Initially this blog was supposed to be used in part as a notebook of sort, taking notes about stuff I found on the web. Through the months I’ve somewhat drifted away from that, in good part by force of a mild pandering to the audience—the commenting audience at least—sticking with posts I know interest the readers I get feedback from. In the last couple of months I’ve managed to pretty much totally forget about stats so it’s a good time to get back to using this as a notebook. And thus, some notes (but mostly quotes) about web applications and a recent angle on building them.
Web applications are “in”
There have been a number of web application related articles lately, a few of them started after reading John Gruber’s The Location Field Is the New Command Line, it’s also where I first became aware of the talk.
The very quick, one paragraph gist of it is: Web applications can’t do everything standalone applications can but they are good enough for most people, are easy to build, can be built on free platforms, run in one place (instead of each user’s system) and are platform independant. They are what Microsoft was afraid of when it choked Netscape, are becoming more and more popular and loads of programmers are switching to this way of seeing application creation.
Web apps can’t do what real apps can
The user experience limitations of a web app are glaringly obvious. They simply don’t look or act like normal desktop apps. The browser in which they’re running — that’s a normal app. But the web apps running within the browser aren’t. They don’t have menu bars or keyboard shortcuts. (The browser itself does.) This isn’t about being “Mac-like” — it applies equally to Windows and open source desktop platforms. Instead of looking and feeling like real Mac/Windows/Linux desktop apps, web apps look and feel like web pages. [The Location Field Is the New Command Line]
But they are simple
Web Applications are easier to deploy because there’s no installation involved. Installing a web application means typing a URL in the address bar. Today I installed Google’s new email application by typing Alt+D, gmail, Ctrl+Enter. There are far fewer compatibility problems and problems coexisting with other software. Every user of your product is using the same version so you never have to support a mix of old versions. [How Microsoft Lost the API War]
Web apps run everywhere
I’ve never worked in a company that built it’s own applications so I mostly forget but one of the driving force behind platform and programming language success is that a lot of programmers work for companies on building apps that are used only internally. In those settings it’s hard to then switch to a different platform, that’s part of the reason Microsoft is so successful. Even a company realizes it’s better off with Open Source software or OS X, it not only has to change hardware, in a lot of cases it also needs to rebuild internal apps. Not so with web applications, they run on every PC with a browser.
Web apps are easier to deploy. No need to install software on each client machine; there’s just one instance of the app, on a web server. Every user gets the latest version of the software, automatically… …Custom web apps are easier to develop than custom desktop apps. That’s not to say it’s easy to make a web app that looks and feels like a desktop app — that’s not really even possible. But it’s easy to write a web app that looks and feels like a web page, which is apparently good enough for most purposes, especially data-entry and data-retrieval apps that tie into server-hosted SQL databases. [The Location Field Is The New Command Line]
You can use any programming environment you want because you only have to get it up and running on your own server. Your application is automatically available at virtually every reasonable computer on the planet. Your customers’ data, too, is automatically available at virtually every reasonable computer on the planet. [How Microsoft Lost the API War]
It’s important to note that Gruber started in this line of thinking after reading Joel Spolsky’s How Microsoft Lost The API War, which I’ve already quoted from. It’s a very thorough look into the current shift of programmers from MS led programming languages and Windows only applications towards internet technologies and web applications. He covers the evolution of the Windows API, the various languages used, some MS strategy switches and how it’s affecting the directions some programmers are taking.
The Web Is It
It’s a lot to digest and that’s only scratching the surface. The obvious trend is the key to understanding the future of computing: the web is it. Servers are becoming more important than clients. While raw processor power will remain useful for applications that need it, simple and general purpose data management — including email, scheduling and time management, office applications, and all other text and information manipulation tools — will increasingly move to a globally shared environment that makes it easier to collaborate and easier to access. The recession is over, the slump is ended. Web development is in demand, and the demand is only going to increase. [Web Apps Are Hot]
Others
Steve Garrity—like Shea and others—parallels the way web apps make sense with the way media types evolve.
Ian Bicking in turn lists some reasons why web apps are better than “classic” apps. I’m sure some were already disagreeing with the whole idea of considering a website an application but item 2 actually extends the definition even further.
They also aren’t applications because there’s no real line between the web as a publication, and the web as an application. Does it start being an application when you use Apache to serve static files? Static files generated by your weblog tool? RSS? A PHP weblog? A site with a search interface? An ecommerce site? Amazon doesn’t look much like an application. He talks about mail readers a lot, but there’s a lot of much smaller applications out there. Every dynamic website is a little application, and yet the user doesn’t have to think about this.
Building Web Apps
The next few articles don’t talk about why web apps are “in” but rather about how to build them and some concepts related to the actual work environment.
Basecamp
Around the same time all this talk about web apps was happening, some new details were coming out about just such an application. Basecamp is a project management tool originaly aimed at creatives. The people who built it, 37 Signals, put together a workshop detailing their process in creating that service and Gadgetopia provided a very informative review.
He came away from the workshop pretty excited and from the things he’s relating, I can see why.
The bottom line is that they built what they wanted to in the way they wanted to. They didn’t get hung up on logistial or technical hurdles — they just kept working towards a goal as if it was completely reasonable and normal for three guys in a shared office with no programmer to build something like this. Thank goodness no one told them they were being ridiculous.
I’m stealing the whole list of things he took away from the workshop. One of the things I like is that they’re designers and it shows in the way they approach the creation of the application.
- Develop a set of “mantras” or rules for how you want things to work. Whenever you develop something, “test” it against the rules. For instance, “less software” or “project management is mainly about communication.” Make sure you stick to your own rules and your own principles.
- Say “no” by default to any feature request. Make a feature work very hard to be implemented.
- Remember that there are significant hidden costs with new features. Besides the actual time to code there’s (1) time spent supporting it, (2) unforseen changes that result because of it, (3) time spent documenting it, (4) the overall degradation of the user experience if it makes things more complicated, etc. Sometimes, the coding time is just the tip of the iceberg.
- Start everything with the screen design. The screen IS the application. The screen drives the functionality, not the other way around. The screen design is the requirements document. (I know, I know — the hair on the back of your neck just stood on end…)
- Get something built quickly. Iterate, iterate, iterate. Release early and often. Plan a major feature upgrade within 30 days of release.
- Be honest with pricing. Clearly display the price, and avoid any hidden fees.
- Avoid preferences. Preferences can be cop-outs to tough problems. Whenever you have the user set a preference, you’re having them make a decision (Joel Spolsky’s book is big on this too). It’s more challenging to come up with a solution, and mandate it. As a result, Basecamp requires something like four fields to be completed and it’s ready to go.
Ruby On Rails
Basecamp is built in Ruby using a framework created for that project and called Rails. All coding aspects of the project were handled by David Heinemeier Hansson who participated in the workshop. You can see what looks like a similar presentation here. In it he gives a good overview of the concepts that went in the building of Basecamp as well as some of the reasoning in choosing Ruby and in building their own framework. He also offers an excellent list of ressources for Getting Started With Ruby.
Fire And Motion
In through all the links of these various articles I also read another Spolsky piece, Fire And Motion which covers some ideas about being effective at work and that could come handy in building a web application (or any programming task for that matter).
Something that sounds very much like me:
For me, just getting started is the only hard thing. An object at rest tends to remain at rest. There’s something incredible heavy in my brain that is extremely hard to get up to speed, but once it’s rolling at full speed, it takes no effort to keep it going.
On Fire And Motion:
It took me another fifteen years to realize that the principle of Fire and Motion is how you get things done in life. You have to move forward a little bit, every day. It doesn’t matter if your code is lame and buggy and nobody wants it. If you are moving forward, writing code and fixing bugs constantly, time is on your side. Watch out when your competition fires at you. Do they just want to force you to keep busy reacting to their volleys, so you can’t move forward?… …Every day our software is better and better and we have more and more customers and that’s all that matters. Until we’re a company the size of Oracle, we don’t have to think about grand strategies. We just have to come in every morning and somehow, launch the editor.
The 80% Company
This is getting further and further from the original subject but to me it’s related, especially with some of the stuff in the preceding article. Nick Denton wrote a piece a few years back called The 80% Company (I’m linking to it here but at the moment of writing his file was completely busted, hopefully it will be fixed soon) in which he said:
…this is why I intend my next company to be different. No more late nights. No more monomaniac workaholics. Less heat, more light. If I keep my nerve, I’m going to institute a four-day week as the norm. Call it the 80% company.
He details various part timer situation where it’s actually more effective to use people who aren’t totally and exclusively invested in their work, in “putting in the hours” and concludes:
So my solution: employ only 80%-ers. Close down on Fridays. That way an employer can hire people with a life outside work, and give them a career path.