Reducing visual noise within the admin

Description

There's a lot of visual clutter and noise in the admin (gradients, shadows, etc.) and not a whole lot of breathing room. We're moving towards new, vector icons, but they currently don't fit stylistically within the admin.

I've taken an initial stab at playing with a flatter, less cluttered dashboard screen: ​http://f.cl.ly/items/3Q0e0y1E1X231K1s3i0M/wp-flatter.png (Ignore the font — I was playing around with Open Sans, but I think it makes sense to stick with just "sans-serif" as our generic font stack.)

You can see a comparison of the current navbar with icons vs. new icons and a flatter, more spacious navbar:

Right now it's just a screenshot of me playing around in developer tools, but I can easily make it into a patch later tonight. There was some concern in #23333 about making the navbar too tall with the padding I'm using, but I think it needs extra vertical padding.

Right now it's just a screenshot of me playing around in developer tools, but I can easily make it into a patch later tonight. There was some concern in #23333 about making the navbar too tall with the padding I'm using, but I think it needs extra vertical padding.

If you can work this into a patch, then everyone can use it as a jumping off point to play with it (and they can try various amount of padding, etc)

on the other hand, the header colors (or something about the header design anyway) need adjusting if they're not going to have gradients to make them more clearly headers.

also happy to lose the shadow at the edge of the menu.

on the other hand, killing the shadows on flyout menus is problematic -- the impression that they're floating above the main content of the screen is gone and it's much harder to make out the menu from what it's popping out over. I think the shadow can probably be toned down a little to get a flatter aesthetic while keeping enough distinction to have the functional benefits.

on padding, I kind of want to play with something in-between. Call me Goldilocks.

I think sabreuse is right - playing Goldilocks with the amount of padding is probably the right way to go. Metabox headers might still be a bit big in 23415.4.diff​, and along with that, table headers might need to grow a bit to be more in line.

Other thoughts:

Would actually rather keep the shadows for admin menu (both inset for the menu itself and the drop for the flyouts), as well as the inset one for the customizer. I find the separation to be quite meaningful, especially in the case of the customizer when used with a theme that has a gray background. I don't think flattening has to mean completely flat.

Headers do indeed need a different treatment - could be as simple as darker, but not sure. Needs exploration.

I wonder if we could kill the list table outer borders completely (or even all the borders in those tables) and also do some tweaking to the list tables in general. It might not work, but worth a try. We have lots of borders - maybe there's a way to get rid of some of them to reduce busy-ness without creating a disjointed experience.

I don't think it's necessary to tackle the toolbar for this round, it was pretty simple already. Also, the inset shadow provided some separation between toolbar and content. There's no reason to go all out and flatten everything, for example I don't think we need to change the buttons either.

on padding, I kind of want to play with something in-between. Call me Goldilocks.

Regarding padding, I wonder if this might call for some vertical media queries. Someone actually put together one idea for their use with ​the admin menu on CSS Tricks. (I like the "sticky" menu implementation here, though that's outside of the scope of this ticket.)

In this case, the solution might be similar to the responsive Google Reader or Gmail themes which decrease vertical padding on both horizontal and vertical window resizing. I'd lean toward just doing it for vertical resizing, but who knows what would be preferred. The only question is whether we'd have to follow the Google lead and allow people to override that change with a setting. If that's the case, then I think the whole idea isn't worth following.

If we're not careful, this ticket will shoot down a thousand rabbit holes, and never see the light of day. I think we need to agree on a pretty tight scope for this particular ticket to have any realistic expectation of it making 3.6.

This doesn't prevent us from opening additional tickets (to simplify the admin even further), but for this ticket, I'd propose we focus on:

Removing gradients

Removing shadows (text & box) where appropriate (though, as Helen suggested I don't think they all necessarily need to go)

Changes to the toolbar (admin-bar.css). As Joen points out, this is already pretty much there.

Padding/Margin changes

Color changes (fonts, backgrounds, etc…)

icon positioning tweaks (leave this for the icons patch)

Changes in 23415.5.diff

Brought colors-classic.css in line with similar changes

Reverted all changes in admin-bar.css

Reverted padding tweaks

Reverted .wp-menu-arrow tweaks

Reverted color changes in colors-fresh.css

Reverted #adminmenu icon background-position tweaks

Added form element :focus styles back in (for accessibility reasons, I don't think we can drop this). We could optionally change the style to something else, but that should likely take place in a separate ticket.

I mostly agree, except that whitespace and color changes may be required to make it work visually once gradients and box shadows are gone. I don't think we can globally call that out of scope for this ticket, though we can say to restrict to where something like a gradient has been changed. Everything else, though (toolbar, :focus styles, etc.) does definitely seem to fall under no-touch.

I think it's actually still a little too aggressive - would like TinyMCE and quickedit buttons not to be touched (they should still look like buttons because they are), drop shadow restored to admin menu flyouts, and inset shadow restored to admin menu and customizer sidebar. There are also some color mis-matches with tabs now that the gradient is gone, e.g. screen options/help, menus, and editor mode. Don't need things to be perfect for a first pass, but I can see getting stuck just because of the color not matching and don't want that to happen.

I think it's actually still a little too aggressive - would like TinyMCE and quickedit buttons not to be touched (they should still look like buttons because they are), drop shadow restored to admin menu flyouts, and inset shadow restored to admin menu and customizer sidebar. There are also some color mis-matches with tabs now that the gradient is gone, e.g. screen options/help, menus, and editor mode. Don't need things to be perfect for a first pass, but I can see getting stuck just because of the color not matching and don't want that to happen.

Is this really necessary? I'm sure some of the grads and drop shadows could be refined to be more subtle, but I think going fully flat is rather heavy handed.

We also need to consider how this will affect usability. Some may call it "visual noise", but when done right, I would refer to the use of these "effects" as visual cues for the end user.

For example, the meta boxes in 3.5 have been refined quite well. The top bar has an ever-so-subtle gradient that is lightweight, but gives enough of a sense of depth that indicates to the user that it is an element that can be interacted with.

If everything has the same visual weight, then nothing will be differentiated. This is not good for usability because we want to make it as simple as possible for a user to know what to do (what to click on, etc.) on a given page.

Believe me, I'm all for completely tearing things down when it's necessary, but in this case I would advocate further refinement of the current admin styling.

Increasing the negative space (as has been done for this ticket), being more selective with the greys (e.g. meta box content areas), etc. will go a long way toward making the admin feel lighter.

I realize I've got some pretty strongly ingrained "muscle memory" with the old icons, but I keep confusing appearance, tools, and plugins. (The posts icon is quite similar, but it is not proximal to the others.)

I could be unique, and could very well get used to the new icons, but thus far, they've added confusion for me.

We started massaging the admin CSS to complement the change of icons, which will shortly also be reverting. There is certainly something that can be done with the admin UI, but it needs to start with identifying problem areas and doing exploration that we don't have time or resources for in the remainder of the 3.6 cycle. Closing this as wontfix - will start fresh with the re-attempt.