In the first part of this series, we discussed context and the “leaning forward/sitting back” modes of user interaction with mobile devices. In this article, we’ll focus on specific user-interface issues that can mean success or failure (that is, use or disuse) for a Moblin app. Let’s start with real estate and the landscape.

Be Aware of the Landscape

Some devices have portrait-oriented displays, and some have landscape-oriented displays that are often used as if they were in portrait mode. Consider the iPhone: it’s a portrait device. While apps, such as movie players or games, might use the iPhone screen in a 320x480 landscape mode, the default for the machine – and for most apps – is to work with the device held upright.

Now, consider your typical notebook PC. Nearly all PC screens (other than tablets) are horizontal – and in fact, recent models have the same aspect ratio as a wide-screen TV or a movie screen. However, the default orientation for most apps is a portrait mode. Users have many windows open side-by-side.  Word-processing docs and browser screens, for example, are portrait. Few apps work “maximized” to fill out the screen, other than spreadsheets, some games and graphics programs and movie players. What’s more, the expectation for many apps is that the application window is “longer” than the screen is tall, and you’ll scroll vertically to see everything. Think, again, of a word processing document or a Web page.

A Moblin netbook or MID uses a different metaphor. For the most part, they have landscape displays that are meant to be used with a single full-screen landscape app. (That can be challenging to design, since unlike with the iPhone, you can’t assume a specific pixel count.) No scroll bars, no vertical paging. While, of course, there can be reasonable exceptions, users expect to find all the action visible on the screen – and filling the screen in one window.

Be Wary of Tabs and Drop-Down Menus

The Moblin experience should be more like a media player than like a desktop application. Drop-down menus, like you’d find on a standard Windows or Mac app, don’t seem right in Moblin app’s UI. The same is true of horizontal tabs, which can be used to change context panes – and especially stacked horizontal tabs. They hide action, and hide context. Given the “snacking” use of Moblin applications, you don’t want to bury the context under menus, or under various settings or app tabs. Don’t make users look for things.

Better options are sidebars, which can take up a column of real estate – but which are easier to see and control. Icon-based toolbars can also be powerful especially if the available icons change automatically. (Users are frustrated by grey’d out options, or buttons which won’t press.) Think about, for example, the ribbon user interface introduced with Microsoft Office 2007 for Windows. While the Office ribbon isn’t designed for a Moblin-style experience, it demonstrates the power of contextual aware toolbars.

Having controls appear and disappear can also be powerful. Consider, for example, how many media players fade out the play-pause-forward-back controls … but fade them back in when the cursor is moved. That’s a great technique to preserve screen space, while also providing a full set of controls for the user.

“Hovering” works in productivity applications as well as in entertainment ones. Consider a mail application. Instead of showing “reply” or “delete” buttons, why not have them fade in when the cursor is moved over a message header?

Be Aware of Input Limitations

While we’re on the subject of moving cursors, never forget that on many Moblin-based MIDs and netbooks, the cursor controls are, well, suboptimal. The touchpads on many netbooks are small and can be hard to use. Personally, I prefer to use an external mouse on a netbook whenever possible – but you can’t count on that. With MIDs, your input options may be even more constrained.

Minimize the amount of cursor movement required to operate your app. That can also limit what you might want to do in terms of gestures, dragging-and-dropping and so-on. Try to keep the actions simple, so that users can be quickly successful no matter what type of device they’re using. Make controls big enough that users won’t be frustrated.

Be Wary of Animations

Distractions are a bad thing, and can degrade the user experience. Consider animations, like having files fly into folders during a content save, or when receiving a message. Animations can bring an app to life, it’s true. But keep them short! Nobody wants to see a 20-second animation, now matter how beautiful it is, more than once. That’s true for a five-second animation, or even a two-second one.

Think about an icon or box pulsing for a half a second, or maybe even 250 milliseconds, as an event confirmation. The human brain is a wonderfully sensitive machine, and it’ll pick up on a very short animation effect. Whenever possible, make the animation shorter than you think it needs to be – and your users will thank you for it.

Be Wary of Status Messages

Distractions are also bad when presenting status or alert messages to the user. The fewer messages, the better – especially if your application needs a series of messages. Don’t do it!

Consider the warning that you might create if your live application loses its network application. Don’t say “Cable Unpluggd,” and then “Lost IP Address,” and then “Lost Connection to the Internet” and then “Connection Recovered” and then “IP Address Acquired”… you get the idea. Tell the user only what he/she truly needs to know. Don’t forget that the user might not be looking at the screen at any particular moment.

So, don't have a message fade in and out that says "Connection Lost." Certainly, don't have a dialog box that says, "Connection Lost," and make the user click "OK." Batch those messages together and only report the state that matters to the user and do it in a non-blocking fashion. The user's focus is the most precious commodity that you have - don't spend it unnecessarily.

Design in the Open

Visit “Open Source Designers,”  an online community for people who design user experiences. There are some excellent resources, and more than 400 people there who you can interact with.

Finally, I’d like to thank Nick Richards, an Interaction Designer at Intel, for his assistance with this article series. Check out his presentations from the Intel Developer Forum, “Designing Moblin for Netbooks" and “Designing Moblin for MIDs".

 * All names and brands are the property of their respective owners.

A former mainframe developer and systems analyst, Zeichick became a technology analyst and journalist in 1984. He has authored more than 3,000 articles, worked with consulting groups, including PricewaterhouseCoopers, IDC and Anderson Consulting, and has spoken at numerous events such as COMDEX, Networld+Interop, Microsoft TechEd, JavaOne and the Software Development Conference.

Read his personal blog at ztrek.blogspot.com, and follow him at twitter.com/zeichick.