2. UI Design for Mobile Devices Multi-mode communications

3. Demo

4. Current UI design challenges 3G pre-IMS and IMS communications functions  Spanning communications modes: from store and forward, to near-real-time, to real-time  Combining IP and circuit switched networks  Combining multiple radios: WiFi and mobile VoIP in enterprise and consumer use cases Bridging the chasm between mobile (IMS) and internet approaches

5. State of play VoIP: Ugly look, naive design, missed opportunities  Failing to make a more flexible form of communication more attractive  Failing to tame PBX, VoIP usability, accessibility Mobile: highly polished, but limited  Usability for central functions is good enough to make the mobile phone accessible to every human  Doesn't encompass messaging, PoC, and real time voice in a single UE

6. Our original goals Bring the polished quality of mobile UI to VoIP devices Make a simple, understandable PBX UI in the mobile form factor Add IM, social networks, and “VoIM” to the mix Focus on communication – not music, TV, games, location services, etc. Do it using a modern approach to platforms and implementation

7. Target applications 3G and IMS WiFi in mobile handsets Enterprise VoIP and FMC Consumer pre-IMS mashups of IP and mobile applications

8. Enablers The new baseline is 3G SoCs Ubiquity of applications processors and/or virtualization obliterate the smartphone/feature- phone boundary PDA-based UI is being replaced by new generation smart mobile devices – iPhone, Danger, Android Managed language system (Java) + open OS (Linux) = smart open mobile devices

9. Technologically similar Transvirtual SavaJe Java FX Mobile Danger Android Blackberry?

10. Architecture Good UI is more than skin deep: The UI designer creates a world for the user to manipulate Architecture must support UI design goals  Abstracting protocols  Translating from protocols to items in a “communication world” Make it simple and enjoyable

11. Abstracting protocols Cover all relevant protocols for telephony and near-real-time messaging Provide a consistent API Provide a coherent event stream Enables building a universal call state machine

12. Architecture diagram

13. Keep it simple No pop-ups, no dialogs No confirmation, except when user data can be permanently destroyed You can always do the thing the screen was meant to enable you to do – no “dead spots” One type of object per screen Softkeys are navigation shortcuts – no “verbs” on softkeys Consistency in forward/back/home behavior

14. The user's communications world Services: The mobile network, the IP PBX at work, Yahoo IM, GoogleTalk, etc. Contacts: Contacts have addresses that can be reached by at least one of the services you use Sessions: Conversations with contacts  The user can have many live sessions, and one current (not on hold) realtime voice session  There is a history of session  Some sessions are favorites

15. Novel, but familiar Sessions bring multimedia, multi-mode, and multi-service communication into the heart of the phone UI Sessions are generic, and have uniform and familiar behavior Familiar operations on mobile calls work the same way  Generic operations on objects  Never lead the user down a dead end

16. Demo

17. Measuring our progress Is it simple? Is it familiar? Does the user do more – did we successfully provide access to power? Is it applicable to high-value problems: IMS, dual- mode, 3G, enterprise communications? How far into mass-market hardware can it go?