We’ve been focusing primarily on solving some of the trickiest responsive questions this week. Some we’ve found solutions to, and some we’re still discussing. We’ve also got a wild idea for the front-end of the site that we’ve got some mockups of to discuss.

Here’s what’s new this week:

• A new position for the “hamburger” button that opens/closes the mobile menu. It’s now part of the adminbar, and stays put when scrolling the rest of the page. There’s a much more obvious active style, and we’ve greatly increased the reliability of the button (no more multiple taps to get it to open anymore!).
• Increased the size of wpadminbar dropdown menus for mobile sizes so that links are easier to tap. (We still need to work on making these easier to close without activating a link).
• Improvements to the media uploader for responsive. Still needs work, but is more functional now.
• Fixed buglets appearing because of Jetpack’s 2x retinafying code interfering with MP6.
• Better positioning of icons in the wpadminbar.
• Improved responsive layout on the Akismet configuration page.
• Added new icon glyphs to the Dashicons font.
• Reworked the way Open Sans is declared in the plugin.
• Fixes to checkboxes and radio buttons.

Once we decided that the adminbar was the best possible place to put the hamburger button for mobile, I started thinking about whether that same interaction might make sense on the desktop version of the dashboard. After all, we’ve already got a button that hides and shows the dashboard, it’s just always been at the bottom of the menu. What if we put it at the top, in the adminbar? The benefit would be that even desktop users would grow to understanding the meaning of the button, since its purpose, hiding or showing the menu, is the same whether you’re on desktop or mobile. If we took it that far, it could even go to the front end of your site; allowing access to any part of your blog’s dashboard within two clicks of your live site. This would be a bigger change than what we can do with just CSS in MP6, so it’s a topic we’re interested in your thoughts on, to see if it’s a good candidate for a potential core patch suggestion.

This week’s edition of MP6 includes contributions from Joen Asmussen, Mel Choyce, Ben Dunkle, Till Krüss, Andy Peatling, and myself. Many thanks, as always, to those of you who have shared your feedback and ideas with us so far. Keep them coming!

We’ll be in #wordpress-ui on Freenode May 20, 2013 at 18:00 UTC to discuss this week’s work; please meet us there if you’d like to chat about what’s new.

If you are working on anything relating to the main WordPress project and sister projects (BuddyPress, bbPress, GlotPress) and you need to put together mockups let me know and I can add you to the account. Email: siobhan at wordpress dot org.

Update: this is for people working on the core WordPress project and sister projects. It is not for people creating third-party plugins and themes.

• More additions to the Dashicons icon font, including buttons in the visual editor (TinyMCE). Some plugins, including Jetpack, may still insert some PNG buttons that still need to be replaced.
• CSS fixes for better layout positioning and cross-browser consistency.
• More consistent results for custom checkbox and radio inputs.
• Removing the PNG “stalk” on comment counts in lists.
• Set textareas to overflow auto to prevent permanent scrollbars in IE.
• Other small bugfixes.

This week’s iteration includes contributions from Joen Asmussen, Mel Choyce, Ben Dunkle, and myself.

Because this was a short week for us, don’t fret if an issue you reported hasn’t yet been fixed. Rest assured it’s on our radar.

Thanks again to everyone who’s contributed your feedback so far — keep commenting below to share your ideas, suggestions, or just bug reports, we appreciate them all.

• Restyled toolbar submenus with a dark background that matches menubar submenus.
• Made all the various delete/trash links the same color red, and removed inconsistent backgrounds/borders.
• Improved the alignment of notices within thickbox containers.
• Added right padding to top level adminmenu links to leave room for the current arrow indicator.
• Improved the appearance of the file upload input.
• Improved the appearance of the comment moderation confirmation screen.
• Removed the blue hover state from disabled page navigation links.
• Removed the wayward borders within the .widefat table.
• Fixed a z-index issue causing toggle arrows to overlap expanded widgets on the widget management page.
• Submenu and current item arrows in the .folded and .auto-fold states are now the same size.
• Corrected the alignment of the New link in toolbar.
• The annoying bug where the W menu opens by default on every page load has been fixed.
• General coding standards improvements throughout.
• Updated the Dashicons icon font.
• Mobile: Improved theme updates table styling.
• Mobile: Fixed toolbar quicklinks line height.
• Mobile: Improved plugins list styling.
• Mobile: Menu management page improvements.
• Mobile: Allow the HTML editor buttons to wrap to two lines on small screens.
• Mobile: Improved styling of the link manager on small screens.
• Mobile: Adjusted height of select elements to match button height.
• Mobile: Bigger touch targets in the file editor’s file list; larger textarea for the editor.
• Mobile: Improved styling for post format options on small screens.
• Mobile: Fixed TinyMCE split buttons and list boxes.
• RTL: Added RTL tests to /branches/.
• RTL: Fixed meta/post box widget positioning.
• RTL: Fixed Plugin/theme editor submit button position.
• RTL: Fixed dashboard comment widget avatar position.

Whew! This week’s iteration includes contributions from Joen Asmussen, Mel Choyce, Ben Dunkle, Michael Erlewine (mitcho), Till Krüss, and myself.

We’ll be in #wordpress-ui to discuss your feedback on Monday, May 6 at 18:00 UTC. Thanks again as always to everyone who’s contributed your feedback so far. As always, please keep it coming — we’re interested in any suggestions, bug reports, ideas, or patches you may have. If you’ve reported an issue that we haven’t addressed yet, it won’t hurt to mention it again (with a screenshot if possible) at this point.

• We’ve styled reset links as text links instead of buttons so they’re reduced in visual weight.
• Long links in the menubar now wrap to two lines instead of being truncated. (ref)
• Fixed unreadable inactive widget titles. (ref)
• Fixed checkboxes collapsing to 0 width in the media manager. (ref)
• Fixed radio buttons and bottom margin in edit image popup
• Mobile: The menubar now opens on the left for consistency with the standard desktop layout.
• Mobile: Labels and inputs on settings pages are now full-width, with no floats, for a cleaner mobile layout.
• Mobile: Reduced the size of avatars in the Recent Comments list so there’s more room for text.
• Mobile: Larger radio buttons that are easier to select by touch.
• Mobile: Set text inputs to 16px to prevent iOS auto-zooming when entering text.
• Mobile: Better styling of Undo actions in the Recent Comments list.
• Mobile: Icons in the toolbar are now better aligned.
• RTL: Fixed positioning of menubar.
• RTL: Fixed screen meta positioning.
• RTL: Fixed main content well and screen options positioning.
• RTL: Made improvements to menubar text and icons.

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

We’ll be in #wordpress-ui to discuss your feedback on Monday, April 29th, at 18:00 UTC. Thanks again as always to everyone who’s contributed by sharing your feedback, patches, and suggestions — please keep them coming! If you’ve reported an issue that hasn’t been fixed yet, don’t fret — we’re compiling items as we get them and keeping track of what’s still outstanding.

This week, we worked on getting MP6 into the hands of a few million new potential testers. We’ve already gotten some interesting feedback from WordPress.com users, and hopefully our experience getting WordPress.com’s various moving bits working alongside MP6 will help pave the way for plugin authors when the new design has started making its way into core.

In version 0.8, we have:

• Prepared MP6 for a new opt-in test on WordPress.com.
• Updated the Dashicons font with more consistent icon alignment.
• Removed cursor: default from current items in the menu bar. (ref)
• Updated color of widget titles so they’re readable on the new blue background. (ref)
• Improved typography on Post Revisions page.
• Fixed the alignment and sizing of checkboxes. (ref)
• Removed CSS for old PNG icons.
• Fixed display issues with the bulk editor.
• Made improvements to Press This.
• Improved the legibility of the Browse Happy outdated browser warnings.

This week’s iteration includes contributions from Joen Asmussen, Ben Dunkle, Till Krüss, and myself.

As usual, we’ll be in #wordpress-ui on Monday April 22 at 1800 UTC to discuss your feedback on this week’s edition. Thanks as always to those of you who have helped with feedback, patches, and suggestions so far.

Here’s what’s new in 0.7:

• The Post Revisions page is now supported by MP6.
• Updated styling for Menu Management and Widgets pages
• Customized radio buttons that match MP6 checkboxes.
• Default notifications now use green instead of red for their border color.
• Adjustments to sticky menu positioning.
• Prevent Jetpack retina styles from overriding MP6.
• Enqueue Open Sans instead of loading via a CSS @import.
• Include missing wpmini-blue images.
• Reverted page tabs to look like tabs; we’ll explore more options here.
• Visual bugfixes.
• New version of Dashicons with additional glyphs.

In addition, Mel put together a simple example page for Dashicons that lists all available icons and the corresponding CSS/HTML/glyph for each. We’ll continue to update this page with more information on using Dashicons. http://melchoyce.github.io/dashicons/

This week’s edition includes contributions from Joen Asmussen, Mel Choyce, Ben Dunkle, Till Krüss, and myself.

Like (almost) always, we’ll be in #wordpress-ui at Monday April 15 at 1800 UTC to discuss your feedback on this week’s edition. Thanks as always to those of you who have helped with feedback, patches, and suggestions so far.

The one that is closest to what I was thinking, and the best balance between showing the new UI (to people who are already using post formats or who have a theme with special support), and getting it out of the way once you’ve chosen, is the “In Page decision with post editor greyed out” one.

I’m curious to know what the UI team thinks. I’d like action taken on this ASAP, so that we can get the UI settled for beta 2.

UI

• Post formats (in general) still need some love – http://make.wordpress.org/ui/2013/04/09/post-formats-usability-test-round-4/ & http://core.trac.wordpress.org/ticket/19570
• UI improvements for revisions screen – http://core.trac.wordpress.org/ticket/23899 & http://core.trac.wordpress.org/ticket/23935
• Review logged out modal styles – http://core.trac.wordpress.org/ticket/23295
• Review message location patch – http://core.trac.wordpress.org/ticket/17028
• Customize link in Appearance menu – http://core.trac.wordpress.org/ticket/21413
• Post formats on smaller devices – http://core.trac.wordpress.org/ticket/23993

HTML5

• Number inputs – http://core.trac.wordpress.org/ticket/22965

CSS

• Increase contrast for blue admin theme: http://core.trac.wordpress.org/ticket/16103
• Post format color contrast – http://core.trac.wordpress.org/ticket/23810
• Secondary button audit – http://core.trac.wordpress.org/ticket/23738
• Test modal RTL horizontal scroll bug patch – http://core.trac.wordpress.org/ticket/22935
• Review RTL revisions patch – http://core.trac.wordpress.org/ticket/23897

JS

• media modal accessibility patch needs review – http://core.trac.wordpress.org/ticket/23560
• Fix tabbing for post formats – http://core.trac.wordpress.org/ticket/23838 & http://core.trac.wordpress.org/ticket/23891
• Test spinners patch – http://core.trac.wordpress.org/ticket/22839
• Slide up/down for accordion code – http://core.trac.wordpress.org/ticket/23890
• Review post save UI patch – http://core.trac.wordpress.org/ticket/23362

If you’ve always wanted to help out with core, but you’ve never taken the dive, now is your chance.

Tasks:

1. Login
2. Look at the Dashboard and get to add post from toolbar
3. Add a (standard) blog post with title and text
4. Preview your blog
5. Add an image blog post, with image from a URL
6. Add a video post, with YouTube video URL provided
7. Add a link blog post
8. Add a quote blog post
9. Add a gallery post
10. Preview your blog again to see all the posts

Test 7: http://wpusertesting.com/videos/DC7-7.mp4

1. Fine
2. Fine
3. Fine
4. Fine
5. She uses “Add Media” to add her image – didn’t really see the post formats options
6. Since it worked once, she used “Add Media” again. Unfortunately the media modal still doesn’t embed videos from URL’s. This lead to a very confusing user experience.
7. She still doesn’t see the post formats bar. She is actively looking on the page for something, but doesn’t see the post format icons and opts to add the link via the editor. In the end, the only way she can figure out how to add a link is through the media modals “Add from URL” option.
8. She uses the editor to add the quote. She’s a little unsure how it works… But she figured it out via the editor.
9. She adds the 3 images via “Add Media”, but didn’t actually add a gallery (though she thought she had). She just selected multiple images and inserted them.
10. Fine

Observations:

• She didn’t use the post formats selector once. She didn’t even appear to see it.
• Apart from the video post, she was able to perform all of the tasks successfully with just the media modal and the editor.
• We really need to make sure that the “Insert from URL” feature inside the media modal embeds video URLS. We’ve seen users attempt to add videos this way in every single round of testing, and they are all very confused when a link is published, instead of the embedded video.
• The user uses selects multiple images and inserts them thinking she’s added a gallery. I wonder how many users do this very same thing…

Test 8: http://wpusertesting.com/videos/DC7-8.mp4

1. Fine
2. Fine
3. Fine
4. Fine
5. She uses “Add Media” to add the image. Doesn’t see the post formats bar.
6. She also attempts to add the video from the “Insert from URL” link inside of the media modal. It only adds a link. 6:20, she discovers the post formats bar. She selects the video format, and pastes the video URL into the title, and then the “Video embed code or URL” box. “Maybe I better not mess with it”, she says, unsure of if she should save her changes.
7. She uses the link format, but ends up using the editor because there was no way to edit the link text via the link post format option.
8. She goes back to using the editor to add the quote. Struggles a bit to know if it’s doing what she wants. After moving on to the next task, she discovers the quote post format, and tries it out. After she publishes it, and click the “View post” link, she gets a 404 error, and the quote is never really published.
9. She uses the gallery post format option. Unfortunately that doesn’t take her to the gallery section within the media modal. She ends up just multi-selecting and inserting multiple images (again, thinking she added a gallery).
10. 15:20 She takes a closer look at the post formats bar.

Observations:

• She didn’t see the post formats bar until half way through her test. After she noticed it, she thought it was handy, and mentioned that for the quote format, she preferred to use it.
• She also attempts to embed a video via the “Insert from URL” option in the media modal, which only adds a link. I’m guessing this happens a lot.
• There is no “link text” field in the link post format, so even though initially she selected the link post format, she opted to add the link via the editor.
• She got a 404 error when she tried to publish a quote through the quote post format.
• When on the gallery post format option, can we link directly to the “gallery” section from the “Add media” button?

Thoughts?