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

List:       kde-devel
Subject:    Re: User Interface guide
From:       Rob Napier <rnapier () employees ! org>
Date:       2001-03-11 4:09:13
[Download RAW message or body]

On Fri, Mar 09, 2001 at 01:24:39PM +0100, Jelmer Feenstra wrote:
> On Friday 09 March 2001 07:17, Greg Turpin wrote:
> > Can we get someone to add this to the kde developers website somewhere?
> >
> > I am thoroughly impressed with this author's comments.  We need
> > to recruit him.  KDE can benefit from a few of his suggestions.
> >
> > Example kicker:
> >
> >    The "start menu" on kicker should be all the way to the left of the
> > screen by default.  You should be able to put the mouse all the way
> > to the bottom left of the screen and click to bring up the start menu.
> >
> > Couldn't agree more with this guy.  The average end user is dumb.
> > Not dumb in a bad way, just in a "I don't want to spend a half an hour
> > learning how to use this feature" kind of way.
> 
> He has a nice way of presenting his thoughts on userinterface issues as well, 
> he certainly made me smile on a number of occasions while reading the article 
> :)
> 
> About what you just said concerning kicker and hitting the start (K-) menu 
> easily; I think it's a very nice feature of windows that if a window is 
> maximized, you can close the window by yanking your mouse to the top-right 
> and hit your mouse button. In kde you are hitting the edge of the window 
> instead of the close button. I for one really liked the fast way of closing 
> windows by the way described above. Comments ?

Just make it symetrical for laptop mode, though. While putting the
close widget on the right might be all good and wonderful for windows
users, putting it on the left is definitely much, much better. Why? In
laptop mode, if I go jabbing at any of the buttons on the right and
miss, I'm certain to be able to undo my mistake, because none of them
are close. If I try to maximize a "normal" window (i.e. buttons on
right), and miss I can accidently close my window and I can't recover
from that. Whoever first started putting a close widget right next to
the maximize widget wasn't thinking like a user. Great thanks to
whoever wrote the Laptop decorations!

In the gratuitous functionality category, I would put the three
different modes for using Control Center. The only people I can
imagine using Icon Mode are novices, who are unlikely to find the
option. The Modules menu, IMO, is unnecessary redundancy. Putting
exactly the same things in the K-menu, Preferences menu isn't such a
bad idea, though I would move it down to be visually close to
Configure Panel and name it symmetrically (maybe Configure KDE).

That said, a lot of the duplication is exactly what I want. For
instance, the duplication between Control Center, Look&Feel,
Background and kwin's local menu Configure Background is very good
(particularly because it's exactly the same interface).

Having had to walk through all the different ways that KDE can be
configured for a book I was working on, I can definitely say that it's
more good than bad, but I definitely ran into a lot of places that
were very "developer" focused (or at least "advanced user focused")
rather than normal user focused. It may be worth considering marking
certain configuration options (or even entire dialogs) advanced, and
hide them if the user is novie. I've seen this done in WinME to good
effect (dang I hate playing catchup and copycat). OTOH, I wouldn't get
crazy here with a bunch of levels.  Probably just "novice" and
"advanced" with a possible addition of "developer" or "experimental"
to hide those things that aren't really ready for prime-time yet.

In terms of "developer" focus, I'd point to the whole Information part
of Control Center. Terms like "block devices" are very meaningful to
us, but perhaps "drives" would be more consumable. "Samba Status" is
another example that might be expanded to include all shared things
(so including NFS for instance). Then you could just call it "Shared
Devices". Similarly, including stuff like DMA-Channels and Devices is
probably best hidden for normal users.

Is there a good place to talk about UI issues? I have a ton of them :)
Are they more appropriate as wishlist bugs against particular
components or as part of a more general discussion? I'm tempting to do
the former so they can be tracked, assigned, and decisions can be made
whether to implement them or not.

Thanks,
Rob
 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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