KOffice 2 User Interface Design Competition

KOffice development is currently going on at a tremendous pace. Version 1.5, with Open Document as the default file format, will be released in March 2006, and it is time to start collecting ideas for version 2. KOffice has received a donation of $1000 to be used as the prize in a GUI and Functionality Design competition. So whip out the RAD tools and your imagination and design the next big thing in office automation!

An anonymous donor who cares a lot about KOffice has donated a sum of $1000 USD to be used as prize money in a design competition. The purpose of the competition is to generate new ideas for the user interface of the next generation of KOffice, which is expected to be released around the same time as KDE 4.0.

Submissions to the competition should be GUI mockups accompanied with a written description of the intended workflow with ideas for the design of KOffice 2. See the KOffice 2 competition page for an example of how this could be done.

In case the judges cannot find an entry that is truly best the prize money may be split between at most 3 entries. We do not expect this to happen, though.

There is no guarantee that any suggestion from the entries will actually be implemented in KOffice 2, but we will do our best not to waste good ideas. We also reserve the right to use any idea from any entry.

Our donor said "I believe in the potential of KOffice to become a better office suite than all the others in the market. It would be great for me and society to be able to buy KOffice which is better than Microsoft Office for the total price of 0 dollars."

Small Print:

The judges will be picked from the KOffice developers. Currently, Inge Wallin and Boudewijn Rempt are appointed, but there might be one more to make the number uneven. Those who enter the competition should be aware that there will be no other compensation paid ever, and that all ideas, graphical elements, workflows, etc, can be used in KOffice 2.0 and published under the GNU General Public License. The final decision of the judges cannot be overruled. Any taxes due will be paid by the winners.

Dot Categories: 


by Thomas Zander (not verified)

I naturally expect a lot MS Office 12 clones to be submitted and then discarded because they are not researched enough to ensure the result would actually be better then what we have now :)

by Ami Pro 3.1 (not verified)

Clownding clones and possibly Melissas doggy lounge.

by Dominik (not verified)

Here (http://www.koffice.org/competition/guiKOffice2.php) it says February the 15th, but here (http://www.koffice.org/news.php) March the 15th.

What is correct?

by Inge Wallin (not verified)

The deadline is february 15th. The winner will be announced march 1st. And there is another error that says 2005 when it should be 2006.

As soon as our webmaster is around, we'll fix that.

by Daniel Molkentin (not verified)

Corrected. Thanks!

by annma (not verified)

My mistake, deadline is February 15th 2006!
Sorry about that!

by molnarcs (not verified)

I'm more interested in koffice kids :))) It is one of the best ideas I heard this year, and I think the edubuntu folks would appreciate it very much. I'm curious: have anyone contacted them about it?

by blacksheep (not verified)

Isn't Edubuntu an effort to build a distribution especially targeted to schools, with terminal sharing facilities and alike?
And, at least in my country, the goal to teach office applications to kids is really about teaching them the real deal in order to prepare them for the future and the office software needs to be what their parents use (or at least easily installable -- that's way OpenOffice.org is the selected one).

Anyway, I totally agree that a word processor for kids would be nice. Though I think SDL or some other game library would make more sense. Bill Kendrick, the author of TuxPaint, was working on such a project.

by Morty (not verified)

>a word processor for kids would be nice.

You have to think bigger than that, not for kids but a genereal real simple wordprocessor. But not by doing the usuall mistake, by building one with only a limited set of features. Rather take the whole KWord and put a simple UI on top of it, like the 'kids' mockups. Your core is still a full featured open document based wordprocessor, but you will only utilize a small subset of the functionality. Make it customizable and you can make a whole range of versions customized for people with special needs using only part of the functionality, like 'grandma', 'author', 'journalist' or 'script writer'.

by Ian Monroe (not verified)

I don't really understand the point. If a kid is old enough to be literate and writing enough to require a computer, they're old enough to use a normal software. My first word processor was WordPerfect 6 in 3rd or 4th grade, I don't recall it being an issue. I wasn't creating tables or printing out address labels, but I knew how to write, save, print and spell check.

I suppose if you want to teach like kindergardens or 1st graders to use a computer word processor, a special UI might make sense.

But you know, IANAT - I am not a teacher. ;)

by Meneer Dik (not verified)

This is all very nice, but as long as the print quality is as terrible as it is now (due to font kerning problems) KOffice isn't even usable in real life. Let us please get the basics right first.

I would love to start using KOffice (and I always try out new versions) but the printing quality is still horrifying.

by Torsten Rahn (not verified)

Well you are mostly talking about KWord and you are right unfortunately. The situation will change once KOffice is ported to Qt4 which offers everything with respect to fonts that we would need. But once this is fixed and once OASIS has become a more common file format KWord will become a really shining word processor application: Fast, featureful, easy to use and developed on a clean decent framework that allows it to be extended easily.

by James Richard Tyrer (not verified)

Actually, as the recent discussion has uncovered, it will take more than just porting the existing code to Qt-4.1. It appears that while the new "HighResolution" option will greatly improve text layout that the code will need to be rewritten to use the new: "QTextLayout" class to get true WYSIWYG printing.

by anonymous (not verified)

Why? It doesn't sound all that hard to replace int with double in the existing KWord code, and to replace QFontMetrics with QFontMetricsF. What else would be required that would require porting everything to QTextLayout?

Btw: you always post about fonts and font kerning. Are you contributing yourself to those things in KDE, as a programmer? Would you be the one who will actually do the work to add true WYSIWYG to KOffice?

by ac (not verified)

Yes I believe he has more than once posted and contributed patches. I first thought he was a troll but over time reading all his posts on the dot and elsewhere I think he truly cares deeply about this issue and is trying to advance the state of KDE. This guy has gone up in my estimation.

by Lee (not verified)

My advice, at least regarding KWord, is simple: dump the legacy word processing stuff. Have a long, hard look at how LyX works, and learn from it. Instead of having low-level options like Letter vs. A4 pages, bold vs. italic vs. underline, etc., have better, high-level options like "Book" vs. "Formal Letter", and "title" vs. "chapter" vs. "inline quotation".

Make sure LOTS of templates are included, and neatly categorised, so that people can easily find and begin the document of their choice. Make it even easier to actually write that document, because inserting elements is as simple as choosing them from the style list or the context menu (technical books would have options like "quotation", "callout", "illustration", etc.). Make it possible to download and *contribute* templates easily through an automated and rated version of KHotNewStuff.

Finally, make it really easy to edit these templates, ot to create your own, with a style creation mode, that works like an outliner, and has all the style options like font choices and bold, italics, positioning of elements etc., but that won't let you put actual content in from that mode, so users clearly see the difference in style vs. content, and can manage their styles easily, and contribute them to others.

Perhaps, also, for simple changes, styles could be easily modified in simple ways without getting into all the style mode stuff. So, you could choose to increase the overall size of all the fonts, or to increase the paper margins or make your book double-sided, without actually getting into all the gritty details of what elements a technical book has, and which headings are big and whcih are small etc. This could even be done with template wizards, which would run on startup (for your first book) or later through a menu item.

This sounds crazy to many, I'm sure. But, if you've ever tried LyX for document editing, you know that it's really a perfect way to write documents; the only thing missing is that setting up templates is a nightmare, because it's based on LaTeX. KWord isn't; it has a lot of great style and formatting technology, and I'm not suggesting throwing that away for a second. But, I think it should take its rightful place as an engine that drives styles, and not as a user-exposed thing, where users have to explicitly say that they're typing in 12pt font now, or that this is italic font, rather than "this is speech", or "this is an address", or "I'd like to insert a quotation".

By doing these things, you'll also make it possible to do more things. Obviously, if the word processor understands that something is an address, rather than just an indented block of text in a different font style, then it can do cool and intelligent things for you, like automatically handling address changes from KAddressBook. Or, if it knows that some quotations are included, it could easily generate a list of thanks to those inspiring writers/speakers at the end of the book.

If a word processor is better for writing documents because it knows the difference between lines and paragraphs and images, then just imagine what a document processor could really do, if implemented properly, when it knows you're writing a book, and that this is the title, and that is the first chapter, and this is a quotation, and that's speech, etc. The possibilities and new opportunities are endless. Just think of how it might go down in workplaces too, when secretaries and government document authors realise that they never need to worry about fonts again, and disabled users can have their interface described in terms of chapters and quotations and authors rather than paragraphs and lines and letters.

KWord already has the style mechanisms to do this, so why not use it? Make a document editing tool, and not a souped-up typewriter. Document processing is here, but no one has really done it yet. KWord could be a new killer app that everyone else is just slowly inching towards, if you let it.

by mikeyd (not verified)

Your post says to me that you prefer LyX and have a few problems with it that you feel kword does better. But your problems would be better solved by fixing those issues with lyx. For people who prefer the whole content oriented thing lyx is there. Don't make kword a copy of lyx. Some people want a program that is very much visual, and oriented towards the actual print layout more than the content, and that's what kword is for.
Maybe lyx should be adopted by koffice as well. I know I'd prefer it to become a proper kde program with kioslaves...

Your post says to me that you have never tried LyX. If you want program which is very much oriented towards actual print layout, then you are either talking DTP and then you should use Scribe or some real layout program, or you don't know what you are talking about. The point was not to eliminate WYSIWYG, but to enable us who prefer that logical authoring. And about LyX, those small problems with LyX he is talking about (at least that's my experience and I am heavy user of LyX myself) would mean complete rewrite, throwing out LaTeX and rewriting LyX based on some other printing technique (like FOP-PDF toolchain combined with ODF). I don't think it will ever happen.

by Martin Stubenschrott (not verified)

Wow, that's a great idea. Please write a proposal :)

Although I also have the fear that there will be many Office12 clones around, and one of them will win :(

My suggestion: Please put in a modal concept like Vi has _as an option_.

Once you are used to the vi editior, you really would also like to have the HJKL keys for navigating in a document.

It should be possible to say:
- Default key bindings (like it is now)
- Vi style key bindings
- Emacs style key bindings

Although I know that probably will never happen, let me dream about my proposed favorite WordProcessor.

by Boudewijn Rempt (not verified)

"Although I also have the fear that there will be many Office12 clones around, and one of them will win :("

Highly unlikely. After all, there are at least two dependable people on the judging committee...

by Gr8teful (not verified)

I endorse everything you said, point-by-point. Such pondered and well-written are even rare. Also, it is a source of ideas on which to base an interface project (hint, hint).

But you're going too fast! With luck, KOffice might be improved and become the #2 Linux suite, behind Openoffice. This involves a lot of faith, because the competition is most excellent (e.g., Abiword and Softmaker products).

In that context, I suggest we do the _basics_ very well done. I work with Oo.o on Linux in a Windows corporate environment. Let me say, interoperability is king. I even have to save as "doc" to share memos, letters, specifications etc. People there are not very enlightened, odf is out of question. Period.

So, Koffice _must_ read M$-Office docs as perfectly as possible. Oo.o 2.0 does a terrific job; I expect (and need) no less. I'm all for odf (and use it whenever possible), but in some places there's a Windows culture so ingrained people prefer to pay whatever M$ asks just to keep things as they are, because change is scary to them.

Alternatively, since Oo.o is in the Windows-compatible niche, KOffice might "go for the younger" and work for people/companies with no previous IT structure. I don't know whether or how this would work out.

by Janne Karhunen (not verified)

> So, Koffice _must_ read M$-Office docs as perfectly as possible. Oo.o 2.0 does a terrific job; I expect (and need) no less

Umm; just because OpenOffice 'supports' (something that resembles supporting but does not really work when you need it the most) MS Office formats Microsoft has been able to postpone rollout of open formats for half a decade now. So let's not play their game anymore. And if the money spent on reverse-engineering MS Office formats would have been spent on writing new software we would have one hell of a Open Office by now.

by sss (not verified)

> spent on reverse-engineering MS Office formats ... we would have one hell of a Open Office by now.
and.. nearly nobody would use Open Office. You can drop support of common format only if you have >= 50% of the market, else most people won't consider using your product.

> because OpenOffice 'supports' office formtats ... postpone rollout of open formats for half a decade now.
It didn't postpone anything. These things are independent.

by Janne Karhunen (not verified)

> and.. nearly nobody would use Open Office

For starters yes, but via truly common open format true mass adoption could be reality in not too distant future. With current versions i really can't see that happening as it's really inferior product quality/feature wise.

So, I would have taken the same approach than Linus took with the kernel: no undocumented binary drivers (or even binary ABIs), please.

by Davide Matarese (not verified)

It's not this the point. I can do the same comparition with mp3 / ogg. One is copyrighted, one is free (at most). Who is the leader now?

by Humberto Massa (not verified)

It's patented.

by reihal (not verified)

You do know that Matthias Ettrich founded both LyX and KDE?
So there must be something in what you are proposing.

by tgrauss (not verified)

YES, my dream ...

This way a word (sorry ... document) precessor would be a lot easier to use.

I already use styles and as I can see, Kword is already very good handling them. At least it is a lot easier to use styles with Kword rather with OpenOffice.org. And OpenOffice.org is also a lot easier than MS Office (mainly because of the good documentation of OpenOffice.org).

At work, I must use MS Office 2003 for small reports. I must use chapters and I have never been able to create a style to automatiquely auto increment chapters numbers (I have searched the documentation and never find). I have also tried with OpenOffice.org and founded in the documentation how to do it (but it is difficult for me and I must look at the doc each time I want to create a new document). But with Koffice, it is really a delight. I didn't need to look in the doc for these basic features (even if the koffice doc is truly excellent and is a pleasure to read).

PS. When I was a computer science student, I used LaTeX and I found it a lot easier than any office suite (except koffice). I am really a newbe in office suites.

by Thomas Zander (not verified)

Most of this is already in KWord, and where its not yet, its mostly because the implementation is not working correctly there. Or, in other words, this setup is what I had in mind when I started working on KWord years ago.

You can create a template with ease from the current document, for example. There certainly are good templates missing, but you and everyone can help with that (*wink*).
Styles already do everything you need, including cool things like the 'next style' feature that makes sure that after typing the headline and pressing enter the next line is of the style for that paragraph.
Whats incorrectly implemented currently is the 'styles based on other styles' feature. What this does is that if you change the base style all others will follow. So change the base style to be 1 point bigger and all follow. But that does not work currently.

We will always support people that want to manually set the font size to 12 / bold. We can't force a workflow on them that takes effort to learn, I'm sure we'd loose too many users that way.

If you have more specific suggestions, please post them to the mailing list, or enter the contest :)

by H. Zelle (not verified)

> We will always support people that want to manually set the font size to
> 12 / bold. We can't force a workflow on them that takes effort to learn, I'm
> sure we'd loose too many users that way.

Yet if you stick to that in advance, I fear you have already lost the battle. Openoffice also allows style-based and (somewhat) content-based editing, yet all the interface buttons for layout- and markup-related things make it all too easy to not use styles consistently, and mess up your document if you change the style afterwards. That increases the effort needed to learn a new workflow, instead of reducing it.

Writing in a structured latex-like way takes time to get used to, and in my opinion the only way to get people to do so is to almost force them, if not completely. That does not mean you need to remove all formatting options - latex also allows emphasis and other markup options. It does help to actually name it emphasis and not 'italic', as the two don't need to be the same.

I would love to see competition entries focussing on the ideas discussed in this thread - I think a good start might be to remove as many text markup buttons from directly visible toolbars as possible, and to replace them with style/content related functions. Even if you keep them in the program, removing all the 'bad' functions from plain sight might just do the trick in educating a lot of users.

As for the msword format vs. open document format discussions - my ideal would be a single (command line?) tool that converts msword documents to opendocument format and vice versa. All compatibility work could go into that tool, freeing openoffice and kword developers from integrating it's functionality into their software.

Unfortunately I'm one of many that will only contribute in replying and not in code, but hey, perhaps it will help to form some ideas. Keep up the good work!

by Tom Chance (not verified)

I agree completely. Perhaps put the manual style tools into some advanced menu or dialogue?

So long as KWord continues to be Yet Another Wordprocessor I fear it's only advantages will be the KDE architecture and its speed. Otherwise OpenOffice will always look more attractive.

KWord probably allows me to focus on workflow but I never really noticed that. To me it looks like MS Word or OpenOffice Writer, it invites you to start making bits of text 14pt-bold and to manually adjust every bullet point to the right margin and style. The whole UI should scream "this is how to use me correctly". It should make writing an article, letter, book or random document as easy as possible and make the user immediately aware of how it will help them. It should force me to say "make this a list, and let me configure the style of lists if I really need to", or "emphasise this" which means "use my configured style of 14pt-bold-Dejavu Sans". Good defaults, a clear mainwindow UI and obvious style configuration utilities would really make KWord stand out from the crowd.

Until then I'll battle on with LaTeX...

by Martin (not verified)

Great ideas! So how about this; let there be a "style" toolbar that is an expanded version of the style dropdown list. It should have a buttons for emphasis on/off rather than bold, italics etc. buttons. Also the most important style options for the current document type should be represented. Hide the text-level formatting toolbar by default.

The style toolbar is to be generated from the formatting styles currently defined. So when creating formatting styles in a document template you also choose how they are to be displayed in the formatting tool bar.

In addition: Mark everything that has been formatted using low-level styles by a wiggly underline in a suitable colour, just like the automatic spell/grammar checkers do. (This should be optional of course.)

by Martin (not verified)

I would love a fully document-oriented mode. And I do mean that down to the point where you cannot type two spaces in a row.

When I wrote a 200-page thesis earlier this year, in LyX, I made some last-minute changes just before sending it to be printed. Even though I knew that those changes would change things throughout the document; page breaks and everything, I didn't bother checking the formatting. (And of course it worked perfectly.) That is the power of document processing.

As someone else pointed out; LyX cannot be made a generic document processor without huge effort. It would have to be KWord.

by Thomas Zander (not verified)

Not typing 2 spaces in a row is also a feature that KWord already has for some time. :)
Its part of the autocorrection.

by Marc J. Driftmeyer (not verified)

I prefer Kile to LyX, but utilize both. What is so terribly difficult about installing Macro Packages? The Dummy's Guide to LaTeX/TeX & their many Apps with sections on Kile, LyX, TeXShop.app would be a huge aide in bridging the gap between these powerful tools.

People who use Final Cut Pro don't just point and click. They study workflows, design considerations, so on and so forth.

KWord could leap forward if it were morphed into a Kile-light for its publishing capabilities and a Framemaker-light/Scribus for its DTP capabilities. If they could develop interfaces to enscapsulate the LaTeX Macro Packages and just simply install them and leverage much of their functionality out-of-the-box, then you'd see people taking a stronger look at these tools for the small office consumer.

Anyone wanting to publish novels, journals, etc., should focus on apps like Kile/LyX/Scribus and make sure they continue to grow.

Most people don't write 500 page novels, technical books, but those that do should not see their beautiful tools become less of a focus just so we can get more users who write 5 page papers interested in Linux.

What I would prefer happen is that Kword provided Services, ala NeXT/OS-X, that interact with Kile/LyX and Scribus/Inkscape and with these tools create a suite of smaller tools that address publishing needs for all.

by fast_rizwaan (not verified)

it is very clean and simple, but very featureful. how many of us have tried the free version of textmaker which can be used freely (free as beer) and redistributed unlimitedly.

Textmaker is an alternative, efficient and powerful word processor for
Linux and FreeBSD systems. It starts quickly and contains a huge amount
of features. It is extremely easy to use, compatible to MS Word formats
and comes along in a modern look-and-feel.

you can register (which is optional) easily by clicking "Register & Ordering" button when you launch the program.


install and use:
rpm -ivh textmaker-2005.2.11-3.i586.rpm --nodeps --force


by Vlad C. (not verified)

Since QT 4.1 was recently announced to have a PDF backend, will that make it easier for KOffice to have an "Export to PDF" functionality similar to OpenOffice 2.0?

by Carsten Niehaus (not verified)

You can already export to PDF, it is in the print-dialog. Select the PDF-printer.

by superstoned (not verified)

yeah, but just being able to say 'save as' and then pdf would be better.

and to parent - i don't think so ;-)

by chainik (not verified)

"Save" or "Save as" assumes that you can "Open" the result in the same application. Users would be disappointed if this assumption doesn't hold true. On the other hand, "Export" doesn't imply the ability to "Open".

by fast_rizwaan (not verified)

kword 1.4.2 can open .pdf files, using the file-open dialog. So, Save as PDF is more logical since we can open the pdf file using kword, as you are expecting "save = open" and "export = import" ;)

by Thomas Zander (not verified)

Yes. But not before the 2.0 release of KOffice, I fear.

by Morty (not verified)

Just wondering, is it not possible to do a quick and dirty version of this by using the existing kprint and some DCOP magic? Just to silence the ones wanting the "Export to PDF", who don't know the power of the KDE framework.

by James Richard Tyrer (not verified)

It increases the possible implementations, but doesn't really make much difference. KDE can add what OO has: a shortcut that has the exact same effect as printing to a PS file and converting it to a PDF with GhostScript (which is what KPrint does when you print to PDF).

Perhaps a more important issue is the ability to use a PPD when making a PDF. KPrint has the GhostScript PPD for pdfwriter translated into XML and it uses the XML file rather than being able to access the PPD file directly.

OO can use any PPD file that you want to PRINT to a PDF, but the short cut seems to be able to use only the Adobe Distiller PPD.

Both programs need for the user to be able to choose the PPD that they want to use for generating PDFs.

by Diego Calleja (not verified)

Nice but...

"The judges will be picked from the KOffice developer"

Be sure to include some usability expert too!

by ac (not verified)

Oh god, please no. So-called usability expert is just going to kill the creativity of this project.

by Olaf Jan Schmidt (not verified)

The usability experts from OpenUsability.org are doing really good work for KDE and other free software projects. Their style is totally different from those "so-called usability experts" that you refer to.

by Uno Engborg (not verified)

I think the orginal poster was looking for usability experts, not so-called usability experts.

A group of techies will of course almost always develop something they themselves can use, and benefit from using. That is not always the same thing as making a program usable for people outside that gruoup.

Real usability experts have tools that when applied actually makes the application better for its intended users.

In my experience, techies refusing to see the big picture, is just as often the culprit when creativity is killed.

... which could also be applied, maybe, to KOffice 2: http://www.vorbisinfo.org/openoffice .

Especially the tabs (and also the OS X-like toolbars and sidebars) would be a good thing, IMHO.

Only an idea, of course...

by Martin Stubenschrott (not verified)

wow that's great. I really like this interface idea.