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

List:       koffice-devel
Subject:    Re: Question about your KPresenter's review
From:       "Eric S. Raymond" <esr () thyrsus ! com>
Date:       2002-02-09 19:34:44
[Download RAW message or body]

Toshitaka Fujioka <toshitaka@kde.gr.jp>:
> I looked at your KPresenter's review page: 
>  http://tuxedo.org/~esr/writings/dragnet/eric-comments.html
> 
> I thank your valuable opinion.
> KPresenter(current CVS HEAD version) can use sound effect
> with all slide.
> 
> I have one question.
> You wrote "The UI is cluttered, inconsistent, confusing, and at times
> capricious." to your page.
> Will you explain it to me in detail ? I can change it.

OK, you asked for it...

Here are Cathy's bug notes on KPresenter.  I have edited slightly for clarity. 
Her feedback is particularly important since she is a real end-user, not a
techie.

Presentation Software:

	Our program was originally prepared, largely by me, in K
Presenter and migrated, during our trip to New York, to Magic Point (by Eric).
I am aware that Star Office has a presentation software suite, but did
not think of it until too close to the time of this presentation.

	K Presenter 1.1.

	K Presenter was extremely frustrating to learn and rather
limited. Most help still unwritten.  Important topics that have not
yet been written include:

1. Description of Kpresenter Screen (which matters because commands are
not intuitive).

2. "Detailed Guides" e.g., "How to perform the most common tasks in K
Presenter, such as "Using the HTML Wizard".

3.Questions and Answers

4. Installation.  Existing help is incomplete.  E.g., How to change the
color of text on a slide.  All the text tells you is "Change the color
to blue by clicking on the dark blue icon in the color palette on the
right side of the editing window (this icon is highlighted in red)."
When you find the icon (which is simple enough despite the confusing
color reference), it opens a window which contains a little rainbow
display that you can use to select any color you want.  This seems to
require clicking the eyedropper icon in this window, and the "OK"
button. but I can never remember the exact sequence for more than 10
seconds at a time. None of this is explained in the "Help"

Navigating through the Help is confusing

1.  Can't use arrows on window bar even though Help window looks like
a browser window.

2.  Need to use links at very bottom of each window.  

Adding text is counterintuitive.

1. Icon for adding text box is difficult to find (and ctrl key
function to do the same difficult to find also)

2. Resizing is limited with text in the box

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

4. There is a command to change the text box size to fit contents, but
it only works vertically.  Text boxes tend to be longer than necessary
and may slip off one end of the slide, which results in centering problems.

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.

6. Fill command confusing.  I have had trouble getting the entire
background (as opposed to just the text box) to change color.

7. Limited special effects.  Why no blinking text?

8. Cannot associate MP3's or sound effects with a slide.  Why not?

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

Magic Point.
Good features (Text editing, sophisticated animation and sound
capabilities.)  Need to get into command line to use sound
capabilities and to create a version of your slide show that will
actually present.  Useful for geeks, not suits.

The answer:  Are we ready?  Not quite yet.  

Just as you want your auto mechanic to make your car run without
forcing you to get into the intricacies of the internal combustion
engine, I, and non-computer professionals like me just want
applications software we can learn quickly and use for our needs.  I
spent 1 ½ hours composing these notes and another 1 ½ formatting it
intelligently for K Word.  No user wants to put up with that.

I started out to make a slide show with K Presenter which turned into
a weekend long odyssey for all three of us.  Most of the reason was
that most of K Presenter's functions are not easy to find or obvious
and are undocumented.

The most important thing in writing applications for non-geeks is that
what you do should be DOCUMENTED, the documentation should be
available on line, easy to navigate, easy to comprehend.  Think: Could
Aunt Tillie learn to use this program in a few hours using the on-line
help?  Could my grandma?  If so, the documentation is probably
okay. Otherwise, it likely is not.

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.

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.

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.

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?  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.

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.  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 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?  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
few good books on UI design, like Jef Raskin's "The Humane Interface"
or Bruce Tognazzini's "TOG on Interfaces", and think about what you
read.  And go look at a Macintosh for a while.  We need to be *better*
than that.

3.  Documentation, documentation, documentation.

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 
version of any KDE component to be released unless the documentation is
fully up to date.

About 70% of KPresenter is unusable to Cathy because it's not documented.
The remaining 30% is much harder to use than it ought to be because it's
not documented. 

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.

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*.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
_______________________________________________
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]