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

List:       koffice
Subject:    Re: Question about your KPresenter's review
From:       Vadim Plessky <lucy-ples () mtu-net ! ru>
Date:       2002-02-19 0:14:51
[Download RAW message or body]

On Saturday 09 February 2002 19:34, Eric S. Raymond wrote:
|   Toshitaka Fujioka <toshitaka@kde.gr.jp>:
[...]
|   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.

Eric, I can't agree with you here.
On my daily job, I receive a lot of MS-Office originated docs, Word's .doc in 
particular.
One-page "list of people to hire" page sent to me by my boss was 81K (!).
Hopefully format was simple enough, and I was able to opne this doc in KWord.
Now guess what size this doc was when I saved it as .kwd?  Only 4K!.
So I think KWord's format rulez!
I haven't used other KOffice programs too much, therefor can't comment.

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

Indeed, you are right.

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

You forgot about BANDWIDTH.
Every KB sent over the Net costs a lot of money - just because TelCos want 
this money from you.
May be this is not very visible in US when big companies have corporate T1 
lines, and people at home have ADSL or cable modems.
But rest of the world is still using dial-up.
And ideed I pay mcu more money for each document I receive in MS Office 
format, comparing to KOffice.

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

While I agree with you that sometimes KDE has problems with UI, I can't agree 
with you that we should take Mac as a reference.
I interviewed a lot of people around, both technical and non-technical.
Most of them found Macintosh hard to use and not-intuitive.

I believe this is just cultural difference between two continents -  know 
that Mac is perceived as "easy to use" in US.
But it will be HUGE mistake to take ideas from Mac/Apple and implement them 
in similar way in KDE.
Apple is aged comapny, there is no innovation happening there.

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

And here you are wrong.
If "User-interface design is not rocket science" tahn we could have good UI 
from MS, Apple and many others.
But their UI'es still suck. So designing good UI is much more complicated 
than you think.

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

So, buy her a Mac - and that's it.
Why Cathy bother to use KDE in this case?

I am also "not a geek"; and, believe me, I (being a Regional Manager for 
rather big territory, in big multinational company) have a lot of important 
things to do.
And, I stay sticked to KDE because I loose productivity in Windows. That's it.
I can't afford to rebbou Windows because IE again locked my computer.
And to spent 1 or 2 hours cleaning computer from viruses which "sudenly 
appeared" in My Documents folder.

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

Sorry but this is BS.
Many people (me, in particular) do not read documentation at all.
Good software doesn't need documentattion to make "each step" (note: I do not 
speak here about documentation to programming languages, OS'es, etc.)

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

May be Cathy should improove her Learning Skills in this case?..
No offense, just an advise.
Sometimes you need just "stop" and start from a clean list of paper.
For example, after doing Project Management for 3+ years, I still took 
extensive course in it. And it was quite helpful.
At least I can avoid mistakes some CEOs of Fortune 500 companies do every 
day. :-) 

Another example: some people who are well qualified still go to get MBA, 
because they want to go up in their professional carrier, imprrove skills, 
change the way of thinking, etc.

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

Haven't we won already?..   ;-))

-- 

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/

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