That's great.
Can you add them to the wiki page:
https://wiki.ubuntu.com/MobileAndEmbedded/UserApplicationCriteria
That way they won't get lost in email list archives.
Kyle
On Oct 26, 2007, at 3:51 PM, Robison, Clayne B wrote:
I agree with everything that Steve said below. A few more things:
1) 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.”
2) 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.
3) 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.
4) 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).
5) 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.
More criteria:
* Applications load + save data automatically - user doesn't have
to remember to save data
* 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.
* # 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.
* # Featureset should be minimized. Applications like Claws have
dozens of menu items, most of which aren't useful to our target
market.
* # of dialogs is minimized
* 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 offscreen, 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.
* 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.
Steve
Thanks.
Clayne Robison
Application Engineer
Intel Corporation
Salt Lake, UT
801.445.0297
"Perhaps travel cannot prevent bigotry, but by demonstrating that
all peoples cry, laugh, eat, worry, and die, it can introduce the
idea that if we try and understand each other, we may even become
friends." Maya Angelou
--
Ubuntu-mobile mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/
listinfo/ubuntu-mobile
--
Ubuntu-mobile mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
