In my last posting I was commenting on the role of IMS in the 3G era. By itself, it may not amount to much, but combined with the higher layers of interesting services, especially presence, it becomes a potential powerhouse for the nascent mobile computing market.
As such, presence and its associated buddy-list presentation is possibly the vital link to a mobile computing future, along with an ever-increasing reliance on the Internet for our daily living, which is inevitable. Information is the key currency of the modern era. The Web is evolving to provide information in ways previously unavailable and unimaginable. Broadband penetration increases and with it comes a more habitual reliance on the Internet.
The question is whether buddy-list managers (”buddy browsers?”) and Web browsers are convergent. This would certainly be a good idea as it would mean that we still have a single universal client with which to visit the information world and to interact with presentities (i.e. anything - human or automaton - that can convey its state to us and support interactive real-time communication). Imagine doing a search on contacts in your social-networking tool (take your pick) and having their presence information visible in the results and actionable (e.g. click to call, IM, push-to-talk etc.)
Currently this is not how things seem to be evolving, other than in indirect ways. There is no such thing as a buddy browser of course, but we have Instant Messaging (IM) clients. The problem is that service providers might hog the buddy browser client to themselves and lock users into a single provider-centric experience. As we know, were this how The Web evolved, we wouldn’t really have a Web would we?
Provider lock-in or not, what we need in the first place is a means to handle presentity information and communications from within the browser, giving rise to a whole new range of potential applications and user experiences whilst maintaining a universal client (browser).
In fact, the problem has already been solved to a large extent. The recent hype over AJAX has brought new possibilities to our attention. Ignoring its name and finer details, the technique allows elements within a web page to communicate with remote servers without the need to reload the entire web page. Most of the time, these embedded communications sessions take place in response to user requests. A user clicks on something and the browser passes this event to the embedded script that uses an AJAX program to communicate with the remote server. State changes happen asynchronously to user interaction, so we would need to be able to cope with updating the page elements in response to remote events. Perhaps the AJAX suite of technologies already allows that, but I don’t know.
There’s no reason why this can’t be done to talk to remote presence servers. Additionally, embedded scripts could be used to launch helper applications, like a SIP client to allow an interactive session to be established, such as voice or a video call. It is conceivable that passing snippets of XML in and out of the browser, which is notionally what AJAX does (it doesn’t need to be XML, despite the “X”) is the universal browser-helper model too. A SIP client on the mobile could allow such interaction with an AJAX program.
Of course, this approach is already present in the PC world (e.g. Microsoft’s Communicator, which is soon to be web-based) but we need to ensure that integrated browsing models are possible for mobile browsers (which Microsoft are also doing). The problem with mobile devices is the myriad underlying operating systems. For something like AJAX to work across all mobiles, the mechanism itself needs to be standardised so that browser providers can build it in. If they aren’t already, the relevant mobile standards need to embrace these new and exciting possibilities.
Buy my book (Amazon US/UK)
Join my email list
Subscribe to my “100 Mobile Product Ideas” free e-book
