Thursday, October 27, 2005

Usability Bugs and New Developers in KOffice

In a recent blog I mentioned that we now have a Usability component for all KOffice applications in the KDE bugzilla.
The nice thing about these bugs is that, in addition to making the application easier to use if they are removed, they often are pretty easy to fix. In other words, they are perfect Junior Jobs.
Junior Jobs are what we call bugs that are easy to fix, and therefore well suited to new developers. The are a great entry into the often quite complex programs. In Bugzilla, they are marked with JJ: in the title.
In KOffice, we have started to collect these JJs in a special web page at the KOffice web.
So if you are a future KDE developer and agree with us that KOffice is where it's at, then please go to that webpage and pick a task that you like. We will welcome you with open arms. You can also go to #koffice on IRC and talk to us almost 24/7.

Sunday, October 23, 2005

Kids Office part 2

When I blogged about Kids Office almost a month ago, I only wanted to present an idea that I had when I took a shower. It was the kind of idea that often comes to my head in lots of different situations.

I had no idea that it would generate such a big interest from a lot of people. I have received 10 comments on the blog alone, and numerous emails. Some people wanted to know if this was just an idea, some provided feedback on the GUI or the basic concept, and some wanted to know when it would be ready.

Curiously enough nobody offered to help with the coding. :-)

Anyway, it is nice to see that I might have stumbled on something that might actually be of use to people. One of the commenters said: Forget the children. Make this for my 58 year-old mother. Perhaps he is right, perhaps this would also be good for those who don't like to use computers, or are afraid of them.
Not one to let good feedback go to waste, I contacted Danny Allen again, and we discussed what we could do about it. We figured that our target group, kids of age 8-10, wouldn't need a full office suite. A writer application and a drawing application would be enough.

So here is the concept of DrawUp, our drawing application that he came up with. It reuses the button bar that we recognizes from WriteUp, and replaces some of the word processing tools to the right with tools more suitable for a drawing application. Here is the application mockup with an empty document:



It uses the same GUI concepts as the word processor described in my earlier blog: large icons, helpful colors, and less features than the full application. It also introduces some other simplifications. Like for instance this:



When you create a new object, you have some easy choices: a circle, a square, freehand drawing, a star, etc. But Danny came up with the concept of a Magic Object. It is a place holder that can be put on the drawing canvas that is like a template for some not so common objects, but still not uncommon:



After you sized and dragged it, you can remodel it into any shape from the magic object palette. The reason for this idea is that we don't want to create configure dialogs for the objects. The way that Karbon and Inkscape does it now is to have, for instance, a polygon tool that can be configured with number of edges. That is too complicated for the small kids that we want to give this tool to.

When you select an already created object, you can transform it in a number of different ways: its' color, the line type, etc, just like in any drawing program:



The difference with DrawUp is that we have tried to make everything as obvious and transparent as possible. Like this, for instance. Notice the lower right corner, where the fill color is shown as the current property to edit. You won't get much clearer than this:



Finally, here is the New / Open dialog. As before, you can you can create a new drawing from a number of simple templates. And you will of course have a preview of earlier created documents.



And finally some words about the implementation. If you want this to become a reality, please volunteer your time and skill. The current engines of KWord and Karbon are great starting points, and both of these programs will probably be little more than new shells (skins if you like) on top of them.

If you volunteer to help with Kids Office, I can almost guarantee you your 15 minutes of fame. I have been approached by magazine editors who wondered if I was implementing it already and when it would be finished. So don't hesitate or be shy. You can mail me or Danny, and you could go into #koffice on irc where we hang out sometimes.

Wednesday, October 12, 2005

Usability and Bug Reports

Well, like a number of other bloggers have already noted, KOffice 1.4.2 is now officially out the door. We have done a lot of fixes, and especially in the support-for-OpenDocument and Karbon departments.

One of the things that we have started to take seriously during the development for 1.4.2 is usability. Usability of a product is a measurement of how easy it is to use. This usually mean applying the Principle of Least Astonishment.

You should provide the user with actions that he or she expects from a certain button or menu item and you should provide the user with the GUI items that he or she expects where he or she expects it. This is not so easy as it might sound. Especially in a highly integrated application suite you need to take several levels of usability into account:

1. You should provide the features that a certain application needs and in a place where the users that have used other similar products expect it. Like, for instance, the style manager in KWord is expected to exist under the Format menu.

2. You should provide the similar actions for all applications in the office suite at the same place. An example of this is that KChart suddenly got a Format menu at all, something that didn't exist before. Previously configuring a chart was under the Chart menu.

3. You should provide compatibility and integration with your surrounding environment, in our case KDE.

Sometimes these 3 levels create conflicting demands that have to be resolved. And sometimes there are many ways to do one thing and maybe no best way.

We think we have covered some distance already on this, but there is still much to do here. So to make it easy for people to show us where we have gone wrong, I created a "Usability" component for all the KOffice applications in our bugzilla. I think that KOffice is first in this regard, which is kind of sad.

Please file usability bugs. I promise that they will be getting a fast review and, if possible, also a fast fix.

At this point I would like to direct my thanks to Alan Horkan who has worked with us on a lot of usability issues. He has previously served as the moderator of the Gnome Usability mailing list, and we are happy to have him on board.

Wednesday, October 05, 2005

Release of KOffice 1.4.2 Imminent Means Much Work for PR Guy

After a long delay, it seems that the ill fated release of KOffice 1.4.2 will become a reality after all.

The reason for the long delay (the release was first planned to be two weeks ago) was that a security hole was discovered. It was kind of tricky, and it took two tries to get the fix right. You will hear more of this in the release notes.

The good news is that we had two more weeks of bug fixing, and 1.4.2 will be even more usable than it would have been without the delay. Especially good is that we managed to fix a compatibility bug with Open Office 2.0beta during the latter part of these two extra weeks. That wouldn't have been possible with the original schedule since OO 2.0beta didn't exist at that time (if I remember correctly).

Since this release is pretty substantive for a bug fix release, I want to make a big media splash with it. It's also well timed in relation to the Open Document debate that has been going on and which I wrote about in an earlier blog. So what do I have to do for a release like this? Quite a lot, it turns out:

1. Write release notes and changelog -- of course
2. Ask Kurt Pfeifle (pipitas on irc) to put together a klik package of it.
3. Write an article on the dot.
4. Write an article for slashdot and perhaps other geeky news sites as well.
5. Contact the marketing working group and get their cooperation in trying to make non-geeky news media run the story.
6. Write news item for the KOffice web site.

So why would I want to make this much noice about a simple bug fix release? Well, first of all, I take my job seriously. If I am the PR guy for KOffice, by golly, people will hear about KOffice. Second, I think that our biggest problem right now is that not enough people have heard of it. If more people knew that there is such a thing as KOffice, more people would use it. And third, this is most likely the last release before 1.5, the release that will bring full support for Open Document, using it as the native file format. So we have to make people aware of it now, so that those who need full Open Document support have heard about it before and can start use it once it arrives.

A general rule in marketing is that people like things that feel familiar more than new and unknown things. So my strategy right now is to make KOffice a household word in the Linux and Open Source world. Open Document is the next big thing, and I want all news articles to mention Open Office / Star Office and KOffice when they speak about Open Document.

So far, this is going pretty well according to plan.