[wp-ui] Tabbed theme interface mockups
jer at simianuprising.com
Sun Feb 21 00:39:19 UTC 2010
tI think the first demo's tabs are too small to be used in such an
important way. Yes, they match the visual/html tabs, but that is a
perfect reason NOT to have the page tabs look this way. Switching
visual/html is a small change that manages just one part of a large
complex page (edit-post.php). These new tabs will be doing MUCH MORE
than that, altering the entire content of the page, losing any changes
done to the previous 'tab'. As such I think they need to look
significantly more important than the visual/html distinction, and I
think the second option makes way more sense for several reasons
Importantly, I think people are completely wrong to say the
title-style tabs are too big or 'take up too much space'. If you open
both mockups and switch back and forth you'll see that the large tabs
actually take up LESS vertical space than the small ones, because the
tab labels serve both needs, tab AND page title, removing entirely the
need for a huge page title above the tabs.
In fact, if you look carefully at the two mockups you'll see that
Gaston seems to have accidentally favored the small tabs by making the
two ideas take up the same vertical space even though the 'big tabs'
have less height: in the big tabs mockup there is extra unnecessary
padding between the tabs and the list of links. If we clean up that
space we see that the big tabs take up less space while simultaneously
giving much more precedence to the tabs themselves, making the whole
system more useful and harder to miss at a glance.
Actually, after putting them side by side and cleaning up some other
spacing issues (the big tabs weren't vertically aligned with the
sidebar, pushing them down even further) in photoshop I was pleased to
see that the difference in vertical space consumption was 100%
opposite of what people thought in responses so far. I think this
resulting graphic shows very clearly how much space is actually saved
by going with the title-tabs:
So #2 is the real space-saver, and if that is our main concern we
should not choose #1.
The other concern is consistency with the current design, which is
obviously important both for maintaining the smallest possible set of
design patterns to keep things simple and for avoiding users
accustomed to the old way from being alienated from the new way. In
that case I think that #2 still has a lot going for it.
While there may not be a precedent where UI tabs look exactly like
that I think we're missing the fact that it has the extremely valuable
feature that it matches how PAGE TITLES are currently shown. If these
are page titles and not sub-sections of a single page, having them
look like page titles is a good idea. The fact that the outline and
shading of the tabs should take as much from the visual/html editor as
possible is fairly obvious, and I think #2 does a good job of merging
together the styles of the visual/html tabs with the normal look of
page titles in WP Admin.
All that said I think the bigger question is exactly what we're trying
to achieve here. Sorry if I missed an earlier conversation about what
the tabs are for, but I see two possibilities each with important
A - We are fundamentally removing pages from the admin and merging
them together. We would just make one long-ass page and tell people to
scroll but we would rather clean it up with tabs.
* The goal is to have less choices in the sidebar to make things simpler.
* It is a bit harder to get to specific tabs/pages (especially
secondary tabs) but maybe its worth it.
* In this case the deleted page should be removed from the sidebar
as in the mockups.
* We should use mockup #1, as it clearly denotes that the new page
is only one page with two sub-tabs that compose it.
* Switching tabs should not reload the page, but instead use
B - We are grouping together related pages to make it easier to find
* The goal is not to have less pages but to make navigation
between pages easier.
* All pages are still visible in the sidebar (unlike in the
big-tabs mockup), but it is easier to see what pages are related to
the current one in the header tabs.
* Each page is still its own url and switching 'tabs' merely jumps
you to the new page, with a full html reload.
* Mockup #2 (big tabs) should be used because it maintains the
individuality of each page while still denoting their relatedness and
making it easier to navigate between pages.
* It also serves to denote subservience of one page to the other
in a useful way (i.e. if you are in the 2nd tab of a set then you know
that the first one is probably the more important one. i.e. Manage
themes is more important/common than install themes).
IMHO these two goals are very different and require different solutions.
I personally don't like the first (A) option. I think the
relationships it defines will tend to redundantly replace the
relationships present in the different sidebar sections. I also think
that removing sections with lots of options from the sidebar will make
things harder to find overall. If we do this it should be with extreme
caution, and the example in the mockups should not be executed because
these two pages are not part of the same options, but rather
I personally like the intention of the second option (B) even though
I'm not totally convinced its necessary. I often find myself on an
admin page wishing for direct links to related pages in the header. A
perfect example is the newly added 'add new' button in the headers of
Edit Posts and Edit Pages. I'd been dying for that since 2.7 came out.
In a similar way I think the big-title-tabs system proposed in mockup
#2 would help people get many tasks done more easily.
There are problems with the idea (B) though, the biggest being how
strange it would be to have some pages in a sidebar section grouped
into tab-groups but not others. Why not have 'edit themes' and 'theme
widgets' mixed into the header tabs for the appearance pages? Looking
at my settings sidebar section makes me even more nervous. What pages
would be linked together and which would be orphaned? With time I
could learn the idiosyncratic relationships the pages have to each
other, but for new users it would probably seem relatively random.
Another problem is that any more than a few big tabs would be too much
for many screens to show and they'd drop to a second line, which would
just look awful.
Sorry for the ludicrously long post. Hopefully it has some food for
thought going forward.
Jeremy Clarke | http://jeremyclarke.org
Code and Design | http://globalvoicesonline.org
More information about the wp-ui