Cannot permanently remove Tabs toolbar using View menu - bug?

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
Feb 12, 2009
17
0
#1
After some experiment I wanted to remove the Tabs toolbar again by unchecking

View|Toolbars and menus|Tabs

and when I do that it does disppear but after closing and restarting TC10 the Tabs toolbar keeps re-appearing (and Tabs is checked again in the Toolbars and menus menu). If I change the Tab toolbar's horizontal position that does get remembered after a restart.

I also tried right-clicking on the Tabs toolbar itself and deselecting Tabs which works but again only for the duration of the TC session. After a restart the Tabs toolbar always comes back.

I then deleted the one Tab command button that I had created for testing and that does get rid of the Tabs toolbar it but I think what I tried above should work also. Is this a bug or a feature?
 

rconn

Administrator
Staff member
May 14, 2008
10,289
90
#2
> After some experiment I wanted to remove the Tabs toolbar again by
> unchecking
>
> *View|Toolbars and menus|Tabs*
>
> and when I do that it does disppear but after closing and restarting TC10
> the Tabs toolbar keeps re-appearing (and *Tabs *is checked again in the
> *Toolbars and menus* menu). If I change the Tab toolbar's horizontal
> position that does get remembered after a restart.
>
> I also tried right-clicking on the Tabs toolbar itself and deselecting
> *Tabs* which works but again only for the duration of the TC session.
> After a restart the Tabs toolbar always comes back.
>
> I then deleted the one Tab command button that I had created for testing
> and that does get rid of the Tabs toolbar it but I think what I tried
> above should work also. Is this a bug or a feature?
It's a feature.

The tab toolbar has four possible configurations -- no buttons and not
shown, no buttons and shown, some buttons and not shown, and some buttons
(and shown).

The default has to be to not show the toolbar if there are no buttons, as
it's (1) useless, (2) takes up screen space to display nothing, and (3)
generates a LOT of complaints from the users. But when the user then wants
to define a button, they'll complain if the toolbar doesn't immediately
appear -- they don't want to have to go back to the menu to actually make it
visible.

What you're trying to do is even more useless - you want to go to the effort
of creating toolbar buttons, and then never display them. TCMD is trying to
reduce the extra work for 99.99% of the users, and asuming that if you have
buttons, you must want to see them. (And if you for some reason only wanted
to see them on rare occasions, you could use the TCTOOLBAR command to do
that.) The option to turn the toolbar on and off from the menu is intended
for occasional use and testing, not as a permanent configuration.

Rex Conn
JP Software
 

rconn

Administrator
Staff member
May 14, 2008
10,289
90
#3
> After some experiment I wanted to remove the Tabs toolbar again by
> unchecking
>
> *View|Toolbars and menus|Tabs*
>
> and when I do that it does disppear but after closing and restarting TC10
> the Tabs toolbar keeps re-appearing (and *Tabs *is checked again in the
> *Toolbars and menus* menu). If I change the Tab toolbar's horizontal
> position that does get remembered after a restart.
>
> I also tried right-clicking on the Tabs toolbar itself and deselecting
> *Tabs* which works but again only for the duration of the TC session.
> After a restart the Tabs toolbar always comes back.
>
> I then deleted the one Tab command button that I had created for testing
> and that does get rid of the Tabs toolbar it but I think what I tried
> above should work also. Is this a bug or a feature?
It's a feature.

The tab toolbar has four possible configurations -- no buttons and not
shown, no buttons and shown, some buttons and not shown, and some buttons
(and shown).

The default has to be to not show the toolbar if there are no buttons, as
it's (1) useless, (2) takes up screen space to display nothing, and (3)
generates a LOT of complaints from the users. But when the user then wants
to define a button, they'll complain if the toolbar doesn't immediately
appear -- they don't want to have to go back to the menu to actually make it
visible.

What you're trying to do is even more useless - you want to go to the effort
of creating toolbar buttons, and then never display them. TCMD is trying to
reduce the extra work for 99.99% of the users, and asuming that if you have
buttons, you must want to see them. (And if you for some reason only wanted
to see them on rare occasions, you could use the TCTOOLBAR command to do
that.) The option to turn the toolbar on and off from the menu is intended
for occasional use and testing, not as a permanent configuration.

Rex Conn
JP Software
 

rconn

Administrator
Staff member
May 14, 2008
10,289
90
#4
> After some experiment I wanted to remove the Tabs toolbar again by
> unchecking
>
> *View|Toolbars and menus|Tabs*
>
> and when I do that it does disppear but after closing and restarting TC10
> the Tabs toolbar keeps re-appearing (and *Tabs *is checked again in the
> *Toolbars and menus* menu). If I change the Tab toolbar's horizontal
> position that does get remembered after a restart.
>
> I also tried right-clicking on the Tabs toolbar itself and deselecting
> *Tabs* which works but again only for the duration of the TC session.
> After a restart the Tabs toolbar always comes back.
>
> I then deleted the one Tab command button that I had created for testing
> and that does get rid of the Tabs toolbar it but I think what I tried
> above should work also. Is this a bug or a feature?
It's a feature.

The tab toolbar has four possible configurations -- no buttons and not
shown, no buttons and shown, some buttons and not shown, and some buttons
(and shown).

The default has to be to not show the toolbar if there are no buttons, as
it's (1) useless, (2) takes up screen space to display nothing, and (3)
generates a LOT of complaints from the users. But when the user then wants
to define a button, they'll complain if the toolbar doesn't immediately
appear -- they don't want to have to go back to the menu to actually make it
visible.

What you're trying to do is even more useless - you want to go to the effort
of creating toolbar buttons, and then never display them. TCMD is trying to
reduce the extra work for 99.99% of the users, and asuming that if you have
buttons, you must want to see them. (And if you for some reason only wanted
to see them on rare occasions, you could use the TCTOOLBAR command to do
that.) The option to turn the toolbar on and off from the menu is intended
for occasional use and testing, not as a permanent configuration.

Rex Conn
JP Software
 
Feb 12, 2009
17
0
#5
I politely disagree, for a number of reasons.

First, this is behavior based on the assumption that the end-user doesn't know what he's doing. While I'll admit that this often seems to be the case from a programmer's or helpdesk perspective, your customer base supposedly consists of technically savy users. It might be better to assume they do know what they want.

For instance in this case, I might want to define a tab toolbar with a bunch of buttons that I need for a recurring task but only once a week or even once a month. The remainder of the time it's only taking up display real estate so I'd want it to be hidden most of the time.

What you're trying to do is even more useless - you want to go to the effort of creating toolbar buttons, and then never display them.
Not never, just not most of the time. In general I believe it's impossible to completely foresee all possible uses of a software feature so in my mind it's dangerous to limit end-user options based on how the designer thinks the software should be used (unless allowing the behavior could easily lead to catastrophic results such as loss of data).

I'm all for closed interfaces (and here I am using a CLI :)) and sensible defaults but it's also often useful to satisfy commonly expected behavior. In most programs where there's no 'Save settings' button any changes that you make are persisted. If I may paraphrase you: what you have done is even more useless - you want to offer an interface to change a setting that is never be remembered.:p

Whats more, there is no indication whatsoever that the setting will not be remembered and the software behaves as if it has amnesia so from an end-users perspective this is probably perceived as a bug.

If I may suggest alternative behavior: simply automatically uncheck this toolbar if the user removes the last user-defined button and automatically check this toolbar if a button is added. Inbetween leave the setting to the user and persist it. To me that makes much more sense. As it is the option to display or hide the toolbar has limited value and goes against commonly accepted behavior imo. Following accepted standards greatly reduces the learning curve of any software and also reduces support requirements.

BTW Note that in the case of changes not taking effect until a restart we have something similar to what I mentioned two paragraphs ago. In that case we have perfectly understandable and defendable behavior (although very strictly speaking technical arguments have no place in a discussion of how a user interface should behave) but this should be indicated in some way, for example by a message box (preferrably with a 'don't show this message again' checkbox).

It's your software (and I think it's great, been using previous versions for years) so you call the shots but I hope you will consider my thoughts on the subject.
 
May 29, 2008
16
2
#6
IIf I may suggest alternative behavior: simply automatically uncheck this toolbar if the user removes the last user-defined button and automatically check this toolbar if a button is added. Inbetween leave the setting to the user and persist it. To me that makes much more sense.
And to me. I second this request!
 

rconn

Administrator
Staff member
May 14, 2008
10,289
90
#7
If I may suggest alternative behavior: simply automatically uncheck this toolbar if the user removes the last user-defined button and automatically check this toolbar if a button is added. Inbetween leave the setting to the user and persist it. To me that makes much more sense. As it is the option to display or hide the toolbar has limited value and goes against commonly accepted behavior imo. Following accepted standards greatly reduces the learning curve of any software and also reduces support requirements.
This is exactly the original 9.0 behavior -- which generated dozens of complaints! Since I changed it to the current behavior, there's been only two complaints (including yours) in the past year.
 
#9
I'm surprised too that anyone would complain that unchecking View/toolbar was persistent. To me it's the only option that makes sense. It's utterly reasonable that while some may find it occasionally convenient to turn off that toolbar others may find it occasionally convenient to turn it on. The toolbar may have been designed with some specific, seldom-used, purpose.

The visibility of the Explorer toolbar persists. Is that so different?