Revision as of 00:24, 16 April 2011 (view source) Jnwi (Talk | contribs) (→Preliminary UI Concept) ← Older edit		Revision as of 00:30, 16 April 2011 (view source) Jnwi (Talk | contribs) (→Preliminary UI Concept) Newer edit →
Line 81:		Line 81:
	[[File:YagpTransparentbuttons.png]]		[[File:YagpTransparentbuttons.png]]
		+
		+
		+	== Text editing ==
		+
		+	All multiline text boxes run in Vi emulation mode by default, starting up in insert mode.  This allows the novice to continue as usual, while the power user can quickly access advanced functionality that would be impossible to include in any kind of menu system.

---

Revision as of 00:30, 16 April 2011

Contents 1 Scope 2 Getting involved 3 Preliminary UI Concept 3.1 Desktop 3.2 Task switcher and application menus 3.3 List view: multiple selection and secondary actions 3.4 Buttons 3.5 Text editing

Scope

The purpose is to provide a fully functional mobile GUI for power users that is both efficient and moderately easy to learn. Previous GUI:s have often been either too simple or unnecessarily complicated.

To succeed, this project needs to provide:

• An overall vision and UI guidelines
• A set of QML widgets
• A task switcher and desktop
• Important core user interfaces like SMS, email, media player, etc.
• Good documentation for developers writing other applications

The above will ideally all run on a vanilla MeeGo image, avoiding the need to code more than a new GUI for most applications.

Getting involved

In order to move faster, teams should work in parallel on the different applications, after the widgets have reached a reasonable state. Feel free to add your name to non-management teams and even volunteer new apps to the list, but introduce yourself to the main organizers if you're new.

• Project management and UI design
  • Jens Wiik
  • Jerry Jalava
• QML Widget developers
• Graphics designers
• Packaging team
• Application developers (vanilla MeeGo applications will be used at first, and replaced one by one)
  • Address book
  • SMS
  • Media player
  • File manager
  • Terminal
  • Web browser
  • Email
  • Photo gallery
  • Task switcher
  • Desktop
  • Calendar

Preliminary UI Concept

Desktop

AMOLED displays allow devices to display information on standby screens without wasting huge amounts of energy. Symbian^3 displays a clock, for example. We will not stop there. Our desktop widgets have two modes: normal, and standby. This allows the user to customize the look of the standby screen without having to access a separate configuration interface.

Desktop widgets should register a wakeup interval with the desktop manager for standby mode. Available intervals are kept simple: 1, 5, 10, 30, 60 minutes. In practice only the clock should need the smallest interval. All widgets registered for a certain interval are woken up at the same time so that the CPU can sleep for as long as possible.

We do not, however, deny CPU time to normal apps while in standby mode.

Task switcher and application menus

Mobile devices have limited screen space, and having menu bars visible all the time wastes a lot of it. Our applications are always in fullscreen mode, and the menu bar of the current application is instead visible in the task switcher. Combining the two reduces the amount of modes that are necessary.

Returning to the application is done by pressing in an empty area. Maemo 5 returns to the desktop when this is done, but in our case the desktop becomes just another window.

The task switcher is activated either through a hardware button or by a touch gesture. There are no hints when in full screen mode - they waste space and this action is so frequent it should be memorized.

List view: multiple selection and secondary actions

Many mobile applications do not include support for multiple selection even though they could greatly benefit from it. This probably has two main causes: checkboxes waste space and look ugly.

We can do better. All list views will support multiple selection by default wherever it makes sense. It is both attractive and unobtrusive if done right: by having a separate background stripe that triggers the selection action.

Even better, the same interface can be used to provide secondary actions - something which is often extremely annoying in touch interfaces. When even a one item selection is made, a bar of buttons slides out from somewhere with the actions that can be performed.

The demo pic is using Maemo 5 - ignore the rest of the UI.

Buttons

When buttons are used in applications with scrolling content, they tend to waste a lot of screen space. Our transparent buttons, labeled with a minimal font size and fading borders, let users see almost 100% of the content.

Pressing inside the bordered area activates the button like any other. Drags can be started from outside and end inside a button without focus shifting to the button.

In the example picture, a browser has chosen to provide immediately accesible back and forward functions, and use the rest of the buttons for tabs.

Only 5 buttons are available in both landscape and portrait mode. In portrait, 5 is still relatively easy to use. When overflow occurs, one button changes into a menu. Applications should avoid using more than 5 buttons.

Text editing

All multiline text boxes run in Vi emulation mode by default, starting up in insert mode. This allows the novice to continue as usual, while the power user can quickly access advanced functionality that would be impossible to include in any kind of menu system.