the (un)real thoughts of realbt

I have a problem.

I believe that AI algorithms for predicting my behaviour within user interfaces (specifically for my interaction with the interface: think resizing windows, positioning on screen, tab selection, etc.) are usually quite dumb. Maybe that’s because they aren’t really AI routines to begin with, but dumb rudimentary logic some programmer was told to code in. This is useless. I don’t think my behaviour is really all that unpredictable anyway.

However, at the same time, it drives me crazy that Windows doesn’t know how to size file explorer dialogues to my liking. My folder preview pane width should be proportional to the depth of the file tree. And the detailed file view of the current directory need not be so wide to consume space that will not be used. This is especially annoying when the columns of the detailed list view end before while the window width continues. This is dumb. Fix it. But fix it right.

Much controversy surrounds the plain text vs. HTML email debate. And apart from the ideological debate (which consumes most of the debate), there are a number of technical problems (which translate into usability issues) that arise from either type.

Let’s start with the introduction of mobile devices: PDAs, cell phones, wireless email toys, BlackBerries, etc. These came long after the plain-text days of Pine. Typically these do not handle richtext formatting. When email is sent as HTML (and when the email client behaves properly), a plaintext copy of the original message is included in the envelope. This ensures that clients not capable of handling the HTML content are able to read the email in its simplest form.

This should work for mobile devices too, right? Well, sure. If they’re built smart enough to ignore the HTML content and go straight for the plain-text version, that’s great. But that still means that the envelope is 100-150% larger than it would be with just the plain text message. While this isn’t a problem for anyone on a broadband connection, you want to be able to download and read your email on your wireless device as fast as possible. You shouldn’t need to download wasted garbage that won’t be touched anyway.

What about office workers and non-technical staff? Anyone that’s familiar with the pre-Outlook days of email can recognise the non-technical staff person using Outlook in an office environment. If you’re used to using Word, it comes as a surprise to find out that email was never intended to cary richtext. Plain text — what’s that? What do you mean I can’t bold that word? This is a huge usability problem and email really hasn’t provided an elegant solution (unless you consider HTML mail “elegant”).

To these users, it only makes sense that one should be able to compose email using all the same features afforded by a dumb word processor. Unfortunately, the deeper understanding of email and its history just aren’t in the minds of most IT workers anymore, and therefore users don’t understand it either. And why should they have to? Email was never meant to be a complex application. Nor should it be.

For Hotmail users and 75% of the wired world, reply methods means nothing. But it is a huge deal. It’s been the cause of many flamewars over the years. Quoted or outlined; quoting and nested; top replies and bottom replies. What is all this? In the good-old plain-text days, text was quoted with a greater-than sign followed by a space (”> “). One then replied to the entire content (or however much of it the replying author wished to quote) below, such that the email thread read like a conversation. It was very intuitive.

But then software makers started defaulting the reply position above the quoted text. This meant that you had to read the email upside down in reverse in order to re-read the thread. Somewhat less intuitive than bottom-reply (discussed above), but this quickly became the norm with Hotmail and the like.

Then along came HTML mail, which became a hybrid of Microsoft Word and top-replies. This was the end of plain-text.

So what’s better? They all have their merits, of course. Usability, it’s nice to be able to bold text in an email without using special characters to highlight a word. It starts to seem cumbersume and very old-school to train a new office worker to use underscores to make a word appear underlined.

Ultimately, it’s become one big mess of usenet flaming, Outlook HTML abuse, and ill-conceived forking of confirmity. One thing for certain: nothing is going to change. On one hand, it would be nice of the world could abandon plain-text, and everyone move to pure richtext (no, not HTML). But the support isn’t there, and it adds to the bulk on mobile devices. It also makes bottom-replies near impossible; at the very least incredibly awkward. And switching entirely to plain-text seems very 1960s of us. In a world of camera phones and RFID tracking, it feels very backward.

It’s a perfect example of human usability, technical standards and habits, and lack of a plan from the non-Microsofties in the world. Email was never meant to be a complex application.

At work, I am a Windows user. And as a result, I use iTunes to listen to my music while I’m busy coding. iTunes is a wonderful application. I appreciate the way it handles my music and helps me organise the songs I listen to in a sane way. Much better than the way I did in the old days of WinAmp. It’s no wonder that at home I use Amarok (previously known as amaroK; don’t ask, it’s a KDE thing).

The only problem with iTunes are its widget controls. I can’t say for certain how well it works on Mac OS (though I suspect it’s flawless), but I know that it’s a little quirky on Windows.

When I click on the pause button (or any other button, for that matter) when the iTunes window is in the background, the first click only brings the window into focus. I have to click a second time to actually “click” the pause button.

Not a big deal. In fact, it almost makes sense. But when you stop and think: this is not standard Windows behaviour, you start to wonder. What was Apple thinking? Surely other people have complained about this. It’s only a little annoying. But it is a usability issue. And what is Apple better at than most software manufacturers? Usability.

My last post about URLs was likely a little long and confusing. Allow me to summarise in 3 points exactly what I think is wrong with most URLs today:

1. URLs to web documents (essentially html files, or anything that renders as html) should not include a file extension specifier. The user doesn’t need this, nor does a smart web server/application.
2. URLs should not contain query strings unless absolutely necessary. Most simple GET queries can be nested as a nicely formed path in a URL.
3. A URL should tell you exactly what you are accessing. Numerical identifiers (usually database keys) are fine (of course, it’s better to have meaningful numerical identifiers than random ones, but that’s another story) as long as the user is able to identify them as such. For example: http://www.news.ca/article/7467289598. Even though the number is meaningless, one should be able to make an educated guess that it is some sort of unique identifier used to “look up” the actual article.

In the first of what I hope to be many posts on the topic of computer usability for the masses ™, tonight I wish to address my concerns with the web and URLs.

The web has been around for 10+ years. Heck, I’ve been on the web for a good 10+ years. It’s hard to imagine really. Things have changed. I remember a time when getting some new plugin to work with Netscape 2 was a pain. On a 14.4 Kbps modem, it was never fun downloading the latest Real Player (in whatever naming incarnation it came in at the time) so I could get a sneak peak at some random stream I decided to watch/listen to. More often than not, it turned out to be a big waste of time.

One thing that hasn’t changed is the bad use of URLs. Back in the day, there were but a few web document (and I italicise that for a reason; more in a minute) file extensions: (s)htm(l), pl, cgi, and perhaps a few others. Today there are dozens. We have php, asp, aspx, pl, py, etc. And the plethora of other document types that people are accessing via the web these days, such as pdf. But, as I said, I’m talking about web document types. I’m really unconcerned about anything that is not rendered directly by your browser which isn’t a media type. So let’s forget about images, movies, sound files, style sheets, and pdfs. All I’m talking about herein are pages that are rendered in one way or another as html by your web browser.

These web documents are essentially the root URL one would use to access a given location. All the media files that come with it are rather extraneous to the end-users cause and they shouldn’t have to know about them (which they don’t — it’s a good thing).

So why are so many URLs utterly unreadable, or at least painfully typed, by humans? Of course we have things like bookmarks and search engines to help us having to avoid typing them in. I’m not trying to advocate that we should type them in — but merely that we should be able to.

How many times have you read an article on some news site — perhaps a newspaper, perhaps a techie site — and the document URL contains some combination of indecipherable numbers, commas, and maybe even a shortened page title? To make matters worse, these often are followed by a “.aspx” extension or something else. Or pages that have seemingly simple URLs but are followed by complicated HTTP GET querystrings that are longer than the width of your browser allows for display.

The good news about modern web servers is support for URL rewritting, which is a method for a web server to take a clean URL and convert it into something more ugly that the web server’s file system can understand.

For example, to view my blog archives from April of this year, the clean URL of http://www.realbt.com/content/post/2006/04/exists. But this isn’t a real path in my web server’s file system. Instead, this is converted to something like http://www.realbt.com/content/wp-archives.php?year=2006&month=04.

Which do you prefer to look at?

In my mind, URLs should be short and readable. We should be able to type them in. No document file type (html, php, asp, etc.) is necessary, and the only non-alphanumeric characters should be hyphens and slashes — maybe an underscore or two is okay if absolutely necessary. (But hyphens are easier to type.)

So to all those mass media web sites — get your act together. I’m not going to enumerate all the possible technical solutions to the problem of matching pretty names to ugly ones because there are simply too many. Anybody moderately familiar with their web server should be able to figure it out.

Another example.

A Macleans story about Harper’s new government has this lovely URL: http://www.macleans.ca/topstories/politics/article.jsp?content=20060417_125314_125314. This could be converted to simply http://www.macleans.ca/topstories/politics/article/20060417_125314_125314. Even though the following number is relatively meaningless, it is still more human-friendly to look at. Long argument lists and document types are simply not necessary for humans to see.

Most URLs of this form translate into some sort of key that is used by a script or application running on the web server to look something up (usually in a database). These are easily simplified. But what about web sites that are purely static. Allow me to use an example.

xyzpaving.com is a paving company. Their web site is structured as follows:

/index.html: the main page
/about.html: about

/services/index.html: the main services page
/services/blacktop.html: some page about blacktop paving
/services/cement.html: some page about cement paving

… you get the idea. The URLs are certainly concise and human readable. And anybody could type them in. Let’s say in 2 years time they decide to change something about their site that requires they move their pages to being php files. Suddenly all their URLs change, broken links emerge everywhere. Anyone who links to a specific page will have to update their URLs. And search engines will be temporarily broken.

This is another reason I advocate for dropping file extensions on web documents (as defined above). This should make the URL structure look like:

/: the main page
/about: about

/services: the main services page
/services/blacktop: some page about blacktop paving
/services/cement: some page about cement paving

Note that index entries (default documents for folders) do not need to have “index” referenced. Not only are these cleaner, but it also provides a simple abstraction layer in the case document types are changed and extensions are changed. It will all happen transparently, and no one will be the wiser. This whole process is easily accomplished in modern web servers with a line or two in a configuration file. Nothing complicated necessary. What a simple solution.