My notes from last Fridays
MOTODEV Summit:
designing the best UI for mobile handsetsbe 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
controls:
grids
(2 line) lists
nested option menus
tabs
predictive
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)gui:
consistency throughout
simplicity
screen size and resolution
prevent user accessing unproductive apps
Autostart
- reg setting
- startup folder: exe or .RUN file
AppLauncher - not supported
AppCenter
- 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(?):
-expensive
SPB Kiosk
- 3rd party solution
- expensive for small volumes
Pocket controller (from SOTI):
skinable
can capture to .AVI
Windows Mobile DevelopmentWhy 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
- ADAPTABILITY
- 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.0web 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