Re: Proposal to specify behavior for terminals without touch hardware

I don't like these paths.

I'm using my Nokia n900 w/ the native browser (which predates touch events).
- When I visit Facebook, I can choose from <mobile, touch, desktop>.
Each of these are useful. The touch site is useful even though I don't
have multitouch hardware and even though the browser doesn't really
send anything remotely touch related.
- What the browser does have is a small screen with a reasonable
chance that the user will want to have big hit areas.

The right approach that web developers should take is more or less the
approach that Facebook took:
1. design a site for <desktop>
2. design a site for <mobile>
3. provide a way to switch between <desktop> and <mobile>
4. design a site for <touch>
5. provide a way to switch between <mobile> and <touch> and from
<touch> to <desktop>
6. provide a survey link in <touch> to find out about capabilities of
clients (crowd sourcing is good)

My desktop is actually more of a touch enabled tablet than a desktop
(1024x600 - multitouch capable) - but my browser isn't touch enabled.
Facebook still lets me select the touch site, and it's useful to me.

People like to think that they should be able to automatically pick
the only format for users. But this really isn't the smart way to do
business -- good businesses understand this. Consumers like being able
to choose from a couple of different things based on their current
needs. Sometimes I choose the mobile site even though I'm using a
desktop capable computer -- often this is because I'm being charged
for data and thus the mobile site saves me money.

Detection is better done using other means:
1. Does the user seem to be clicking the wrong link a lot? -- This
could be indicated by many requests which are aborted or replaced by
other requests shortly afterwards where the original request never
appears in sub resource referrer requests and the later request does.
If so, the hit regions are probably too small and the site should
offer a touch version to the user.
2. Does the user seem to have a slow link? -- This could be indicated
by a high delay between requests for a main resource and sub resource
(again pair checking via referrers). If so, the site could offer a
mobile version to the user.
3. Does the user agent seem to be slow? -- This can be detected by
client side scripts under performing sampling tasks. This could mean
that the system is swapping to death (old computer, mobile computer,
...). If so the site should offer a lite version to the user (this
could be an html version as opposed to a mobile version, or it could
be a mobile version).

Note that the user's preference for a given version of the site is
partially a per UA instance setting, and there's a simple way of
managing this, the site merely gives the UA a cookie indicating the
preference that the user has selected. Users will relatively quickly
settle into one version or another. But they will also be happy to be
in control of the decision.

All of this is possible today. And some bigger sites do some of this.
If you try loading gmail while your desktop is swapping to death or
while something is eating all of your bandwidth, gmail will give you a
note ~this site is taking too long to load, would you like to try the
html version~.

The world at large would be better served by people making reusable
demos of things like this (or getting them integrated into the common
frameworks) than it would be by user agents adding some more things
which enable developers to do bad jobs of discriminating against users
of user agents.

Received on Friday, 13 May 2011 07:07:55 UTC