I'm an issue queue power user. I've maintained large projects for years now, closing out and sorting thousands of issues. My process starts every day with me going through my personal tracker and opening every link with new comments. I read the comment and engage with the commenter(s), recategorizing issues or updating their statuses all the while.

Faced with the new changes, I was immediately thrown by the fact that I could no longer find the issue status when reading the most recent comments and wanting to update the issue accordingly. I browsed to the top of the page and couldn't find it there either. All I could think to do was to actually go to the edit page to find it. I even left a despairing comment about this - what was I to do, I wondered?

Looking at the page further, I finally found the issue status is the title of a table holding metadata about the issue. I was very confused, because I read that table several times trying to find the familiar "Status" row, which everywhere else was always next to the "Category" and "Priority" properties.

I think it's a mistake to have the title of the table that appears to be about metadata to be an actual value of the metadata - and that without a label. Status should be another row in that table - make it the first row if you want and keep the color coding, but give it a label and treat it like all the other metadata there. The inconsistency is jarring.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Dave Reid’s picture

I think this will just take us some mental retraining. I admit I find it confusing that it's not in the rest of the 'details' because my mind doesn't think a 'header' on that block is important information.

joshmiller’s picture

I think this could cause even more confusion with screen readers. Headers are typically descriptive of a chunk of information.

"Active" does not convey why Project, Component, Category, and Assigned are grouped together. Even more confusing, it does not convey that this "informative" header can change often. Headers should remain like anchors to information, and if something changes, the data should change and the header should clearly mark out the group of things that can change.

Fancy way to save space, but fail for usability and most likely fail for "Cognitive Web Accessibility" http://wave.webaim.org/cognitive (see the section on focus and structure).

joshmiller’s picture

FileSize
109.31 KB

Proposed design solution

Proposed change that would help solve the weirdness. There are other things I'd like to see changed about the design, but that is likely a different issue.

Bojhan’s picture

I am not sure, I think I agree with @David that this is a mental model shift. There are other issue trackers that present it similarly. And the fact that you are looking for "Status" in the same list as the other items is led by the way this was previously presented.

I'd like to give this some time, because it is a very big change and that affects behaviour. It does not necessarily mean that its bad for usability, something not having a label is not immediately a #usability fail.

Screenreaders can be served by adding a element invisible heading. We do that in many other places already.

klonos’s picture

I like the alternative design proposed in #3 (adding the "Issue Details" as a heading, moving the status along with the rest of the table rows and adding a "status" label to it), but I still would like it to have the background status colors we use in the queues instead of the gray.

tvn’s picture

Project: [Archive] Drupal.org D7 upgrade QA » Project issue tracking
Version: » 7.x-2.x-dev
YesCT’s picture

FileSize
85.61 KB

I'm not sure which of #3 is better (I suppose I prefer the way it is now), maybe there is data from the past design stage we can look into.

If is is confusing, maybe we could use "status:" and spacing like the info below it, keep the colors (which I really like)

Bojhan’s picture

I am not sure about this, it convolutes the design and I am not sure if its really a big problem. There is always a downside to any design, this is a relatively small downside but makes it look cleaner.

swelljoe’s picture

FileSize
65.98 KB

How do I get this behavior in my own project_issue installation?

I strongly prefer the way it is presented here at d.o (which looks like the proposal in #3), but in my project_issue installation it looks like a broken combination of the old and new way, e.g., it looks like the screenshot I've attached, which is kinda the worst of all possibilities, with a nonsensical big "Issue status" label at the top (without actually giving the status). I can remove the status from the list of items underneath, but can't figure out where the "Issue status" title is coming from or how to make it look like the d.o instance.

joshmiller’s picture

@swelljoe - Chances are pretty high the customization to the project module can be found in the drupalorg module. Linked below is the git repo tree for the relevant module:

http://cgit.drupalcode.org/drupalorg/tree/drupalorg_project

swelljoe’s picture

I just got it figured out. It's not too complicated, but was also not intuitive (to me).

The effect is achieved by turning off the label in the per-issue metadata block (setting it to ), and then in the display for the metadata move the status to the top of the list of items, and remove its label. Then add CSS for "#block-project-issue-issue-metadata .field-issue-status-1" and"#block-project-issue-issue-metadata .field-issue-status" that matches the d.o style for those elements (or whatever styling one wants, but the d.o style is fine for me, and nicer than what I currently have).