Re: Proposal to specify behavior for terminals without touch hardware

I don't know why this needs to be mentioned in the Touch Events spec.
Detecting "on<event>" in element/window is the preferred method of detection
for any event type.


On Fri, May 13, 2011 at 8:26 AM, Gregers Gram Rygg <gregersrygg@gmail.com>wrote:

> 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.
> >
>
>