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

List:       kde-usability
Subject:    Re: usability guidelines
From:       Segedunum <segedunum () actuaria ! co ! uk>
Date:       2004-08-05 20:59:48
Message-ID: 200408052159.55099.segedunum () actuaria ! co ! uk
[Download RAW message or body]

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

On Thu, 5 Aug 2004 01:17:39, Mikolaj Machowski wrote:
>  Make a menu item insensitive when its command is unavailable. For
>   example, the Edit->Copy item, which issues the command to copy
>   selected data to the clipboard, should not be active when there is no
>   data selected.

- From the KDE style guidelines:

Menu items should not be added or removed during runtime. Disable or enable 
them instead.

Disable Undo if there is nothing to undo.
Disable Redo if there is nothing to redo.
Disable Cut and Copy if nothing is selected.
Disable Paste if nothing was cut or copied before.
Disable Find Next until Find has been executed for the first time.

I agree, the KDE style guidelines could do with fleshing out, but the basis is 
certainly there. The problem is that many people don't think KDE has style 
guidelines.....

> Why use the Gnome HIG instead of the KDE UI Guidelines? And doesn't the KDE
> UI Guidelines cover all you talked about?

Yes, most of it is covered. However, the Gnome guidelines are currently a bit 
better organised and they have some sensible stuff such as the number of menu 
items to aim for that aren't really in the KDE style guidelines. A lot of the 
examples and real-world methaphors used are really positive, and there should 
always try to be a resolution in an error dialogue box. For example, when a 
floppy cannot be found the dialogue box says "The disk may not be present, or 
may be corrupted. Try repairing the disk or saving to a different one." 
That's a good example of not just leaving a user stuck with an error message, 
although it isn't perfect, as bad advice can actually be worse than none. I'm 
not sure about having a system tell a user to repair a disk, although it does 
ask them to try another one. I think there's a lot of stuff we can take out 
of that approach, and it doesn't have to be hard or terribly controversial.

Unfortunately, the Gnone guidelines have a lot of technology specific stuff 
that shouldn't really be there and they are merely a list of what to do and 
what not to do. It doesn't really explain why things are done, or give 
examples of bad things and it also doesn't really recognise that not 
everything will be perfect. They also have a Bugzilla section called HIG 
Violations, which I don't think is terribly helpful. It is useful to have, 
but it is never productive to nitpick on every detail with UI design because 
you're never going to get utopia on it.

Cheers,

David
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBEp/I53OaWc7M8G0RAlD2AKCoT1t7dGoDX364Y5OKUiTNhhbvnQCggUad
D5zRTZ+wQxi0bLbV4BCDwOM=
=25VE
-----END PGP SIGNATURE-----
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability

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