Make WordPress UI

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Matt Thomas 8:59 pm on May 17, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Hey, UI gang. Here to help you wind down the week is the latest update to MP6, version 1.2.

    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.

     

    • Hassan 9:32 pm on May 17, 2013 Permalink | Log in to Reply

      The idea of bringing the admin menu on the frontend (along with the admin bar) is just brilliant, I think.
      I don’t know why this never occurred to me before :)

      We need to make it a reality… after heavily testing it, indeed.

    • Hassan 9:47 pm on May 17, 2013 Permalink | Log in to Reply

      By the way, the update notification bubble is sometimes orange and sometimes blue. Is this intentional or a bug? I prefer the orange; the blue looks a bit wonky when the it’s on a highlighted menu item which is also blue.

    • mindctrl 12:34 am on May 18, 2013 Permalink | Log in to Reply

      Looking good. Bringing the admin to the front end is nice. A couple questions though.

      1. How much weight is that going to bring to the front end?

      2. Will we be able to totally disable that feature via filter/option/something where the weight doesn’t come with it if necessary?

    • Just a guy 12:58 am on May 18, 2013 Permalink | Log in to Reply

      I love it!

  • Siobhan 5:26 pm on May 17, 2013 Permalink | Log in to leave a Comment  

    Hello UIers! The kind folks at Balsamiq have provided us with a free license for MyBalsamiq for the WordPress project. If you don’t know what Balsamiq is, it’s a tool for creating mockups (and it’s pretty cool)

    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.

     

    • Shane Pearlman 5:35 pm on May 17, 2013 Permalink | Log in to Reply

      if you need to do anything with the admin we have some balsamiq templates of the admin: http://tri.be/?s=balsamiq. some are way out of date, but are a good starting point. I probably have them all up to date in some internal projects if you need anything specific.

    • Siobhan 5:42 pm on May 17, 2013 Permalink | Log in to Reply

      Shane’s templates are awesome. I’ve used them many times :)

      That also reminds me: there’s a user-contributed collection of UI components and design for Balsamiq. If anyone wants to contribute any I think that would make them very happy.

    • Jose Castaneda 6:03 pm on May 17, 2013 Permalink | Log in to Reply

      Not going to lie: That is pretty awesomesauce!

    • Hugh 9:19 pm on May 17, 2013 Permalink | Log in to Reply

      I use Balsaiq for some other work I do. What is MyBalsamiq?

  • Matt Thomas 1:09 am on May 11, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Howdy gang. On this fine Friday evening we bring you version 1.1 of MP6. This was a short week for several of us, so this week’s edition consists of a few small updates:

    • 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.

     

    • Nick Halsey 2:21 am on May 11, 2013 Permalink | Log in to Reply

      Looking better and better!

      I’m guessing no one’s looked at it in IE8, though. Surprise, *no* icons! I actually kind of like the simplicity it brings, but it renders several things useless, like tinyMCE :) I just noticed it today in 1.0 and 1.1 doesn’t fix it.

      • Matt Thomas 2:56 pm on May 11, 2013 Permalink | Log in to Reply

        Thanks, Nick. We’ll have to build workarounds for IE8 and other obsolete browsers that are still officially supported. That will likely be one of the last things we do though, as changes we make elsewhere can end up breaking special cases created for IE<9.

    • gibuh 2:55 pm on May 11, 2013 Permalink | Log in to Reply

      Error establishing a database connection, is the message after trying to host. can you help.
      i used
      http://www.ostraining.com/blog/wordpress/move-your-wordpress-site/

      • Matt Thomas 2:57 pm on May 11, 2013 Permalink | Log in to Reply

        Sorry, I’m afraid we can’t help there — this isn’t related to the MP6 plugin for WordPress. If you installed MP6 and are now seeing errors, delete the mp6 folder from your /wp-content/plugins/ directory.

    • Sofia Rose 3:03 pm on May 11, 2013 Permalink | Log in to Reply

      Im liking the new look! Any idea when it will make it into core?

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

        That will be up to the core team, but we aiming to have it ready for them in time for 3.7. Many factors could change that though.

    • Lea Cohen 6:07 am on May 12, 2013 Permalink | Log in to Reply

      Hi

      Thanks for the fixes of RTL!

      There is one problem that I still see: In the New/Edit Post screen, in the tags meta-box, the x is located on top of the tag name.

      The css should be changed like this:

      .tagchecklist span a {
      margin: 0 -17px 0 0;
      }

    • kai-ser 6:05 pm on May 12, 2013 Permalink | Log in to Reply

      I’m fine with replacing TinyMCE Icons with dashicons where possible, but
      background: none !important; on a .mceIcon renders TinyMCE plugins resp. WP-plugins like TinyMCE Advanced useless, they rely on the ‘core’ icon sprite file. :/

    • Ipstenu (Mika Epstein) 11:02 pm on May 12, 2013 Permalink | Log in to Reply

      Check box marks for images aren’t showing.

      http://cl.ly/image/0Y120N0f3l2d

      So there, as you can see in the thumbnail above, I clicked float right. No checky boxy mark.

    • paaljoachim 7:37 am on May 13, 2013 Permalink | Log in to Reply

      What is the process you are using to make the adjustments to the layout and design of the UI?
      The reason why I am asking is that I am playing with the thought of redoing certain elements (menus and submenus) of how the UI is put together in WP. To bring in another view of how things can be done. This means finding a simple way of actually changing the UI.

      • Matt Thomas 6:01 pm on May 13, 2013 Permalink | Log in to Reply

        Our approach is pretty simple; it’s mostly just CSS restyling what’s already there. No reason why you couldn’t make your own plugin that makes bigger changes to the markup and such, but that’s not something I’ve got experience with.

        • paaljoachim 10:29 pm on May 15, 2013 Permalink | Log in to Reply

          I do not have experience with it either. I am thinking of playing with the WP UI making test modifications to show possible interesting adjustments that can be done with the side menu and panels.
          As there are not just color modifications but other adjustments as well for instance the left line showing active plugins to make it even more clear which are active and not (which is a simple and good idea). Are you guys also planning on adding additional Admin color schemes under the user profile similar as to what exists today? Giving additional color options for the user.

          • Matt Thomas 7:50 pm on May 17, 2013 Permalink | Log in to Reply

            No plans for additional color schemes beyond the one we’re building now (color schemes are a surprising amount of work) but when we’re done, we imagine customizing the visuals of the admin by writing a plugin could make it super-simple to customize the admin, as easy as changing color options in a well-built theme.

    • Tom J Nowell 11:35 am on May 13, 2013 Permalink | Log in to Reply

      I had thought the menubar had been changed to open on the left in mobile, but there are a number of issues that remain and have persisted:

      • The mobile menu needs to be on the left, and more importantly, needs to be a part of the admin bar. As it stands, the button to access it is hidden underneath other elements on various pages, most notable the ‘About WordPress’ page where a WordPress logo sits over the top, making it very hard to navigate away
      • The WordPress logo in mobile is misaligned and is cut off at the bottom
      • Various other icons are misaligned in the admin toolbar
      • Non Core menu icons are misaligned with their Core counterparts, some completely broken

      Usability wise, it’s got significant problems:

      • On an iPhone 4S, I had trouble making the menu slide out, it would slide out half a centimeter then hide itself, i had to press several times.
      • Trying to add an image, I selected media, and the sub menu slid out, but before I could tap on ‘add new’ the screen went blank and I was taken to the main media library page
      • There is a particularly troublesome problem in that the admin toolbar has no concept of overflow. Everything is expected to fit magically into the toolbar. It doesn’t, and when it doesn’t, it overflows on to the page, making links at the top hard to read or innaccessible. Various toolbar links flow into eachother overlapping, some over the top of the page outside the toolbar, and the user avatar covers up the menu link making it hard to click

      In attempting to upload the above photo via my phone, I noticed a bug on the add new page, the image box is wider than the screen, making the edit/view link innaccessible:

      Overall the style of MP6 is working out nicely, but it feels untested

      Hardware/Software tested:

      • iPhone 4S iOS 6.1.3
      • OS X Mountain Lion, Chrome 26

      • Matt Thomas 6:06 pm on May 13, 2013 Permalink | Log in to Reply

        Thanks for the comprehensive list; I’ll add it to our to-do list. As we’ve stated before, MP6 is experimental and you should expect things to break while we continue to develop it. Rest assured that it is being tested in a multitude of browsers, both desktop and mobile, but since we’re releasing new versions weekly, every week there will be some things that are newly-broken and some things that have been reported but are not yet fixed.

        • Matt Thomas 7:52 pm on May 17, 2013 Permalink | Log in to Reply

          As an update; a couple of the issues you posted here have been taken care of in this week’s work. Others will remain outstanding for a while longer — our list is long but we’re working through it. :)

    • paaljoachim 1:39 pm on May 13, 2013 Permalink | Log in to Reply

      It looks nice. Now how do I change it back to standard WP look? Or change the black to another color?
      Or add in lines between each menu section to visibly split each section (as in the regular WP UI)?

    • Hassan 9:03 am on May 14, 2013 Permalink | Log in to Reply

      Plugin info modal needs some love.

      1. When a plugin’s name is (ridiculously) long, the header doesn’t auto adjust.

      2. When the content area is shorter than the FYI sidebar, backgrounds break.

    • MicioDue 3:13 pm on May 15, 2013 Permalink | Log in to Reply

      Hi,
      I use IE10 and I still receive the annoying unsecure browser warning in admin page, even in a fresh installation of WP 3.5.1. Won’t it be useful to add in future versions a proper tag just after tag to force IE browser mode, avoiding IE to fall back to compatibility mode?<br /> <a href="http://msdn.microsoft.com/en-us/library/jj676915(v=vs.85)" rel="nofollow">http://msdn.microsoft.com/en-us/library/jj676915(v=vs.85)</a>.aspx

      • MicioDue 3:15 pm on May 15, 2013 Permalink | Log in to Reply

        (text was scrambled in my previous post…)

        Hi,
        I use IE10 and I still receive the annoying unsecure browser warning in admin page, even in a fresh installation of WP 3.5.1. Won’t it be useful to add in future versions a proper meta http-equiv=”X-UA-Compatible” tag just after title tag to force IE browser mode, avoiding IE to fall back to compatibility mode?

        msdn.microsoft.com/en-us/library/jj676915(v=vs.85).aspx

      • Matt Thomas 7:53 pm on May 17, 2013 Permalink | Log in to Reply

        Hi Micio — do you get the same warning with and without MP6? If so, you should probably report this in a core trac ticket so it can get fixed in WordPress itself.

    • Just a guy 6:30 am on May 16, 2013 Permalink | Log in to Reply

      I like it! The new styling on the checkboxes and radio buttons is nice, but the dropdown menus could use a similar retouch…they look a bit out of place and outdated now.

      • Matt Thomas 7:54 pm on May 17, 2013 Permalink | Log in to Reply

        I agree; sadly most browsers provide very few (or no) options for customizing select elements with CSS. There may be some other options for dropdowns in the future (requiring new code, not just new styles) but I’m afraid for now they’ll be sticking with their default browser-supplied styling.

  • Matt Thomas 12:04 am on May 4, 2013 Permalink | Log in to leave a Comment
    Tags:   

    MP6 1.0 

    Here we are in the tenth week of the MP6 experiment, and with it comes our tenth release, 1.0. And while the version number is simply the one that comes after 0.9, it’s also beginning to look nearly complete. We’ve worked our way through our primary to-do list, concentrating now on responsive issues and core issues for which we’ll be submitting patches. Here’s what’s new this week.

    • 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.

     

    • Hassan 11:30 am on May 4, 2013 Permalink | Log in to Reply

      Great progress as always. Here’s what I have for you today:

      1. Some delete/remove links still sport the old red background and/or underline on hover, e.g. Delete link on any active widget and Delete link on themes page. That’s probably because there is no global “delete” style shared throughout wp-admin?
      2. the tables in Plugins > Add New > Featured, or Popular, or Search Results etc. have a plain white background with no different grey and white background for even and odd table rows.
      3. The new style for Upload Files and Media Library tabs in the media modal is much better now, however, there is still that soon-to-be-dead “burnt orange” color when hovering over the tabs. Another thing is that this new style is broken if you Add Media from QuickPress > Screenshot. Also, why not make them consistent with page tabs style? i.e. grey background on inactive tab(s).
      4. I see that icons in the toolbar now also turn blue on hover (e.g. comments icon), but when in the frontend with the toolbar visible, the search icon which opens up the search field does not have a hover effect; it’s dull.
      5. So, because Firefox does not (yet?) support customizing checkboxes/radios with CSS does that mean no workaround (e.g. JS) will be implemented?
      6. The issue of disappearing submenu in admin menu when moving the mouse near the arrow (reported by me here, point #2) is still there, I see. So, here you go, “it won’t hurt to mention it again” :)
      7. Are you planning to implement different border colors for the notification message class `.updated` (e.g. red for failed/unsuccessful)? Or have you settled on just making it green regardless?
      8. In IE10, if I have a blinking text indicator in a field (e.g. Enter title here when adding new post), and I hover with the mouse over a side menu that has a submenu, this blinking text indicator appears on top of the submenu. This is only happening in IE. Screenshot.
      9. IE10 again, the numbers inside number fields look wonky but they revert to good-looking state as soon as you click inside them. Screenshot.
      10. I think this is probably outside the scope of MP6 since it would require markup modifications, but can we please address the placement of those Help and Screen Options panels when the new design is out? They totally look like they don’t belong to wp-admin, let alone the fact that many users can’t see them at all.
      11. Hey, since we’re doing spring cleaning, let’s update the default grey loading spinner image! I never liked it anyway.
      12. Hovering over the grey comment icon in post listings table turns the icon’s color into blue, but the “tail” of the comment bubble is orange (!). Screenshot.
      13. Can we get rid of the default disabled scrollbars in textareas in IE? Screenshot. I hear `overflow: auto;` can do the trick ;)
      14. As a result of the increased font size, the Edit link in publish meta box appears in a separate line when the date is long. Screenshot.
      15. I’m not sure about the new icon for “Status” in publish meta box. What is it anyway?? Since it’s thinner than the eye and calendar icons, it looks like it is not aligned correctly : /
      16. Yep, TinyMCE icons also need to follow the new “great flattening” movement. They’re separate as TinyMCE is a standalone plugin, I know.. but still.
      17. I find it a bit confusing that the Unapprove, Spam, and Trash action links in comments table turn blue upon hover even though their original colors are orange and red.
      18. In the theme customizer there is a redundant blank row above the Close and Saved buttons at the top. Screenshot.
      19. In the Widgets area when Enable accessibility mode is selected, the Cancel button displays an underline on the text when you hover over it– that shouldn’t be. Screenshot.
      20. Done with my rant! I love WordPress :D

      • Joen Asmussen 10:35 am on May 10, 2013 Permalink | Log in to Reply

        This is an impressive laundry list, thank you!

        I’ve adressed a couple of your issues.

        1+2+10+11: Keeping in mind MP6 is just a plugin for now, some changes are best left until an eventual core merge happens. Particularly changes that are best done after core changes have been made. The plugin list, for example, lacks an “alternate” CSS class, and your idea of a global “delete” style is a good one. I invite you to consider creating one or a couple of trac tickets to improve the markup here and there.

        5: I don’t think we’ll work around Firefox inability to style checkboxes for the plugin phase, but it’s certainly worth bringing up the discussion when MP6 merges with core.

        6: Yep, that’s certainly not idea. It’s related, I suspect, to the left pointing arrow that takes focus for a short time. Like MT said, though, there’s a core ticket to improve the overall hover/flyout mechanism, which should fix this.

        7: We really wanted to! But distinguishing between types of notification messages require CSS classes that currentlhy aren’t there. This needs a core change.

        8: Wow, that is wonky. I haven’t been able to fix this. The z-index behaves as it should, so why the caret stays on top I do not understand. So I’m inclined to call this an IE bug.

        9: Higgs on a cracker. This is an issue only in the metro version of IE10, and even there the page requires only a reload to “fix” itself. I suspect it’s related to the fact that those boxes are HTML5 “step” boxes. Modern browsers show a little up/down arrow to allow you to increment or decrement the number. Again inclined to call this an IE bug.

        10: We’ve actually been through a fair stack of mockups trying to address the placement of these, but we arrived at your conclusion as well, out of scope for mp6. In order to give these tabs the proper redesign they deserve, there’s markup related to notifications to change as well!

        12: Great catch, fixed!

        13: Sure, let’s try that.

        16: I think you’ll be pleasantly surprised later today.

        17: Yep. Fixed.

    • mindctrl 1:33 pm on May 4, 2013 Permalink | Log in to Reply

      Thanks for the update. It looks like you have the date wrong for the next chat.

    • Manny Fleurmond 1:49 pm on May 4, 2013 Permalink | Log in to Reply

      I sorta liked the admin bar menus being the lighter grey; made a nice contrast with the bar itself.

    • yoramzara 5:10 pm on May 4, 2013 Permalink | Log in to Reply

      I am using RTL (Hebrew). The desktop version looks great. The mobile version is not usable. I recommend using http://wordpress.org/extend/plugins/juiz-smart-mobile-admin/
      It works better

    • Marko Heijnen 10:46 pm on May 5, 2013 Permalink | Log in to Reply

      Open sans should only be loaded when user is logged in. So the code need to be wrapped in if( is_user_logged_in() ) {}.

      Also curious what the state is of broken menu mentioned here: http://make.wordpress.org/ui/2013/03/30/another-friday-another-iteration-of-the-plugin-that/#comment-22843

    • Nick Halsey 1:05 am on May 6, 2013 Permalink | Log in to Reply

      It’s looking good overall, but a couple of issues:

      • No way to access the admin menu on Windows Phone 7/IE 9 mobile (rendering WordPress completely unusable). It’s fine on WP8.
      • Dashicons don’t work on Windows Phone 7 (see also http://core.trac.wordpress.org/ticket/23985). May be tolerable if you could at least access the admin menu.
      • Loving the responsiveness, but it makes a poor assumption that smaller viewport == touch (by making stuff bigger). This leads to weird UX when resizing windows; for example, snapping windows to half-screen in Window 7/8, when the admin bar get bigger and takes up more of the reduced screen real estate for no apparent reason. It also doesn’t account for the increasing emergence of touch screens on laptops and desktops with bigger viewports. Maybe input-type detection of some sort could better inform touch-target-related design decisions than viewport size?
      • Admin menu can display incorrectly in smaller viewports when toggling the menu from collapsed to expanded at medium viewports. For example, if you resize your window to a viewport where the admin menu is automatically collapsed (but not yet hidden fully), then expand (and also if you re-collapse) it, then resize your window past the breakpoint where the menu is fully hidden, it gets all messed up.
      • Depending on a variety of factors such as number of top-level menu items, screen resolution, etc., it’s possible to get stuck with a collapsed admin menu, with the expand button and some menu items stuck behind the browser’s on-screen back button in IE 10 Immersive (metro). I don’t think there’s anything we can do about it, but it can be very annoying. Issue is probably present without MP6, but is related.

      • Nick Halsey 11:51 pm on May 7, 2013 Permalink | Log in to Reply

        It turns out that issue 4 is setting a setting somewhere that makes the menu display (poorly) on WP7. So they may be related.

        Also, on the posts index page the table rows are super tall on WP7. There’re a bunch of other miscellaneous issues but I’d only worry about the significant ones since WP7 is slowly on the way out. Keep in mind that IE9 mobile is the devices’ ONLY allowed browser, though, so lack of support for the browser excludes users of the device from using WordPress there (except for the feature-limited app).

    • Mr Papa 4:14 pm on May 6, 2013 Permalink | Log in to Reply

      hey Matt, looks like you are hooking into ‘init’ to load the Google Open Sans font… can you change that to admin_init so it does not also get loaded on the front end??

    • Jose Castaneda 9:26 pm on May 8, 2013 Permalink | Log in to Reply

      Looking good so far will have to test with mobile ( iPhone 5 ) tomorrow.

    • Shiva Poudel 9:37 am on May 9, 2013 Permalink | Log in to Reply

      Hey authors how can I use custom dashicons or others font after using this MP6 Plugin….

    • Lorelle 6:03 pm on May 9, 2013 Permalink | Log in to Reply

      My college class is using the UI test on our sites and have found 2 issues.

      Firefox versions 17-19 are having trouble with the Edit Post > Publish > Visibility button. When clicked to access Public, Private, and Password Protected, the user is jumped down the web page and the Visibility feature does not open. They have to switch to Chrome to use that feature.

      The Autosave notification pops up on when editing posts on the first visit in hours, days, weeks, and months when no change to the page has been made. This happens across a variety of browsers and operating systems and remains reproducible over the past two weeks.

      Is there a specific place for WordPress.com users to report issues on this?

      Thanks.

      • Matt Thomas 4:34 pm on May 10, 2013 Permalink | Log in to Reply

        Hi Lorelle — I wasn’t able to reproduce the first issue you mentioned using Firefox 17, 18, or 19 on my Mac. Here’s a video of me trying to reproduce: http://f.cl.ly/items/0k2w3c0c1J0J3P0M2r3z/Untitled.mov Could you try that with MP6 (and any other plugins) disabled to see if it makes a difference?

        I haven’t experienced any issues with autosave either in developing MP6 so far. There’s no official support for MP6 since it’s still an opt-in test, but if you can provide more details on your setup here we’ll keep trying to reproduce the issues.

    • rvlawrence 9:18 pm on May 9, 2013 Permalink | Log in to Reply

      Is this the new admin theme for the next version of WordPress? When is it coming out? Or is it just a plugin? This isn’t clear.

      • Ipstenu (Mika Epstein) 11:03 pm on May 9, 2013 Permalink | Log in to Reply

        It’s a plugin for now. It may (hope) end up in 3.7 :)

        • rvlawrence 12:42 am on May 10, 2013 Permalink | Log in to Reply

          Oh wow, great to hear! Is this plugin OK to use on a live site now? Looks very fresh and modern. WordPress needs this.

          • Matt Thomas 12:53 am on May 10, 2013 Permalink | Log in to Reply

            Many people are using it on live sites, but your mileage may vary and things may still break at unexpected moments while we continue hammering on it. :)

    • Hassan 8:43 am on May 7, 2013 Permalink | Log in to Reply

      What tha?? I’ve posted a comprehensive comment here since Friday and it’s still saying “Your comment is awaiting moderation”, while obvious spams like this one above get the green light?!

    • Matt Thomas 3:46 pm on May 7, 2013 Permalink | Log in to Reply

      Not sure why your comment was originally held for moderation; I’m guessing it was the number of links. The spam comment has been removed.

    • Hassan 10:26 am on May 8, 2013 Permalink | Log in to Reply

      Yeah, I guess I had too many links.. that’s probably why :P

    • Matt Thomas 4:29 pm on May 11, 2013 Permalink

      It might be helpful to leave separate comments for each issue or group of issues; it makes it a little easier for us to reply to them individually (and reduces the chance of you getting caught in the spam filter). :)

  • Matt Thomas 11:26 pm on April 26, 2013 Permalink | Log in to leave a Comment
    Tags:   

    MP6 0.9 

    Thank goodness it’s Friday, because we get to bring you this week’s edition of MP6, the secret plugin that’s a little less of a secret every day. This week’s edition is primarily focused on improvements to the responsive design and 6PM (that’s MP6 in RTL). Here’s the details:

    • 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.

     

    • wordsauce 2:19 am on April 27, 2013 Permalink | Log in to Reply

      Have you heard anything about compatibility issues with mp6 and the WordPress MU domain mapping plugin?

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

        I haven’t had a chance to look at that plugin myself yet; but if you can provide some screenshots for us we can take a look.

      • Ipstenu (Mika Epstein) 9:47 pm on May 2, 2013 Permalink | Log in to Reply

        Even having a custom wp-content shouldn’t matter… What problem are you having, though?

        • johnchoo 6:51 am on May 16, 2013 Permalink | Log in to Reply

          I just customized my wp-content folder which caused MP6 to stop working.

          The admin now just looks like a non-styled admin panel.

          I’m guessing that after the wp-content directory change, something in the plugin folder stopped connecting with the admin settings?

          I deactivated the MP6 plugin and everything is working fine now.

          Would like to get this fixed though because MP6 is so much better!

          It’s kind of painful to have to look at the default admin now haha.

    • Hassan 4:58 am on April 27, 2013 Permalink | Log in to Reply

      Where can I find some of these “reset links”?

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

        It’s in the QuickPress interface: http://cl.ly/image/1f1x0q0l3L0K

        I think reset buttons in forms are kind of bad/scary anyway (wipes out all your input, with no undo), so I wanted to reduce its visual weight compared to the Add Media and Save Draft buttons.

        • Hassan 8:16 am on April 30, 2013 Permalink | Log in to Reply

          Oh, didn’t notice that– which proves the new design did indeed achieve its purpose, eh? ;)

        • Hassan 12:21 pm on April 30, 2013 Permalink | Log in to Reply

          …btw just noticed, when you click a reset link, that is, its :active and :focus states, it will still show some button-ish look– not something you’d expect when clicking on a text link.

    • Rami Yushuvaev 12:18 pm on April 27, 2013 Permalink | Log in to Reply

      The RTL looks much better, but there are still few issues.

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

        Mitcho will be continuing to look at RTL issues this week; if you know of any that haven’t been reported just let us know.

    • paaljoachim 10:28 pm on April 27, 2013 Permalink | Log in to Reply

      I apologize if this is the wrong place to post this, but the below is something that should be discussed.

      I began my test and have sent it through the feedback form at the admin-feedback page.
      Bottom line. Colors need to be accessible by the user so he/she can change the black, the grey background and the white boxes. This can be a rebranding section inside the settings area.
      Draggable areas: posts, pages, categories. To reorder.
      Media library: user created folders.

      Content Blocks do not work as these have to be initially created outside of a page/post. Block only show code inside the content area of a page or post.
      Content needs to be added in an intuitive way inside page/post. Improve the toolbar (Show/Hide kitchen sink just call it show/hide.)
      To split the content area into columns click the grid icon and an overlay is seen. Click a grid cell add media, or text etc. Move to another grid cell/space add content. Something similar to this: http://wp.smashingmagazine.com/2011/10/14/advanced-layout-templates-in-wordpress-content-editor/
      Click an icon if need be have a dialog box come up.

      Use Add Media for media. If the user selects multiple images (can be done by clicking inside a small check box on the image) have another dialog box come up to help with creating the gallery. But use the Add Media button and the existing but very much future improved toolbar to add content. It is not a good idea to go a totally new way.

      Content creation is a hot potato that needs a good intuitive approach. Having a grid layout (similar to a table) would help a lot.The user should be able to customize the toolbar to remove and add various content icons that is needed.

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

        These are some interesting suggestions to be sure, but many of them are likely outside the scope of MP6. We’ve limited this project to a visual redesign of the existing interface, for two reasons. One is that it’s a big visual change for users to adapt to, and if we combined a dramatic visual redesign with significant changes in information architecture it would present a significantly higher barrier to existing users (cf. the Windows 8 start screen). Second is just a practical consideration — we’ll be able to roll out a visual redesign into core WP a lot faster if we don’t attempt dramatic UX changes at the same time. That’s not to say they’re a bad idea, or aren’t worthwhile areas of improvement, just that they should happen independently of MP6.

        • paaljoachim 6:35 pm on May 1, 2013 Permalink | Log in to Reply

          Then I hope Core developers will pick up the ideas I suggested and expand them onward. I noticed two new features in MP6 the visual design.
          For rebranding – one part is color customization. Just inform the user that a new possibility called rebranding has been added. That the user now can customize the color scheme, wp icon, avatar, favicon and other rebranding options in one rebranding section inside the Settings area. Do not force a change upon the user, just inform that options are added so the user can customize it themselves.

          Content Blocks I have not seen before, and am puzzled why I see it there. Since this is not visual redesign but a new feature. As I already suggested, it is not a good route to take. It is a lot better to improve the TinyMCE tool bar so the user can get used to this instead of a new content block creation area (actually pretty much the same goes for post types which is a discussion on the core forum page).

          • Matt Thomas 7:04 pm on May 1, 2013 Permalink | Log in to Reply

            Thanks paal; we will definitely take your suggestions into consideration as we keep working.

            The ability to customize the color scheme of the dashboard will likely be easier to do with MP6 than it was before (because everything, including icon colors, will be controlled by CSS. That said, our plan currently is to only ship with a single color scheme for the sake of simplicity. I think a plugin that customizes the color scheme with an easy color selector would be awesome once MP6 is part of core, but I don’t think there are any plans for color customizers out of the box, as they add complexity that most users won’t need.

            Content Blocks aren’t a part of MP6; that must be a part of a plugin or theme you’ve got installed.

            • paaljoachim 8:37 pm on May 1, 2013 Permalink

              So color schemes will be controlled by CSS. That is interesting!
              If I take it one step further… Switching the WP icon for ones own company icon and other rebranding options using CSS would also be interesting. When options are controlled by CSS it makes it easy to share stylesheets with others. Interesting! Thanks Matt!

    • ckluis 12:06 am on April 30, 2013 Permalink | Log in to Reply

      @paaljoachim – you can check out:

      visual composer
      ether content
      titan editor
      carrington build
      multi-edit plugin
      elegant builder
      page builder
      aqua page builder

      My personal preference would be for a solid core of something like 320press using bootstrap as a base with the ability to load new CSS files for design. Then you could use a layout tool like the above and have the cleanest possible classes because you only have to change the design classes.

      • paaljoachim 9:36 pm on May 2, 2013 Permalink | Log in to Reply

        Content creation is such an important feature to get right and is one of the most asked for features. What about creating a content creation work group? Ckluis shares some of the ways that various developers have found a way to add content. There are likely some great developers out there that are just waiting for the chance to take part in a content creation work group hosted by WP.

    • studiograsshopper 9:34 am on April 30, 2013 Permalink | Log in to Reply

      There’s an issue with widget control panels which are wider than usual, resulting in the expand arrows of the background Active/Inactive widgets being visible where they shouldn’t be. here’s a screenshot:

      http://i647.photobucket.com/albums/uu196/adewsuisse/38ed95ca-4d49-4aa3-ba32-8795d5f6dd24_zps201e75c0.jpg

    • Ipstenu (Mika Epstein) 4:44 am on May 2, 2013 Permalink | Log in to Reply

      I reported it once before, thought it was fixed…

      The text for new posts (+ New) is vertically aligned poorly. If you remove line-height: 1;
       from #wpadminbar .ab-label, it works.

      #wpadminbar .ab-label {
display: inline-block;
height: 33px;
}

      • Matt Thomas 3:56 pm on May 3, 2013 Permalink | Log in to Reply

        That block of CSS looks suspicious anyway. :) I’ve corrected the height and removed the line-height properties.

    • rvlawrence 2:56 am on May 4, 2013 Permalink | Log in to Reply

      Is this going to be in WordPress 3.6?

  • Matt Thomas 11:54 pm on April 19, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Greetings, Savvy WordPress Enthusiasts. Time for another update to the plugin that gives WordPress that new car smell again, MP6.

    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.

     

    • mattatifpd 4:17 am on April 20, 2013 Permalink | Log in to Reply

      Loving this more with every iteration! One bug I’ve noticed is that plugins that add their titles to the “Settings” menu sometimes have long titles. So far, those long titles don’t wrap. This should fix that (though I don’t know if this affects other things I haven’t yet noticed):

      In colors-mp6.css line 214, change this:
      #adminmenu .wp-submenu {white-space: nowrap;}
      to this
      #adminmenu .wp-submenu {white-space: normal;}

      Here’s a screenshot of the title not wrapping (as an example): https://www.dropbox.com/s/r6ec7mjfx6c9cbm/Discussion%20Settings%20%E2%80%B9%20Matt%20Cromwell%20%E2%80%94%20WordPress_2013-04-19_21-09-20.png

      Hope that helps!

    • Hassan 11:50 am on April 20, 2013 Permalink | Log in to Reply

      Good job folks.

      1. I see that Firefox isn’t getting any custom checkboxes/radios love still?

      2. Try to hover over any admin menu item that has a sub menu, now move your mouse slowly to the edge of the menu approaching the grey arrow, the sub menu will go away. There is a “blind spot” there, I believe. This happens only when admin menu is expanded.

      3. There is inconsistency in the size of the arrow when the admin menu is collapsed. Screenshot.

      4. wp-list-table headers still need some love folks! They’re not easily distinguished from textual row data.

      5. I think field labels (e.g. in You Profile page) shouldn’t be bold; leave the emboldening to the h3 section headers instead, so that titles are distinct from content. Comparison screenshot.

      6. There is some inconsistency around those red-ish Delete/Remove links through various areas in wp-admin. Sometimes they have underlines, sometimes it’s a border-bottom. Hovering sometimes puts a red background on the whole link, sometimes it’s just a border etc. Also, the padding on hover isn’t correct for the Delete Menu link under Settings > Menus.

      7. I’m still not sure how to put this, but this “visual unification” thing for the admin menu and toolbar is still missing something… I wish I could figure out what it is.

      8. Those new icons in the Publish meta box are cool! Yay, calendar icon is no lonely anymore :D

      • Matt Thomas 12:38 am on April 25, 2013 Permalink | Log in to Reply

        #1 – No checkbox love for Firefox, sadly, as Mozilla’s support for changing the appearance of checkboxes is not great.

        #2 – I think the script for menus may be changing to the amazon-style instant dropdowns, but will keep this in mind.

        The rest I’ll take a look at. :)

    • Ulrich 12:59 pm on April 20, 2013 Permalink | Log in to Reply

      I am correct in understanding the responsive design is not finished yet. This is what I when I resize my chrome browser and try to open the menu.
      http://pix.am/HeqX.png

    • Jose Castaneda 3:08 pm on April 20, 2013 Permalink | Log in to Reply

      @Hassan I noticed #2 as well while using Chrome, Safari and Firefox but IE10 seems to not have that issue.

      One thing I did notice is when you hover on the table pagination the styling seems to lack a little contrast.
      http://img803.imageshack.us/img803/9237/mp6tablenav.png

      The second is the footer seems a little odd when the menu is expanded:
      http://img713.imageshack.us/img713/51/mp6footer.png

      • Matt Thomas 12:39 am on April 25, 2013 Permalink | Log in to Reply

        Thanks, I’ve added both of these to our list.

      • Matt Thomas 12:46 am on April 30, 2013 Permalink | Log in to Reply

        A fix for the table pagination issue is now in trunk.

        I haven’t managed to reproduce the second issue with the footer overlaying the sidebar; let me know where you’re seeing that if you still are.

    • juicypixels 9:16 pm on April 20, 2013 Permalink | Log in to Reply

      The footer is messed up for me. Line 3479 is .rtl #wpcontent, #wpfooter but should be .rtl #wpcontent, .rtl #wpfooter.

    • NumberKruncher 2:09 pm on April 21, 2013 Permalink | Log in to Reply

      The checkboxes are still appearing incorrectly in the “Edit Gallery” section (see http://pbrd.co/11XdIEc). This is occurring with 0.8 on my development server plus on my wordpress.com account.

    • Ipstenu (Mika Epstein) 10:46 pm on April 23, 2013 Permalink | Log in to Reply

      Widget titles are totally readable in active widgets now! Yay!

      Not so much for inactive: http://cl.ly/image/3p1e3j1p1Q2t

      May I suggest this?


      #wp_inactive_widgets .in-widget-title {
      color: #0074A2;
      }

    • John Blackbourn (johnbillion) 8:42 am on April 26, 2013 Permalink | Log in to Reply

      Small issue: The table headers on the comment moderation screen are missing some padding.

    • Jamàl 6:06 am on April 30, 2013 Permalink | Log in to Reply

      It seems the plugin loads Open Sans stylesheet in the front end.

  • Matt Thomas 2:38 am on April 13, 2013 Permalink
    Tags:   

    MP6 0.7 

    Hey gang. It’s still Friday in part of the world, which means the latest iteration of MP6 is now available. This week was mostly dedicated to refining what we’ve been working on so far, expanded testing and support for multi-site installations (particularly one really big multisite installation), and styling some of the new UI that’s landed in WordPress 3.6.

    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.

     

  • Mark Jaquith 3:52 pm on April 11, 2013 Permalink
    Tags: post format ui   

    @saracannon has posted her take on a new direction for post format UI, addressing some of the concerns that surfaced after @lessbloat‘s tests. Re-thinking WordPress Post Format UI.

    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.

    post-formats-classic-i-copy-1024x698

    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.

     

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

      The modal doesn’t feel quite right to me. A) So many sites are adding those ultra-annoying modals, and It would feel a little like that to me, and B) with the exception of the Media modal, i feel like it doesn’t fit with the current UI direction. It’s very well done, so I don’t want to sound too critical, but it doesn’t feel quite right to me.

    • Mel Choyce 4:01 pm on April 11, 2013 Permalink | Log in to Reply

      Was just about to post this below, but I guess it belongs here now:

      I love these explorations! I know we don’t want increase the barrier between thought and post, but I do think that by choosing to write a post, you’re already making a decision. I like that we’re prompting users into action by making them decide on a post format. I wish we could test this with a selection of .org users, who might have different goals and behaviors than .com and tumblr users.

      Going on to the individual exploration, I’m not a huge fan of modals — especially since they never seem to act correctly on a small screen — but I can see them being a handy solution here. What would happen if someone automatically closes the modal, though?

      Overall, I agree with Mark — I definitely think #2 is the right direction. It makes a lot of sense to me, especially since it’s bringing you to the right screen and prompting you for action without the distraction a modal window might have. It helps directly reinforces how your decision effects what you’re posting. With a modal, there’s a little bit of a disconnect between what you choose and how that changes what you see.

      Building on this, I can also envision a setting that allows you to set your default post format, which would highlight your default when you land on the new post page and have the others greyed out. Alternately, we could do the selected/default icon in color and leave the others b+w. Power users, people who just post one type of content, or even professionals creating sites for clients could set defaults or disable formats entirely, and I think #2s method would make any of those changes easier.

      • Mark Jaquith 4:08 pm on April 11, 2013 Permalink | Log in to Reply

        So I was thinking that if you clicked into the post editor or title, it’d select Standard and let you go on your way. Just like before. And we could give focus to the post title, and select standard if you just started typing a title. Again, just like before. So this way you can’t miss the new UI, but you can also just skip past it when you just want to start composing.

    • esmi 4:09 pm on April 11, 2013 Permalink | Log in to Reply

      The perennial issue with modal windows is ensuring that they are fully accessible to those using screen reading software or those who don’t use a mouse. Ensuring this level of accessibility can put a lot of additional strain on the UI devs. Is that really something you want to impose at this stage of the game?

      • Mark Jaquith 4:13 pm on April 11, 2013 Permalink | Log in to Reply

        I’m not advocating that we use a modal. I agree with your concerns (and have more of my own). See above comments. Updated post with screenshot to be clear about the approach I was talking about.

    • sara cannon 4:13 pm on April 11, 2013 Permalink | Log in to Reply

      The greyed out area can also surface and choose “standard” as a format when clicked / tapped

    • Ipstenu (Mika Epstein) 4:17 pm on April 11, 2013 Permalink | Log in to Reply

      Would it still be possible to switch between? Sometimes I change my mind, and one thing I HATE about how Tumblr does it is that I have to totally start over :/ I Even if there was a warning that any standard specific content would be lost, the main part of the post below I’d like to keep.

      • Chip Bennett 4:19 pm on April 11, 2013 Permalink | Log in to Reply

        Looks like the sidebar meta box is retained – or, is rolled into the Publish meta box, as a dropdown or radio select.

      • sara cannon 4:20 pm on April 11, 2013 Permalink | Log in to Reply

        Yes, in the publish meta box there will be a switcher. I also think this is essential

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

          So I’m clear — the switcher won’t stay above the post title as it is now in Beta1? IE: the icon bar will go away after you’ve made your choice?

          • Mark Jaquith 4:59 pm on April 11, 2013 Permalink | Log in to Reply

            That’s the idea. Big and up top on first load. Tucked away once you’ve chosen (either explicitly or implicitly). Addresses the two big issues we’re having in beta 1: not obvious enough before choosing, in the way after choosing.

            • sara cannon 5:00 pm on April 11, 2013 Permalink

              and resolves any potential confusion for users that might think they can use all the buttons/formats on one post

            • Terry Sutton 5:06 pm on April 11, 2013 Permalink

              Ok. In that case, I’m split on the idea of it going away to a metabox, or staying above the post title as it does in Beta1. So after you’ve chosen which post type, here’s what you see: http://cl.ly/image/2g1f3o2D3m1U

            • Brian Richards 5:36 pm on April 11, 2013 Permalink

              I can’t decide whether or not I’d like for the UI to disappear completely after choosing my post format. I do like the notion of “putting it out of the way”, but what happens if I’ve accidentally clicked/tapped the wrong format and wanted to quickly click/tap on a different one — is the UI only removed after I begin entering content?

              I know from the explanation that the UI just gets moved into the Publish metabox, but it’s unlikely I would know or expect this behavior otherwise.

              The alternative of keeping it in place (and dimming the unselected choices) doesn’t sound like a great solution either because, as already discussed, it stays in the way and could lead to later confusion about the purpose of the buttons (e.g. “is this how I add a link to my post?”).

              Tough call…

    • Chip Bennett 4:17 pm on April 11, 2013 Permalink | Log in to Reply

      +1 to “In Page decision with post editor greyed out. Icons will go away and the “switching” will be in the sidebar like above.” It looks great, and appears to be a huge improvement to what we have now (3.5.1 and 3.6 beta 1).

      -(Eleventy Frillion) to a modal.

    • Robert Dall 5:06 pm on April 11, 2013 Permalink | Log in to Reply

      OMG you are awesome @saracannon I loved how you covered all the bases here… A couple comments.

      The Modal system as @AndyPeatling put it on twitter. “Not sure forcing the UX would be well received for dot org though. Most don’t care or use them.”

      The Post format switching as a radio button would to far to long leading pushing the category, tags, feature image to push them lower in the window.

      Icons with Text +10,000 looks awesome!
      One comment regarding the icons getting greyed out on the hover is it is opposite of the hover state in the admin menu on the left. We should keep the standard hover over icons the same through out the admin section of the site.

      Can we choose icons only or text only or both like Apple offers in there mail application? It seems that would suite the best of both worlds.

    • Tom Auger 5:08 pm on April 11, 2013 Permalink | Log in to Reply

      Really love this new direction. The in-your-face visual icons really bring this often-underused part of the post to the front.

      My only comment is – does the editor really need to be greyed out? Should we not just default to “Standard” and then let the user switch it up from there. I can just see a ton of bloggers who don’t currently use post formats get really annoyed when we add another click to the process.

      • Robert Dall 5:15 pm on April 11, 2013 Permalink | Log in to Reply

        I see your point most bloggers will choose the standard post… It beta1 it already chooses standard by default and I think we should keep it that :-)

      • sara cannon 5:19 pm on April 11, 2013 Permalink | Log in to Reply

        Mark pointed out above that we will still have the title field focused like normal – so start typing like normal and there is no extra “click” and standard is chosen for you

    • Ryan Cowles 5:38 pm on April 11, 2013 Permalink | Log in to Reply

      Awesome work, Sara! These concepts look rad.

      While I don’t have much to say in regards to the UI itself, I think this part is important: “you can turn all post formats off from within core settings to override what your theme set. ”

      If a new step in the post creation flow is introduced that forces the user to select a post format, I think the user should be allowed to disable it. Therefore users that only use one post format aren’t forced to go through an unnecessary step each time a new post is created. Just my $0.02.

    • Helen Hou-Sandi 6:04 pm on April 11, 2013 Permalink | Log in to Reply

      I think this is a good compromise between representing the “choose once” part and not blocking users from just writing a new post as they currently can. What’s currently in trunk definitely does not reflect that it’s (generally) a one-time format selection before you get started. I think with smart wording in the feature pointer letting the user know that they can turn this off in screen options in addition to the filter that’s already been committed, it will work out okay.

      Question about the “just start typing to make a standard post” interaction, though – what happens to the switcher? Does it disappear and cause everything to shift up while the user is typing? That seems less than ideal to me.

    • Chip Bennett 6:09 pm on April 11, 2013 Permalink | Log in to Reply

      Crazy thought: what if the big ol’ post format icons were stacked vertically, to the left of the post editor (i.e. a third column on the post-edit screen)?

      Still have the everything-grayed-out-before-selection UI, but then let the icons remain where they are after selection.

      That would allow for easy switching, and would not cause the UI to jump around with appearing-then-disappearing icons above the post editor.

    • thirzah 6:13 pm on April 11, 2013 Permalink | Log in to Reply

      (random person chips in) Love it – but minor thought – if they are at the top, and (what looks likely to be) more meta boxes pushing post/data entry ever downwards, would it be possible to make the ‘publish’ box pinnable, or copied at the bottom, or something? – Yours, Lazy Scroller :)

    • sara cannon 6:19 pm on April 11, 2013 Permalink | Log in to Reply

      For responsive screens, we can wrap the icons. because they will be eliminated after choice – we don’t have to worry about real estate

      980: ​​http://s.sar.ac/image/3B2H2v0P1841
      768 ​Option 1: http://s.sar.ac/image/1D1e002x2i0X (5 across slightly spread out)
      768 Option 2: http://s.sar.ac/image/2a3u3v3E3p03 (5 across slightly spread out & centered)

    • nathanrice 6:30 pm on April 11, 2013 Permalink | Log in to Reply

      I have some deeper issues with the new Post Formats, but first let me say that I like the idea of a “decision first” approach with the ability to change in the publish box. Makes a lot of sense to me, and doesn’t clutter the post UI with buttons. It’s a little out of the way, which may have UX implications, but the initial decision path more than makes up for that.

      As for the Post Formats strategy itself, I’m troubled by the decision to turn this feature on by default. From reading through a few trac tickets, I can see the logic behind why this decision was made, but it still seems like it’s going to be a bit of a shock, especially to theme developers who may not see this coming, and certainly to users who will now have a UI that their theme isn’t at all prepared for.

      If this is the wrong place for this discussion, please tell me where I can go to bring this up with the powers that be. I’d like to understand the rationale if there was no other alternative, but otherwise, I’d like to see if there isn’t a better alternative than what we’ve got currently. And if my initial assumption is incorrect, I apologize.

    • Hal Gatewood 6:39 pm on April 11, 2013 Permalink | Log in to Reply

      Rough potential tabbed idea… http://goo.gl/143Zu

    • Drew Jaynes (DrewAPicture) 7:40 pm on April 11, 2013 Permalink | Log in to Reply

      I really like this concept a lot better. Plus, there’s parity with the hide/show overlays we used in the menus UI refresh.

      The thing I’ve consistently heard from talking to people about the new formats UI is that an intermediary choice step would solve a lot of the headaches and I think take this approach over what we have now will be a big step in the right direction.

    • Archetyped 4:18 am on April 12, 2013 Permalink | Log in to Reply

      “In Page decision with post editor greyed out” seems like the best option as others have noted.

      I agree with @markjaquith that clicking the title/description fields should automatically select the default post format and close the selection UI, however, I would suggest it be even a bit more flexible than that. I would suggest that clicking anywhere outside of the “post format selection UI” should automatically select the default post format (e.g. standard post) and close the post format selection bar just as if someone had selected the format itself. This allows for a much larger hit target for the user to get to the editor and start creating content without much delay.

      I think it was also suggested that the post format selection UI go away immediately if the user starts typing in the title field (focused by default). I like this as well.

      In addition, how about an option in WP’s settings to allow the user/author to set the default post format. The editor fields for the selected post format’s would be displayed by default when creating new posts and the appropriate button would be highlighted in the post format selection UI.

      This would be a productivity boost for users who post mostly videos, or mostly links, or mostly status messages, etc.

      • sara cannon 4:53 am on April 12, 2013 Permalink | Log in to Reply

        “I would suggest that clicking anywhere outside of the “post format selection UI” should automatically select the default post format ” — yes! I’m not sure if this was mentioned in the above threads but this is definitely something that should be included.

        @melchoyce also has mentioned the idea of setting a default post format in a comment above. I think that idea should definitely be explored further and is a logical next step. Part of why I think this is – we have ten formats with no hierarchy for preference.

    • Grant Palin 6:48 am on April 12, 2013 Permalink | Log in to Reply

      I generally dislike popups, modal or otherwise, when they are not really necessary. I could have made an exception in this case since the choice it would provide would determine the appropriate UI. It’s something that kinda needs to be done up-front.

      That said, it’s still a jarring change, and the better option may be the row of icons above the editor, which maybe shrinks or fades when a choice is made in order to stay out of the way. At least it’s top and center that way.

    • Avryl 11:24 am on April 12, 2013 Permalink | Log in to Reply

      I don’t really get the concept of selecting a post format. All post formats do more or less the same, you can add media, add a title, add a description/content. Why not just have one and detect what’s posted?

      Or maybe, have two buttons in the media uploader, one “insert in post” and one “make an image post”, same for a gallery, video and audio. When the user adds a link to the content, give the option to make a link post. Maybe this would be more obvious if there’s an “add link” button next the “add media” button or by somehow integrating them both in TinyMCE. A status post can be created if there’s no title.

      I’m just wondering, but what happens when a user inserts an image into the content of a standard post format and nothing else? Then that would be an image post right? Maybe it’s possible to detect if the user assigns the “wrong” post format, as in the UI test?

    • jrbeilke 2:45 pm on April 12, 2013 Permalink | Log in to Reply

      Nicely done Sara. I also prefer the in-page decision for post formats and think it stands out more than the current beta UI without being too obtrusive.

      I am concerned about all of the new decisions that a writer will be faced with when adding a new post. At a minimum the screen options/theme support should help to control the available post formats. Defaulting to a standard post when no selection is made would also streamline the process for those that want to stick with their current workflow.

      Another issue that I’ve run into while testing is the admin Posts screen, and posts without a title. It would be nice to tweak the Posts screen to show a snippet from the post if no title has been set. Maybe it’s just me, but with some of these new post formats (ie Aside and Status) a title isn’t necessary, but makes administration difficult without it.

      Posts without titles – http://i.imgur.com/M40SwIR.jpg
      Mockup Posts with snippets – http://i.imgur.com/WtwfSnt.jpg

      • Konstantin Kovshenin 2:46 pm on April 12, 2013 Permalink | Log in to Reply

        Related/possible solution: #24011

        • jrbeilke 3:09 pm on April 12, 2013 Permalink | Log in to Reply

          Thanks, didn’t see that ticket.

          Looks like it might work, but if it’s tied into save_post then what if there are already existing posts without titles? Will the user have to go through and re-save all of the posts that are missing a title?

    • Matt Mullenweg 8:10 pm on April 14, 2013 Permalink | Log in to Reply

      Also as food for thought: we’re supporting too many formats. Anything where you’re giving a user 10 choices before they get started is going to be rough from a usability and design perspective, especially given it’s not really obvious what that choice does not just to the form, but to the post when it’s published.

      There is some direct and indirect data about which formats are most used, perhaps we could apply our 80/20 principle to just supporting the 3-4 formats that would make the biggest difference to users.

      • Ipstenu (Mika Epstein) 3:49 am on April 15, 2013 Permalink | Log in to Reply

        What if you consolidate?

        Image and Gallery – Make it one, and if someone puts in an image, it shows just one. If it’s a gallery code, or they attach mulitple images, then use a gallery? To steal a page from Tumblr, that’s how they do it.

        You could do the same for audio/video maybe. Though that would be harder to theme in both cases.

        • sara cannon 10:51 pm on April 16, 2013 Permalink | Log in to Reply

          ^ I really like this solution – we just use the format “image” in the UI, but then when a user attaches more than one, it automatically makes it the “gallery” format in the background (no need to manually switch). It solves a UX problem where someone might decide to upload more than one after-the fact. (image->gallery is really one of the main use cases for decision-changing that I foresee)

      • Mark Jaquith 12:46 pm on April 15, 2013 Permalink | Log in to Reply

        The formats have been defined in code and in the codex for a while, so dropping some formats would result in data loss for some.

        One thing that has been considered is hiding less-used formats, so that instead of 10 options, you might have 5 options and a “more” button.

      • Ian Stewart 3:21 pm on April 15, 2013 Permalink | Log in to Reply

        +1 for hiding seldom used formats.

      • Andy Peatling 5:09 pm on April 18, 2013 Permalink | Log in to Reply

        I posted usage stats for frontend WordPress.com posting here: http://core.trac.wordpress.org/ticket/19570#comment:154

    • chabis 10:32 pm on April 17, 2013 Permalink | Log in to Reply

      There needs to be some careful rethinking about the post formats. two assumptions:

      A. many users want to create a post with a single content (gallery, audio, image, etc) and a post format is fine for that.
      B. many other user want to create a post that contains an image, a text, another image, then a video, etc.

      Now how do you make clear to the user that A. is not equal to B.? A. is a complete view change from a Post to a Gallery whereas B. is a Post with multiple content elements.

      In my point of view, and as mentioned before, the user gets confused by post-formats and the icons. Especially the icons can me users think that they need to click on the format to insert a media. And at the same time the decision hurdle is too high, maybe a user changes its mind during the editing process, what do you do then?

      Maybe we need to think about the editor in a slightly different way. It should be intelligent enough to make assumptions with the added and future content. The text-editor of koken.me is just a wonderful inspiration for that:

      http://help.koken.me/customer/portal/articles/632095-text

      • Anointed 6:37 pm on April 21, 2013 Permalink | Log in to Reply

        WOW, just WOW, that koken admin is SWEET! Especially the media manager. thnx for the link, not sure I would have ever found it on my own. Really gives the WordPress media manager something to aim for.

    • Anointed 6:34 pm on April 21, 2013 Permalink | Log in to Reply

      Not sure where to make this request, but this seems as good a place as any.

      I actually like the new post-formats setup, especially the video format where the actual player shows up on the page after clicking publish. This makes it so much easier to understand what is happening and to make sure the video oEmbed url works and you have the right video.

      My only request, is it would be nice to have the video player display PRIOR to clicking publish.

      Right now, we are able to make sure we have everything else right prior to publishing, but cool as this new player showing up is, we still don’t know that everything is perfect prior to publish as we can’t see the player.

      So, please make the player show up as soon as the oEmbed url/embed code/etc is inputted into the box.

  • lessbloat 6:10 pm on April 9, 2013 Permalink  

    How can I help with 3.6? 

    Are you looking for something to work on for 3.6, but don’t know where to start? Here a breakdown of a few open UI & front-end dev tasks broken down by skill set:

    UI

    HTML5

    CSS

    JS

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

     

    • trishasalas 7:19 pm on April 9, 2013 Permalink | Log in to Reply

      I’d love to help out with ticket 23810. I have a test subject who is legally blind as well as color blind…Question though, I am unfamiliar with the ticket system, how would I get started?

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

      Why Post Format also appears in themes that do not support it?
      It’s just unnecessary and misleading.
      Until 3.5.1, if the theme did not support the Post Format, it did not show up on the page.

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

        @arielk As best I can tell from looking at code in 3.6′s code (though I haven’t read anything about this), it seems like the extra post-format data will be appended/prepended to the the_content() if the theme doesn’t handle it separately. I’m not completely sure about this, so I’d love someone who knows more to clarify, but I think I’m seeing that.

        • ArielK 8:08 pm on April 9, 2013 Permalink | Log in to Reply

          @mrwweb I’m not talking about the theme itself, I’m talking about the display on the edit post.

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

            To clarify: *Because* post format data for 3.6 is displayed on the frontend regardless of the theme, it’s no longer theme-dependent on the backend.

      • lessbloat 8:51 pm on April 9, 2013 Permalink | Log in to Reply

        I think the plan is to have fallbacks for all post formats, for all themes, even those that don’t support post formats. See http://core.trac.wordpress.org/ticket/23347 for more.

  • lessbloat 2:13 pm on April 9, 2013 Permalink  

    Post formats Usability test – round 4 

    Here’s another round of post formats usability tests (testing against the UI currently in trunk).

    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?

     

    • George Stephanis 2:22 pm on April 9, 2013 Permalink | Log in to Reply

      Perhaps it’s worth including a new feature pointer to the new post type selector?

      • George Stephanis 2:22 pm on April 9, 2013 Permalink | Log in to Reply

        Errr … post format, rather. D’oh.

      • Matt Mullenweg 5:13 pm on April 9, 2013 Permalink | Log in to Reply

        If you have to point to it, you’re doing it wrong.

        • Mark Jaquith 5:28 pm on April 9, 2013 Permalink | Log in to Reply

          We point to just about everything new we add.

          • Manny Fleurmond 6:23 pm on April 9, 2013 Permalink | Log in to Reply

            But Matt has a point. The new feature has to be obvious or else a user won’t use it. When I first installed the beta, my first thought was that it was unobtrusive to the point of near nonexistence.

            • Mark Jaquith 12:23 am on April 10, 2013 Permalink

              Yeah, I agree. Am batting around some ideas. Some of our previous incarnations/mocks were more prominent.

      • paaljoachim 8:20 pm on April 27, 2013 Permalink | Log in to Reply

        I would personally junk the new Post Type selector as it creates confusion. Or even better incorporate it into the content toolbar area. It is not intuitive as it is seen in the video test.
        From watching test 7 I do so totally agree to how she was handling how to create posts.

        Create new post -> Then begin to think about what one needs to do.

        Inside the content area it is natural to click Add Media as the button is obvious to see. One would naturally also add a gallery in the same way. Adding a link can be a bit hard to understand and she is just kinda guessing how to add a link and clicks the Add Media button as she has become used to using it. It requires some practice in selecting text then clicking the lock icon in the toolbar to then add a link. Adding a video should be as intuitive as the woman in the video test makes it out to be, but for the moment it is not, but it seems that is changing in 3.6.

        Have one post type and then inside the content area…. add the content. Be it an image, gallery, quotes, chat, video etc. Instead of focusing so much on creating post formats it would have been A LOT better if the focus was on creating easier ways on adding content inside one area.

    • Manny Fleurmond 2:25 pm on April 9, 2013 Permalink | Log in to Reply

      I think the post format bar is a bit too unobtrusive. Maybe the icons need to be bigger?

      • Mark Jaquith 12:24 am on April 10, 2013 Permalink | Log in to Reply

        Current idea I’m batting around is bigger with text, at least until you’ve saved a draft and committed to a particular post format, at which point, we could show a more unobtrusive or change-oriented UI.

        • Samuel Wood (Otto) 12:47 pm on April 11, 2013 Permalink | Log in to Reply

          Definitely “with text”. A pure icon based UI is pretty awful in this case because there’s no way to know what those icons mean or do until you click on them. Each of those icons should have text underneath it saying what it is.

          I’m sure that these results might be different if somebody looking to add a “quote” had the word “quote” on the screen somewhere.

    • mindctrl 2:53 pm on April 9, 2013 Permalink | Log in to Reply

      The post format icons are too small and maybe even need to be a bit darker.

      The text that changes at the right end of the bar to indicate what kind of post format you’ve hovering over is too far away and disconnected from the mouse cursor.

      When you first “add new”, the cursor is in the title box, as it should be, but if you select a different post format, such as “link”, the “Enter title here” text goes away, and you’re presented with two boxes. It’s a bit confusing.

      When you enter a title, the permalink text shows up by “sliding” into view, and pushes down the content area box. Never really noticed that until watching the video, but it feels a bit weird now that I notice it.

      The “add media” modal needs work. If someone inserts a YouTube url like she did, the embed should probably show instead of a link.

      When adding a video link via the video post format UI, the video embed/box doesn’t show in the content area. I’m thinking something should show there similar to how an image shows.

      When adding a video post using the new post formats UI, the user is presented with a different flow than, say, the image format and gallery formats (both which have their own differences/inconsistencies). On video, they can paste a url into the box (which is quite big for a url, which I take to mean more than one is allow, and why doesn’t the image format mirror this?), they can use the big box that says “Select Video from Media Library”, they can use the “Add Media” button, and if they know it, they can just paste a URL in the content box if it’s an oEmbed capable link.

      When adding an Image post format post, there’s a box called “Link URL”. What does that mean to a normal person? Having not even tried it yet, I don’t even know what it means. Without having tested it, I would assume it’s a place to paste a direct link to an image. If that’s the case, why is the box smaller than the video URL box, which seems to allow/encourage multiple URLs.

      Note about previous paragraph: because I didn’t know what “Link URL” meant, I had to test it. Turns out, it’s a link that wraps the inserted image. Not intuitive, at least to me, and likely not to my mom or wife or anyone else that doesn’t live on the computer like I do.

      –
      Those are my quick thoughts for now. I’d be glad to share more later.

      Thanks for the user testing videos. They’re helpful.

      • Mark Jaquith 12:27 am on April 10, 2013 Permalink | Log in to Reply

        Thanks for your feedback. You make some really great observations, and I’d like to take action on most of them.

    • Robert Dall 4:02 pm on April 9, 2013 Permalink | Log in to Reply

      Mindctrl my thoughts exactly… Also what if you put a external link for a image in the media uploader. Does that link then get carried forward? Or does it get overwritten by the link url in the post format?

      • mindctrl 2:44 am on April 10, 2013 Permalink | Log in to Reply

        The image format doesn’t present the option to link the image in the media modal when clicking the big “Select/Upload Image” icon. You can only do that from the main post screen in the “Link URL” box – inconsistent with the way it works using the regular “Add Media” method.

        I think I’d rather see the “Select/Upload Image” icon/link and the “Link URL” options go away, and prompt people to use the “Add Media” button like they are when doing a gallery post. It provides both consistency and all functionality.

    • davidossahdez 4:06 pm on April 9, 2013 Permalink | Log in to Reply

      Maybe a text saying “Select your post format” just above the Post Format toolbar can be useful. The user needs to know what are going to do that great looking buttons. Also, the bar is big enough to put a label to the side of each button. The colors must be conserved. They are unobtrusive for people that simple wants to make standard posts, what actually is great.

    • emanuel_blagonic 8:03 pm on April 9, 2013 Permalink | Log in to Reply

      Hi everyone, let me drop in in this discussion. We work a lot with the users and most of them would say that the post format bar is not really visible. I think there are 2 issues there:

      1) The only thing you see when you want to create a new post is the info on the right side saying “Standard Post”. I think the better call to action would be “You’re creating a Standard Post” or something similar. Off course, I’m not a native english speaker so have that in mind. Maybe this will be more helpful?

      2) Visually, the post format bar looks really nice, but what would be better is if the bar would be in a for of a tab-navigation. I think this could make an visual impact for a user to see post formats more clearly and because of the tabs (and seeing the selected tab as well) will lead him to think there is more than only creating Standard Post.

      My 2 cents, sorry for bad english ;)

    • petemurray 8:12 pm on April 9, 2013 Permalink | Log in to Reply

      The other post formats look unclickabe. Grayed out = not an option to most users.

      The head of the page says ‘Add New Post’, I’d think that the post format is already selected. Perhaps ‘Add New’ would work better? It would leave the user with a choice to resolve.

      Perhaps also a visual tweak – make the buttons appear tab like?

    • Mel Choyce 9:15 pm on April 9, 2013 Permalink | Log in to Reply

      Maybe some color could help?

      • Robert Dall 9:48 pm on April 10, 2013 Permalink | Log in to Reply

        I would have to agree… the use of colour would help in the UI a lot… But I would also comment that larger icons would great increase usability for those without great eyesight or getting on in years.

    • Isaac Keyet 9:33 pm on April 9, 2013 Permalink | Log in to Reply

      The problem is fundamental. If you ask someone to post a new post in WP, these are the steps they would have to take:

      1. Log in
      2. Find Posts in sidebar, click Add New
      3. Type up a post, Publish

      If you ask someone to do an image post they’d follow the exact same steps. It’s a problem with intent. If the user intends to post an image post from the start, that should be the starting point. The current UI is not action centric and therefore the process is illogical to users.

      Consider this for a regular post:

      1. Log in
      2. Find “New Post” or equivalent somewhere in the UI
      3. Type post, Publish

      And this for an image post:

      1. Log in
      2. Find “New Image post”
      3. Create post, Publish

      Action-centric.

      • Mark Jaquith 12:33 am on April 10, 2013 Permalink | Log in to Reply

        Or:

        1. Log in
        2. Find “Add New” or “New Post” or equivalent
        3. Be prompted as to what kind of post you’re creating
        4. Create post, Publish

        The problem with making the decision as the first step is that we have a lot of entry points, and our menus would become really huge if each format got a spot.

        Now, that’s not to say that we can’t have such “choose first” points. But I don’t think we can do it universally. I’d actually like if the dashboard had a Tumblr style row of huge post format icons that’d jump you into creating something of that type. I think @melchoyce mocked that up.

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

          > I’d actually like if the dashboard had a Tumblr style row of huge post format icons that’d jump you into creating something of that type. I think @melchoyce mocked that up.

          Better yet, @ryelle already coded it up — she was just waiting on me to get her finalized icons. We decided in chat to make it a plugin before putting it into core.

        • mindctrl 3:09 am on April 10, 2013 Permalink | Log in to Reply

          The Tumblr style row of icons with text below would be great for the dashboard, and a smaller-sized version for the post-new screen.

          The default dashboard config has a lot of things that I think average users don’t really care about, and I’ve heard that a few times.

          The “Right Now” box is full of stat data that doesn’t serve a useful purpose for average people. I don’t think most people care that they have 33 posts, 14 pages, 52 categories or 49 tags. I don’t think they care what the name of their theme is and how many widgets are active. At least not in their face every time they login. They don’t need to see which version of WordPress they’re running there too, since it’s already in the footer.

          All of that is precious real estate that could be used better for actionable items like the row of icons.

          Obviously that’s all configurable; just speaking about the defaults – which are many peoples’ first impression.

          I’d love to see that mockup of the row of icons mentioned. That would make a great default dashboard widget.

    • Lance Willett 9:23 pm on April 10, 2013 Permalink | Log in to Reply

      Have we done a variation where the “Add New Post” text changes with the chosen format? I keep thinking it’s a bug that it doesn’t change.

      Example:

      • Robert Dall 9:54 pm on April 10, 2013 Permalink | Log in to Reply

        Agreed… That would help… What about taking a page from Apple’s Mail Program with having the icons under the text.

    • sara cannon 7:41 am on April 11, 2013 Permalink | Log in to Reply

      I did an exploration exercise on post format UI – blog post here http://ran.ge/2013/04/11/re-thinking-wordpress-post-format-ui-an-exercise/ – I agree with lance that the title should change with the format

    • Paul 2:04 pm on April 28, 2013 Permalink | Log in to Reply

      I don’t think making crap icons bigger, or changing them to crappier colors is going to help here. also the whole implementation seems to be half in and out. I don’t mean to hurt anyones feelings but I feel like maybe we need to be a bit more honest about the whole situation. (

      1. I think text based tabs would be better than the current offering, as well as greater clarity of which item is selected. It needs to explicitly show that its actually related to the rest of the items on the page (as one usually does with tabs for example ). I’ve been using the a custom variation on crowdfavourties post formats UI for a while on a number of client projects, and had quite a bit of success with clients getting it straight away.

      2. This all seems to be a blatant attempt to duplicate tunblr’s way of doing this – except doing it poorly. WP has always been one step ahead in usability in my opinion, and its a competitive advantage that should not be sacrificed.

      3. I agree that if you have to point to it you’re doing it wrong. though an initial prompt might be a good idea, with a highly visible “switch format button type”.

      4. There needs to be a meta boes and screen adaption for every post format for the text prompts on screen to place holder text. There could be post format descriptions added though that may be a little long winded. at the verr least the title Must change from add to post to add new standard post / add new video post etc.

      While the above criticism may come accross as a little harsh these are my initial reactions and they should be tempered by the fact that I do believe better support both for developers and users in the core when it comes to post-formats is fantastic, and a great step forward, just not in how its being approached right now, also that I see that its one hell of an undertaking.

← Older 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