How to improve OpenOffice’s blood supply

Writing in The Guardian, Andrew Brown wonders why OpenOffice, one of the flagships of the “replace Microsoft with open source” movement, is so bad. It is a question well worth asking, since in most discussions of open source software it is tacitly assumed that we are talking about nothing but a clash of business models and that the software that is on offer from both sides is essentially of equal quality – since if you have enough programmers then they’re bound to produce a product that works, aren’t they?

Roll your own (intuitive) interface

Holding down Ctrl and rolling the mouse wheel is a widely accepted mechanism for zooming. There are two obvious, intuitive mental models that you can use:

1. By rolling the wheel you are moving yourself. So roll the wheel towards the screen to make the screen look closer (bigger), roll away from the screen to make it look further away (smaller).
2. By rolling the wheel you are moving the screen. So roll the wheel away from you to make the screen look further away (smaller), roll towards you to make the screen look closer (bigger).

As Windows software manufacturers we can’t pass judgement on these alternatives: it is our duty to adopt whichever convention is being used by all the other Windows software out there. When there is disagreement, we have to judge which manufacturer is likely to beat the others, and thus which convention is likely to dominate.

So what do you think: will the manufacturers of Microsoft Word (convention 1) beat the manufacturers of Internet Explorer (convention 2) or vice versa?

Hunt the question

For a little light relief, fire up Roxio Creator Classic 7.0 and try using it to burn a CD.

Help reinvented: good news for everyone

Here’s Jensen Harris’s Office UI Blog, which describes the evolution of the user interface in the next version of Microsoft Office: Have you ever tried to use a command that was disabled and couldn’t figure out why it was grayed out? Another feature we’ve added to tooltips is the ability to communicate to you why it’s disabled and what steps you might need to take to enable it.

Cardbox 3.0 has had this feature ever since we launched it. Here it is:

I suppose I should be irritated that Microsoft have independently invented the same feature, but I’m not. The reason is that people don’t always stumble on this feature for themselves, and a certain proportion of our support emails are a tedious repetition of “move the mouse onto the disabled command and see what Cardbox tells you”. If Microsoft Office does it too, and people get used to moving the mouse onto a disabled command to see why it’s disabled, it means less frustration for the users and fewer support requests to us.

Escape from Windows

We make our living from a program that runs on Windows. It is my dearest wish to see Cardbox running on something else. Why? – and how can it be achieved?

I am not actuated by great objections to the Evil Empire’s business methods (doubtless this is a moral defect in me) but Windows is crumbling under its own weight. Every time something is wrong, or over-complex, or incomprehensible in Windows, Microsoft add another layer of complexity to cover it up. For example, Windows has a way of requiring rebooting after almost any software update, however trivial it is. We are told that Windows Vista will contain additional programming to avoid this. I have seen this happen before and it is like finding a piece of rotten wood in your house and covering it up with waterproof paint. The rot doesn’t go away but you can’t see what it’s doing any more. The remedy for complexity is to paint more complexity on top… and when Windows finally collapses we don’t want to be buried in the rubble.

This is why the news that Apple is moving to Intel processors is so interesting to us. Most of the press coverage has been to do with the cost and performance implications of the move but the technical point is the really exciting one. It is already possible to run a limited set of Windows programs on Linux, in a limited way, using a software layer called WINE (I’m told that Cardbox 2.0 works under WINE but I don’t know about version 3.0). Now suppose that Apple puts its resources behind its own CIDER project:

1. Bronze Apple: Get as many Windows programs as you can to run on the Macintosh “out of the box” with no changes. When problems occur, cooperate with the manufacturers to find a way round them that doesn’t harm Windows compatibility. The programs will look more Windows-ish than Mac-ish but at least they’ll work, and a barrier that stops millions of users from even considering the Macintosh will be gone.
2. Silver Apple: Now that software developers know that there’s a worthwhile market there, put resources into a hand-holding project that will help them produce Mac-aware versions of their programs. No revolutionary rewriting from the ground up, just adaptation to the Mac way of doing things so that a Macintosh user doesn’t have to make allowances for an alien program’s origins.
3. Golden Apple: Encourage selected developers to go the whole hog and produce dedicated Macintosh versions of their software. The move to Intel makes the move easier technically, and the Silver Apple level will let the developers gauge the market and plan their investments accordingly.

Result: insurance against a possible collapse of Windows, the removal of an artificial market barrier, and, once more and more programs stop being dependent on Windows, a big opportunity for Linux as well.

And what about Linux? The Cardbox Server already runs on both Windows and Linux, but there are three problems with moving Cardbox to Linux as well: no-one uses Linux on the desktop; we can’t write programs for the Linux user interface because there is no one such thing; and no-one wants to pay for Linux software anyway.

The 0th rule of bug assessment

Larry Osterman’s WebLog at Microsoft refers to an article by Eric Sink called My Life as a Code Economist. Sink’s thesis (endorsed by Osterman) is that it’s not always worth correcting bugs, because it may be cheaper or safer to leave them uncorrected.

Sink constructs a beautiful matrix of characteristics that determine whether you should try to correct a bug.

1. Severity – When this bug happens, how bad is the impact?
2. Frequency – How often does this bug happen?
3. Cost – How much effort would be required to fix this bug?
4. Risk – What is the risk of fixing this bug?

In good business school style, you plot each bug on a four-dimensional chart and use the chart to determine which bugs you should correct and which you shouldn’t.

But the most important question of all is missing:

Question 0. Do you know exactly what is causing the bug, and how?

If the answer is No, do not rest until the answer is Yes.

Can you learn anything from bits?

The overwhelming trend in software today is for everything to go electronic. “I sell bits”, a software publisher friend of mine told me proudly, “I sell nothing physical: my customers download everything they need”. Manuals, according to this trend, are obsolete. Everyone knows that no-one reads manuals.

Now I agree that when you’re looking for something a help file can be a very good thing. Even a PDF file has its uses: if I’m following the “download it and run it without learning anything” approach to software buying, half a dozen pages of PDF may be all I need apart from the menu commands themselves.

But there is an old rule that says that anything worth learning needs learning. And I’ve never really believed that you can learn something purely by looking up specific items in a help file or reading brief descriptions on a screen.