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

List:       kde-usability
Subject:    Re: Direction of KDE default?
From:       "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date:       2002-07-26 9:42:05
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 26 July 2002 01:18, Ian h wrote:
> Since most users will be used to Windows 9X/XP , the
> initial setup must mirror that behavior model. This

this is an assumption, and not even a correct one. there is no reason it 
"Must". if it was completely incomprehensible to the user then i'd think 
about agreeing, but that isn't the case.

or are you saying we should start using drive letters? bah.

*watch your assumptions!*

> computer. The most important thing is that KDE hides
> the OS it is running on top of.

another assumption, namely what "hiding" means and given a certain 
interpretation of that word how important it is. this is an emtpy sentence.

> overall) behavior should. As someone said the average
> user is interested in only getting thing done. In my
> mind this means a improved version of what they are
> use too. KDE should be "easier" use for most users.

this is what we are striving for. copying Windows won't achieve this, btw, 
because users don't find Windows easy. they learn to cope with it, but they 
don't find it easy. just FYI.

> By reading tool tips, tutorial and generally playing
> with settings, some of these users will find that KDE
> has better ways of doing things.  For them, setting
> dialogs must be very clear, interactive(immediate
> change on Apply) and most imporyantly be
> non-destructive(restore and default settings buttons).

we don't have config file roll-back, that's true. it would be a useful 
addition, though people don't seem to have too many problems without it since 
configuration changes are immediate and there are default setting buttons.

>  An example of non-interactive action is having to log
> out and back in again to just change the date format
> will frustrate a user.

and where does this occur?

> All file extentions must be set to the apropreate
> install apps.

AFAIK they are. if you could point to individual cases where this isn't the 
case it could be fixed.

this is why painting with broad strokes (which, trust me, has been done a 
hundred times before this) is not very productive.

> In the same vein, devices should be
> competely transparent. Whether using io-slaves or
> auto/supermount the user has to have total control or
> atleast be told why they can be. When it comes to
> pluggable devices, the user must be notified on when
> connected/disconnected. This is epecially important
> whenprematurly disconnected or on a device error. 

some of this is within the range of KDE, and there is development to support 
better mounting GUIs. however, much of it is outside of KDE's scope. we're 
not designing an OS, just the desktop part of it.

> The assciated Application must be able to handle the error
> correctly.

i think everyone agrees that robust apps ar e good. but again, do you have any 
examples of this? examples == bugs == fixable.

> I welcome everyones comments.

i know this email is a little harsh. but it is time to squash the noise level 
bit and raise the signal quality.

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

"Everything should be made as simple as possible, but not simpler"
    - Albert Einstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9QRlu1rcusafx20MRAu+tAKCtBSb7pvJ3LvjEebCp7dirCUSSUQCfZWYu
vdXjVaKzdYLXCc6r6tiBQWM=
=ZuIt
-----END PGP SIGNATURE-----

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]