Criteria for assessing completeness of application porting to Ubuntu Mobile.

• Minimum criteria
  • Hildonization
  • UI works at 800x480
    • All screens and dialogs must fit onscreen (800x480)
    • All screens and dialogs must render properly (no overlapping widgets, no text spilling out of buttons, no text off-screen, no popup menus that aren't wide enough to read the content of the menu, etc).
    • Dialogs must be positioned centered and fully onscreen. The user should never have to move a dialog to see its contents
    • Applications with multiple screens (such as a tabbed browser) must present an easy, obvious way to navigate between screens.
  • UI works for finger touch (no small buttons)

    • See Designing for Finger-Driven UIs

  • Set up for translation
  • Consistent with theme and icon framework
  • Documented
  • Tested
• Complementary criteria
  • Applications load + save data automatically - user doesn't have to remember to save data
  • Implements Hildon Accessibility Library
  • Filesystem is hidden from the user. Users should never need to know a filename, they should only interact with data + metadata (thumbnails for the image viewer, song/artist name for music, from/to/subject headers in email, etc).
    • This means no traditional open/save dialogs
    • "Attach file" dialogs need to present a friendly list of objects to attach (thumbnails or metadata)
    • If the user has to be presented a list of files, the list must only include relevant files. Things like /usr and .xyz files must always be excluded.
  • Number of configuration options is minimized. Applications should come preconfigured with intelligent defaults. Options should only be included if they're easily understood by the computer-phobic or if they're likely to be useful to a large minority of users.
  • Feature set should be minimized. Applications like Claws have dozens of menu items, most of which aren't useful to our target market.
  • Number of dialogs is minimized
  • Applications run as a singleton (can't have multiple copies of the app running)
  • Instant feedback - any interaction with the UI results in visual/audio feedback within 200ms, which is the upper limit of what's necessary for the appearance of 'instant'. For a tactile device like a MID, it's important that widgets act like physical objects. Delayed reactions remind the user that they're on a computer.
  • Applications shouldn't require a mouse cursor for functionality. This means hovering + tooltips are out.
  • Applications shouldn't require right-clicking for any significant functionality - right-clicking is awkward if the user is holding the device in one hand and using their other hand to navigate (I'd like to see right-click abolished entirely).
  • Error messages should suggest a course of action to the user.
  • Applications gracefully handle out-of-memory and disk full conditions. Gracefully = no crashing, freezing, or losing data.
  • Network connectivity: Applications should be network connection aware, allowing the user to be connection agnostic. I.e. internet/network based apps should function as well as possible regardless of whether or not there is a connection to their backend data, performing automatic synchronization when network connection is available. This may mean some amount of caching and prefetch to anticipate non-connected states. For example, an e-mail app allows someone to work perfectly well offline—composing, reading and managing mail—and then automatically synching once a connection to the server is available. Users should NEVER have to press some button that says “Sync Now”, “Go Offline” or “Go Online.”
  • Storage space awareness: Because many of the devices we are targeting are going to have limited storage space, all applications that store data on the device should be aware of this limitation and be prepared to handle the inevitable. I recognize that this criteria juxtaposes #1, which requires networked apps to prefetch and cache, and assumes limitless local persistent storage.
  • System CPU and Memory resources: Many of our target devices will also have limited CPU and Memory resources, and much of the software that is currently installed by default (e.g. the System Monitor) are currently VERY resource intensive. Applications that know they need lots of CPU and/or memory (e.g. video playback) should sniff out the current playing field and warn the user if CPU/memory usage is already so high that performance may be hampered. Ideally, we wouldn’t have this hardware restraint, or OS would do this for apps, but I don’t think we’re to that point yet.
  • Power: Mobilized applications should recognize that battery life is a major goal for these platforms, and that they have a responsibility to play nicely. At a minimum, calls that prevent the system from sleeping, or the screen from blanking should be used judiciously. Applications should also handle the backup and sleep/exit events generated by OSSO/D-bus to prevent their own data loss. Those applications that are beginning a process that may need some time to complete (e.g. file download) should calculate whether there is enough power to complete the operation. All applications should handle the battery-low event to allow the user to take appropriate action (e.g. notify your chat buddy that you might disappear).
  • Screen: While it is true that all dialogs must fit on 800x480 resolution, they should also not be so small that they cannot be read on devices with native 1024x600 resolutions.