Back in July I blogged about the maturity of KWord. Or, more accurately, the lack of that. I attacked the problem head-on of why KWord is not really used for serious work. In this blog I want to revist the issue and show the progress made since then.

First, a little look back. Since the KOffice2.0 release now 2 years ago we made various releases with the 2.3.1 release being the most recent. The amount of features added and bugs fixed in each release is nothing short of amazing. Yet, the most heard complaints are of simple issues. Things that stop even the least demanding users from using it daily. In my last blog I suggested user profiles in the form of personas as means to focus on a solution. And this has had some good effects!

First the unexpected happened; several people disagreed strongly with the goals and wanted to continue rewrites and new features with as goal to make things faster and to implement features required for MSOffice compatibility. This caused discussions and a realisation why we were not making progress like we wanted to; different people were pulling KOffice in different directions.

After this was identified the pieces started to fall into place; we lost a lot of users from our last stable release of 1.6 till now. We lost a lot of developers or potential developers too because the koffice codebase kept on growing and with all the dependencies was not at all easy to compile. Next to that we were going more and more into the direction of a pure office suite. I’ll get back to that later, but I think we have to admit that a pure office suite is not exactly all that exciting as a spare-time hack-project. Many developers are not using a word processor or speadsheet/presentation app often enough to decide to program on it too.

We live in a world where MSOffice is present on the vast majority of office computers. This has lead to the conclusion we need to be good at interoperating with it if we want to compete with it. True enough, but I think the real question we forgot to ask is if we want to compete with MS and LibreOffice in what is essentially a saturated market. Any market share we want is at a cost of those big two.

The way forward for KOffice has been to first re-establish our goals and focus on those. Focus is best described as deciding what not to do. The decision was made to not add features that benefit MSOffice interoperability if that hurts KOffice’ goals. This decision has lead some developers that earn their income with creating exactly that, to fork KWord and take some applications like the databse app and the painting application with them that actually don’t fit very well in an office suite. This splitting of paths is a sad thing, but here in KOffice we are grown ups so we’ll live and a lot of good came out of it too. The positive effect is KOffice can gain focus on our actual goals.

So what are the goals of KOffice?

The concept of a word processor, a spreadsheet and a presentation application are all useful, but at the same time its not exactly a field that is ground breaking and it doesn’t really attract a lot of new users. If you want to become significant; you end up copying MSOffice, and you would not be the first to try.

The vision for KOffice is one where you can become productive and edit plus do professional layout of any type of content. People working in some office create a lot more than just text documents. Look around in soho and you’ll see what I mean.

The vision for KOffice decouples the applications from the content they contain. A word processor becomes a page-layout application. A presentation application has slides and animations.

Then as a separate pillar there are the content types; text, a vector graphics (for your arrows, circles etc), even a spread-sheet shape.

See what we did here? We brought back what it is that people expect from an office suite, but we didn’t get ourselves stuck in that 30 year old concept. With little effort the user can stop using his word processor to, well, edit text and instead she can turn it into a music-score editing application. She can edit and print knitting patterns. The possibilities are endless and since any of those can be provided as plugins to the main KOffice all those add-ons can come from any 3rd party.

Ok, I’m getting ahead of myself. I’ll try to be more clear about the ideas I have of the direction of KOffice in future blogs and if you have some ideas please share them in he comments.

My idea for KOffice is to make a set of applications that help people get their work done by being fun and with those plugins there are unimagined possibilities to get users to have fun and to get more types of work done quicker. Specifically the idea of what an office suite is should be challenged. Its useless to try to compete in an already saturated market by just copying the competition. Just like with KDE4 its much more fun to build a platform that allows both the old and imaginative new usages.

A first step has been made; KOffice is now split up and it moved to git. You will find the core libraries and the applications in koffice.git and next to that is a koffice-plugins.git. These are the new core of koffice and maintained by the koffice developers. Next to this are the plugins that are not (yet) part of the core. Some of them challenge what it is that an office suite should do. The music shape was a google summer of code project by Marijn Kruiselbrink and it allows the word processor to be turned into a musical score editor. Its not finished and looking for developers. There currently already are 6 projects available on git.kde.org; projects.kde.org/projects/playground/office

This split setup has the huge advantage that downloads and compile times will go down significantly. With the first release of koffice after this split and packages are made by distros it also will mean developers can compile and change plugins in a matter of minutes because they  live in their own git repos. No longer multi hours waiting times.

The newly strengthened goal of KOffice aims to make it easy to extend KOffice without having to modify the main KOffice source code. This means that the core devs can focus on making the applications usable while you focus on creating that cool knitting-shape or guitar-score shape for your girlfriend

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.