Slightly ajar

Over the last year or so there has been an increasing visibility of the web away from the desktop, especially with the rise of Opera Mini (which we've just announced over 1 million downloads in 10 days) and the hype of the iPhone. That isn't the only way to see the web away from its traditional confines though, and the launch of a white games console from the N company paved the way for another kind of experience - surfing from the couch. What makes this unique and what should you look out for?

If you take the experience on a phone, there are some constraints and differences you have to look out for. Even though they are called Personal Computers, a PC is generally anything but, with many people sharing one machine. On the other hand a phone is very personal. A phone is rarely shared, people keep them with them at all times, and customise them heavily. It is therefor logical that personalisation is something that should be taken into account for a successful mobile web experience, and it should be optimised for 1 to 1 interaction, just like the desktop. The TV on the other hand is a much more social affair. There is probably not many sites more popular on the N companies console that YouTube. what is more fun, having friends bunched around a desktop in the office, or sprawling out on the couch with a pizza watching the latest funny clip? The web on a TV is meant to be shared between many people. Information isn't private, as many people can see the screen at once and the tV is probably in one of the busiest rooms in the house. The Big N take great advantage of this with multiple controller support. Other users can point at things on the screen individually. With some imagination this could be taken advantage of in interesting ways. Wiicade for instance allow for multiplayer games. Apart from Video, Music and Games, social networks could be an interesting area for innovation. Presently there isn't much social going on in the popular networks - one persons interacts at a time.

So what are the constraints? We'll it is different than mobile. With mobile you have slow latency and low bandwidth (unless you are connected to Wifi). TVs in general are connected to Wifi or a wired network. Mobiles also are limited to the palm of your hand, while TVs are generally much bigger than your desktop or laptop. The problems in this area are viewing distance and resolution. A standard definition TV has a resolution of 720 by 576 (PAL 576 p/i) or 720 by 480 (NTSC 480 i/p) and in reality the viewable resolution is lower than this due to inefficiencies. This low resolution causes bigger problems as the screen sizes are usually large so the pixel density is very low, and text can be blurry and hard to read. As technology marches on these problems will fix themselves. 720p (1280 by 720), 1080i and 1080p (1920 x 1080) displays are already on the market and fairly popular (note: the most popular TV browser doesn't support HD), and the resolution is around that of regular computers. Whether the user has a HD TV or not though, the same constraint is present. The user will usually be sitting on the sofa, a good distance from the screen. You as a designer have to take this into account, and is sometimes called the 10 foot interface. Even on a big HD screen, the text should be designed to be enough to read. This limits what can be displayed at one time. Consider restricting the number of columns and including side bar content, that isn't regularly accessed, under the main content. Browsers are gaining high quality zooming functionality (Such as Opera's Intelligent/Adaptive Zoom) , but the experience will be better if the text is readable without having to zoom in and out.

The methods of interaction can also be difficult. Just like mobile, this is hard to predict. A set top box or TV could come with a wireless keyboard and trackpad/scroll ball, or it may come with just a remote (that can vary themselves). It may even come with a magic wand that follows the users hand movements. Unless a keyboard is available (this shouldn't be assumed) then text entry will be a pain (although experience makes this easier) so avoid making a user add unnecessary text. Consider implementing OpenID for example, and keep the URLs short. Use device independent event handlers in your JavaScript where possible.

Just like mobile, you don't have to make a separate optimised page for TV browsers. Media Types and Media Queries come to the rescue. You can define a separate stylesheet just for TV browsers or you can adapt your existing stylesheet to bump up the text size and refolw the layout for example. Using a combination of the two, you can progressivly enhance the layout as you detect higher screen resolutions. If you have stylesheet that either has the media attribute set as all or tv (or screen, tv and other combinations of different media types) you can include the following CSS:

@media tv {
     /* catch all for any tv that don't fit the queries below */
}

@media tv and (min-device-width: 720) and (device-aspect-ratio: 4/3) and (scan: interlaced) {
     /* styles for 480i standard ration TVs goes here */
}

@media tv and (min-device-width: 720) and (device-aspect-ratio: 4/3) and (scan: progressive) {
     /* styles for 480p standard ration TVs goes here */
}

@media tv and (min-device-width: 1280) and (device-aspect-ratio: 16/9) and (scan: progressive) {
    /* styles for 720p widescreen TVs go here */
}

@media tv and (min-device-width: 1920) and (device-aspect-ratio: 16/9) and (scan: interlace) {
    /* styles for 1080i widescreen TVs go here */
}

@media tv and (min-device-width: 1920) and (device-aspect-ratio: 16/9) and (scan: progressive) {
    /* styles for 1080p widescreen TVs go here */
}

If the stylesheet is just for tv you can leave the first catch all media query out and just include the styles without a media query. If you use all or include other media types in the statement, you probably want the media query so that screen browsers or printers don't get the TV styles (unless you want them to of course). Depending on your design, you'll probably not want to include all those media queries and just adapt the layout and text sizes where needed. You may also want to use max-device-width instead of min-device-width and exclude some of the extra conditions. It may not be important if the screen is interlaced or progressive for example. Aspect ration may be important if you use multiple columns, as a widescreen display will fit more content horizontally (or will at least have more real estate, maybe not more pixels). You milage may also vary with what browsers support which media queries. device-width should be the most supported. Opera and WebKit based browsers are the only browsers that currently support MediaQueries as far as I know, but they are part of CSS3 and any device based browser worth its weight in salt should add support for this.

Finally, you should take into account the colours, thickness of elements and movement on TV. White and red in particular are hard to read on TV (My blog won't be great then) as the bleed (I'm not sure if this also applies to HD TVs?) and so should be avoided if possible. One pixel elements, such as borders can also bleed, so consider using 2 pixels at a minimum. Fast movement on older TV can also cause ghosting, so be careful in this regard. Speaking of movement, media playback is often a problem as a company has to licence the codecs or plug-ins. This makes it very variable if a format is available or not. Flash is generally the most supported, but generally needs to be saved as version 7 or lower. Avoid Quicktime at all costs, as it is only available on Mac and Windows (or Apple's own hardware). Many devices come with some form of embedded linux for example, where this is not available. Windows Media is not much better, if at all. This is one of the reasons why Opera (and Mozilla) are pushing for a Ogg Theora solution. It is an open standard, that can be implemented and shipped by anyone without paying licensing fees or royalties. Including this in a browser allows it to be used on devices and become a baseline format that people can deliver to. This is something for the future however, and no browser on TV that I know about supports this yet.

So in summary, make your text readable at ten feet, think collaboration, think social, avoid unnecessary input, progressively enhance for HD with Media Queries, and avoid those sharp bright colours.

The iPhone has now been released to much fanfare. I'd like to run through a few things on what this means to web developers and those that want to optimise their sites to work on mobile web browsers.

The first point that has to be raised is that Apple also believe in the One Web approach, where they feel that mobile browsers are capable of rendering regular web pages and optimisations can be made by giving an alternative stylesheet customised for the smaller screen. This is a view that Opera supports. Makers of WAP browsers will probably disagree as they don't have the technology to display regular web pages correctly. It isn't a black and white case of course. Sometimes it is nice to have a mobile specific version, such as when the content is very location aware, or the application is complex so it would take a lot of work to optimise the regular site. I would say on average is is best to leave the page as it is, and rely on technology such as Opera Mini's intelligent zoom or iPhone's zoom, or optimise the CSS (more on that later) for web pages (blogs, wikis, news sites etc) and do a custom mobile version for web apps like Flickr or Gmail etc. With a mobile specific site a link should always be given to go to the regular site, as there may be information there that wasn't provided on the mobile version.

If using One Web principles, the issues comes with trying to optimise the CSS for mobile. The W3C spec has a solution for this; the handheld media type. The principle being that computers use Screen media, when printing Print is used, Handheld for mobile phones, PDA and small handheld media devices/tablets and so on. This sounds rosy, except Apple and Nokia in their wisdom have decided not to support Handheld. That may be fine if they didn't want authors to optimise the layout for iPhone/S60 Phones, but Apple clearly do in their developer documentation (click on Optimise for Page Readability and scroll down). They state that iPhone ignores the print and handheld media queries because these types do not supply high-end content. Where they get this idea from I've no idea. It is obvious they don't need to support print (Opera Mobile and Mini don't either) because you are not likely to hook your mobile up to a printer and print the document, but print media has nothing to do with high or low end content. It is the same for Handheld, and it should be used for doing exactly what the suggest; specifying a stylesheet for mobiles. They get around the lack of handheld support by using Media Queries. This is a solution I've proposed in a previous article. This works well and gives a lot of fine grain control, but it would be much simpler to just support handheld media to get the same effect. That would get around any issues where a desktop based browser could get the mobile stylesheet due to using the screen media type, and where older mobile browsers will not get the mobile stylesheet as, as far as I know, only Opera based and WebKit based browsers support Media Queries. It is also worrying that they seem to suggest that developers should design specifically for the iPhone, and not mobile browsers in general, especially with a CSS filename of iphone.css in their example. This is a case we tried to avoid when the Wii browser was getting popular, by adding TV media support, so that all TV based browsers would benefit from the optimisations. There are of course exceptions where a web site is and should specifically be aimed for one browser and device, such as when Wiicade make use of the Wiimote hardware for example. In the case of the Apple documentation they give the following code suggestion:

<link media="only screen and (max-device-width: 480px)"
href="iPhone.css" type="text/css" rel="stylesheet" />

I'd suggest changing it to the following:

<link media="handheld, only screen and (max-device-width: 480px)"
href="mobile.css" type="text/css" rel="stylesheet" />

That way it will work on any devices that support handheld media (and makes sure Opera Mini 4 doesn't apply its desktop overview mode) and also on mobile devices such as the iPhone and Nokia S60 browsers which only support Media Queries.

Apart from the handheld debate, it is interesting to note that iPhone suffers quite a few of the same limitations as Opera Mini. Notably that it doesn't support file downloads or uploads (although you can upload from the camera in Mini), no plug-in support such as Flash, limited javaScript execution time etc. Although these are draw backs of both browsers, it does mean that it will make the base line that developers can aim for much more consistent. Fixing issues in one browser should fix many issues in the other browser.

One thing of note on the iPhone that is interesting to me was revealed in Daring Fireball's iPhone First Impressions. That is that the UI's interface uses the Helvetica font. This is interesting for a couple of reasons. First of all OS X usually uses Lucida Grande as its default UI font. I wonder if there was any reason for the choice, or if it just looked better on the smaller but high resolution screen? Either way I love the Helvetica font, so I think it is a nice choice. The most interesting thing for web developers though is that it means one important thing — that regular desktop quality fonts are available on the iPhone. This is not really a surprise, as it is based off OS X after all, but it is nice to have confirmation. One of the biggest problems with mobile development in my mind is the inconsistencies between devices caused by font support on phones. many only have one font (which is of quite low quality) and some have very limited text sizes available. It is also common that italic isn't even available. I don't have a iPhone, so I can't confirm if any other fonts are available. I'd expect they'd include the Microsoft core fonts (in the Web folder in FontBook) such as Arial, Times New Roman and everyone's favourite Comic Sans MS. I think it is important for consistency in mobile web design for handset providers to start providing the same fonts across models and brands. Web Fonts could solve the problem but it will be a while before they are supported across multiple mobile browsers, and a user probably doesn't want to download large font files across a slow EDGE network.

<p.look out for our Opera Mini 4 developers guide soon. it is in the final stage of preparations. As Opera Mini 4 is in beta, standards support will likely change for the final release, so look for updates to the document as time progresses.