Tuesday, 11 January 2011

Diagramly, how we think web apps should be

I'm going to stay from the usual high level technical discussions in this post towards usability of web applications. We launched a very basic version of mxgraph.com last week that provides a fairly simple diagramming tool. I say simple, although I forget the mxGraph component does expose a large number of styling options and it possible to draw 70-80% of diagrams using the tool.

But the key point with mxgraph.com is the fact that 99.5% of it is on the client. The only things we can't do currently are save/load locally, and create images and pdfs. And we're working on images and pdfs, HTML 5 will also give us local save of sorts. So the key thing here is the built-in scalability of the solution. You might remember people talking about doing it this way 5 years ago, but so few solutions actually do. Removing the need to recover heavy server costs removes the freemium model temptation.

The other thing, in terms of mxgraph.com as a web application, is to make it look like an application. The two things web apps so often do that makes the usability painful and start-up time awful. 1) Login or registration and 2) Putting a web site around the app. I don't believe these work, plain and simple. We are going to offer the option of a Google login to store the diagrams in docs, but other than that, the idea is to provide local save/load. And we're not going to ask to login to the Google account until the points it's needed (i.e. a persistence request from the user to Google Docs).

Same for putting a web site around the app, you are simply increasing the time before the app is usable. There are constant discussions comparing web apps to desktop apps, but people seem to have forgotten start-up time. Don't click on the button to try it now. Don't register in 30 seconds to enable saving. Go to the domain, use it immediately.

Aside from all web users hate of registration, I believe people don't like other people storing their stuff. I know this goes against SaaS principles that you're supposed to offload everything remotely, but I honestly don't think this applies to data. I'm happy to put it in my Google Docs account, but I don't like the idea that service provider assume I want them to keep my data just because I use their service. Apart from being more user friendly, this decision removes any database from the architecture, we store nothing. So each server instance has no dependence on other instances or on any database or database cluster, near-linear performance still.

The last issue is the freemium model. I don't like it and I don't think it's a serious business model to target end users for small sums to add a few features to a tool. It probably creates some pocket money, but I doubt somewhat that it scales to a viable business point in the vast majority of cases. It isn't worth the annoyance it causes users being constantly reminded what they get extra for x Dollars/Euro/Pounds/Francs per month. The tools need to advertise some other revenue stream indirectly, don't do it stand alone.

These are the reasons I think mxgraph.com is actually more interesting to users than the fairly large number of Flash based diagramming sites that are mostly freemium/registration based. All we need now is you to tell us how to improve it so millions of users will flock to it to test my scaling claim.