The MeeGo theme system is versatile, allowing for both global changes and special exceptions to the general theme logic. It’s possible to invest only a small amount of effort to set baseline colors, fonts, shapes, and backgrounds.
On the other hand, even without extensive coding it’s possible to tweak the theme all the way to the finest details and make it completely different.
More info coming soon!
Part of helping people understand your application and what it does lies in making scrolling predictable. Only scroll repeating content or UI elements like lists, don’t hide distinct functions below the fold line because people may not realize that they need to scroll to find that feature.
Where possible, use MeeGo common components in your application. This helps the user apply what they learn from other MeeGo applications to yours, and gives them a smooth, consistent experience as they navigate around their device. It is mandatory to have ‘Home’, and ‘Back’ in all views, the only exception is in full screen mode, available in application-like media players.
When designing your application, consider what might prompt people to leave your application and go into another, or vice versa. Optimize your design for the reality of multitasking.
Each view in your application should be uniquely recognizable and understandable, even when it is scaled smaller in the switcher, to help people find it and reopen it when they are multitasking. An application should celebrate its unique content and functionality in a way that emphasizes the iconic quality of the application, without compromising usability gained through the use of consistent components.
Before moving on with your application design, it is important to identify the nature of the task your application is dealing with. This should be the main drive behind the proposed user experience. Think about the focus of the application and the motivations for someone to use it. Understanding the nature of your application also helps you organize and choose how to display information and interactions.
Even though it is impossible to classify each, as it would be impossible to identify every possible application that could be created, the two types at each end of the spectrum are productivity and immersion.
If an application deals with more pragmatic actions, such as sending a text message, it is described as a productivity application. These are usually tasks where efficiency is key, not only in terms of performing the task, but also precision on getting to it. A well organized drill downs structure and simple toolbars with key actions, are good examples of how to present a responsive and quick task.
Therefore, these applications usually rely more on common components to build their UI, as simplicity is preferred. This is not to say that such couldn’t achieve an engaging experience.
There are applications offering more entertainment-based or visually rich experiences, like playing a video or browsing a map. Full views are quite often used in such cases. Although connecting to core behaviors of MeeGo’s UI helps users feel in control when stepping into a new environment, custom-made layout or component might provide a more appropriate experience to what is being offered.
Games are the perfect example of immersive applications. Users expect to be entering a ‘new world’ as a new game is launched. Whether they have a simple structure or complex, it is up to the designer to decide how to represent content, navigation, or interaction.
An application may appear in many formatting options (such as full screen mode, grids, etc), but most views follow a basic structure.
The main use of the status bar is to show signal strength, time, and battery life (operator optional). In addition, it supports notifications. This bar may be removed in specific cases.
The title bar contains the homescreen button, title, or tabs, View Menu (opened from the title), and the close or back button. Each view has a title specific to the view. In other words, most of the time the title gets updated as the user navigates through an application. This bar may be removed in specific cases.
This is where most of the action happens and the layout gets dynamic. Content area can present navigation options, text, media, etc. Actions are not limited to View Menu and toolbar, they may be presented together with the content, as well. Other types of actions, such as media control buttons, can be presented together with the content. Refer to the Common Components for all button variants.
This is an optional fixed bar available to an application at all times, whenever core commands are needed. It is also possible to use it for navigation options. The bar is limited to 4 actions. In landscape, this bar moves to the top, together with the title bar. Even though either icons or labels can be used (but not both at the same time). Icons recommended due to localization issues.
As seen on the Application Types section, not only how you organize, but also how you present your layout will have a major impact on the user experience. While a list presenting content may be suitable for a pragmatic task, other formats might be more engaging for other applications.
Whereas navigation models help organize how to structure an application, they do not imply any format or layout of how to present it. Drill downs are the perfect example. They serve as a model for several applications, such as a phonebook and Image Viewer. These present different types of content and, therefore, an array of distinct experiences.
Here we present two options of how to format a gallery, both using drill down as navigation structure. The application does not present a long list of navigation options, and has images as its core experience. Presenting items in the top level of the navigation helps make it more engaging, as well as providing quick access to the latest content from the first screen.
Consider the type of content and how complex the structure is, and explore the maximum amount of screen real estate.
Device orientation will suit multiple applications in different ways. While watching a video is best in landscape, with the media taking up all the screen, scrolling long lists is more comfortable in portrait.
MeeGo common components are always provided for both orientations. In other words, by using them, there is no need for extra work. It is advisable, however, that anyone building an application acknowledges such a change, as it might impact the desired experience.
Applications can overwrite default changes. However, it is recommended that all application provide both portrait and landscape mode. The main reason is the form factor of some available MeeGo devices. In devices with a slide hardware Qwerty, the landscape experience becomes key, and somehow extended. Therefore, the user shouldn’t be forced to change orientation to complete a task. Playing a game is one of the few exceptions to this rule, as its experience flow does not require (in most cases) the use of any other application.
Assets can be subtly resized and/or reshuffled to make better use of the screen real estate after changing the orientation.
Lists are probably the most common UI layout, and have a particular behavior depending on the orientation.
Whereas portrait allows for more items to be presented, landscape presents the possibility to extend the content area of a particular item. This is especially useful for text strings, which, in landscape, get more character area. The title of a message, for example, has less chance of being truncated.
Some applications may consider splitting lists into two columns, when in landscape, to optimize space usage. This may be used when there is no hierarchical order, usually in first level drill down pages. However, this should never be done when the list follows a specific order criteria (such as chronological, alphabetical, etc).
Buttons should always be centralized (especially important due to two column split) and, full width in both orientations.
Always consider designing the application settings. The user accesses settings from the View Menu in your application. The Settings view presents Home, Title, and Back (View Menu is not necessary).
In some cases, it might be desirable to provide quick access to specific settings of an application’s sub-views. These will be a corresponding sub-view of the application’s global settings. For example, in a subview of a Messaging Application showing a specific account, settings could take the user to the sub-settings of that account. However, there is a navigational difference in such cases. If the sub-view of settings is accessible from the correspondent sub-page, “Back” would take the user back to the page where it was opened from, and not back to the settings top level.
In the Settings view, group similar settings (by using visual dividers) together to help the user find related options. Each group can contain multiple items, such as texts, images, and buttons.
If the user can change settings directly on the UI, do not include those settings in the Settings view. For example, if the user can set a clock alarm directly in the Clock Application main view, do not include the alarm setting in the Clock settings view.
Note that when the user changes the settings, the change takes place immediately, with no need to save changes. You can use the Undo button in the view menu to discard any changes, and reset all changed settings back to the previous states. The Undo button is shown only after the user has made changes.
Applications may vary in navigational patterns. Three main templates have
been created to help support the application’s main functional goals.
This is the most scalable template, used when access to all application navigation structure is needed on the top level. Layouts are not restricted to lists. The Close button gets replaced by a Back button, as the user drills down the structure.
This template is for flat experiences, prioritizing content over navigation structure. View Menu is used for hopping between navigational options. This allows for many navigational options, as opposed to the Tab Bar template (below). As all these navigation points work as the top level of the application, the close button remains even after a navigational change. Note that filters behave differently, even though they too are placed in the View Menu. Filtering works like a drill down, hence the Close button gets replaced by a Back button, for example, switching between Messaging accounts.
This template is for quick access between distinct areas or modes. Be careful about mixing actions (like “Create New Message”) with navigational links in the Tab Bar. Use buttons within the content area for actions, if necessary, in this layout. This model is limited to maximum 4 navigation options. Navigational options in an application should not change over time.
Lock Screen
Presented when user first wakes up the device.
Home
Access to open applications through the switcher. Favorite applications are presented, as well as access to launcher.
Launcher
Access to all applications available in the device
| Symbol | Name | Action | Result |
 |
Tap | (Press, Release) | Open items/Select buttons/links Insert cursor (in text field) Reveal hidden controls Stop kinetic scrolling |
 |
Long press | (Press, Wait) | Reveal Object Menu Repeat (qwerty) key press |
 |
Drag | (Press, Drag, Stop, Release) | Pan/Scroll content Paint to select text in text field (interaction needs to be first started horizontally, otherwise panning is triggered) |
 |
Flick | (Press, Drag, Release) | Kinetic Pan/Scroll content (in some cases, bringing in new content, such as Gallery, switching to next picture) |
 |
Double Tap | (2*Press&Release within time limit) | Switch between zoom levels (touch screen) Silence alert (accelerometer) |
 |
Pinch | (Press, Release) | Zoom in/out (points touched on screen follow fingers) |
 |
Two-finger long Press | (Press, Wait, Release) | Select text (non-editable text fields) |
The lock screen is presented when the user presses the power key to wake the device from idle state.
The screen presents the wallpaper (which the user can personalize), date and time, and the lock action button. The device is unlocked by dragging the lock button into the wallpaper area.
Notifications are also supported in the lock screen. They stack up in a similar way to the Notification Drawer.
The launcher is a view that contains links to all applications installed in the device. In the launcher, the user can browse through the applications and add up to 4 links to the quick launch bar at the bottom of the screen. In editing mode, the user can also change the order of application links.
Applications are presented in a 4 x 4 grid. In the case where there are more than 16 applications, more pages of the same grid are added to the right. Paging through the different grids is done by swiping the current grid off screen, hence bringing the new one into view. When the user installs a new application, it goes to the end of the application grid.
The user opens the launcher by selecting an icon at the bottom of the Homescreen (placed together with Favorite Application links). To close, the same icon is used.
All applications require a name and icon for the launcher.
Users will often want to (or have to) use more than one application at a time, such as listening to music while writing a message. This is known as multitasking, and the switcher is an area where multiple tasks are managed. The basic behavior of the switcher is as follows:
When an application is first launched, a new task starts. This task is represented in the switcher by a live thumbnail of the current content within the application, that is a blog web page would always display the latest blog entry. The switcher is always accessible via the home button in the top left corner.
Whenever a second application is opened, the new task is included within the switcher. With that, MeeGo allows users to quickly switch between applications by pressing the home button. Applications can be opened from the launcher and from other applications, such as opening a map from an email.
When the user clicks on an application in the launcher, that is already open in the switcher, the system opens the window that was already open. It does not restart the application.
Tasks are shown in the order they were opened, from left to right. Every time a new task is opened, it pushes the previous task panels to the left and adds its thumbnail view to the far right.
The default view of the switcher presents the latest accessed task in focus, with the other, different tasks running to the right. Thumbnails are presented in chronological order, as they are opened.
It is possible to browse through the thumbnails, one by one, by slowly dragging them, or to use a quick swipe to rapidly pan from one side of the list to the other. During this quick swipe, a tap stops the transition at tapped point, but does not open the application. To open the application, the user needs to tap the desired thumbnail.
Users can use a pinch multi-touch motion to change the switcher into an overview mode. By pinching in, thumbnails move into a grid display. The grid can scale up to a 3×3 version, thereafter the switcher then starts to create new pages. Pinching out, while in the grid mode, changes the view back to larger stacked mode.
Direct feedback refers to the response the user receives when using the touch UI. When there is a change, the user must get feedback. Indirect feedback refers to the response the user receives while, either not using the device, or using it so that the attention is not directed to the UI.
Direct feedback can be haptic, auditory, or visual feedback from interaction with the touch screen or hardware buttons. Indirect feedback is typically in the form of notifications. Notifications may contain both sound and haptics, but they can also be visual only, or contain only visuals and sounds (or in principle also visuals and haptics alone).
When you need to catch the user’s attention, you can use auditory and haptic feedback, in addition to visual feedback. The user’s attention is usually directed away from the device, when the device’s UI is locked and the screen is blank. However, the user’s attention can be elsewhere also, when the UI is in use. A time-consuming operation may cause the user to look elsewhere, or the user’s attention may be on the hardware keyboard, so the events on the screen are easily missed. When feedback is needed almost immediately after the user’s last action (such as when the user tries to send an email without defining a recipient), a visual notification is usually enough, because the user’s attention is already on the device.
In some cases, you can also use auditory and haptic feedback to emphasize the visual message. For example, a confirmation query may have an additional questioning sound to emphasize that the user needs to pay special attention to the device. However, be careful with this kind of use for sounds and haptics, because users find it annoying if the UI requires a lot of attention all the time. You can use sounds alone for presenting events, or sounds combined with visuals, but do not use sounds alone with haptics.
You can use haptic feedback alone when you do not know whether the user’s attention is on the device. For example, when downloading a web page lasts so long that the user’s attention is not likely to be on the device, even though the device is not locked, a subtle tactile pulse can be a useful indicator.
You can use tactile feedback alone, when it is appropriate to confirm the user’s action, but a visual confirmation message is too much. For example, connecting the charger and the device starting to charge (as opposed to not starting, due to a wrong charger type, for example). In this case, haptic feedback can also be used because the user is in physical contact with the charger connector and the device.
Note that the presentation of alerts and notifications depends both on the settings in the active profile and on the current UI state. For example, during a phone call, the auditory part of many alerts is changed (presented as a beep, or the auditory part can be a simplified version of the original, or the sound may be omitted altogether).
MeeGo provides support to both virtual and hardware keyboards.
The virtual keyboard is invoked automatically when an input field is in focus (that is when the user taps an input field). The title bar and status disappear to optimize screen real estate. It has a portrait and landscape layout, opening according to the orientation it is being called from. If the user rotates the device, the layout is smoothly changed according to the new orientation.
The user can close the virtual keyboard by either tapping outside the text field or by dragging down the virtual keyboard. Note that the virtual keyboard does not act as a drawer in the sense that the user cannot pull it up. It will come up again once the text field is actioned again.
Whenever the hardware keyboard is opened, the virtual keyboard does not get loaded.
Pressing backspace clears a single character. The long press clears characters with key repeat. Long press duration and key repeat rate are the same as with a hardware keyboard. If the user selects the text and hits backspace, the whole selection is cleared. This is script (written language) dependent.
The language is set automatically, based on the UI language that the user selects in the first device startup. This can be changed in Settings.
In most cases, applications present confirm buttons as part of their UI. This is true when sending a message or login in a website. Other applications perform actions as the user types. The perfect example is search, which automatically updates the list result with every letter typed.
However, other methods can be used. In a one liner text field, the enter key works as a natural confirmation key (similar to websites and other operating systems). This works when entering a password, for example.
It is also possible to add a confirmation button to the extra line. It is not recommended for UIs like messaging, where an overall view is desired before confirming (tapping outside the text brings the whole UI back), but useful for quicker inputs. This option could be used in a form, with a next action linking to the next text field.
For applications that need to provide a more immersive experience, Full Screen Mode is available. It is important, however, to always provide a way out of the application (and to application navigation when appropriate). Full Screen can be presented in two different ways:
All controls (Title Bar, Status, extra controls, etc) are removed, presenting only the maximized content. Controls are made visible by tapping the screen. This is especially useful for media-related experiences.
Because MeeGo may run in devices with no other hardware navigation keys, it is important to provide a persistent way out of the application. In some cases, it is not possible to use the tap to show the controls (for example, a Flash Player application displaying interaction content). Whenever that happens, a persistent access to exiting the full screen is still mandatory (back or close).
In a few specific cases, like games, a more immersive experience might be desired, with no chrome. It is only possible to remove the persistent navigation out of the application if an easy to access exit command is available.
MeeGo applications can be written using Qt (a rich C++ application framework) or Qt Quick (a Javascript-like declarative language). The MeeGo SDK includes Qt Creator IDE with GUI builder to enable streamlined development. It is currently available for use on Linux workstations as shown below.
Develop |
Debug |
Package |
Distribute |
The MeeGo SDK creates a virtual environment on your workstation that replicates direct development on a MeeGo OS-based system. Netbook and handset development images are currently available. You can set up your development environment in two ways, depending on the capabilities of your host system. QEMU will work effectively only on VT-enabled systems with graphics acceleration (first blue box above), while chroot+Xephyr (second blue box above) will only work on systems with Intel graphics. Both provide a similar development experience.
You can debug your application by using QEMU or Xephyr and run your application inside the MeeGo user experience. Both QEMU and Xephyr have been enhanced with support for hardware accelerated graphics.
Create a standard RPM-format package for your MeeGo application.
The RPM package can be submitted to one of the various application stores.
Finally there is some great news for N900 owners as MeeGo 1.1 with dual boot capability has been released. MeeGo is basically a Linux based Smartphone / Mobile operating system that was jointly announced by Intel and Nokia at Mobile World Congress back in February 2009. Insider sources confirm that the only reason MeeGo was developed with Intel is because of Microsoft’s Windows Phone 7 not supporting Atom processors produced by Intel. MeeGo is not only Smartphones focused as this operating system will battle Android and iOS by running on variety of hardware i.e. touch tablets, TVs, in-car gadgets, netbooks etc. We believe that MeeGo like Android, will appear as “Stock” in lesser devices and with UX (User Experience) theming / branding on top.
According to official Meego Blog, the new release 1.1 will be packaged with:
Unlike Android and other Smartphone applications, MeeGo is a tough nut to crack when it comes to installing this OS over various platforms. Until now, we have confirmed that this new release, MeeGo 1.1, has files available for planting it’s image on Nokia N900. If you are tired of Maemo 5 OS on your current N900, you can give MeeGo 1.1 a shot by downloading the required files from here. Please note that we do not recommend novice users trying out this build as a guide offering complete installation process is still not out.
THE OPEN SOURCE, Linux based Meego mobile operating system has been given a 1.1 release update today.
The mobile OS Meego was only unleashed back in the spring and is ready to roll with version 1.1. The smartphone OS is a combination of Nokia’s Maemo and Intel’s Moblin, so it’s no wonder that this latest release looks like it was tailor made to fit Nokia’s excellent N900.
Nokia’s N900 user community has been pressuring the Meego open source community to add the OS to its headliner smartphone. It looks like Nokia and the Meego teams have mostly answered their prayers with a dual-boot option that fires up Meego alongside Nokia’s own Maemo OS on the N900.
We say mostly because Nokia still hasn’t given its official blessing yet. The Finnish phone company has been promising Meego dual boot on its so far underrated qwerty slider smartphone for awhile.
You can still pop along and pick up the Meego 1.1 update. You can also pick up the N900 Meego 1.1 update. However, the community and users are still waiting for the nod from Nokia. Actually, since when have fanbois waited for an officially sanctioned nod from hardware or software providers before they started tinkering with their toys?
The INQUIRER reported earlier this month that the N900 would be the first device to receive support for Meego 1.1. Updates include the kernel, X-server, the GCC compiler, battery loading meter and even the Fennec browser. The team said then that there were still bugs but they should be fixed by release. Maybe Nokia is waiting for a bug-free green flag.
| © 2010 Netspider.com Make IT Easy | Xml Sitemap | by net spider |
