Killing Microsoft's Clippy with open source

Killing Microsoft's Clippy with open source

Summary: Novell distinguished engineer Michael Meeks likes to use the example of Microsoft's unpopular Office assistant to illustrate why open source is really the best option for software development

SHARE:

...just fix it. If you think about the software cost of some catastrophic blunder, often it would be way cheaper if you could just get in and fix it. I think that is a huge benefit of the free-software industry.

You are focused at the moment on the issue of how you get the look and feel of OpenOffice.org right, I understand. What are you looking for?
The main issue is that, when we have a dialogue — and most Windows systems have the same problem as OpenOffice.org has — what you do is, you have this little canvas, a Visual Basic thing, and you draw a button, and you draw another button and so on.

Now there is really no layout to this. You can't enlarge the window, because it really wouldn't look right. You enlarge things and it would just add grey space or something. If you increase the font size, the thing grows as the fonts grow but, beyond that, there is nothing exact. Modern toolkits, like Java, introduced layouts so it was more like a web page. You see that when web pages resize they can do that.

The real reason it has become a focus is that our toolkit currently looks much like Windows — well, say Windows 95. To improve that we have gone for things that you see in Windows XP. The trouble is that, when you start introducing these new looks, particularly on new different platforms, like Unix or Linux and Mac OS, well...

You know that Mac buttons are huge and have these pulsing backgrounds so the area that you have allowed for your scroll bar needs to be twice as tall and so on.
The problem then is that either you add lots of wasted space for all these different platforms and shapes or it all goes horribly wrong. You scale things and it looks ugly.
So, hopefully, we have now solved that so, if you want to resize a figure, then fine. You just resize it. That is the thinking behind it.

Is it going to be difficult do this efficiently?
It is more of a resource thing rather than about efficiency. For example, take German. Often the words are quite long. The problem is that, when you resize, you have to leave enough space for German screens. 

If you think about the software cost of some catastrophic blunder, often it would be way cheaper if you could just get in and fix it. I think that is a huge benefit of the free-software industry

Did you use consultants for this?
Yes, we have used our internal consultants and we have exercises where we have people doing basic tasks and struggling to do them. And we did hundreds and hundreds of hours and that paid off massively in terms of usability.

If you look at the Windows menu, it shows you can install many different applications on the system, so you wind up with this four-column mess. Then you have to try and find this application that you have just installed and you have forgotten the name of it, and so on. We had a sort of similar tree-hierarchy thing in our menu but then we realised that, actually, this is not a very good ergonomic way of working. So now we have favourites that you can customise very easily and then you can use search and your browser and go through your applications. Then you might be an expert user, in which case you know the name anyway, so you just type the name, hit enter and it runs it. Otherwise you have categories and you can browse it and so on. And then some users find tree views very irritating. And categorisation is sometimes difficult. There has been some really interesting user-interface work there.

So when will it be ready?
This is really a discussion between us and other people working on the code. Now this is a competition between us and other people, but I think ours is a very strong contender. Within the next month I would expect to see it start to move.

Topics: Apps, Software Development

About

Colin Barker is based in London and is Senior Reporter for ZDNet. He has been writing about the IT business for some 30-plus years. He still enjoys it.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

4 comments
Log in or register to join the discussion
  • Lousy is slightly harsh I think

    Thanks for the feedback. The intro's extra 'the' was a mistake introduced at the editing stage so no fault of Colin's and we are fixing it now.

    As for the transcription -- it's hard balance to strike between cleaning up quotes and keeping the structure of how an interviewee speaks. But we tend to favour the latter as it makes for a more interesting interview.

    As anyone who's been in management long enough should know, it's not what people say that really counts in job interviews - it's how they say it - and some of the same goes for journalism.
    Andrew Donoghue
  • Lousy transcription, or does Michael really talk like John Prescott?

    Michael Meeks has a tough job. Anyone who's struggled with making documents not created in the Word interface with Microsoft Office should be able to sympathise.

    - extra 'the' makes the above confusing.

    The example I like to give is "Clippy"
    simon.brown@...
  • Some points

    I took down Michael
    Colin Barker
  • Apologies, not enough coffee & nicotine this morning

    Sorry Colin, I was being too harsh.

    Andrew - Yes, it is the journalist's task to convey the underlying sense of what is being said. It would have been good to see the comments Colin made in answer to my feedback in the original article to give context to the quoted words.

    I was drawn in by the title of the article, but frustrated becauase the point was not well elucidated. I find it hard to maintain enough faith in the quality of the writing to discern the subtext once I've come across a few ambiguous or awkard sentences - my failing.
    simon.brown@...