Web 2.0 has given birth to huge numbers of web applications that support the way that we work and spend our leisure time. This is gradually turning users from the desktop to the internet. Providing applications through the internet enables users to access their information from almost any web browser – the concept of ‘owning’ a PC seems to be diminishing, because they’re slowly turning into generic internet access devices.

But as more people rely on the internet for access to their personal and business information, availability and reliability of access to that information becomes critical. This has recently led to a number of new products and initiatives which aim to cope with the situation when you’re not online, either by choice or because you’re unable to access the internet. The general solution is to temporarily store interactions locally at the PC, until online access becomes available. When the internet becomes available, these interactions are synchronised with the web application, and you’re back up and running again.

What tools enable this offline experience? Dojo Offline is a free, open source toolkit that enables web applications to be built with appropriate off-line functionality. Mozilla’s Firefox 3 will include off-line storage and synchronisation facilities. Adobe’s Apollo project is a multi-faceted cross-platform runtime that allows use of web technology in a desktop setting. There’s also Joyent Slingshot – a product that enables you to develop or use existing Rails applications so that they work offline. All of these are useful to have available and I’m sure in one years’ time, many of these will be used in production-quality web applications. But, you’ll have no doubt read the title of this post, and indeed, I ask the question: does offline matter?

It’s easy to answer in the affirmative: I was on a train journey a couple of weeks ago, and didn’t have internet access. This meant it was impossible to look up reference material for the Prototype Javascript library. I felt lost and frustrated – and that’s just for losing access to a website! How did I cope with this? Answer coming later.

A clue lies in David Heinemeier Hansson’s recent post suggesting that offline access doesn’t matter. There’s been a lot of discussion around this. If it’s absolutely mission critical that people have access to information when and where they want, then a web application is not the way to embody access to that information. Even if it is mission critical, there are always other ways of solving the problem: printing information out before you visit a remote area of China; buy a book to use on the train (no, that wasn’t the solution to my problem). If availability is not critical and your web applications are out of reach just use a different tool – pen and paper is wonderful stuff. Or go and do something else instead. The bottom line is, no matter how many people bellow and blog that they need access to information 24/7, the practical reality of the situation is this: they don’t.

In any case, these are solutions to a temporary problem. The internet will eventually become available everywhere with insanely great levels of up-time. Server technology and improving developers’ skills will lead to a drop in other types of service outage. What about those remote areas of the world where the internet won’t be going? Unfortunately, the internet, like other commodities, isn’t a fair resource. Users of web applications are most likely to be in the top 10% of the world’s economic locations. Shockingly, but unsurprisingly, the rest don’t matter, and it makes no economic sense to develop applications just in case they’ll be used offline. Instead, much of the move to offline access will be driven simply by competitor products moving offline.

But let’s suppose offline is a good thing. What would be the best way to provide it? Many of the current solutions require developers to write varying amounts of additional code and user interfaces to mimic the client-server experience whilst offline. This pushes up costs. Joyent’s Slingshot alleviates much of these concerns by providing platform-specific application-agnostic Rails runtimes, a customised web browser to bridge to the underlying operating system, and a bunch of Rails stuff to handle storage and synchronisation, thereby allowing existing web applications to run offline. The irony with Slingshot is that what you end up with is a desktop application as well as a web application. Mind you, it gives software developers a compelling reason to start using Rails.

Finally, let’s get back to my train journey and let me answer my question. After being frustrated with the unavailability of the internet, I went back to building software the old-fashioned way: I spent one hour thinking about what I was trying to achieve and how best to achieve it, then another two hours writing code, using comments in place of uses of the Prototype Javascript library. The following day, when I had access to the internet, and to the documentation, I replaced those comments and carried on. And it’s quite likely that the solution I ended up with is an order of magnitude better than what I would have developed had I had access to the internet on that train journey. Everyone can do with a little offline time!

Have you read CNET’s review of the SanDisk Sansa Connect (you know, the new iPod killer)? No? Please have a read now. Worth 8 out of 10? Worth a purchase? Maybe.

Now go and read another review, of the device actually being used. A different story? Maybe.

An interesting post over at 37signals suggests that it’s good to give up on a feature that’s taking too long to implement. This is a great tip if the pain of implementing a feature outweighs its value or benefit.

A better tip is to properly assess the value of a feature before starting to implement it. When you’re familiar with the environment in which a feature is to be installed, and you’re knowledgeable about the users and use of an application, you can assess such things as:

• are there other ways of achieving the same outcome using existing features?
• how often is this new feature going to be used?
• how critical to the application (or business) mission is this feature?

I have another tip: don’t even start thinking about implementing something until your customer has asked you for it a second time. (Children reading this blog should ignore this particular tip!)

I must however suggest caution with this approach: because to be able to persuade customers not to add a feature, for whatever reason, requires trust between customer and supplier. For large projects, we build trust by finding out about our customer and how their business works. The primary objective of this activity is to gain enough knowledge and information so as to be able to implement what they need effectively – which isn’t necessarily what they ask for! Indeed, we often advise on making changes to their business process, reducing the amount of work we have to do! Sometimes people get so caught up in the mindset of a ‘contract’ that they forget what they’re in a contract for.

The reason why engineers don’t want to give up is because of the perceived loss of engineering effort: their part of the pie, their code legacy. Gone forever. I’ve worked with software engineers who have been distraught at learning that their software is to be discarded – either unwanted or superseded. But they really shouldn’t have worried: it’s all history – get over it and move on.

You can apply these tips to real life too!

A case for optimisation of a job description, perhaps?

As seen at the window of an Inverness employment agency:

Answering incoming calls for technical and non-technical queries.

It’s time for our annual PAYE returns to be made. Once again, the weirdness of government websites is baffling. Today I performed three test submissions and one real submission of our returns, via our MYOB accounting software. All failed with timeout errors on the gateway. However, I then received four acknowledgment e-mails thanking me for the submissions, each of which included the text “If this was a test transmission, remember you still need to send your actual Employer Annual Return using the live transmission in order for it to be processed.” Who knows what’s worked and what’s not worked? Not me. Besides, I can’t submit all of the return via the software: P11D forms need to be printed off and posted.

Still here are two screenshots from the HM Revenue and Customs website that might brighten your day: