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

List:       kde-usability
Subject:    Re: Konqueror - suggestions
From:       Trian Karayiannis <tak2 () kent ! ac ! uk>
Date:       2003-07-12 17:47:19
[Download RAW message or body]

> > That's because Cervisia is not part of Konqui. You would have to
> > deactivate Cervisia for that. (Or request that Cervisia does not show a
> > button by default, since it is a rather advanced app)

OK, for somebody non-technical who made more of a 'bulk' install (eg. distro 
install), that's not immediately apparent. I would imagine the average user 
would expect to be able to configure it through the 'configure toolbars' 
menu, or at least some item in the konqueror configuration. If you hadn't 
told me I need to 'go there and do that' I wouldn't have known.

> other parts that aren't part of konqueror are fully customizable. this is a
> limitation in the XMLUI usage where the viewmode_toolbar can not be
> customized.

100% spot on.

>
> > You could argue to remove some buttons on the default config, then make
> > bugs.kde.org feature request. Hiding the menu bar is certainly not an
> > issue, it just confuses users. A feature that is not visible does not
> > exist (for most users).

Well, it could be enabled by default, but I'd find it cool if I could have 
such an option. Konqueror and konsole are two applications that spring to 
mind where I don't use the menu that much. Having it near the left of the 
title bar (around where 'Edit' usually lies) and towards the bottom (to hint 
it's more related to the app and not the window manager) would make it quite 
quick, because this is where the mouse instinctively goes when we want to use 
the menu, I would imagine.

This is a bit more of a power-user feature. Why don't I write one myself...? 
I'm not exactly confident with C++ (read at the end).

> agreed
>
> > > One other thing I had in mind about this was to put the navigation
> > > buttons in a single line, rather than 4. I am no C++ programmer, but
> >
> > That would be confusing (since it is completely nonstandard and no one
> > expects this),
>
> "No one expects the Spanish inquisition!" ;-) but seriously, and to play
> the devil's advocate, i don't know how terribly confusing it would be. in
> fact, it may be immediately apparent to users due to being a reflection of
> the toolbar and that the right click menu is a power user feature anyways.
>

Exactly what I had in mind. OK, it's not standard but then it's a new idea. I 
could argue it structures things more logically. Mentally you'd say "ok, this 
line is about navigation: up, back, fwd, reload" and you'd only hunt in this 
line for the appropriate button. I'd put just images, like the toolbar, 
because that's what the users are more familiar with.

A similar one-line structure could be applied to 'Copy', 'Cut' and 'Paste' 
(text-only, with some discrete separators between them, maybe). I'd put them 
in the order of frequency of use (leftmost the most frequently used), which I 
imagine is the one above. 

Whenever I use the right-click menu I find myself _hunting_ for the location 
of these buttons each time. The sometimes large amount of separators (and 
icons) does not help either. So I end up using the keyboard shortcuts much 
more often.

(on a relevant note, could the separators be made a bit more discrete?)

One last place I imagine this could be applied at is the 'Delete' / 'Trash' / 
'Shred' situation, with 'Delete' on the left as the one most frequently used.

Generally, arranging buttons like that gives the menu a logical structure 
without having to place the buttons in a sub-menu (which is slower). Also, it 
can be argued that it's actually faster, because a) there's less hunting 
(structure) and b) users hunt in two dimensions. But I wouldn't overdo it 
with arranging buttons like that either. I'd have these three rows maximum, 
maybe.

Speaking of complex menus, have you used Alias|Wavefront Maya? There's a 
radial right-click menu, plus a left-click menu if you Space-click. 
Forgetting the latter, I find the former very handy (and any other maya users 
I know agree). Now, I wouldn't want anything that complicated on what is 
essentially a file manager+browser, but the point is that changes from the 
(how old is it?) standard bring (shudder... the 'microsoft word') innovation.

> > makes clicking much more difficult and not than easier
> > (Fitts law)
>
> well, the first item would still be (close to being) under the mouse, and
> one could make the icons 22x22 or what-have-you and thereby increase the
> target size.
>
> this would also be balanced out by the fact that they would be similar to
> the toolbar and make the menu smaller.
>
> > and is not that easy to implement, since QPopupMenu and friends
> > do not support this.
>
> actually, this wouldn't be too hard with QPopupMenu at all, as you can
> insert widgets into a menu. so you create a widget with the four icons,
> mimicking the toolbar look, and pop it in as the first item.
>
> i'd be happy to test this feature out locally on users great and small if
> someone were to code it. Trian?

I'd be very happy to write all these myself, but
1) unfortunately I'm not very confident with C++ yet (pointers and all)
2) I need to get familiar with the KDE and relevant C++ libraries first.

I'm a java/perl programmer (strangely enough with a photographer/graphics 
designer background), trying to make my way into C++ and unix programming. 
Having said that, give me a good source of library documentation and I could 
pick things up fairly quickly. :-)

I hate just saying "why don't you guys try this and that and that..." without 
being able to actively contribute. So, I want to get up and going with kde 
programming. :-)

Regards,

Trian


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