Archive for the 'simplicity' Category

UI: Computers should be seen, not heard

Tuesday, August 21st, 2007

When I was a child, my father would quote the Victorian era expression “Small children should be seen, not heard” when I became overly boisterous. At that time I was not sure whether or not he meant it. I do however believe it should apply to computers…

Don’t put words in other people’s mouths!

Safari’s URL and form autocompletion really irritate me: they always add their guess to the end of what I’m typing a third of a second later. That means I press enter, only to find incorrect data was added to the field, and then submitted. Others have the same complaint. Nevertheless people do want some form of autocompletion.

For Find It! Keep It! I added an almost identical interface: the same popup window, the same use of up and down keys to choose, the same ability to click or double click on a choice, but crucially, you’re always in control. Nothing is added behind your cursor until you use the up and down keys to choose a selection. Type a new character in, and your selection is cleared.

Don’t just grab something that I was about to use!

Spotlight invariably updates its window the instant before I click the file I want to open, causing me to open the wrong thing.

A different solution is to use colour to show which page contain the search term. Although it does mean more information on the screen, it lets users click on pages as soon as the search term is found. That’s what I’m doing in Find It! Keep It! when searching pages by content.

Don’t jump up and down to get attention!

An application’s icon will bounce automatically when the application opens a modal panel if it is running in the background. It is possible for each application to remove this effect on a per-application basis. The problem then is that either one has to set a preference in each app to override default behaviour, or apps behave inconsistently. Apple could system wide preference for this to alleviate the problem.

Delay informing people about things until it’s relevant!

Software Updaters are another source of interruption that I don’t believe is necessary: as long as I don’t adversely notice the change when I use the tool, I don’t need to know that it’s updated the moment I use it. Web applications change constantly, but no one complains unless they stop working. Desktop applications will, I believe, adopt a similar model. How then, will the user know about the latest improvements? By email! People are in the mood for reading things when reading their email, not when working. Apple’s Software Updater is the worst in this category: it interrupts you and then asks you to drop everything and restart your computer.

Software should not behave like 3 year old children

It is difficult to hold a conversation when someone continually interrupts: one can’t organize one’s thoughts while being bombarded with new information. Using a computer is a similar situation. When the user talks, the computer should just listen.

Solving the evolving File Format problem

Tuesday, August 14th, 2007

Andy Matuschak brought up a really good obstacle to providing an easier upgrade and downgrade path for applications: changing file formats.

Changing file-formats is far from free. It fractures your user base as your users find they cannot share their documents with their friends. It makes it difficult for you to regression test your code. And it dissuades third parties from supporting your file-format, because you’re giving them more work each time you change. Overall changing file-formats should be avoided where possible. How then can you extend your application?

Future proof your file-formats!

I try to keep my file-format forwards compatible: the same file should work with older versions of my software. This makes it easier to find bugs that I may inadvertently have added: I can regression test against an older version of the software.

I use a file-format that lets the Application store but not use the fields it does not understand. There are many such solutions: SQLITE database, Trees, XML, python pickles… The reason to store fields one does not understand is that one can save them back out later.

For example consider an HTML document. Even if your HTML editor does not know what the “blink” tag means, it can remember the fact that that there is a “blink” tag around the text over there. Even if you edit the text within the blink tag, it can make reasonable guesses about grouping. Of course if you delete the text and type it back in, the blink tag will be gone. But most of the time you don’t just lose your formatting because a colleague used a different tool to edit your file. The key idea here is that you can use an extensible hierarchical data format to keep things associated with their attributes.

Keep the conversion code separate!

Sometimes, to simplify the main application’s code, it does makes sense to change file-formats. In that case, write a bidirectional converter. A version field in the file-format specifies (by naming convention) the converter to use so that the App when encountering a file of a different file-format can figure out the chain of conversions it must apply to get something it understands.

Now if you downgrade, you’re in almost the same position as your friend who never upgraded: your application can’t read the new format files. There is however a difference: as part of the upgrade process a bidirectional converter was added. It does not need to be removed on a downgrade. Because the the older version of the application knows how to figure out which converters to call, it will just find them and call them.

Note that because the original file-format is extensible, it’s possible for the bi-directional converter not to throw away any data. Similarly because the oldest version of the app stores the stuff it does not understand and saves it back out again, changes made by a co-worker with an older version of the software should cause little data loss.

Additional benefits of independent converters

Because you have independent converters you can earn bonus points with people who have not yet been able to upgrade. You can give or sell them the tool to convert the files. The tool can even advertise the features they’d get by upgrading.

You benefit because your code is simpler. The application code is simpler because it only knows its native file-format, the converter’s code is simpler because it’s focussed on one task. You also benefit because it’s easier to require a new base OS for your next version without fracturing your user-base.

Of course writing writing a converter is a pain, and a bidirectional one even more of a pain, but as I said in the beginning changing file formats should be avoided. Writing a bidirectional converter forces you to consider more cases, leading to a better upgrade converter. Furthermore you can reduce the pain for third parties by giving or licensing your converter to them.

What about standard file formats?

I think the same idea of independent converters can be applied, although it may not be possible to keep the additional information known to later versions of the file-format in earlier versions of the file format.

Simplicity: a recurring winning idea

Sunday, October 22nd, 2006

Our lives are unnecessarily complex

Consider the number of forms you should have filled out. Here’s a starter list: insurance (health, vision, dental, house, life, car, …); banks (checks, saving, credit cards), retirement, taxes (state and federal).

Consider the number of options on standard electronics (cell phone, dishwasher, TV, video recorder…)

Consider the length of modern laws (just the Patriot Act is 300 pages long). How can you obey them if you don’t know them?

Consider the mainstream software you use daily, how many features do you really use? Why is the average computer book 500 pages long?

Contrast this to our previous tools: fire, stones, reading, writing, hammers, etc.

The costs

All this unnecessary complexity has a cost and no benefit. Inefficiencies can kill entire national industries. Toyota succeeded while US manufacturers were failing because it focussed on eliminating waste.

Where does this complexity come from?

Ironically, economics! It’s cheaper to add a feature than to change a design, both for existing users (less to learn) and for the tool maker (less to change). Although risk aversion plays a role too…

Consequences

Among early adopters, simpler often wins. This rarely lasts as new features are added without removing older ones. (PowerPC RISC became as comples as CISC; GPUs, once simple and fast, have become larger than CPUs; Mainframes, minicomputers, microcomputers each replaced their bigger older brothers).

Late adopters, having found it so hard to master one tool, refuse to learn another, perpetuating bad tools. Can we have x86, but faster? Can we have Windows, but without the viruses? Can we have Word, but without the annoying features?

Web 2.0 is just another incarnation of this cycle. Google’s key invention was a simple interface, coupled with page rank. GMail was easy to use: free webmail existed before.

One could think that Web 2.0 is successful because it’s free. 37 signals refute this notion: people subscribe to use their web applications. Why? Because their tools are simpler to use. 37 signals believe in simpler products that do less than the competition. They one down the competition rather than one upping it.. Their philosophy is in their book.

Find It! Keep It! also emphasizes simplicity. Two examples: You don’t create a project or a document. You just go to the URL and press Keep It! Saved webpages and database searches have URLs, just like live pages.