Views and a Conversion
By Thomas Zander
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 
February 1st, 2011 at 18:10
It seems a good idea to transform word processor into a document editor in one page, this is a much better way to design what people need today, I don’t need to write text and occasionally an image, I need to insert lots of different stuff graphics,etc. Separating the apps for layout and not for task seems good, but I at least spreadsheet application should remain.
About the ms-office compatibility, is really needed no matter what you do, as it is a “layout app” which can content anything, it should be able to content everything inside a ms-office file.
People want to create lots of stuff but also read and share lots of stuff, and without ms-office compatibility, it would be hard to give that guitar score document to a friend, normal people won’t download koffice for opening it.
Performance is important in anything to do, and the first thing that drew me away from kword was it’s performance, I couldn’t pg-down fast through a simple document.
So performance and ms-office compatibility should still be priorities.
Changing the subject, what about all the calligra and koffice split, I Still can’t really understand it, will you release koffice next versions on your own, only kword, will you join calligra?
February 1st, 2011 at 19:58
Hi Thomas,
I really appreciate what your doing with KOfffice, and like the idea of re-inventing what an office application should be.
However, that said, I don’t think that filters for importing documents of other formats actually hurts that and this is a basic requirement for an office program for me and many many others – we want something new, something that enables us to do more, something fun, but we also still want to be able to send things to our friends who dont have this system, or open things that they send us.
I’m wondering if it is possible to add these filters/converters through the plugin system?
February 1st, 2011 at 20:34
Good to finally have some web-facing news from the other side of the split, thanks.
So, grossly simplified, KOffice would aim to differentiate itself from Caligra by having a feature set that isn’t self-censored for the sake of keeping MSOffice compatibility ? Even moving away from ODF alltogether it it can’t handle a hierarchy of guitar scores inside a presentation inside a spreadsheet cell ? And provide a great SDK to create shapes as plugins ?
Those are tempting ideas, and KOffice will hopefully create a compelling niche for itself. I think you need to define a good set of practical goals and personas though, if you want to attract the right people and to not get lost in a myriad of prototype features. This blog post is a step in the right direction, but it is still a bit cloudy.
Alas, I’m sorry I can offer no better than this comment for the moment, as I do not have enough time to work on any office suite. Good luck !
February 1st, 2011 at 21:05
Why have a “suite” at all? Why not have a single application that can put a spreadsheet on an infinitely-large workspace or an A4 page, that can put on that page paragraphs of text in Portrait format or slides in Landscape format? In other words, one app that does all which all the individual suite members formerly did?
February 1st, 2011 at 21:24
I love the idea of using a Qt / KDE based Office suite, especially as LibreOffice (and the former OpenOffice) seem so bloated and don’t integrate swimmingly with KDE
I’d love Kword to really look and feel like a word processor, just now it really doesn’t
I don’t use Kword for exactly this reason, it feels to unfamiliar
Music scoring sounds wonderful and the ability to add in other parts of the office scheme is very cleaver but I’d rather go into a word processing document and feel at home – even the awful ribbon just about manages this
Sorry if this sounds critical but it’s how I feel Koffice could improve in the future
Mike
February 1st, 2011 at 22:23
@Jussi you write that having filters for importing fileformats doesn’t hurt.
I fully agree with that and didn’t mean to give a different impression. The blog was more talking about adding features in the base libraries and applications to support the fileformat more. Even if such a feature goes against the nature of KOffice itself
Specifically, if you import a not native document you will have pretty good conversion rates for the feature set that KOffice does have already. This will not go away.
And to confirm; import / export filters can be written as plugins.
@moltonel
Thanks for the kind words, and indeed the goal is a little as you write. One thing I want to add is that KOffice has no interest of moving away from ODF. In cases where the standard itself doesn’t fully support our features ODF is flexible enough for use to legally put things like a music score in that open document file with a proper fall back for other applications to show our intended result.
Naturally our excellent PDF support stays a viable exchange option too.
@Dotan
a universal application is something that was discussed but decided it would turn out to be too confusing. So instead we created a small set of applications that are specialized in either lots of pages (KWord), in slides (KPresenter) or an infinte canvas (Karbon).
Speaking about code and implementation we cheated and created the one universal application anyway. We called it flake and its essentially the core of all KOffice applications.
This also brings down the amount of work it takes to maintain the applications to essentially only maintaining one library and a set of plugins that are reused in all apps. KWord as an application is reduced in line count to a tiny bit. In fact its got less lines of code than konsole or dolpin. Its ⅓th of the size of marble.
@Mike
I like that you point out Qt and great integration as winning points for KOffice. Which they are! Naturally thats not enough, as you point out.
If you feel KWord is too unfamiliar that can be because of many different issues, there are a lot of problems with the most recently shipped KWord. Bugs in user interface, bugs in behavior. Stuff that leads to frustration if you have to work on it.
I have been using KWord for a month now and have committed some 200 patches to improve its behavior. Its gotten much more usable and it doesn’t frustrate me that much anymore.
Thanks for the feedback guys, love reading it. Keep it up
February 2nd, 2011 at 00:23
Sorry if I misunderstand, but these are the objectives of the KOffice-side of the fork? Whereas the Calligra-side of the fork will continue to aim at MS Office interoperability?
February 2nd, 2011 at 05:44
Not trying to compete frontally with LibreOffice/MS Office seems to be the right attitude to me.
I like the idea to rethink what an Office suite is and should be.
My opinion : user wants to aggregate, share, organize and process thoughts and datas (text, images, music scores…) and produce final documents of any kind with that.
Office suite’s role takes place in the last step : producing final documents of any kind, in the office range (music scores, charts, articles, books, etc.)
The technical aspect is one part of the approach (versatile librairies/plugins to be able to process more data types (e.g music scores)).
But I think some real efforts should be done on the UI/UX part to focus on the workflow (“I’ve some diverse sources on my computer, and I want to produce a document with it”) and fine tune it, to free Koffice from getting stucked in old concepts (one software to create one type of documents).
Use case : I want to write an article. I do some research on the internet, browsing with reKonq. I save some documents on my desKtop. I also collect some bookmarks and notes.
Now, i’ve got all the info i needed : i have to start sorting them.
I use a mindmapping tool* or tree based note keeper* (like the old BasKet : http://basket.kde.org/screenshots/basket-note-pads.png). I drag&drop links, notes, and the files I’ve downloaded in it.
I add some more rich text and titles. Then, i start drawing the outline of my article by sorting all of this stuff. I don’t have to select some text to change a title1 into a title2 : i just drag/drop or press “tab”.
When i’m satisfied with the outline, i configure some general style properties (all titles1 in blue, 16pt, bold) and get the final document. I can still polish it by modifying the page layout, some style locally, etc. and print/send it.
This is the kind of workflow I expect from an office suite (and that’s why I’ve already asked for an outline mode in Kword here : http://forum.kde.org/viewtopic.php?f=96&t=88576, sadly nobody answered if this feature had already been discussed).
Until now, I find restructuredText (light markup language converted in LateX/pdf) more efficient and userfriendly to produce text documents. At least, all my titles1 look the same and are great looking, and I can focus on content first.
Sadly, I’ve no integrated workflow between the mindmapping tool and my text processor (that’s why my mindmapping tool is often pencil and paper).
*I definitly need that kind of tools in an office suite.
February 2nd, 2011 at 11:20
@kboite
First, thanks for the words of encouragement, I loved the overview and description of the workflow.
Using an outliner has long been something that I’d have loved to have myself but nobody has gotten around to it yet.
It will take someone to step up and do it, frankly speaking. The good news is that this is much easier in KOffice than starting from zero elsewhere
February 2nd, 2011 at 15:08
I always thought one of the benefits of FLOSS was that the developers all pulled in different directions, creating a larger, more full-featured program in the long run? Breaking this project apart because some people are paid to create MS compatibility seems very sad to me. Users need this compatibility, and they likely want what all of the developers are adding, not just the developers on one side of this split or the other.
While I am a huge KDE fan, I’m not a KOffice user and I may try it out currently just to compare its direction in the future… Thanks for your work and I hope that you succeed in your goals.
February 2nd, 2011 at 17:03
@lefty
Hey, I want to avoid going too far off topic and so won’t go into details of how we got to this split up. This blog is about how the koffice side goes on with some goals that make it clear where we are heading. Lets focus on the future.
What do you want to see happening in KOffice? Would you consider hacking on a koffice plugin?
February 3rd, 2011 at 02:41
Anyone remember Ashton-Tate’s ‘framework’? That was another integrated suite in which text, spreadsheets, graphics, were all elements of equal rank. It never coped well with the transition to wysiwyg working, but had some challenging ideas.
February 3rd, 2011 at 03:15
I know what I don’t want to see. I don’t want to see kword turned into a music notation software. Not just because music notation is a very complex topic ( see lilypond for example) but because I believe in the do one thing and for it well philosophy. I hope this doesn’t sound too harsh.
February 3rd, 2011 at 06:07
[...] Zander), ведущий разработчик текстового процессора KWord, представил своё понимание путей развития офисного пакета KOffice. [...]
February 3rd, 2011 at 07:22
I don’t understand something, can you share code with calligra so that plugins work for both?, I mean can’t you go into different directions While keeping plugins compatible with each other? As some koffice/calligra are things you can add to a page(music scores, drawings) can’t these be universal?, maybe other plugins can’t, but All possible should be shared between these 2.
Or even more, can’t you make a new set of apps designed for all you say but based totally on calligra code?
Isn’t changing the ui and adding some features enough?
I say all these because I wanted to contribute to koffice when I finished learning c++/qt, but now I’m confused about what project should I contribute in. It would be better if I could contribute to both at the same time.
February 4th, 2011 at 08:38
damian:
Ideally, yes, you would be able to contribute plugins that work in both. And with the code in its current state, a plugin written for one (such as a simple docker) would probably work in another. From a practical standpoint, though, the code bases are going to start to diverge and that will probably mean API changes in the next couple versions. So down the road, that probably won’t be as easy.
Dion:
The beauty of the koffice design is that everything is modular. The music flake is just a plugin like any other plugin If the user doesn’t want it, he can simply turn it off and use the other features of koffice. Similarly, we only need to invest development resources there if someone wants to pick up the music flake plugin and really start to push the boundaries with it. The “one thing” we have chosen to do well is to make the code modular. In fact, it is a little too modular right now for my taste. The design seems to be heavily influenced by the “Design Patterns” programming paradigm which prioritizes runtime modularity and abstraction over code readability and inheritance. The more I get used to it, the more I like it, though.
Everyone:
It’s good to see everyone on here contributing their ideas. If any of you would like to dive into the code, I’ve gotten to a point where I think I can give you some good pointers on how things work and would love to help you get started.
February 4th, 2011 at 12:23
I would love to be able to use KWord for taking notes, with drawings, images, tables etc. Basics are there, but some way to go.
February 4th, 2011 at 13:00
A main problem with KOffice applications is that the way dockers work, they are not well behaved on small screens (mine is 1024x600px), Selceting some object may at any time make the window bigger than the screen, hiding stuff out of reach, making the window unmaximized etc.
February 4th, 2011 at 13:41
@Anders
I very much agree that the dockers are a pain point. When Qt introduced them I’m sure they didn’t expect such usage as KOffice is using them now. Ideally we enhance the system in Qt but in the mean time a solution where dockers are embedded in a scroll area would be very nice to have.
If you have specific ideas please don’t be shy