Review: Android
Linked by Thom Holwerda on Mon 19th Dec 2011 20:11 UTC
Google Once upon a time, in a land, far, far away, there were two mobile operating systems. One of them was designed for mobile from the ground up; the other was trying really hard to copy its older, desktop brother. One was limited in functionality, inflexible and lacked multitasking, but was very efficient, fast, and easy to use. The other had everything and the kitchen sink, was very flexible and could multitask, but had a steep learning curve, was inconsistent, and not particularly pretty.
E-mail Print r 6   · Read More · 100 Comment(s) http://osne.ws/jmo
Permalink for comment 501165
To read all comments associated with this story, please click here.
RE[5]: Comment by frderi
by Neolander on Sat 24th Dec 2011 13:47 UTC in reply to "RE[4]: Comment by frderi"
Neolander
Member since:
2010-03-08

"Well, it seems to me the aforementioned principles are very general and could apply to non-software UIs such as that of coffee machines or dish washers."

Do you really want dishwashers and coffee machines with resizable windows, double clickable icons and a pointer device?

You are missing the point. I'm talking about the aforementioned principles of architecture, visual organization, coherence, etc.

I hate coffee machines with exotic coin slots and inconsistent button behavior just as well as I hate this kind of stuff in desktop software.

"So, how did keypad-based cellphones running s40 and friends manage to use this very paradigm for years without confusing anyone ?"

Certainly not by using a WIMP paradigm.

Well, in fact, if I take a typical keypad-based OS like Nokia s40, you get...
-> Windows. Each software has its own content area, which is not shared with other software.
-> Icons. Well, they are all over the place really, but let's consider the main menu. Depending on screen estate and user preference, icons can either be directly labeled in a list form, or they can take a grid layout with icon label appearing when an icon is hovered.
-> Menus. Considering how little screen estate old phones had, it's no surprising that menus are used all over the place in order to get a reasonable feature set to "fit in".
-> Pointers. To select something in a menu, you typically point it using the arrows of a 4-directional pad, then click it using the center of said pad.

I have never needed to help anyone using a s40 phone, except for very specific tasks. On the other hand, I regularly help people dealing with the intricacies of iOS.

Oh, I'm not saying skeuomorphic designs are the answer to everything. I'm saying that for quite a few applications on a Post-PC device, they make a lot more sense than a traditional WIMP paradigm would.

And this I can agree with. In my opinion, skeumorphic designs fail at being a universal UI paradigms, but when you want to mimick existing hardware's functionality instead of exploiting the full power of a computer, they fit the job well and are fun.

How many times do you keep your hand on a knob?

For audio mixing, I can spend quite a lot of time carefully tweaking something while listening to an audio loop. By the way, I believe faders and sliders are better for that kind of task when space and cost are not an issue, but that's another story...

"What you are talking about is feature bloat, which is not an intrinsic problem of WIMP."

Well, it kinda is, by design. It wasn't anticipated when they first came up with it, so it has become a problem for the paradigm. Solvable by conventions, yes, but conventions are more a bandaid than a real fix are they.

No, it isn't. Modern cars are feature-bloated, home heater controller are feature-bloated, dedicated stopwatches used to be feature bloated before cellphones started to eat up that functionality, and I could go on and on.

As soon as you put a processor in a device family, no matter what its UI paradigm is, engineers become able to implement as many features as they want. It then takes mental discipline to prevent the feature set from expanding too much, and usability expertise to devise a good information hierarchy when the feature set really has to be big. That kind of competence is precious on any digital hardware, no matter what kind of UI it uses.

"The reason why desktop computers did not get those is that they were designed for work rather than for fun."

Then what were all those PC's doing in our homes in the nineties?

I'm not sure I understand what you mean, sorry.

Of course is not obvious. Do you think coming up with a working WIMP paradigm was all that obvious to begin with? Just look at the multitude of WIMP-based GUI solutions that were out there in the eighties. Nowadays pretty much everyone is emulating the Mac. Its still early days for post-pc.

Well, so far you have defined post-WIMP UIs as some sort of postmodern user interface that breaks free from all conventions and does whatever is suitable for the task at work. Does not sound like a good start to create a paradigm.

See zooming user interfaces for an example of what a touchscreen-specific user interface paradigm could be like : http://en.wikipedia.org/wiki/Zooming_user_interface

"This kind of paradigm works for simple tasks, but breaks down as soon as you want to do stuff that is a tiny bit complex."

Then aren't we the luckiest guys on earth that smartphones are a perfect fit for simple tasks?

Sure, but aren't we talking about tablets and other post-PC devices which aim at being more than a portable video game console with a touchscreen or a cellphone with toys installed on it ?

"How about printing that PDF, as an example ? Or jumping between chapters and reading a summary when you deal with technical documentation that's hundreds of pages long ? Or finding a specific paragraph in such a long PDF ? Or selectively copying and pasting pictures or text ?"

These are all possible on present day devices, so i fail to see your point here.

My point was that menu-based WIMP workflows are reintroduced for that kind of tasks, which shows that skeumorphic designs are not a universal UI paradigm, as you have acknowledged earlier in this post.

I have yet to run into this issue with my iOS device, maybe because in iOS its an API feature and its consistent over all applications.

So you are telling me that if you use a pinching gesture or a double tap in any (and I really mean any) iOS application, it will have a consistent behaviour ?

Doubt it.

Nothing is perfect. I disagree though that its a much better idea to use a classical WIMP design instead. Customers seem to agree, and since they are voting with their wallets and make developers like you come to work everyday, i think that's what matters in the end.

Sorry, I do not develop software for a living, it's more like a hobby ;) This way, I can avoid overhyped technology, underpaid hackjobs, and boring programming environments, and focus on what I like to do.

"Adding millions of nonstandard widgets to increase an application's vocabulary is possible in a WIMP design, good programmers only avoid it because they know how much of a usability disaster that turns out to be."

That might be the case on a desktop or laptop, but is not so much the case on a post-pc device for already mentioned reasons.

Such as ?

"Such as ?"

One could use color, sound, vibrations, ...

So you think that WIMP interfaces are unable to use feedback based on color and sounds ? I think you should spend more time using them.

Vibration feedback is hardware-specific, and the desktop market has decided overall that it does not need it, but if every laptop included a vibrating mechanism, I guess there would be a standard API + support in the widget toolkit for that, as is the case for gamepads where rumbling is a common feature.

Edited 2011-12-24 13:52 UTC

Reply Parent Score: 1