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â beneďŹts 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
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
OfďŹine storage
(C) Copyright Paul Golding, 2008
8. 8
Widgets and OfďŹine...
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.
OfďŹine 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â
OfďŹine
â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 beneďŹts 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
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 reďŹected
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 (ofďŹine
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 reďŹected 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
OfďŹine 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 âsurďŹngâ 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
OfďŹine sync Browser
âAlways onâ web
Web 2.0 âMobile OSâ
(e.g. Widgetization)
API API
Telco Telco OS OS
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 ďŹow 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 ďŹt 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 deďŹning 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