Its been about 13 months since KOffice2.0.0 was released, the first in a series of an office suite that is itself over 12½ years old. What we said in the 2.0.0 release announcement was that it was not yet ready for end-users. One of the effects of that first release is that we have received a lot of attention from various places. Attention that in general has helped us a lot in getting KOffice more mature. But unfortunately we still don’t have a “ready for end-users” label on any of our KWord releases.

This lead me to ask the question; what does it actually mean to be end-user ready. And how do we know when we got to that target. In my investigation towards that answer another question got answered; what is the way to get there (call it a roadmap, if you will).

Back to the question of what is end-user ready. The first thing to decide is who is actually a KWord user? There is a usability concept called “persona” which answers that question. I won’t go into the theory here as thats well documented on more reputable usability sites but personas are a good fit. This quickly lead to the discovery that the KDE community already did the research and we have personas on techbase!

My work is currently limited to KWord alone, which is where my expertise lies as I’m the maintainer of that part of KOffice.

The result of this work is that we now have 4 personas, each a person that has a real name and a set of hobbies and likes/dislikes. If we ask those users what he or she requires from KWord for it to be ready for use we end up with 4 different definitions of what it means to be ‘end-user-ready’.

This actually makes a lot of sense so I went ahead and ordered them into how hard it is to support them (how much work needs to go into KWord to satisfy the user). The full details are documented on the KOffice wiki

Susan is a recreational user with a sharp focus on web and social media, there are only a couple of usecases where she would use KWord as a word processor. Susan would use KWord to make flyers to advertise her upcoming party and send that around as PDF or ODT or just print it. Susan would also use KWord for the occasional letter or for writing her resume.

Matt is a student geology he will be managing a lot of images and place them into documents that can easilly span 100 pages.

Santiago would use a self made template to write his documents and he’d use multiple columns plus floating frames to make his documents. Santiago would use various variables like ‘last printed date’ since being able to get that info out of the doc makes him feel smart.

Berna is an office worker she would have the highest demands for KWord of all.

KWord will start working towards end-user-ready in the order as the users above appear, the first user that can call KWord ‘ready’ is Susan and in usual open source style we will be ready when we are ready. But we will measure this progress using bugzilla where this milestone is defined and tasks that need to be done are marked with the appropriate persona as a target. In the last week I went through all bugs and open tasks and all the important ones are tagged with the appropriate milestone.

This means that if you are interested in using KWord you can check which features are missing by listing the open tasks for the persona that matches you most. I expect upcoming releases to mention the progress that has been made to make KWord end-user-ready for each user.

If you want to help out; please check bugzilla (start on our wiki). Especially the junior-jobs should appeal to new users.

In a previous blog I mentioned a lot of new features we are working on. With the release of the beta the time for working on new features is over and now we are in full bug fixing frenzy.
A question that recently came up in the KOffice community was when we can honestly say that KOffice is ready for the end user. One answer which I personally like is that features that are present should just work. Fully, and well tested. The project I did in the last week was work on list items. I’ve tried to find all the bugs I could on this topic and make sure they all got fixed for the 2.1 release Naturally this includes writing unit tests to avoid them regressing later. And last I think it is only complete with a blog entry explaining the progress KOffice made.

The fixes were mostly focused on getting list items positioned correct as the rest of the features already worked in 2.0.  Right to left lists are a bit tricky and they were basically broken by placing the counter in the margins.

The following ‘before’ and ‘after’ screen-shots of my test document probably show the progress much better.

First the new status and for reference the old one below. (click to see full size)

Counters in 2.1

Counters with bugs

Its been some months since we released KOffice2.0.0, the first official release for the new platform KOffice2.
For common and certainly for advanced office users we made clear that 2.0 is missing features for them. What then, you may ask, is 2.1 going to change for them?
Well, here is what we are working on and what has been integrated into what will become the 2.1 release in a month or two.

Tables
Releasing a word processor without tables was pretty daring, and for 2.1 we did a lot of work to correct this. As part of the GSoC project we got Elvis Stansvik working on this for the whole summer. As this is part of KWord, I was the mentor and near the end we also got help from Casper Boemann. The end result is that KWord can show a huge set of tables based documents correctly. Its important to point out that this is ongoing work; creating new table cells or modifying the shape and look of a table is currently not possible.

Change Tracking
While editing a text document you can always undo your changes and get back to the way your document looked before. But what if you want to show the actual changes made right inside the current document? Or even better, being able to see what your colleague changed in the document over the weekend. This is what change tracking offers and this has been integrated just last week and it looks like we’ll have most of the expected features available in 2.1 thanks to the work of Pierre Stirnweiss. The most exciting part is that this lays the foundations for projects like collaborative editing.

Improved image handling
This has been detailed in another post already, so I’ll keep it short. For 2.1 the images handling has been made faster and we now are much smarter with memory usage so its possible to have image-heavy documents showing just fine even on memory constrained systems and devices.

Continued improvement in OpenDocument Format (ODF) support
ODF is still a huge specification and during the 2.1 time-frame there have been various teams working on testing and improving KOffice to become both better at writing correct and full ODF as well as reading other applications ODF documents. As ODF is a way to inter-operate between different application suites so its obvious that the way to get better ODF support is to collaborate on this front with others.
KOffice has been working at the front-lines with the industry big names for some time now. A recent example is the plugfest in The Netherlands last summer and the upcoming plugfest in Italy where KOffice is well represented.
An exciting initiative is the officeshots which renders an ODF document in all available office applications and shows the output. KOffice has been working with the OpenDoc Society to provide hardware and software support and make sure KOffice interoperability can be verified by everyone.

KFormula major improvements.
The formula editing component in KOffice has seen many upgrades since the 2.0 release. This means that all KOffice applications can now display and directly edit formulas. The GSoC project by Jeremias Epperlein has seen improvements specifically in rendering the formulas much more pleasing to the eye and the editing of a formula is well integrated into KOffice and quite easy to use.

Windows™
At the tagging of the beta1 all of KOffice compiled without problems on visual studio 2008 which significantly lowers the barrier to developer and end user adoption of KOffice. We are still looking for enthusiastic packagers and naturally developers on this platform to help improve the experience for end users.

MSOffice support
Still quite important for many is the ability to open MSOffice documents correctly and the major painpoints are one by one being addressed. Major things like importing text correctly, importing tables and importing images in presentations have been added for 2.1.

Kexi
Although Kexi is continuously developed, we don’t manage to deliver the final version of the application on time. Users are encouraged to stay with 1.1.x series if possible.

Having a picture in your text document is one of the simplest things you should expect a word processor to do. Having good looking images in your presentations, same thing. You should expect that to just work.

Images collection in KWord

The fun begins when you take a look at that “just works” means. For instance, I can have a 1000 page document with one or more photos on each page. Those photos easilly take some 10Mb in memory if they are meant for printing. So obviously the simple solution of just holding your images in memory is out.

Another problem that we see is when a user inserts a photo from his camera into a KPresenter presentation. Then scales it down to only be half the screen width. This means that we’ll effectively be showing the picture at some 15% of its original size. If we want to keep the viewing and moving of things around very nice and snappy, we can’t just scale the image on every repaint, that would be way to slow.

After a couple of weeks of coding we have a quite nice solution in KOffice. I added a KoImageData class which stores the actual image data and is able to dynamically create a scaled down version of that. The actual data we store is in many cases stored in a temporary file on the filesystem and transparently loaded when needed.
This has the directly noticeable effect that if you load a document with loads of images it will be much faster done, and with less memory used. The KOffice applications will no longer parse the image data on load. That will happen later.

My personal usecase is this; I would love to make a collage of loads of pictures of my friends and holidays. And I’d like to do that digitally. Now, when I create a new document in Krita or the Gimp that is full printing resolution of an A4. Then start loading the pictures as layers, it very quickly makes them crash or just get unusably slow.
My ideal solution is that I just start a KWord document where I insert a lot of these images into and I can scale, rotate and move them around very quickly. With hardly any suggestion that I’m manipulating huge amounts of data.
At printing time I’m printing actually to high-resolution images and the resulting PDF can be shown to the printer whom can print it at wanted resolution.
Expect this work work just fine in KOffice2.1

Some 3 weeks ago we released the KOffice 2.0.0 platform to the world. The release feels successful as I look at the amount of positive buzz created on the intrawebs. I did note some questions and concerns came up that I want to address.

This release is marked not for end-users, then why release instead of wait until its done?

A long and winding road

Indeed, we marked the 2.0 release as not for end users. KOffice has for the past decade been an open source project with the concept of “release early, release often”. This is a strategy that works very well for us. It just feels natural. I think we should realise that in the last couple of years the open source audience has changed. When I did a release of an application 10 years ago the chance of that reaching a user that wasn’t himself also a developer was pretty slim. Now I release an application and some weeks later users that may not even use a command line at all can be using it.

Naturally, this is great news. I personally love it that my software reaches a lot wider audience. On the other hand the concept of release early, release often has a mis-match between what is released and what many people expect from it.

We released because we have to release, its the way that has proven to work very well. Enthusiasts should consider to try the release and tell us what they think, help us make it better. Others that don’t want to live dangerously with their software can wait until its ready for them.

What is a “platform” release?

KOffice2 is a new approach to office components. I’ll write a bigger blog about that later. The big new thing in KOffice2 is a component-based approach, so we have, for example, a text component that is the same in all KOffice2 applications. This component system requires a solid base, a platform as it were. We invite 3rd party developers and interested users to look at our office suite from the perspective of how this platform not only allow an traditional office but also allows innovative new usages for them to build on top of KOffice 2.0.

More to the point; we show things like the kids office plugin that shows integrators and distros a proof of concept that KOffice can be tweaked rather severely. The message is clear; companies that package or sell open source software now have another option to consider for their clients. One that we are convinced will have a lot of potential for them.

When will I, the end user be able to use it?

KOffice 2.0 is a stable release. The features we have should be reliable (not crash, etc.). In fact, version 2.0 already has a lot of features no other suite has. At the same time its missing a lot of features you should really expect from an office suite.

The short answer is thus that it depends. If your office requirements are low, you might very much like the 2.0 release. Otherwise we suggest to wait till 2.1 or 2.2.