Active Topics
-
The N900 is now 15 years old! (7)
to Nokia N900 by Danct12 - 1 day, 13 hrs ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 2 days, 8 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 4 days, 17 hrs ago - more...
 |
|
2009-01-11
, 16:44
|
|
Posts: 600 |
Thanked: 742 times |
Joined on Sep 2008
@ England
|
#182
|
Originally Posted by qole
Yep I love the pinprick-metal style.
The N800 doesn't look cheap. It looks like a classy, high-end transistor radio, circa 1963.
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.
 |
|
2009-01-11
, 18:04
|
|
Posts: 11,700 |
Thanked: 10,045 times |
Joined on Jun 2006
@ North Texas, USA
|
#183
|
Originally Posted by ragnar
I was completely with you until that last statement ragnar.
But... I guess the problem might not be self-evident for somebody who has not done designs on this area, but what exactly would you control with the d-pad?
You're talking for instance about navigating in menus. That assumes that there is a focus element on screen. Look at the iPhone UI, for instance. There is no focus element there. For a proper touch UI, you shouldn't have a focus element.
A traditional UI style is to have focus elements and then means to move this focus element around; first click to move the focus to position on screen, second click to confirm. Another style is to have no focus on lists and menus: first click always selects whatever you click. But you can't really mix these styles together very well.
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?
__________________
Nokia Developer Champion
Different <> Wrong | Listen - Judgment = Progress | People + Trust = Success
My personal site: http://texrat.net
Nokia Developer Champion
Different <> Wrong | Listen - Judgment = Progress | People + Trust = Success
My personal site: http://texrat.net
Last edited by Texrat; 2009-01-11 at 18:12.
|
|
2009-01-11
, 18:10
|
|
Posts: 1,513 |
Thanked: 2,248 times |
Joined on Mar 2006
@ US
|
#184
|
Originally Posted by ragnar
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.
But... I guess the problem might not be self-evident for somebody who has not done designs on this area, but what exactly would you control with the d-pad?
You're talking for instance about navigating in menus. That assumes that there is a focus element on screen. Look at the iPhone UI, for instance. There is no focus element there. For a proper touch UI, you shouldn't have a focus element.
A traditional UI style is to have focus elements and then means to move this focus element around; first click to move the focus to position on screen, second click to confirm. Another style is to have no focus on lists and menus: first click always selects whatever you click. But you can't really mix these styles together very well. The current S60 touch UI does this, and I'm not sure that people are very pleased with the results. (Blackberry Storm tries to do this half-child of pressing lightly focusing and pressing heavily activating, but that's slightly hackish.)
There are major implications to whether you have an UI that supports a focus element or then not. Take an example... for instance, of a file manager style application: content list on screen, toolbar on screen. If you have a focus, you can click on an element and then choose a command from the toolbar. If you have no focus, then you cannot do UI's like that, but must set the commands differently. Or take another example from the S60 UI designs. They have the Options menu for commands for the focused item. It's essentially the same as the toolbar: the first click cannot activate an item, because the user must be able to click once to select item, then press Options to get commands for the focused item. It makes good sense for HW keys, but not really for touch screens.
The more you try to stick on to hard key based navigation, the less you can optimize for touch UI's. It's really that simple, fortunately or unfortunately.
|
|
2009-01-11
, 18:24
|
|
Posts: 11,700 |
Thanked: 10,045 times |
Joined on Jun 2006
@ North Texas, USA
|
#185
|
SD69, I wish I could make my thanks to your post above bigger and more powerful. 
__________________
Nokia Developer Champion
Different <> Wrong | Listen - Judgment = Progress | People + Trust = Success
My personal site: http://texrat.net
Nokia Developer Champion
Different <> Wrong | Listen - Judgment = Progress | People + Trust = Success
My personal site: http://texrat.net
 |
|
2009-01-11
, 18:43
|
|
Posts: 4,708 |
Thanked: 4,649 times |
Joined on Oct 2007
@ Bulgaria
|
#186
|
Originally Posted by ragnar
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?
For 1) no, other means can be done. iPhone does it one way (with their zoom loupe), but other means can be used, either on-sceren or off-screen, depending on if there are hardware keys or not.
2) Well, touch screens work well with games suitable for touch screens. Just like you wouldn't enjoy Civilization with only HW keys (well, some do!), you wouldn't probably enjoy Quake with only the touch screen.
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...
__________________
Technically, there are three determinate states the cat could be in: Alive, Dead, and Bloody Furious.
Technically, there are three determinate states the cat could be in: Alive, Dead, and Bloody Furious.
 |
|
2009-01-11
, 18:43
|
|
Posts: 3,397 |
Thanked: 1,212 times |
Joined on Jul 2008
@ Netherlands
|
#187
|
Originally Posted by Texrat
Well, this is discussed before, but there are basically 2 options to fullfill both modes:
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?
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.
__________________
Goosfraba! All text written by allnameswereout is public domain unless stated otherwise. Thank you for sharing your output!
Goosfraba! All text written by allnameswereout is public domain unless stated otherwise. Thank you for sharing your output!
|
|
2009-01-11
, 18:49
|
|
Posts: 3,397 |
Thanked: 1,212 times |
Joined on Jul 2008
@ Netherlands
|
#188
|
Originally Posted by SD69
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.
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.
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]
__________________
Goosfraba! All text written by allnameswereout is public domain unless stated otherwise. Thank you for sharing your output!
Goosfraba! All text written by allnameswereout is public domain unless stated otherwise. Thank you for sharing your output!
Last edited by allnameswereout; 2009-01-11 at 19:00. Reason: example finger usage
 |
|
2009-01-11
, 19:12
|
|
Posts: 236 |
Thanked: 149 times |
Joined on Jul 2007
@ Finland
|
#189
|
Originally Posted by Texrat
I think that this would be a great way to create the UI because it would at the same time allow for
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?
-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.
|
|
2009-01-11
, 19:12
|
|
Posts: 631 |
Thanked: 1,123 times |
Joined on Sep 2005
@ Helsinki
|
#190
|
Originally Posted by Texrat
I guess we mean different things by "contextual" (and it looks like certainly we mean different by modal vs. non-modal!
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'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.
 |
| Tags |
| blurry photos, fud, funny farm, haiku, hibernation, not the droids, picnic baskets, straightjacket, trollosaurus rex, what competition? |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 13:55.
N9: Go white or go home