Make WordPress Design

Updates from Helen Hou-Sandi Toggle Comment Threads | Keyboard Shortcuts

  • Helen Hou-Sandi 4:58 pm on September 17, 2015 Permalink |  

    Potential UI/UX projects in core 

    It’s not uncommon for both existing and potential contributors to feel like they don’t know what to work on. Let’s try listing a few UI/UX items that have come up on wishlists in this post, both as a temporal call for interested parties and to reference later. If you’re interested or have another frequently-requested item in mind, sound off in the comments or join us in the #design channel in the Make WordPress Slack.

    When changing UX, it’s important to be running user tests and surveys. These can be done lo-fi, such as with index cards or a questionnaire, or as high fidelity as using a functioning plugin and a user testing service. It’s also important to assume that it will take multiple iterations to get there and to avoid becoming too attached to a single approach.

    Publishing UX

    When running user tests for post formats during the 3.6 release cycle, one of the most striking observations was that a majority of users had a hard time locating the Publish button at all. Because it’s typically in the top right, it’s possible it’s not on the screen, and is very disconnected from the general content workflow of writing and then publishing. The most common idea is to put the buttons in the bottom bar of the editor, since it pins and makes sense within a writing flow. There are, as always, other considerations to make, such as post types without an editor or various post statuses (another problem in the current box – you can’t actually have a private draft, because it’s the same field in the database). This project would likely involve multiple approaches, storyboards, mock ups, and lots of user testing through all stages.

    Comment Management Overhaul

    A lot of strides have been and are being made in the Comment API behind the scenes, but we still have a generally dated comment moderation experience, from the list to the edit screen to the moderation screen shown when following a link from notification emails. This is a good project for a team to brainstorm on before attacking: What does a good comment management experience need? How do we accomplish that within WordPress?

    There are also some smaller tasks that could be tackled, such as UI improvements. For instance, right now comments are presented with an interface that is very similar to post editing and without much context. What if comments looked and felt like comments while editing (showing an avatar, a better general layout, etc.)? What kind of contextual information would be helpful to show?

    Small screen flow

    The admin adapts fairly well to small screens. There are some places where what’s critical or important on a given screen is overwhelmed by other items. Some particular offenders are the theme/plugin/media filters, filtering and navigation on content lists, and the additional buttons that often appear next to the “Add Media” button above the editor. The content in those areas stacks up and pushes down the primary content below, sometimes completely off the initial screen. We want UI to direct user focus to what they want or need to be doing, and these particular visual components are major offenders against that.

    Tickets: #32558 for the filter bar, #29989 for the media and related buttons.

    • Tom Ryan 6:13 pm on September 17, 2015 Permalink | Log in to Reply

      Much of WordPress’ future potential growth will come from new users and the current interface is unnecessarily arcane in many areas (It’s not anyone’s fault, it’s just evolved that way). Here are a few UX areas that could use some help in WP:

      1. Menu Hierarchy – Need a top to bottom review of menu consistency throughout WordPress. The original menu structure was developed when WordPress was mainly a blogging platform. It’s very cumbersome when you are trying to develop a full blown site in WP, rather than just publishing a blog post.

      2. Nested Menuing System – The current menu system breaks down after you get more than one level deep. Then yous have the Customizer, which has a completely different menuing system. This has lead developers to create their own menu systems, which makes the WP UX inconsistent from theme to theme. WordPress needs to provide theme and plug in developers a way to do all of their interface within the WP menu system, rather than having to create their own.

      3. Menu Consistency – This is a related to #2 above. WP has the top menu bar, the admin menus and the Customizer menus, which all feel like they are completely different products. Many of the settings overlap and make no sense to end users.

      4. Integrate “Page Preview” Into the Interface — Currently the Customizer is essentially the “page preview” feature of WP.. Rather than being integral to the main interface, it jolts you into a completely different interface, which overlaps in functionality with other areas of WP. There are ways to integrate the Customizer functionality into the main interface so that it WP becomes a more cohesive product.

      5. Settings Organization — Ensure better consistency of how to adjust settings. Sometimes plugin developers will put their settings under Settings, sometimes it will be in a new top level menu. Sometimes you can get to settings from the plug ins page, sometimes you can’t. Many of the WP core settings have the same issues. There should be a more clear delineation between standard settings and setting added by plug ins. It often hard to find the settings you wan to change because the Settings menu is so large and not organized into core and plug in settings.

      Currently, using WP to create and manage web sites is a “less than delightful experience” The changes above would really go a long way to clear up some of the cruft and make the WP interface easier to work with.

      I’m not a developer, but I would be happy to help with the process in any way I can.

      • allstar 4:10 pm on September 18, 2015 Permalink | Log in to Reply

        Just as you have inactive widgets it would be nice to have inactive menu items as well. There is some overlap when you start to look at Menus and Widgets, both have locations, active, inactive and order. Differences being static-sih individual menu items versus a widget’s instance
        functionality and linear widgets versus multidimensional menus.

        I’m stating something I see in an effort to be constructive. I know a merge would be difficult and an overlap of functionality complicated but it offers a possibility of having similar interfaces and for new people less learning can only be good.

      • dlouwe 12:25 am on September 19, 2015 Permalink | Log in to Reply

        A personal pain point somewhat related to #2 is the method for removing menu items. One or two items are simple to remove, but trying to remove 5+ is a tedious nightmare. A way to bulk delete menu items would save so many headaches.

        Also in regards to #5, this is likely something that would need to be put into the plugin submission guidelines and enforced by the plugin review team, rather than something implemented in core. I can’t imagine a good way to prevent plugins from modifying the admin menu however they please, so this kind of organization would need to happen at the community level.

    • raulalgo 6:36 pm on September 17, 2015 Permalink | Log in to Reply


      I’m fairly new here but I’ve been willing to collaborate for a while. I’m UX designer with big experience on mobile and long time user of WordPress.

      I’ll be happy to give a go at some elements on that list.

      Is there any priority among them?

      • sanit.tmg 9:58 am on September 19, 2015 Permalink | Log in to Reply

        hello sir… i am an IT student.. and i wanna learn about this word press but iv’e tried all videos, tutorials and much more but haven’t got my answers… sir will you plzz answer my questions sirr?

    • Cătălin Dogaru 7:12 pm on September 17, 2015 Permalink | Log in to Reply


      I would be interested in working on #22058 (alternative UI for the Background Image section in the Customizer) and #23120 (provide visual feedback on saving widgets). Some progress has already been made, it would be interesting to take things further.

    • Stephen Rider 1:42 pm on September 18, 2015 Permalink | Log in to Reply

      In response to Tom Ryan:
      You have a lot of good ideas, but I would have to strongly disagree with separating plugin settings from Core settings. I got involved with WP back around v2 or so, and at that time there was a widely accepted idea that plugin settings should all go under the Plugins menu. It was a huge mess. A few people (myself included) began championing the idea that plugins should me integrated cleanly. The best interface for a plugin is to be made in a way that you might not realize it isn’t Core.

      I totally agree with you that plugins should consistently link to their own Settings screens (if they exist) from their entry in the Plugins page. I believe I wrote the first tutorial about how to do that back in 2008: http://striderweb.com/nerdaphernalia/2008/06/wp-use-action-links/

      It would be nice to have some consistency, but at the same time I would hate to bind developers’ hands. It’s more a question of education.

      • Tom Ryan 5:37 pm on September 18, 2015 Permalink | Log in to Reply

        Thanks for your feed back Stephen!

        With respect to separating out plugin-added options, here is the issue I’m trying to address: The WP interface can look VERY different from site to site, depending on which plugins are installed. This makes the WP interface non-standardized and hard to find the things you use on a regular basis. I can understand your point about making the plugin integration seamless, but often settings are all over the place for no good reason. I have one theme that requires 5 other plugins and my top level menu is a mess of options I never use.

        Here is an example of a very a simple interface tweak that could help quite a bit: List all the core Settings items first, then a line, then list all the additional plugin settings below that line. That way, it’s still on the same menu, but you can always find the core WP items in the same place.

        By the way, many of the plugins I use should not be top level item; once they are set up, I only need to access them occasionally. It would be better if they were more like the themes page where you could see icons, for the installed plugins and click on them to configure them.. Maybe to have the best of both worlds, you could include a checkbox to enable the user to add a plug in to the top level menus. That would keep the top level WP menu clean by default, but allow users to include it in the top WP menu if they need to access it frequently.

    • Morten Rand-Hendriksen 4:11 pm on September 18, 2015 Permalink | Log in to Reply

      There’s also the ImageFlow project which looks to change the experience of adding and editing images.

    • FolioVision 4:53 pm on September 18, 2015 Permalink | Log in to Reply

      Hi Helen,

      Thanks for the suggestions. We’ve written a plugin for front end comment moderation (and now caching) called Thoughtful Comments. It works with all themes. We’d be happy to help add front end moderation to WordPress. I’ll take a look at backend moderation and see what might might be improved there.

      Hi Tom/Stephen,

      Plugin settings really must be put back into the Settings Menu and the Tools Menu. Each plugin demanding a top level menu item for itself is totally out of control and make most client sites look almost unusable now. 90% of plugins can get by with a Settings entry and (where necessary) a Tools entry.

      Forcing plugins to link to their own setting pages would be very helpful. I’d love to bind developers hands as consistency is the hallmark of great UI (think Mac OS 7 to 9 and Apple OS X vs Linux/Windows). Adding a requirement to consistently link to setting pages would make me very happy.

      Alec Kinnear

      • Tom Ryan 5:44 pm on September 18, 2015 Permalink | Log in to Reply

        > Each plugin demanding a top level menu item for itself is totally out of control and make most
        > client sites look almost unusable now. 90% of plugins can get by with a Settings entry and (where
        > necessary) a Tools entry.

        Thanks Alec, I agree with you 100%!

        If you think it looks bad as WP developer, can you imagine what it’s like for someone trying to come up to speed on WP for the first time? The WP learning curve is way to steep and long at this point.

        I’m hoping that the UX group will be able to address many of these issues to make WP a more accessible and easy/fun to use product.

    • fredhead 9:56 pm on September 21, 2015 Permalink | Log in to Reply

      I’d be interested to participate in the Publishing UX exercise. From my experience, in most cases simply floating the Publish button at the top as I scroll down the add/edit screen would work wonders for me. I hate having to always scroll up and up just to save my edits.

      FWIW, as a user and someone who sets up WP sites for other people, I totally agree with the discussion about adding flexibility to the WP core navigation as well as the need to provide more guidance about using Settings and Tools as the default location for plugin settings and functionality. The number of top level menus for lightly used plugins is way out of control in my experience and view.

    • th23 8:18 am on September 22, 2015 Permalink | Log in to Reply

      Really great to see, that the team is always looking how to (further) improve the user experience and interface :-)

      I just yesterday submitted an idea on how to optimize the flow creating / editing a gallery – based on some feedback/ observation of a few friends using and struggeling a bit with finding their way around:

      In case somebody can point me to what to do next, I am happy to contribute!

    • thomask 7:49 pm on September 30, 2015 Permalink | Log in to Reply

      I would like to point the WP design/UX community to my ticket https://core.trac.wordpress.org/ticket/33931 where i have prepared very detailed wireframes for possible redesign, unification and simplification of many WP pages. I have also described there many problems with unnecessary differencies that might baffle the users and that harden the translation and modification.

  • Helen Hou-Sandi 6:43 pm on May 11, 2015 Permalink  

    I’ll be kicking off weekly core UI meetings again, starting this Thursday, May 14, 2015 13:00 UTC-4 in the #design Slack channel.

  • Helen Hou-Sandi 7:08 pm on December 19, 2014 Permalink
    Tags: ,   

    I’ve just posted a potential CSS roadmap for core over on Make/Core. For those of you who don’t follow along there, I’d love your eyes and thoughts.

  • Helen Hou-Sandi 12:56 am on June 20, 2014 Permalink
    Tags: 4.0   

    Call for screenshots: Web store experiences 

    We are taking a look at plugin discovery workflows in 4.0. To that end, we’re looking for screenshots of various web store experiences to study as comparable art, particularly in terms of how users are enabled to determine and look for what they might need/want, and what data is shown for users to use in making a final decision. We’ve identified the following as potentially being helpful – please post a comment claiming an item, and then post screenshots, preferably on a service that will not disappear in a year. Can give access to upload items here if desired.

    Important screens to capture are: landing pages (store home, top-level groupings), search results, browsing of listings, and single listing. If an item listed below can be accessed both on the web and natively within the app, cover both. If you’d like to cover something that isn’t listed, please also post that in a comment.

  • Helen Hou-Sandi 3:02 pm on September 20, 2013 Permalink  

    Update: Media Library Grid View 

    Slowly getting rolling with updates, but after @shaunandrew‘s initial proposal, I’ve agreed to lead the plugin for a Media Library Grid View. Our weekly meetings are Fridays at 15:00 UTC in #wordpress-ui. Plugin development will proceed for the time being on GitHub.

    @shaunandrews has also done a couple of screencasts of some experiments:

  • Helen Hou-Sandi 7:51 pm on August 19, 2013 Permalink
    Tags: ,   

    I will be interim-leading MP6 in a mostly-project management capacity while @iammattthomas is on sabbatical. We’ll resume weekly open meetings in #wordpress-ui next week, Monday, August 26 at 18:00 UTC.

  • Helen Hou-Sandi 2:10 pm on February 12, 2013 Permalink  

    Discuss: Icons 

    If you’re running trunk, you’ve probably noticed some new icons being tried on for size. There’s ticket #23333 on Trac for them, but it’s quickly becoming overwhelming and I’d like to give design-minded folks a chance to focus in on the icons themselves and discuss without as much distraction regarding the rest of the admin (see #23415, which absolutely goes hand-in-hand), SVG-vs-font-vs-plugins oh my, developer rabbit holes, etc. Trac just isn’t a great fit for some of the discussion, anyway.

    I’m seeing a few focal points for discussion:

    • Icons themselves, from a graphic design standpoint. What works, what doesn’t, what might make this style of icon “WordPress-y”, other things that I personally (as a non-designer) can’t prompt very well.
    • What kind of treatment flat/vector-style icons need to really work in the WordPress admin, e.g. hover states, colors, etc. Size is also perhaps a part of this, although do keep in mind that we can play with the sizing and styling of other elements as well.
    • What other icons we need beyond the admin menu – post formats is definitely one, and perhaps we can also start thinking of other places that could use icons as a part of the visual vocabulary.

    Some helpful links from the 88 and counting comments on the ticket:

    • Helen Hou-Sandi 2:17 pm on February 12, 2013 Permalink | Log in to Reply

      I’d particularly like to see @empireoflight and @melchoyce combine forces and work to create a more complete set for use around the admin – there are elements in each set that seem very strong to me. Of course, I would think that any contributions are welcome; I’m just going with what’s been done so far so things keep moving.

      Post formats needs an icon for each of the 10 formats – not sure if standard should just use the regular pin icon or if there are any other icons than can be reused. I’m also seeing where an icon could be used in the inputs/textareas themselves – URL, quote, quote source, embed code/URL, image, and gallery. @melchoyce‘s wireframes used icons and placeholder text rather than visible labels, so I’d like to at least give that look a shot. For the record, so nobody jumps on me, in my current patch, labels are still there, just not visible, and we’d need to keep it that way for accessibility.

    • esmi 2:43 pm on February 12, 2013 Permalink | Log in to Reply

      Speaking from a purely design/usability pov, I find the darkness/heaviness of http://bendunkle.com/wp-admin-icons/ somewhat intrusive when it comes to readability. Any chance we could lighten them (a la the current icon set) and then revert to a heavier/darker version hover and onfocus? That might also sidestep the accessibility issues of using red as a highlight color. The Post and Appearance icons look rather similar to me at first glance. Perhaps the Post icon could be swapped out for the more stylised pin in https://core.trac.wordpress.org/attachment/ticket/23333/icons-18-24-32.png

      • Chip Bennett 1:35 pm on February 16, 2013 Permalink | Log in to Reply

        That\’s my biggest complaint thus far: Post, Appearance, and Plugin icons are all way too similar. Also: I don\’t get \”paintbrush\” = \”appearance\”. (I assume that\’s what the appearance icon is?) IMHO, a paintbrush implies \”format\” or \”color\”, not header/background/Theme options.

    • @mercime 5:23 pm on February 12, 2013 Permalink | Log in to Reply

      I’m all for the icon fonts by Ben Dunkle. Instead of making heavy/solid icon fonts, how about making it outlines instead for a cleaner look? Compare bbPress and BuddyPress outline icons with solid wp-admin icons https://mercime.files.wordpress.com/2013/02/wp-admin-buddypress-bbpress.png?w=145

    • Empireoflight 7:53 pm on February 12, 2013 Permalink | Log in to Reply

      @mercime, the outlined look doesn’t translate to an icon font very easily; hence the solid icons. However, it gives me an idea for an “open face” icon set, as a variation on the theme.
      As for the icons looking too large, the intention is for more padding to be added but we’re playing w/that. They do seem a bit dark, but the great thing is you can quickly change the color w/css.

    • Hugo Baeta 12:14 am on February 13, 2013 Permalink | Log in to Reply

      What if the icons were a very light embossed look? (it could still be an icon font, with text-shadow to create the effect).

      I am with the other comments I’ve seen, the icons look too bold there. One personal opinion about this style of simplified shape is that it really looks better if you keep simplifying, maybe even make them smaller?

      On a discussion with @koop he made a mockup of a super minimalist menu, removing the divider lines and adding more padding to the items. It felt so airy and light, I loved it! I’ll try to reproduce it and make a screenshot for y’all.

      • Hugo Baeta 7:23 am on February 13, 2013 Permalink | Log in to Reply

        ok, talked with @koopersmith before posting this here. One important thing to take note is that I don’t intend to distract from the discussion about the icons with the other changes showed in this screenshot. But it’s an interesting new way to look at the menu. Also keep in mind that the menu simplification is not my doing, but Koop’s and I love it so much I use it on my installations 😛

        This said, here’s what I did: ( http://cl.ly/image/0a3S0a2G053I )

        • reduced the opacity of the icons
        • increased the margin around them

        What do you think?

        • lessbloat 8:00 pm on February 14, 2013 Permalink | Log in to Reply

          Really loving this @hugobaeta. Nice work with that screenshot!

        • lessbloat 8:10 pm on February 14, 2013 Permalink | Log in to Reply

          Here’s a before and after comparison:

          There is so much less for your brain to process with the one on the right. Though I’d argue that we could probably go even smaller with the icons there.

          • Ipstenu (Mika Epstein) 8:36 pm on February 14, 2013 Permalink | Log in to Reply

            I think that size is really good. Smaller and you start running into readability issues with people who don’t have aces vision. (And telling me to +1 font size in my wp-admin is a crap answer, by the way.) We COULD go smaller, but I think this is a really nice balance between size and all-around readability.

            • lessbloat 2:38 pm on February 15, 2013 Permalink

              As a clarification, I said smaller icons, not smaller text. 😉 Smaller icons would command less attention and actually improve readability for the text.

            • Ipstenu (Mika Epstein) 4:37 pm on February 15, 2013 Permalink

              I dunno, visual ‘readability’ of icons also suffers at smaller sizes. This icon size is really perfect. I feel like I’m not missing out on details and I can clearly see what everything is easily. If you made the images smaller, the thing lines in the images themselves would lose distinction.

            • Hugo Baeta 5:06 pm on February 15, 2013 Permalink

              My point with going smaller with the icons was also to go simpler, reduce detail. If you look at the old icons, they look “smaller” and more elegant comparing to these new ones, because the new ones are a solid block instead of gentle lines with highlights.

            • Ipstenu (Mika Epstein) 5:14 pm on February 15, 2013 Permalink

              Hugo, the current ones are so small for me I have a hard time noticing the visual diff between Feedback and Appearance today. Smaller images will lose pattern recognition ability (I don’t know if that’s the right term…) and make it harder to tell everything apart at a quick scan when you collapse the bar. A lot of people cannot collapse the sidebar now because they lose the ability to tell what’s what when they do.

              Since we’re already removing the detail and going with flatter images, which I like by the way, we have to make sure to keep them distinct. I feel smaller will lose that.

            • Hugo Baeta 5:18 pm on February 15, 2013 Permalink

              and, actually, the old ones ARE smaller! Here’s the evidence:

            • Hugo Baeta 5:28 pm on February 15, 2013 Permalink

              Fair argument @ipstenu. But if the icons are getting bigger, then the text also needs to follow that to keep proportion. Maybe that’s exactly what the menu needs… do you guys remember how clear the old (pre 2.7) menus were? yes, the horizontal blue bar at the top!

              quick mockup with inspector:

        • Mel Choyce 12:51 am on February 21, 2013 Permalink | Log in to Reply

          Late to the game on these, but just wanted to comment on how much I like this layout & grouping. I think we could play with spacing and division between content & settings a little more, but this feels like a much nicer fit for the new icons.

      • Drew Strojny 2:56 pm on February 14, 2013 Permalink | Log in to Reply

        One personal opinion about this style of simplified shape is that it really looks better if you keep simplifying, maybe even make them smaller?

        I haven’t read through much of the discussion to date, but this is the first thing that jumped out at me when I updated and saw the current flat icons. While I love them, they look disproportionately large and out of place to me in the current menu. +1 for making them smaller and/or re-evaluating the proportions of the surrounding elements. I think Hugo / Koop are on the right track with the screenshot.

        I also think @lessbloat echoed similar comments in the Trac ticket and provided a screenshot of a non-gradient version with more spacing, which I also think is on the right track.

        I’m also not a big fan of the white hover on the current background. Not enough contrast. I’d say a subtle change to a lighter grey when hovering would work well.

    • Helen Hou-Sandi 6:22 am on February 13, 2013 Permalink | Log in to Reply

      Something that came up while I was talking to @koopersmith about something else entirely – the toolbar icons seem to really work well in terms of language and staying power, and maybe even personality, as minimal as they are. The admin menu icons in trunk clash somehow – perhaps it’s the roundness, perhaps it’s something else. That part I can’t quite quantify. What I’m trying to say is that I think the existing toolbar icons are an important starting influence :) The admin menu icons are less a cue and more a unique reference, so they do function a bit differently, but having two different styles of vector icons is going to give a disjointed experience.

    • Archetyped 8:37 pm on February 14, 2013 Permalink | Log in to Reply

      Thank you for starting this discussion @empireoflight and thanks to @helen for bringing the discussion out of Trac (is it okay to say it’s chaos in there?).

      I’m curious what the “official” goal for this potential icon reboot is? “Scalability and utility” (as put forth by @empireoflight) are good reasons, but are they a higher priority for WP than things like branding and personality?

      These icons feel rather “generic” to me. While the official icons have their flaws, they are unique and give WP a particular flaire that helps to identify WP as “different”.

      It’s not about flat vs shaded, it’s about identity. Sure, generic icons would definitely make it easier to implement WP as a white-label CMS for clients, but I for one would feel the loss of a certain amount of whimsy and fun that drew me to WP those many years ago.

    • Chip Bennett 1:41 pm on February 16, 2013 Permalink | Log in to Reply

      Are these icons being tested with the menu both expanded and collapsed?

      Most of the icons make sense, but in the collapsed state, the old \”Appearance\” icon is far more meaningful than the new one, IMHO.

    • lessbloat 4:32 pm on February 21, 2013 Permalink | Log in to Reply

      Was chatting with @joen about the icons, and he mocked up:

      As a riff on some of the icons styles. Posting it here to add to the existing discussion.

    • Empireoflight 12:40 pm on February 22, 2013 Permalink | Log in to Reply

      I did a ton of tweaking, both the images and css last night. Icons are a bit smaller still and include an orange hover state (it should be orange like the text, not white). It’s pretty much what we currently have in 3.5 with new icons. I used @melchoyce ‘s suggestions for the angled plug; Mel, let’s talk soon about the post format and other icon.s I added an active state into the menu sprite. I’ll submit it to trac today, but here’s the preview: http://cl.ly/image/2j0a3F2W271b (how do I insert images directly to this thread?)

      • Hugo Baeta 9:36 pm on February 25, 2013 Permalink | Log in to Reply

        Hey @empireoflight – I like what you did there, the size reduction makes them feel a bit more proportional. And the all gray treatment (including text) also makes the new icons fit better.

        To include an image inline, just write the html for it <img src="… 😉

  • Helen Hou-Sandi 8:50 pm on February 4, 2013 Permalink  

    Round 3 of post format UI user testing… 

    Round 3 of post format UI user testing, using Crowd Favorite’s code for UI and display fallbacks along with San Kloud as the theme.


    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 1: http://wpusertesting.com/videos/DC7-5.mp4

    Note: there are a lot of comments in the video that are interesting but not relevant to the task at hand. Leaving out for the sake of brevity.

    1. Fine.
    2. Fine.
    3. Notes that that that was not where he was expecting to see the Publish button; seems to also feel that the box is overfull with all the options.
    4. Notes that it isn’t a preview so much as just viewing what you did.
    5. Finds the format tabs and chooses Image. Saves the image but not sure he needs to. Doesn’t see anything specific to an image post in the UI and finds it confusing. Goes to Add Media and finds the Insert from URL panel. Fills in the extra fields for caption, etc.
    6. Wants to watch the video in the editor.
    7. Notices that there’s no http:// in the URL field. Discovers that without http:// the display fallback code just shows “View on”, which is confusing.
    8. Wants a clear field for the quotation itself and for the field layout to reflect how it’s usually seen in the front. Notes that there’s no indication about whether or not the source URL field is required. On preview, notices that the display cuts off a word – thinks it shouldn’t truncate words, but would really rather be able to change the title.
    9. Uses the “Add images” button. Discovers shift-click. Wonders why one is blue – maybe the cover of the gallery? Doesn’t see a way to drag/drop them into a different order. New media modal inserts into the content editor rather than updating the Gallery Images area.
    10. Notices a post called “47” – the image post that didn’t have a title. Thinks the title should have been the image caption he specified.

    Overall observations:

    • He’s opinionated :) Watch the whole video to see.
    • The output fallback seems to be helpful. Otherwise the theme wouldn’t show any of the data he entered and then who knows what the opinion might have been.
    • What other fallbacks might need to be in place for auto-generating of titles?

    Test 2: http://wpusertesting.com/videos/DC7-6.mp4

    1. Fine.
    2. Had to click the New menu in the toolbar to get the dropdown. Not sure what was going on there.
    3. Also has to scroll around briefly to find the Publish button, but doesn’t seem concerned about it.
    4. Fine. (Still the toolbar dropdown issue.)
    5. Chooses the image format tab. Just pastes the image URL into the content editor; isn’t clear where it was supposed to go.
    6. Puts the video URL in the specified fields; notes that there wasn’t such a field for image.
    7. Adds title to a regular post first, then switches to Link. Types URL with www but without http://.
    8. Fine.
    9. Uses the “Add images” button. Discovers shift-click. Uses “Insert into post”, as it’s the only option. Same effect as the previous test.
    10. Doesn’t see my favorite website, is afraid to click the link. Notices that the picture isn’t there. Video post is missing but she doesn’t seem to notice.

    Overall observations:

    • Found it easy to choose different formats for her blog post. Found WP overall to be easy to use, even with some of the things that seemed to not quite work.
    • This time, both users were concerned about the ordering of the images in the gallery.
  • Helen Hou-Sandi 4:03 pm on January 31, 2013 Permalink
    Tags: , post formats   

    Have made it through the second round of user testing videos for post formats (thanks, @lessbloat). These were on core as-is, using Twenty Twelve as the theme. Should have switched to San Kloud to enable all formats, but it actually may not have made much of a difference for these. There’s a third round still to watch and annotate.


    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 1: http://wpusertesting.com/videos/DC7-3.mp4

    1. Fine
    2. Fine
    3. Takes a moment finding the Publish button, but otherwise fine.
    4. Fine
    5. Notices it says nothing about a title; adds one anyway. Uses Add Media -> Insert from URL.
    6. Again goes to Add Media -> Insert from URL. Inserts the video, which gets linked. Doesn’t work for oEmbed to have it linked :( Again adds a title herself
    7. Again goes to Add Media -> Insert from URL, but says she doesn’t think she’s doing it right. Tries to click the link that’s inserted in the editor to check if it goes to the right place.
    8. Corrects then to than 😀 Adds it as plain text in the editor.
    9. Add Media -> Media Library (woo!) Selects the three images using multi-select and inserts them all into the post.
    10. Checks the sesamestreet.org link, which works. Then she closes the tab, so it’s over before getting to see some things like video.

    Overall observations:

    • She never once noticed the post formats metabox or wondered why the instructions were telling her to write blog posts of various kinds.
    • Not having a title bothered her a bit, perhaps because it looks so important/required.
    • The media modal certainly seems usable/comfortable, as she kept returning to it and was really quite handy with it.

    Test 2: http://wpusertesting.com/videos/DC7-4.mp4

    1. A little copy paste mishap, but otherwise fine
    2. Fine
    3. Scrolls to look for the Publish button, then has to digest the whole Publish metabox to find the button. After publish, does not expect to stay on the edit screen, because she’s “done” / ready to move on.
    4. Fine
    5. Opens the URL and drags the images over to the other tab directly and drops into TinyMCE. Observes that more and more things on the computer support drag and drop, so it’s a familiar mechanism.
    6. Looks immediately for embed code. Copies and pastes code into the Visual editor; observes that it doesn’t show her what it will look like. Says that she would preview the post, but the test doesn’t say to do so, so she doesn’t. Wonders if there’s another way to embed; finds the format metabox. Selects “Link” and updates. Notes that changing and updating doesn’t seem to make anything look different. Wonders what it’s for – maybe a layout, but doesn’t make a difference to her.
    7. Remembers the format she discovered in the last task and selects it. Notes she wants selecting a format to come before adding information (not sure if flow or layout wise); because it’s under Publish she doesn’t notice it, and considers anything under there to be of use after publishing. Says she always previews/checks posts for formatting on her own blog :) Wonder what she uses…
    8. Selects format – “What is the difference here, exactly?” Is really expecting the editor area to change with selecting a format; wonders what the value even is.
    9. Selects Image format, presumably because Gallery isn’t available in Twenty Twelve. Looks around and eventually finds “Add Media”. Figures out to use shift to do a multiselect. Inserts them all; wonders if she did something wrong but notices that it’s formatted/shows images in the editor. Now wonders if Add Media should have been used for embedding the video to get a nice formatted view.
    10. Notices the “Link” flag on that post, but it doesn’t seem otherwise formatted. Considers lack of formatting in various posts to be a consequence of her mistakes.

    Overall observations:

    • Whenever a user thinks that it is their mistake that something didn’t make a difference or work right, we really need to look at how to fix that – to help them avoid the mistake in the first place and feel confident that they know what to do or can figure it out.
    • This could have been one of us testing such a feature. Her observations are all very astute – there’s no value in selecting a format when editing, which was further enforced by the theme display; the location on the screen is counter-intuitive to workflow; oEmbed is buried/not discoverable (and not just by WP); creating galleries as opposed to batch insertion is not something naturally thought about; and “Add Media” quickly becomes a familiar place to do more than insert images or upload files.
  • Helen Hou-Sandi 10:26 pm on January 21, 2013 Permalink

    3.6 Core Development Cycle 

    If you’re looking to contribute to core UI, you’ll want to keep an eye on Make/Core, as we’re shifting our thinking of core UI contributions to being an integral part of various areas of core rather than a separate group/workflow/etc. All of the planned features for 3.6 include UI components and participation in them is highly encouraged. Office hours are either set or being set for each team and will be held in #wordpress-dev, so as always, feel free to join discussions as they’re held, whether in IRC, on the Make/Core P2, Trac, or elsewhere. Regular updates/summaries will be posted on that P2.

    Also, as you’ve probably noticed, we haven’t been having weekly UI group chats, due to a combination of the end of the 3.5 cycle and a shift in how we’re thinking about this group. For more, see @jenmylo‘s comment: https://make.wordpress.org/ui/2012/11/16/coming-soon-weekly-updates/#comment-22558. The #wordpress-ui IRC channel is always open, and we can use it for UI-focused discussions if #wordpress-dev is otherwise focused on something, but let’s all get comfortable in #wordpress-dev, too :)

    One last thing: this shift in thinking also applies to Trac. Right now there is a “UI” component, which is a bit of a mess and ultimately not a great help for watching for tickets of interest, as UI-related items are just as often found in other components. We’re working on emptying the component out by moving things into more relevant components (Administration is a good fallback if you don’t see another) and, for the time being, adding a manual keyword of “ui-focus”. In moving things, it’s also good to just be reviewing the issue the ticket raises and testing any patches provided, marking as needs-refresh if it doesn’t apply or closing the ticket (or making it with the close keyword) if it’s no longer relevant. There are almost 3500 tickets open right at this moment, which is an unmanageable number that leads to things getting lost. Let’s help get that down while we get Trac organized. Here’s the list of tickets in the UI component, and the newer list of things tagged ui-focus. If you’re not Trac-minded, don’t worry. If you are, we’d appreciate the help!

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc