unraveled

October 2003 Archive

LiteSwitch X

Up until OS X version 10.3, application switching in OS X has been poor. To switch the active application in 10.2, you hit Command-Tab and a highlighted dock icon told you which application was selected. It worked, but it had problems. The biggest of which occurred when open applications were separated by several unopened applications on the dock. When this happened, the highlight skipped across these unopened applications in a seemingly unpredictable manner because almost no one could remember exactly which applications were open and which applications where closed.

10.3 fixes this problem by introducing a new application switcher, very similar to the Windows application switcher and also very similar to LiteSwitch X, an application switcher developed by Proteron.

Samuel Caughron, developer of Proteron’s LiteSwitch X, has written an open memo to Apple regarding 10.3’s new application switcher. He claims that a developer at Proteron first conceived of it and that Apple should recognize this. As John Gruber has already stated, both of these claims are absurd. Almost every developer knows that Windows has featured an application switcher since version 3. LiteSwitch X was by no means an original idea. Expecting Apple to recognize a fallacy further contributes to Caughron’s ignorance.

If Caughron were smarter, he wouldn’t have said anything about original ideas or Apple’s failure to recognize Proteron. What he should have done was simply congratulate Apple on implementing a new application switcher and point out that Proteron offers an application that does pretty much the same thing as 10.3’s application switcher, but it does it better. Because LiteSwitch X does do it better.

To summarize: good job Apple, bad move Caughron, download LiteSwitch X (it overrides 10.3’s application switcher when installed).

Richard Stallman on Software Patents

Yesterday I heard Richard Stallman, founder of the Free Software Foundation, speak at the University of Westminster. The topic of his talk was software patents and why they’re a bad idea. I had previously heard about certain software patents that caused some trouble, but it was very useful to hear Stallman spell out these problems.

He began by describing the term “intellectual property” as biased because it prejudges that software should be treated as property. Stallman argues that software is only information. The term also lumps together copyright and patent laws which are completely distinct laws. This lumping together of laws keeps people from seeing the real issues at hand. So the first step is to separate the issues. Copyright covers the authorship of an expression, is automatic and usually lasts for about 150 years. Patent covers ideas within that expression, is not automatic and usually lasts for about 20 years.

Stallman went on to discuss the main problem with software patents: when writing software, there’s practically no way to know what patents may interfere with the software you’re writing. (There is a way but it’s very difficult.) On top of this, patent language is written by lawyers for lawyers and is consequently difficult to understand.

When dealing with patents, the options that software authors have are few:

It’s easy to see why Stallman calls software patents landmines for programmers.

An important question that I was pondering during his talk was one he eventually addressed himself. Other fields, such as engineering, deal with patents fine. Why should software be an exception? Stallman describes this as an unfair question because it treats software as the exception. A better question is this: should there be a different patent policy for different fields? Stallman thinks so. To explain his answer, he compared the fields of software design and pharmaceuticals. Pharmaceuticals, which can be patented, generally contain very specific chemicals which do a very specific thing. Software, on the other hand, is extremely complex and so it must contain many different ideas. Furthermore, software design is inherently easier than other fields because it’s based on mathematics. An example Stallman gave was an if-then loop. When a programmer creates an if-then loop, they know exactly how it’s going to work. They don’t have to worry about electric charges, heat or the mass of the computer the if-then loop is running on. This general ease of design makes it possible to include many different ideas, which in turn create more points of patent vulnerability.

Near the end of his talk, Stallman described the problem of software patents in terms of music. Imagine if any sequence of chords, particular melody or rhythm was patentable. Now imagine how Beethoven, The Beatles or Bob Dylon would be able to write music. This is analogous to the current situation in software design.

What Can Be Done About It?

From the flyer distributed at Richard Stallman’s talk:

The European Parliment voted in September for strong restrictions on software patents. But these are in danger of being set aside at a meeting of the EU’s Competitiveness Council of Ministers on 10 November. Senior patent officials from across Europe are already trying to “negotiate” a script for the meeting to follow.

If UK ministers cannot be convinced before 10 November, it is believed they will push strongly for the Council to adopt a November 2002 draft text, which is even worse than the infamous McCarthy report. The European Parliment’s rules for second reading make it very difficult for MPs to fix a bad text from the Council.

The FFII is calling on supporters to send letters and faxes to MPs as soon as possible, or even better to MPs in person, to tell the Government why software patents are a bad idea, and how particularly bad the November 2002 draft is.

More information is available at Foundation for a Free Information Infrastructure UK and softwarepatents.co.uk.

Mac Notes

Update: There’s still no built-in keyboard shortcut for Zoom in OS X version 10.3, but you can now easily add it using the Keyboard Shortcuts tab of the Keyboard & Mouse System Preferences. This is a very welcome addition to OS X.

Making Computer Science Fun

I don’t talk much about computer science on unraveled, but a recent lecture I heard by UCLIC director Harold Thimbleby got me thinking.

His lecture started off by describing science as generally boring. However, there are many ways to make it interesting. For example, to make chemistry interesting, you can create flashy chemical experiments. To make physics interesting, you can pull out the Van de Graaf generator and play with static electricity. But how can we make computer science fun? It’s not common to demonstrate computer science in the same way that we see more established sciences such as chemistry and physics demonstrated, but there are ways to do it. And it’s extremely important that we start doing it more often.

We’re surrounded by technology, but very few really understand it. Because computers are generally difficult to use, training often ends up accommodating poor design. This only leads to a misunderstanding of what’s going on and continued poor design.

So how do we create a better public understanding of computer science? Harold suggests that we stop trying to understand computers by using them. Instead we should unplug them, discuss the key principles involved and participate in hands-on activities to discover how they work.

A simple example that he included in his lecture was Count the Dots (PDF). In the activity, the participants learn the basics of binary numbers by using a series of cards with dots on them. It’s an easy demonstration that shows you don’t need a degree in computer science to understand how computers represent and store information.

This is just one example activity; there are many more available from the Computer Science Unplugged project that Harold referenced. I think it’s a project whose time has come. So let’s stop using computers for a moment and start understanding them. In turn, we’ll design a better future for everyone.

Don Norman, Door Locks and Dance Clubs

Don Norman took some time away from User Experience 2003 London to talk to UCLIC students and faculty about his recent theme of emotional design. Most of what he talked about is in the aforelinked essay, so I won’t get into any specifics, but I would like to summarize his main points. In a nutshell:

It sounded good and reasonable to me except for the business point, which is something I’ve been thinking about a lot lately. I may have more to say on that another day.

The night before his talk, I thought I’d page through The Design of Everyday Things for some pre-lecture inspiration. A few hours later, while walking through my residence hall, Langton Close, I realized that I could finally unlock all the doors without thinking much about it. This inspired me to write an essay on door locks which I present here in shameless Don Norman style:

Generally, mechanical door locks are horribly designed. When I checked into my new student accommodation for the first time, I was handed a set of three keys: one for the reception door, one for my flat door and one for my room door. Each lock works in a completely different way. The reception door lock must be turned slightly clockwise to be opened. When I arrive at my flat, the door lock must be turned counter-clockwise half a rotation to be opened. Finally, my room door lock must be turned a full counter-clockwise rotation to be opened. On top of these differences, the key must be inserted with the teeth pointing in a specific direction (depending on whether you’re locking or unlocking) and returned to a position in order to be released, which may or may not be the same position that it was inserted.

In order to use all of the doors seamlessly, I have to remember all the differences between the ways they work. When I first moved in, I fumbled around for a few seconds at each door. But after living here for three weeks, I’m finally able to unlock each door without thinking about it much.

Why should it take me several weeks simply to lock and unlock doors? Clearly, there is a widespread design flaw among door locks: a complete lack of standardization. In The Design of Everyday Things, Donald Norman notes a key advantage of standardization: “No matter how arbitrary the standardized mechanism, it only has to be learned once.” If door locks were standardized, I would hardly need to think when opening each door lock. Additionally, I would be able to use the same locking/unlocking technique on every mechanical door lock in London! Unfortunately, this is not the case.* Door locks are made by thousands of different companies, each with their own unique design. Perhaps someday, more lock makers will realize the benefit of standardization, more door locks will work the same and people will operate more mechanical door locks with ease.

On a somewhat unrelated note, the night after Don Norman’s talk, I had my first London nightclub experience at Fabric. It was about what I expected: excellent music, great atmosphere and absolutely friggin’ packed. I stayed from 10-2, when I got smushed like a sardine and decided I’d rather die on the streets of London than get trampled by a mad rush of clubbers. And I’m sorry, but moving around in a 2 square foot space is not my idea of dancing. What can I say? I’m a dancing machine; I need more space than that.

*Increasingly, electronic and keycard door locks are becoming more common, which are generally sometimes easier to use. However, their use is far from prevalent, and it appears mechanical door locks will be used for many years to come.

HCI as Science

We had a great lecture/conversation with Paul Cairnes today on HCI as Science.

According to Thomas Kuhn’s Structure of Scientific Revolutions, science works within a paradigm and has phenomena, methods and questions. Paul argued that if HCI is to be considered a science, it needs a paradigm. As the class identified, HCI has plenty of current phenomena, but due to advances in technology those phenomena are radically changing and continue to change. This is a strong contrast to traditional sciences such as chemistry and biology where phenomena are generally static. Since HCI phenomena are constantly changing, HCI is constantly moving into new domains, redefining itself and absorbing new types of technology. Basically, there are no static phenomena so there can’t be an HCI paradigm. Furthermore, since there is no HCI paradigm, HCI is not a science. Paul concluded by saying that if HCI is to be recognized as a science, it needs a proper theory.

The second part of Paul’s talk lecture dealt with Karl Popper’s theory of falsifiability which says that science is justified through falsification (being proven false). If it’s not falsifiable, it’s not science. Therefore, according to Popper, if HCI is a science it must have falsifiable universal laws. There are a few examples of universal HCI laws such as GOMS and Fitts’ Law, but compared to the established sciences, we find HCI generally lacking in such laws.

So if HCI fails both Kuhn’s and Popper’s definition of science, what is it? Paul suggested an interesting way to look at it: usability (HCI) is a privative. If we say “this system is usable,” it’s falsifiable by any one instance of unusability. In other words, usability is the absence of unusability.

So why does it even matter if HCI is a science? Does anyone really care? Well, as Paul noted, after we graduate we’ll be masters of science, not art or philosophy. There should be a reason for that. Furthermore, he said it’s good for HCI be considered a science because science was practically the only measurable form of progress in the 20th century.

So what do you think? Is HCI a science? Does it matter? Why?

Safari Form Autorestore

Because Safari has crashed one too many times while I was typing into a form field, I would absolutely love it if someone - maybe even someone on the Safari team - could give Safari the ability to restore form data that’s lost after a browser crash. Word has autorestore, why doesn’t Safari? Now go to it LazyWeb.

← September 2003 | Archives | November 2003 →