Another Friday, another iteration of the plugin that makes even the fauxgo look good and you shouldn’t use. Calling 0.5 “Aureolin” aka #FDEE00, which doesn’t stand for anything just like MP6.
Notifications
Alerts and notifications need more love, but we’ve made a first pass at them. They could be significantly improved if we introduced more classes in addition to .updated. For example; a .successful class added to the notification shown when a post is published or WordPress is updated. When a plugin update is unsuccessful, we should use the existing .error class. We could also use .updates when showing that updates are available, or .info when an alert is used to provide don’t-miss information. I’m sure there are more; let us know your thoughts in the comments.
Other miscellaneous notes:
- Stop squinting: WordPress is almost ten years old and needs bigger fonts. We’ve increased the base font size to 14 pixels with nothing smaller than 12 pixels as a rule. We think this has done a lot for legibility, though some areas may still need adjustments.
- Help tabs now match the new active/inactive styles used elsewhere. Props to Joen for this.
- Switched to dashicons for view switches and post format icons.
- Rewrote the Open Sans font rule so it doesn’t interfere with specifically declared fonts used elsewhere (i.e. monospace elements).
- Login simplified.
- Many more small adjustments; see the full revision log for details. (It’s amazing how fast things can move when everyone has commit.)
An experiment within an experiment
As we melt away the layers of aesthetic cruft accumulated over many years, we start to notice more “first world problems” — things that didn’t seem like that big of a deal before because there were more fundamental problems but as we fix those the higher-order problems are more grating.
There’s scope creep, and there’s scope taming — taking the wild beast of scope and conquering it so thoroughly with the coordinated effort of a diverse, unified, and motivated team that Friction and Resistance melt away before you. I was initially skeptical we could tackle the following in MP6, but as our open approach has attracted new people and also more effectively leveraged contributors who might not have as much time I’m proud to announce:
- We’re responsive. We’d originally thought that this was outside the scope for MP6, but a strong initial effort by Andy Peatling convinced us it could be done. We’re adding support page by page so no need for individual bug reports just yet, if you have questions or suggestions please leave them in the comments here.
- There’s a fixed-position menu bar. It only floats if the viewport is taller than the admin menu, and it’s disabled on all smartphones and tablets (except iPads). Users should disable the Floating Admin Menu plugin, if installed. Props to Till Krüss for bringing his plugin into MP6 to enable this functionality.
These are done as sub-plugins within MP6 directories we can easily disable if they get in the way of our core goal of creating a new unified aesthetic ready to be in core.
Always forward…
The team will be meeting in #wordpress-ui at April 1st, 2013 1pm CDT to go over this week’s edition and discuss your ideas for the next one. We’ll follow it up with our next release a week from today on April 5.
This week included contributions by Joen Asmussen, Mel Choyce, Ben Dunkle, Isaac Keyet, Till Krüss, Andy Peatling, Samuel Wood (otto), and MT. Many thanks as well to all of you who have commented here and participated in the weekly chat; your feedback has helped shape our work.
lessbloat, 
Daniel Dvorkin 2:32 am on March 30, 2013 Permalink | Log in to Reply
Really nice work! I’m wondering what’s the rationale behind moving the menu to the right side on mobile..
Matt Thomas 2:34 am on March 30, 2013 Permalink | Log in to Reply
This is still up in the air — it was easier to implement the button that opens and closes the menu on the right-hand side. I think we could successfully implement it on the left (and it would feel more natural to keep it on the left), though it will be a little bit more tricky to find the room. We are all ears and eyes if anyone has suggestions!
mindctrl 2:49 am on March 30, 2013 Permalink | Log in to Reply
I like it on the right. As a right hander, it’s easier to reach the button and when the menu opens on the right, it’s easier to access the menu items.
Travis Northcutt 3:58 am on March 30, 2013 Permalink | Log in to Reply
What do you think about keeping the button on the right, but having the menu open on the left?
That seems like it might follow convention and perhaps user expectations reasonably well. It’s quite common for that kind of menu to open from the left, and it’s on the left on larger screens as well. Additionally, it’s quite common for menu toggle buttons to be located top right (see many responsive sites, as well as e.g. Google Chrome).
mindctrl 11:52 am on March 30, 2013 Permalink | Log in to Reply
I’ve seen several implementation where the button is on the right and the menu is on the left. It does feel inconsistent though. If my finger is on the right side and taps a menu button, and the menu opens on the left, it feels somewhat disconnected and not right. I then have to move across screen to access the things the button exposes.
I’ve always disliked that menus open on the side of the screen farthest away from my fingers. It always feels clumsy even though I have big hands. I wish we could break from convention on that, but I see the WordPress for Android app is going to have the drawer on the left soon. Apparently the iOS app has the left drawer too. It’s probably best to provide some consistency across all the devices and methods of access.
luetkemj 8:03 pm on April 2, 2013 Permalink
I like the opening on the right, although I do not like that the menu button moves when you open it. If I open it by accident finding the button again is a pain. Small thing, but a thing.
Tom J Nowell 4:02 pm on April 3, 2013 Permalink | Log in to Reply
It should be moved to the left.
The obv fix would be to move the button to the admin bar where the WordPress logo is. This way it’s always visible, fits into the wider conventions, and is always in the same place and accessible.
David 4:07 am on March 30, 2013 Permalink | Log in to Reply
Two weeks ago Ze Fontainhas pointed out some problems with text overflows, one of which was in the Right Now widget on the Dashboard. It’s still there today, and from what I can tell, it’s not a text overflow issue but rather a problem with the padding-left of #dashboard_right_now p.musub getting overridden by #dashboard_right_now p.sub.
I managed to fix it by adding:
`#dashboard_right_now p.musub {
padding-left: 16px;
}`
to css/colors-mp6.css. There may be a better way to fix this, but from what I can tell it works alright in Firefox, IE, and on Safari on my iPhone and iPad.
Matt Thomas 5:58 pm on April 5, 2013 Permalink | Log in to Reply
Thanks; I needed to set up multisite on my sandbox to check this out. A fix is now in trunk.
Marko Heijnen 2:51 pm on March 30, 2013 Permalink | Log in to Reply
On the plugin page you can have two search bars when you go from small screen to large one. And on theme page to search bar gets lost.
Also sometimes the menu doesn’t seem to work probably on some sites. Not sure why yet.
Marko Heijnen 2:27 pm on March 31, 2013 Permalink | Log in to Reply
When user setting unfold is set the body class auto-fold is missing. This is causing the bug. Following code does solve the issue after you logged in again since it does need to set the cookie.
add_filter( 'get_user_option_user-settings', 'filterout_unfold' ); function filterout_unfold( $option ) { $option = remove_query_arg( 'unfold', $option ); return $option; }Ipstenu (Mika Epstein) 4:50 am on March 31, 2013 Permalink | Log in to Reply
Regarding larger fonts: I love it. Can we consider increasing the default font size of the editors to match?
Matt Thomas 5:11 am on April 1, 2013 Permalink | Log in to Reply
Definitely; good call. I’ll take a look at that this week.
Matt Mullenweg 7:46 am on April 1, 2013 Permalink | Log in to Reply
We still have some work left on last week’s focus, but at some point WYSIWYG, DFW, text areas, and input-form heavy places like settings would be a good iteration.
Jesper van Engelen 8:52 am on April 1, 2013 Permalink | Log in to Reply
Great improvements once again! A small issue that occurred was that, on small window widths on the single post edit page, the “Edit” and “Get Shortlink” buttons get moved to the next line after the post URL, which causes the “Add Media” and other buttons you may have there to float over these buttons.
I would love to see just icons there when the width is low (smartphone-low), and have these icons align with the editor HTML/Text tabs. I’ve made a quick mock-up of this, which shows what I mean: http://snag.gy/ODpIZ.jpg.
kwight 1:47 pm on April 1, 2013 Permalink | Log in to Reply
Was there any discussion about having the post format icons after the title on edit.php?
It might be less disruptive, especially when mixed in with standard post formats (titles will always line up): http://d.pr/i/BsWp
hugw 2:59 pm on April 1, 2013 Permalink | Log in to Reply
Really liked font size 14
Mark Jaquith 7:07 pm on April 1, 2013 Permalink | Log in to Reply
http://cl.ly/image/0U0C0T1G2b2y
I still find the differences between text inputs and secondary submit butons to be too subtle. The secondary butons aren’t obviously buttons. See also Chrome input cancellation icon clipping.
corrinda 11:09 pm on April 1, 2013 Permalink | Log in to Reply
Larger fonts – definite improvement – a darker color font would make the dashboard even easier to read
Lachlan MacPherson 11:42 pm on April 1, 2013 Permalink | Log in to Reply
This made my day! It’s the little things that make all the difference
Justin Sainton 1:28 am on April 5, 2013 Permalink | Log in to Reply
Not sure if this is on the radar, but the z-index of the fixed sidebar doesn’t seem to be giving too much love to the Debug Bar area – not sure who should be responsible for deferring, but here’s a screenshot anyway
http://cl.ly/image/0q3K0P2Z3C0q