#needs-screenshots, #has-screenshots, and multi-device dogfooding of visual change

I’m attempting to provide before and after screenshots for all (most) visual changes that land in trunk, on multiple devices. These screenshots are used in visual changelogs such as the Today in the Nightly posts. The goals of this effort are to increase awareness of our usability (particularly touch/mobile), make ui review easier, establish a visual archive, and dogfood visual change on multiple devices.

To create the Today in the nightly posts, I work my way through the latest commits looking for visual changes to UI. From the changesets, I visit the tickets. If the tickets don’t have before and after screenshots for both a desktop and a phone (at least), I take screenshots as I test. I upload those screenshots to the ticket. I comment on the ticket with any bugs I find in the process. I often find bugs, especially on phones. If I don’t have time to provide all screenshots, I tag the ticket with needs-screenshots so I can get back to it later. If I see flow problems while testing, I post a visual record to make/flow and crosslink it with the ticket.

If a ticket has at least one screenshot, I tag it has-screenshots. Once all screenshots are collected, needs-screenshots is removed, leaving has-screenshots.

Now that I have tickets with screenshots that are all tagged with has-screenshots, I collect the shots and publish them as “Today in the Nightly” using the tool we’re all making together, WordPress. The process of dogfooding all visual changes, taking screenshots as I go, and turning the screenshots into posts is fantastic recursive dogfooding that reveals bugs, bad flow, and mobile brokenness. Triage, recursive dogfooding, visual archiving, visual awareness, change awareness, flow awareness, and useful posts are products of this virtuous process. My pet names for these acts of recursive dogfooding and visual archiving are kibbling and visual oxygen (VizOx, a riff on the communication is oxygen mantra of p2).

needs-screenshots and has-screenshots are part of a post-commit lifecycle that hasn’t existed before on core.trac. Historically, once a ticket was closed as fixed, it was done. However, diligence remains. has-screenshots and needs-screenshots are applied after a ticket is resolved as fixed and are used as testing signals by flow patrol. We may need other post-commit workflow keywords, but for now I’m seeing how this has/needs pair works out for visual change testing.

If you’d like to help collect visuals, we want before and after screenshots on at least two devices, with one of them preferably being a phone. We’re increasing our mobile/touch awareness by testing and capturing all visual changes on phones. Provide whatever screenshots you can. The Flow Patrol team will handle the remainder. Developers, taking screenshots of your patches and commits as you test really helps ui/ux review and flow patrol. This process is an engine for empathy and awareness.

I’m focused on visual change and usability, but other teams with other focuses might want their own post-commit lifecycle keywords. Commit is not the end of the process.

Obligatory recruiting pitch: If you’re interested in nurturing a QA mindset in a continuous integration, continuous dogfooding environment, help the Flow Patrol team continuously dogfood flow. Some of our duties are listed in the Flow Patrol handbook. Ideally, every component and feature team has someone continuously dogfooding, patrolling flow, publishing visual records, and helping teams meet merge criteria.

#awareness, #dogfooding, #empathy, #flow, #has-screenshots, #kibbling, #needs-screenshots, #post-commit-flow, #vizox, #workflow

Help Test and Capture the Network Admin UI

One of the wider objectives of WordPress 4.3 is to improve on the Network Admin UI. This includes refining the experience on different device sizes. We first need to capture a baseline of existing screen flows and identify tickets from that.

We need help capturing this data. 🙂

Having access to a local, multisite WordPress installation is the preferred method, as you’ll have an easier time making changes, applying patches, and generally having control over the data. Here are some guidelines for testing locally:

Realizing that installing and configuring multisite locally can be a barrier, a test server is available for anyone to access. This test server has two network installations, one for subdirectory and another for subdomain. Data will be reset on a regular basis. This allows anyone to go through the various network admin tasks.

Both networks are running trunk as of about 20 minutes ago. I’ll be making an effort to automate the maintenance of that setup.

If you’d like a super admin account to these networks, leave a comment below or ping @jeremyfelt anywhere. #core-multisite is preferred. I’ll create a matching username to your wordpress.org profile name and set you loose to capture and break things at will. 🙂

Once you have a test network available, here are the things we need captured:

  • Add a new user to a site when the user does not currently exist as a network user.
  • Add a new user to a site when the user does exist as a network user.
  • Install, enable, and then activate a theme for a single site on the network.
  • Install a theme and enable it for use on a network.
  • Install and then activate a plugin for use on a single site on the network.
  • Install and then network activate a plugin.
  • Create a new site on the network.
  • Update a plugin.
  • Update a theme.
  • Edit the domain/path for an existing site on the network.

Once captured, it’s great to share all of the data on the Make/Flow site, with a description of the screens tested and the device/browser configuration. If you need access to Make/Flow to post your results, leave a comment here or in #core-flow.

Specific details on each of these screens should also be added to this spreadsheet that the overall Admin UI team is using to coordinate efforts. Feel free to capture one workflow or many.

If you notice a bug in the screens you have captured, or in the screens captured by somebody else, it should be reported. Ask in #core-multisite or #core-flow on Slack if you need any help.

#flow, #multisite, #testing

Mobile Flow Update

Here’s the state of the open mobile flow tickets we’ve been calling out in the jumpstart posts.

#29989 Hide Media Buttons on small screens

I’ve really wanted this one for awhile. There was some good design momentum, but we’ve faltered as we moved to implementation. This ticket needs developer feedback. We really need these improvements to post-new.php for mobile.

#31187 Allow swiping the admin menu open and closed on touch devices

This one has gained some momentum. We need code review and testing. I’d really like to land this one.

#29906 Submenus can’t be dismissed on mobile.

During the first NUX meeting, the importance of the toolbar was called out by several. The toolbar needs help on mobile. There’s a working patch on this ticket that needs code review. There’s another case to cover that needs discussion and eventual patching.

#29993 Media action links are cramped on small screens

This needs a patch refresh and more discussion.

#29992 Cramped tag action links on small screens

This has a patch that needs CSS review and testing.

#15930 Make trashed posts/pages still readable

This is a possibly very simple patch that will remove a lot of frustration from certain flows. Read about one such flow.

#31233 Dismissable admin notices

This isn’t really a mobile flow ticket, but I like it enough to tack it on here as bonus. There’s a first pass patch on the ticket already. I’d love to see this go somewhere.

More here:


#4-2, #flow, #mobile

4.2 Community Initiative: NUX Working Group

Amy Hendrix

Andrea Rennick

Beth Soderberg

Bob Dunn

Brian Krogsgard

Carrie Dils

Corey Ellis

Courtney Dawn

George Stephanis

Jan Dembowski

I’m excited to announce a new community initiative for the 4.2 release cycle: the formation of a new user experience, or NUX, working group.

More than 15 members of the wider WordPress community have already been invited to participate in the working group, though everyone is welcome to attend meetings and are encouraged to join in on discussions.

The group will be tasked with helping to identify common pain points new users might experience using WordPress. The hope is to (re)invigorate the conversation about making NUX a priority in core decision-making. We’ll work together to identify problems and recommend solutions.

The primary focus of the group — at least for the duration of the 4.2 release cycle — will be to brainstorm actionable goals, and make recommendations for incrementally improving new user experiences throughout the WordPress admin. These changes would likely include improvements to contextual help on various screens, improvements to the content of the Welcome Panel, as well as adjustments to many other established workflows in core interfaces including the installation process.

Large or small, recommendations that come from the working group will receive direct feedback from core team members, and give many new contributors an opportunity to participate in making WordPress better for everybody.

Jennifer Bourn

Julie Kuehl

Mika Epstein

Mike Hansen

Morten Rand-Hendriksen

Natalie MacLees

Ryan Boren

Suzette Franck

Syed Balkhi

Trace Levesque

The 20 community members initially invited to participate were selected based on their demonstrated experience in training or working with new users, and/or tailoring UX experiences. They include: Amy Hendrix, Andrea Rennick, Beth Soderberg, Bob Dunn, Brian Krogsgard, Carrie Dils, Corey Ellis, Courtney Dawn, George Stephanis, Jan Dembowski, Jennifer Bourn, Julie Kuehl, Mika Epstein, Mike Hansen, Morten Rand-Hendriksen, Natalie MacLees, Ryan Boren, Suzette Franck, Syed Balkhi, Tracy Levesque, and myself.

The first meeting for the working group will be held Tuesday February 10 2015 19:00 UTC in the #core-flow channel on Slack.

Anyone interested is welcome to attend or participate. Maybe we’ll see you there!

@sabreuse, @andrea_r, @bethsoderberg, @bobdunn-trainer, @krogsgard, @cdils, @zzramesses, @courtneydawn, @georgestephanis, @jdembowski, @jenniferbourn, @juliekuehl, @ipstenu, @MikeHansenMe, @mor10, @nataliemac, @rboren, @suzettefranck, @smub, @liljimmi.

#4-2, #flow, #nux

Improving Mobile Flow in 4.2

Over on make/flow, we’ve been flow testing core, posting visual records, and opening tickets tagged make-flow. During 4.2, we’re going to highlight a couple of these flow tickets every week, with an emphasis on mobile. Here is a small selection of mobile make-flow tickets to consider for 4.2. From log in, to the toolbar and admin menus, on to the editor media buttons, these tickets note some of the annoying little UX issues that impede flow on phones. Fixing these would improve our mobile flows significantly.

The logo header on the log in screen is too large a tap target

Submenus can’t be dismissed on mobile.

Hide Media Buttons on small screens

Prevent device keyboard from displaying after selecting an image in TinyMCE

Allow swiping the admin menu open and closed on touch devices

If you’re curious about Flow and Visual Records, check out the sidebar on make/flow, the Flow Glossary, and the #core-flow Slack channel.

#4-2, #flow, #mobile