Apps, Bookmarks, and the Chrome Web Store

A question we get a lot about the Chrome Web Store is the distinction between apps and sites, or “aren’t these just bookmarks”? Here is my take on the topic. It’s not necessarily the official view, just my personal opinion to help you explore the concept further.

Most apps on the store are are indeed a link to an existing page on the web somewhere; what matters is the content on that page. A successful app will be visually rich, “full-screen”, task-focused, and easy to start using. For example, a link to wouldn’t work as an app, but Amazon Window Shop does.

The fine print:

  • I suggest thinking of the store as a place where you can discover great web apps. Need a photo editor? Search for it on the store and you’ll not only find a list of apps, but also reviews, comments, and screenshots for those apps. That preview info is much more useful than just links, when you consider that each app takes time to learn and in some cases require sign-up and payment.
  • In some cases, apps already exist and are then submitted to the web store. That’s totally fine, the important thing is if it’s a good app or not. Mapnificent was an existing website, it works on multiple browsers, but was submitted to the store and has been popular with users.
  • Some apps can gain from the publicity of launching on the store at the same time as launching as a regular website, but that’s a side issue. Also, apps like GMail – which were well known prior to the store launching – seem to attract more “but it’s just a bookmark” reactions. I think that’s just an initial reaction and will go away as users get familiar with the web store concept.
  • In other cases, apps are developed just for the store. e.g. I think (but don’t have the back story), this was the case with WeatherBug’s Weather Window, one of my favourite examples of a well-focused, personalised, rich app on the store.
  • Many modern websites fall somewhere between the richness of a Mapnificent and the traditional stature of a Wikipedia (for example). These modern sites are often good candidates for apps, but just need a little UI tweaking. So the app’s manifest should point to a slightly different endpoint, which uses a different set of stylesheets, for example, which remove most of the branding and auxiliary site info (which are gratuitous since the user has already “installed” the app). It’s also good practice for these sites to support single-sign on by implementing and checking for Open ID.
  • This being the Chrome Web Store, you can assume the platform has all the latest features of HTML5 that ship with Chrome. It’s great if your app also works in other browsers too, but it’s not a requirement. If you’re using a feature which only Chrome supports, chances are it will eventually work when other browsers introduce the feature too. The important thing is you’re at liberty not to target legacy browsers (though, again, for the right kind of app, it’s certainly still worth considering web standards and degrading gracefully; but when it comes to games, for example, not gonna happen).
  • In fact, there are actually some differences between apps on the store and apps accessed as regular websites. Firstly, I’ve been talking about hosted apps here, but there are also packaged apps, which are a hybrid of an extension and an app, and they can do more powerful things like injecting content on web pages. e.g. Fiabee lets you drag images into a special “Drop Images Here” region it embeds into the page at the appropriate time. Secondly, with the recent introduction of the background feature, hosted apps also get some additional permissions.

All this helps to answer a related question: How long will it take to build an app? The quick response might be the ever-faithful “How long is a piece of string?”, but that old pearl ducks the question, so let me make it more concrete:

  • If your product is already “Thinking In Web Apps”, stick it in the store today. (You might like to add Open ID support if login’s required and Open ID isn’t supported already.) A simple way to put it in the store is Paul’s AppMator. Typical Effort: 60-120 minutes, including time to make a quality landing page.
  • If your website is already using modern features, has modern look-and-feel, etc., you will probably need to customise the UI a bit and maybe revamp some features. You might also consider making it work offline with Application Cache, but that’s not critical at this stage. Then submit your customised app to the store. Typical Effort: 3-7 days.
  • If your website is a traditional “static” website, with minimal JavaScript and so on, and you’ve decided you want presence in the store, you’ll probably want to create a brand new app from scratch. Or maybe more than one, since there doesn’t have to be a 1:1 relationship between apps and sites. It’s actually many:many; an app can mash up multiple sites, and a site could power multiple apps (e.g. an e-commerce site could yield a product browser, a shopping cart manager, a new deals monitor, etc.; each of these is a bite-sized, task-focused app,; the best kind of app!) Typical Effort: How long is a piece of string?!! Well, it depends a lot on your existing infrastucture, e.g. do you have an easy-to-use API for your services. So depending on that, and the nature of the app, it could be anywhere from a few days to a month or more.

Linux Journal Editor’s Choice Award, Development Book – Ajax Design Patterns


Just discovered Ajax Design Patterns has received the 2006 Editor’s Choice Award from Linux Journal for books on software development. It’s a personal honour, but it’s also a sign of the groundbreaking role Ajax has played in 2006.

Ajax Design Patterns, published by O’Reilly, assumes that you have a good idea of how HTTP, HTML, the DOM and CSS work (although it does help you brush up as necessary), and it shows you how to combine the basics into sophisticated applications. You can almost think of it as an Ajax cookbook, but with the underlying theory and advice that you need to make interesting applications.

Thanks to Jason Salas for passing on the news (Jason followed the book’s progress as it evolved and recently wrote a positive review on his blog.)

How Much Docs?

Nate’s talking about functional specs.

How much doco happens on a project is one part opinion and one part “what do you want to optimise for?”. I generally find there’s a dichotomy in attitude to software documentation.

1. Definitive (aka normative, exhaustive, complete, bureaucratic, rigourous, formal). The ideal here is that everything should be covered in documentation – the docs are a snapshot of every activity, plan, and state of the project. The aim is: (a) to let you carry on unhindered if “(stakeholder/worker) is run over by a bus” for all instances of (stakeholder/worker); (b) affect payments and provide legal evidence/cover. 2. Informative (aka agile, pragmatic, informal, half-hearted). Use docs pragmatically, to help explore ideas, reach consensus, remember what we said, etc. You cannot reconstruct a project from docs like this – if everyone is “run over by a bus” at the same time, there will be a delay and a subsequent divergence in the project direction.

That’s a clear distinction – in the Informative mindset, the docs are only there to reach a better quality result; in the Definitive mindset, we’re compromising some productivity for the sake of risk management (both (a) at a tactical level, i.e. if someone leaves; and (b) at a strategic level, i.e. upper management can theoretically be comfortable about how much is exposed and how much they’ll get back as a penalty if things slow down, etc.).

Both Definitive and Informative have a range of approaches. In particular, Informative use of docs can range from none at all, up to a project resembling a Definitive project, but when you look closely, the docs are lightweight and only subject to informal reviews rather than full-on inspections and audits. They may also the use of less conventional “documentation”:

  • Whiteboards
  • Post-it notes
  • Flashcards
  • Wikis and blogs.

As an agile proponent, I’d generally favour the Informative approach, but software isn’t developed in a vacuum. Organisations understandably want to be reassured about what gets delivered, which pushes them to rely on Definitive methods. The problem here, of course, is that Definitive-style docs require an almost impossible task of pinning down requirements, and furthermore, fixing requirements runs counter to the modern organisation’s goal of being agile.

There’s obviously no one solution, but one essential ingredient comes from multi-talented people. Too often, requirements are penned by business people on the assumption that software developers are left playing with their compilers. That’s changed a lot over the past five years, and organisations will do well when they hire business people who have an interest and competency with software, and software developers (fast becoming the majority) who can empathise with the business’s needs and are actually literate as well.

(I hope it doesn’t go unnoticed that Software As She’s Developed has actually posted about software development. That’s so ’04.)