Vertical-tab-ify admin/user/settings

Screenshot please!

Screenshot 1:

Screenshot 2:

Visual review
From an initial look, this needs some work. To begin, I don't know if I like the initial implementation of a set of VTs within a set of VTs (screenshot 2). It is awkward to use, hard to manage, and frankly a bit confusing. We might want to play with a few different ideas here, as I don't think that the current implementation is workable.

Secondly, the Account cancellation settings, Signature, and Pictures tabs do not provide a summary once another selection is made. For example, if pictures are disabled and you enable them, the summary is removed. This is true for all of the listed tabs.

Third, the label for the account cancellation radios has a "for=" attribute with no corresponding form element and therefore returns a warning when validating with W3C. This 'for' attribute should be removed.

All in all, I like it, but it still needs some touch ups.

Why not split the emails to either a seperate page, or a seperate set of tabs on the same page?

Or try this one:

Context, I only see the content area - can you supply a full screenshot. I am quite worried about how far we take, vertical tabs.

two screenshots now. Note that this is no CSS magic, but done with the GIMP. I have no clue whether or how this could be implemented.
Also note that the strange border, that doesn't quite reach the edge at the top right is caused by the "margin-right: 5%" in div.vertical-tabs. Removing that makes it look perfect but breaks the node/add form. I think it should be removed from dev.vertical-tabs and added specifically for node/add, but that's a different issue.

I don't like nested fieldsets, nested vertical tabs seems like an extra layer of bad. If the form requires nested fieldsets then it's simply wrong - like wretched sinner says we should at least consider moving this stuff to a tab.

Maybe we could just leave the e-mail settings as regular fieldsets.
I tried that, but it doesn't really work by simply making the outer fieldset vertical tabs and leaving the rest as is. Since there's no docs on vertical tabs yet, I'm kind of lost.
Someone with more (/any at all) Forms API knowledge would have to roll a patch.

Please let's not overuse vertical tabs until we have to puke. I agree that vertical tabs make sense in that page, but two levels of vertical tabs just seems a bit much and indicates that there's too much that can be changed on that page. Maybe we should think about splitting up that page into more sensible sub-pages.

Maybe make "User e-mails a whole new page (admin/user/e-mails, e.g.) and use vertical tabs for both...

Don't nest vertical tabs! Argh!!!! That's worse than nested collapsible fieldsets.

If this page is going to be vertical-tabified, then the email messages need to be moved off of this page and into their own UI. Perhaps into a local task? then you have one page with VT for user settings. Another page with VT for email messages.

Rather than nest two levels of vertical tabs, it makes more sense to use an accordion UI pattern for nesting the second level of grouped items.

I've edited one of the mock ups in #3 to illustrate what I mean.
Feel free to edit the mock up with Fireworks.

Rather than nest two levels of vertical tabs, it makes more sense for an
accordion UI patten to be used for nesting the second level of grouped
items.

Why?

why not? :D

Vertical tabs doesn't work very well for nesting since it is demanding on horizontal space.

The main advantage field sets of vertical tabs have over accordion is that the field set/drawer titles of vertical tabs are always next to each other no matter which field set is open or closed.

Accordions within vertical tabs keeps the vertical footprint close to a minimum without the horizontal price tag of vertical tabs if nesting is ever required. I assume if furthur nesting is required, it could be better for the remaining levels of nesting to be as accordion field sets or field sets as currently used in D5/D6 instead of vertical tabs (due to the horizontal space limits of vertical tabs.)

The problem with accordion within VT I see is that the overall page layout becomes too complex. Also, you can't see two fieldsets at a time, e.g. to compare their contents.

@SteveJB. I like the accordion idea.

I think it would be better to move the accordion to a different page/screen/local_task. Your suggestion is a good compromise I think, though are we really too lazy to implement a hook_menu() item!? hook_menu() isn't that scary is it? Perhaps there are other issues.

@kkaefer

The problem with accordion within VT I see is that the overall page layout becomes too complex.

Which is all the more reason not to nest VTs.

Also, you can't see two fieldsets at a time, e.g. to compare their contents.

What are tasks or use cases where this might be desirable? Does it fall into our 80% of users or tasks? Note this is also an issue with nested VTs.

The problem with accordion within VT I see is that the overall page layout becomes too complex.

Which is all the more reason not to nest VTs.

I never said that (see comment #11).

Hm. I'm not sure I like an accordion here. I frequently compare the values between different mail templates and if I had to click one, memorize it, then click another, that'd get very annoying.

Why not just a single set of VTs for the page, and leave collapsible fieldsets around the mail templates?

#22 seems most reasonable to help get this in quicker. Then we can discuss what the heck we want to do with the email templates.

If collapsible field sets were visually styled to appear similar to accordion field sets, it could make it easier to read what's within the nested field sets.

Perhaps, but let's cover that in another issue. Changing the styling on collapsed fieldsets has wide-ranging effects. What's being proposed here is very simply converting one page to use VTs.

I am marking this won't fix, the apporach in Xano_'s patch is far better.

http://drupal.org/node/455576