[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Re: Question about your KPresenter's review
From:       Thomas Zander <zander () planescape ! com>
Date:       2002-02-10 10:41:07
[Download RAW message or body]


On Sat, Feb 09, 2002 at 02:34:44PM -0500, Eric S. Raymond wrote:

> 1. Koffice data formats
> 
> First, I think the design of the KOffice format (tar archive of XMLs and PNGs)
> was a mistake.  Koffice files ought to be XML dumps with binary objects 
> embedded in them in MIME base-64 enconding.
> 
> Why do I say this?  Because the existing format buys only a minor
> increase in space efficiency (none for the existing XML portions, and
> only about one bit out of eight for the binary objects). 

Encoding a png/mp3/whatever inside an XML stream looks VERY obscure in my eyes. 
Plus you forget the fact that the archive is compressed. The gzip compression 
means a huge gain for the xml file. (over 500%)

> gives away is format transparency and hackability with standard tools.
> This loses much more than you have gained.

It is hackable with standard tools; I am surprised I have to tell you its
a tar gzip file since '/usr/bin/file' gives this away.
I wonder how many complaints we would get if the files were huge because 
we do it the way you describe.

Now (with out solution) its easy to replace a picture in a document, embedding 
documents in others is transparent since we can use a directory structure where 
embedded docs are in a subdir, the DTDs are all open (and correctly maintained btw).

Anyway, I hope you won't blame KOffice for choosing a solution which users 
appriciate (and they have) and hackers are able to open up. 
See; its a compromise and IMO a good one.
In the future it is likely we will move to use a zip file as the archive, to come
in line with other unix-using office suites out there. 


> On today's machines, the traditional arguments for tight-packed binary
> formats are specious.  Disks are cheap; processor clocks for parsing 
> and decoding are cheap.  It makes much more sense to optimize for 
> minimizing *human* use of time -- which means transparent data, the
> counterpart of open source code.

Unfortunately bandwith is (still) not as cheap as disk space, sending a file to 
someone else is still almost impossible with documents over 1MB. The text-only 50
page document flatland is 90Kb compressed, and 500Kb uncompressed. 
If we start to talk about spreadsheets the default file gets bigger in a hurry!

> 2.  Failure to follow basic principles of good UI design
> 
> And, at least with Kpresenter, you have not gotten the surface gloss
> right either.

I am a UI designer by trade, and I agree with KPresenters missing that gloss. 
I would like to spend some time going over the UI. But time is (as always) the 
one thing I do not have a lot to spare of.

<...>

> Here's another one.  You have many pulldown entries that duplicate 
> icon functions.  Why?  Sure, users may want pulldowns or they may
> want icons, but they are unlikely to want both at once.  Choose one
> as a default, not both.

Rule number one in menu/toolbar design; put all actions in the menus. Icons
are shortcuts for the menus, and thus always a subset.

But you are right on most other points.


> I hear people tell me that the documentation is behind because KPresenter
> us evolving too fast.  What this tells me is that the developers are
> masturbating -- coding strictly to please themselves, not documenting, and
> not thinking or not caring that the lack of documentation makes KDE 
> frustrating and impossible for the end-users for which it is supposed to
> be targeted.

Ok, let me clear up a misunderstanding here; we have found that geeks are not 
capable of writing documentation. We have also found that there are plenty of 
people very capable and willing to do so. 
In other words; we have people who write the documentation and people who code.
This gives a number of advantages in the way docs _are_ written and UIs are described.

If people say that documentation is playing catch-up then we have to look into
why that is, and not jump to an uninformed and mainly cursing conclusion like
you do up here. Nothing personal though..

> If you think you can win the desktop battle this way, you are smoking crack.
> Don't tell me "oh, we'll get the documentation in shape eventually" because
> that never happens.  The gap between code and docs just gets wider and
> more intimidating as you neglect it.  You need to tackle this *now*.

No, we don't.

First rule of coding; make sure you have a good basis to build on. This is the 
thing being worked on.
Rule number two is that the product you put out of the door is stable. This
is the other thing.
Then a good UI can be created (yes it can be created meanwhile, but alas this
is not a requirement I am willing to ask of the volunteer coders)
After a good UI is created the writing documentation can be done in an intelligent
manner; before this point all documentation is patchwork.


Bottom line; the file format is open, but maybe that needs to be made a bit more
public at sites like www.koffice.org
the example application KPresenter needs some finish, you are right.
Documentation is not something the coders are concerned with, the writers are 
working on the docs.  Its not finished; thats correct; blame us for releasing
too early too often.

KOffice is evolving; and with a team of about 4-10 people I think they are not
doing a bad job. 

Thank you for your opinion.

-- 
Thomas Zander                                            zander@earthling.net
The only thing worse than failure is the fear of trying something new

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]