Adam @ Bitscribe

In my last post, I said that Firefox is “the best thing that ever happened to the web, maybe even the best thing that’s ever happened to software in general.” This off-the-cuff remark seemed to generate more buzz in the comments and on reddit than my main point.

xkcd nailed the issue with perfect humor. Everyone’s going crazy for Firefox, but come on - it’s just a browser. Right?

Well, yes and no. Yes, Firefox is a browser, and in many ways only an incremental improvement over its immediate ancestors like Netscape, IE, and Opera. But it’s also much more than that. Firefox is the enabling technology in a whole new world of software development.

I doubt I need to expound on the virtues of web applications over locally installed apps to anyone that is reading this. But really though, take a moment and think back to what software was like before web apps took over. Incredibly long development cycles, endless installation headaches, viruses, hardware and operating system incompatibility. Being forced to develop with whatever language(s) and tool(s) are available on your end user’s operating system was once the norm, and it gives me the cold sweats just to think about it now. And CDs, in a box? We were such barbarians.

In short: desktop apps sucked. They sucked to make, they sucked to use, and they sucked to support. I’m giving myself ulcers just reminiscing on those days.

Firefox is just one small piece in the web application software revolution. But because it is such a visible piece, it serves as a rallying point for all of us championing the revolution. It solved not necessarily the hardest piece of the puzzle, but the piece that software geeks were probably least equipped to solve: marketing a thin client to the masses.

It’s the bootstrap piece. With that in place, everything else gets pushed back to the server, and software geeks can focus on what they are extremely well-equipped to solve: everything else, which is all technical and design issues.

The beauty of it is that Firefox itself will become a less critical component as time goes on. It served as an emissary, a flag bearer for the technical and political elements that drive this revolution: standards compliance, markup separated from content, specialized open formats like RSS, PNG, and SVG, and client-side scripting powerful enough to do almost everything one might want an application to do. But having led the way, others will follow. And we don’t need Firefox, specifically; we need a standards-compliant browser. Pretty soon all browsers will be that, because they have to be, or be left behind.

As it turns out, replaceability is one of the guiding principles of this new generation of software. Components that can be swapped out like legos. Nothing in the web application stack is unique or can’t easily be replaced with a comparable product. Apache rules the web server world, sure, but Lighttpd is a perfectly suitable replacement. Red Hat Linux ruled the OS world as far as servers and developer workstations for a while, but then it started to suck because of the RHEL/Fedora split. Faster than you can say “lickety-split”, Red Hat was off the map and Debian’s offspring Ubuntu now dominates. Any other major component you can think of is swappable: databases (MySQL, PostgreSQL), languages (Ruby, Python, PHP), application frameworks (Rails, Django, Nitro, Symfony), shells (bash, zsh, dash) - the list goes on.

This might have been the nastiest bit of sucking from the old style of software development. In that world, you had major components that couldn’t be swapped out. Microsoft was king here of course, but they weren’t the only ones: think of Oracle, Sun, or Adobe. This control was great for the profits of the company in control of the technology, but total suck-land for everyone else in the long run.

Firefox is not just a browser; it’s a software platform. Once upon a time we spoke of developing software for DOS, or Windows, or UNIX. Now we develop for the web; and by all rights, Firefox is the web. Not by virtue of its market share, which remains a small minority; but by virtue of its leadership position within that market.

Or you can say Firefox is just a browser, as long as you also say that Linux is just another unix derivative, Microsoft Office is just another office suite, Google is just another search engine, and Rails is just another application framework.

Revolutions rarely are really something completely new. They’re always “just” an incremental improvement over whatever existing before. But that increment can be enough to launch a whole new paradigm. Firefox is one piece of a larger whole which is going to - nay, already has - change the world.

Catapult is a side project I’ve been working on this past few weekends, with the goal of bringing a command-line style interface to web navigation.

Think about how one normally navigates to the web apps one uses every day. If I want to compose a new post on my blog, for example, I go to the blog homepage (by entering in the complete url, maybe utilizing my browser’s autocompletion), then grab my mouse and click on the admin link, then click on the write link, then switch back to the keyboard to start typing. This is no big deal for just one app, but think of all the actions like this we perform every day. Web searches, Gmail, Yahoo yellow pages, Google Maps, Craigslist, eBay, your bank’s website, and so on. Typically we do all this with bookmarks, urls typed in from memory, and lots of clicking on navigation links. It’s not very efficient.

Catapult lets you create commands that act as shortcuts, in some cases dynamic ones. So for example a Google search would be “g [search terms]”. I can launch Gmail with “gmail”, but I can also jump straight to the compose window with a recipient already entered by typing “gmail someone@somewhere.net”. Searching my inbox is just as easy: “gmail /thing to search for”.

It’s interesting to note that using the Gmail launcher has increased my productivity in an unexpected way. I often need to send an email about something, but opening my inbox and seeing some new messages that have come in distracts me from that task. By jumping straight to the compose window I don’t even get a chance to see the inbox and thus avoid unintended distraction.

Check it out, and post any feedback here; or drop me an email with your comments.

Consider for a moment the html form element for entering multi-line text:

<textarea>...</textarea>

Not much to look at, is it?

Hard to believe, but this little widget is fast supplanting the word processor as the tool with which most of humankind’s writing is done. Just as the word processors supplanted the typewriter, the typewritter the pen, and the pen the quill.

Think of all the places where one writes using textarea. Blogging, Writely and friends, site comments, feedback forms, message forums, GMail, and user profiles on community sites like Tribe, to name a few. Even the internal tool I use at work for creating project designs involves writing in a textarea.
What’s astonishing, then, is just how lame the textarea widget is. I’m pretty sure that Notepad has it beat out for features and usability. Scary, that.

I think the attitude thus far - and my attitude until just recently - was that textarea is just a multi-line version of <input type=text>. If you were trying to use it for any serious writing, you’re doing it wrong.

Sure, you and I know that for any serious writing you should use a real editor, then cut-and-paste the results into a textarea. For example I’m writing this in vim, to later be pasted into the textarea of my blogging software. But this is a haphazard and error-prone approach. One can accidentally cut and pasted too much or too little, for example. And then what if you want to edit it? Back to the original text file, delete the contents of the text area, and then cut and paste again? Or edit in place in the textarea, the very thing we were trying to avoid to begin with?

People not in the know about text editing tools - that is to say, 99% of computer users - just muddle by with textarea. They don’t know any better, but that doesn’t mean they aren’t feeling the hurt. Improving textarea’s capabilities would make everyone’s lives better, not just power users.

The other thing that gets my goat is the quantity of time an energy put into javascript rich text editors. Countless web applications, realizing the importance of decent editing capabilities, have sought to create their own or integrate an open source rich text editor. A few notables including GMail (which includes the very important feature of autosaving drafts) and WordPress. But these tend to be quirky, slow to load, and difficult to make work cross-browser. More significantly though, is that the application developers are spending huge amounts of time developing and maintaining a method for text entry, which seems like massive duplicated (and thus wasted) effort to me.

Everyone needs to have decent editing capabilities whenever they enter text. Why not just build it into the browser?

Partial attempts have been made, so I’ll mention a few of the notables here. One of the first ones that really caught my eye - and got me thinking about this - was automatic spellchecking, introduced into Konqueror a few years back. I was amazed by how much this improved my web writing experiences right away. Prior to having it, I think there was a small part of my brain that was constantly worried about whether I was spelling this or that word wrong and making myself look like an uneducated yokel. But any such thoughts were being squelched by the pragmatic concerns of cutting and pasting the text into Ispell or OpenOffice. So I had this constant little game of stress going on in my head - gone the moment Konqueror started highlighting my misspelled words in red. (I understand that Firefox 2 will be adding this feature as well.)

The honorable mention goes to KVim, which alas appears to be a dead project. This is a KPart (a pluggable component of the KDE architecture) that, when activated, caused most of KDE’s text widgets (including Konqueror’s textarea) to turn into a vim editor. Unfortunately the usefulness of this is limited for obvious reasons, but this is the closest browsers have ever come to having a non-sucky textarea widget.

More on the rich text side than the power-editing side is the clumsily-named Xinha Here Firefox plugin. Regrettably this is not inline; you have to right click and select “Open Xinha Here”, at which point a window pops up to offer an advanced editor. When you save, the results are pasted back into the textarea. More convenient than an external editor, but still far from the seamless solution we need.

So come on folks, let’s collectively come to grips with the fact that textarea is the most important editor of the future. Time to make it, you know, good.

There’s a debate that seems to be emerging among web app developers between three competing types of interfaces. I’ve been pondering this question for years - almost since I first began working in the web realm - but, lacking good terms to describe my vague thoughts on the matter, I was unable to vocalize them. Luckily I stalled long enough that someone else did the hard work of coming up with terms. Here they are:

• REST - Aka “the usual”. This is where all the information for the page’s state is stored in the URL, or in the payload of an HTTP POST. (The latter implies that every piece of data you want to carry onto the next page will appear as a hidden input field in the previous page’s form.)

  REST is easy to use, works perfectly with all browser functionality (back, forward, bookmarks, etc), and requires no server-side storage. It is the default and should be used unless there is a compelling argument to use one of the other two types.

• Continuations - This is where you stuff user state data into a session stored on the server. Aside: the name comes from the continuation feature offered by advanced languages, but the language or framework doesn’t need to support low-level continuations to implement the interface feature. Sessions are a cinch to use with modern languages, in some cases even easier than REST since you can store complete objects and not just easily urlencodable fields like text and numbers. Use of sessions makes a lot of sense for multi-page forms (which closely resemble the “wizard” style of interface in the olden days of local GUI applications). The checkout process on a shopping cart, filing out a long and complex profile on a dating site, or browsing the result set from a complex query on a travel booking site are some good examples of where continuations / sessions are often used.

  The downside to continuations is that they break some browser functionality. This is painfully apparent with tabbed browsing. Want to browse two result sets side-by-side in two tabs or browser windows? Too bad - you can only have one session at a time. I’ve often worked around this by viewing the site with two different browsers at once. The fact that this terrible hack is worth using indicates there is some serious flaws in the continuation model.

• Ajax - Always a crowd-pleaser. Ajax breaks browser functions completely in most cases, so it should be used only when breaking standard navigation can be considered a benefit. One of my favorites is deleting an item out of a list. Back/forward and bookmarks make absolutely no sense for this. Dragging the map around in Google Maps is another good example. (Importantly, you can still get bookmark / email a link to your friend / etc capability via the “Link to this page” link.) And sometimes Ajax can be justified just for speed reasons. GMail breaks some browser functionality in places where it might be preferable to keep it, but the benefit to performance makes this a worthwhile tradeoff.

Personally I really like continuations. They are just so dang intuitive. The user clicks a link or button to start a new session, taking them into a multi-page form where they can move at will between the steps, tinkering with all the data until everything is just right. Then when they are satisfied that everything is perfect, they click “Commit” or “Place Order” or other button at the end of the process, and the session data is finalized and saved into the server’s database.

Continuations can actually get even cooler if they can be used as a work-in-progress which can be returned to at a later time, or even send the link to another person for collaboration. One of our clients has a system which uses this to submit change requests. Certain types of users can start the request, entering in all the relevant data, but they cannot commit it. The change request is saved as a work-in-progress and users from another role are notified. One of those users then loads up the request - effectively taking it over - and can verify and approve all the data they see entered, then run the finalize step at the end to commit the change.

One could actually do this same sort of thing even with a single-page form, but prior to needing this interface feature I never stopped to think about storing data in an incomplete / work-in-progress state. The old web app model was just form post -> store to database, and that was it. Multi-page forms forced me to come up with a good implementation for saving the state of an incomplete data record; but once that capability was available, I discovered there were a lot of other uses for it.

Multiple Continuation Sessions

So what about running two separate continuation sessions in different tabs? There’s a pretty simple technique for dealing with this, although it doesn’t seem like many places use it. The trick is to create a unique key each time a new session is started. For example, a travel booking site might generate a random key whenever you click “Find my flights” or whatever was the initial button or link to launch the search process. This key should go in the URL, so your address bar looks something like:

http://example.com/multipageform.php?sesid=12345

The object storing your continuation data can then be accessed via something like $_SESSION[’multipageform’][$_REQUEST[’sesid’]]. Users can view the same session in multiple tabs by cutting and pasting the URL from their results or by a duplicate tab/window function. Or they can view different sessions by opening a separate tab and starting a new search - or any combination thereof.

One thing to watch out for here is that your session data can get pretty large if you don’t do a little bit of manual garbage collection. I usually just limit the number of sessions which can be open at once, throwing out the oldest one when the limit is reached. For example:

if (count($_SESSION['multipage']) >= 5)
   unset(key($_SESSION['multipage']));
$sesid = sha1(rand());
$_SESSION['multipage'][$sesid] = new MultiPageFormController;