January 27, 2008

Technologies for better web based applications: XMPP, Flex, and more

Posted in Future of Web Apps, Software at 21:39 by Graham King

The difference between a web site and an application is that an application is more dynamic, more responsive, to the user. A traditional web site is a set of pages you browse through, like an online catalog or brochure. A web application needs to be more interactive in two ways: By having a richer graphical interface, and by having real-time data.

A richer graphical interface

This is mostly done today by using Javascript. This is a good approach to start with, but your Javascript can quickly get quite hairy, and there are certain things you simply can’t do, such as interactive graphs, flexible typography, or socket connections (which matters in the next section). If you do use Javascript, I recommend the Yahoo User Interface Library.

For a richer environment that is easier to work with, and if you create a graphically rich web application in Javascript you will yearn for both, Flex is the way to go. It is a free (as in beer, unfortunately not yet as in speech) SDK by Adobe that allows you to write graphically rich and responsive applications that run in the Flash player. Flex already has a lot of traction, see O’Reilly books sales for 2007. Bruce Eckel was so impressed with Flex that he went to work for Adobe (as a consultant).

If you can accept targeting your application only at Firefox, for example for an in-house app, then an alternative is to build it as a Firefox extension.

Real-time data

AJAX has given us more responsive web applications, by allowing them to fetch data from a server programmatically. This is what gmail does to check if you have new e-mail. AJAX, or more correctly the browser XmlHttpRequest object, solves the problem of a client fetching data from the server., but it does not allow a server to tell a client that there is new data to fetch. Currently most servers will just check at regular intervals. There are currently two ways to allow the server to push data to the client.

You can trick the browser into keeping your HTTP connection connected, and receive data this way. There are many very nasty ways of doing this, collectively known as Comet.

Or, you can allow your web application to chat, using IM, with your server, or with anything else on the XMPP network. This is a fantastic way of making your app ‘connected’, receiving live data about anything you care to send it. Other people are saying this better than me, such as Matt Tucker here - a less technical summary is here.

There is an XMPP library for Flex, called XIFF. I’ve blogged some documentation about using XIFF.

Applications that just happen to come from the web

So, what can a desktop client do that a browser originated one can’t?

  • Drag and drop from the OS, for example to upload a file, is still difficult. In Firefox the dragdropupload plugin makes this easy. In IE there are some ActiveX’s. For a cross-browser solution you have to turn to Java, see here drag drop file uploading in Java. I wish Flex / Flash did this.

  • Desktop integration, such as minimizing your application to the taskbar. If you need strong desktop integration, you could use Mozilla’s Prism, or write an Adobe AIR application. In most cases launching your app from a button in the browser toolbar instead of from the OS menu doesn’t make a difference to the user.

  • Work offline. If a user is offline, they aren’t getting their e-mail, can’t get to their network shares. They will be quite unhappy. The fact they can’t access your application will likely be far down their upset list, so for most applications this doesn’t matter much. For those apps where it does matter, there is Google Gears which is wrapped by the Dojo offline toolkit. Firefox 3 also has offline support.

Let’s be sensible now

I am not suggesting you build your whole application in Flex, or that HTTP be replaced by XMPP. That would be ridiculous. What I am saying is that if you add these to XHTML, CSS and Javascript, you get a much better web application, which allows an even greater proportion of the world’s software to be web based, with all the advantages that that entails.

Yesterday: cgi-bin/submit.pl. Tomorrow: the world.

March 12, 2006

Shaun Inman - “10 reasons why you need to build an API”

Posted in Future of Web Apps, Software at 19:08 by Graham King

Shaun Inman is the creator of Mint. He gave a presentation at the Future Of Web Apps (futureofwebapps) conference, held in London on Wednesday 8th February. It was a short presentation with little elaboration of the 10 reasons, followed by a lengthy Q&A session.

An API takes a good thing and makes it better. API must not change.

API allows external extension of your application. A plugin architecture allows internal extension.

The 10 reasons are:

  • Increase brand awareness
  • Allow users to own their data
  • Build goodwill with developers
  • A perfect excuse for a community
  • Solving programming problems with an API in mind can improve code quality
  • Simplify internal reuse of data
  • Allow others to extend the functionality of your application
  • Alternate input mechanisms
  • Unanticipated applications of your data

  • Turn your program into a platform

    The initial Mint release only supported Firefox and Safari (not IE), to cut down on the support calls by only having technical users.

    See also Larsz’s mind map.

March 11, 2006

Tom Coates - Native to a Web of Data

Posted in Future of Web Apps, Society, Software at 19:45 by Graham King

This is a write-up of my notes from Tom Coates’ presentation at the Future Of Web Apps (futureofwebapps) conference, held in London on Wednesday 8th February.

Tom Coates used to work for the BBC, and has recently joined Yahoo. He has worked with Simon Willson. Tom had a highly polished presentation. Here are the notes:

  • We are moving from web pages connected by links to data connected by APIs.

  • The Web 2.0 design aesthetic can be summed up as: Rounded corners and gradient fills.

  • The future according to Tom: A web of data sources, services for exploring and manipulating data, and ways that users can connect them together.

  • Mash-up: A network effect of services. Web as a platform. Hybridization of web services together makes both of them better.

  • APIs drive people to your site, allow people to enhance your site. You don’t have to do all the work yourself. People might start charging for the user of their APIs.

  • “What can I build that will make the whole web better ?” The Aggregate Web. It’s all about data - owning, exploring, manipulating.

  • Build for normal users (the HTML interface), for developers (the API), and for machines (XML, predictable and consistent URLs and structure)

  • Start designing with data, not pages. Navigable, re-usable, explorable data.
  • Identify core objects that people will refer to. For the BBC, that’s programs, films, events, people. Then make each core object addressable by URL.
  • Good URLs: permanent, readable, and have a 1 to 1 correlation with concepts. Use directories to represent hierarchy. Predictable, guessable, hackable. Reflect structure of data. Only 1 URL for a piece of data. For example the BBC needs to have one and only one URL for a single program. That way all entries on the web will connect to that one URL, and will be connected themselves.

  • Correlate with external identifier schemes (such as ISBN)in your URLs, or coin a standard if there isn’t one. If 100 people are blogging about a film, they need to be connected somehow - if they all link to the same BBC or IMDB page, they will be connected.

  • Build list views and batch manipulation interfaces. Types of page:

    • Destination page (the entry of a film). Make XML versions of these.
    • List page (search results, lots of films). Make RSS versions of these.
    • Manipulation page (comment on a film). If needed, use AJAX / Flash here.

  • Make sure your AJAX / Flash doesn’t break your URLs. Keep it in the page. Only manipulate the concept of that page.

  • Use standard formats where possible. See microformats.org.

  • Make your data as discoverable as possible.

    That’s the end of my notes ! See also a good mind map of this talk

« Previous entries