-
Designing websites for the Nintendo Wii
Jun 19, 05:11 PM
Yesterday was my 25th birthday, my beautiful fiance gave me a Nintendo Wii, as soon as I had it set up I wanted to expand it, install things and connect it to my mac. I bought some credit and downloaded the Opera internet browser for it – upon trying out mine and a few other self-designed sites, I found that the pages just didn’t look quite right so immediately set upon trying to find a way to create a specific css file for this console’s browser.
I found a link pointing to the Opera website where the article in question has disappeared, fortunately for us the Internet Archive comes to the rescue
This is the article in question:
Making Wii-friendly pages
By Mark ‘Tarquin’ Wilton-Jones ยท 30 May, 2007
Overview
Web Specifications
The Wii game console by Nintendo has a Web browser that uses the Opera 9 display engine. It supports most Web technologies supported by Opera 9 for desktop, including HTML, XHTML, XML, WML, RSS and Atom, CSS, XSLT, SVG, and JavaScript except designMode, contentEditable, and Audio. It does not support FTP, NNTP, IRC, XHTML+Voice, or widgets.
For details, see the complete list of supported specifications.
Display
Web pages are displayed using a virtual screen size that is 800 pixels wide with varying height, using tv or screen media. The display can be zoomed by the user.
Interaction
The browser uses a controller similar to a mouse. It also has an on-screen keyboard that has very limited key event detection. However, the controller offers some additional buttons to provide extra possibilities.
Read more about the Wii remote.
Windows
The browser uses a single window that cannot be resized, and allows a maximum of one additional pop-up to be open at any time.
Plug-ins
The browser supports Flash 7 as the only plug-in.
Introduction
The Wii is a game console whose defining characteristic is its motion sensitive controller; the Wii remote. The Wii also has a Web browser called the Internet Channel that the user can download, and although it looks quite different from its desktop cousin, the browser is Opera. The Wii output is displayed using a regular television screen, which would normally be a very poor device for displaying Web pages, so the browser has several features suited to displaying Web pages on a television screen. In most cases it will work with Web sites without any changes, but you may want to make various enhancements for Wii users to give them the best possible experience with your site.
The Wii browser is based on the Opera 9 display engine, so apart from some small differences relating to its interface, the browser’s HTML, CSS, and scripting capabilities (including XMLHttpRequest/AJAX) are the same as Opera 9 for desktop.
Most Web pages are designed to fit on a desktop computer screen, whose size may be 800 pixels wide by 600 pixels high, or 1024 by 768, or higher. Television screens are usually much smaller, with those used in North America being the lowest standard resolution; 720 by 486 pixels, which may be reduced to less than 550 pixels wide due to the inefficiencies of the television. With the Wii browser, however, this low resolution is generally not a problem.
How Opera displays Web pages on Wii
Instead of reformatting the page to attempt to make it fit on the screen, Opera on Wii lays the page out as if it was using a virtual screen 800 pixels wide. The height of the virtual browser window changes depending on various settings, but can be between 376 and 660 pixels high. The page is then scaled down to fit inside the display of the user’s television. If the page needs more than the size of the virtual browser window, then the user can scroll in whichever direction is needed, to see the rest of the page.
With a good quality television, most Web pages can be used and read like this (although it can be a little difficult). In some cases it may not be comfortable enough for reading, however, so the page can be zoomed to read the parts that the user is interested in. Zoom is available either as manual, where the user can zoom in or out as much as they want, or as automatic. The automatic zoom is adaptive, in that it will work out what part the user is interested in, based on where they point the controller, and it will attempt to zoom in the right amount to fit that content inside the width of the television display.
This has limits at each end of the scale: If the desired content is too wide, over 640 pixels, all of it cannot be displayed when zooming. If the desired content is too narrow, under 250 pixels, then it will not be possible to zoom in enough to make that content fit perfectly inside the display. In the first case, the browser will zoom in to a nominal value, and the user will have to scroll sideways to see the rest of the content. In the second case, some of the surrounding content will also be shown.
The Wii remote
Since the Wii has only one main controller (the secondary controller does not make much sense in a Web environment), it has to perform all the user interaction with the page using that controller. This means that the Wii remote sometimes functions as a mouse, and sometimes as a keyboard.
As long as it is pointing at the television, it is a mouse. Wherever the user points the remote, the mouse cursor will point. When the user presses the A button, it is the same as clicking the left mouse button. When the remote stops pointing at the television, it becomes a minimal keyboard. Pressing the A button then is the same as pressing the Enter/Return key on a keyboard.
Scrolling the page is normally done with the trigger button. This works as a panner, in the same way as middle-clicking the mouse would work on desktop, except that it only scrolls as long as the user holds down the button. The page will scroll in whichever direction the user points on the screen. The user can also scroll using the directional control on the controller, with the added benefit that this can also scroll within scrollable parts of the individual page. However, if possible, you should avoid using framesets, inline frames, and elements with scrolling overflow, as they require the user to use a scrollbar or directional control, instead of the normal panner mechanism.
The user can also use button combinations to perform common actions, to allow normal functionality if the toolbar is hidden. These are done by holding the B button, and pressing one of the other buttons on the Wii remote. Key combinations are available for the +, -, up, down, left, and right keys, performing the functions Forward, Back, Reload, Open Favorites, Search, and Web Address respectively.
The virtual browser window
The Wii can be used in normal (4:3) or widescreen (16:9) mode, if the television supports widescreen. The browser toolbar can be set to always display, to automatically hide, or to toggle when the user presses a button. The user can also change the width of the display, to compensate for the inefficiencies of their particular television.
Depending on the display width the user has set, the widescreen settings, and whether or not the toolbar is set to hide, the visible area of the page can be anywhere between 376 pixels and 660 pixels high. Specifically, the following ranges of heights indicate whether the toolbar is set to always display, and whether widescreen mode is being used:
376-420 Widescreen with toolbar set to always display. 452-496 Widescreen with toolbar set to auto-hide or button toggle. 500-560 Normal screen with toolbar set to always display. 600-660 Normal screen with toolbar set to auto-hide or button toggle. The following JavaScript automates detection of these settings; note that the settings can be changed after the page has loaded:
var toolbar, widescreen, tempheight = window.innerHeight; if( tempheight >= 376 && tempheight <= 420 ) { toolbar = true; widescreen = true; } else if( tempheight >= 452 && tempheight <= 496 ) { toolbar = false; widescreen = true; } else if( tempheight >= 500 && tempheight <= 560 ) { toolbar = true; widescreen = false; } else if( tempheight >= 600 && tempheight <= 660 ) { toolbar = false; widescreen = false; }Also note that properties such as screen.height should be avoided as they relate to a virtual screen size, not the actual size of the screen, or the space used by the virtual browser window.
Page addresses and forms
As the Wii is not designed to be a desktop computer, it does not use a traditional keyboard. Instead, it uses an on-screen keyboard that is displayed in place of the Web page. The on-screen keyboard offers a fairly complete set of keys, but it is nowhere near as fast to type with as a regular keyboard. The user needs to point the Wii remote at the letter and press a button. There is a word completion option that the user can enable, but it can only complete words in the user’s chosen language, as well as some common top level domain names. It cannot show a list of previously visited addresses, so it is not possible to modify these.
Writing uppercase characters requires an extra button press to enable uppercase mode. Some characters, such as those with accents, require searching through an extra set of available characters. Some characters cannot be typed at all, such as the Welsh w-with-circumflex character, Polish L-with-stroke character, Arabic characters, and so on. There is also no copy/paste functionality, so writing the characters near the input to allow the user to copy them into it is not an option.
Long page addresses take long to type. Addresses that mix uppercase and lowercase characters require additional key presses to enable or disable uppercase. Addresses that use accented characters are particularly laborious. As an example, the following page address is very awkward to type:
www.example.com/2007/20/01/{Touche}?id=17+omThe following page address is much more convenient:
example.com/toucheThis extends to forms as well. When filling in a form, it helps if the form can provide as much of the information as possible. For example, if a certain form field is always expected to begin with “http://”, then it will help to have this as the default value of the input. Do not force the user to type if they do not have to. In some cases, pages demand that the user fill in a form field even if that form field is not really essential. This means the user has to put the effort into typing when they should not have to, and it may be enough to put Wii users off filling in the form at all.
Some input types can be used in place of simple text inputs. If an input expects one of a certain selection of values, you could use a SELECT input. In addition, like Opera 9 on desktop, Opera on Wii supports Web Forms 2.0. This means that in many cases, the amount of typing required can be reduced by using a native input. Take, for example, a form field that represents a date. Traditionally, a normal text input would be used:
<input type="text" name="somedate">However, you could also use the date input type for this, and Opera will then present the user with a calendar where the date can quickly be selected:
Browsers that do not understand Web Forms 2.0 will display a normal text input instead, meaning users do not see any difference between the two inputs, while Opera users will be given a convenient date control. See the demonstration.
Note that forms have two further limitations. Firstly, the file input type is not available, and will always be disabled. This means that it is not possible to upload files. Secondly, the way the keyboard works means that it is not possible to submit a form by pressing the return key. If the form is designed to be submitted, you should always provide a submit button or image input, and not rely on the user being able to press their return key to submit the form.
Browsing history
In order to minimize resource usage, Opera on Wii is limited to a maximum of six history entries for the main window, and six for any pop-up. This means that in the browser window, the user can use the back button a maximum of five times to see previous pages in their browsing history.
If a visitor is likely to follow links more than that depth into your site, and they want to return to the main index page of your site, they will have to find a link to it, or type it in again. It is not possible for them to see or modify a list of their visited history, and they also cannot modify the address of the displayed page in order to minimize typing. Typing is, of course, unwelcome, so it is best to ensure that each page they might visit has an obvious link back to the index page, or at least to a section index which in turn links back to the main index.
Special CSS considerations
Opera on Wii is a television browser, and by default, it will use tv media. However, since the majority of sites do not cater for tv media, it will revert to using screen media if no stylesheets specifically for tv exist. Since it is designed to behave like a desktop browser, this allows it to work well with the majority of sites, but allows you to give it specific styles as a television browser if you think that it needs them. Note that the tv media support is based on continuous media only, and it is not possible to use paged media features.
In accordance with the CSS specification, when Opera is applying tv media, it will use only that one media type, and will not combine tv and screen media at the same time. If you intend to style a page using tv media, you cannot use screen media for the main styling and then override just a few styles in tv media, because Opera will just use the tv media content, ignoring the screen media content. Instead, you should either style the page for Opera on Wii completely in tv media, or make sure the main parts of your stylesheet apply to all media types, then apply overrides using a specific tv media section.
The user can optionally enable Opera’s Small Screen Rendering, but unlike Opera Mobile, it will act on screen media, and will ignore handheld.
Usefully, Opera on Wii also supports CSS 3 media queries, allowing you to adapt your site’s layout to suit the display resolution that Opera uses. The media queries will work with the virtual browser window size used by Opera, so width is 800, and height is whatever the current virtual browser window heigh is.
If your page’s design is unusable when the browser window is resized to 800 by 376, it will not work on Opera on Wii (hint; use Opera on desktop and set the preference Tools > Preferences > Advanced > Browsing > Show Web page dimensions in title bar). However, assuming that you use CSS to define your layout, you can use media queries to define a different layout for different sized browser windows. For example, if your design cannot be used when the browser window is 900 pixels wide or less, you can define different styles for smaller spaces like this:
#nav { float: left; } ... @media all and (max-width: 900px) { #nav { float: none; } }If you organize the layout of your page into columns, it can help to make sure that each column is less than 640 pixels wide. This will ensure that the automatic zoom can perform optimally, to allow the user to read the content without having to repeatedly scroll sideways.
There are also some other considerations that need to be made for television screens. In general, they do not cope well with high contrast, which can cause the colors to shimmer badly and bleed into each other, and the rest of the screen display to become washed out. In general, it is best to try to avoid high contrast on television displays, but in particular, avoid large areas of bright red. This means, for example, that a bright red block should not be put next to a white block.
See the color bleeding demonstration (warning; demonstration can be uncomfortable to look at on some displays).
Note that since Opera on Wii uses tv media if it is provided, you can use that media type to give it a different style sheet.
Fonts
Only two fonts are available on Wii; a generic sans-serif font called “Wii NTLG PGothic” and a monospace font called “Wii NTLG Gothic”. These are visually almost identical, but the monospace version has the letter spacing adjusted slightly to maintain the same width for each letter. As a result, it generally does not matter what font your page attempts to use, because Opera on Wii will always end up using the same sans-serif font, and will look the same as if you attempt to use any other font. The fonts can be displayed in normal, bold, small-caps, and at different sizes, but not italic.
The fonts contain all characters from the ASCII character set, basic accented Latin characters, basic Greek characters, most Japanese characters, most Simplified Chinese characters, a large number of Traditional Chinese characters, common Cyrillic characters, and some of the more popular symbols. Characters from most other scripts are not available, such as Devanagari, Arabic, and Hangul. Some of the less common characters from available character sets are also not provided, such as those used by Hungarian or Welsh. If characters are not available in the font, a placeholder square will be displayed where that character would have appeared.
Special JavaScript considerations
JavaScript is perhaps the part that exposes the most differences between Opera on desktop and Opera on Wii.
As with CSS, JavaScript will see the virtual browser window size, not the actual television resolution: window.innerWidth, and similar properties, such as document.body.clientWidth, will all be 800. window.innerHeight and similar properties, such as document.body.clientHeight will all give the height of the virtual browser window. Properties such as screen.height cannot be used.
However, it is in the interaction with the interface that most of the differences lie. Since the browser remains always full-screen, windows cannot be resized. Pop-ups are supported, but replace the opening page, are displayed maximized, and cannot be resized. The opening page is hidden behind the pop-up, and the user can return to it by using the Back button. It is not possible to open more than one pop-up at a time, so if one pop-up opens another pop-up, it will replace the first pop-up.
Advertisements are particularly bad for this, so the pop-up blocker is used, and set to block unwanted pop-up windows. If your site makes use of pop-ups, you should make sure that they are only opened on request (such as when the user clicks a link), never open more than one at once, and make sure that the pop-ups do not open at the same time a new page is loaded in the opening window.
The screen size can also produce some limitations. In particular, DHTML menus can be a problem if they contain too many items. They can be unreadable if text is small, and when the user zooms in to see better, they may extend beyond the screen size. Because the scrolling also requires the same controller, the menu items can become very difficult to access, as they may close when the user tries to scroll to see the bottom.
Because of the limitations of the keyboard interaction, Opera on Wii cannot support designMode or contentEditable, used for creating rich text editing controls. Most scripts that provide these controls will detect if the browser supports them, and can show a normal textarea instead. Support for rich text editing can be detected using this code:
if( typeof(document.designMode) != 'undefined' || typeof(document.body.contentEditable) != 'undefined' )Event detection
When the Wii remote is being used as a mouse, it fires the same events as a normal mouse would do, such as mouseover, mousemove, and mousedown, with the exception that it cannot fire the dblclick event. There is no equivalent to the right mouse button, so custom context menus cannot be used.
Many pages, and in particular games, make use of key detection. They check when the user presses a key, and run some script when that happens. Most of these pages will also work with a mouse, but some pages may still need keyboard interaction. It is not possible to use the on-screen keyboard except within a text input. The on-screen keyboard cannot pass any key events back to the page. This also means that it is not possible for the user to use modifier keys such as Shift, Ctrl, or Alt while clicking on the page.
The only key events that can be detected are those that are sent by the Wii remote buttons. Some of these perform functions that cannot be detected, but most can be detected and used by scripts. The keyCode properties of the events are not the same as the equivalent keys used by desktop, where available, because they perform the functions of desktop key combinations, not single keys. The keyCode property for these keys are as follows:
Directional control up/down/left/right
175/176/178/177 – normal keyboard uses 38/40/37/39 for arrow keys
Button A (normal select button)
13 – only functions as a key while the mouse cursor is not being used, otherwise it is left mouse button
Button B (trigger, used for panning)
171
+ and – (zoom in and out)
174 and 170
Button 1 (toggle display of toolbar)
172
Button 2 (toggle small screen rendering)
173If the user uses a key combination, such as B+Up, these will be seen as two separate key events, but the sequence of keydown and keyup should show that a combination was used. Note that this pattern will only work if the associated keypress events are cancelled.
The keypress event can and should be cancelled if you wish to use key events to override the normal behavior of the buttons. For example, if you wish to use the directional control to provide directional response in a game, you can detect the key presses of those buttons, and use them instead of normal arrow keys. However, those buttons will attempt to scroll around the page. Either return false from the keypress event handler function, or use the preventDefault method of the event object, to prevent the scrolling. Of course, it is important to make sure that the scrolling is not actually needed by the user before you prevent it.
document.onkeypress = function (e) {<br> if( e.keyCode 175 || e.keyCode 38 ) {<br> moveup(); return false; } else if( e.keyCode 176 || e.keyCode 40 ) { movedown(); return false; } else if( e.keyCode 178 || e.keyCode 37 ) { moveleft(); return false; } else if( e.keyCode 177 || e.keyCode 39 ) { moveright(); return false; } //allow other keys to work return true; };Note that button 1 can be detected, but its keypress event cannot be cancelled.
Images and plug-ins
Opera on Wii has the same image capabilities as Opera on desktop. This includes JPEG, GIF, PNG (with alpha transparency), BMP, ICO, SVG 1.1 basic, and scripted canvas. If your images display correctly in Opera 9 on desktop, then they should also work on Wii. With plug-ins, however, there are some significant limitations. Only one plug-in is currently available for Wii, and that is the Adobe Flash Player 7 plug-in. Opera on Wii does not have any download capability, so the user cannot download extra plug-ins on request. The wmode=“transparent” attribute is not supported, so plug-in content that is supposed to be transparent should not be made to overlap other content, as it will obscure it.
The Wii has a processor with performance that is less than half that of most desktop machines, and with about one tenth of the available RAM. As a result, it can have trouble with Web pages that attempt to display hundreds of images, or large Flash movies. In particular, streaming video players written for Flash can have problems with buffering, as they quickly use up the available memory.
Most Flash games, however, work well enough, as they are not so demanding on memory. However, it is important to note that the same restrictions apply to keyboard interaction as for JavaScript. This means that games that need the user to be able to press the space key, for example, will not work. Flash also has very limited Wii remote button detection. It can only see the mouse pointer and left mouse button click.
It is possible to detect the Wii remote buttons using JavaScript, but since communicating between JavaScript and plug-ins normally needs Java for LiveConnect, and Java is not available on Wii, this means that JavaScript cannot directly communicate the button presses to the Flash movie.
There you go, it was a lot I know, but pretty useful I think for the minority that actually use this browser regularly.
As I said before, I did not write this article, I am merely reproducing it for reference, it was originally published on the Opera Dev website
RSS