[wp-ui] Tabbed theme interface mockups
vf5761 at technobabbl.es
Mon Feb 22 04:44:54 UTC 2010
Ignoring the visual appearance for the moment, I like the way systems like
MediaWiki's user preferences operate, loading everything then hiding all but
me; I'd like it, and I think it would be usable. The only constraint (and
reloads) is number of tabs. Lots of tabs could break into multiple lines,
killing the experience.
Twitter <http://twitter.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:
> 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
> * 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wp-ui