WebStart and Web Browsers

I posted the previous post (JDNC and Rich Internet Applications) to the JDNC forum and got a timely and well-considered reply from Mark Davidson. It has made me realise that I have completely failed to articulate what I find so attractive about the browser metaphor and, by extension, my perception of what a RIA should be.

RIA is an acronym I saw first used by Macromeduia in conjunction with its Flex product. But I have seen it more generally used by those with a server-side Java perspective, trying to describe what are essentially web applications but with a richer interface. There are a variety of technologies for doing this but most share a common architecture. Rather than delivering HTML, the server-side is responsible for constructing an XML payload (which typically includes both declarative and procedural elements) that is delivered (sometimes via a proxy) to the browser. The browser (or a plug-in hosted by the browser) then presents the application to the user.

To recap: as a server-side Java developer I swap all the capabilities of the user's browser (its handling of D/X/HTML, CSS, DOM, Javascript, plugins...) for somebody's proprietary XML dialect and hope for the best? Perhaps - if the company is big enough and has the resources and is spending the time (Microsoft, 2006+, XAML anybody?). If I had to categorise WebStart I would have to put it into this camp. The differences are that it is honest enough to do away with the browser and Java provides a hugely rich environment.

If I look at the applications I use day-in/day-out, there is a spectrum to how complex and interactive they are. What I am struck by is how many of them are now 'browser-based', despite all the compromises that must bring. Obviously this is also a matter of taste, but I am with those that do not believe that the browser has reached the end of its development. For the record, here is a list of things I use a browser for:

  • browsing ;-)
  • blogging (Blogger & Bloglines)
  • documentation/design (Twiki)
  • bug tracking (Bugzilla)
  • filling out my tax form (something from the UK tax office)

...and here is a list of things I don't do with a browser:

  • email (Outlook)
  • music (iTunes)
  • cutting code (Eclipse)
  • presentations (PowerPoint)

Obviously I don't always choose a browser-based solution for its user-interface. For example Bloglines has the advantage that it can keep track of what I've read, irrespective of where I've read it. Many of these browser-based solutions would benefit from a richer user-interface. Blogger, Twiki and Bugzilla would benefit from some form of 'text-editor' component, Bugzilla from a 'table' component and Blogger from a 'calendar' component.

There is an inherent attraction of having a number of browser-based applications; they can be seamlessly tied together. Its not just because its trivial to put a link on a page, but also because these aplications live in the same environment and follow the same rules (eg I can go back to that page, I can bookmark it, I can send a link via email, I can open it in a new tab). Finally browser-based applications often just plain look better. In an application where most of the information is read-only, the ability to easily control how that information is rendered is a big plus.

My problem is what is the way forward for a Java developer who wishes to offer a richer user-experience while retaining the benefits of a browser-based solution?

Comments

Post a Comment

Popular posts from this blog

A Review of hReview

microformats may well represent a path from where we are today to the [lowercase] semantic web. If so, one of the first waypoints along such a path could be the emergence of aggregators capable of taking advantage of suitably marked-up content. Applying a 'microformat' approach to tagging, Technorati introduced the rel="tag" approach to marking-up tags. Technorati also supply the corresponding aggregation service, e.g. see posts tagged with microformat . Given this minimalist approach to tagging, the hReview specification comes as something of a surprise. It seems to represent a format developed independently of the environment in which it is most likely to be used. The rel="tag" approach makes a major, simplifying assumption. This is that the tag refers 'to a major portion of the current page (i.e. a blog post)' . I am assuming that it could apply equally to a blog entry in an RSS/Atom feed. Thus an aggregator can associate a tag with two p...
Read more

SmartLink

Image
In a previous post I tried to describe how I thought technologies like SmartTags and AutoLink ought to behave. With greasemonkey in Firefox I've been able to build a proof-of-concept demonstrator. For the moment I'm calling it Smart Tag/Auto Link. SmartLink is based upon the idea that content authors should mark-up content that can be 'smart-linked', using standard XHTML constructs. This has two advantages: it effectively provides an 'opt-in' mechanism for content providers it doesn't require 'magic' to identify what can be smart-linked and thus provides a much more extensible approach. of course there is one fairly major disadvantage: there isn't any suitably marked-up content out there, with the exception of some test posts I've put together for the purpose. Getting Started If you want to know a bit more about SmartLink then click here . Alternatively if you want to see how SmartLink behaves and you're using Firefox t...
Read more

Google I/O 2013

With Google I/O approaching it is time to start speculating... Last year the keynotes at Google I/O were very different in tone; the one for Android and the one for Chrome OS. It will be interesting to see if there is any big change this year, now that Sundar Pichai will - indirectly - have a role in both. Google's commitment to the web and the evolution of Chrome has taken them to an extraordinary place.  Soon it will be possible to develop apps using standard web technologies and deploy them to a wide range of environments; desktops running OS X, Linus or Windows as well as Chrome OS. There seems to be a genuine desire to get Chrome apps to play nice in their host environments, not just within the browser. For example the launcher that was part of Chrome OS now has a variant in some desktop environments. The Chromebook Pixel has a touch screen, so developing Chrome apps for a touch interface is clearly on the agenda. So isn't it about time for Chrome apps on Android...
Read more