Maemo UI improvements blog.

January 24, 2008

More User Interface Generalisations – the Consistency Myth?

Filed under: Light UI modifications — Tags: , , , , , , — kareljansens @ 22:22

As Antoine R J Wright already noted , there is more to a good pocket computer’s user interface than just getting the right screen layout for your user’s home screen. “Consistency” is the magic word, but what does that exactly mean and how important is it really?

Let’s go back to the Psion. The Series 3 has a keyboard-oriented interface, based on drop-down menus, lots of keyboard shortcuts and a zoomable screen. Psion put down guidelines and many developers did indeed follow them. Nevertheless, there are Psion programs that do not follow those guidelines and became rather successful nevertheless (most of JBSoft‘s programs e.g. took those guidelines rather loosely). I think that the explanation for this is that the Psion’s interface, while very clever, wasn’t very intrusive or necessary for efficient use of the computer. Despite their inventiveness, Psion Series 3s were basically shrunk down pcs with keyboards. The user didn’t need to get accustomed to a radically new way to use the Psion, just to a more clever way to use the keyboard.

The Newton was different. For one thing, it’s a true tablet pc so any way to use a keyboard on it would be tricky and uncomfortable. Most Newton users would not be accustomed to using a tablet, so Apple rightly decided that the user interface was very important to the whole “Newton feel”. Then again, that consistency (as far as the user experiences go — I’m not going to delve into the developer’s point of view) is mostly limited to the HWR, the gestures interface (scrubbing to delete stuff, dragging to/from the margins to copy/paste), the placement of menu options (the “send” icon top right, in-program menu options on the baseline) and the look and feel of sub-windows.

The content of Newton programs could vary wildly and mostly escaped interface control. Example: Newtons came with “Newton Works”, a combination of word processor, spreadsheet and various installable modules, that out-of-the-box would not recognize handwriting; you needed a community-developed addon for that! (the reason for this was that Works was developed for the eMate, a keyboard variant of the Newton MessagePad). I still have on my MessagePad an interesting CAD-like program for surveying and drawing house plans, PocketHousMap, that defied several (but not all!) of the Newton’s guidelines. Cigraph stopped supporting it when de Newton was discontinued, but the manual can be found here.

What’s my personal take on this? There is one significant difference between the two environments I mentioned above and Maemo/Hildon: Both SIBO (Psion’s Series 3 OS) and NewtonOS are — very — closed source, and the Itablet’s OS isn’t. The question is whether it is doable (and ethical) to impose strict guidelines to developers on an Open Source environment. Personally, I think it shouldn’t be done, not as mandatory guidelines anyway. On the other hand, the design of Hildon isn’t such that it encourages developers to freely adapt to it; there are too many inconsistencies, flaws and even contradictions in it to make Hildon a “good” user interface. The only reason people “hildonise” their applications, is because there is no real alternative to the Hildon UI — yet.

This is where Penguinbait’s KDE port comes into play again. KDE is a very mature windowing environment, which has been fully GPLed recently. It is also very adaptable (see my earlier remark about putting menus on the bottom) and people seem to really like developing for it. If I were to improve the Itablet’s UI, I’d put my money on tweaking the KDE port, especially now that Cellwriter is claimed to be working in KDE, and give Hildon a run for its money.

We don’t need to turn the Itablet into a Newton copy (although it might be possible with OpenEinstein, one day), but we do need to find better ways to make it interact with us, especially if we want the Itablet to become more than a geek’s network sniffing tool. It’s a fine line between giving developers a set of guidelines they want to follow, and UI fascism, but I believe that less rules is always better. We just have to find the good less rules.

About these ads

8 Comments »

  1. Sometimes I think that it’s a blog of mindreaders =) Cause right now I’m thinking of guidelines concept for the maemo platform. It’s very complex and has lots of things to discuss together =) I think I’ll post some chapters before guidelines itself.

    Comment by Andrew Zhilin — January 25, 2008 @ 09:21

  2. I really would love reading other people’s ideas about UI design. Besides being a true UI anarchist, I’m also quite the amateur on the subject; my ideas come from using different portable platforms, not from some “School For UI Design”, so maybe this sort of clash of concepts is what we need.

    Sofar all the UI concepts for Linux pocketables (Nokia’s Hildon, Intel’s MID, OpenMoko, Qtopia and whatnot) have been about designing a rich UI environment, aimed at the lowest possible denominator of user (which I like to call the “Palm PHB” — Palm Pointy Haired Boss), and requiring substantial efforts from developers to create/port applications. The result has been fragmentation, user confusion, lots of half-finished projects and general mayhem.

    Maybe we need to apply the general Linux philosophy to Linux handhelds: Give as few design guidelines as possible, make it as generic as possible and allways give the choice to the user.

    But then again, what do I know, eh?

    Comment by kareljansens — January 25, 2008 @ 14:06

  3. I read this a few times before coming into respond; mainly because I am on my tablet and its fun tossing thoughts against a slow-moving browser ;)

    Consistancy: having expectations met in either interface or responses to input actions.

    It’s fine to keep the lid open in terms of what items do and look like; what is not fine is to deveate from that on the same screens or with well established paradigms. For example: the sidebar for the OS’s shell has three different looks for the web/contact/applications menu when you finger tap them in os2008. That is inconsistent. For example: there is no option to toggle the scroll bar (finger vs stylus size) on any application but both are shown, sometimes in the same app.

    It doesn’t matter if the box has several types of toys to play with; people will alway have more fun when the selection of the toys (the os shell choices) keeps a focus towards a type of play (windowing, styli driven, finger driven). It doesn’t matter what the OS can do if the toys make it hard to find the point.

    Comment by arjwdotcom — January 26, 2008 @ 16:49

  4. Just a quick response (more when I have time): I cannot discuss remarks about ITOS2008, because I will not tolerate that POS on my tablet. In fact, I’ve skipped the last two OS upgrades: I’m still on ITOS2007 before the ill-fated, card-eating SDHC “upgrade”. Basically, it boils down to the sad fact that I don’t trust Nokia software “developers” with my data anymore…

    Comment by kareljansens — January 26, 2008 @ 17:02

  5. My quick 2 cents on consistency:

    Consistency should be applied to minimize the amount of unnecessary learning that the user would need to do. Interface standards are an obvious example of this. Once you learn how the steering wheel and the brake pedals work on a car, it is beneficial to take advantage of this learning in a new car, unless you have discovered a brilliantly better way of handling car controls. A car would work equally well by reversing the position of the pedals, but you clearly don’t want to do that. “Don’t make me think!”, as also discussed by the book of the same name, is a rather good principle. Being consistent shouldn’t really be seen as a fundamental limitation, there are many many ways to differentiate the design even while being consistent in some interface norms. Cars are once again ok examples of this.

    One can easily go too far in consistency. Similar things should behave similarly, but then again, different functionalities should have some differences. Platform-level UI consistency can have the problem that then every application and every view looks the same and resembles each other. You could probably even draw some vague correlation curve whereas the more different a functionality is from some other functionality, the more different it should look and feel. This is perhaps slightly better understood for instance within web designers: having different parts of a web service look different helps the user to understand where he actually is in within the service. I for instance don’t really see a big problem in the different plugins on the task bar looking visually different: a shortcut plugin for the browser can look slightly different from the “all application” menu. Of course once you start to pile these individual small differences up everywhere, the overall end result will suffer in consistency. It’s a balance between differentiation and consistency. But I don’t think that consistency is the #1 rule to follow.

    I think this then very well relates to “mandating interface standards”. Interface standards should mostly be these building blocks and general style rules of an interface. I don’t fully agree on “less rules is better”. If 95% of the applications on a device behave in a certain way, and the user knows how they work, it is highly advantageous to specify these rules and try to follow them in your own applications also. I’m not saying that the Maemo UI would have reached this yet, but as a general principle. For instance the Apple HIG – and to some limited extent the iPhone HIG – are quite good examples of guiding developers to use a certain style without preventing also innovation in the field.

    Comment by Roope Rainisto — January 27, 2008 @ 11:22

  6. The car analogy is the perfect example for minimalist user interface guidelines. Basically, all that car user interfaces have in common is the steering wheel and the pedals; all the rest varies wildly from manufacturer to manufacturer, even from model to model sometimes. And yet users (car drivers) have little or no difficulties adapting to a new car, often to two or more cars simultaneously (his car, her car, company car).

    This is basically the point I’m trying to make re tablet user interface guidelines: Have as few as possible of them. Just make sure all developers will want to adopt the “Core Guidelines” — the steering wheel and pedals if you want — and let them go nuts on the rest.

    Do note the “want to” in the previous sentence: We’re working with Open Source developers here, meaning that it’s slightly more difficult than herding cats to get them to agree on something.

    The main reason I don’t like the Maemo UI, is because it’s wasteful. Of screen real estate, of ergonomy (remember my remarks about important menu options on the bottom) and generally of common sense. I’m basically against Maemo because of what Sean Luke writes in his article and allthough he makes it seem as if there’s still hope, the simple fact that Nokia has until now chosen to totally ignore his suggestions for improvement, makes me certain that they will keep on doing so.

    Comment by kareljansens — January 28, 2008 @ 21:26

  7. Karel, I don’t really agree with the minimal approach here. The average result of letting an open source developer “go nuts” on their application will not lead to a good UI. That’s post priori proven, simply looking at the current scene of open source applications. It’s not good, to put it bluntly. (Of course with plenty of exceptions!)

    I think many developers would certainly appreciate a good and versatile style definition, covering all main the aspects of their design work. Something that would allow them to concentrate more on the SW development issues at hand. With a style definition, you don’t _have to_ follow it if you feel that it’s not good or if you want to try something else. A style definition is good food for thought even if you don’t then follow the style. But I don’t really see good reasons not to give one in the first place.


    About the Sean Luke article: No, we’re not trying here with Maemo to copy the Newton device. It’s a fine device, no doubt about it. You might want to send your comments also to Apple, perhaps they would be interested to do that. ;) Newton is fundamentally a stylus driven UI design, and that’s not a big direction for the future to go towards. That seriously affects things like non-full view windows, HWR, button sizes etc. Stylus is not the way to go. Of course there are many individual features and elements that the Newton utilizes that are future improvement areas, as well as many things that can be improved in the Maemo UI. We are doing a whole lot of improvements and new features, it’s just that we cannot discuss them publicly beforehand. I know that’s probably not very comforting, but that’s just the way it is.

    Comment by Roope Rainisto — January 28, 2008 @ 22:43

  8. Thank you for the second part of your reply. It’s hardly the answer I was hoping for, but at least I now know where I stand with Nokia and the development for the Internet Tablets. Sadly this is exactly the opposite direction I had hoped Nokia would go, so it seems to be the end of the line for me.

    FYI, if I am going to buy a keyboarded handheld again, it’ll be the Pandora (http://craiginator.bluwiki.com/). Still, all is not lost yet: OpenEinstein is still developing.

    Comment by kareljansens — January 29, 2008 @ 13:28


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

The Shocking Blue Green Theme Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: