[maemo-developers] Maemo Best Practices

[From: Edward Page]

Hi All,

I was talking to texrat recently who had the idea of organizing best
practices for app development.  Currently I really only have a couple
of categories with limited ideas for each.  I'm curious what you all
think before running off and creating the wiki page.  Out of laziness,
I did some wiki syntax but not all of it is.

Some of it will be controversial and would probably be best to leave
out of what we put online.  I do not mean this with the intention of
starting a flamewar and turning this into some of the more
"interesting" t.m.o conversations but I think it'd be good to hear
various opinions on them before deciding to leave it out rather than
just ignoring some of the harder issues.

Ed Page
(epage)

"Let's adhere to standards, but lets make those standards good. "
-- joshua.maverick

= User Experience =

== Custom Interfaces ==

"""
As pointed out by others earlier in the thread, Maemo, being a
finger-oriented mobile OS, has some very specific UI guidelines for
developers to follow to help maintain "consistent experiences". In my
mind it really boils down to what you're doing though: Are you
building an app to add/extend functionality of the device (i.e. a
simple note taking app, a map application, etc), or are you building
an app/program to be used/run on the device (i.e. a game, a photo
editor, whatever)?

If the former, then you should definitely follow the visual
requirements of the UI guidelines and do your very best to leave the
"appearance" up to the hildon theme/ OS control in general. That way
when a user changes themes, your intergrated app changes accordingly.

On the other hand, if you're building an "application" that
conceptually stands out as a program rather than just some "feature
compliment/way of doing cool stuff that you don't expect", then the
interface should be more under your control than that of the
underlying OS/theme. That's not to say you should ignore the UI
guidelines about button placements, size of text/etc... those are all
there to help ensure a pleasant experience on a mobile device... but
in this type of situation things like PNG backgrounds, different
looking buttons/etc are acceptable and almost expected, AS LONG as
they're done well and the interface is INTUITIVE. Any time you deviate
from the "Standard view" that users are used to, you have to put extra
effort into making sure that they won't need an instruction manual in
order to figure out how to use your design/UI elements.
"""
-- jolouis

"""
You don't need custom design to make it "nicer". It's the UX that's
important, and wondering every time I open a new app where the buttons
are, and what's part of the background, isn't helping.

In some apps it makes sense, in most it doesn't. Most of the apps just
need a better UI layout to make them "nicer".
"""
-- ColdFusion

== Screen Rotation ==

Keep in mind there are many use cases where a user might want or not
want rotation.  Reading a book in bed is one example where rotation
might do the exact opposite of what the user wants.  Also when setting
the device on a desk, due to the sensitivity rotation might
accidentally be invoked.

Generally do not rotate to portrait mode if the hardware keyboard is out

= Debugging =

== Debug Logs ==

Debug logs provide a way for users to report back information in an
precise manner.

Things to include
* Program Name
* Program Version
* Device / OS Used
* Separation between launches

To not eat the users space, logs should be rotated.  One example of a
rotation scheme is to delete the logs in the package install script.
This will clear out log history in upgrade at which point the logs
will most likely be irrelevant anyways.

For best results in getting these from an end-user to developer, a
non-command line approach needs to be available.  Some examples
include
* Keyboard shortcut (in About or generally) to put log into the
clipboard buffer or save using user-friendly file dialog
* A log screen in the About dialog

= Guideline For Keyboard Shortcuts =

All applications have different requirements so keyboard shortcuts are
the most fickle to get right for an application while trying some
semblance of consistency.  A consistent guideline to use when not in
an exceptional case can provide an improved user experience.

Generally the +/- hardware buttons should be left for volume
management rather than interface zoom.  Two examples when its possibly
acceptable to override volume is for custom volume within an app (like
a game) or document zoom.

Suggested shortcuts include
* Ctrl+Enter or Ctrl+f for toggling Full Screen
* Ctrl+f for search
* Ctrl+n Find Next
* Ctrl+p Find Previous
* Ctrl+i / Ctrl+o for Zoom In / Out
* Ctrl+r for Refresh