'Beginnings of a summary of some of the repeatedly occuring topics'

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

List:       kde-usability
Subject:    Beginnings of a summary of some of the repeatedly occuring topics
From:       Irwin <emerald-arcana () rogers ! com>
Date:       2002-05-26 4:57:06
[Download RAW message or body]

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

I'm probably going to end up seeing this disappear admist the traffic but it's 
worth a shot.

I've compiled a quick list of 3 or 4 issues I've seen on the mailing list and 
attempted to put some of the key arguments I've seen into the file, along 
with some possible recommendations (for rather clear issues) or a list of 
suggestions (for issues that are still unresolved).

I know that people aren't in the habit of doing this, but perhaps we can 
rename our subjects accordingly when we change topics?  This isn't common 
Internet etiquitte, but I think it would be very nice for a change if the 
subject line actually reflected the contents of the message. :)  Ahh, wishful 
thinking...

- -- 
- -- Irwin 
(Arcana)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE88HTL4kwAe/yBEAIRAi6wAJ985VOCLd3YvJkcCT8z8bHQS7Yu1wCfWxAY
keBD5slo3+d30PuTlkzeEIc=
=gsg7
-----END PGP SIGNATURE-----

["topics.txt" (text/plain)]

KDE Usability Topics and Viewpoints
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

General Usability Discussions
-----------------------------

1. User Levels

DESCRIPTION: KDE should have user levels to allow new users to be better integrated \
into the environment.  User levels will hide the advanced features so any one with a \
certain level of expertise will not feel overwhelmed by the number of options.

COMMENTS: 
A. Seigo (2002-05-20): the goal should not be to remove things that people aren't \
familiar with (otherwise we may as well remove computers altogether; no one is \
familiar w/computing until they use them for an extended time). rather the goal \
should be to limit those things which are beyond the grasp of the average person.

K. Koehntopp (2002-05-22): Looking at the kcontrolcenter, I am overwhelmed. There are \
far to many switches and dials, and most of them are essentially unused. Most of them \
really should not be there, but go away into some panel which is normally invisible, \
and only available by clicking at some button labelled "advanced".

T. Zander (2002-05-20): The complexity you point at has little to do with the amount \
of features being turned on at the same time.  As long as they have a good default \
the user will never even try to change the features.

<incomplete>

CONCLUSION: User levels do not achieve the intended purpose because users first
have to figure out their expertise.  They never get the opportunity to learn more \
advanced features.  In addition, users of different classes will end up dealing with \
"different" user interfaces which leads to confusion from support lists.

2. Application Plugins

General "Computer" Applications
-------------------------------

1. The Apply Button

DESCRIPTION: The behaviour of the "Apply" button.

S. Edwards (2002-04-16):
Hi all,

A quick question I guess. Consider this:

1. User starts a program (a Firewall program for example).
2. User changes settings.
3. User presses 'Apply' and the settings immediately take effect on the 
system.
4. User presses 'Cancel'. The program exits.

What state is the system's setting in now?

a) Same as before point 1.
b) Same as just before point 4.
c) none of the above.

What do people expect here?

I. Kwan (2002-04-16): 
I think that as soon as you hit 'Apply', you should grey out the 'Cancel'
button.  Notice an application like KControl does NOT have cancel buttons,
probably precisely this reason.

In this instance, I would put the program in the 'Applied' state with the new
user settings that were chosen when you selected 'Apply'. (Same as before
Point 4).

C. January (2002-04-16):
1. Cancel should be called Exit if it exits the whole program.
2. Apply buttons are a horrible addition to dialogs. First of all, most
Apply buttons appear next to Ok and Cancel buttons which close the
dialog...except Apply doesn't actually close the dialog. Secondly, with most
implementations once you press Apply your changes are fixed; pressing the
Cancel button does not, usually, undo your changes. Preview is probably a
better choice for environments where this actually matters (e.g. look and
feel settings). The rest of the time (e.g. with firewall settings), an Apply
button makes little sense anyway.

A. Seigo (2002-04-16):
if anything, i could see the term "Ok" being changed to something more in line 
with "Apply" and "Cancel" as it is ambiguous until one learns what "Ok" 
actually means. perhaps something like "Apply and Close", although that is 
long, would require people used to "Ok" to relearn the interface, etc... 

C. January (2002-04-16):
When I said Preview I actually meant that the button would really preview
the settings rather than change them there and then like the usual behaviour
of Apply.

A. Seigo (2002-04-16):
how do you preview a user agent change in konqueror?

or, to fall back to our original saw: how do you preview a firewall rule 
change?

because "Preview" doesn't apply to all types of settings having "Preview" 
there sometimes and "Apply" there others would suck. additionally, previews 
(if at all possible) should be in the dialog itself. cf: kde3's style and 
color kcms

I. Kwan (2002-05-26):
I noticed that when watching people use a dialog with "OK", "Apply" and "Cancel", \
they usually hit Apply before using "OK" to close the window.  This suggests that \
there is confusion because people are using apply to "be sure" that their \
application's settings are saved.

POSSIBLE SOLUTIONS:

* Rename "OK" to "Apply and Close".
* "Preview" to see changes without saving them, OK, and Cancel
* Status quo: OK = "Apply changes and close window", Cancel = "Cancel all changes and \
close window", Apply = "Apply changes and leave window open".

3. static Window Placement Policies

DESCRIPTION: There should be a window placement policy that places a window in a \
pre-set location on your desktop.

SUMMARY OF DISCUSSIONS:

-Current window placement policies place windows dynamically on the screen so that a \
                user does not know where to find them.
-Static window placement policies will allow a user to predict exactly where the \
                window will be placed so he/she can move it to the desired location.
-Static window placement policies will end up "stacking" windows, which means it is \
more difficult to find them under a number of windows.

-"Paper on a Desk Analogy".  How you arrange the paper on your desk; a new window is \
equivalent to a co-worker placing a new sheet of paper on your desk.

POSSIBLE SOLUTIONS:

* Add an option for placement of new windows in "Center"
* Add an option for placement of new windows in "Upper-left Corner"
* Status quo (do nothing)

Specific KDE Applications
-------------------------

1. kdesktop kcmshell

2. kicker kcmshell

3. KMail

4. Konqueror (File Manager)

5. Konqueror (Web Browser)

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