Real Time Mobile Web V0.2

  • 21,227 views
Uploaded on

Update of my previous deck on similar topic, but this one with some refinements and more pictures.

Update of my previous deck on similar topic, but this one with some refinements and more pictures.

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • Good presentation ! thanks for sharing !
    http://www.comparatif-cybermarche.com/
    Are you sure you want to
    Your message goes here
  • Paul, you have outdone yourself again, just the type of application frameworks we are proposing to our clients for real-time native-web convergences. I am borrowing some of your words :)
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
21,227
On Slideshare
0
From Embeds
0
Number of Embeds
7

Actions

Shares
Downloads
1,423
Comments
2
Likes
77

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 1 Rich Mobile Applications Enabling a real-time mobile web UX Paul Golding (02-Dec-2008) v0.2 Copyright Paul Golding, 2008
  • 2. 2 The Thesis Due to a number of key browser and mobile platform trends, mobile web applications will increasingly be capable of real-time and asynchronous functions that will dramatically improve the user experience, including impacts on telephony, messaging and social networking. This will lead to a new breed of Rich Mobile Applications (C) Copyright Paul Golding, 2008
  • 3. 3 Real-time? Real-time here means ability for the web-based applications to respond to asynchronous events as they happen in both the web and “native phone” domains. For example, web application will be bought into focus in response to IM message, text messages, phone calls, social network updates - they will handle the events, consume the data and dispatch response(s). Real-time is a key attribute of the mobile experience - it is what mobile is all about! (C) Copyright Paul Golding, 2008
  • 4. 4 Real-time? Web  Page Web page synchronised to user clicks Phone events Web Web events Page  Web Page Web 2.0 Web page changes state asynchronously to user clicks Copyright Paul Golding, 2008
  • 5. 5 Mobile Browsing 1,2,3.. Thus far, mobilisation of web has been mostly about accessing the web from a mobile. Phase one was ‘cut-down’ web (e.g. WAP) and phase two was ‘full web’ on the mobile. Full web still a relatively poor UX, but improving and highly motivated by the increased digitisation of lifestyles due to Web 2.0 - i.e. we all spend more time online and need the same basic ‘always browsable’ benefits that mobile telephony brought to telephony. Phase three needs to be about making the web ‘always on’ (persistent) and enabling it to merge (mash?) with the other mobile functions (e.g. telephony, messaging, location etc.) Always browsable not the same as ‘always on’ (C) Copyright Paul Golding, 2008
  • 6. 6 Key browser trends... (C) Copyright Paul Golding, 2008
  • 7. 7 Trend 1- Persistence In order for a mobile application to be reactive to real-time events, it has to be always running, or persistent. Key technologies that support persistence are: Widgets/Embedded web container Offline storage (C) Copyright Paul Golding, 2008
  • 8. 8 Widgets and Offline... Widgets can support persistence by allowing the web application to always be running and always be visible (in some way) to the user. Note that many implementations today of widgets are NOT persistent! They do not run in the background. Offline storage supports persistence by allowing (a copy of) web-bound data to be accessed and updated in real-time without a viable web connection (C) Copyright Paul Golding, 2008
  • 9. 9 The advantage of persistence... Widgets Always on and able to react to events Always visible to the user - easy to ‘bump into’ Offline ‘Web bound’ data always available Outbound events can be asynchronous to network availability (e.g. updating status, sending a message etc.) Challenges: battery, data sync, widget UI (small screens) (C) Copyright Paul Golding, 2008
  • 10. 10 Trend 2 - Push We have persistence, but how do we make these apps reactive to events? Not by AJAX-ian polling = bad for battery = bad for mobile! Non-web push already exists - WAP Push, SMS, MIDP registry, Blackberry, Mobile Me: all external to web runtime. Mobile AJAX will likely incorporate COMET - true asynchronous push within the web runtime. Example - lightstreaming. See http://blog.wirelesswanders.com/?s=push+ajax Web Page Web 2.0 Data pushed to the web page (C) Copyright Paul Golding, 2008
  • 11. 11 Trend 3 - Browser APIs Open AJAX mobile APIs e.g. BONDI initiative (OMTP) Telephony, messaging, address book, location, camera, media etc. Note - most browsers already support embedding of phone numbers (OMA) Web Device Web Page APIs Page Browser Browser Javascript access to APIs (C) Copyright Paul Golding, 2008
  • 12. 12 Trend 4 - embedded web Making the web browser a component accessible natively - e.g. Qtopia, Android [like Adobe Air on the desktop] Client-side “mashing” possible, between web apps and between web and native apps/data stores e.g. address book + dynamic Facebook updates This architecture tends to support pattern of web-UI enabling of native apps (e.g. iTunes). In other words, native-centric more than browser-centric integration. Still valid, still useful. Device Native APIs App Embedded Browser (C) Copyright Paul Golding, 2008
  • 13. 13 Trend 5 - MIDP Bridging Ability to access MIDP helper applications from within the browser environment Numerous potential benefits to running helper functions in MIDP, but also architectural challenges (at embedded level) Fragmentation not so problematic if large part of the overall app will be web-based MIDP Web Apps Page Browser (C) Copyright Paul Golding, 2008
  • 14. 14 Trend 6 - Helper Functions Use of native phone applications to support the browser Possible method is Netscape plug-in architecture and <object> tag Emerging in browsers like Opera 9.5 and Torch Mobile’s Iris (partner solution for Qtopia) Add-ons architecture in Fennec Helper Web Apps Page Browser (C) Copyright Paul Golding, 2008
  • 15. 15 Trend 7 - Better Javascript Faster performance (e.g. SquirrelFish in Webkit) Richer libraries Javascript could also be used to support inter web-app communication pathways (e.g. in Widget framework) Will Javascript become native to mobiles anyway (e.g. JavaFX Script)? (C) Copyright Paul Golding, 2008
  • 16. 16 The ecosystem trends... (C) Copyright Paul Golding, 2008
  • 17. 17 Web 2.0 Trend - Cloud Computing Moving more of your data into the cloud - contacts, diary, documents, notes, bookmarks, photos Other data sets makes sense: text messages, call records, - moving towards 100% of “phone data” stored in the cloud (C) Copyright Paul Golding, 2008
  • 18. 18 Web 2.0 Trend -Microformats Data formats that make data more portable between web applications Opportunities to move more mobile data into the cloud, keeping it open and portable. Emerging formats will enable “contextual” computing <div id=quot;hcard-Paul-Goldingquot; class=quot;vcardquot;> <span class=quot;fnquot;>Paul Golding</span> <a class=quot;emailquot; href=quot;mailto:goldingp@gmail.comquot;>goldingp@gmail.com</a> <div class=quot;adrquot;> <div class=quot;street-addressquot;>9 Eton Way</div> <span class=quot;localityquot;>Windsor</span> , <span class=quot;postal-codequot;>POSH 1</span> <span class=quot;country-namequot;>United Kingdom</span> </div> (C) Copyright Paul Golding, 2008
  • 19. 19 Moving “Phone” data to cloud Browser Phone Data Store The Cloud Text messages Call records “Phone” APIs Address book Open API Divert status MMS etc. User’s mobile phone usage is reflected back into the cloud into an open skype Truphone Others platform. It can then be subscribed by other services enjoyed by the user - e.g. Skype, Truphone etc. (C) Copyright Paul Golding, 2008
  • 20. 20 Web 2.0 Trend - Social APIs Google Social Graph API Google Friend Connect Movement generally towards GGG web architecture (Web 3.0) Means very easy to port social connectivity to web runtime from the phone - i.e. add a friend online, not in the address book, not in the SIM (C) Copyright Paul Golding, 2008
  • 21. 21 Social Applications Browser Phone Data Store The Cloud Text messages Call records “Phone” APIs Address book Open API Divert status MMS etc. Social apps Social APIs (C) Copyright Paul Golding, 2008
  • 22. 22 Mobile is social Messaging (real-time) Native Apps Mobile Internet = Video (packet and switched) Location Proximity (BT, barcodes, RFID, geo- tagging, GPS, “mobile compass”) Telephony (IMS, call records) Mobile is the ultimate connector! Presence/Address Book (offline storage) Mobile TV (Interactive services) (C) Copyright Paul Golding, 2008
  • 23. 23 Mobile social networks - the trend will be towards the “here and now” (i.e. real-time) aspects: Dynamic/automatic status updates based on user’s context - trend already happening with photo/location enabling of so many iPhone apps Proximity updates - “bump into” things or people and have this reflected in my social network (e.g. mobiles will replace business cards and handshaking) ‘As I think’ updates - e.g. ‘jotting at the speed of thought’ (thumbjot.com) (C) Copyright Paul Golding, 2008
  • 24. 24 RMA before RIA With the aforementioned mixable/mashable aspects of browsers with native apps, a Rich Mobile Applications potentiality is emerging RIA is usually all about the richness of the UI (e.g. Flash/Flex) whereas RMA will be more about the richness of the connectivity in its broadest sense. RIA also coming, but not so important (C) Copyright Paul Golding, 2008
  • 25. 25 Use Case - Web address book Fully networked, always up-to-date, shared address books Offline means that the address book can now be web-bound, but also instantly accessible without a connection UX - my address book is easy to maintain, always up to date (even if a friend changes his/ her number - I get the update). It shows dynamic data about my contacts, such as Facebook status, and can vector into other services, e.g. “creating social events” via Facebook In future, users will kill time by ‘surfing’ their address book. It won’t look like what it does today. It doesn’t exist in one place - it is a mash-up using microformats. The active address book is the quintessential Mobile 2.0 experience (C) Copyright Paul Golding, 2008
  • 26. 26 Use Case - Rich ‘Caller’ ID Calls/texts/emails always augmented by latest information from the user’s social networks (from the web address book) User can easily ‘bump into’ other stuff in real-time associated with their contacts (C) Copyright Paul Golding, 2008
  • 27. 27 Use Case - Rich ‘Social ID’ Rich caller ID in reverse: Web 2.0 experiences are augmented in real-time by social connectivity available via my mobile E.g. 1 - Direct association: read a blog article by Joe B and can click to call Joe B, text Joe B, or otherwise ‘connect’ with Joe B via any means possible via the enhanced address book E.g. 2 - Semantic association: read a blog about ‘acupuncture’ and immediately search for possible connections in my social network (C) Copyright Paul Golding, 2008
  • 28. 28 Implications Today Tomorrow Mobile Mobile Mobile Phone Phone Phone Network Network Network Web 2.0 Web Browser Browser 2.0 Browser Web 2.0 Media Player Media Player Media Player Other Other Other e.g. Camera e.g. Camera e.g. Camera Movement of real-time service logic and data away from the operator and towards the Web! Can this trend be extended up into the mobile network itself? This trend already underway with limited ‘network APIs’ (e.g. Betavine) (C) Copyright Paul Golding, 2008
  • 29. 29 Today: Silo mobile architecture... Rich IO Browser Messaging Comms Media (Sensors) Web Telco Telco OS OS bound bound bound bound bound
  • 30. 30 Future: Rich Mobile Applications Rich IO Messaging Comms Media (Sensors) API API API API Offline sync Browser “Always on” web Web 2.0 “Mobile OS” (e.g. Widgetization) API API Telco Telco OS OS
  • 31. 31 Mobile network trends... (C) Copyright Paul Golding, 2008
  • 32. 32 Operator trend - SIP/IMS Mobile networks migration to all-IP infrastructure, such as SIP-based IMS and XML/HTTP based XDMS (web standards, but not yet web- based - still behind a wall) In the network, SIP-based applications are easy to build, extend, mash- up and deploy: SIP servlets, SLEE etc. BUT - main technical hurdle has been IMS apps on devices and lack of universal client - no such thing as a “SIP browser” -- or is there? (C) Copyright Paul Golding, 2008
  • 33. 33 SIP ‘browser?’ Oh - it’s just a mobile web browser (or widgets) Using a native SIP ‘dispatcher,’ possible to use the browser UI as the front end for SIP apps? [Various integration points possible.] In conjunction with widgets, we have always-connected UX via browser IMS/SIP apps instantly mashable! IMS widgets the future? OR...we use XMPP to do the same thing (C) Copyright Paul Golding, 2008
  • 34. 34 Operator trend - Mobile TV Another possible key trend is emergence of Mobile TV networks (DVB-H) Interactivity is supported by mobile data, which is the possible mashing point Availability of media player and ESG should be exposed via Mobile AJAX ‘standard’ to allow Rich Mobile TV (RMTV) applications to be created. Possible new (and big) revenues stream from ‘because of’ effect - new genres of ‘social TV’ and ‘context TV’ will emerge. Also possible using MIDP bridge (e.g. JSR 272 Mobile Broadcast API) New breed of mobile TV mash-ups possible (including IPTV - I have designed them!) BUT, again, subject to willingness to make the TV ecosystem open. (C) Copyright Paul Golding, 2008
  • 35. 35 Other opportunity - Home Expose PnP and DLNA protocols to the web runtime Example is iPhone 2.0 “remote” application to control Apple TV and iTunes (via Bonjour) = mega-cool app! Use case: printing to PnP printers - “Do you want a copy of this picture (on my mobile)? Let me share it on your printer.” (C) Copyright Paul Golding, 2008
  • 36. 36 Challenges Battery life - persistent applications can be “chatty” Filtering - need way to control flow of real-time events and reactions on the handset - technological and design-pattern solutions required. Embedded platforms - not easy to enable concurrency on mobiles across multiple ‘run times’ (e.g. browser, native, MIDP, helper apps etc.) Solution is probably the new breed of integrated run-times, like Qtopia, Android etc. Persistent UX - not easy to allow users to interact frequently with concurrent web applications. Solution is better display technologies. Still a long way to go, including better use of 3D. Standards - potentially many ways to enable rich mobile applications from the browser. It is also an area of hot innovation, so need to ensure we don’t end up with lots of incompatible solutions. (C) Copyright Paul Golding, 2008
  • 37. Possible Mobile 3.0 tipping points (TP)... 37 TP = Rich Mobile Browsers? TP = Femtocells? Rich Mobile Apps Agile Sensor Access Proliferation TP = RFID? Smartphone Adoption Mobile 3.0? Cloud (“always on mobile web”) Computing TP = Android? App Social TP = Multi-network Stores Computing content vending? TP = iPhone? TP = Social APIs? All of these technologies have already landed! Mobile 3.0 = when most of our digital services will become mobilized
  • 38. 38 Summary Mobile browser trends and Web 2.0 trends point towards a uniquely mobile browser evolution that caters for the other stuff that mobiles do, taking into account the real-time element of the mobile UX New ‘rich mobile applications’ (RMA) will emerge where richness of connectivity (or richness of context) is more important than the richness of UI that is the prevalent trend in desktop browser evolution towards RIA Other ‘background’ trends in the mobile networks (e.g. IMS, DVB-H) could play a part in the evolution. In fact, RMA is a good technological fit for easier service creation with these networks. Openness is a problem (for operators) but essential for proliferation of perpetual mobile connectedness. (C) Copyright Paul Golding, 2008
  • 39. 39 Conclusions RMA is possibly the defining pivot of the next generation of mobile applications (with or without IMS). It involves ultimately an ecosystem play because mashing of other phone functions with Web 2.0 only makes sense if there’s a useful Web 2.0 ecosystem (e.g. cloud computing) to support services In other words, players in the ‘RMA race’ need a technology/ecosystem strategy to win the mobile platform wars that will eventually reduce fragmentation. Most likely, there will be three winners in the consumer space and two in the enterprise space. I have my own ideas - you can guess who :) (C) Copyright Paul Golding, 2008
  • 40. 40 Thank you Paul Golding paul@wirelesswanders.com wirelesswanders.com Follow @pgolding (C) Copyright Paul Golding, 2008