Applications

From Openmoko

(Difference between revisions)
Jump to: navigation, search
m (added template links)
Line 16: Line 16:
  
 
==Finger-Based Applications ==
 
==Finger-Based Applications ==
 +
 +
([[Sample Native-Finger Application|template]] for new native-finger applications)
  
 
=== 0th Phase ===
 
=== 0th Phase ===
Line 38: Line 40:
  
 
==Stylus-Based Applications ==
 
==Stylus-Based Applications ==
 +
 +
([[Sample Native-Stylus Application|template]] for new native-stylus applications)
  
 
=== 0th Phase ===
 
=== 0th Phase ===
Line 68: Line 72:
  
 
Panel Applications are individual executables residing in the [[Top Panel]]. They usually indicate their status and offer a pop-up menu. We are not yet sure whether there is enough screen real estate for this huge number of panel applications.
 
Panel Applications are individual executables residing in the [[Top Panel]]. They usually indicate their status and offer a pop-up menu. We are not yet sure whether there is enough screen real estate for this huge number of panel applications.
 +
 +
([[Sample Panel Application|template]] for new panel applications)
  
 
=== 0th Phase ===
 
=== 0th Phase ===

Revision as of 22:02, 19 February 2007

Contents

Overview

Although OpenMoko is designed for smartphones that use a stylus, it would be foolish to expect people to only operate their handsets with stylus. For this reason, some core phone-related applications will be developed with finger (as opposed to stylus navigation) in mind.

NOTE: Applications listed on this page are listing in order of priority and by phase. 0th phase is for the developers preview release in February, 1st phase is for March. 2nd phase is September... when we are ready for mass market appeal.


General Principles

  • All modifications are saved instantenously, there should never be a save command.
  • Make sure users can't make interface operation errors, or that the effects are easily reversible, instead of just notifying them of the potential consequences of their actions.
  • When you open a document you should be returned to the place where you were working when you last closed or save it (this is our concept of sessions).
  • Label buttons with adjectives, which describe the state of the object affected
  • Designers should seek an efficient monotonous solution to gain benefits, including ease of learning, simplicity of implementation, minimization of documentation, and lowered maintenance costs.
  • Whenever you find yourself specifying an error message, please stop; then redesign the interface so that the condition that generated the error message doesn't arise.
  • If the user gets no utility from a process, there is no reason to tell them that it is happening.
NOTE: Innovation usually happens at the bottom. What we need to do is provide consistent ways to develop and deploy appliations.


Finger-Based Applications

(template for new native-finger applications)

0th Phase

1st Phase

2nd Phase

Stylus-Based Applications

(template for new native-stylus applications)

0th Phase

1st Phase

2nd Phase

Panel Applications

Panel Applications are individual executables residing in the Top Panel. They usually indicate their status and offer a pop-up menu. We are not yet sure whether there is enough screen real estate for this huge number of panel applications.

(template for new panel applications)

0th Phase

1st Phase

2nd Phase

Personal tools

Overview

Although OpenMoko is designed for smartphones that use a stylus, it would be foolish to expect people to only operate their handsets with stylus. For this reason, some core phone-related applications will be developed with finger (as opposed to stylus navigation) in mind.

NOTE: Applications listed on this page are listing in order of priority and by phase. 0th phase is for the developers preview release in February, 1st phase is for March. 2nd phase is September... when we are ready for mass market appeal.


General Principles

  • All modifications are saved instantenously, there should never be a save command.
  • Make sure users can't make interface operation errors, or that the effects are easily reversible, instead of just notifying them of the potential consequences of their actions.
  • When you open a document you should be returned to the place where you were working when you last closed or save it (this is our concept of sessions).
  • Label buttons with adjectives, which describe the state of the object affected
  • Designers should seek an efficient monotonous solution to gain benefits, including ease of learning, simplicity of implementation, minimization of documentation, and lowered maintenance costs.
  • Whenever you find yourself specifying an error message, please stop; then redesign the interface so that the condition that generated the error message doesn't arise.
  • If the user gets no utility from a process, there is no reason to tell them that it is happening.
NOTE: Innovation usually happens at the bottom. What we need to do is provide consistent ways to develop and deploy appliations.


Finger-Based Applications

(template for new native-finger applications)

0th Phase

1st Phase

2nd Phase

Stylus-Based Applications

(template for new native-stylus applications)

0th Phase

1st Phase

2nd Phase

Panel Applications

Panel Applications are individual executables residing in the Top Panel. They usually indicate their status and offer a pop-up menu. We are not yet sure whether there is enough screen real estate for this huge number of panel applications.

(template for new panel applications)

0th Phase

1st Phase

2nd Phase