Hello all We’re here with the final regularly…

Hello all! We’re here with the final regularly scheduled weekly installment of MP6, version 1.5. As we’re beginning to wrap up our visual redesign, we’ll continue to release updates to MP6 when necessary, but will no longer be announcing them every Friday. We’ll miss you guys. 🙂

New this week:

  • We’ve begun merging colors-mp6.css and wp-admin.css. This is just about done, but we need to do a bit more testing before we flip the switch and use the new CSS files for everyone. When we’re done, this will allow for much cleaner future potential patches/merges into Core.
  • Load Open Sans on the login screen.
  • RTL: Fix comment bubble tail and positions, view switch margins.

This week includes contributions from Michael Erlewine (mitcho), Till Krüss, and myself.

You can continue leaving comments here with feedback for us. And we’ll issue new posts when there’s something big new for you guys to take a look at (we’re already noodling on some larger core design issues we’re looking forward to sharing with you). As always, thanks for all your helpful feedback in advance.

#icons, #mp6, #plugins, #svg

Happy Friday everybody Here’s what’s new in MP6…

Happy Friday, everybody. Here’s what’s new in MP6 this week. It was a short week for most of us, so we’ll keep the post similarly short.

  • Mobile: You can swipe right and left to open and close the menubar now, in addition to tapping the “hamburger” button in the top left.
  • Mobile: Implemented a fix for dropdowns not displaying full width; props to deanjrobinson for his advice here.
  • Mobile: Better treatment for post revisions.
  • Mobile: Fixed multisite theme list.
  • Mobile: Align theme/plugin list checkboxes.
  • Mobile: Align theme/plugin list titles.
  • Mobile: Fixed frontend admin-bar.
  • Renamed toolbar.css to admin-bar.css for uniformity with core.
  • Added a changelog link to readme.txt.
  • Changed the minimum required WP version to 3.5, so 3.5 users will get update notifications for MP6.

This week’s iteration includes work by Joen Asmussen, Till Krüss, and myself.

If you missed it yesterday, be sure to check out our roundup of potential implementation recommendations for plugin authors who need to add a custom icon to the top-level menu. We appreciate any feedback you’ve got for us, so we can codify our recommendations for developers who’d like to add MP6-style icons to their plugins.

We’ll be back next Monday with office hours in #wordpress-ui on IRC, for anyone who would like to discuss their feedback with us. You’ll find us there 1800 UTC on June 3.

#icons, #mp6, #plugins, #svg

The MP6 team has been working on recommendations…

The MP6 team has been working on recommendations for plugin authors who add a top-level icon to the dashboard’s main menu. We’ve investigated a number of options, all of which have their own advantages and disadvantages. In this post, I’d like to share the options we’ve considered in the hopes of generating a larger discussion about what would be the best possible solution for WordPress and for plugin authors. An example of the two SVG methods is available at http://codepen.io/joen/pen/otdkK.


Method A: CSS-colored SVG icon

This method uses SVG (vector, infinitely scaleable) icons that are embedded inline in the HTML. Using this method, the icon is able to inherit the color of the admin and change depending on customizations chosen by the user (a high-contrast admin theme for vision-impaired users, for example).

Pros
  • Clean, retina, and infinitely zoomable.
  • Only a single icon file needs to be created, no need for 2x versions or separate hover/active states.
  • With colors being controlled by the admin CSS, they will always match the core set of icons, as well as any further customizations made by the user.
Cons
  • SVGs won’t render in IE8 and below. A number of possible solutions are discussed below.
  • For the CSS coloring to work, the SVG markup has to be cleaned up either manually or via an optimizer, adding some overhead to the creation.
  • The actual SVG markup has to be inline in the HTML. Hard to cache, requires core changes, potential security concerns.

Method B: CSS background-image SVG icon

This method also uses SVG icons for infinite scalability, but is applied via the CSS background-image property. Using this method, colors must be selected by the plugin author, and a separate file must be created for each color.

Pros
  • Clean, retina, and infinitely zoomable.
  • No security concerns (that we are aware of) with SVGs when used as background images.
  • No WordPress core changes are necessary.
  • SVG files can be used directly from Illustrator, no editing of the SVG necessary.
Cons
  • SVGs won’t render in IE8 and below. A number of possible solutions are discussed below.
  • Multiple files must be created for normal, hover, and active states.
  • With colors being controlled by the plugin author, they won’t match any customizations the user has made (a high-contrast admin theme for vision-impaired users, for example). Plugin authors must be mindful to use the colors recommended in the MP6 style guide (and creative plugin authors could use any colors, gradients, or styles they want).

Method C: PNG icons (the “no-build option”)

Alternatively, plugin authors could specify new MP6-style icons in the PNG format, using the same technique they use currently.

Pros
  • Universal browser support.
  • No WordPress core changes are necessary.
  • No security concerns with PNG.
Cons
  • Multiple files must be created for normal, hover, and active states.
  • Two sets of icons must be created in both 1x and 2x versions for retina displays (and more, when higher-than-2x displays appear).
  • With colors being controlled by the plugin author, they won’t match any customizations the user has made (a high-contrast admin theme for vision-impaired users, for example). Plugin authors must be mindful to use the colors recommended in the MP6 style guide (and creative plugin authors could use any colors, gradients, or styles they want).

SVG Browser Support

Internet Explorer 8 and below have no native support for SVG files. Icons in the SVG format will not display in IE8 and below as a result.

  • Modernizr’s .no-svg class could be used to specify PNG fallbacks.
  • A number of polyfills attempt to add SVG support to these browsers (we haven’t tried them).
  • We could adopt a Google Apps-style browser support policy for MP6, supporting the current and previous major release of each browser. This would drop IE8, but make room for the many new clients we’re supporting: mobile versions of Chrome, Safari, Firefox, and IE; and the Android and Blackberry browsers. We don’t know what IE8 usage is like among WP users, though.

Conclusions

Method A, inline SVG, is the best option from the designer’s viewpoint — plugin authors include a single icon and all styling is provided automatically. MP6 makes dashboard customizations like a high-contrast admin theme for visually impaired users much simpler than the current admin design — and method A makes styling plugin icons as easy as the core set of dashicons. However, the technical hurdles and possible security concerns could be significant and we need more input on whether this method is practical.

Method B would be the next-best option — it would provide the primary benefit of using SVG icons (infinite scalability) without requiring changes to core. It would be significantly more difficult (though not impossible) for plugin icons to reflect user customizations, but would still require less manual work than creating separate sets of 1x and 2x PNG (method C).

We’re interested in any thoughts that you may have, especially if you’ve worked with SVG before and can offer insight on how we could implement method A successfully. If you know of any reason why any of these absolutely won’t work, feel free to rain on our parade. 🙂

#icons, #mp6, #plugins, #svg