I think the smaller tabs preserve more horizontal space: allow for a higher number of tabs on a page.. Not all users are on large screens, many still use 1024 resolutions. And then there are mobile devices. <br><br><div class="gmail_quote">
On 21 February 2010 20:00, <span dir="ltr"><<a href="mailto:wp-ui-request@lists.automattic.com">wp-ui-request@lists.automattic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Send wp-ui mailing list submissions to<br>
<a href="mailto:wp-ui@lists.automattic.com">wp-ui@lists.automattic.com</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.automattic.com/mailman/listinfo/wp-ui" target="_blank">http://lists.automattic.com/mailman/listinfo/wp-ui</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:wp-ui-request@lists.automattic.com">wp-ui-request@lists.automattic.com</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:wp-ui-owner@lists.automattic.com">wp-ui-owner@lists.automattic.com</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of wp-ui digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Tabbed theme interface mockups (Jeremy Clarke)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Sat, 20 Feb 2010 19:39:19 -0500<br>
From: Jeremy Clarke <<a href="mailto:jer@simianuprising.com">jer@simianuprising.com</a>><br>
Subject: Re: [wp-ui] Tabbed theme interface mockups<br>
To: <a href="mailto:wp-ui@lists.automattic.com">wp-ui@lists.automattic.com</a><br>
Message-ID:<br>
<<a href="mailto:e1202cb11002201639g446aad80wee51cdaddd907207@mail.gmail.com">e1202cb11002201639g446aad80wee51cdaddd907207@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
tI think the first demo's tabs are too small to be used in such an<br>
important way. Yes, they match the visual/html tabs, but that is a<br>
perfect reason NOT to have the page tabs look this way. Switching<br>
visual/html is a small change that manages just one part of a large<br>
complex page (edit-post.php). These new tabs will be doing MUCH MORE<br>
than that, altering the entire content of the page, losing any changes<br>
done to the previous 'tab'. As such I think they need to look<br>
significantly more important than the visual/html distinction, and I<br>
think the second option makes way more sense for several reasons<br>
stated below.<br>
<br>
Importantly, I think people are completely wrong to say the<br>
title-style tabs are too big or 'take up too much space'. If you open<br>
both mockups and switch back and forth you'll see that the large tabs<br>
actually take up LESS vertical space than the small ones, because the<br>
tab labels serve both needs, tab AND page title, removing entirely the<br>
need for a huge page title above the tabs.<br>
<br>
In fact, if you look carefully at the two mockups you'll see that<br>
Gaston seems to have accidentally favored the small tabs by making the<br>
two ideas take up the same vertical space even though the 'big tabs'<br>
have less height: in the big tabs mockup there is extra unnecessary<br>
padding between the tabs and the list of links. If we clean up that<br>
space we see that the big tabs take up less space while simultaneously<br>
giving much more precedence to the tabs themselves, making the whole<br>
system more useful and harder to miss at a glance.<br>
<br>
Actually, after putting them side by side and cleaning up some other<br>
spacing issues (the big tabs weren't vertically aligned with the<br>
sidebar, pushing them down even further) in photoshop I was pleased to<br>
see that the difference in vertical space consumption was 100%<br>
opposite of what people thought in responses so far. I think this<br>
resulting graphic shows very clearly how much space is actually saved<br>
by going with the title-tabs:<br>
<br>
<a href="http://simianuprising.com/wp-content/uploads/2010/02/wp-tabbed-admin-pages-wrong.png" target="_blank">http://simianuprising.com/wp-content/uploads/2010/02/wp-tabbed-admin-pages-wrong.png</a><br>
<br>
So #2 is the real space-saver, and if that is our main concern we<br>
should not choose #1.<br>
<br>
The other concern is consistency with the current design, which is<br>
obviously important both for maintaining the smallest possible set of<br>
design patterns to keep things simple and for avoiding users<br>
accustomed to the old way from being alienated from the new way. In<br>
that case I think that #2 still has a lot going for it.<br>
<br>
While there may not be a precedent where UI tabs look exactly like<br>
that I think we're missing the fact that it has the extremely valuable<br>
feature that it matches how PAGE TITLES are currently shown. If these<br>
are page titles and not sub-sections of a single page, having them<br>
look like page titles is a good idea. The fact that the outline and<br>
shading of the tabs should take as much from the visual/html editor as<br>
possible is fairly obvious, and I think #2 does a good job of merging<br>
together the styles of the visual/html tabs with the normal look of<br>
page titles in WP Admin.<br>
<br>
-------<br>
<br>
All that said I think the bigger question is exactly what we're trying<br>
to achieve here. Sorry if I missed an earlier conversation about what<br>
the tabs are for, but I see two possibilities each with important<br>
ramifications:<br>
<br>
A - We are fundamentally removing pages from the admin and merging<br>
them together. We would just make one long-ass page and tell people to<br>
scroll but we would rather clean it up with tabs.<br>
* The goal is to have less choices in the sidebar to make things simpler.<br>
* It is a bit harder to get to specific tabs/pages (especially<br>
secondary tabs) but maybe its worth it.<br>
* In this case the deleted page should be removed from the sidebar<br>
as in the mockups.<br>
* We should use mockup #1, as it clearly denotes that the new page<br>
is only one page with two sub-tabs that compose it.<br>
* Switching tabs should not reload the page, but instead use<br>
javascript to jump back and forth in the content which is already<br>
loaded.<br>
<br>
B - We are grouping together related pages to make it easier to find<br>
related pages.<br>
* The goal is not to have less pages but to make navigation<br>
between pages easier.<br>
* All pages are still visible in the sidebar (unlike in the<br>
big-tabs mockup), but it is easier to see what pages are related to<br>
the current one in the header tabs.<br>
* Each page is still its own url and switching 'tabs' merely jumps<br>
you to the new page, with a full html reload.<br>
* Mockup #2 (big tabs) should be used because it maintains the<br>
individuality of each page while still denoting their relatedness and<br>
making it easier to navigate between pages.<br>
* It also serves to denote subservience of one page to the other<br>
in a useful way (i.e. if you are in the 2nd tab of a set then you know<br>
that the first one is probably the more important one. i.e. Manage<br>
themes is more important/common than install themes).<br>
<br>
IMHO these two goals are very different and require different solutions.<br>
<br>
I personally don't like the first (A) option. I think the<br>
relationships it defines will tend to redundantly replace the<br>
relationships present in the different sidebar sections. I also think<br>
that removing sections with lots of options from the sidebar will make<br>
things harder to find overall. If we do this it should be with extreme<br>
caution, and the example in the mockups should not be executed because<br>
these two pages are not part of the same options, but rather<br>
fundamentally different.<br>
<br>
I personally like the intention of the second option (B) even though<br>
I'm not totally convinced its necessary. I often find myself on an<br>
admin page wishing for direct links to related pages in the header. A<br>
perfect example is the newly added 'add new' button in the headers of<br>
Edit Posts and Edit Pages. I'd been dying for that since 2.7 came out.<br>
In a similar way I think the big-title-tabs system proposed in mockup<br>
#2 would help people get many tasks done more easily.<br>
<br>
There are problems with the idea (B) though, the biggest being how<br>
strange it would be to have some pages in a sidebar section grouped<br>
into tab-groups but not others. Why not have 'edit themes' and 'theme<br>
widgets' mixed into the header tabs for the appearance pages? Looking<br>
at my settings sidebar section makes me even more nervous. What pages<br>
would be linked together and which would be orphaned? With time I<br>
could learn the idiosyncratic relationships the pages have to each<br>
other, but for new users it would probably seem relatively random.<br>
Another problem is that any more than a few big tabs would be too much<br>
for many screens to show and they'd drop to a second line, which would<br>
just look awful.<br>
<br>
-----<br>
<br>
Sorry for the ludicrously long post. Hopefully it has some food for<br>
thought going forward.<br>
<br>
--<br>
Jeremy Clarke | <a href="http://jeremyclarke.org" target="_blank">http://jeremyclarke.org</a><br>
Code and Design | <a href="http://globalvoicesonline.org" target="_blank">http://globalvoicesonline.org</a><br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
wp-ui mailing list<br>
<a href="mailto:wp-ui@lists.automattic.com">wp-ui@lists.automattic.com</a><br>
<a href="http://lists.automattic.com/mailman/listinfo/wp-ui" target="_blank">http://lists.automattic.com/mailman/listinfo/wp-ui</a><br>
<br>
<br>
End of wp-ui Digest, Vol 2, Issue 12<br>
************************************<br>
</blockquote></div><br>