Realtime Mobile Web v02

8/9/2019 Realtime Mobile Web v02

1/40

Rich Mobile ApplicationsEnabling a real-time mobile web UX

Paul Golding (02-Dec-2008) v0.2

1

Copyright Paul Golding, 2008


2/40

The ThesisDue to a number of key browser and

mobile platform trends, mobile web

applications will increasingly becapable ofreal-time and

asynchronous functions that will

dramatically improve the user

experience, including impacts ontelephony, messaging and social

networking. This will lead to a new

breed of Rich Mobile Applications

(C) Copyright Paul Golding, 2008

2


3/40

Real-time?

Real-time here means ability for the web-based applications to respond toasynchronous events as they happen in both the webandnative 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!

3



4/40

Real-time?

4

Copyright Paul Golding, 2008

Web

Page

Web page synchronised to user clicks

Web

Page

Web 2.0

Web

Page

Phone events Web events

Web page changes state asynchronously to user clicks


5/40

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 tomerge (mash?) with the other mobile functions (e.g. telephony, messaging, location etc.)

Always browsable not the same as always on

5



6/40

Key browser trends...


6


7/40

Trend 1- Persistence

In order for a mobile application to be reactive to real-time events, it has to

be always running, orpersistent.

Key technologies that support persistence are:

Widgets/Embedded web container

Offline storage

7



8/40

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 datato be accessed and updated in real-time withouta viable web connection

8



9/40

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)

9



10/40

Trend 2 - PushWe 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

10


Web 2.0

Data pushed to the web page


11/40

Trend 3 - Browser APIsOpen 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)

11


Browser Browser

Javascript access to APIs
http://www.openajax.org/member/wiki/OpenAjax_Device_APIs_Moduleshttp://www.openajax.org/member/wiki/OpenAjax_Device_APIs_Modules


12/40

Trend 4 - embedded webMaking the web browser a component accessible natively - e.g. Qtopia,

Android [like Adobe Air on the desktop]

Client-side mashing possible, between web appsandbetween web andnative 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.

12


Native

App


13/40

Trend 5 - MIDP BridgingAbility to access MIDP helper applications from within the browser

environment

Numerous potential benefits to running helper functions in MIDP, but alsoarchitectural challenges (at embedded level)

Fragmentation not so problematic if large part of the overall app will be

web-based

13


Browser


14/40

Trend 6 - Helper FunctionsUse of native phone applications to support the browser

Possible method is Netscape plug-in architecture and tag

Emerging in browsers like Opera 9.5 and Torch Mobiles Iris (partner solution

for Qtopia)

Add-ons architecture in Fennec

14


Browser


15/40


16/40

The ecosystem trends...


16


17/40

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

17



18/40

Web 2.0 Trend -MicroformatsData 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

18


Paul Golding

[email protected]

9 Eton Way

Windsor

,

POSH 1

United Kingdom
mailto:[email protected]:[email protected]:[email protected]:[email protected]


19/40

The Cloud

Moving Phone data to cloud

Phone Data

Open API

skype Truphone Others

Browser

Phone APIs

Store

Text messagesCall records

Address book

Divert status

MMS

etc.


19

Users mobile phone usage is reflected

back into the cloud into an openplatform. It can then be subscribed by

other services enjoyed by the user -

e.g. Skype, Truphone etc.


20/40

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

20



21/40

The Cloud

Social Applications

Phone Data

Open API

Browser

Phone APIs

Store

Text messagesCall records

Address book

Divert status

MMS

etc.


21

SocialAPIs

Social apps


22/40

Mobileis socialMessaging (real-time)

Native Apps

Mobile Internet

Video (packet and switched)

Location

Proximity (BT, barcodes, RFID, geo-

tagging, GPS, mobile compass)

Telephony (IMS, call records)

Presence/Address Book (offline

storage)

Mobile TV (Interactive services)

22

=



23/40

Mobile social networks - the trend will be towards the here and now (i.e.

real-time) aspects:

Dynamic/automatic status updates based on users 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)

23



24/40

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 therichness of the connectivityin its broadest sense.

RIA also coming, but not so important

24



25/40

26


26/40

Use Case - Rich Caller ID

Calls/texts/emails always augmented by latest information from the users

social networks (from the web address book)

User can easily bump into other stuff in real-time associated with their

contacts

26


27


27/40

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

27


28


28/40

Web

2.0

Mobile

Network

Implications

Phone

Browser

Media Player

Other

e.g. Camera

Web

2.0

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)

Mobile

Network

Browser

Media Player

Other

e.g. Camera

Web

2.0

Mobile

Network

Browser

Media Player

Other

e.g. Camera

PhonePhone

Today Tomorrow


28


29/40

30


30/40

Future: Rich Mobile Applications

30

Messaging CommsRich

Media

Telco Telco OS

IO

(Sensors)

OS

Web 2.0 Mobile OS

API API

BrowserOffline syncAPI APIAPIAPI

Always on web(e.g. Widgetization)

31


31/40

Mobile network trends...


31

32


32/40

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 technicalhurdle has been IMS apps on devices and lack of

universal client - no such thing as a SIP browser -- or is there?

32


33


33/40

SIP browser?Oh - its 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

33


34


34/40

Operator trend - Mobile TVAnother 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.

34


35


35/40

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 (onmy mobile)? Let me share it on your printer.

35


36


36/40

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, includingbetter 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 dont end up with

lots of incompatible solutions.

36

37Possible Mobile 3 0 tipping points (TP)


37/40

37

Rich Mobile

Apps

App

Stores

Sensor

Proliferation

Agile

Access

Cloud

Computing

Smartphone

Adoption Mobile 3.0?(always on mobile web)

TP = Rich Mobile Browsers?

Possible Mobile 3.0 tipping points (TP)...

TP = RFID?

TP = Multi-networkcontent vending?

TP = Android?

TP = Femtocells?

TP = iPhone?

All of these technologies have already landed!

Mobile 3.0 = when mostof our digital services will become mobilized

Social

Computing

TP = Social APIs?

38


38/40

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

38


39


39/40

ConclusionsRMA 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 theres 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 themobile 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 :)

39


40


40/40

Paul Golding

[email protected]

@pgolding

40
mailto:[email protected]:[email protected]

Documents

Realtime Mobile Web v02