hover.
Hover.
The future of computing is of course, immersive, and sensory based (touch, sight, etc). This much is obvious.
The iphone, google phone, palm pre, etc pose an interesting question to interface developers (web, native). I speak of hover events. This isn’t a new problem (googling for ‘iphone hover’ shows a lot of complaints) There are many many sites that operate menus on the basis of hover (and have been around since web 1.0 days, back when javascript was considered just good for kiddie scripting) But a touch based interface makes it exceptionally hard to plan/design for a hover based site, and we leave behind a metaphor that can be both very useful and intuitive.
(Yes, I know of touchstart and touchend; notice I didn’t say ‘impossible’. Bottomline, I want my mouseover event.)
And it’s not just hovering over items, it’s general mouse behaviour that contains a lot of information about a user’s behavior that could be mined, so to speak.
To demonstrate, I quickly threw together a page that uses this. Everything would still theoretically be googlable, it’s super easy with hover, but I’m guessing it would be a complete headache to do this on a touch based interface. Where oddly enough, I think it’d be of immense use (not a lot of screen space required, scales decently well till about a 100, can be non-obtrusive js with a fallback on no js: you’d simple render it as a vertical list)
Question is, how would you do something like this on a touchscreen? Do we strive to write insane code and duplicate this functionality (and possibly not get there) or do we design around it and implement functionality that works the same on both interfaces? The first lets us maintain the design at a cost that’s not really justifiable, the second makes us lose some strength of design by saying “NO YOU CANNOT”.
Thoughts? Mail me at sunil.pai@idiom.co.in
2 years ago | Tags: ux
