WIMP UI paradigm won't scale down to touch UIs | Hacker News Reader

WIMP UI paradigm won't scale down to touch UIs

russellbeattie.com

33 pointsdirtyaura16 comments

It's a rather long article, but has good observations by someone who has tried different tablet OSes.

I personally believe that we are on the verge of a fundamental shift in computer UIs. And it starts by scaling up from a simpler solution (e.g. iOS UI, Android, Meego), not by scaling down from a more complex solution (traditional desktop UIs).

Now the interesting question is that when we need to support a lot of different kinds of actions/tasks in an application, how will this be supported in touch UIs. Russ mentioned Photoshop as a good example of such application.

In our upcoming iPhone game, we have played around with circular context menus and at least in that setting they seem to be quite promising. However, you can really only have a few choices (4-5) in circular context menu on iPhone. However, on iPad or tablet, you could have several "rings" of actions. Traditionally, in mouse-based systems, circular context menus haven't have several rings because of the Fitts' law, but on the touch based system, I don't see that as a problem.

Any thoughts of possible directions, where touch UIs will evolve?

I don't think circular context menus make a lot of sense for touch based UIs because some part of the menu will always be obscured by your hand. I guess this could be mitigated by having it expand in only one direction based on if the user is right or left handed, but loses a lot of the efficiency of the circular menu.

I like how android does the context menu. Long hold and then a scrolling menu shows up. It obscures the entire screen though, so that's not a model for a larger screen netbook.

The reference to 'Fitt's Law' made me curious. From the http://en.wikipedia.org/wiki/Fitt%27s_law article:

"Fitts's law is a model of human movement in human-computer interaction and ergonomics which predicts that the time required to rapidly move to a target area is a function of the distance to and the size of the target."

The extra effort you had to make to click the 'Start' button on the taskbar in early versions of Windows 95 (because the button didn't stretch all the way into the corner) is a nice illustration about the importance of this law. This has been fixed:

"Edges and corners of the computer display (e.g., Start button in Microsoft Windows and the menus and Dock of Mac OS X) are particularly easy to acquire because the pointer remains at the screen edge regardless of how much further the mouse is moved, thus can be considered as having infinite width."

The problem with circular menus comes down to limited choices (as you pointed out), and the simple fact that it's difficult to read a circular menu. They will work best when the choices are adequately represented by an icon or single word, the choices are hierarchically flat (no drilling through submenus), and when the menu is accessed so frequently that the user can quickly map those choices to muscle memory.* Outside of these conditions, they don't work so well, because their advantages in terms of Fitts' law are greatly outweighed by their lack of readability. Unfortunately a "rings" system would only exacerbate that.

* A circular menu is also especially good if there's some natural mapping between the choices and a circular layout, like choosing a compass direction.

Good points, especially the case for readability, i.e. the need for either a good iconic representation or a short word. In our game setting, there has been so far a good iconic match with a short word (e.g. buildings that you build to the specified position), but I can see that this will be a big problem in a more abstract cases.

I don't see scrollable list-like context menus (as suggested in an another comment) very good either, it seems to work against the benefits of touch UI. Maybe I need to play with Android first to be convinced.

Now that I think, Photoshop-style 'temporarily' modal actions picked from toolbar could be actually a good pick for a multi-touch UI. In mouse-based systems, frequently switching between tools can be really cumbersome (without keyboard shortcuts), but in multitouch systems it could actually work quite well.

When I think circular menu, I immediately think Star Trek's touch screens. Wonder who was responsible for simulating those interfaces.

http://www.lcarscom.net/

http://conceptmodeler.files.wordpress.com/2009/04/ingr_lcars...

Fitt's law! I was going to write about that in my post, but I forgot! Because of the bezel on the IdeaPad I was using, Fitt's Law was turned on it's head: The closer a UI element was to the sides of the screen - scrollbars, close buttons, start button - the harder they were to use! My fingers just couldn't jam into the tiny space needed to get to the UI widget. At one point, I tried hiding the task-bar, and then couldn't activate it again because it only stuck up on the bottom like 3 or 4 pixels high. :-)

Of course, this will go away once all touch-screens are flush with their frame, but it's an amusing side-effect to note.

:-)

-Russ

I dont know whether he installed the Microsoft Multi touch pack.

http://windowsteamblog.com/windows/b/windows7/archive/2009/0...

http://www.microsoft.com/downloads/details.aspx?FamilyID=b15...

I did - but the IdeaPad only has an Atom processor, so the apps ran really sluggishly - also, it doesn't add any multitouch additions to the main Windows UI that I noticed. That said, I didn't realize MS had released the Surface stuff, so it was still fun to play with.

-Russ

One of the beefs I have with current touch solutions is that they require me to move my hand a lot. I set my mice to high sensitivity and then just do things with tiny movements. Most current touch UIs have a 1:1 mapping between screen movement and finger movement, I keep wishing someone implements a microflick based UI where users have to make tiny movements.

I'm the same way. Honestly I don't think the current WIMP paradigm works that well for desktops either.

I agree. Maybe desktop-style UI's are dead for - well - desktops, too?

What are the pain points in desktop UI's for touch devices? 1. Drag and Drop - many inexperienced users find drag and drop difficult so killing it wouldn't harm anyone. It always was a bitch with overlapping windows anyway.

2. Managing overlapping windows in general just sucks. I've often argued that tiling windows are a much better idea and these could be made to work on touch devices with larger screens too.

3. Scrollbars are useless on touch-devices and not much fun on the desktop. Luckily touchpad scrolling and mouse-wheels mean I don't have to use them much so maybe they can die too.

4. 'Hover' type interactions are usually inessential. and when they aren't it's usually a sign that something is horribly wrong with the UX

Maybe even with touchpad/mouse/keyboard, the changes made necessary by touch devices might force desktop UI's to shed some of their weaker aspects.

Another thing to think about is the '10 foot interface'. This suffers similar limitations to touchscreens and with Google TV and similar products spreading their influence, the remote control could become the most commonly used input device of all.

Points 1 and 2 are solved (at least on OS X) to a degree where I would be annoyed if those things were taken away.

How so? Last time I checked 'drag and drop' was still the primary method of file management in Finder and Apple hasn't added a tiling window manager.

Yes, drag and drop is widely used in OS X and it works very well. Your windows aren't tiled all the time, but Expose puts them into a tiled structure, and it works with drag-and-drop. So I can have all the windows open I want, in whatever configuration I want, start dragging something, enter Expose, and drop it wherever I want.

Microflick works okay for folks with good fine motor control. Older folks: not so much. And lest we forget, the personal computing revolution is 40 years old -- over the next couple of decades we'll be seeing power users reach 70-80 years old in large numbers.

Reply on news.ycombinator.com