The new issue queue workflow has been in place for over a month. It has prompted a lot more feedback from the community than during the Q/A period back in May. This feedback has been grouped together using the tag “D.o UX”, and it is clear that there has been a significant disruption to the contributor workflow.
Out of concern for getting some relief to the contributor community in a timely fashion without causing further disruption by deploying piecemeal changes, eliza411 (Drupal.org Software Working Group member) initiated a project in November to try to tackle the issues both thoughtfully but quickly, while still involving design, development, and end-users. The issues we saw were simply too large and interconnected to be tackled independently.
The project is limited in scope, largely run by volunteers, and is striving to adhere to a timeline that positively impacts the issue queue within the next two months.
Research & exploration
We looked into all the issues tagged “D.o UX” and found that most of the major/critical issues revolved around the workflow for editing issue metadata/adding files.
The major problem with a separate “edit page”, is that the "workflow" is disconnected from how contributors actually use the issue queue. They tend to read the latest comment, then go back and forth between the comment form, the last few comments (addressing arguments raised in them) and then often proposing something (e.g. a patch, image, status change) to help move the issue forward.
This workflow is not really possible anymore. You have to either write your comment on the issue page and copy it over to the “edit page” or keep both of them open and go back and forth between two tabs. We know that this cannot really be resolved with more quick fixes (e.g. placing more edit page links, having the meta block move along the scroll).
The new edit page also brings together a lot of good elements, the ability to hide files, the ability to describe your changes, the ability to both update the summary and add a comment, etc.
Therefore we focused on improving the main pain points:
- Address the usability of the node edit form (e.g. clutter created by the HTML hints (already fixed!))
- Figure out how to remove the disconnect between the workflow of a contributor and that of the system.
- Bring back the issue title in line with the bottom of the form
- Try to keep the simplicity of the comment form (considered a major win, for reducing the overwhelming effect of the issue queue).
We actually have a lot of data on how people use the issue queue (webchick was able to gather this through direct queries). Some of this data is interesting as a guide for elevating certain functionality over other.
In the 3 weeks before the upgrade...
Total number of unique participants in issue comments: 4,855
Total number of issues created: 6,553
Total number of issue comments created: 40,056
Total number of comments making changes to issue metadata: 25,420 (63% of all comments)
Most popular metadata changes:
- field_issue_status: 50,09%
- field_issue_files: 16,60%
- body: 10,01%
- taxonomy_vocabulary_9 [issue tags]: 6,10%
- field_issue_version: 4,00%
- field_issue_assigned: 3,70%
- node_property:title: 3,11%
- field_issue_priority: 2,16%
- field_issue_category: 2,05%
- field_issue_component: 1,53%
- field_project: 0,65%
In the 3 weeks after the upgrade...
Total number of unique participants in issue comments: 4,861 (+1.2%)
Total number of issues created: 6,248 (-4.65%)
Total number of comments created: 36,532 (-8.79%)
Total number of comments making changes to issue metadata: 20,645 (-18.78% from before, and now 57% of all comments change issue metadata)
Most popular metadata changes:
- field_issue_status: 40,75% (-9,34%)
- body: 21,07% (+11,06%)
- field_issue_files: 18,32%
- node_property:title: 2,95%
- taxonomy_vocabulary_9 [issue tags]: 2,86%
- field_issue_assigned: 2,75%
- field_issue_version: 2,54%
- field_issue_related: 2,13%
- field_issue_priority: 1,81%
- field_issue_category: 1,64%
- field_issue_component: 1,22%
- field_issue_parent: 1,11%
- field_project: 0,86%
We can see that overall the numbers went down. Issue status and files are the most often changed fields on issues, therefore we should make sure it’s very easy to update those. The body field (issue summary) is also quite popular and is now being edited much more often than before.
We spend a whole bunch of hours thinking and occasionally discussing ideas, going from floating headers, inline editing, just dumping the edit form inline. In the end we set down on exploring two options: tabs and fieldsets. One approach where we would bring it inline and place it behind a tab, the other where we would bring it inline and place it behind fieldsets.
This approach got a lot of positive feedback from the development team, because it would all be one AJAX load away. Using in a pattern like this is quite new on Drupal.org, but relatively common on the internet. The big advantage is we don’t actually confulute the UI at all, with the more intermediate/expert functionality. A big down side is that you will be moving in between two tabs to know the status of an issue, edit the summary and add a comment. These often connected activities would require back and forth between the tabs.
The fieldset approach got a lot of positive feedback from the different contributors we asked. Primarily because it brings back a familiar experience and extends it to cover issue summary / related issues. We saw that a lot of people liked it because you can see the issue status again, something a lot of people long for. There are a few cons to this approach most notably that it could easily overwhelm new people - because all of the settings are once again exposed.
We finally settled on a solution. And we propose to bring elements of the edit page back near the comment form and collapse them in fieldsets.
This design proposal has been reviewed by Bojhan, tvn, rszrama, mpotter, webchick, dww, YesCT, jhodgdon, alexpott. We’ve sought input from a variety of stakeholders (at least one representative from each of the following: core contributor, core committer, contrib developer, site builder, project manager).
The issue status is brought back in line using a fieldset. However the current design of the issue queue is slightly overwhelming and takes up a lot of space. By reorganising the elements, using “two columns” it is now easier to scan.
In addition to reorganising, the issue guidelines have been reduced to just one link, rather than several links throughout the form. This caused clutter, that made the form harder to scan. We propose instead to have one link, which makes it truly stand out.
This fieldset is collapsed by default, thus to not overwhelm beginners in our queue. We will need to figure out how to make this efficient in “remembering” the state for more advanced users.
The comment form has never really received much design work. The WYSIWYG buttons look out of place and are out of sync with the overall styling of Drupal.org. In our proposed redesign we revamped them a little bit and made them blend in more with the design. Using icons of the Libricon library ( https://github.com/ry5n/libricons ) .
In addition to that, the “filter tips” are reduced to just one line. A partial implementation of this already happened placing these tips in a collapsible fieldset.
Issue summary & relationships
We grouped together the issue summary and relationships. This is all meta information. We want to push this functionality more forward, because it greatly enhances the quality of discussions. Putting it close to the comment action, similar to how dreditor did this before the upgrade - should elevate this functionality much more than placing it on just the edit page. There are some concerns with this approach, see Discussion point 2.
We received a lot of feedback that the act of uploading a file was now too disconnected from the act of commenting. We moved this closer in-line but omitted the part about hiding and showing files. We believe that is a significantly more complicated interaction, that is often done by those who wish to fine tune the summary view - we believe this is best done in the edit form (especially given the height to which the file list can grow).
The text is slightly simplified, and a custom button is added to adhere to the styling of d.o.
We are very aware, this is still far from ideal. But it’s the first, quick step towards better issue queue. We are hopeful that next year, given Drupal Association’s commitment to focus on Drupal.org improvements and Developer Tools Leadership team (https://groups.drupal.org/node/368148) that is being developed by the Software working group, that we will gain a lot more resources to tackle the harder UX issues.
One of the concerns raised with this design proposal is that it buries the issue summary editing behind a collapsed fieldset, while one of the main points of the changes was to make issue editing front and center and encourage it more. It is very important to promote the idea of editing the summary, however with our current limitations we are unable to bring it closer. A suggestion was raised by xjm, to include inline editing with that allowing people to edit - where the summary actually is, instead of at the bottom. However after various back and forth between the development team behind Drupal.org this is too difficult to implement right now.
Another big concern with the current design proposal was performance. Loading fields from the edit form each time you open an issue can be expensive. However we received a lot of positive feedback from various contributors, while other approaches received less support. Given this fact, we would like to move forward with this design and wait for actual performance testing before jumping to any conclusions.
What we need now is your feedback! We created quick and dirty prototype, which you can try out on this development site:
Enter drupal/drupal in pop up window, to access the site. Enter username: bacon, password: bacon to log in.
Take a look at the proposal, try it out on the dev site, and please give us feedback on the following points:
- To what extend does this solve or not solve the current pain points?
- What is your first impression using it?
- Do you have any suggestions to improve the current design?
- Can we start implementing this design on D.o?
We would like to thank the various people involved in getting this off the ground:
- eliza411 for kickstarting this all, and providing feedback.
- mcrittenden for for conducting interviews and gathering stakeholders’ feedback.
- Bojhan for the designs.
- sanchiz for working on the prototype.
- tvn for working on the prototype, providing feedback on the design and this post.
- rszrama, xjm, drumm, mpotter, webchick, dww, YesCT, jhodgdon, alexpott for providing thoughtful and constructive feedback.