The office apps I’m using now include OOo (in place of Microsoft Office), OpenProj (in place of Microsoft Project), and Dia (in place of Microsoft Visio). All of my instructors know that I’m a Linux guy, a KDE guy, and that I am definitely NOT a Microsoft guy. I’ve shown them KOffice, as well as the office apps that I’m forced to use currently, and they have agreed to let me use them in place of the Microsoft stuff. My sorrow is because I prefer KOffice to any of the office and production applications that I’m currently using in look and feel, so I’m excited to see my KOffice more stable! I look forward to KOffice being more compatible with Microsoft formats soon so that I can use KOffice on a more regular basis that what I’m able to use it now.

In KOffice things like vector graphics that Karbon uses are actually shared between all applications. You will essentially find that many of the tasks you need are available in Karbon as well as in all other applications. Including KWord. So I do see your point, but KOffice has brought sharing technology to a new level that your example of MSOffice is not even coming close to.
The majority of photo manipulation can be done in KWord too, although actual retouching and manipulations that a gimp or krita can do are not possible in KWord. This is mostly because the Krita guys say they don’t want to allow editing of graphics using the KOffice component system.

Bottom line is that I think KWord is good for this usecase because a core component you need is a physical page size and a straight forward way to place content at specific locations on that page. Which is where KWord shines most.
The integration with real graphics applications is actually pretty smooth and you can even edit you vector graphics and colors and all right from inside KWord.

Now, your second example of using tables instead of kspread thats one example I fully agree with. Not only are KWord tables immature and not all that useful right now, the spreadsheet function is best left to the spreadsheet.

Is it worth spending time on optimising KWord to do what Krita or Karbon do better? Would it be worth spending time optimising KWord to help people maintain spreadsheets in KWord tables, or should we be trying to educate them to use KSpread instead?

ODF isn’t a formant that assures that a document will look the same in two different application. Even between MS Office and OOo is happens that text can have a different length. That’s something that can’t be completely avoided in practice.
Of course ODF compatibility gets improved all the time.

Unforunately that is mostly a Qt problem. We are waiting for Nokia to fix that.

What lead me to do this work is that I had the feeling people that are working on KOffice have been working on stuff they care about but will not really have too much of an impact on how many users will use the apps. For example working on fixing a rendering glitch in a high end feature like drop-caps is all fun, but not all that useful if people don’t want to use the application because much more basic stuff is missing. Being able to hide the toolbox is indeed a good example.

The effect of documenting the milestone “Susan” and the other personas is that we are all clear that if there are no more tasks to support Susan we should focus on making things pretty and otherwise dotting the i’s and crossing the t’s. Making it perfect for one user (naturally without hurting others in the process) will make KWord much more usable for everyone.

I’m looking forward to hitting that milestone, please lend a hand any way you can. Userbase still needs a lot of attention for KWord, for instance

1) I can share ODF documents (text) with any OpenOffice.org user.
Right now not even the simplest text format is not preserved with same fonts. The text is few letters shorter, text is bigger with same font+size and very specific order formated documents gets rendered wrong in KWord.

2) The fonts looks ugly (there came fix for that in the development version (git?) release) and should be better way to be antialiased and managed.

3) My one big visual problem is that the document does not look good in the application. I must admit that the visual look is not so high in the developers to-do list. But it is something what draws normal user attention. The document should have shadow, it should be flexible so it has good space between the application edges and have a flexible space between document pages (possible to tweak to be a 0-25.4mm).

4) Possibility to hide the menubar. Me and my friends have all the needed functions in the sidepanel. The menubar is just taking space, especially in the netbooks what class of portable computers are very much used in schools).

Technical missing features? Not so much, only standard support and the “eye candy”..