[wp-ui] Tabbed theme interface mockups

Mon Feb 22 04:44:54 UTC 2010

I'm in favor of Jeremy's Option A, with JavaScript switching between tabs.
Ignoring the visual appearance for the moment, I like the way systems like
MediaWiki's user preferences operate, loading everything then hiding all but
one tab using JavaScript. Doing that with the large tabs would be fine by
me; I'd like it, and I think it would be usable. The only constraint (and
this is relevant whether the tabs are switched with JavaScript or full
reloads) is number of tabs. Lots of tabs could break into multiple lines,
killing the experience.

Voyagerfan5761
Twitter <http://twitter.com/voyagerfan5761> •
Blog<http://technobabbl.es/?utm_source=emailmessage&utm_campaign=sigs&utm_medium=email>•
FriendFeed <http://friendfeed.com/voyagerfan5761>

On Sat, Feb 20, 2010 at 18:39, Jeremy Clarke <jer at simianuprising.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.automattic.com/pipermail/wp-ui/attachments/20100221/0f2f2221/attachment-0001.htm>