Make WordPress UI

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • Matt Thomas 11:09 pm on April 5, 2013 Permalink
    Tags:   

    MP6 0.6 

    Happy Friday to you all! The latest iteration on MP6, version 0.6, is now available. This was a relatively light week for us. Our focus was on fixing bugs and refining the ideas we introduced last week. Here’s what’s new in 0.6:

    • Darkened the background gradient of secondary action buttons so that they are more easily distinguished from text inputs.
    • New dashicons for table sorting, Press This, close/dismiss buttons, and image editing functions.
    • A new function that adjusts the margin created for the toolbar on the front-end from 28px to 32px, to match the larger toolbar in MP6.
    • Larger font size for textareas and text input elements (matching 14px used elsewhere).
    • Allow zooming on mobile devices for wider accessibility.
    • Corrected the positioning of the flyout submenu’s arrow when those menus appear near the bottom of the browser viewport.
    • Visual bugfixes in the Plugins section.
    • Visual bugfixes for multisite installations.
    • A hint of MP6 style applied to WordPress.org, with more to come.
    • More small bugfixes; see the revision log for full details.

    This week’s iteration included contributions by Joen Asmussen, Mel Choyce, Ben Dunkle, Till Krüss, Samuel Wood (otto), and myself.

    What’s next? We’ve got some core issues on our plate (new classes for better alerts, refined installation screens) as well as lots still to do for mobile devices.

    We’ll be meeting in #wordpress-ui at Monday, April 8, 2013 at 1800 UTC 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 12. Thanks to everyone who has helped so far by sharing your bug reports, patches, and ideas for improvement.

     

    • jayanratna 11:18 pm on April 5, 2013 Permalink | Log in to Reply

      Hey,

      Found a bug or an issue not quite sure, but anyway the custom post types that have their own icons are overlapped by the default custom post type icon wich is the pin. But everything else feels so awesome, cant get better then this.

      • Matt Thomas 11:20 pm on April 5, 2013 Permalink | Log in to Reply

        Thanks; could you let us know what page you’re seeing that on (is it in the posts table?) and what browser you’re using?

        • Manny Fleurmond 11:24 pm on April 5, 2013 Permalink | Log in to Reply

          This happened to me with a plugin I’m working on. If I don’t set a menu icon on a custom post type explicitly and use css to change the icon, you get the overlapping. I solved it by explicitly setting the icon in register_post_type to NULL;

        • Ipstenu (Mika Epstein) 12:58 am on April 6, 2013 Permalink | Log in to Reply

          And yet it works fine on Feedbacks by Jetpack, so I don’t think it’s MP6′s CSS per sey…

      • Matt Thomas 11:24 pm on April 5, 2013 Permalink | Log in to Reply

        Just re-read and saw you’re referring to custom post types, not post formats. I haven’t tested these yet but will make a note to do so next week.

    • Marko Heijnen 11:24 pm on April 5, 2013 Permalink | Log in to Reply

      • Matt Thomas 5:36 pm on April 7, 2013 Permalink | Log in to Reply

        Yep; I’ve added this to our to-do list so one of our developers can take a look.

        • Marko Heijnen 12:40 pm on April 23, 2013 Permalink | Log in to Reply

          What is this? what I’m I then? If this is an Automattic plugin then use your internal P2 fore discussing things. The MP6 projects lacks giving feedback back and to me it really seems as an open project at all.

    • Alex Mills (Viper007Bond) 12:37 am on April 6, 2013 Permalink | Log in to Reply

      I think it’s a bit odd that my mouse is given a pointer instead of a hand when hovering over the current page’s item in the menu even though the item is a link, but maybe it’s just something I need time to get used to.

      • Matt Thomas 1:32 am on April 6, 2013 Permalink | Log in to Reply

        The idea there was to help reinforce the contrast between the current item and regular links by removing its hover cursor. I can imagine uses cases where you might want to re-load the current page to refresh it, though, so I’d be alright with removing this rule.

        • Alex Mills (Viper007Bond) 11:40 pm on April 8, 2013 Permalink | Log in to Reply

          If it stays, it should be more specific and only apply to the child menu item IMO. For example if you do Posts -> Add New, the top level “Posts” gets a normal cursor which seems wrong to me as that is a link to a different page (All Posts).

      • Matt Thomas 9:20 pm on April 17, 2013 Permalink | Log in to Reply

        I decided to remove the cursor: default declarations, so every link gets the pointer cursor regardless of whether it’s the current item; if it’s clickable it gets the pointer. This is in trunk now.

    • Ipstenu (Mika Epstein) 1:01 am on April 6, 2013 Permalink | Log in to Reply

      Tags are goofy on my ipad. http://cl.ly/image/0G2A2O2b3z1S

      Sorry about the weird screenshot, but you can see the cluster of not right, I hope.

    • Hassan 1:29 pm on April 6, 2013 Permalink | Log in to Reply

      1. Why do we still have a calendar icon in the “Publish” meta box? It’s looking odd there. Also the border beneath each item (Status, Visibility, Published on… etc.) looks redundant now; we only have border beneath the meta box title. Same applies to the “Save” meta box for media files.
      2. I’m thinking plugin listing page can have those Deactivate | Delete etc. links appearing only on hover– like the action links on the post listing page = more consistency.
      3. I’m not sure about the new look for page tabs. They’re not easily recognised as tabs anymore.
      4. There’s no hover effect for some elements in the Toolbar? Update notification bubble, comments etc.
      5. Update notification bubble is sometimes blue and sometimes orange. Intentional?
      6. The site name menu in the Toolbar doesn’t offer much when in the backend. In fact, the dropdown menu with the Visit Site item is redundant since I can click on the site name to visit my site anyway. Why not get rid of it– or better yet, perhaps integrate the +New menu with it somehow?
      7. Dropdown menus in the Toolbar look a bit odd when they pop down with the white background. I’d naturally assume they’d be looking more like the floating menus in admin menu, i.e. dark background.
      8. Screen Options and Help panels are still intact I see. It has been known for a while now that with their current placement they can easily get unnoticed by many, many users. I know there’s a trac ticket about this.
      9. I’m still reluctant to swallow the visual unification of the Toolbar and the Admin Menu. Less clutter, more simplicity and streamlining– yes. But something just doesn’t feel right.
      10. In listing pages (e.g. wp-admin/edit.php) table headers are not easily distinguished from row data when both are plain text. Could be bolder or different color.
      11. We now have custom designed checkboxes but not radio buttons? These two usually go together. Oh, and also tags!
      12. In plugin listing page, can we click on a plugin’s name to select its checkbox instead of aiming at the little target, i.e. the checkbox itself?
      13. I think active plugins should be listed normally and inactive ones should have the colored border on the side not vice versa; since, naturally, majority of the plugins would be active and that’s the “normal” thing. When it has a colored border, it’s trying to say: “I need your attention here”, but no attention is actually needed.
      14. It’s time to update the default, grey loading spinner image!
      15. Is the burnt orange color gone for good?

      Keep up the great work!

      • Hassan 2:10 pm on April 6, 2013 Permalink | Log in to Reply

        11. should read “and also select HTML tags/elements”.

      • Hugh 5:52 am on April 8, 2013 Permalink | Log in to Reply

        9. I’m still reluctant to swallow the visual unification of the Toolbar and the Admin Menu. Less clutter, more simplicity and streamlining– yes. But something just doesn’t feel right.

        My first reaction to MP6 was *choke*, *gasp*, “what has WordPress become… Drupal?… is this the influence of Windows 8?” Growing up with a Dad in the U.S. Air Force there always was something endearing to the grey and blue. It’ll take me a while to get over myself… (I just activated the plugin tonight, so I have not been following the growth process.)

        But after looking at your comment #9 critically, I think part of the problem is the real-estate of the black. It is such a bold color that it feels part of the screen is missing and it takes a chunk out of left and top. It is like there is somehow less negative space, because the workspace is so well defined.

        A secondary issue might be that the visual line created by the bottom of the top bar is not respected by the left content, so there appears to be a larger space than is necessary above the “dashboard menu element”. The text of the left in my opinion, should be nudged up a bit.

        BTW: is there a visual dictionary somewhere of what to call these elements in the admin area?

    • Marko Heijnen 3:32 pm on April 7, 2013 Permalink | Log in to Reply

      wpmini-blue.png and wpmini-blue-2x.png are missing

    • davidossahdez 2:10 am on April 8, 2013 Permalink | Log in to Reply

      Hey guys, great job! I love this new dark UI. The only thing that I see a little off is the Menu Name text box, in Appearance > Menus. Take a look: http://d.pr/i/LQYi – Maybe with a little more top margin it would look better :)

    • Avryl 11:23 am on April 8, 2013 Permalink | Log in to Reply

      I really love this! : ) I’m not sure if this is the right place to give feedback, but here are some tiny details:

      There’s a white border right beneath the widefat table head. Of course this is only visible when the first row is has a darker background.

      Caused by this:

      .widefat td, .widefat th {
      border-top-color: #fff;
      border-bottom-color: #fff;
      }
      .widefat td, .widefat th {
      border-width: 1px 0;
      border-style: solid;
      }

      Compare the top to the bottom bit:

      white border 1

      white border 2

      When the side navigation is collapsed, the arrows on hover are still bigger than the one for the current page. The colours are also a bit weird…

      sidebar 1

      It might also look nicer if there’s only one arrow on the (uncollapsed) side navigation that follows the hover state. It looks a bit weird when you hover over an item just above an active item.

      sidebar 2

      • Joen Asmussen 1:05 pm on April 9, 2013 Permalink | Log in to Reply

        About the white border, I’m not 100% what the problem is, though be aware my eyes are old! Can you elaborate?

        Fixed the issue with the dark flyout header, good catch.

        Re: hiding the arrow on active menu items when hovering, I think it would look weird that it disappeared whenever a menu was rolled over.

        • Avryl 3:15 pm on April 9, 2013 Permalink | Log in to Reply

          So there’s a white 1px border on the top and bottom of every td and th element in the widefat table. It’s only visible if there’s a non white row at the top of the table, except for active plugins because the border is then set to none. The border is created on line 577 of wp-admin.css, so you can just overwrite it as it is done for the plugins table on line 1624 of colors-mp6.css.
          Sorry for going on about this, it’s just a tiny detail of course… : )

    • mrwweb 5:55 pm on April 8, 2013 Permalink | Log in to Reply

      I’m seeing a really weird font bug in Firefox 19.0.2 on Windows 7. I’m running WordPress 3.6-beta1 with MP6 and Twenty Thirteen.

      When you hover over any admin menu item that has a submenu, the font in the entire admin menu gets blurry/pixelated. I put together an animated gif to show the difference: http://mrwweb.com/files/mp6/mp6-firefox-menu-font-bug.gif

      I haven’t had much luck debugging. The issue doesn’t appear in Chrome, and I even tested it in Firefox with all my extensions disabled. It persists even then.

      Possibly the weirdest thing is that when I open Firebug to try to debug the issue, the problem is resolved. When I close Firebug is comes back. It’s all very confusing, but the bug makes WP almost unusable in Firefox for me. It’s just so unpleasant to have that happen every time I use the admin menu.

      • Hassan 7:05 pm on April 8, 2013 Permalink | Log in to Reply

        Yeah, I’m also seeing that bug with Firefox on a couple of sites, not just wp-admin. Not quite sure what’s causing it.

      • Joen Asmussen 1:02 pm on April 9, 2013 Permalink | Log in to Reply

        I’m unable to reproduce this in the just-released Firefox 20. Can I get you to test again and see if the problem persists? It’s possibly related to the icon font which has -webkit-font-smoothing: antialiased applied, though that shouldn’t affect Firefox as it doesn’t have this property.

        • mrwweb 7:31 pm on April 9, 2013 Permalink | Log in to Reply

          Doing my best to isolate this. Now on Firefox 20.0. The problem still exists, however, here are some more caveats:

          • It only applies when the #adminmenuwrap has “position: fixed.” This works both by removing the property with firebug OR making the window short to remove the fixed positioning.
          • It only applies when using the web font. If you fall back to the generic “sans-serif” font, the problem goes away (independently of the issue above).

          • mrwweb 7:35 pm on April 9, 2013 Permalink | Log in to Reply

            Oops. One more thing to note: I’ve seen various Firefox-related font-rendering problems related to Hardware Acceleration. At least in my testing, the problem persists regardless of whether that’s enabled or not.

    • Alex Mills (Viper007Bond) 11:38 pm on April 8, 2013 Permalink | Log in to Reply

      FF 19.0.2, latest trunk WP as of this comment, MP6 0.6 (not trunk). Issue with the alignment of the plugin update icon:

      screenshot

    • Matt Thomas 7:18 pm on April 9, 2013 Permalink | Log in to Reply

      My apologies if anyone missed us in IRC yesterday; I got wrapped up in work and forgot to sign on. Let us know here if you have anything you wanted to give feedback on, and we’ll catch back up at the regularly scheduled time next week.

    • mrwweb 9:02 pm on April 9, 2013 Permalink | Log in to Reply

      Small bug in revisions: The tooltip appears below the title:
      mp6 revisions tooltip bug

    • Terry Sutton 12:04 pm on April 11, 2013 Permalink | Log in to Reply

      The plugin page feels a bit overwhelming on first glance, even with not too many plugins installed. This screen adds a little extra padding after the plugin name column, a light yellow on those to be updated, and softens the second row of the description a little( .plugin-version-author-uri).

      http://cl.ly/image/2G3V1J2H3d2d

  • Matt Mullenweg 1:40 am on March 30, 2013 Permalink
    Tags:   

    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.

     

    • 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 convention has been set, facebook, google+, youtube, the WordPress for the iPhone etc
          • Too many admin toolbar items means it overflows and the little grappler icon can no longer be clicked, making the admin menu unusable
          • You have to scroll up to the top if you want to use the menu

          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.

    • 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? :)

    • 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

      Stop squinting: WordPress is almost ten years old and needs bigger fonts.

      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

  • Matt Thomas 6:55 pm on March 22, 2013 Permalink
    Tags:   

    MP6 version 0.4 

    It’s Friday, so here’s a little something to make the weekend feel like it’s getting here faster: this week’s update to MP6, version 0.4. This was a short week for the team so there’s not as much as in the last couple of versions, but there’s still plenty here that we’d like your feedback on. Here’s what’s new:

    • The MP6 toolbar styles now load on the front-end of your site, so we can see how themes interact with the slightly darker, flatter, larger toolbar design.
    • The Plugins page has been re-thought, eliminating the opacity change for inactive items in favor of a blue border and background to denote activated plugins. We were aiming for something that wouldn’t be overwhelming if you have a long list of all-activated plugins, but that provided for more contrast between active and inactive items than the current design.
    • Updated MP6′s styling in the Menu management page; this is still unfinished.
    • New checkboxes are larger (easier to click/tap) and unify the visual styling of checkbox elements across almost all browsers/platforms.
    • Replaced more PNG raster icons with vector Dashicons — arrows, calendar icon, collapse button, etc.

    There are a number of items that have been discussed in the comments and on IRC — just because you don’t see them here yet doesn’t mean we’ve decided not to do it — just that we haven’t done it yet. So keep sharing your ideas and suggestions please; but don’t assume anything you see is considered absolutely final just yet.

    This week’s edition includes contributions by Ben, Mel, Otto, and myself. Thanks also to Mark J, Joen, Matt and all the others who offered feedback that made it into this week’s work.

    We’ll once again meet in #wordpress-ui on Monday, March 25 at 1800 UTC to go over this week’s edition and discuss your ideas for future iterations. That will be followed by the release of the next version a week from day on March 29.

    Looking forward to your thoughts and ideas for improvements!

     

    • Tevya 7:07 pm on March 22, 2013 Permalink | Log in to Reply

      Just in case it got lost on the previous post/thread, here’s my suggestion for buttons that blend more with the flat interface, while still looking like buttons by maintaining a subtle gradient. All I did was remove the border radius and the inset shadow:

      • Matt Thomas 7:10 pm on March 22, 2013 Permalink | Log in to Reply

        Yep, we’re still going to take a look at toning down some of the lighting effects on buttons to bring them a little more inline. Mel’s suggestion on the other thread also reminded me of a similar style we’ve used on WordPress.com: http://cl.ly/image/2S3v1B463R3N/

        • Tevya 7:15 pm on March 22, 2013 Permalink | Log in to Reply

          Personally I think I like how the square corners fit with the square corners of everything else. But those look great. They’re much more flat, without being completely flat so they look like buttons. In my humble opinion, either would be awesome.

          • buzztone 1:32 am on March 23, 2013 Permalink | Log in to Reply

            Definitely agree – the square cornered buttons match really well with the rest of the interface. The rounded cornered buttons look odd – a bit of a remnant left over from 3.5.1.

            • alternatekev 5:09 pm on March 23, 2013 Permalink

              I would normally agree – and visual consistency is important – except that here, we’re hinting at interactivity, and rounded corners inevitably feel more clickable than square corners, especially when square edges adorn just about every other non-clickable page element. Making these 2-3px rounded humanizes the button and allows us not to rely entirely on color and text to denote interactivity.

              Just a thought.

      • Jesper van Engelen 10:39 pm on March 27, 2013 Permalink | Log in to Reply

        In my opinion, flattening the buttons this much does not improve the visibility of these elements as buttons. The issue does not occur for the primary buttons as they stand out because of their color (obviously) but the secondary buttons, in this case the “Preview Changes” button blends in so much that it is hardly recognizable as a button. In this particular case, of course, it is well known that there is a button there – but what to think of custom plugins where the button is used inside, for example, a post list table? In that case, the button will blend in with the rest of the content to the extent where people won’t know it’s even usable as a button.

    • Jerry Bates (JerrySarcastic) 7:15 pm on March 22, 2013 Permalink | Log in to Reply

      Looks great! I think the plugin page is a big step forward, though I also liked the hover effect on deactivated items; some deemphasis of inactive plugins is still helpful, even with the blue boxes in place.

      I did notice a bit of a problem with a repeating down arrow image in the screen options and help tabs on my retina mac, where “arrows-2x.png” are still being called in the stylesheet:
      http://cl.ly/image/3X2g2m1z3v0N

      • Matt Thomas 7:24 pm on March 22, 2013 Permalink | Log in to Reply

        Whoops! Good catch. I overrode the 1x graphics but forgot to do the same for the 2x versions. Just committed an update to trunk that fixes this; you should be able to update to it shortly.

    • Marko Heijnen 7:30 pm on March 22, 2013 Permalink | Log in to Reply

      I think the checkboxes or little bit to big on the plugin screen. ( don’t think this is a retina issue ).

      Also curious what the opinion was to make the menu color on hover blue. I don’t think that makes it really readable.

      • Matt Thomas 7:34 pm on March 22, 2013 Permalink | Log in to Reply

        The checkboxes are intentional — standard checkboxes are 10px square and I find them frustratingly difficult to target, whether with a mouse, trackpad, or touchscreen. The new checkboxes are 16px square, and add some hints that you can interact with them, by changing the cursor to pointer and darkening the background color. I’m happy to consider sizing alternatives here, but I hope folks will try using the big checkboxes for a few days and see if they start to feel normal to you; they definitely do to me now.

        • Tevya 8:07 pm on March 22, 2013 Permalink | Log in to Reply

          I really like the large checkboxes. They look great and are easy to click.

        • Archetyped 8:59 pm on March 22, 2013 Permalink | Log in to Reply

          I don’t have an issue with larger checkboxes, but at least on Firefox, the styling has caused the checkboxes to be less usable.

          System/OS controls do not react to styling the same way across all platforms, which is why modifying default styling of these controls is generally not recommended.

          If larger hit targets (especially for mobile) is the goal, then why not allow clicking on the plugin titles, or clicking anywhere on the plugin’s row (save for where actual links are) for that matter, to cause the checkbox to be selected?

          That would be far more finger friendly and wouldn’t the maintenance nightmare that modifying system controls can be.

        • buzztone 1:56 am on March 23, 2013 Permalink | Log in to Reply

          I think the larger checkboxes are an improvement – but on Firefox they are very hard to see. Better on Chrome and better still in IE9.

          Also I get no on-hover over checkboxes feedback in either Firefox or IE9 and only extremely subtle in Chrome.

          The blue on-hover over checkboxes in 3.5.1 is very strong which compensates partly for the overly small box size.

        • Matt Thomas 2:07 am on March 23, 2013 Permalink | Log in to Reply

          Yeah; Firefox is a little unkind in how it treats checkmarks with -moz-appearance: none applied (not how you’d expect, given the way that webkit browsers do it). Lovely thing about browser-prefixed selectors though; if a browser doesn’t support it fully, we can just eliminate the rule for that browser. Removed -moz-appearance: none from trunk for now so Mozilla browsers will see default checkboxes, everybody else gets the new ones.

      • Matt Thomas 7:35 pm on March 22, 2013 Permalink | Log in to Reply

        Regarding blue on hover: the contrast of the light blue against the dark grey felt contrasting enough for me, and there haven’t been too many complaints about its readability yet. But this is something we may continue to tweak along with borders in the sidebar and a number of other possible treatments for menu bar items.

    • Ipstenu (Mika Epstein) 10:34 pm on March 22, 2013 Permalink | Log in to Reply

      Woah. Plugins YAY. That blue line caught my eye and within a second I knew “Oh, this is active!” It’s like the Apple Dock and the little light. That was great, Matt!

      The actual colors though are … well I couldn’t tell it was a blue box on my non-Retina Macbook until I leaned waaaaaaaay back and angled the monitor. That meant the side-line and bold text was perfect. Even without color it was okay. (My doctor says I have issues with green backgrounds, wonder if this is related…)

      • Matt Thomas 2:03 am on March 23, 2013 Permalink | Log in to Reply

        Thanks! Mark Jaquith suggested the line; Joen suggested the blue background. Together I think they work well. I wanted to use a background color that was subtle enough it wouldn’t be irritating if you’ve got 20 plugins that are all activated (that would be a lot of any strong color). I also wanted to try something that wouldn’t require opacity changes, given esmi’s accessibility concerns about them below. My hope was that this would work with or without the background-color though, so that’s great to confirm. (Un-bolding the text really makes a lot of difference!)

    • John Blackbourn (johnbillion) 11:17 pm on March 22, 2013 Permalink | Log in to Reply

      For some reason the “Disable the visual editor” checkbox on the profile screen has its border missing and is generally a tad wonky.

    • Matt Thomas 2:00 am on March 23, 2013 Permalink | Log in to Reply

      There were a couple of annoying bugs in 0.4 especially for hi dpi screens, so I tagged 0.4.1 with some fixes for those issues. That’s the version we’ll discuss on Monday.

    • Dean Robinson 10:54 am on March 26, 2013 Permalink | Log in to Reply

      Can’t really join in the IRC chats (silly timezones), and only had a quick scan through the logs, so forgive me if this has already been covered and dismissed.

      The admin bar and menu being the same colour, with no real division, is probably the only thing I’m not 100% liking after playing with MP6 for a few days. Was any consideration given to styling the admin bar in a similar way to the bar on WordPress.com (quick mockup: http://cl.ly/NpLj ) or would it be somewhat “off limits” to keep .com and .org visually separate.

      The blue bar and blue menu item would potentially clash if they were both blue (mockup with grey ‘active’ item: http://cl.ly/Noxy ), and maybe the blue is just too bold when the rest of the UI is so dialed down – but its just a thought.

      • Matt Thomas 5:34 pm on March 27, 2013 Permalink | Log in to Reply

        Thanks, Dean. I had tried something similar in my private noodling, but we hadn’t discussed the idea yet. I think there’s something to it for sure, but in the end I think most of us were pretty drawn to the seamless effect created by putting both the toolbar and sidebar navigation on a single background. As Joen put it, “laying a white piece of paper on a dark surface.” Mark Jaquith’s carpenter’s square analogy also felt apt. Treating it all as one element is an attempt to harmonize what felt before like too many incongruous style choices on what are all essentially navigation elements.

    • Jose Castaneda 8:33 pm on March 27, 2013 Permalink | Log in to Reply

      Truly loving the progress so far. The one thing that I did notice is the “wp-menu-separator” gives it a bit of weird look, to me. I understand there should be a difference between the groupings but it looks odd without a noticeable/visible difference.

    • Till 8:32 am on March 28, 2013 Permalink | Log in to Reply

      The new toolbar is 32px tall, but the padding is still set to 28px. See in html.wp-toolbar in http://core.trac.wordpress.org/browser/trunk/wp-admin/css/wp-admin.css#L1914

  • Mark Jaquith 8:37 am on March 22, 2013 Permalink  

    Should we tab the Plugins page with Manage Plugins / Install Plugins in the same way that we’ve done with Themes? Why or why not?

     

    • Franz Josef Kaiser 10:14 am on March 22, 2013 Permalink | Log in to Reply

      Personally I don’t see any value in adding tabs. What I would see value in, is having a way to organize or group plugins. Currently I have ~200 custom written plugins that I manage with this [1] plugin, which makes my local stack quite slow. As a developer I’d really like to have any kind of way to better organize those plugins and not use a slightly fragile, slow plugin that took a lot of time to develop.

      From a user perspective I’d like to see an UI that is equally designed and usable to the one we have for themes. Basically both are the same so I would expect to have a lower entry barrier for new users. From a core dev perspective this would as well offer a chance to remove redundant code pieces when both screens can share parts of their view building code.

      [1] https://github.com/franz-josef-kaiser/WP-Plugin-Directories

      • Russell Heimlich 12:54 pm on March 22, 2013 Permalink | Log in to Reply

        +1 on the idea of better organizing plugins. I thought about writing a plugin that lets you type in a field and the plugins shown get whittled down to only show the ones that match parts of what you type. Similar to the filter topics feature of this page http://www.pewresearch.org/topics/

      • Scott Kingsley Clark 1:25 pm on March 22, 2013 Permalink | Log in to Reply

        I also would like to see some sort of categorization (whatever that is) in the plugins list.

      • Shane Pearlman 3:10 am on March 23, 2013 Permalink | Log in to Reply

        +1 of on plugin organization, at least in regards to add-ons and extensions to larger plugins. The events calendar has a number of add-ons and it would be nice if they were grouped visually.

    • Russell Heimlich 12:55 pm on March 22, 2013 Permalink | Log in to Reply

      Yea I think so. It follows the theme of tabs that I’m starting to see show up in the admin interface. This would make a great user test to see if new users can find where to add new plugins easier than the way it currently is set-up now.

    • Scott Kingsley Clark 1:27 pm on March 22, 2013 Permalink | Log in to Reply

      I’d like to see tabs used here, not for just using tabs, but in hopes that the theme search UI may eventually be used for plugins too so you could filter by category (see Franz’ comment above) and other criteria (maybe).

      In my opinion, it would make the plugins page and add plugin page a little more consistent with the themes and add/search theme pages.

    • Tevya 2:32 pm on March 22, 2013 Permalink | Log in to Reply

      Plugins should look like Themes or Themes should look like Plugins. As far as I’m concerned, either is fine, just make it consistent. I’ve long wondered why they’re so different. Consistency please.

      • Tevya 2:44 pm on March 22, 2013 Permalink | Log in to Reply

        On 2nd thought: I’m not a big fan of the “tabs” on the Themes page. In MP6 they don’t really look like tabs anyway. Why not make it more like every other page in the WP admin and remove the “Manage Themes” tab entirely, and turn “Install Themes” into a small “Add New” button like on Plugins, and Posts, and Pages, etc???? That would be the most consistent.

      • Chip Bennett 9:34 pm on March 22, 2013 Permalink | Log in to Reply

        +1 for consistency between Themes and Plugins, whichever UI is ultimately chosen.

    • Ipstenu (Mika Epstein) 3:07 pm on March 22, 2013 Permalink | Log in to Reply

      Tabs, or buttons, since right now the links are small and I’ve had to send that screenshot of ‘This’ circled enough times this month ;)

    • Helen Hou-Sandi 3:14 pm on March 22, 2013 Permalink | Log in to Reply

      They should be consistent, yes.

    • sara cannon 6:09 pm on March 22, 2013 Permalink | Log in to Reply

      yes.. but if we go that direction, it would make sense to match the levels that they are in the menu hierarchy: possibly bringing themes top level (matching plugins) and letting appearance be about visual modifications / theme customizations & menus, widgets.

      • tomdryan 10:42 pm on March 27, 2013 Permalink | Log in to Reply

        Yes! Speaking as a relatively new WP user, there do need to be some simple changes to the menu hierarchy (and elsewhere) that can reduce the learning curve and increase the usability of WP. Is there a usability work group for WP or is that addressed in this group? In any case, I would love to contribute some usability feedback while all the fumbling around I did is still fresh in my head. :)

    • Mike Schinkel 12:15 am on March 23, 2013 Permalink | Log in to Reply

      I’d really like to be able to archive plugins, i.e. not delete them but ZIP and keep on the local system for later unarchive and (re-)activation. It would also be really great if we could group plugins and collapse the group so we don’t have to look at the long list of plugins. Finally a simple thing would be to have the list of activated plugins be the default rather than all plugins.

    • buzztone 2:21 am on March 23, 2013 Permalink | Log in to Reply

      I’d like to put in a cheer for Tabs on the Plugins Page. Used well they could significantly improve the usability of the interface.

      Some of the better plugins, like Yoast WordPress SEO, are now using tabs to significantly improve the ease of use of their plugins. Ease of use of the Plugins page could similarly be improved by adding some useful Tabs, starting with Manage Plugins / Install Plugins.

    • Matt Thomas 5:34 am on March 29, 2013 Permalink | Log in to Reply

      My +1 would go to making Themes work like other sections — where there’s an “Add Theme” button-like link next to the main themes header (this would re-use the same pattern as Posts, Pages, etc. too, not just Plugins). We struggled a little bit with what to do with this tabbed style in MP6, since it’s unique to the Themes pages (it appears on the About page too, but in a little different context).

  • Matt Thomas 7:38 pm on March 15, 2013 Permalink
    Tags:   

    MP6 version 0.3 

    Thank goodness it’s Friday! Because Friday means it’s time for an update to MP6. As we’ve mentioned before, this is not intended for the general public, just for savvy WordPress enthusiasts eager to preview or contribute to a re-imagination of our collective home, wp-admin.

    On Monday we met on IRC in #wordpress-ui to discuss feedback on last week’s iteration. We’ve taken that feedback, plus the comments left here on this P2, into account in what we’ve done this week. Here’s what’s new:

    • Almost all icons are now served from the Dashicons font. Work continues on the remaining raster icons.
    • The Plugins page now has borders and more padding between rows in the table. Opacity is only used for text, so their checkboxes stay fully opaque.
    • .widefat tables, .postbox divs and other containers have a deeper drop shadow and a new header design that more clearly defines the container from the background, and the header from the rest of the element.
    • Folded menus now get a small arrow for the current section. The way the arrow appears/disappears with the submenu isn’t great; if we remove the delay on submenus this might not be an issue.
    • The tabbed style of the Appearance section header has been removed.
    • The WordPress logo on the About page is now an SVG.
    • Page headers are now regular instead of light weight.
    • Admin color options are hidden when MP6 is present, as the plan is to only ship with one color scheme (though it will be even easier than before to customize your own).
    • The new comments/updates notification bubble is now #d54e21 instead of gray, to give it more emphasis.
    • We’ve included an example of a plugin icon in SVG format. We chose Jetpack as a common plugin that users might have installed alongside MP6. This is our suggested design for plugin icons, but not yet the final suggested method of implementation.

    Here are things that we discussed in feedback, but didn’t implement this week:

    • Test new values for green/amber/red status text.
    • Make adjustments to the secondary button styles for more contrast with the background.

    This week includes contributions from Ben, Mel, Isaac, Joen, Otto, and myself. Many thanks as well to those who gave their feedback, ideas, patches, and bug reports during Monday’s meeting.

    Like last time, we’ll do office hours on Monday to discuss next week’s iteration, followed by version 0.4 on next Friday; March 22. To save myself the time zone embarrassment from last time, let’s aim for 1800 UTC, whatever time that happens to be wherever you are in the world. Arrive an MP6 enthusiast; depart an MP6 contributor!

     

    • Jerry Bates (JerrySarcastic) 7:47 pm on March 15, 2013 Permalink | Log in to Reply

      Looks great! In the end I agree that in the end #222 for the toolbar/admin menu looks the best. Funny how it grows on you…

    • Michael Adams (mdawaffe) 8:05 pm on March 15, 2013 Permalink | Log in to Reply

      The active menu item indicators look strange to me when hovering over an adjacent menu item.

      http://cl.ly/image/1K0B1S3M1s33

      • Matt Thomas 9:07 pm on March 15, 2013 Permalink | Log in to Reply

        Yeah; that’s a little awkward but haven’t had a better idea for how to treat it yet. Maybe let the submenu overlap the main menu slightly? I think it would be awkward if the arrow disappeared.

    • esmi 8:33 pm on March 15, 2013 Permalink | Log in to Reply

      Oh – nice plugins! And pretty UI. Three areas of concern from an a11y perspective, though:

      1. Can the contrast on “Collapse Menu” be pushed up a little to #888? Currently it’s a little too low for confort and well below the 4.5:1 suggested ratio.

      2. Post revision comparisons. Not sure I’m comfortable with red-on-red and green-on-green. At present, the contrasts are way too low at 2.7:1 (heck – even I’m having problems reading the changes).

      3. Ditto the text for inactive plugins on the Plugins page. Seriously – 2.8:1? And absolutely no way to “highlight” it without a mouse?

      On the plus side – love the new look. And plugins that hooked into the previous UI should port over really well judging by our tests with eShop.

      • Matt Thomas 9:06 pm on March 15, 2013 Permalink | Log in to Reply

        Thanks; this will be helpful as we work on the next iteration. FWIW I haven’t even looked at post revisions yet, so something truly buggy/awful may be in effect there.

    • Ze Fontainhas 9:20 pm on March 15, 2013 Permalink | Log in to Reply

      I love the changes and am really looking forward to what’s coming.

      Since I cannot help it, and fully aware that it might be a tad to soon to discuss this, I’d like to just leave the obligatory note regarding i18n, particularly in what concerns translated strings which are longer than their original English counterparts. Since the CSS is being discussed, perhaps some of this could be taken into consideration. Other than that, amazing work, thanks.

      • Matt Thomas 9:39 pm on March 15, 2013 Permalink | Log in to Reply

        Thanks, Zé — I’ll definitely do a run in various languages to check for copyfit; some languages have a real knack for exposing places we’re forgotten to consider line-height, padding, or margins.

        Another i18n consideration is the Open Sans subsetting. We currently only load the latin subset, which means that languages that use latin extended are seeing an unholy mix of Open Sans and their system default sans-serif. We’ve talked a little bit about having MP6 automatically load subset extensions depending on what you need: latin, latin-ext, cyrillic, cyrillic-ext, greek, or greek-ext.

    • ianarmstrong 11:38 pm on March 15, 2013 Permalink | Log in to Reply

      Hey Matt, do you plan on using modern responsive techniques on the admin bar? It still wraps in an ugly way on mobile: http://imperativeideas.com/misc/dev/stillaproblem.png

      I hoped to see that remedied in the new version.

    • Till 1:36 am on March 16, 2013 Permalink | Log in to Reply

      I’d love to see the new admin menu float by default: http://wordpress.org/extend/plugins/floating-admin-menu/

    • Marco Galasso 10:32 am on March 16, 2013 Permalink | Log in to Reply

      v 0.3 Line 2607 should be:
      #menu-management .nav-tab:hover {
      background-color: #2ea2cc;
      color: #fff;
      }
      if not the hover state is white on white.

      • Matt Thomas 5:05 pm on March 18, 2013 Permalink | Log in to Reply

        Could you post a screenshot of where you’re seeing white on white? That line is actually used for tabs on other screens, so adding the #menu-management ID would break it in those locations. I haven’t looked at the menu management screen yet at all, really.

    • Paul 10:46 am on March 16, 2013 Permalink | Log in to Reply

      I think it needs more contrast, so I’d avoic grey on black and replace it with white. I’d also make the main content area background white, or at least a very lightt grey.
      And I’d replace the font with something a little bolder. Just to make everything more visible

      • Remkus de Vries 12:31 pm on March 16, 2013 Permalink | Log in to Reply

        I would say the current v0.3 version should definitely be improved with a strong focus on contrasts. The widgets in the widget areas are way to subtle right now as well.

    • buzztone 5:47 am on March 17, 2013 Permalink | Log in to Reply

      The Plugins list remains confusing for me (as noted last week by Mike Schinkel). It is quite difficult to distinguish between different plugins.

      Posts and Pages lists are easy to distinguish, despite removal of the lines between posts, due to the alternating white and grey backgrounds.

      Lines may need to be retained on Plugins list

      • Matt Thomas 4:48 pm on March 18, 2013 Permalink | Log in to Reply

        We’ve got some thin lines between items in the plugins list now, but I agree it probably still needs more work. We’ll continue trying different things on that screen.

      • Ipstenu (Mika Epstein) 5:27 pm on March 18, 2013 Permalink | Log in to Reply

        Can you see the lines in-between on your monitor? I checked on four (including iPad) and they look okay. 2 pixels didn’t see too heavy to me, but it makes me notice that the lines don’t extend all the way.

        http://cl.ly/image/2N2P1B1B2Z3R

        • Matt Thomas 7:55 pm on March 18, 2013 Permalink | Log in to Reply

          the lines don’t extend all the way.

          Eek, good catch. I’ll get that fixed too.

          • buzztone 1:18 am on March 23, 2013 Permalink | Log in to Reply

            With changes made in v0.4 this is now really clear. The blue border and background to denote activated plugins look great.

            It also makes more sense to me in that it emphasises activated plugins. The grey backgrounds in 3.5.1 to me made the deactivated plugins stand out more.

            The use of the blue colour really improves the clarity of the Plugin List.

    • Tevya 4:44 pm on March 18, 2013 Permalink | Log in to Reply

      The buttons! The buttons are still rounded and given a slight “bubble” effect. Make them flat with square corners like everything else.

      • Matt Thomas 4:49 pm on March 18, 2013 Permalink | Log in to Reply

        I’ve been hesitating to change the buttons, because after using the Windows 8 “Metro” design language both in win8 and on the web (SkyDrive, etc.) I found the purely-flat buttons to be not quite buttony enough. Maybe squaring the corners or some other more subtle changes would be appropriate. That’s why I’m hesitant to remove the gradient and shadow styling.

        • Matt Mullenweg 6:47 am on March 19, 2013 Permalink | Log in to Reply

          Agreed.

        • Mel Choyce 1:10 am on March 20, 2013 Permalink | Log in to Reply

          I agree with both Matts — we don’t want to go too Metro. It starts getting hard to tell what’s a button and what’s not.

          Here’s a super quick stab at toning down the button styles: http://cl.ly/image/1V1n1r0S2M3B It could even be a little less subtle, honestly.

        • Tevya 2:55 pm on March 22, 2013 Permalink | Log in to Reply

          I can understand that. I’d suggest removing the rounded corners, but including a subtle gradient like Mel demonstrated. As it is the blue buttons (Publish/Update) stick out like a sore thumb. Even just going to a straight gradient would help a lot, I think. Here’s an example. All I did was turn off the rounded corners and the inset shadow and I think it looks much more consistent with the rest: http://db.tt/FKkok65u

    • corrinda 3:55 pm on March 19, 2013 Permalink | Log in to Reply

      The color used for the copy for the pages with the light colored background is a little too light making it difficult to read. This is the first time I’ve sen the proposed design for the Admin UI. There are some interesting changes but have to say I find the heavy black menu on the left rather imposing and with a rather cluttered look without the dividers.

    • jameskoster 5:56 pm on March 19, 2013 Permalink | Log in to Reply

      Perhaps I’m missing something but I find myself questioning the point of this plugin?

      If it’s to make the admin panel inline with current design trends, that’s fine. But aren’t there more important UI things to consider at this point? Like optimising the markup / css, utilising a CSS Preprocessor, transitioning from px to em / rem, removing all bitmap images, going fully responsive, consistency etc etc?

      I appreciate that cannot all be achieved with a plugin (perhaps that’s why MP6 exists – to see if there’s demand for a new aesthetic), but laying the groundwork properly first would make skinning / iterating the current design so much easier in the long term. Shouldn’t that be the priority?

      My 2c on the design perspective; I think the admin bar should have a different background-color to the left hand nav. Seeing as it sits ‘on top’ of the main nav, I’d suggest making it slightly lighter to differentiate between the two. Right now they appear to be part of the same entity, until you scroll. Maybe even try blue http://cl.ly/image/3t273s2H3S0t ?

      Why no rounded corners? Curved corners can make a UI seem more friendly, which is important in something as daunting as WP. Would be interested to hear the psychology behind ditching them.

      I think the icons in the main nav are more seamless if set in the same size as the link text http://cl.ly/image/213t0S1O2G0Z

      The design stuff is all subjective of course (and that’s the biggest challenge with a project like this), but I’m interested to see where it all leads!

      • Helen Hou-Sandi 10:25 pm on March 19, 2013 Permalink | Log in to Reply

        The point of the plugin, at least in my understanding, is to explore what we can do with the admin to do things like incorporate vector/font-based icons as a part of the visual language, what aesthetic changes are needed to meld with the icons or vice versa, what issues there may or may not be regarding visual hierarchy and workflow representation on various screens, and just get a little adventurous in a way that fits better with what a cross-cycle, rapidly-developed plugin can do.

        I don’t think what the plugin currently does means it’s going to exclude things like CSS cleanup or better docs or starting to look at responsive, etc. It’s in development and is open to contributions; I know that I have contribution goals for this plugin that are not aesthetic-related. I also think that a CSS preprocessor is rather besides the point in this situation, and for all the asking for core to use one, I haven’t seen any actual practical demonstration of how one would be best used for WordPress and how it affects contributors, despite specifically having asked for it. See http://core.trac.wordpress.org/ticket/22862#comment:2. Please feel free to demonstrate – I genuinely want to see it!

        HTML structure is an entirely separate issue, and you are correct, it cannot be addressed in a plugin. It is extraordinarily difficult to change markup in the admin – many, if not most, markup changes made in core elicit reports of breaking something somebody was doing. Sometimes it’s acceptable (they were doing something hacky); more often it’s not. Either way, the reality is that making those changes and then following through with feedback and commentary is quite time consuming and there never do seem to be enough front-end dev bodies, and even fewer who want to jump into this less glamorous side (and who can really blame them?)

      • Matt Thomas 10:44 pm on March 19, 2013 Permalink | Log in to Reply

        To add to what Helen said, I’d just say that MP6 doesn’t stand in the way of any of the “more important UI things” mentioned above. While MP6 grew out of an effort to update the dashboard icons in 3.6, the work that is being done on it should have no effect on any efforts to optimize markup, use preprocessors, going fully responsive, etc (removing all bitmap images is something we’re doing in MP6). That’s why it’s a plugin — while our hope is that many of our suggestions eventually make their way into core, none of us are core team members, so no time is being taken away from the bigger tasks that lay ahead.

        • Helen Hou-Sandi 3:38 am on March 20, 2013 Permalink | Log in to Reply

          Indeed. I’m just doing drive-by observations with MP6 until at least 3.6 RC (when I stop being able to commit as a guest committer) – the whole focusing on the core cycle thing :)

    • Mike McAlister 7:50 pm on March 20, 2013 Permalink | Log in to Reply

      I love the idea of the dark navbar. It gives the admin more of an app feel, which I think WordPress is well suited for, given its many modules.

      I do think, however, that the current MP6 dark menu could use a little more detailing. I grabbed the plugin and spent a half hour tweaking a few thing. You can check out the differences here: http://cl.ly/NhFi

      Some of these notes may have been suggested, but here are a few thoughts.

      • I love the adoption of the flat UI, but it leaves the admin menu feeling sparse and disconnected. Links seem to run into each other and it’s harder to navigate. Menu items need more distinction.
      • The dark is almost too dark, making it feel like an older interface, rather than something new or iterative.
      • The blue hover links in the menu need to be lightened if you’re going to use blue. Both colors are too dark/harsh to be optimally legible on hover. In my edits, I kept the icon blue but the text hovered to white.
      • I love Open Sans on the WordPress.com site. It feels a little off in the admin though. It’s a bit more playful of a sans-serif and contributes to the dark color feeling more retro than contemporary. Helvetica Neue felt very solid and modern and would compliment a dark menu well.
      • Several people have noted this already, but the admin bar should stand out from the admin menu.

      So anyway, I’ve really only tinkered with the menu (and briefly at that), but I think some of these modifications could really get the dark admin menu on track. If you’re interested in test driving my iteration or peeking at the code, you can download the plugin here: http://cl.ly/NhNy.

      • Kelderic 10:35 pm on March 20, 2013 Permalink | Log in to Reply

        I really like your changes to the main menu. Adding lines between each menu items is a distinct improvement. One thing I’d suggest is continuing that and adding lines between the sub-menu items.

    • Shea Bunge 9:22 pm on March 20, 2013 Permalink | Log in to Reply

      Very nice! One thing, shouldn’t the visual editor font default to Open Sans instead of Georgia? It looks a little strange against the new interface

    • Dean Robinson 6:51 am on March 22, 2013 Permalink | Log in to Reply

      Oh my, this is looking very nice. Liking where its headed thus far, but that’s probably not a massive surprise. I’ve really been liking the WordPress.com interface lately (in particular the super simple new post interface), so nice to see some of that style filtering through.

      Also feels a lot like where Fluency Admin might have been (and a little of where it had already been) if I’d had enough time to keep it up-to-date over the past couple of years (time that was put to other uses because the core admin had already gotten close enough to Fluency that I couldn’t really justify spending more time on it).

      Really looking forward to see how this evolves.

  • lessbloat 5:06 pm on March 12, 2013 Permalink  

    We decided to test bringing the theme locations back out as a meta box (instead of using checkboxes) to figure out if the old layout would work for users.

    For this test, I removed theme locations as checkboxes, and added the theme locations metabox back in. I also moved the “Automatically add new top-level pages to this menu” option back to it’s old spot, because it looked odd by itself.

    Here are the results:

    User #17

    Here’s the video.

    Step 1: Log in

    No issues.

    Step 2: Go to menus

    No issues.

    Step 3: Reorganize pages

    No issues.

    Step 4: Preview changes

    No issues.

    Step 5: Remove menu item

    No issues.

    Step 6: Add another menu

    2:30 – She doesn’t see the “create a new menu” link. She starts typing in the existing menus name field, thinking she’s creating a new menu.
    3:20 – After saving her changes, she realizes that she made a mistake, and changes the menu name back to “Menu 1″.
    3:30 – She see’s the “create new menu” link, and is on her way

    Step 7: Add links

    No issues.

    Step 8: Delete menu

    No issues.

    Observations/Thoughts

    • This user was sharp. With that said, having the theme locations meta box back in the top left corner, revealed two undesirable behaviors. 1) She assumed that the theme location metabox was where she managed her menus. 2) She thought she could create a new menu by editing the existing menus name field, and saving it. We’ve seen both of these behaviors before the last time we tested having the theme locations meta box in the top left corner.
    • For the next test, I’m going to try moving the theme locations box below the menu item options.

    User #18

    Here’s the video.

    Step 1: Log in

    No issues.

    Step 2: Go to menus

    No issues.

    Step 3: Reorganize pages

    No issues.

    Step 4: Preview changes

    No issues.

    Step 5: Remove menu item

    No issues.

    Step 6: Add another menu

    No issues.

    Step 7: Add links

    No issues.

    Step 8: Delete menu

    No issues.

    Observations/Thoughts

    • Overall, the second user succeeded with all of the tasks. She had to look for the “add new” link and the “delete menu” link, but she found them without too much trouble.

    Thoughts?

     

  • Matt Mullenweg 12:15 am on March 9, 2013 Permalink
    Tags:   

    As a continuation of the work begun in core for 3.6, I’d like to present you with the first iteration of the MP6 plugin. (Contents may have shifted or settled in shipping.) As it says on the tin, this is not intended for the general public, just for savvy WordPress enthusiasts eager to preview or contribute to a re-imagination of our collective home, wp-admin.

    From the base of what was in trunk 3.6 last week, here’s what’s new:

    • A visual treatment for the toolbar and menubar that visually unifies the two and reduces clutter.
    • Flatter visual styling, with square corners, for tables and grouping elements like .postbox.
    • Increased saturation of the traditional WP blue (old vs new comparison: http://cl.ly/image/1X2G3X1Y0y2g ).
    • A splash of color to denote the current menu item. (gasp)
    • Removed the burnt orange hover state in favor of a lighter blue.
    • Single-color icons are now served via an icon font, making them load instantly and look crisp at any zoom factor. (The speed is noticeable on slower connections, like Gogo.) We can also use these for mobile apps.
    • Consistent typography for all operating systems by including the Open Sans web font. (Cognizant of complications embedding this could entail.)
    • Added padding between links in the menu for easier touch navigation, important as the majority of internet interaction will happen on touch devices within a few years.
    • Lightened the page background using white backgrounds for grouping elements and a gray background for the body.
    • Removed the large header icons for a cleaner look at the top of the page. Reduce, reuse, recycle.

    “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” — Antoine de Saint-Exupery

    This week included contributions from MT, Joen, Ben, and Otto.

    It’s worth noting that we don’t anticipate to support an alternative admin style (blue) like the current admin does, but the simpler visual language and icon font makes it infinitely more flexible for people to customize the color scheme of their admin.

    There will be office hours on Monday with MT to discuss next week’s iteration, and then version 0.3 will come out March 15th. Come by with ideas, ruminations, rants, soliloquies, haiku, hex codes, complaints, beard grooming tips, and bike sheds. We plan to continue doing weekly iterations, to try at least one new thing per week, until it’s ready for core. The only constant is change. :)

     

    • Justin Sainton 12:41 am on March 9, 2013 Permalink | Log in to Reply

      I think I’m in love.

    • Joey Kudish 12:51 am on March 9, 2013 Permalink | Log in to Reply

      Nice! I really like the direction this is headed in. You mention office hours on Monday but not what time it’s at :)

    • Jerry Bates (JerrySarcastic) 12:56 am on March 9, 2013 Permalink | Log in to Reply

      Looks great!

    • Mel Choyce 12:59 am on March 9, 2013 Permalink | Log in to Reply

      Wow, I mean, wow. It looks stunning. Definitely an incredible start. There’s a lot of things I love immediately love about this: the reversed arrows on the admin menu, the “almost flat” styles on the container elements, the updated typography… Looking forward to meeting on Monday!

    • Lachlan MacPherson 1:00 am on March 9, 2013 Permalink | Log in to Reply

      Wow! Although the darker toolbar and menu is initially jarring (only due to the difference) I think its perfect for putting focus on the content! Really like how it sections the content from the admin items.

      I’m also loving the Open Sans font, but would love to see experimenting with a bigger font size. 13px just seems way to small.

    • Matt Thomas 1:05 am on March 9, 2013 Permalink | Log in to Reply

      Hi guys — let’s meet at 9am Pacific/1pm Eastern/17:00 UTC.

      • Matt Thomas 2:02 am on March 9, 2013 Permalink | Log in to Reply

        How do I get time zones wrong? 9am Pacific, 1pm Eastern, 1800 UTC.

        • Matt Thomas 2:03 am on March 9, 2013 Permalink | Log in to Reply

          Ok. One more time. 10am Pacific, 1pm eastern, 1800 UTC. Walking away from the keyboard now.

          • Jose Castaneda 2:06 am on March 9, 2013 Permalink | Log in to Reply

            We forgive you. :)

          • Ipstenu (Mika Epstein) 4:56 am on March 10, 2013 Permalink | Log in to Reply

            You’re my TimeZone Screwup Twin ;)

          • Mark Jaquith 7:39 am on March 11, 2013 Permalink | Log in to Reply

            So, I don’t want to be that guy… but you messed it up the third time too, because you looked at PST and EST, but Monday, March 11th, is on PDT and EDT for most places in the United States.

            1800 UTC is 2pm EDT and 11am PDT.

          • @mercime 3:16 pm on March 11, 2013 Permalink | Log in to Reply

            1800 UTC ? = 11am Pacific and 2pm Eastern – daylight saving 1 hour ahead

          • Matt Thomas 4:16 pm on March 11, 2013 Permalink | Log in to Reply

            Foiled by time zones and DST. Next time I’m using swatch beats.

            Let’s chat in 45 minutes, otherwise known as 1700 UTC. Apologies if this is too-short notice for anyone — please leave your feedback here if you can’t make it. I’ll let someone else announce the time for the next one. :)

            • Mel Choyce 4:24 pm on March 11, 2013 Permalink

              How long will the meeting go on for? I had a meeting come up at 1, but it lets out at 1:30 and I have some feedback I want to chat over.

            • Matt Thomas 4:28 pm on March 11, 2013 Permalink

              Just depends on how many show up and how much ground there is to cover. If we’re not still going when your meeting is out I’ll be around afterward as well though.

    • Philip Arthur Moore 1:30 am on March 9, 2013 Permalink | Log in to Reply

      I’m sure I’ll have more thoughts about this, but for now, all I can muster up is a, “Holy Moly Holy Moly This is BEAUTIFUL!” I wasn’t very hot on flat icons at all because of the surrounding admin elements in /trunk/ but when it’s presented in this manner it makes me want it yesterday.

    • Syed Balkhi 1:33 am on March 9, 2013 Permalink | Log in to Reply

      I love this thing man. Simply beautiful.

    • Jose Castaneda 1:34 am on March 9, 2013 Permalink | Log in to Reply

      I’m liking what I’m seeing so far. Really digging the colors more.

    • Ricky Lee 1:38 am on March 9, 2013 Permalink | Log in to Reply

      Simply stunning! Feels fresh and aesthetically similar to Windows 8. Absolutely the right choice to iterate thru a plugin instead of forcing the flat icons into current design. I would of loved to have seen this in 3.6 but hopefully it will be the mission of 3.7.

      Interested to see how core will handle .wp-menu-image and plugins not using icon font.

    • @mercime 3:46 am on March 9, 2013 Permalink | Log in to Reply

      What a relief!!! You guys and gals were were playing with us :-)

      I couldn’t quite fathom why the UI team would brutalize wp-admin by replacing the clean and professional icons on the dashboard’s elegant gray background with heavy icons which gave me a headache everytime I visited the dashboard of my test site on 3.6 trunk to test a plugin/theme. Yikes.

      So the joke’s on us:-) Thank you for the cool new plugin. The UI team is awesome as always. And those icons fit perfectly with the dark background, See ma, no headaches :-)

      Cheers.

    • Manny Fleurmond 4:31 am on March 9, 2013 Permalink | Log in to Reply

      So much beauty in this new look. Love the subtle design choices: the graying out of disabled plugins, the contrast between the sidebar and the main content area, the white meta boxes on grey backgrounds. The blue highlighting really pops on the backgrounds. And thank you for squaring off everything. This is just plain clean and gorgeous. I hope this makes it into 3.6 because it looks ready for primetime to me

    • t.schwarz 4:35 am on March 9, 2013 Permalink | Log in to Reply

      Hmm… there was a plugin a couple of years ago that had a very similar look. Don’t remember the name, though. This one is not love at first sight for me, though. It reminds me of outlook.com, which I like, but I don’t think the uni-color treatment of sidebar and navigation bar is looking too good. I like what MS has done with the top bar as color-coded identifier for different apps, but even without that functional requirement, I like the different color in the nav bar. With the same color the WP-Logo induced offset of the title in the navbar looks odd to me. And the dark top left corner looks too dominant for my taste. Also – even facebook is re-introducing 2px rounded corners in the new feed design, which, I believe, adds a lot of levity to the design. I believe that would be true for this design as well.

    • buzztone 5:17 am on March 9, 2013 Permalink | Log in to Reply

      I like this – it’s a significant improvement. Brings the WordPress interface up to date and will I believe enhance the WordPress user experience.

    • Devin Walker 5:23 am on March 9, 2013 Permalink | Log in to Reply

      The darker left navigation was jarring at first but now I’m easing into it. It’s more ‘metro’ style with the flat colors. I enjoy Open Sans as a font, it’s one of my favorites so good choice on that for sure! Ditching the blue alternate color is a great decision, I couldn’t stand that color scheme. The font-icons are also a nice addition, although I have Gravity Forms installed and their icon looks goofy next to the new UI’s icons. If plugins are to blend in better they will have to also follow suit with the flat look. I agree with @t.schwarz that the all dark top-left corner is a bit too dominant. Not first love, but an improvement I believe.

    • Ben May 7:54 am on March 9, 2013 Permalink | Log in to Reply

      Really love it – a great direction for the admin…. *sniff* WordPress keeps growing up so fast ;)

    • Antonio 8:39 am on March 9, 2013 Permalink | Log in to Reply

      Good, it would be a great idea to begin thinking in terms of responsive web design in the admin too as in the core themes. Furthermore, it would be great starting to take into account the now implemented CSS3 modules to manage layouts in the correct way (i.e. Flexible Box or Grid Layout) using polyfills for browsers that don’t support them.

    • karmatosed 10:16 am on March 9, 2013 Permalink | Log in to Reply

      This is really cool, look forward to seeing how it distills during housekeeping hours as things are refined.

    • TobiasBg 11:14 am on March 9, 2013 Permalink | Log in to Reply

      WIth WP_DEBUG true, on trunk, I get this warning on every admin screen:
      Warning: Creating default object from empty value in …/wp-content/plugins/mp6/mp6.php on line 21

    • Terry Sutton 12:39 pm on March 9, 2013 Permalink | Log in to Reply

      Opens the door for all kinds of personalizing: http://cl.ly/image/3D132l2y0t1x Very Nice.

    • Lee Willis (leewillis77) 12:48 pm on March 9, 2013 Permalink | Log in to Reply

      Hi Matt, it’s an interesting look, and not one I’m a fan off, but I guess that’s a personal preference.

      That aside, there are a couple of bits of constructive feedback I’d like to offer on some of the styling – what’s the best place to do that – the support form for the plugin? core trac? plugin trac?

      Thanks

      • Helen Hou-Sandi 2:19 pm on March 9, 2013 Permalink | Log in to Reply

        There will be office hours on Monday with MT to discuss next week’s iteration, and then version 0.3 will come out March 15th. Come by with ideas, ruminations, rants, soliloquies, haiku, hex codes, complaints, beard grooming tips, and bike sheds.

        • Lee Willis (leewillis77) 8:12 am on March 10, 2013 Permalink | Log in to Reply

          Hi Helen,

          Thanks for the reply. I’d seen that, but unfortunately I can’t do that time, hence I was looking for somewhere I could log something?

          • Matt Mullenweg 11:51 pm on March 10, 2013 Permalink | Log in to Reply

            You can leave it here!

            • Lee Willis (leewillis77) 7:43 pm on March 12, 2013 Permalink

              Thanks Matt, Helen,

              My main two comments are as follows:
              1. The headers on WP list tables don’t seem sufficiently different from the data rows. This is especially evident on list tables that don’t have sortable headings (Since the headings aren’t links and therefore aren’t a noticeably different colour). I’d like to see some visual separation between thhe header rows and data rows, whether it’s background colour, increase font weight, borders etc. Example: http://imgur.com/FupxufL

              2. The inactive text colour seems far too close to white to be comfortable – can we find a better way of indicating inactive than lowering the contrast? I’d be surprised if the contrast in this shot passes any accessibility tests for contrast. Example: http://imgur.com/QKqvTfB

              Cheers

    • Ryan Hellyer 2:00 pm on March 9, 2013 Permalink | Log in to Reply

      I wrote a review up including some comparisons to the MP6 plugin today. Just thought I’d mention it in case it’s of interest here:
      http://wprealm.com/blog/admin-panel-what-does-the-future-hold/

    • unsalkorkmaz 5:08 pm on March 9, 2013 Permalink | Log in to Reply

      For some reason, plugin is broke tinymce -> insert/edit link’s “link to existing content” section.

    • Cátia Kitahara 12:47 am on March 10, 2013 Permalink | Log in to Reply

      I like the direction it’s moving on to – it’s nice to activate and deactivate the plugin to notice all the differences – I love the menu and its icons and colors, the square corners and the font. I’m not sure yet about the admin bar and the menu, I like the fact they became one unique element, but it seems it lacks a bit of balance, I tried making the footer this same shade of dark grey (#222) and it looked better to me (obviously you’d need to replace the right margin with some right padding). And I’m not sure about the box-shadows, sometimes they look good, sometimes they look like they don’t belong to this new look. Just some first impressions, but the overall feeling is very positive! Great job! Congrats! :)

    • scottsweb 12:45 pm on March 10, 2013 Permalink | Log in to Reply

      The plugin is a big improvement over the trunk 3.6 icon update I was testing a few weeks back. It is nice to see the whole wp-admin interface updated to reflect this new look and feel. Simplifying (by reduction) is a lovely ambition to design toward.

      Having said that I would like to understand the reasons for this change a little more. Right now it feels like this update is focused solely on bringing WordPress in line with current design trends (a flat / Windows 8 look) rather than to creating something uniquely WordPress.

      I think we should be aiming higher than that and that our time would be better spent looking ahead to the future of publishing and content management.

      It is interesting. But is it necessary?

    • Drew Strojny 2:00 pm on March 10, 2013 Permalink | Log in to Reply

      Nice work all! Really love the direction this is headed :)

    • Mike Schinkel 4:17 pm on March 10, 2013 Permalink | Log in to Reply

      I’m finding the plugin list to be confusing with information about different plugins blending into each other because it doesn’t have the alternating grey/white bars like for example the post list has.

    • Maor Chasen 5:05 pm on March 10, 2013 Permalink | Log in to Reply

      Great stuff! I like the direction in which things are moving.

    • Jonathan Dingman 8:20 pm on March 10, 2013 Permalink | Log in to Reply

      Looks great, I love the dark background.

      I’d love to see a sticky sidebar nav, where it floats with me as I scroll down the page.

    • taghaboy 9:00 pm on March 10, 2013 Permalink | Log in to Reply

      just ONE question, is the admin panel responsive? Thanks

    • basequatro 12:05 am on March 11, 2013 Permalink | Log in to Reply

      Some icons are overwrited by plugin and remains with two icons.

      Another error is with submenu, Doesn’t adjust to the text size

      Overall i like the new visual

    • Richard Archambault 1:46 pm on March 11, 2013 Permalink | Log in to Reply

      I’d just like to say, “Wow!!”. My only comment other than that might be that I find it maybe a bit too dark (though I really liked Fluency Admin back in the day, so go figure). Maybe some sort of very subtle visual seperator between menu items might improve it just a bit, by making it seem less like a long list of plain ol’ links? I like the direction very much, though!

    • DaveE 1:57 pm on March 11, 2013 Permalink | Log in to Reply

      I love the new direction. But, if I may, there are a few things I thought may be worth nit-picking:

      As one or two others have mentioned, I find the contrast between the nav column and the main body to be too great. It requires a mental refocus each time I glance between the two to switch from light text/dark background to dark text/light background. It seems like the nav bar could be lightened to a point where it could continue to use dark text on a light background but still provide separation from the main body.

      I also agree that there should be better separation between plugins on plugins.php (as others have mentioned). And finally, I think the matching color box-shadows on alert boxes (for example the yellow box shadow on a yellow alert box) is a little too strong. Maybe tone that down to a more neutral grey hue?

      I’m really digging the new icon font, Open Sans usage and the flat color scheme/styling. Well done folks, well done!

    • GhostToast 2:27 pm on March 11, 2013 Permalink | Log in to Reply

      I like the way this looks. I am curious how easy it will be to integrate Custom Post Type icons, as this is a nice touch we can add for helping clients associate different data types. I can’t help but feel it is very similar to ICS/JellyBean for Android, though that is not a bad thing.

    • karmatosed 6:38 pm on March 11, 2013 Permalink | Log in to Reply

      To go with the ‘new’ blue, I’d suggest the following for a status colour refresh:
      Green #00a213, Red #cb0800, Amber #cb7e00.

      For the message updated you could remove the border and opt for a #fdffad background colour.

    • Tevya 11:51 pm on March 12, 2013 Permalink | Log in to Reply

      Buttons need the flat look! Especially blue ones like Publish/Update. They still look rounded like the old interface. Give them square corners and remove the shading to make them flat like everything else, please!

    • Kelderic 12:54 am on March 13, 2013 Permalink | Log in to Reply

      I like the flatter look, but one thing that I wish could be kept is horizontal divider lines between the menu items. Additionally, on the menu pages (for example the Widgets page), the gray title boxes are so pale that they are hard to make out. Having Some differentiation isn’t a bad thing.

    • traversal 3:43 am on March 14, 2013 Permalink | Log in to Reply

      This is shaping up really well.

      There’s one thing I’m not mad on though. I feel the change to almost-white meta-boxes is problematic, and will mess up the interface for many plugins that create highly customised content inside metaboxes.

      I’ve been playing about this morning with an integration stylesheet for my plugin MasterPress, which contains a lot of custom field UIs, and the white meta-boxes just don’t seem like a great choice.

      Compare this, which shows how the UI looks with white metaboxes: http://cl.ly/image/0u3a1m3k2m24

      … and this, where I’ve made them darker gray again: http://cl.ly/image/1a0A0f0K3q43

      The gray version looks far better to my eye, and ensures that “content” really pops to the fore. In the white version, the metabox titles almost look like text inputs as well. Any other plugins that rely on metaboxes being a darker gray would probably have similar issues.

      I also ripped out the box-shadows for metaboxes in favour of a gray border, which I feel looks a bit cleaner too.

      But anyway, it’s a great new direction, and I think the writing is on the wall – WordPress will very likely look like this soon :)

    • hakaner 8:33 am on March 16, 2013 Permalink | Log in to Reply

      I’ve tried and pretty liked it. It looks exactly what I want. Thanks!

    • wesrice 4:44 am on March 18, 2013 Permalink | Log in to Reply

      A filter to define the primary color in the css would be nice. I know its easy to add your own css to the dashboard, but I think it’d be an interesting thought to be able to define a single color value and have all instances of the default color overridden.

      Perhaps the solution is as simple as putting all of the colors of the dashboard in a single css file, which would make it more manageable for devs to maintain color customizations.

  • lessbloat 2:09 pm on March 7, 2013 Permalink  

    Here’s the last round of menus usability tests with 23450.6.diff​ applied.

    User #15

    Here’s the video.

    Step 1: Log in

    No issues.

    Step 2: Go to menus

    No issues.

    Step 3: Reorganize pages

    No issues.

    Step 4: Preview changes

    No issues.

    Step 5: Remove menu item

    No issues.

    Step 6: Add another menu

    No issues.

    Step 7: Add links

    No issues.

    Step 8: Delete menu

    No issues.

    User #16

    Here’s the video.

    Step 1: Log in

    No issues.

    Step 2: Go to menus

    No issues.

    Step 3: Reorganize pages

    No issues.

    Step 4: Preview changes

    No issues.

    Step 5: Remove menu item

    4:35 – When she expanded the menu item, the remove link was below the fold, so she did not see it. This caused confusion.

    Step 6: Add another menu

    No issues.

    Step 7: Add links

    No issues.

    Step 8: Delete menu

    No issues.

    Observations/Thoughts

    Overall, everything worked great. We added a task to delete a menu in there, to double check that users were able to spot it at the bottom, and they both seemed to find the link easily enough.

    The second user found a bug. The extra description items (CSS, XFN, Description) were unchecked in screen options, and should not have been showing in the menu item edit screen. Since they were there, the “remove” link was pushed below the fold, which caused her confusion. We’ll need to fix this.

     

    • Chip Bennett 2:18 pm on March 7, 2013 Permalink | Log in to Reply

      Can I throw in a vote for returning the “Theme Locations” meta box? IMHO it is far more intuitive to associate Theme Locations with menus, than to associate menus with Theme Locations. It is also far more useful to see, at a glance, what Theme Locations have assigned menus, than to see what Theme Locations a given menu is assigned to.

      To test:

      Step X: Assign a custom menu to every Theme Location provided by the current Theme

      I think this step – critical to the setup of any given Theme – has been made more difficult with the current UI changes.

      • lessbloat 2:35 pm on March 7, 2013 Permalink | Log in to Reply

        Thanks for your feedback Chip. Honestly, neither solution is ideal. The decision came down to a choice between the lesser of two evils.

        The old way of doing this had several down falls:

        • The positioning of the theme locations meta box was confusing. It was aligned in the left column at the top, which A) pushed the menu item options down (which was not ideal), and B) seemed out of place when the rest of the actions in that column dealt with adding menu items to your menu. With the new layout, all of the items in the left column now perform the same function (adding new menu items).
        • With the old way, adding a new menu was a three step process. 1) Add a new menu (enter the menu name, and click “create menu”), 2) Add menu items, and then 3) Select a theme location. The new approach reduces this to two steps.

        As such, I feel like the new approach simplifies things for the better.

        • Chip Bennett 2:55 pm on March 7, 2013 Permalink | Log in to Reply

          The positioning of the theme locations meta box was confusing. It was aligned in the left column at the top…

          Agreed. But why not put the Theme Locations metabox in the main column, right above the Menu-Edit metabox?

          The new approach reduces this to two steps.

          But the reduction-in-steps isn’t associated directly with the change. After creating a new menu, the user must still assign the menu to a metabox – only using checkboxes now instead of the dropdown.

          Also, this workflow appears to assume: a) a New Theme, with b) no previously created custom nav menus. Have you done UI testing for a user who already has created custom nav menus, then switches Themes?

          And to keep responses in one place:

          Also, you can see at a glance which theme locations are assigned to which menus in the menu select drop down

          “At a glance” requires clicking the select, in order to see all menus/Theme locations. That’s an extra step from the old UI, when all Theme Locations were visible without user interaction. Also, I’ve not tested: how does the current UI scale when the same menu is applied to multiple Theme Locations?

          • Chip Bennett 3:12 pm on March 7, 2013 Permalink | Log in to Reply

            Oh, and I forgot to mention:

            Also, you can see at a glance which theme locations are assigned to which menus in the menu select drop down

            You also cannot tell from that select whether all Theme Locations have menus assigned.

            The only way to know if there are any Theme Locations without menus assigned is to make a mental note of the assigned locations in the dropdown at the top of the page, then compare that mental list with the list of checkboxes at the bottom of the Edit-Menu metabox.

            IMHO, that is a pretty significant UI loss inherent in this change.

        • Chip Bennett 3:51 pm on March 7, 2013 Permalink | Log in to Reply

          I moved discussion to Trac, as it seems more appropriate there. Let me know if I’ve picked the wrong ticket.

      • lessbloat 2:39 pm on March 7, 2013 Permalink | Log in to Reply

        Also, you can see at a glance which theme locations are assigned to which menus in the menu select drop down:

  • lessbloat 6:52 pm on February 26, 2013 Permalink  

    Icon feedback 

    I’d like to kick off another round of icon feedback, this time with several constraints. If you have any concerns with the flat icons currently in trunk, now is your time to speak up.

    A few rules for this exercise:

    DO’s:

    • Please be constructive. Each icon has a letter assigned to it, if you’ve got feedback for 2 out of the 13 icons, tell us what you don’t like about each one individually (or even better, mock something up for each one).
    • Please leave admin UI out of all mockups for this exercise (just icons on a white background for now).

    DON’Ts:

    • Don’t make broad declarations (i.e. “I don’t like them”, or “I like the old icons better”).
    • Don’t comment on the color/contrast (we’ll save that for another discussion).

    Thoughts:

    Source File

     

    • George Stephanis 7:07 pm on February 26, 2013 Permalink | Log in to Reply

      I’m going to assume these letters aren’t the letters that the characters will necessarily be mapped to in an icon font (if that happens).

      L (key): I don’t like how narrow the point is where the disc connects to the key blade.

      Apart from that, I like it all.

      • lessbloat 7:09 pm on February 26, 2013 Permalink | Log in to Reply

        Right, just random lettering, they have nothing to do with the mappings. ;-)

    • Norcross 7:10 pm on February 26, 2013 Permalink | Log in to Reply

      from a strictly visual perspective, I’d prefer to see the them be aligned either by the top or the bottom. A and E (the paintbrush and camera, respectively) seems to be shorter than the rest.

      • Tom Auger 8:35 pm on February 26, 2013 Permalink | Log in to Reply

        That’s a good observation. In fact, it would be ideal if they were all the exact same pixel height. To that point, I, E and possibly A don’t appear to match.

    • Isaac Keyet 7:21 pm on February 26, 2013 Permalink | Log in to Reply

      Some thoughts…

      B: Compared to E, G, H, and I (which are all rounded) the comment bubble seems way too rounded and like it’s the odd one out. The big > also makes it seem less vertically centered (optically).
      H: compared to G and L, H seems “too long” and the optical center is off to the upper right which throws off the balance.
      E: most likely modeled after a classic camera (e.g. a Leica) and not a modern DSLR it makes sense in theory, but compared to other icons it’s less than round corners seems off. Especially when compared to C and F – these icons have very straight lines for a reason.
      I: my biggest pet-peeve is with this icon. It’s overly complex compared to most other icons in it’s detail, which becomes especially noticable in the small size. An icon with only two levers (one up, one down) would convey the exact same thing and reduce the overall business of the admin and settings sidebar section. The previous icon also only had two levers if I remember correctly.
      M: the cogs in the gear seem too tall, mainly because there’s no second gear to relate this cog to. Presumably the second gear would have smaller teeth to grip into this one, but as it is now all you have to go on is this icon on it’s own so you have to assume that subsequent gears have the same teeth size, which makes this gear impossible to work. (I know I’m being super picky now, but if you’re going to do it, better do it right! ;) ). A gear with bigger gaps in between the teeth/shorter teeth would make more sense.
      A, C, D, F, G (and to some extent I): these icons have gaps in between different parts of the icon, but they’re not all the same size (at least it doesn’t look that way) for consistency the gaps should all have the same optical depth.

      I’d be happy to mock up any of this. Or all of it. Source files? :)

    • sara cannon 7:21 pm on February 26, 2013 Permalink | Log in to Reply

      is (M) the gear for settings or (I) the board? Personally I like the gear.

    • Ipstenu (Mika Epstein) 7:24 pm on February 26, 2013 Permalink | Log in to Reply

      L – which is for ‘Sites’ in Network Admin has always felt a little indistinct. What does a ‘key’ have to do with your sites?

      G – I greatly prefer this to the straight horizontal icon before. +1 Having it at an angle feels better.

      E – I prefer E2 since it indicates that there’s more than just ONE type of media to be uploaded.

      B – I’m torn here. I prefer the B-original aesthetically, but B2 fits the schema more.

      M – I agree with Issac – The cog teeth are too tall. (Where is this being used? The icon for settings is the slider). Depending on how it resizes, maybe a dial with an arrow instead?

      I – Two sliders in the icon (like we use today) would be better I feel.

    • Chip Bennett 7:24 pm on February 26, 2013 Permalink | Log in to Reply

      A, G, and H (A and G in particular) are very, very similar; especially when viewed at a glance, and without accompanying text labels – and especially considering their on-screen/in-menu proximity.

      Is a paintbrush the best/most accurate icon for “Appearance”? Perhaps a painter’s palette, or a paint can/brush? Or maybe a monitor/screen with content, or a “layout” option (with boxes for header/content/footer/sidebar)?

      • Ipstenu (Mika Epstein) 7:27 pm on February 26, 2013 Permalink | Log in to Reply

        A painter palette would be more distinctive. (I think G and H look more ‘alike’ when on their angle… Maybe flip G so the prongs point straight down?

      • Isaac Keyet 7:33 pm on February 26, 2013 Permalink | Log in to Reply

        Nice thoughts…

        On this topic, I just realized that while A + G + H + J + L are all similarly tall, skinny and on a 45° angle, they seem to be on their particular angle randomly (A + G + H pointing up+right, J + L pointing down+left).

        If A + G + H is about changing up your site (not producing content), I think the Key (L) should also be pointing up+right.

    • Helen Hou-Sandi 7:30 pm on February 26, 2013 Permalink | Log in to Reply

      A and H having such differently shaped handles is what strikes me first, especially alongside G with its squarely terminated cable. I think the wrench (H) is perfect, so if sticking with a paintbrush, then I suppose I’d like to see what it’d look like with a handle similar to the wrench.

      However, I’m still torn about whether or not a paintbrush is really the right icon. I like it in many ways, but some of the items under the Appearance menu (widgets and menus in particular) don’t seem to fit with what a paintbrush conveys.

    • Tom Auger 8:38 pm on February 26, 2013 Permalink | Log in to Reply

      I like the simplicity of it all. I daresay F might be just a little too simple – could you add the typical “page curl” without increasing the visual clutter too much?

    • acsearles 8:52 pm on February 26, 2013 Permalink | Log in to Reply

      L (the Key) kinda bothers me. I think the joining of the teeth and the circle seems a little to fragile to me. At first I thought the key would be better horizontally but I think that the diagonal works with best with A D F G H J. Here’s an example that I like from the noun project. http://thenounproject.com/noun/key/#icon-No655

      B2 (comment bubble) is much better. Side note, I’ve never liked how a comment bubble tends to look like a thumbs down at small sizes but I’m not really sure how to get over that yet. Maybe something like this? http://cl.ly/image/3k463V0t1s0v This would take advantage of the top-right to bottom-left diagonal we have going and make it look a little less like a thumbs down. I also slimed down the height on the bubble. It was starting to have a little to much mass to it. It sticks out when it’s so big.

      E2 (media) I like the inclusion of the music note but the terminals on the end look weird to me as circles. Correct me if I’m wrong but most often a music note is more oval and sits kinda on a diagonal, which could be good for consistency. Here’s what I’m thinking. http://cl.ly/image/3z0x082d151V

      M (gear) I agree the notches are to tall. Just slightly down some would help. But I’m kinda with isaac on this one about two gears. I know one gear has become a common icon for settings pages and such but it’s really the gears working together that is the concept not just the gear itself. But these icons are pretty simple so a second gear might get too complicated. But if you do a second one, it should be on the same diagonal as everything else. This one from the Noun project I think does it well if we stick with a single gear. http://thenounproject.com/noun/gear/#icon-No6052 the difference is the inner-circle is wider and the notches are not rectangles they’re trapezoids. Plus the notches aren’t as tall.

      I (slider panel) is too complicated compared to everything else. Two would be better. Conceptually, with out text, I’m not sure what the difference between the M and I would be if I clicked on it. So maybe I needs to go back to the drawing board.

      A (paint brush) I like the eye idea from Isaac. But maybe we could go with something more like this. http://thenounproject.com/noun/eye/#icon-No2307 Isaac’s revered out eye is a little creepy. But I’ll a little hesitant to get away from the paint brush because it fits really nicely with everything else, where I don’t think an eye would. If we did an eye, I would put some thought into trying to make it conform to the diagonal that we’ve already go set. I don’t love it but I would start here. http://cl.ly/image/0a2O1i2C473f

      F (pages) Sorry Tom, I think the curl might be too much. if you ad the curl then you’ll need a line to help distinguish it. I don’t think it needs it. But for the pages I would bring down the page on top to overlap more of the page on bottom. That way it’s a little more stream lined but you keep everything else that’s good about it. I agree with some commenters above that it stands a little to tall. Here’s where I think you should move it to. http://cl.ly/image/2G0X092d1G1G

      Well, that’s all my thoughts. Sorry it’s a little long.

    • Matt Thomas 3:07 am on February 27, 2013 Permalink | Log in to Reply

      I think the individual forms are looking good, but they could benefit from tweaking the size relationships between them. If we extend square or rectangular icons all the way to the edges of their specified size, then non-square icons all look optically too small by comparison. The Chrome Web Store has some really simple but relevant guidelines on how to space differently-sized icons for optimal size consistency between them. https://developers.google.com/chrome/web-store/docs/images#iconsize

    • Ricky Lee 3:24 am on February 27, 2013 Permalink | Log in to Reply

      It is such a drastic departure from current textured icons. I understand that flat design is in right now but a slight inner shadow would work wonders.

      https://dl.dropbox.com/u/12607958/menu.png

    • Aaron D. Campbell 4:37 am on February 27, 2013 Permalink | Log in to Reply

      I definitely like B2 & E2. The Key (L) looks a little funny. I think most keys have a shoulder up next to the round part. Adding that might help.

    • lessbloat 2:19 pm on February 27, 2013 Permalink | Log in to Reply

      Overall I think these are looking great. Ben has done an awesome job getting us to this point. All that’s left in my mind is a bunch of nit picky minor stuff to make them more cohesive.

      My thoughts:

      A – The top most rounded corner of the paintbrush seems off (could it be smoothed out)

      A – The width of the white line between the brush and the handle seems inconsistent with the rest of the white lines in the set (i.e. between the roof and the house in C)

      B2 – I prefer this one over B, but it still seems inconsistent when compared to the border radius on E & I.

      C – Lines here are all very straight compared to the other icons. Could we slip in some very slightly rounded corners?

      C.32 – I think it’s an optical illusion, but the gap between the roof and the house seems almost too thick.

      C.16 – The thickness of the roof is somewhat lacking, which causes it to appear lighter than the rest of the house

      D.32 – The thickness of the inner ring seems just right. The outer rings seem a tad thick.

      E2 – I like it. We should try to reduce the overall height to better match the other icons if possible. I like what acsearles said about oval terminals if we can work that in.

      F – Again, the straight edges stand out to me. Even slightly mouse nibbled corners would help bring this one inline with the others.

      G – I like it.

      H – Seems slightly too large

      H – You might be able to drop the hole at the bottom of the handle. It shows a level of detail that is not present it the rest of the icons, and I think it will make resizing the wrench a bit more manageable.

      I – If we can get away with two sliders, I think that would be best. As it stands it’s currently rather complex compared to the others.

      J – I like it.

      K – You might get away with flattening the bottom curvy line. It stands out to me since most of the other icons in the set have a flat bottom.

      L – I agree with Aaron Campbell Squaring off where the key meets the round part should help here.

      M – Rounding the corders of the tips of each cog might help

      M.32 – You could bring the inner circle here out a tad.

      In general:

      As Matt Thomas and others pointed out, we should take a close look at the size relationships, and see if there is anything we can do to make these more uniform.

      There seems to be a lack of consistency in line widths, as well as white spaces. Compare the roof in C, with the link widths in D, with the plug widths in G, and the pin needle width in J. They are all slightly different. Then compare the white spaces in-between the brush and the handle in A, with the roof and the house in C, with the space between links in D, with the white lines in F, G, and I. It’s super nit picky, and in several of those cases there might not be much that can be done about it. But it’s worth taking a second glance.

    • Empireoflight 3:48 pm on February 27, 2013 Permalink | Log in to Reply

      http://cl.ly/image/162s2W3Y2T0X
      a: I smoothed out the curve at the top of the brush a bit, and added a few “eye” options. A palette will get to complicated at the small size. The eye seems creepy to me.
      b. I bumped the speech arrow over a pixel; a bit more like @acsearles recommended.
      c. I lowered the rook a bit so the white line is softer.
      d. Unchanged; I tried making the outer rings a bit skinnier but it looked too thin compared to the rest of the icons
      f. unchanged
      g. I made the stem slightly rounded per @helen‘s suggestion. I don’t think we can put it in the same boat as paintbrush and wrench, as those terminate and the plug should suggest continuing outside the icon, but I think this is a decent compromise.
      h. nuked the hole. I like the hole.
      I. did a few variations. I like three sliders best.
      j. untouched
      k. straightened the bottom of the profile. I like the curve better, it suggests the old icons and makes it more human.
      l. Made the diaganol cogs a bit skinnier and the outer ring larger.
      m. Make the connection point to the main part of the key bigger. I tried flipping/rotating the key but it looked really weird. It has a precedent in the post icon so it’s not an anomolly.
      overall: I didn’t touch positioning or lining them up. They are in slightly different places based on their context in the menu, and if I line them up they look wack when seen in the menu. I didn’t touch scale; again, some may look too big or small but when I originally designed them I did it in context and they seem much better proportioned when seen that way.

    • t.schwarz 5:41 am on March 9, 2013 Permalink | Log in to Reply

      G/H. I think the relative sizes are a little off. The plug seems too “fat” compared to the wench.

    • Greg 10:28 am on March 18, 2013 Permalink | Log in to Reply

      Hey All

      This is my first contribution to the ‘make’ area so be gentle.

      As a starting point I generalised and said to myself, to create a flat design we remove the ‘edges’ from designs, thats the strokes in between menu items, strokes to delineate areas or functionality and in this case edges to sharply define shapes and icons. With this in mind I removed the sharp points which seemed to unity the feel to the icons.

      Below basic rationalizations to change current icon.

      A: I saw an artists brush as a better representative icon for appearance over a painter’s brush.

      E: This is really tricky as the icon with the camera and musical note has a lot of information in a small area so I felt really motivated to change it, the problem is to what ?? I took the view to represent what can be done with media assets rather than what types assets are supported. So to kept it really clean and used the ‘play’ symbol.

      K: Each icon has a similar level of detail with regard the silhouette, so I added more human attributes to what was an overly simplified silhouette.

      https://dl.dropbox.com/u/504792/icons.png

  • Matt Mullenweg 5:08 pm on February 25, 2013 Permalink
    Tags: hangout   

    It seems to be moving in the right direction, but just to make sure we’re all on the same page let’s do a G+ hangout for discussing the Great Flattening — how about one of these times:

    • Wednesday Feb 27 at 11a PST / 19h UTC.
    • Thursday Feb 28 at 10:30a PST / 18:30h UTC.
    • Saturday Mar 2 at 9a PST / 17h UTC.

    Leave your name and which times work for you, if any, and we’ll pick one.

     

← Older posts

Newer posts →

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel