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

List:       kde-devel
Subject:    Re: Improving our user interface
From:       Christian Czezatke <e9025461 () student ! tuwien ! ac ! at>
Date:       1998-01-19 22:36:43
[Download RAW message or body]

Hi!

On Mon, 19 Jan 1998, Preston Brown wrote:

> While this is not something we should think about before Beta 3, it does
> serve to get the creative juices flowing.  This guy has some good points
> about us not falling into the trap of copying too many things from
> microsoft and other existing GUI interfaces.  Everyone should read this.

Thanks for pointing that out! 

> 	(b) launching apps: many programs take a while to come up.
> 	    Bigger programs take longer.  It's a problem.  Mac and
> 	    Windows addressed this problem with splash screens.  Gives
> 	    you something pretty to look at while you're waiting.
> 	    Also addressed with progress bars... gives you something
> 	    to concentrate on while you're waiting (sarcasm). 
[snip]

This is a good point! I've already pointed that out on kde-look quite some
time ago. -- The more general guideline for this should IMHO BE:

   Provide _immediate_ feedback to the user.

This is really something that KDE is not really perfect in at the moment.
-- Just try to launch Applixware or Staroffice from an X-Terminal running
KDE. (Where you don't have the feedback of your harddisk going mad as the
app comes up). 

Matthias started to implement something like that in kpanel I, but it was
thrown out in kpanel II (for technical reasons, I suppose). 


[snip -- about tasks that could go on in the background]
>           As
> 	    Sirtaj pointed out, the main piece of information a user
> 	    needs to have is if there is a problem with a
> 	    transfer--fine!  If there is an error then slam as many
> 	    obnoxious dialogues in his face as you deem appropriate,
> 	    but then I'm sure, Sirtaj, you'll agree there is no need
> 	    for a dialogue with a successful operation, right?!  With
> 	    NeXT, in the modeline there is a small progress bar (or
> 	    text?) that you can watch if you want, but the key thing
> 	    is that if you tell it to do such-and-such an operation,
> 	    it says OK, and gets out of your face and does it.

Generally speaking, not providing feedback when an operation completed
successfully is the "Unix way". But I'm not sure if this is really such a
good idea for a GUI. 

As for NeXT, I had to program under (and use) NeXTStep/intel 3.2 at the
university for a semester. Altough I think that this was quite a valuable
experience that I don't want to miss (the students can choose between NeXT
and Delphi/NT nowadays -- and 90% of them choose Delphi/NT, arrgh...), I
have to admit that I didn't quite like the NeXT user interface.

For example, it was quite interesting to watch someone copying something
to the floppy. -- They hit some secret hotkey (<CTRL>-<P>, as far as I
remember) and a "background process" window popped up. While sitting in
front of the computer (and _waiting_ for the files to get copied) you did
nothing else but wait for the copy operation disappear from the
"background process" list. (After that you had to "eject" the floppy to
actually flush the buffers to the floppy). 

The more general rule should IMHO be:

  Everything that is launched from within a GUI should be represented
  somehow within the GUI as long as it is running. 

Whether the representation is provided by a dialog box or a tiny image
that is docked on kpanel is IMHO not the point, but it should IMHO be
represented on the desktop somehow.


> 	    However, all of these are easily
> 	    solved--here is how NeXT solves these:
> 
> 		(a) there is a dialogue if there is an error,
> 		(b) there is "Inspector" to monitor processes that are
> 		    in-progress if you are really concerned about it.
> 		(c) the old and new locations are greyed-out until
> 		    they are completed

Sounds interesting. -- Altough I cannot remember NeXT 3.2 doing that (but
my "NeXT semester" is quite some time ago now...).

> OK--this is a long email--I appreciate your attention if you're still
> with me!  Let me just make my final point, and thus hopefully explain
> better my previous "KDE blows" remarks: I think that what we're
> looking for is for ppl who use microsoft b.s. to take a look at
> KDE/linux and say "Damn, this is very nice!  I guess things *are*
> greener on the other side of the fence".  The current KDE (beta 2),
> would elicit, fairly, "Hmm... very nice for unix--very usable--but
> win95/nt does x, y, z nicer.

Sounds somehow familiar to me... :-(((

> To accomplish the
> more favorable opinion, one needs to go beyond immitation and come up
> with *better* ways of doing things (of course!).  I hope my remarks
> help y'all in thinking of what these might be.

Agreed. -- But judging form this email, is a danger of imitating NeXT...
;-)

In my opinion KDE development can somehow be compared to what I would like
to call the "Japanese Leica" phenomenon. 

I don't want to offend anyone, but this is the story you get told about
the success of the Japanese photo industry here:

At first there was the Leica, a really good German camera. 

During the first phase Japanese enterprises started off with taking the
original Leica and cloning it bit by bit.

In the second phase they started to add improvements to the original
model. So they ended up with a product that was superior to the original
model and had a smaller price tag which brought them large market shares.

IMHO "stealing" features from existing products is a viable strategy when
you enter a market quite late because it gives you a competitive product
in a rather short time. But of course just cloning cool features from
other products won't lead to long-term success (unless you are _that one_
sw company... ;-))

I consider KDE as still being in the first, the "cloning" phase, but it is
now approaching the end of that phase. Whether or not a transition to
the second "improving" phase can be made will IMHO be crucial for the
long-term success of our project. (But I'm _very_ optimistic).

Sorry if this email got a bit "philosophical" but IMHO there is a danger
of loosing the sight of the "big picture" during the daily hassles of
fixing yet another KDE-Beta bug... 

     Christian

--------------------------------------------------------------------
| Christian Czezatke, Student of Computer Science at the Vienna    |
| University Of Technology.                                        |
|------------------------------------------------------------------|
| email: e9025461@student.tuwien.ac.at                             |
--------------------------------------------------------------------

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