Web browsers make bad text editors

September 16, 2005

As editors web browsers have all sorts of problems, such as a narrow view of the text (squeezed into a small to tiny text box), only (very) basic editing operations, and a severe lack of features. Some of the features can be somewhat fixed up by the website, like spellchecking and saving drafts in progress, but even then they tend to be awkward. (You can read one person's grumbles about the problem in the context of blogging here.)

This makes it puzzling that more and more people are designing systems that call for web browsers to fill the role of text editors. Often the web browsers are the only available text editors. 'Web-based' is big (blogs, wikis, bug tracking systems, and so on) and all too often web-based means 'only accessible through the web'.

Every time I see this, I wince.

Bad software creates a kind of friction. In the face of friction, people have to work harder and be more motivated in order to use your software. Some of them won't bother; some of them will wind up grumpy. The more friction your systems have, the larger this effect.

Most people have a finite amount of energy and time that they're willing to devote to writing things. The more work the text editing takes, the less they have left to spend on creating and refining the actual content. And the content is the important thing, so effort spent merely editing it is basically lost.

(Certainly this is the case for me. More than once I've concluded that fighting text editing in my browser simply would take more energy than I have available for writing at the moment, and not written comments on this or that.)

In many cases the people writing the content are probably the most important users of your system (especially in the case of bug tracking system). The corollaries are obvious.

DWiki has deliberately adopted the contrarian position of making file editing with a real editor the primary (and so far only) way to work on pages. I feel strongly that this is a big part of why I've been willing to keep writing at least an entry a day for almost three months now; it is simply that much easier.

(The extra features enabled by real file editing are very nice, too, like drafts and notes and outlines that stick around as long as I want them, and an ideas file.)

(Updated: my apologies to people who are seeing this twice. I realized I had given this entry the wrong name, and in DWiki changing an entry's name also changes its identity in syndication feeds.)


Comments on this page:

From 192.88.60.254 at 2005-09-16 11:59:18:

One thing that I'm surprised hasn't taken off is DAV - letting you use a web-based storage system for your files while at the same time letting you modify them with any tool that can speak DAV or, if you're willing to limit your capabilities somewhat, any tool that can talk to regular files if you're on a linux box with davfs installed, or any tool that can talk to Microsoft's "Web Folders" on Windows.

Actually, a wiki that also exposed a DAV interface that just served the raw files on a slightly different URL would probably be a good idea.

Maybe DAV is one of those things we'll hear about for years and years, consider vaporware, and suddenly be overwhelmed with when, say, the iMac will ship with nice support for it. (c.f. USB in the early 1990s)

DanielMartin

By cks at 2005-09-18 02:18:48:

I think I tend to think of DAV as a more of a workaround for this sort of issue than a real solution, partly because I think that in a lot of cases DAV would wind up being a publishing/retrieval mechanism instead of a real file store. (Do you really want to push the file over DAV every time you reflexively hit save in your editor?)

On a quick look, DAV seems a rather complicated protocol. I suspect that wiki authors and other people needing this sort of thing will go for simpler and somewhat more ad-hoc protocols, probably based on something like SOAP or XML-RPC.

(I also suspect that being implementable over plain HTTP GET and POST is pretty important these days, as it's much more likely that your code can work in a broad variety of environments. DAV appears to require everything between hither and yon support some additional HTTP verbs.)

Written on 16 September 2005.
« Efficiently distributing huge files to lots of workstations
Getting a list of all objects in Python »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Sep 16 01:20:57 2005
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.