Mobile Ajax – more than a pretty face

pretty.jpg

(

Note One : I would be interested in hearing and blogging about your company if you are developing Mobile Ajax applications and to brainstorm/elaborate the ideas in this blog. Please email me at ajit.jaokar at futuretext.com if you are doing something interesting

Note Two : In response to Patrick’s comment on my blog below (Update): Why focus on a specific technology like Ajax? Actually, I am not focussing on a specific technology like Ajax. I am however focussing on Open Standard Web based technologies that foster rich internet applications. To me, the Web is more than the Browser. For example, at least Widgets and RSS (in whatever incarnation it gets standardised by the W3C) are important. Thus, Ajax for me, is a way to provide RIA (Rich Internet Apps) using Open Standards but it is not the only way.

Note Three : An example of taking a programming only view can be seen at Tom Hume’s blog (I have a lot of respect for Tom’s views in general – but I am using this to illustrate my point) Tom quotes (not his own blog) : AJAX on the web is a hack, every developer knows it’s a hack. That ignores the bigger picture and looks at it from a purely coding perspective. In contrast, the blog he is quoting from by Mike Rowehl is more comprehensive but it also does not make any reference to the architecture. In general, the impression one (wrongly) gets is ‘Mobile Ajax’ is like ‘Using Ajax on a mobile browser’ and I am saying that: That’s not the case. You need a different architecture and we need to take a more strategic view. By the way, it is independent of where the application could be deployed(at Carriers or at service providers or even Corporate as I discuss below)

)

Today, I spoke at the Mobile User Experience conference organised by Osney Media

This was a gathering of folk interested in Mobile UI, more used to traditional Telco WAP/SMS applications than some of the Ajax driven Rich Internet Applications becoming increasingly common on the Web

This blog is in response to a question from the audience.

I promised that I would blog about this topic because I had a meeting to attend to afterwards and had to leave immediately after my session (sorry Ben/Vicki – feel guilty coming for lunch, attending my session and then off immediately – but I hear it was a good conference! Will see more of it next time round ..)

Anyway, .. In my talk I mentioned that Mobile Ajax was more than a pretty face.

I subsequently said that many (especially people from a programming background) – take the definition of ‘Web Ajax’ literally and apply it to Mobile Ajax ‘as it is’. This means looking at the Ajax acronyms (XHTML, Javascript, XMLHttpRequest etc ) and then extrapolating them to Mobile devices

This is very limited thinking .. because it excludes something else that is missing in a mainstream Mobile Ajax application.

That ‘something’ is ‘Cloud computing’

Cloud computing is a term recently popularised by Google CEO Eric Schmidt . This rather long Wired article gives a fascinating insight into this new computing paradigm of Cloud computing summarised by

The desktop is dead. Welcome to the Internet cloud, where massive facilities across the globe will store all the data you’ll ever use. George Gilder on the dawning of the petabyte age.

By more than a ‘pretty face’: i.e. much more than the UI.

Since Soonr is the best example of the use of Mobile Ajax, I shall discuss these ideas in context of Soonr

(As I said, if you are working on something interesting in this space, please email me). I have blogged about Soonr before - so I am not going to go into details of the application itself.

Conceptually, the Soonr application does something quite simple i.e. it allows access to files on your desktop.

By virtue of using Mobile Ajax, it already benefits from a good UI, open standards (non proprietary technology) and the benefits of browser based application deployment

However, if we look at only the ‘Mobile Ajax’ component, we are missing out far more because what makes the Soonr application interesting is: it combines the UI and data management capabilities of Ajax with Cloud computing with other technologies like transcoding

Some of these technologies (like transcoding) have been around for a long time (as I recollect, even as early as 2000/2001) for example this company but these applications never worked in practise. Today, we have the entire Cloud architecture and transcoding, image panning etc are merely components in the bigger picture

For example, a word document on the desktop could be converted to a jpeg and stored in the ‘cloud’. It could then be deployed optimally on the mobile device including features like zooming/panning etc.

cloud.JPG

The results are very powerful.

And that’s what I mean by ‘more than a pretty face’ i.e. if you look at it only from a programming perspective or from a UI perspective ignoring the architecture – then you are missing the whole point!

A secondary consequence of the above discussion is: Mobile Ajax could be well suited for corporate applications (security/permissions etc could also be managed at the middle tier)

Corporate mobile applications is where the action is at the moment and this scaleable(and relatively cost effective) architecture will benefit from the moves Google and others are making in this space (Will Google cloud displace Microsoft) .

For instance: Motorola acquired Good technology in this month . Nokia acquired Intellisync also in this month.

These moves are all going for the hallowed Blackberry market.

In that context, the corporate incarnation of Mobile Ajax becomes very interesting because the pieces are there and they are cheaper and cost effective to deploy (because browser based/Open standards etc etc)

The paradigms used here are also actually not new. If you follow the architecture of BEA Tuxedo and more earlier IBM CICS (no I am not that old! I had to ask someone about CICS – but I have worked with Tuxedo at PeopleSoft (now Oracle)) – the ideas are very similar BUT with a ‘Web’ hat on

Some of these ideas above need more elaborating(for instance the corporate role of Mobile Ajax in light of recent moves by Motorola and Nokia) but you can see what I mean by ‘Mobile Ajax is not just a pretty face’ .. If you miss out the architecture, you are missing the whole point!

Image source: cecm . The site is in Brazilian/Spanish – so not quite 100% sure what it is about – but I know a pretty face when I see one :)

Comments

  1. alan patrick says:

    Re Cloud Computing:
    What no-one has explained to me satisfactorily is what do you do when all services and data are remote webservices and the umbelical cord is cut. Murphy’s Law still operates in cyberspace!
    Churlish to point that out I know, but its the first question any risk analyst will ask :)
    Re Mobile Ajax…..its not useful getting too attached to any one language / syntax / whatever, especially in Mobile as it still embryonic as a real ‘web’ service platform.
    Read “Hackers and Painters” by Paul Graham, there is a wonderful essay on why they used the obscure language LISP rather than the “obvious” choices of languages at the time (C, Java) to build their web app business.

  2. Alex Kerr says:

    I think as Ajit says the actual technical implementation that evolves to become the standard used for AJAX on phones is not important for the big picture, it’s the whole notion that counts, i.e. including the structure, user interface etc. Technically I think the phone end of the equation needs more access to the phone OS functions and hardware than it currently has, but there is no reason why this couldn’t be open standards based and part of the phone OS.
    Speaking of clouds, I think an exciting development on this front are Amazon’s S3 storage service, and Elastic Compute Cloud (EC2). This radically lowers the boundaries for small and large vendors to deploy web applications to a great many users worldwide. Amazon will not ultimately be the only provider of this sort of thing, but they are certainly leading the pack at the moment, and as a developer I am actively investigating using these services in a commercial context.

  3. Alex Kerr says:

    Forgot to add that on a more comical note, the face pic at the top has a distinct air of Michael Jackson about it! ;-)

  4. Kathryn says:

    it looks like michael jackson

  5. zahadum says:

    @ alan patrick: yes, we should not confuse the concept with the execution … but ajax is NOT committing the design sin of hard-wiring, so it can respond to its environment (which meets the the cohesion/coupling metric).
    to caution against being locked into the ajax architecture is like saying the you cant use the MVC pattern for everything: it is trivially true but mostly irrelevant, since each of these is the best general-purpose solution to the problem domain to which each belongs!
    … however, you pretty much disqualify yourself from any serious consideration when you describe LISP as an obscure language that was not an “obvious” choice for graham’s back-end portal.
    * first, LISP is a /famous/ language which is just as significant as any of the ALGOL-style languages …
    it has been a lynch-pin of all serious computer science curricula
    for DECADES!
    in fact, if your designer or architect does not already familiar (if not actually fluent) with functional languages, then you pretty much know that you have a loser on your hands. STAY AWAY FROM HIM – cuz this guy chases fads & does not know how to learn from past mistakes (ie the kind of wisdom that drives the pattern community).
    if some has graduated from compsci (not sw engineering) without being to demonstrate a meta-circular interpreter, then you can reliably assume that he will never understand the /internal logic/ of any business problem he is confronted with.
    * second, ‘popularity’ is NOT the correct criterion for selecting a language! …. SUITABILITY to the task is what you want!
    and LISP would be the “obvious” winner (hands-down, no-brainer) for a /parsing/ job, which is what Allen’s back-end portal had to do.
    here is a rule of thumb that over-simplifies the bad as well as the good: crunching goes to APL (not fortran) :: parsing goes to LISP (not C).
    more generally, basically, relational problems should be handled by relational languages (prolog & descendants); functional problems by functional languages (LISP, SCHEME, ML, Haskell); imperative problems by message-passing langauges (ie oopl like Smalltalk/ObjectiveC) … and all three styles should be MIXABLE!! so that functionals can also have objects or relationals can also have functions or objects can also have relations/functions etc (eg OCAML or datalog or lambda prolog etc).
    moreover, any one properly trained compsci should be to emulate any one of these language idioms as a programming /style/ within their (other) language of choice! — eg all the brilliant examples of how to program an an object style from within LISP:
    http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-19.html#%_chap_3
    http://www.lisp.org/table/books.htm
    the lesson for alan patrick: when offering advise, it helps to actually know what you are talking about, and over-generalizing is just as bad as over-simplifying!
    so, while ajax might not solve every web problem for SOA (ie you should start with robust back-end in WSDL-based api’s), it is not a bad place to start!