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

List:       kde-devel
Subject:    RE: Mousepointer changing depending on OS state
From:       "Markus Holzem" <markus () holzem ! de>
Date:       1999-02-24 14:42:23
[Download RAW message or body]


I'm sending this to kde-devel@kde.org too since there is a
similar discussion going on...

RESPONSE TIMES

It is important to give the user a feeling that the system is
still running. A usability test made several years ago gave the
following results:

* 0.1 second is about the limit for having the user feel that the
  system is reacting instantaneously, meaning that no special feedback
  is necessary execpt to display the result.

* 1 second us about the limit for the user's flow of thought to stay
  uninterrupted, even though the user will notice the delay. Normally,
  no special feedback is necessary during the delays of more than 0.1
  but less than 1.0 second, but the user does lose the feeling of
  operating directly on the data

* 10 seconds is about the limit for keeping the user's attention focused
  on the dialogue. For longer delays, users will want to perform other
  tasks while waiting for the computer to finish, so they should be given
  feedback indicating when the computer expects to be done. Feedback
  during delay is especiallyimportant if the response time is likely to
  be highly variable, since users will then not know what to expect.

(cited from J. Niellsen, Usability Engineering)

No matter what, a KDE application should give feedback to the user how
much time a process will need on an average system (P133, 64MB, I think).

The KDE libraries should provide functions for the watch cursor to
be displayed, when the process is going to need between 1 and 10 seconds
and a progress bar that shows how much of the process is done for
longer periods.

One of the best implementations of such a progress bar for a system
I've seen in CorelXARA where the progress bar is shown in the
statusline. I've attached a screenshot to the mail. Perhaps someone
can make the effort to implement a widget that is capable of showing
such a progress bar in front of the text.

Unfortunately I currently don't have the time to do it :-(

Cheers,

Markus

PS:  The usage of this functionality is not part of the KDE system,
     but part of the application. There is no RUMBA system around
     (Read Users Mind Before Acting) and no other KDE application
     like the WM can guess how long a process will take.

PPS: Even on a 1000s GHz Machine with 1000s GB of RAM there will
     be a process a user will have to wait for... There is not
     much change in response times between a 8086 and a Pentium
     - only the complexity of programs and tasks changed.

============================================================
 Markus Holzem Consulting  Email:   mailto:markus@holzem.de
 Schloßparkstraße 3        WWW:     http://www.holzem.de
 D-52072 Aachen            Telefon: +49 (241) 9800297
 GERMANY                   Telefax: +49 (241) 9800298

 GUI- and Usability-Design
============================================================

> -----Original Message-----
> From: jmkeller@infiniteworlds.dyn.ml.org
> [mailto:jmkeller@infiniteworlds.dyn.ml.org]On Behalf Of James Michael
> Keller
> Sent: Wednesday, February 24, 1999 12:38 PM
> To: kde-look@kde.org
> Subject: Re: Mousepointer changing depending on OS state
>
>
> Christoph Monig wrote:
> >
> > Hello all,
> >
> > in the LA-Times Article mentioned on the KDE homepage I read that
> > the author's only problem with KDE was that the mousepointer doesn't
> > change when he clicks an Icon, and a program launches. I think he's got
> > a point there. It would make things easier if you could see, that KDE
> > was 'doing something' in the background, launching a Program for
> > example.
> > My question is: Is there anything preventing the developers from doing
> > this,
> > or have they just never thought of it ?
>
>
> 	See the problem is unlike WinXX the gui is not tied to the OS under
> it.  KDE is at it's basic state a fancy front end.  Once it's passed the
> application call to the OS, it dosn't have any contact with it till the
> app requests an X window, at which point it wraps a KWM window around
> it.  Even then, KWM dosn't really know about anything other then the
> window.  KDE apps just share data exchange pipelines like the clipboard
> and such and can talk to each other at some basic levels.
>
> 	On top of that, all the OSs that KDE runs on that I know of are all
> true multi-threading multi-tasking - unlike windows - if you had a super
> fast box with lots of ram, your program loaded into a ramdrive, then
> executed - you wouldn't be getting hourglasses either when you click on
> a program in windows.
>
> 	Now, one idea would be an optional animated "program
> launch" pointer to
> the set, that basicaly was say a spinning X for a few revolutions and
> then stoped.  Something toggleable in configuration - to run after KFM
> has launched a program after a mouse click.  This together with KFM
> III's selectable click number should go nicely to making KDE use about
> as intuative as you can want for a 2 year old program.  Windows had how
> long to get here?
>
> --
> ===========================================================
>         James Michael Keller | jmkeller@radix.net
>               http://www.radix.net/~jmkeller
> -----------------------------------------------------------
> Contents (c)1999 James Michael Keller.  All rights reserved
> ===========================================================
>
>

["statusbar.gif" (application/octet-stream)]
["Markus Holzem.vcf" (application/octet-stream)]

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