the 200ok weblog

The old rules for supporting screen resolutions were simple. Monitors were basically all the same shape and new ones just got a little bigger... so all you really had to do was support the standard resolution of new monitors, plus one resolution "back". Easy!

But these days the rules aren't so simple. Desktop monitors are generally bigger, but they come in a variety of sizes and ratios; and users don't always maximise their browser windows anyway. People are browsing on tiny mobile phones that weren't really designed for anything longer than a text message. Devices like the iPhone, Nintendo Wii and Asus Eee PC are new and shiny, yet their resolution is retro.

All of these displays are new. We don't have a situation where the major differences are divided between new and old, nor is there a linear increase in size as new displays come out.

To really see what this means, let's compare a selection of new device resolutions side by side:

(Statistics from TheCounter.com November 2008 resolution data)

So what difference does it all make? Didn't fluid layouts solve all our problems? Well, unfortunately, no they didn't.

bigger and... broken?!

There's nothing like a real-life demonstration to illustrate how much your monitor can change your browsing experience.

A few months ago I finally upgraded to a 22 inch widescreen LCD from my trusty old 17 inch Sony Trinitron CRT (which lasted ten years). At work I use twin 1280×1024 LCDs, so widescreen is a new frontier for me. I still occasionally feel like I'm watching tennis.

One reason I lingered at 1024×768 was the reality check - amazingly it's still the most popular screen resolution out there. The share is falling, but having dropped just 5% in the past year (from 50% to 45%), it's not going anywhere just yet.

So we keep supporting 1024×768 and I had generally thought that larger monitors wouldn't have any problems. But when I switched over, I was surprised to discover that many sites which work nicely at 1024×768 effectively "break" at 1680×1050.

what's bad at high resolution?

• Fixed width + left-aligned sites
• 100% width + fluid layout
• Tiny text

The single biggest annoyance for me is sites that are left-aligned and fixed-width. That means they're way off to the side on a widescreen monitor, so I'm either looking off to one side or I have to start messing around resizing my browser.

Fluid layouts don't solve everything, since line lengths can get completely out of control. Would you set a line length of 19 inches in print? Not for body copy, I'm sure. But that's basically what happens on my screen at 100% width - and it's incredibly hard to read.

The other major issue at higher resolution is text size - it's just too damn small! I'm forever zooming the page or even disabling styles completely. Designers, please, set larger text!

what's ok at high resolution?

• Elastic layouts
• Fixed width + center aligned

Elastic layouts do fare quite well, so long as they have intelligent minimum and maximum widths set up to preserve line length. Some go too far and end up being as bad as a fully fluid layout, but the good ones subtly adjust to use some more space. Bonus points for bumping up the text size for very wide screens (and I can only think of one here: props to nickcowie.com).

Fixed width, center-aligned sites are great, since they put the content front and centre and keep line lengths readable. At smaller resolutions it looks basically the same as left-aligned sites, so centre-aligned design adds a nice experience for people viewing at wide resolutions without causing any trouble on smaller screens.

so how do you choose a resolution?

With all this in mind, how do you decide on a base resolution to support? Even if everybody browsed with maximised windows it's not a straight call. You end up having to choose a middle ground - no resolution is perfect for every last screen.

Besides that, what does it even mean to "support" a resolution these days? So let's start by defining what we mean by "supporting a resolution".

define support levels

I'm suggesting a graded support system, the same way most of us treat browsers:

Direct support

A resolution where the user can view the default rendering of the site without horizontal scrolling, loading alternative stylesheets or some other form of modification. The design does not have excessive whitespace. Something that works at both 1024×768 and 1280×1024 would mean direct support for both.

Oversize support

A resolution where the design works even if it has a large amount of whitespace, eg. a fixed width, centred design.

Cut down support

A resolution where the primary content is on screen without scrolling, but the user scrolls to see secondary content (eg. having your main content area fit at 800px wide, but the sidebar etc requires scrolling).

Alternative support

A resolution supported via an alternative stylesheet, resolution detection, alternate template, device detection or some other modification from the default.

No support

You leave it to the user (or their device) to sort it out if they are using that resolution.

I'm sure we all have something like this in our heads anyway, but it's better to be precise and definite - particularly when the boss asks you to explain why the site was cut off on his Wii.

use your own stats to make decisions

Nobody's statistics are as relevant as your own, so you should always pay attention to them. Look to global statistics for trends, then apply those trends to your current state.

When I redesigned this blog I found that about 5.8% of visits were at 800×600, 18.6% on 1024×768, 23.5% on 1280×1024. The other 52.1% were at various large and widescreen resolutions above 1280px wide.

I set the minimum cutoff point for direct support at 1024×768 (minimum width 950px). At 800×600 you see the main content and middle column, but have to scroll for the third column.

Then I decided to use oversize support for large screens, capping max width at 1200px.

There's only 250px play between the min and max width; so the line length doesn't change by too much. I could just as easily have set a fixed width, but I prefer to let the design breathe a little.

I currently don't have extra stylesheets for mobiles and other small screen devices. Some random testing shows the site seems to hold up ok anyway. Essentially I'm leaving them in the "no support" category (I might be more interested if mobiles supported the handheld media type).

the process

So basically the process I suggest for choosing a resolution is this:

1. Look at global stats for trends
2. Look at your own stats for current numbers
3. Consider what the trends mean for your stats
4. Allocate major resolution market shares to support categories (create a support matrix)
5. Build to meet the requirements of your support matrix
   • Build your default site to suit the min and max widths of your Direct Support resolutions
   • Support slightly-smaller resolutions with Cut Down Support
   • Support massive resolutions with Oversize Support
   • Where there's a need, build niche stylesheets or templates for Alternative Support resolutions
6. Periodically review your support matrix

That's a very formal way to describe the process, of course. Really what it boils down to is making some conscious decisions; and considering what you want to happen at all the potential resolutions out there.

conclusion

There are a lot devices out there with a crazy array of resolutions. The good news is you don't have to support every last resolution directly.

There's no imperative to fill up the entire screen at massive resolutions; and it's not the end of the world if someone needs to scroll a lot on a tiny-screened device.

Statistically speaking, the majority of people are still using a reasonably standard size monitor to view your content. Widescreen monitors just mean there's more real estate than you actually need to present your content.

So, create a coherent, legible design and don't be scared of whitespace. A good design sitting in the middle of a big space is a better experience than a clever-but-unreadable fluid design.

Of course, next thing you know someone will bring out some new device that changes the whole situation...

Labels: mobile device, screen resolution, widescreen

At WDS07 people were going nuts over the iPod Touch. Legend has it that the infamous Perth gang roamed the wilds of Sydney, buying every Touch in their path! While those reports might be slightly exaggerated, the buzz was certainly high since we don't officially have the iPhone here in Australia - so the Touch is the next best thing.

I was briefly caught up in the moment and spent a heady 45 seconds or so planning to buy one myself. Then I heard about the disappointing capacity, particularly against the price. Since my current iPod holds my entire music collection, sixteen gigs just isn't going to cut it for me! ...and while the interface is cool, that alone doesn't justify the price.

but add a keyboard...

Still, after playing with one for a minute I realised what would be a killer app for me: an iPod Touch and a portable keyboard. The sort of fold-out arrangement you can get for Palm Pilots would be ideal:

why a keyboard?

Why? Because an iPod with a portable keyboard would be the ultimate conference and meeting note-taker for me. I don't need to do fully-fledged web dev at a conference, I just need to take notes. I generally use Dreamweaver since that means I don't have to reformat my notes later if I want to blog them; but any text editor will do.

So a laptop is overkill and just weighs me down on the way to the pub. An iPod Touch and keyboard would weigh bugger all compared with a laptop. The keyboard would need its own power, so it could easily contain a kickarse auxiliary battery and still be relatively light. The touch screen also means you don't need a mouse.

Of course I could just go get a Palm Pilot and a wireless keyboard... but the Touch does have a damn fine screen (rivalled only by the PSP) and the touch interface means no stylus to lose on the bus. Not to mention that, yes, the Touch is cooler than a Palm Pilot (don't try to tell me geeks aren't into shiny toys ;)).

accessibility

Adding a keyboard to some of these devices might also have an accessibility benefit. Touch screens currently lack tactile feedback (you can't feel a touch screen "keypress"), so on-screen keyboards are pretty useless to a blind user. Adding a keyboard would also help anyone who sends a lot of text messages - including hearing-impaired people.

Obviously a keyboard alone won't make devices accessible - many of them don't currently vocalise their menus and so on. But a keyboard would certainly help on the input side of things. They might even prevent a bit of SMS-thumb RSI!

It's a case where accessibility moves into the realm of usability. Sure, the little keypad on a phone works just fine to send texts and peck out short emails - but a full size keyboard is more usable. I can also see full-size keyboards being popular as the mobile-savvy baby boomer generation ages, since the tiny buttons on most phones are hard to use if your eyesight is going or you're not quite as dextrous as you once were.

ultraportability (is that even a word?)

At the end of the day I don't specifically have to have an iPod with a keyboard, it could be any small, web-enabled device with a reasonable screen. Data charges aside, a phone would have the significant advantage of being able to connect even when there's no wifi available. Currently in Australia that basically means "anytime you're not at home", although Meraki mobs may change that.

I'm really just looking at the potential of adding a real keyboard to an existing web-enabled mobile device. As John Allsopp recently highlighted, the mobile web suffers from poor text input. Adding a keyboard would take many devices from "annoyingly slow" to "quick and easy", without adding three kilograms of dead weight to your bag.

Here's hoping more devices start getting portable keyboard options.

Labels: ipod, ipod touch, keyboard, mobile device, palm, portable, ultraportable, wds07, wireless keyboard

Or, How I learned to stop worrying and love the stylus

Most people in IT are exposed a lot of different web-enabled devices, but we probably don't pay enough attention to their interfaces. Many web developers have a tendency to just think about desktop PCs running Windows, or perhaps they'll think about Macs too. But what about all the other devices?

I've been pushed into thinking about this over the last few days, mostly because I've been using a borrowed tablet PC while my desktop was having some niggly hardware problems. The way I've used the tablet is substantially different from any other device I've used before.

devices and their interfaces

Let's take a look at a few of the devices people are using. I won't dwell on desktop PCs of any flavour since they're reasonably consistent: keyboard, mouse, full size monitor. Walking across a university campus, you're increasingly likely to see any and all of the following devices.

laptop pc

Usual inputs

• keyboard and touchpad/joystick/trackball
• when docked, full size keyboard and mouse

Gotchas

• a lot of people are slower when using touchpads and joysticks

tablet pc

Usual inputs

• stylus and on-screen keyboard when undocked
• any combination of stylus, keyboard and mouse when docked

Gotchas

• forms with no submit button - the stylus "clicks" so you have to pull up the on-screen keyboard and use the enter "key"
• precise clicks - the stylus tends to drag a little when you're trying to click, so very small click areas and close-spaced links can be irritating
• links with no "active" style - when you're not completely sure if the click has registered (or if you clicked the right thing), you'll really wish there was an active style on the link

Notes

• absolutely awesome for any interface which uses click+drag (play Solitaire or Bejeweled to see what I mean)
• if the interface is sensitive enough, great for drawing
• users far more likely to switch between portrait and landscape orientation

mobile phones

Usual inputs

• keypad, sometimes joystick-style buttons or stylus
• some models have extras like little keyboards and so on, but they're not especially common

Gotchas

• apart from phones with Opera, the embedded browser is likely to be pretty limited with unpredictable support for standards, plugins, etc
• almost none of the browsers properly support media="handheld" ....yet, hopefully
• most phones have low bandwidth connections and/or can't load big files
• some interfaces forget the "enter" key and can only submit forms with the stylus (or the user won't know how to find the enter key, which is effectively the same)
• very small screens (relatively speaking)

pda and handhelds (including game devices)

Usual inputs

• stylus which is also used to enter text with graffito or on-screen keyboards
• many PDAs have addons like keyboards or mice, but they're not universal
• game devices often have cross-pad devices, some have joysticks

Gotchas

• all stylus-related limitations of the tablet pc
• all browser/UA limitations of mobile phones
• relatively small screens or even split screens (eg. Nintendo DS)
• some screens have glare/backlight issues
• some have very odd text input methods - eg. the Sony PSP takes some getting used to and URLs are a pain to enter

user familiarity masks problems

Users do find ways around many limitations, or become so used to poor workarounds that they no longer think of them as "problems". However if you have a system that needs lots of workarounds, users are also likely to simply stop using your system and go elsewhere. User familiarity should not be seen as a substitute for good usability.

connecting in the first place

Many of these devices have "wireless capabilities" but this can mean many things. Wireless LAN without security, wireless LAN with security, bluetooth, WAP, etc. A large number of devices can connect to a wireless network but won't get past corporate VPN requirements. For example there's no VPN client for the Sony PSP, which put an abrupt end to our wireless testing at work (although the PSP is actually capable of using most of our systems, so long as VPN is down at the time).

Even if you can connect, wireless networks (at least in Australia) usually aren't the nirvana you might wish for. Slow, prone to dropouts and generally not free, wireless is absolutely not "ubiquitous" and not necessarily "high speed".

so what do we learn from all this?

To a large extent, you could summarise by saying that - between all the options- users with devices other than desktop PCs have the same requirements as disabled users. That means some of the most technology-savvy, youngest and brightest users are actually the ones at risk of hitting problems. The user base also includes key decision-makers like managers, CEOs and so on who like to have the latest and greatest toys.

One interesting thing to note is that some users are essentially mouse-only users, which is less commonly considered than keyboard-only users. Most devices do offer a keyboard substitute but many of them are limited.

conclusion?

Here's the good bit. You can cater to varied devices by doing all the "right things": build to standards, don't use tables or fixed width layouts, let users choose or override style settings, keep page weight to a minimum.

It's not a new message, just a lot of new reasons for the ones we already know. Best of all, they're reasons based on the latest gear rather than any form of moral highground or expectation that everyone wants to follow Best Practice.

Standards are good for the boss's latest PDA; your kids' expensive new game handheld; and the tablet PC you kind of wish you didn't have to give back to your employer. They're not the most laudable reasons, but they sure do motivate people.

Labels: graphics tablet, hci, interfaces, keyboard, mobile device, mobile phones, mouse, pda, stylus, tablet pc, trackball, ui, ux