Thursday, November 15, 2007

MotoDev Summit notes

My notes from last Fridays MOTODEV Summit:

designing the best UI for mobile handsets

be obvious
be accessible
be consistent
be new and beautiful }be engaging
be fast }
be protective (protect users (MY) work)
be familiar - speak my language - applications should ahve a personality - make user smile
be powerful - give the user (ME) power and control

(2 line) lists
nested option menus
progressive disclosure
5 way controls

application based - not task based

common structure:
list -> view -> edit -> save -> list...

Flow + media + prompts = application

flow: movement between tasks/screen/functions/action

media: icons animations colours image themes fonts sounds

prompts: context style tone nomenclature capitalisation grammar & punctuation

Put context in your messages:
Not: "Wait..."
But: "One moment. Loading contact from sim card."

"language can never describe a user experience"

framework (from device/platform) + application = UI

when developing the UI, focus time/effort where users will spend their time, not on edge cases.

controling device access (Symbol devices)

consistency throughout
screen size and resolution
prevent user accessing unproductive apps

- reg setting
- startup folder: exe or .RUN file

AppLauncher - not supported

- free download
- prelicensed on each device
- shell over the OS
- admin password to close
- diasbles activesync
- no programmign required
- has a debug mode
- supported

Good mobile Messaging 5(?):

SPB Kiosk
- 3rd party solution
- expensive for small volumes

Pocket controller (from SOTI):
can capture to .AVI

Windows Mobile Development

Why certify?
- commitment to quality
- demonstrates applying best practices
- required for inclusion in Microsoft app catalogue and marketing
- helps ensure device compatibility

why sign apps?
- slightly improved UI - as not prompted
- required for installation on some devices
- needed for access to some device functionality

designing for multiple devices:
touch screen - with or without
form factor - screen resolution & orientation
hardware (buttons, radios, peripherals, etc.)

however - all use same runtime

Plan before starting:
- define minimum device requirements
- try and use additional functionality of some devices and down grade gracefully where not available
- avoid trying to target the lowest common denominator
- support touch screen where available

consider using separate forms for touch screen and non-touch screen versions

to target multiple devices
use anchoring and docking
when that is not enough, use the Orientation Aware Control
when that is not enough, hard code screen design based on device

Mobile Web 2.0

web 2.0 = user generated, has a network effect

think of mobile as an extension of the desktop

focus on mobile centric data/situations, rather than just portng desktop functionality