Mobile Web Evolution - Rich Mobile Applications and Real-time Web UX

Mobile WebEvolution:

Rich Mobile Applications and real-time

web UX.Paul Golding

@pgolding

Anarchitect’s guide to Rich Mobile

Applications (RMA).

(C) Copyright Paul Golding, 2008

July 2008rev 1.0

2

Designed first ever mobile internet portal - Zingo (1998) [Lucent, Netscape, Spyglass...]

Mobilist since 1990 (many GSM patents)- set up the mobilists groups on LinkedIn and Facebook

1990-date: Worked on mobile tech/apps on every continent (operators, vendors, start-ups, VCs...). MIDP 3 Expert Member.

Most recently Motorola’s Chief Applications Architect for mobile applications and Mobile TV/IPTV applications. Ran their mobile ‘Mashing Room.’

Designed numerous mobile apps and platforms, including various mobile social networking services, especially using location and video. Architect of ThumbJot (social jotting/ideas tool for iPhones/Web 2.0)

Author “Next Generation Wireless Applications” (2nd Edition)

@pgolding


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 (RMA).


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

4

Real time is a key attribute of the ‘mobile experience’ - it is what mobile is all about.


Mobile Browsing?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 mostly a poor UX but 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.

Next phase 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.)

5

‘Always browsable’ is not the same as ‘always on.’


Full, Cut Down or both?

Emerging ‘iPhone design pattern’ increasingly common:

Cut-down web for optimal mobile UX - very prevalent with iPhone sites

Full-web for non-essential functions (e.g. FAQs, blogs etc.)

Downloadable app that essentially mimics the cut-down web UI, but enhanced by: faster UI response, some offline functions, but mostly location and photo APIs

6

Designed-for-mobile web is different from mobile web browsing.

Some sites will not design for mobile web and just fall back on the availability of mobile browsers that can browser the full web.

Currently, this is a far from ideal UX and not the trend of sites serious about engaging with mobile users.


The browser trends...(C) Copyright Paul Golding, 2008

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

Offline storage

8(C) Copyright Paul Golding, 2008

Widgets and Offline...

Widgets support persistence by allowing the web application to always be running and always be visible (in some way) to the user.

Offline supports persistence by allowing (a copy of) web-bound data to be accessed and updated in real-time


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

10

There are some challenges:

1. Battery life2. Data sync.3. Widget visibility (concurrency) on small screens


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


Trend 3 - Browser APIs

Open AJAX mobile APIs

Telephony, messaging, address book, location, camera, media etc.

Note - most browsers already support embedding of phone numbers (OMA)


http://www.openajax.org/member/wiki/OpenAjax_Device_APIs_Modules

http://www.openajax.org/member/wiki/OpenAjax_Device_APIs_Modules

Trend 4 - embedded web

Making the web browser a component accessible natively - e.g. Qtopia, Android [But these aren’t yet widespread, like Adobe Air will probably be on the desktop]

Client-side “mashing” possible, not just between web apps, but between web and native apps/data stores e.g. address book that could include dynamic Facebook data

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.

13

We could use native environment to support data push models besides COMET, including XMPP/SIP, if required. However, we still need an ‘application layer’ standard for asynchronous messaging to mobiles.


Trend 5-MIDP Bridging

Ability to access helper applications within the MIDP 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 bridging discussed as part of Fennec (but activity unclear)

14

We could use MIDP environment to support data push models besides COMET, including XMPP/SIP, if required. However, we still need an ‘application layer’ standard for asynchronous messaging to mobiles.


Trend 6 -Helper Functions

Use of native phone applications to support the browser

Classic 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


Trend 7 - Javascript

Faster performance (e.g. SquirrelFish in Webkit)

Richer libraries

Javascript could also be used to support inter web-app communication pathways

Will Javascript become native to mobiles anyway (e.g. JavaFX Script)?


The ecosystem trends...(C) Copyright Paul Golding, 2008

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


Web 2.0 Trend -Microformats

Data formats that make data more portable between web applications

Makes ‘storing in the cloud’ more of a commodity service

Opportunities to move more mobile data into the cloud, keeping it open and portable.


The Cloud

Moving “Phone” data into the cloud

Phone Data

Open API

skype Truphone Others

Browser

“Phone” APIs

Store

Text messagesCall records

Address bookDivert status

MMSetc.

User’s mobile phone usage is reflected back into the cloud into an open platform. It can then be subscribed by other services enjoyed by the user - e.g. Skype, Truphone etc.


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


Value of the Social Graph(C) Copyright Paul Golding, 2008

Value in forming the links - gravity/stickinessValue in what you do with the links - e.g. services

Value “because of” the links - e.g. advertising


Mobilizing the graphMessaging (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)

23

=Mobile is the ultimate

connector!


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)

‘As I think’ updates - e.g. ‘jotting at the speed of thought’ (thumbjot.com)


RMA before RIAWith the aforementioned mixable/mashable aspects of browsers with native apps, a Rich Mobile Applications trend 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


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.


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


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


Web 2.0

Mobile Network

ImplicationsPhone

Browser

Media Player

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

Othere.g. Camera

Web 2.0

Mobile Network

Browser

Media Player

Othere.g. Camera

Phone Phone

Today Tomorrow


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?

31

Rosenberg’s SIP vision:

“It should be as easy to create a new phone service as building a web page”

p.s. notwithstanding creation of a new walled garden


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?

32

Conveged SIP/HTTP already possible server side (e.g. with J2EE containers)

SIP model deliberately based on HTTP, though some “program model” differences

Various embedded approaches possible, such as invoking webkit API from a SIP/SIMPLE handler/wrapper.


Operator trend - Mobile TV

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


Other opportunity - Home Networks

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


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


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


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 :) 37


Thank you

Paul [email protected]

blog.wirelesswanders.com

Follow @pgolding


mailto:[email protected]

mailto:[email protected]

Mobile Web Evolution - Rich Mobile Applications and Real-time Web UX

Technology

Transcript of Mobile Web Evolution - Rich Mobile Applications and Real-time Web UX