daperl | # 181 | 2009-01-11, 16:42 | Report

Oh yeah, and even Apple added hardware volume controls in their iPod Touch refresh for the added speaker (internal, huh?). Please don't tell me the n900 won't have stereo speakers.

eiffel | # 182 | 2009-01-11, 16:44 | Report

Yep I love the pinprick-metal style.

In 1969 I bought my first transistor radio - a tiny Sony radio with a front panel just like that of the N800.

That style died out when it was replaced by cheaper plastic, which is why it looks classy on the N800.

Roger.

Texrat | # 183 | 2009-01-11, 18:04 | Report

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?

---

Last edited by Texrat; 2009-01-11 at 18:12.

SD69 | # 184 | 2009-01-11, 18:10 | Report

Thank you for your good and persuasive comments. But they imply that the case for a D-pad is entirely its use as a focus element in UI or navigation. The D-pad can be used for a variety of functions, some as simple as vertical scrolling and some of which have yet to be conceived, but not available if it is absent from the device. It also seems inconsistent with the open nature of the device and the years of engaging an open source community to remove the existing HW keys that have been present for years over the objection of the open source community.

Texrat | # 185 | 2009-01-11, 18:24 | Report

SD69, I wish I could make my thanks to your post above bigger and more powerful.

Bundyo | # 186 | 2009-01-11, 18:43 | Report

Nah, you're pnot taking into account a number of usages you're so accustomed with that you'll know they're missing when they're actually gone. I meant d-pad for navigating INSIDE the input field. I don't want to delete 5 letters to type 6, right? How will the iPhone zoom loupe help me with that?

And you probably mean that we should only play strategies from now on on the next devices. Quake is not suitable for touch screen, refer to Tomb Raider for WM5 devices and they actually using some keys too .

Does someone remember the user interface form Steven Spielberg's Special Report? I can tell you why it won't be used much in this form - it will give you an instant arthritis if you try to actually use it for something else than moving pictures around...

allnameswereout | # 187 | 2009-01-11, 18:43 | Report

Well, this is discussed before, but there are basically 2 options to fullfill both modes:

1) Hardware/software button to switch modus.
2) Detection.

Because all kind of things from menus to user input depend on size, and size is everything on a small screen. Either way, I'td require hacks in e.g. GTK too.

Option 2 is probably very difficult. Either way, it is probably expensive to implement this because both modus operandi have to be tested well.

The advantages boil down to if you make things stylus friendly you can give the user more space. Touch (finger) friendly leaves less space. Touch/finger is easier for sudden, short usage because you don't have to take out the stylus. A stylus allows more precision.

The competitors market seems to bet & serve the touch/finger market, and Nokia is following this trend.

Because of the disadvantages of finger touch only you have to fall back to clever tricks in the touch UI. And, these exist. I've read several sound ones on http://tabletui.wordpress.com

Something like multitouch does not necessarily require 2 hands, btw. Just 2 fingers.

In some situations I've even used my nose. Picking out stylus was not an option. And I don't see one doing it with pleasure during sports either. So this, together with HS*PA, makes the device more a mobile outdoor device. And that is for sure closer to what I want than the current N8x0, but opinions differ.

allnameswereout | # 188 | 2009-01-11, 18:49 | Report

Games? What is wrong with asdw (except that it destroys these keys earlier)? Nothing (all FPS games, requiring speed, use these and there are keybinds near these keys as well), except when you dont have a hardware keyboard (N800, 770). The software keyboards in existence are all pretty shitty IMO but given the popularity of N800 I must be wrong on that one.

Pandora comes with 2 of these dpads (no clue why... must have some reason...), and Pandora is aimed for this purpose of gaming, so perhaps a device such as a Pandora is better suited for those who deeply care about games. Maybe I like the N810 hardware keyboard because previously I used mostly phones and Sharp Zaurus. Both an even worse keyboard...

Also, remember that scrolling currently sucks compared to other devices. If you take Fennec into account, you don't have to use the dpad there. You use your fingers to navigate through the application. The only reason you'd need your keyboard is to become Sir TypeALot. They do their best to limit your required keyboard usage to minimum.

[EDIT], I will give example: take the RSS Feed Applet. You either have it small and informative with lots of items (a lot information, stylus friendly, finger unfriendly), you have it with big buttons and you must scroll up and down using the buttons (far less informative, finger friendly, not optimized for stylus but works). Autoscroll is resource hog.

Now, imagine you can scroll down in this by using a gesture instead of the buttons. Imagine you point on an item and it will show you the summary (full screen, or overlapping area; given my attention span I say full screen ). Then you get 2 options: 'X' (close) or 'OK' (more information). While this does not make the application as informative as it standing, doing nothing, showing you the RSS items it does make it better while using it (IOW, outdoors). Indoors you can have your tablet standing doing nothing and being a monitor, sure. And, with some intelligent tagging, filtering, and feed browsing (this, given complexity, more for 'later' versions I suppose!) it could become a killer application.[/EDIT]

---

Last edited by allnameswereout; 2009-01-11 at 19:00. Reason: example finger usage

Naranek | # 189 | 2009-01-11, 19:12 | Report

I think that this would be a great way to create the UI because it would at the same time allow for
-great touch UI built by Nokia AND
-continued easy porting of open source software

I fear that if the focus elements are removed from UI, it will make porting applications that rely on them difficult. Of course I'm not a developer so this might not actually be a problem.

ragnar | # 190 | 2009-01-11, 19:12 | Report

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.