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

List:       koffice-devel
Subject:    Re: Question about your KPresenter's review
From:       aleXXX <alexander.neundorf () gmx ! net>
Date:       2002-02-09 23:20:27
[Download RAW message or body]

On Saturday 09 February 2002 20:34, Eric S. Raymond wrote:

> 3. Need to double click inside box to add text, then click away to see
> the box again and end text type-in mode.

Yes, the double clicking is annoying, I think this is almost the only place 
in KDE where it is required.

> 5. Cannot selectively change format of text.  For instance, Word-like
> buttons for boldface, italic, or underscore only operate on all text
> in a box.  If you need to treat different portions of text on a slide
> differently, you need multiple text boxes.  Help doesn't explain this.

???
Select the part of the text which you want to format, change the formatting, 
done. As in any other app.

> 7. Limited special effects.  Why no blinking text?
> 8. Cannot associate MP3's or sound effects with a slide.  Why not?

Because nobody implemented it ;-)

> 9. New view command opens a new K Presenter window.  That is misleading.

Well, there where lengthy discussions about this topic, and the meanings of 
these things ("mew view", close, quit, etc) were clearly defined.

> Eric again:
>
> Cathy apologizes for not having sent this sooner.  I have a few remarks
> of my own to add.
>
> 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).  What it
> gives away is format transparency and hackability with standard tools.
> This loses much more than you have gained.

Well, people who want "hackability with standard tools", probably you mean 
the standard unix text proc. tools, are probably able to untar the file. 
After doing this, they don't look at the "bits", they look at plain text and 
png's.
End users don't use grep, sed, perl, whatever.

> It's not a good response to answer that all one has to do is untar
> the file and look at the bits.  One might as well argue that struct
> dumps are just as good as XML because after all one only needs to
> write a trivial C program to inspect them.   Format transparency
> means transparency *to a human eyeball on casual inspection* -- a
> plain-text, self-describing format.
>
> Format transparency is valuable in many ways.  It means programs can
> cooperate more easily without having to know each others' internals.
> It enforces a valuable discipline on programmers -- if your data format
> is too complex for a human eyeball to grok, it is very likely too complex
> for you to maintain.

Yes, of course.
But the format *is* based on open standards, tar, gz, xml, png.
My girl friend will never even think about caring of the format of the saved 
file, neither my mother or sister.

> I should add that Kpresenter is not the first time I have tripped over
> an ugly data format in KDE.  The KAB format used by the address book
> is *extremely* nasty -- a poor, cobbled-together kluge.  I know because
> I have written a program that writes it, translating from Microft Outlook
> addressbook exports.
>
> Seeing this kind of bad design makes me uneasy about the KDE code in
> general.  When all your data formats that I have investigated look as
> ugly and poorly thought out as this, what am I to think of the code
> behind them?  

Well, many file formats are xml based, the format of the .desktop files is 
standardized with Gnome, I consider the format of the koffice files not bad.
Sure there may be exceptions.

> It looks far too much as though you have concentrated
> on surface gloss without thinking carefully about architecture and
> design principles and flexibility for future modification.

Well, I suggest you look at some code before you make such statements.

> 2.  Failure to follow basic principles of good UI design
>
> And, at least with Kpresenter, you have not gotten the surface gloss
> right either.  When I open Kpresenter on a document, the main screen
> shows me:
>
> 1. Ten pulldown menus
> 2. Fifty-nine icons
> 3. Six different toolbars, five horizontal and one vertical.
>
> I do not have to look any further than that to know that the user
> interface is going to be a mess, and was designed by a geek with no
> feel for ergonomics.  From an end-user's point of view this is
> *impossibly* cluttered.  

Yes, right. My first action is also always to disable some toolbars.

> It's like a bad parody of Microsoft Windows,
> or rather what Windows would be like if Microsoft didn't do any
> end-user testing (that is, an even *worse* pile of crap than it is
> now).

You know that calling software "an even worse pile of crap" might sound a 
little bit insulting to some people ?

> You guys need to learn the Macintosh way of progressive disclosure.
> The initial screen should only offer basic, common operations, with
> more options unfolding only when the transaction state requires them.
> (For example, none of the text-related icons except "create text box"
> should be visible at all unless the user has a text box selected.)
>
> Here's another one.  You have many pulldown entries that duplicate
> icon functions.  Why?  

Toolbars are optional, all actions have to be accessible via the menus.
How do you want to use a toolbar using the keyboard ?

> 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.
> User-interface design is not rocket science.  It largely consists of
> getting details like these right -- and knowing *why* they're right,
> because you have to be respectful of the end-user's time and limited
> attention span.  Cathy is not a geek; she has more important things to
> do than pick her way though that ugly jumble.
>
> It's not like KDE people *cannot* get UIs right.  Kmail's, for
> example, is pretty good.  The rest of you desperately need to read a

Don't tell us what we have to learn or what we desperately need to read, 
please.
We are always open to suggestions, as long as they are expressed in some 
positive way.

> 3.  Documentation, documentation, documentation.

Well, docs are fine, but another rule says "1. Users don't read 
documentation. 2. Users don't read anything, not even message boxes" (from 
"Joel on UI Design for programmers")

> But the best thing you can do is just stop coding.  Right now.  Stop!
>
> Now go fix your documentation until it is (a) feature-complete, and (b) has
> been tested on end-users.
>
> Now get yourself a nice fascist release manager who will *not* allow a new

Don't use the word "fascist" !!!!

Bye
Alex, who is a bit disappointed from Eric. S. Raymond
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]