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

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

Still DNS troubles.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>


Return-Path: <cathy@minx.thyrsus.com>
Received: from localhost (localhost [127.0.0.1])
	by golux.thyrsus.com (8.11.6/8.11.6) with ESMTP id g1E4GHe06404
	for <esr@localhost>; Wed, 13 Feb 2002 23:16:18 -0500
Envelope-to: esr@thyrsus.com
Delivery-date: Wed, 13 Feb 2002 20:28:47 -0800
Received: from hurkle.thyrsus.com [198.186.203.83]
	by localhost with IMAP (fetchmail-5.9.7)
	for esr@localhost (single-drop); Wed, 13 Feb 2002 23:16:18 -0500 (EST)
Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233] \
helo=minx.thyrsus.com)  by hurkle.thyrsus.com with esmtp (Exim 3.22 #1 (Debian))
	id 16bDVn-0007o3-00
	for <esr@thyrsus.com>; Wed, 13 Feb 2002 20:28:47 -0800
Received: from localhost (localhost [[UNIX: localhost]])
	by minx.thyrsus.com (8.11.6/8.11.6) id g1E4PEg01833;
	Wed, 13 Feb 2002 23:25:14 -0500
Message-Id: <200202140425.g1E4PEg01833@minx.thyrsus.com>
Content-Type: text/plain;
  charset="iso-8859-1"
From: Catherine Olanich Raymond <cathy@thyrsus.com>
Reply-To: cathy@thyrsus.com
To: Toshitaka Fujioka <toshitaka@kde.gr.jp>, koffice-devel@mail.kde.org
Subject: Re: Question about your KPresenter's review
Date: Wed, 13 Feb 2002 23:25:14 -0500
X-Mailer: KMail [version 1.3.1]
Cc: "Eric S. Raymond" <esr@thyrsus.com>
References: <200202092346.43050.toshitaka@kde.gr.jp> \
                <20020209143444.A4273@thyrsus.com> \
                <200202122308.47913.toshitaka@kde.gr.jp>
In-Reply-To: <200202122308.47913.toshitaka@kde.gr.jp>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-SpamBouncer: 1.3 (1/18/01)
X-SBClass: OK

On Tuesday 12 February 2002 09:08 am, Toshitaka Fujioka wrote:
> On Sunday 10 February 2002 04:34, Eric S. Raymond wrote:
> [snip]
> 
> > 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 don't think that every user has high-capacity disk and high-performance
> processor. My machine is Celeron 333MHz/HD:20GB/MEM:192MB. ;)

I don't know what constitutes a "high-capacity disk and high-performance 
processor."  However, I *do* know that even low-end machines nowadays are 
very fast and have high disk capacity compared to a decade ago.  I understood 
Eric's comment to mean that "even ordinary machines are fast enough and have 
enough capacity that you don't really need a tight-packed binary format 
anymore."


[text cut here]

> > 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).
> > 
[text cut here]

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

To be fair, though, Eric, this is one design flaw that also characterizes 
Microsoft products--creating three or four different ways to perform the same 
function.  For example, MS Word creates three different ways to implement 
typical commands:  icon, pulldown menu, and "hotkey" (usually the control key 
plus a second key).   Icon plus pulldown isn't too bad, because you are not 
likely to trigger a function by accident that way.  Adding "hotkeys" to the 
mix is worse because you can trigger a function through an inadvertent typo.


> > 
> > 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.
> 
> I'm not a geek. ;p But you're right. I didn't do the study of UI design.

I personally do not think KDE needs to be better at UI than Macintosh (though 
it's a worthy goal to shoot for!).  But you need to be at least as good as 
Windows.  If you are not, Windows users will feel that they have no reason to 
consider switching, even if KDE running on Linux offers a much cheaper 
alternative.


> > 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 wouldn't go so far as to say 70% of KPresenter is "unusuable" to me because 
it's not documented.  But I *would* say that 70% of KPresenter is 
undocumented, and that I spent at least 2 frustrating hours attempting to 
figure out how basic functions worked before I began to catch on.  



> > 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.
> 
> masturbating ?  Hahaha, nice joke. ;) But I can't stop coding. Because,
> KPresenter(CVS HEAD) has a lot of bugs. I must fix these bugs.
> (If somebody does not fix a bug, a bug is not fixed. And if somebody does
> not implement the feature, the feature is not usable. If nobody does it, I
> do it.)
> 
> Of course I'll write a document. But now I don't have a time.

Believe it or not, Eric understands that the KDE office team does not have as 
many developers as it would like to have.  Eric and I both understand that it 
is not possible to fix all problems at once.  What Eric was saying above is 
that, since you have to choose which tasks to handle first, you would be 
better off leaving KPresenter as it is (even with all the present bugs still 
in it!) and finish the documentation, than trying to fix all the bugs before 
going back and doing the documentation.

I agree with Eric about that set of priorities.  Even in its present state, 
KPresenter 1.0 *is* usable if you know what you're doing.   Completing the 
documentation would help users get to the point where they know what they are 
doing faster.

Think about it.

> Thank you for a valuable opinion. I make effort in order to make the
> best presentation software.

Thanks for listening.

-- 
Cathy Raymond <cathy@thyrsus.com>

"The meeting of personalities is like the contact of chemical substances; 
if there is any reaction, both are transformed."  Carl Jung


_______________________________________________
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]