Changing my mind: reverting my menubar, toolbars and statusbar changes

[Ingo Klöcker]

On Sunday 07 November 2010, David Jarvie wrote:
> On Sunday 07 November 2010 09:31:44 Ingo Klöcker wrote:
> > On Saturday 06 November 2010, Ingomar Wesp wrote:
> > > Aurélien Gâteau wrote:
> > > > I have been quite busy trying to convince everyone actions to
> > > > toggle UI items such as menubar, toolbars, sidebars or
> > > > statusbar should be labeled "Show/hide Foo" depending on the
> > > > visibility of Foo rather than implemented as a checkable "[ ]
> > > > Show Foo" item.
> > > 
> > > Having followed the discussion and how you fought to get this
> > > change in, I'm a bit saddened that it turned out to not work so
> > > well in practice.
> > > 
> > > Maybe we can tackle the underlying issue in another way. If I
> > > understood the problem correctly, it basically boils down to
> > > 
> > > [X] Show Foo
> > > 
> > > textually implying the opposite of the action that the user is
> > > going to trigger if (s)he clicks it. If we keep the checkboxes,
> > > maybe we are able to change the text, so that it is obvious that
> > > it describes the current state rather than an action by changing
> > > the verb into an adjective:
> > > 
> > > [X] Foo shown
> > > [X] Foo visible
> > > [X] Foo enabled
> > > 
> > > Just an idea...
> > 
> > IMHO that does not really fix the problem. I think the real problem
> > is that we think that an additional qualifier like "Show" or
> > "shown" is necessary. As if our users would not understand what
> > the state of the checkbox preceding the menu entry signifies.
> > 
> > I just had a look at Firefox (maybe others can check applications
> > from other "vendors" like Apple, Microsoft, etc.)
> > 
> > Firefox has the options to show/hide certain UI components in the
> > View menu (while we have them in the Settings menu). In this menu
> > Firefox simply lists the UI components names without any verbs,
> > adjectives, etc., i.e.
> > 
> > View
> > 
> >      Toolbars
> >      
> >       [x] Navigation Toolbar
> >       [x] Bookmarks Toolbar
> >  
> >  [x] Status Bar
> >  
> >      Sidebar
> >      
> >       [ ] Bookmarks
> >       [ ] History
> > 
> > Does it really matter that Firefox has those options in the View
> > menu while we have them in the Settings menu? I don't think so.
> > 
> > So, why don't we simply get rid of "Show" (and the "Shown" in
> > Settings-
> > 
> > >Toolbars Shown). IMHO those qualifiers are totally superfluous in
> > 
> > combination with checkboxes. Our convention to add the "Show" does
> > stem from a time where we could (and did) hide the checkboxes of
> > checkable menu entries. Apparently, with Qt 4 the checkboxes of
> > checkable menu entries cannot be hidden. Since we are already at
> > Qt 4.7 it seems very unlikely that QtDF will ever change this. So
> > why insist on a convention that does not make any sense anymore?
> 
> I agree about removing "Show" etc. But if this is done, the menu
> items should be moved to the View menu. In the Firefox example you
> give, the menu name (View) puts the meaning of the menu items in
> context and acts as the verb, giving the necessary hint to the user
> that the checkboxes determine the view state of the respective
> items. Removing the verb and leaving them in the Settings menu would
> IMO make their meaning a bit unclear.

Do you really think this would be a bit unclear? What else would an 
unchecked UI element in any menu mean?

Quite frankly, I cannot image the number of users which grasp "[ ] Show 
Toolbar" but not "[ ] Toolbar" to be significant. Surely, there are a 
lot of not that computer literate people (like my parents) who 
understand neither one nor the other. But people who understand the 
former, but not the latter? I claim that such people do not exist. Prove 
me wrong! ;-)


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20101107/97363d7a/attachment.sig>