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.

I’ll be kicking off weekly core UI meetings…

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.

I’ve just posted a potential CSS roadmap for…

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.

#core, #css

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.


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:

  • http://www.shaunandrews.com/wordpress/resize-media-library-thumbnails-on-the-fly/
  • http://www.shaunandrews.com/wordpress/toying-with-media-library-interactions/

I will be interim leading MP6 in a…

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.

#3-8, #mp6

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:

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.

Have made it through the second round of…

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.

#3-6, #post-formats

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!