Re: Proposal to specify behavior for terminals without touch hardware

Lets not turn this into a discussion about religion. Some prefer
UA-detection, others feature detection. Specifications are meant to
specify how browsers behave, also in edge-cases. So developers don't
have to fight with browser differences.

I'm not saying the user should not be able to choose, but rather that
this is how browsers behave today. Developers find it useful, and I
think that makes it valuable in the specification. If I have a site
that loads scripts on demand, why should a desktop user without touch
hardware load touch-specific scripts?

Gregers

On Fri, May 13, 2011 at 9:07 AM, timeless <timeless@gmail.com> wrote:
> 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 12:27:05 UTC