[KDE Usability] On the future of the menubar

[Ben Cooksley]

On Fri, Feb 26, 2010 at 8:44 PM, James Tyrer <jrtyrer at earthlink.net> wrote:
> Dotan Cohen wrote:
>>>> How is System Settings different than any other KDE application in this regard?
>>> Many KCM modules need a lot of vertical space. Some can be improved,
>>> others cannot (speaking as someone who spent quite some time trying to
>>> fix some of them before 4.0 was released). Therefore it makes sense to
>>> leave most space available to what matters.
>>>
>>
>> Is that not true of a PDF viewer? The whole page doesn't fit on a
>> vertical screen (even less on a widescreen). So why does Okular still
>> have a menubar?
>>
>> Or how about a web browser? Or an office suite? Most apps are limited
>> by vertical space, System Settings is not special in this regard.
>>
>>
>>> This is not specific to System Settings, so I think it would be good to
>>> standardize a "reduced menu" in the HIG, similar to what Rekonq created.
>>> The use-case would be applications which do not need large menus and
>>> have important vertical space needs.
>>>
>>
>> In general, I agree. I have not seen the rekonq implementation, though.
>>
>>
>>> - This menu would be included in the toolbar either as a "Menu" button,
>>> or as an icon if horizontal space is limited (that's the case for
>>> Rekonq, where horizontal space is best left to the url lineedit).
>>>
>>
>> There is a feature request for that:
>> https://bugs.kde.org/show_bug.cgi?id=211304
>>
>>> - This menu would contain items like "Configure", "Quit" or "Help", with
>>> "Help" being a submenu like Rekonq does.
>>>
>>> - A limit should be defined to let developers decide whether it makes
>>> sense for them to use a "reduced menu".
>>>
> This is starting to not make much sense.  Consistency is very important.
>  I find SystemSettings a bit disorienting.  I presume that it is
> because it doesn't follow the HIG.  IIRC, this is called proactive
> inhibition in learning theory.  The hybridization of the MenuBar and a
> ToolBar might seem to be innovative to the person that designed it, but
> to me, it is simply inconsistency.  Does any other application have the
> "Help" MenuBar category available on a ToolBar?

Consistency is important, true. However having a 3 item menu bar,
which has all the items present in it accessible via the toolbar is
just a waste.

>
> SystemSettings should have a Menu.  I would presume that it could be
> hidden with <Ctrl><m> which I do in Konqueror when I need more vertical
> space.
>
> Obviously, if SS doesn't have many major menu categories, then the menu
> is going to be rather minimal.

3 menus to be precise. File, which just contains Quit, Settings, which
contains just Configure, and the standard Help menu, which I find to
be a complete waste of space.

And restoring the menu bar would likely not make it any more usable,
and would likely result in bug reports from those users with limited
vertical screens as more modules now have scrollbars, and System
Settings "has become less usable".

>
> The question which I think needs to be considered is whether it should
> be permissible for the MenuBar and a ToolBar to appear on the same line
> the way the multiple ToolBars are.  If this were allowed, it should
> resolve the problem since a MenuBar with only:
>
>        File
>        Go
>        Settings
>        Help
>
> isn't going to take much space -- less than half of the screen width.

This is completely non-standard with other platforms, and will likely
introduce more issues....

>
> There are other things which could be more consistent or improved.
>
> It would probably be getter to use the correct icon: "help".  I think
> that it is OK to use the KDE specific icon since I really don't know
> what the "system-help" is supposed to be used for.  There is no standard
> icon name for the Help Menu since the word "Help" rather than an icon is
> supposed to be used.
>
> IIUC, it is permitted for icons on ToolBars to appear and disappear
> based on context -- that they should do this rather than be grayed out
> (which is only done when they are usable in the context but not
> currently usable).  So, the "back" icon on the HybridBar should
> disappear when it can not be used rather than being grayed out.  The
> HybridBar could also have a "Quit" icon that could also appear and
> disappear when it is needed.  Actually the result would be that an icon
> for either "Back" or "Quit" (but not both) would appear on the HybridBar.

Quit isn't shown by the icon view when viewing a module...

>
> The text box on the HybridBar is labeled "Search".  Not sure if that is
> best.  It isn't really 'search', but it isn't really 'find' either, more
> like 'filter', but not exactly.  Theory suggests that a different term
> should be used, or perhaps the label isn't needed.

Most users are likely to be confused by the term "Filter". Originally
it was a Search, but instead of showing only results, it now only
disables those that don't match to help the user find the modules
quicker in the future.

>
> --
> James Tyrer
>
> Linux (mostly) From Scratch
> _______________________________________________
> kde-usability mailing list
> kde-usability at kde.org
> https://mail.kde.org/mailman/listinfo/kde-usability
>
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<