Small Surface Area
Graphical User Interface

The Small Surface Area - Graphic User Interface was developed with the idea of allowing full business class editing on a small surface area device, such as a phone. In this documentation this design pattern will be referred to as "SSA design" or SSA-GUI. The basic precepts of this design are as follows:

  • The application functionality must be divided into atomic tasks.
  • Each task can be comprised of one or more steps.
  • There must be a task bar at the top when in portrait mode, or on the left side of the screen when in landscape mode.
  • The task bar must always show the list of steps for the currently running task.
  • The task bar must contain a button to allow switching of tasks.

The basic idea is to have the app start off with a main menu. The main menu allows the user to initiate a task. When a task is initiated, the first step of the task will be displayed. This will also update the task bar to show two items, Main Menu and the new task's step name. The step's matching visual components can include more ways to initiate another step to be added to the list.

One important use of the task bar, when the user is doing complex editing, will be to allow the user to scroll through the steps they took to get to the point they are at. Should the user be called away, they will need to be able to come back and use the task bar to ascertain where, precisely, they are in the process. This means that for apps with complex editing the task bar must be able to scroll.

Since the task bar is at the top when in the portrtait mode (the most commonly used mode for phones) control buttons should take up no more than a single row at the bottom of the screen. Normal buttons here would include save (or OK), cancel, add, and delete.

If many more options than these are needed then a "Edit" button should be added. When the edit button is pressed the app will display a contect sensitive menu. This menu would normally include buttons for Cancel All and Save All. When the calling screen has a list, it could also include buttons to toggle selection mode, cut, copy, and paste.

Allowances must be made to interface the editing screens with the task bar. This is needed so that as the user makes selections, or edits the information, the task bar can update accordingly. If the main menu had a task called, "Edit makes and models" then when the user clicks on this button, the program should launch the associated task. Launching this task would display the first step, which would list the makes. The user could add a make, or delete a make, or go into a make to see the models. When the user clicks the arrow next to "Chevrolet" to go into that make, a new step would be added to list the models of Chevrolet. The task bar would now have 3 items "Main Menu", "Edit Make:Chevrolet", and "Edit Models". At this point it could be possible to go deeper by specifying attribues of a specific make and model. If this were to happen then the task bar would change to "Main Menu", "Edit Make:Chevrolet", "Edit Model:Chevrolet", and "Edit Model Attributes".

At any stage of editing the user should have the option to "Save All", or "Cancel All", normally through the Edit menu. It is never assumed that saving is done dynamically. This allows for business class editing. This means having the ability to save or cancel any one step in the larger process, at any time in the process. One example of this would be to change one attribute for a specific make and model. Instead of clicking "Save" repeatedly until you get back to the main menu, saving the changes to each level in turn, clicking "Save All" would allow you to do it much more efficiently. Being able to save multiple changes to multiple levels of complex information, while retaining the ability to cancel all of those edits, still retains value. This design allows for both possibilities.

For a working example of this design, check out our Pro Workout app. It is currently in the Alpha state and should be available on the Google Play Store soon.