#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 trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision., 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 dogfooddogfood The practice of using one's own software, typically bleeding edge (trunk), thus "eating one's own dogfood". This also applies to using one's own APIs internally. 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 UIUI User interface. 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 ticketticket Created for both bug reports and feature development on the bug tracker.. 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 tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) 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. Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors., 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.tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.. 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 Networknetwork (versus site, blog) Adminadmin (and super admin) UIUI User interface. 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, multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site 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 trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. 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 pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” @jeremyfelt anywhere. #core-multisite is preferred. I’ll create a matching username to your wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party 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 #coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-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 bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. 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 SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. 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 ticketticket Created for both bug reports and feature development on the bug tracker. needs developer feedback. We really need these improvements to post-new.php for mobile.

#31187 Allow swiping the adminadmin (and super 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 patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. 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 tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) action links on small screens

This has a patch that needs CSSCSS Cascading Style Sheets. 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:

https://core.trac.wordpress.org/query?status=!closed&keywords=~make-flow

#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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 adminadmin (and super 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 UXUX User experience 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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., 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 adminadmin (and super admin) menus, on to the editor media buttons, these tickets note some of the annoying little UXUX User experience issues that impede flow on phones. Fixing these would improve our mobile flows significantly.

The logo headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. on the log in screen is too large a tap target
https://core.trac.wordpress.org/ticket/31185

Submenus can’t be dismissed on mobile.
https://core.trac.wordpress.org/ticket/29906

Hide Media Buttons on small screens
https://core.trac.wordpress.org/ticket/29989

Prevent device keyboard from displaying after selecting an image in TinyMCE
https://core.trac.wordpress.org/ticket/31162

Allow swiping the admin menu open and closed on touch devices
https://core.trac.wordpress.org/ticket/31187

If you’re curious about Flow and Visual Records, check out the sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. on make/flow, the Flow Glossary, and the #core-flow SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel.

#4-2, #flow, #mobile