Symphonious

Back as far as Raskin’s The Humane Interface, and quite possibly before, modes in user interfaces have been frowned upon. Despite that, huge amounts of software ships with a simple mode and an advanced mode. The theory being that when users get started they use the simple mode which makes the simple tasks they want to do really straight forward. Later when they want to do more than the basics, they’ll be more familiar with the software and thus be able to handle the advanced mode.

The problem is, the user has become familiar with the simple mode so when they switch to advanced mode, they are rank beginners again and thus can’t handle the advanced mode. There’s simply no bridge to get them from the simple mode to the advanced mode. They’ve been set up to fail.

The problem is, it’s incredibly hard to convince people of how wrong this kind of thing is because the initial feedback is always so positive. The simple mode is way simpler and users can get stuff done that they couldn’t before. The problem lies just beyond that, there’s no way the user can use all the rest of the functionality. So you either need to make your advanced interface as simple as the simple one (eliminating the modes) or just get rid of the advanced functionality since it’s too hard to use anyway (or I suppose just not care about usability).

Fortunately, yesterday while wandering around Wisley Gardens taking photos of flowers I realized I was holding one of the most dramatic examples of modes and how it inhibits the learning curve. The Canon D40, like most DSLRs has a bunch of modes you can put it in:

• Fully Automatic
• Flower/Macro
• Landscape
• Portrait
• Aperture Priority
• Shutter Priority
• Fully Manual

Somewhat surprisingly, this is a good thing. The camera, isn’t able to tell if you’re taking a picture of a flower and thus want a short focal length and vivid colours or if you’re taking a portrait shot and want a slightly deeper focal length and softer tones, so it gives you an easy way to tell it what you’re doing so it can take the best shot. These are “good modes” - they’re not so much modes as they are settings designed to help you out, but hidden in there is a bad mode.

See, the first few modes are the “beginner zone” and the last few are the “creative zone”. When you’re in the beginner zone you don’t have any control over the ISO, the aperture, the exposure or even if the flash is used beyond picking the mode you want. In the creative zone however, you’re suddenly expected to understand and manage all of those extra settings. This is a bad mode.

I very quickly realized that since I’m quite new to SLRs, if I tried to manage all those settings by myself, the shot would generally be pretty average. If I set it to flower mode though and used my SLR as a good old point and shoot it would take fantastic photos every time (my lousy framing and lack of a macro lens not withstanding).

It was extremely tempting to go running around the garden in beginner mode being able to quickly and easily take pictures and getting great results but I knew if I did that I’d be stuck in beginner mode forever. At some point I have to go running around taking lousy photos just so I can learn what all those settings do and take full advantage of my camera. Once I master them all though, I’ll be able to get the shot I want in so many more situations and have so many more types of shot suddenly available to use for artistic expression.

So how could the camera make things better? Well, just enabling the options in beginner mode would be a good start. Set them all for me automatically but let me override them if I want to learn. That way I can play with aperture, and just aperture, to learn how it works and by looking at the settings the camera picks to work with my aperture, even learn how it interacts with the other settings. The camera does in fact provide some presets to help when shooting portraits, landscapes or flowers even in the creative zone so maybe I could use them as a stepping stone. Of course, they aren’t on a big dial on top of the camera so I can’t remember how to get to them… It’s certainly not an easy problem to solve, but it is quite clearly a problem. Since almost everyone has used a camera before, usually a point and shoot, it should also be a pretty good example to show why modes can hold you back - they’ve used a camera quite a lot, but still haven’t learnt anything about all those exotic settings. Maybe then we can start solving the usability problems instead of just trying to sweep them under the carpet. After all, the results are really worth it.

David Welton described a frustration he had with FireFox’s spell checker which piqued my interest:

I write most of my email (in gmail) and submit most web site content in English, however, a significant portion is also done in Italian. I leave the spell checker in English, because Italian is, in general, quite easy to spell, so that even as a native speaker, a helping hand is occasionally welcome. However, it isn't as if I write Italian perfectly either, so the help there would be nice as well. I find it quite annoying to go change the language in the spell checker option each time, especially when, as an example, I'm responding to email and do 2 in English, one in Italian, another in English, and so on.

On the face of it, identifying what language an author is using looks a lot like a natural language processing problem and thus requires a PhD and many years of research to tackle. Looking a little closer though, you begin to realize that the problem domain is dramatically reduced in this case:

1. We’re dealing with a preselected list of languages that the user can actually speak. For the majority of people who’d use this feature, that would be 2 languages and it would be very rare to make double digits.
2. We don’t really want to know the language that’s supposed to be in use, we just want to find the spelling dictionary that most accurately checks the language that’s being used.
3. We obviously have a spelling dictionary for each of the candidate languages around or it’s pointless detecting the language in the first place.

Given the first restriction of a limited number of languages, we can use a pretty brute force algorithm since we don’t need to check every language on earth. Given the third restriction, we have a big list of valid words in each language. Finally, given the second constraint, we just want to find the spelling dictionary that marks the fewest words as errors and we’re very likely to have the right language.

So all we do is check the document with each dictionary, count the errors for each and pick the dictionary that gives the fewest errors. I implemented this and it works amazingly well for such a stupid algorithm, but there’s a problem…

Dictionaries are really big. Downloading a dictionary for each possible language isn’t a lot of fun if you happen to be writing a browser based editor. Worse, loading 5 dictionaries into RAM takes an awful long time and consumes way too much RAM to cache.

Fortunately, the spell checker I happen to have handy breaks words up uses a simple optimization to avoid having to search through the entire word list every time - it includes a separate file of the most common words in the language. For the spelling checker that allows it to find a match for most words from a small hash table. For our purposes though, the most common words are exactly what we need and they reduce the size of the dictionary to something extremely manageable.

In fact, the most common words from the 12 languages EditLive! supports amount to amount to about 40k in total. Easily small enough to download them all and they load fast enough that there’s no need to cache them in RAM at all.

I was going to post the code I wrote but it depends on a proprietary, third party spelling checker and is frankly so basic that it’s really not worth sharing. I was going to put it up as a servlet for people to play around with but Google has one that’s way better anyway. Still, it was fun to do up and nice to know that something that seems to complex is actually ridiculously simple.

Kevin Gamble pointed me towards the Sun Wiki Publisher for publishing documents to MediaWiki servers straight from OpenOffice/StarOffice. The key problem with these types of integrations is that wiki markup simply can’t handle anywhere near the same level of expressiveness as even HTML, let alone a word processor document. Hence the description mentions:

All important text attributes such as headings, hyperlinks, lists and simple tables are supported. Even images are supported as long as they have already been uploaded to the wiki site. An automatic upload of images is currently not supported.

The lack of image upload is just due to the early stages of development, but the loss of formatting is going to be permanent. Generally wiki markup can’t handle things like nested tables and there’s a big difference between tables and “simple tables”. Those users who don’t use heading styles (and there are, unfortunately, a lot of them) will probably akin to a plain text dump.

Of course, determining which formatting you want to keep and which you don’t when moving content between systems is incredibly difficult but it’s always nice to actually have a choice which wiki markup just doesn’t provide.  For example, EditLive! has three modes for cleaning pasted content from Microsoft Word (and from any other source really):

• Clean - structural information only, like headings, tables, lists etc.
• Inline Formatting - preserve the formatting as best as possible with HTML by using inline styles.
• Embedded Formatting - preserve the formatting as best as possible by adding CSS styles to the head of the document and using classes.

There’s also some options about plain text and prompting the user when the paste but they’re so unpopular we may as well just ignore them.

Towards the end of many EditLive! releases someone goes through the default configuration to make sure it’s got all the new settings and is the best set of defaults we can find. Inevitably, this leads to a discussion about which of the above three options is best and after 6 years or so of having this discussion there still isn’t a completely clear answer. Lately the trend has been towards pasting clean among our clients but there are still plenty that want pixel perfect rendering accuracy. In large part, it depends on how well structured the original documents are because if they don’t use heading styles they simply won’t import well with “clean” and if they’re full of gratuitous formatting that you want to get rid of but use heading styles well then “clean” works well for you.

Bottom line, having a choice about these things makes importing existing content so much easier - even if you hide all the inline formatting functions in the editor so users are still encouraged to just use headings and CSS etc.

Jeff Atwood:

Some of the largest sites on the internet — sites you probably interact with on a daily basis — are written in PHP. If PHP sucks so profoundly, why is it powering so much of the internet?

The only conclusion I can draw is that building a compelling application is far more important than choice of language. While PHP wouldn't be my choice, and if pressed, I might argue that it should never be the choice for any rational human being sitting in front of a computer, I can't argue with the results.

Results are and should be what matters. There’s no point in writing extremely elegant code if it doesn’t work. There’s no point writing elegant code if it requires herculean efforts to deploy in production. There’s not even any point writing elegant code if it takes you twice as long unless you can actually justify that in maintainability.

The reality is that even code that feels vastly more elegant is often only marginally more maintainable than average code. There is a huge maintainability benefit going from lousy code to average code but from there it starts to rely more and more on domain knowledge and particular coding patterns than on the elegance of the code.

As developers we need to keep in mind that while theoretical excellence is a really important thing to investigate and pushing the boundaries of technology with new techniques and languages, but they’re not everything. When it comes down to it most of us are paid for results, not theories. If those results come from a clunky, out of fashion programming language then so be it.

Nick Bradbury:

Those of us who believe that desktop software is still relevant in a browser-based world should be up in arms about how hard it is to install software (on Windows, at least - it's easier on the Mac). Multiple security warnings, required OS updates, and tech-heavy language make downloading and installing software too scary a prospect for non-technical users.

Desktop software on all platforms can and should be really easy to install. All it requires is for the user to click a link, click “Run” and the application should be up and running. In future they should be able to access it directly from their hard drive (start menu, Applications folder, command line, whatever is appropriate for the platform). Anything more complex is purely because the developer chose to make it more complex.

For instance, Microsoft’s World Wide Telescope is difficult to install because the developers chose to use .Net 2.0 and not bundle it with the download. They chose to require all the latest Windows updates and security packs and they chose to use a setup wizard for the install. None of this is actually needed and the same problem happens with web apps where users are forced to upgrade their browser or switch to IE or upgrade flash etc.

Install experience is not decided by the platform used, it’s decided by how simple the developers choose to make it.