Meego Wiki
Views

Netbook Design Guide

From MeeGo wiki
Revision as of 19:20, 11 October 2011 by Nedrichards (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

MeeGo netbook is similar to, but different from, other desktop Linux operating systems. It is designed specifically for 10" or smaller screens, with Atom chips and Intel 3D graphics. Because of this tight focus it is possible to create a more pleasing experience for its users. However, this also means that existing Linux applications need some modification if they want to be at their best in this environment. The following design principles were used by the MeeGo design team themselves and should help you out in creating awesome netbook experiences.

Contents

Constraints

MeeGo Netbook is designed for small portable devices with 7-10" screens, keyboards and small trackpads as the pointing devices. The smallest screen resolution expected is 1024x600. Pervasive connectivity, using ethernet, wifi and possibly 3G or WiMAX, a front facing camera, storage expansion (via either USB or SD type memory cards and an external monitor port are expected to be available.

Interaction architecture

Netbook users want to get multiple things done at the same time, but the small screen makes it difficult to do any of them justice if they're put together. Netbook applications should expect to fill the whole of the screen on their zone (in small screen mode). With the panels and zones interface allowing fluid and quick task changing and background operation.

These applications are self contained experiences and all popups should be constrained and contained within the applications window. Spawning new windows can, if not handled correctly lead to inadvertent opening of new zones or in getting a dialogue 'stuck' underneath another window causing frustration.

Panels

Since this means the application is quite likely not to be visible at any time you may wish to implement a Panel to allow the user quick access to your key features, directly from the toolbar. The media player uses a panel to show a different view of the user's state, more appropriate for quickly pausing or modifying their play queue so they can switch back to what they really wanted to do.

The important thing with a panel is, if it's going to take more than a couple of clicks, that you should open your host application. Panels are not a good place to do complex tasks and they should reset their state to the 'default' upon each invocation.

Panel quick points:

  • Quick tastes of interaction
  • Just one screen, ideally page not scroll
  • Get to what you want to use a lot, as quickly as you can
  • Not a place to stay.

Anatomy of an app

MeeGo Netbook applications are made up of three main elements with distinct purposes. Use them well and your application will flow and zing.

Toolbar

Every application has a toolbar. This is where users will look first for functionality. Thanks to the less than ideal trackpads on netbooks this is quite chunky in size, but it also encompasses the functionality of a menu bar in traditional applications. The toolbar will always contain a close button, however the user can also close your application by using the zones panel.

We find that direct use of buttons in the toolbar is very effective, however if you have a collection of less important and related choices then you may collect them together into a dropdown.

Toolbar quick points:

  • Use it to act on the context.
  • No menus
  • This is also your window decoration

Sidebar

An application may have a sidebar, but it is not required. Sidebars are used when you want to change the context of the main content view. This is not progressing through a single view, where you might want to use breadcrumbs (which would go in the toolbar) but can either be entirely new data or a new filter on existing data such as Album vs Artist view in a media player.

Sidebar quick points:

  • Use it to change the context.
  • Lists work well, but you can put other types of control here if you like.

Content pane

As far as your users are concerned, this is your application and is the area we want to control the least. Go wild.

Just remember that your users have a widescreen display and that you're taking all of it up. We have found that grid views work well to get the required information density.

Content pane quick points:

  • Where the action is.
  • We like grid views.

Notifications

Since Zones means that your application cannot be guaranteed to be in front of the user at all times and the toolbar is usually hidden until the user asks for it, active notifications are important to master. You may send a notification to the user at any time when your application is not focused. Only one notification will be shown at a time and it will be expired after 7 seconds. If two or more notifications are scheduled to be shown they will go into a stack and be shown in order. The user may dismiss all notifications at any time. Alongside the dismiss button you may display a single positive action of your own. For example, if a new instant message arrives the user can choose to dismiss the message or actively switch contexts to the conversation and answer it.

Applications should be careful not to spam the user with unnecessary or out of date notifications. For example, if a notification is sent that we have lost connection to the internet then it should be immediately removed from the stack if the connection is restored. Similarly, if a new email arrives a notification may be shown, but if another new email arrives then the notification should be cancelled and a new one sent with the current state "Two new emails".

Don't be modal

MeeGo is all about speed and responsiveness. Searches should ideally occur as the user types and blocking modal popups are discouraged for communicating with the user, in favour of contextual information bars.

Similarly, transitions and animations should be as short as is possible to convey the information required or cover up pauses or gaps in the interaction and ideally they should pre-emptable by user action.

Big screen mode

When on a big screen, not a netbook the system will change to work more effectively. Since the context of use has changed on a larger screen, many of the comments above no longer apply. Applications should not always open to be the size of the screen (unless their design requires it), they can open in their 'natural size'. Also, opening a new application will not automatically open a new zone (although users can still use the zones panel to manage them). Furthermore, the toolbar will be visible at all times.

Currently big screen mode is activated when the primary display is >11".

Projectors

The user may attach a projector or TV to the device at any time. When this happens the primary display will automatically be switched to the new screen and the resolution will be changed to match. Your application should automatically reflect this.

Where next?

If you want to actually do something about this check out this handy page on how to adapt your GTK+ application for netbook.

Personal tools