View Single Post
Posts: 631 | Thanked: 1,123 times | Joined on Sep 2005 @ Helsinki
#190
Originally Posted by Texrat View Post
I was completely with you until that last statement ragnar. The question is, why not? Why can't there be contextual info that determines whether the UI is presently modal or non-modal? Why can't I have a pure touch experience (ie, no focus elements) for the most part but then a change to a modal/focus approach when a specific app or usage demands it?

As a huge proponent of contextual UIs I'm discouraged by the Maemo OS retreat from certain aspects (such as abandonment of the finger-vs-stylus detection). In fact I'm convinced that, more than any other input experience, touchscreens MUST make high use of contextual elements. So... why not?
I guess we mean different things by "contextual" (and it looks like certainly we mean different by modal vs. non-modal! ). I'm cautiously optimistic towards using contextual awareness and information in the UI. By I think contextual in terms of the functionalities that the device offers to the user, not so much in terms of the UI style in which these functionalities are offered.

For what it it worth, I was basically the inventor behind the finger vs. stylus feature (there's a patent for that on my name, so I guess it's public information), so I do share some pain behind in dropping it. But not very much, ultimately.

I gave some examples in my previous entry why it is hard to combine a focus-less and a focus style.

Perhaps you could do it by doing two UI's for an application, one where the flow is optimized for touch, and another based on the idea of focus + commands within the same view, and then switch between these two sensibly (somehow, it's certainly not trivial). And hope that the users wouldn't get confused over some functionality in the application being presented in two really different styles all the time.

Even if that would make sense, it is doing the UI layer twice for all applications, and that's massive work. It's not optimal to use the same flows for both of them, doing that would make the end result poorer than not doing anything at all.

Some specific applications might benefit more from this switch that others. Say something like the browser, many current browsers can switch to this HW key focus moving mode even though they don't show focus by default. But ultimately these are usually exceptions. Considering for instance the iPhone, one can argue that most of the applications in there would really not benefit from adding the HW rocker key to the device. And requiring HW keys on the device basically means that the keys should make sense, "should do something" in all the applications.

(This, as I've talked before, is not to say that HW keys cannot be in the device, but the rule is "support if they are presented, but do not assume that they are there".)

In theory nothing is impossible, but basically the effort taken would be huge, and maintainability and scalability would be hard. ... It's a race. Going through all the cliches like "time is money", "nothing is free" etc., it's better to do one great UI than try to do two good UI's.