My dad sent me an article recently about some sort of software package that (assuming I read the article correctly, it was pretty dense) allowed you to develop web applications that were more extensible by the user, thus presumably moving web apps closer to traditional desktop applications in terms of functionality. That sparked a return email tirade over why I think that’s stupid. When I was done, it occurred to me that it would make a decent blog post, so here it is.
Take any modern application, say Microsoft Word for example. Word has several features I use all the time and a shitload that I never use. Some of what falls in the latter category is on the toolbar by default, and some in the former category are not. For instance, I do cut-and-paste operations pretty much exclusively from the keyboard, rather than use the mouse, so the cut/copy/paste buttons on the toolbar were wasted space, so I removed them. I use footnotes all the time, but there was no button, so I added one. I also use basically three fonts, so I removed the drop-down list of 7,491 mostly irrelevant fonts and replaced it with three small buttons. Extending that idea, you can write macros that handle functions you do all the time, and then you can assign a button or a keyboard shortcut or whatever. Whenever you are doing any of these things, you are customizing the software - maybe just the interface, but often you are customizing the functionality as well - to suit your needs.
With the recent “Web 2.0″ craze, “web applications” have become all the rage. In the “old days” of the web, you would go to a web page, click, wait, and then see a new page. Web applications attempt to do away with the click-wait-reload cycle by reacting much more dynamically. Since the web “page” reacts much more quickly, and the interface and the data change fluidly as you make changes, it behaves more like an application than did traditional web pages.
Take PeachForms, for instance. At its core, there is a GUI where you input data, which is saved to the database on my server. If I was developing this thing five years ago, the model would be: (1) fill in the data, (2) click a button, (3) wait for the data to be sent to the server, validated, and possibly stored (assuming validation), (4) if there was a problem, reload the page to notify the user, who would then fix the problem and repat steps 2-4, (5) page eventually reloads letting you know all your data validated and was stored, and you can move on to the next step. Now, thanks to “Web 2.0″ technologies, the model is (1) fill in the data, one section at a time, (2) the data is validated and saved in the background, one section at a time, as you move to the next section, and (3) you can literally get from zero data to finished product without a single page reload. It behaves much more like an application than a web page, which is pretty cool.
Now, the point of this article is that one thing that has been lost - and which this “NetSuites” product apparently attempts to remedy - is that ability to customize the interface and/or the functionality of the web app. In other words, one alleged drawback to using a web app instead of a traditional app is that you cannot change how the web app works for you. Sure, the developer may have built in some customizability (e.g., the ability to change some of the colors), but fundamentally you are still locked into whatever “options” the developer wanted to support (which is typically a fairly limited set). So if in using PeachForms some user prefers for the calculator to be located in the bottom left corner instead of the upper right corner, tough shit, they can’t make that change. Supposedly with this product, the ability to make these kinds of tweaks to web apps would be introduced.
The problem is, that’s bullshit. Web apps are not meant to outright replace traditional apps in 100% of situations. A web app should address a particular function and a particular situation. It should be narrowly tailored to do a particular job and do it well. If you as customer think changes need to be made or functionality needs to be added, then you pitch those changes to the developer. A developer who is focused on supporting a system which is designed by its very nature to support changes the developer may not even be able to conceive on his own is a developer who cannot focus on properly implementing needed functionality.
The other thing is, I’ve been around long enough to realize that “more options” is not necessarily always a good thing. Suppose my software needs to do a specific thing on a weekly basis, but it can’t happen earlier than Monday at 12:00 noon or later than Friday at 5:00 pm. I can code something that will allow the user to designate any day/time he wants right down to the second, and then I can validate his submission to make sure he fits within the appropriate parameters, and force him to make a correction if necessary. Maybe the guy was in a hurry and accidentally clicked Monday at 9:00 a.m. instead of 9:00 p.m. - no big deal, but it’s annoying for the user to have to do the same thing twice. Also, notice this phenomenon - this example is clearly user error, but is the user pissed at himself? More than likely, the user is annoyed at the software for being too cumbersome, ignoring the fact that if he hadn’t fucked up in the first place it would have worked just fine.
Now imagine I had made a command decision that you could pick Monday at 9:00 p.m., Tuesday at noon, Wednesday at 3:00 p.m., Thursday at 7:00 p.m., or Friday at 2:00 a.m. You can’t fuck that up - you’ll pick one and move on, and your choice cannot be invalid from the software’s perspective. It may be that your ideal time isn’t an available choice, but more than likely you’ll adapt to the one that’s closest to your need. If it’s important enough to you, you can make your case to the developer, and if your point is well taken a good developer will consider making a change. My point is, by limiting your options in this regard, I have actually improved your experience with the software. I did this with PeachForms - your options are to have a 1″ margin on both sides (for regular paper) or a 1.5″ left and 0.5″ right (for redline paper). It would be almost impossible for me to support allowing the user to pick his own margins - inevitably some douchebag would try to have 3″ margins, break the damn thing, and then badmouth my product for being too rigid and unresponsive to the user.