Tab order on multirow tab control

[Wayne]

Is there a way to stop the default action of a multirow tab control
whereby the row with focus moves to the front of the tabs? I find this
behaviour annoying and confusing to the user and am at a loss as to why
MS has designed their tab controls like this.

[Rick Brandt]

Wayne wrote:

Is there a way to stop the default action of a multirow tab control
whereby the row with focus moves to the front of the tabs? I find
this behaviour annoying and confusing to the user and am at a loss as
to why MS has designed their tab controls like this.

ALL multi-row tabs act this way. How else can you identify the active tab
except by moving it to the front?

Try the Buttons format instead of the Tabs format. The buttons don't move.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Wayne]

Rick, I guess I hadn't thought about the fact that the tab needs to
move to the front row as you have explained. Maybe it would be more
intuitive to the user to highlight the tab by having its text go bold
when selected instead of changing the tab row order. That way the user
would always find the required tab in the same place instead of having
to hunt for it. What do other users think or am I the only one who
finds the action of the tab control confusing - maybe I'm easily
confused. :-)

Anyhow, thanks for the info Rick - it's much appreciated.

[Robin S.]

"Wayne" <cq*******@volcanomail.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

Rick, I guess I hadn't thought about the fact that the tab needs to
move to the front row as you have explained. Maybe it would be more
intuitive to the user to highlight the tab by having its text go bold
when selected instead of changing the tab row order. That way the user
would always find the required tab in the same place instead of having
to hunt for it. What do other users think or am I the only one who
finds the action of the tab control confusing - maybe I'm easily
confused. :-)

At the risk of looking like a dumbass, I think you're right. I find this
"feature" really annoying in the advanced display properties for Windows as
mine has three rows of tabs (ATI). I can never figure out where the previous
row went. While this isn't a huge slowdown, I don't have a great tolerance
for "the small things."

Regards,

Robin

[Steve Jorgensen]

On 30 Dec 2004 15:03:44 -0800, "Wayne" <cq*******@volcanomail.com> wrote:

Is there a way to stop the default action of a multirow tab control
whereby the row with focus moves to the front of the tabs? I find this
behaviour annoying and confusing to the user and am at a loss as to why
MS has designed their tab controls like this.

As others have pointed out, all tab controls in Windows work this way, and to
do different would be inconsistent. I agree though that it breaks many of the
rules of good GUI design, including the fact that it thwarts our muscle and
positional memory.

The solution I usually aim for is to try to modify the design to not to need
that many pages on a tab control.

Describe your situation, and perhaps, some of us will have ideas for reworking
the UI design.

[Wayne]

Thanks for the feedback folks. I'm happy with the UI design of my
database and so is the client - but like Robin, I find this "feature"
really annoying and was wondering if I am the only one that has a
problem with it. I also find it a pain in the advanced display
properties for Windows where there are 3 rows of tabs.

The fix for my database of course is to follow Rick's advice and use
buttons instead of tabs. Although I'm not particularly happy with the
look of buttons, at least they don't jump around all over the place and
the result is an interface that's a lot more intuitive for those users
who don't spend any more time in front of a PC than they have to.

[Trevor Best]

Wayne wrote:

Thanks for the feedback folks. I'm happy with the UI design of my
database and so is the client - but like Robin, I find this "feature"
really annoying and was wondering if I am the only one that has a
problem with it. I also find it a pain in the advanced display
properties for Windows where there are 3 rows of tabs.

It's worse in Exchange Server, there's one dialog in there that has
multirow tabs and one of the tabs is the entire width of the dialog so
when it's current, it's not apparent at all.

--
This sig left intentionally blank

[David W. Fenton]

"Wayne" <cq*******@volcanomail.com> wrote in
news:11**********************@c13g2000cwb.googlegr oups.com:

Is there a way to stop the default action of a multirow tab
control whereby the row with focus moves to the front of the tabs?
I find this behaviour annoying and confusing to the user and am
at a loss as to why MS has designed their tab controls like this.

1. Redesign to not need multi-row tabs.

2. Hide the tabs and drive the tab with an option group, instead.
This solution can be formatted to look identical to the tab style
that uses buttons instead of tabs.

If like tabbed UIs, myself, but have found that users don't like
them nearly as much as I do, so I tend to hide the fact that I'm
using a tab control and drive the tab in some other fashion. Here's
some examples:

Tab control driven by buttons (fake buttons, actually -- those are
actually labels, and that's why they are colored):
http://www.dfenton.com/DFA/examples/Activities.gif

Tab control driven by listbox (also uses the fake buttons at the top
to show/hide the tab control (Profile) vs. a subform (Assignment)):
http://www.dfenton.com/DFA/examples/c_2pers.gif

Same top-level form with the subform displayed instead of the tab
control, and the subform has a listbox that drives the data
displayed in a subform with a regular tab control on it:
http://www.dfenton.com/DFA/examples/cand1.gif

Tab control driven by a wizard interface with <<PREVIOUS/NEXT>>
buttons: http://www.dfenton.com/DFA/examples/...gistration.gif
http://www.dfenton.com/DFA/examples/NRG/DataInput1.jpg

I don't see any examples there that use the actual option group
button solution, but I've definitely used that in the past (I just
haven't posted any examples using that approach).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Wayne]

David, I've tried the option group solution and I like it. Thanks for
the tip.

[Bas Cost Budde]

Armando wrote:

I agree. I've always been annoyed by that behavior. But here's where it
probably came from - think of the physical item this mimics, a tabbed index
card. Whatever card you're staring at currently will have its tab in front
of all the others, right? A disconnected tab would blow the metaphor, I
guess.

That is true. The trouble is we're relying on muscle memory for many
unit tasks. In a real drawer you move all tabs front/back by hand, so
you know. In the multi-line tab panel, there is only the mouse movement
that gets recorded with muscle memory --> controls should stay in place.

I once used to make tabs I don't use (or allow) invisible; but this
results in the same problem, namely moving tabs. That is awfully
confusing. You have to keep on reading/searching to get at the tab you want.

Would it be better to maintain the relative tab order, and move tabs
that have their place 'before' the active tab to the *bottom* of the
tabcontrol? Sort of top view of the drawer. I think I could live with that.

--
Bas Cost Budde, Holland
http://www.heuveltop.nl/BasCB/msac_index.html
I prefer human mail above automated so in my address
replace the queue with a tea