[wp-ui] Tabbed theme interface mockups

Sun Feb 21 12:12:47 UTC 2010

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.

On 21 February 2010 20:00, <wp-ui-request at lists.automattic.com> wrote:

> Send wp-ui mailing list submissions to
>        wp-ui at lists.automattic.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://lists.automattic.com/mailman/listinfo/wp-ui
> or, via email, send a message with subject or body 'help' to
>        wp-ui-request at lists.automattic.com
>
> You can reach the person managing the list at
>        wp-ui-owner at lists.automattic.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of wp-ui digest..."
>
>
> Today's Topics:
>
>   1. Re: Tabbed theme interface mockups (Jeremy Clarke)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 20 Feb 2010 19:39:19 -0500
> From: Jeremy Clarke <jer at simianuprising.com>
> Subject: Re: [wp-ui] Tabbed theme interface mockups
> To: wp-ui at lists.automattic.com
> Message-ID:
>        <e1202cb11002201639g446aad80wee51cdaddd907207 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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
> stated below.
>
> 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:
>
>
> http://simianuprising.com/wp-content/uploads/2010/02/wp-tabbed-admin-pages-wrong.png
>
> 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
> ramifications:
>
> 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
> javascript to jump back and forth in the content which is already
> loaded.
>
> B - We are grouping together related pages to make it easier to find
> related pages.
>    * 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
> fundamentally different.
>
> 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
>
>
> ------------------------------
>
> _______________________________________________
> wp-ui mailing list
> wp-ui at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-ui
>
>
> End of wp-ui Digest, Vol 2, Issue 12
> ************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.automattic.com/pipermail/wp-ui/attachments/20100221/95842f62/attachment.htm>