Time to Redefine the Browser

5:30 PM -- There is no more important debate in wireless than whether wireless Web services will replace the thick-client/local-applications model that represents the logical evolution of the computer itself. I’m going to continue to argue that we want to move towards Web services for reasons of cost, management, and flexibility. While we might base further mobile platforms on real operating systems, and this appears to be the likely direction, all we really need to support is a big browser, a local Web server, some caching functionality, and maybe a little more. But there should be no need to port most applications to every mobile device -- that’s both expensive and impractical.

And this brings me to the most critical piece of local software, the browser. Now, “browser” is an increasingly inaccurate and inappropriate term. The modern browser is more analogous to the “intelligent terminal” of yore -- the DEC VT-100 and the IBM 3270 come to mind here. While these were hardware, of course, the important part was the API defined for each. This allowed applications to be run on any terminal that was compatible.

A similar challenge awaits us today. First, we should redefine the browser as an application interface. I’m still thinking about the right term for this. And we should finally standardize the browser itself, with an ANSI or other standard. Vendors should stop competing, by changing the API to the browser. I’m not a browser expert, but I have run across a grass-roots organization working in this area -- the Web Standards Project . I don’t know much about them, but I already wish them well.

— Craig Mathias is Principal Analyst at the Farpoint Group , an advisory firm specializing in wireless communications and mobile computing. Special to Unstrung

artr 12/5/2012 | 3:01:59 PM
re: Time to Redefine the Browser I think you are starting to get close to the truth about interfaces, i.e., it's all about the flexibility of the devices to handle any application and in any modality of communication. This lets users choose what interface they want to use at any time for a given application, without the application having to do anything about it.

Its very much what I have seen as being the value of Unified Communications. UC lets the individual user communicate independently of other users. In particular for messaging, the sender sends messages the way they want to, while the recipient responds the way they want to. That's flexibility that facilitates work flow efficiency and minimizes user frustrations.

A case in point is the use of speech recognition to knock down the traditional barrier between the telephone caller and the recipient. While it was very convenient for the caller to leave a voice message, it was a real pain for the recipient to retrive and manage a voice message. Now the callers can still leave a voice message, but who says the recipient really has to listen to it so inefficiently? Now, they see it in text form, just like email, which is way more manageable and efficient tyhan voice.

So, is that what a browser does with information access or via a business process application? I don't think so!


Art Rosenberg
The Unified-View
(310) 395-2360
AllKindsOfThings 12/5/2012 | 3:01:25 PM
re: Time to Redefine the Browser Hi There,

With regard to interfaces it might be interesting to have a detailed look at the ecosystem and stakeholders creating the software stack in whatever devices we are talking about.

Its certainly true that some simplification is required that hasn't bee addressed in a good way - mobile devices and their system, library, driver, application and presentation layer are simply a MESS. The JSR process has not helped much, due to the rather weak compatibility of many results and too much room for interpretation, leading to far too many incompatible implementations across the board.

Browsers have long lost their focus of just being an simple interpreter for presentation describing mark-up and are a MESS themselves as well, where everybody mixes in their own way of "smartness" and embedding of APIs, Libraries, Plug INs.

I like the idea of a clean up of the Mobile Handset stack very much - but who can actually perform it?

In the mobile world there seems to be a stand-still in creating a unified communication client that is functionally attractive enough to compete in its usability - in part as a result of an ecosystem self-blockage.

Instead of agreeing on something meaningful and interoperable over the last some years, folks have made quite small inroads towards anything that offers a real vision of an integrated service suite that could be broadly deployed.

The fact that a handset vendor like Nokia somewhat caved in context of OVI by starting to push clients and services of Microsoft feels a bit like a declaration of bankruptcy - at least with regard to the ambitions of one of the major players with some power to support defining a Handset Software Stack and creating a competitive client suite.

If I was head of Nokia Siemens Networks, I would strongly ask myself, who will buy my enabling backend platforms if this is rolled out as a general scheme... When the handset division replaces everything the embedded clients could talk to by the MSN Service and Enabler stack - where does OVI go? The service enabling division then retreat to "radio access enabling only" real soon?

TodayGÇÖs Mobile Equipment and Service Industry would probably do themselves a great favour if they found a way to define a truly interoperable approach (ideally also interworking) for a software AND service stack that is truly competitive - else GYMAS ((the group of the five usual suspect ISPs - Google, Yahoo, Microsoft. AOL/ICQ, Skype/eBay) will split up the service and enabling market among themselves...

@Art: As to your comment, I share the view that offering a good choice of useful communication options is a requirement, I however struggle with the notion of "communication independently from other users".

Maybe you could outline this a bit more. Please apologize where I might misunderstand this, as I am sure you would consider it obvious that - as communication depends on a recipient - none of it could ever really ever occur in a single ended way.

So, no matter if we consider traditional face to face or remote communication methods - interoperability of the chosen method is mandatory to succeed in an communication attempt.

As long as the service suite at hand is not interoperable with my communication party at the receiving end, it does really not matter what I send.

Many new services fail because they focus on inventing something totally new and ignore creating a migration path or continuity model.

Technology innovation seems to run so much quicker than the proliferation of the knowledge how to actually *best* use all the new communication options - most people on this planet are still early in their learning curve with this regard and have more choices than they can handle.

All the Best!
artr 12/5/2012 | 3:01:04 PM
re: Time to Redefine the Browser I agree with your observations about the industry's progress in making everything interoperable across all technology boundaries. Your concern about making contact recipients accessible to contact initiators can be helped by making them more modality independent when it comes to communications.

This will be especially true for asynchronous messaging, but will also be practical for real-time contact now that IM is becoming more popular. So, for example, a message originator can create a new message in any form that is convenient and address it to a recipient (NOT just a particular mailbox address associated with the message content format). The recipient will be notified in whatever format is appropriate, real time or not, and can retrieve the message in any format that is convenient or appropriate.

The old telephone answering game of voice is an old example, where a caller ends up leaving a voice message when they can't have a voice conversation connection. The reverse was also true for some voice mail systems where the response to a voice message could be a "call return," if the sender is accessible for call.

The cross-media approach to messaging is now moving from simply enabling text messages to be retrieved in speech by phone (old "unified messaging")to gaining traction as "visual voicemail" or "voice-to-text messaging," where voice messages are converted to text and sent as text emails (as opposed to being simply wave attachments to an email. The benefit there is because a text message is a lot more efficient to manage than managing the retrieval of voice messages (even with speech commands).

While voice messages allowed "call return," email didn't, but now both email and IM are able to respond in voice, as calls or voice messages. So, all this flexibility will enable a contact intiator to use presence intelligence to intitiate a feasible contact, regardless of what the recipient wants, and, vice versa, the recipient can control their accessibility, regardless of what the initiator wants. The bottom line is that people will more quickly be able to successfuly communicate in some form, independently of what the recipients prefer or can actually do at that moment in time.

Obviously, if a real-time conversation is needed, both parties need to be accessible and able to talk, and sometimes that may need to be a scheduled appointment, or, what I have termed an "ASAP" (as soon a s possible) arrangement.

To gain such practical flexibility on the part of all users, what we will need is universal adoption of flexible, multimodal mobile devices that are interoperable with any other device across any network.

Hope that clarifies my vision, which will indeed take time and effort to become a reality.