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


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 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
- 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.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