Resolving the issue queue pains

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
Bojhan's picture

Background

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.

Explorations

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.

Proposal

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).

Issue status

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.

Comment form

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.

Files

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.

Discussion

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.

Feedback

What we need now is your feedback! We created quick and dirty prototype, which you can try out on this development site:
http://page-drupal.redesign.devdrupal.org/

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:

  1. To what extend does this solve or not solve the current pain points?
  2. What is your first impression using it?
  3. Do you have any suggestions to improve the current design?
  4. Can we start implementing this design on D.o?

Thanks

We would like to thank the various people involved in getting this off the ground:

Comments

After a quick test I have to

dddave's picture

After a quick test I have to say that this is a major improvement over the status quo. I do have one question though: Was it a deliberate decision to place the collapsed fieldset "Issue metadata" above the comment field? It looks odd to me and doesn't feel right. Sorry to be not able to describe this better.
The lack of feedback about the current issue status is still a major problem, esp. on longer threads you visit via a link.

Yes, it was a deliberate

tvn's picture

Yes, it was a deliberate decision to help address loss of context when people jump to the comment form. https://drupal.org/node/2125287

That actually makes sense. I

dddave's picture

That actually makes sense. I might have more of a look and feel problem than a functionality problem.

First impression: I love it!

alexpott's picture

First impression: I love it! Tested the prototype and everything works nicely. http://page-drupal.redesign.devdrupal.org/comment/8252273#comment-8252273

So much win!

Wim Leers's picture

So much win! Thank you, thank you, thank you!

One thing that I haven't seen mentioned at all, yet which is very important for frequent users: keyboard navigation. Especially when changing the issue metadata. Please make sure we can tab from one form item to the next!
(That's a problem both on the current d.o and in the prototype: the "Project" form item always performs an AJAX request, even if you didn't change anything, and then removes keyboard focus, preventing further tabbing.)

To answer your feedback questions:

  1. Yay, able to change issue status and upload patches in the comment form again!
  2. YAY, but:
    1. So many text collapsed fieldsets in the prototype! Especially the "Text format" fieldset is confusing, because it's something you only need 1% of the time, yet it looks the same as the other, much more important fieldsets. However, the designs in this article address that, so if those are implemented: no concern :) It's nice to see that d.o will be using a very D8-like text format selector/filter tips implementation :)
    2. A new best practice has emerged since the D7 upgrade of d.o: hide all irrelevant files in the issue summary. That means that whenever you upload a new patch, you should hide older patches. To continue to do that, I'd still have to go to the full node page. Effectively that means I'd stop following that best practice. But that makes the collection of files in the issue summary a whole lot less useful.
  3. I like the two column approach for the issue metadata. That's probably also a good step in making d.o usable on smartphones. I see one problem though: "Project", "Version" and "Component" logically belong together, but "Assigned" doesn't fit in there. I think "Category" does fit in that row, so I suggest moving the "Category" form item into the right column and "Assigned" into the left column.
  4. Yes, this is definitely a step forward! Thank you!

Finally, a suggestion for how to implement the remembering the user's preferences for using the issue metadata and other fieldsets: use localStorage, not a cookie. The cookie would get sent to d.o for every request, making every d.o page load slightly slower.

Thanks for your feedback! A

tvn's picture

Thanks for your feedback!

A new best practice has emerged since the D7 upgrade of d.o: hide all irrelevant files in the issue summary. That means that whenever you upload a new patch, you should hide older patches. To continue to do that, I'd still have to go to the full node page. Effectively that means I'd stop following that best practice. But that makes the collection of files in the issue summary a whole lot less useful.

Perhaps we can address this by fine-tuning automatic filtering, which happens on the Files table now. Original idea during the upgrade was to provide a way for people to manually hide/display files only. During the testing in Prague we received feedback, which made us add filtering to the table, so currently it shows X latest files. Further plans include limiting files to the ones uploaded in X latest comments. There might be a better way to determine, which files are the most relevant and should be displayed. See https://drupal.org/node/2104225 for discussions about that.

I see one problem though: "Project", "Version" and "Component" logically belong together, but "Assigned" doesn't fit in there. I think "Category" does fit in that row, so I suggest moving the "Category" form item into the right column and "Assigned" into the left column.

The current location is basically the "way it was always", and the way people used to. While I can see the value in your suggestion, we might want not to go there right now, as practice shows people have tons of different opinions on the best possible grouping of the fields. Some data on which fields are often being changed together would help here.

The text format should follow

Bojhan's picture
  1. The text format should follow the design, which will make it differentiate from the other fieldsets. Ideally we follow D8's lead on this one, just not sure how realistic that is.

  2. I agree, this is a difficult problem. I personally don't think that selectively hiding/showing files was ever a good idea. I think that tvn's idea, to do this more automagically might be more sensisble than introducing that complexity here. If that never materialises, we should figure out a way to bring it back but more sensibly (e.g. only showing the last couple of "shown" files, so you can hide those, instead of the whole list).

  3. We can move those select lists around, I will need to see in the final prototype how much space we have for the two column approach. What we can and can't group together.

Thanks for your feedback!

That looks really great!

joachim's picture

That looks really great! +lots!

We will need to figure out how to make this efficient in “remembering” the state for more advanced users.

Could that be left up to dreditor to handle?

Do we have any data on how many users use dreditor, and what proportion of module maintainers that is?

Tried the prototype. A few minor points:

  • it's unfortunate that the 'text format' fieldset below the comment textarea looks the same as the fieldsets with actual issue stuff in them. I wonder if there's a risk of accidentally clicking it when you want the next one down. But I don't think there's much that can be done to improve this.
  • would it improve usability of the form for less experienced users if each fieldset had a description on it when collapsed? Eg, 'Issue summary & relationships: Update the issue summary to do yadayada, and set relationships such as parent issue or related issue'. Of course there's no easy way I think to do that sort of thing with Form API, so probably a non-starter...

Thanks for your

tvn's picture

Thanks for your feedback!

Could that be left up to dreditor to handle?

I think that's what we are going to do, at least while implementing the first iteration of changes.

it's unfortunate that the 'text format' fieldset below the comment textarea looks the same as the fieldsets with actual issue stuff in them. I wonder if there's a risk of accidentally clicking it when you want the next one down. But I don't think there's much that can be done to improve this.

'Text format' is a fieldset on a prototype only. Per design proposal we will remove it, leaving only the actual drop-down to choose format.

would it improve usability of the form for less experienced users if each fieldset had a description on it when collapsed? Eg, 'Issue summary & relationships: Update the issue summary to do yadayada, and set relationships such as parent issue or related issue'. Of course there's no easy way I think to do that sort of thing with Form API, so probably a non-starter...

I don't think we want to add more text to the form, what we are trying to do is to keep it as simple and clean as possible. We might think of some other ways of educating less experienced users.

A drop-down makes sense for

webchick's picture

A drop-down makes sense for admin users, but what happens when a user (like bacon) only has access to a single text format? Right now it looks pretty messy.

I assume they'll see only the

tvn's picture

I assume they'll see only the link "More information about text formats", which is helpful in case they want to find out what tags they can use.

Yhea, I think most users

Bojhan's picture

Yhea, I think most users won't care since they have their WYSIWYG. If you really wish to find out about a particular tag, you can just go there.

Much better! These changes

DSquaredB's picture

Much better! These changes are a great improvement.

DSquaredB
Danita Bowman

Thanks for the hard work!

tedbow's picture

I really do like the new comment form and being able to edit the metadata etc without going to the edit page.

1 issue I did find is in the "Issue summary & relationships" field set the "text format" link under the summary is overlapping the label and text field for the "parent issue"

http://snag.gy/khYdC.jpg

I was viewing this on Mac using the latest Chrome.

Also are you planning on leaving the ability to add a comment on the edit page as well? It seems weird that when click the edit tab the first you have the ability to add a comment here as well. http://snag.gy/iKuMb.jpg

http://page-drupal.redesign.devdrupal.org/node/2146395/edit

Since with the new changes you would be able to do the exact same things on the comment form and edit page it might be confusing. My suggestion would be to leave the Comment text box off the form.

But I would say, yes, the new design would be a great improvement.

Thanks

Core developer

Thanks for the feedback. Yes,

tvn's picture

Thanks for the feedback.

Yes, we are aware of the 'Text format' link behavior in Chrome. Note 'quick and dirty' description of the prototype :)

Also are you planning on leaving the ability to add a comment on the edit page as well? It seems weird that when click the edit tab the first you have the ability to add a comment here as well.

Yes, we are going to leave that ability, so people could explain their changes while doing them. A new comment is generated automatically every time you change something about the issue anyway. Comment field just provides an ability to explain your changes, and it is also playing the role of the 'Revision log message' field. So whatever you type there will be a description of your revision on node/x/revisions page.
What we might do is move the field down on the issue edit page and/or change it's label/description.

One of the concerns raised

msonnabaum's picture

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.

I very rarely need to update the issue summary when I'm updating an issue. Putting this field in my way doesn't make me more likely to use it, it just annoys and confuses me every time I see it. Just yesterday I accidentally updated the issue summary with what should have been my comment. Collapsing it is the least that can be done. I'd still highly prefer it was gone altogether as these tasks aren't nearly as related as we wish they were.

Good work

StuartJNCC's picture

I think it is has several improvements in relations to the issues raised. Didn't see any obvious downsides. One point though - where has the [Preview] button gone? If removing it is part of the design and not just an oversight, then I think it is a serious regression. I always like to preview my submissions before I commit them. Saves lots of potentially embarrassing blunders from being exposed to the entire Drupal community!

.

mradcliffe's picture

I am fond of the preview functionality as well. I'll probably use it 3-4 times before I submit a comment (and usually wish I had done it at least 1 more time :-).

I don't know how difficult it is or how visually complex the preview becomes with all of the issue summary details, but my main use case of preview is to proofread my comment and formatting.

Preview button is likely a

tvn's picture

Preview button is likely a lot of work if we want to preview both all issue changes and the comment. And even if we just want to preview the comment, since it's not the usual comment field anymore. So we might want to leave that for the next iteration in order to implement these changes faster. Unless there will be more feedback that people absolutely need it.

I agree with this. Then

joachim's picture

I agree with this.

Then again, I don't use the preview much myself.

But it's possible to edit one's own comments, so for the time being maybe that's an acceptable workaround?

I think so, I really removed

Bojhan's picture

I think so, I really removed it to reduce the complexity of what we are trying to do here. I think its essential to bring it back in the future though, now that every small edit to the summary creates a new comment - you get flooded with messages if you are tweaking the layout.

I wouldn't take the pre/post

greggles's picture

I wouldn't take the pre/post change in statistics to seriously because the end of November and all of December are commonly a lower activity period for Drupal. The change in different ratios seems like it can be a valuable metric (issue summary edits per comment, for example). Using the data to guide decisions about which fields to expose makes a ton of sense to me.

I've also been surprised at how much I miss having these controls on the comment box. I think the proposals here will make a solid improvement to our workflow.

One item that I think this misses is the context of an issue when you land on node/NID#new - whether you are coming from the /project/issues view or the /tracker/UID page to a thread you follow that has a new comment you will land at the bottom of the page and miss all context about the issue. Here's a screenshot with my proposal. I think that idea is proposed with some amount of code in this issue.

One item that I think this

tvn's picture

One item that I think this misses is the context of an issue when you land on node/NID#new - whether you are coming from the /project/issues view or the /tracker/UID page to a thread you follow that has a new comment you will land at the bottom of the page and miss all context about the issue. Here's a screenshot with my proposal. I think that idea is proposed with some amount of code in this issue.

That's why we have 'Issue metadata' fieldset above the comment form. It is collapsed by default, but the idea is to provide a way (via dreditor or the site itself) for power users to keep it expanded all the time, so that they see all metadata the same way they used to on D6.

We are trying to limit the scope in order to implement this faster, so sidebar block being sticky is not a part of this iteration. It still might happen later.

@greggles Yhea, I think for

Bojhan's picture

@greggles Yhea, I think for this iteration should settle with collapsing the issue metadata. I think we can do a scrolling sidebar, but the implications might be larger so we will need to explore it a little more. For example, it makes it even more jarry on a mobile phone.

Fieldsets

mradcliffe's picture

I was surprised how much I liked the fieldsets. I think that I had an instant critical response to them because of they weren't as visually distinct as tabs. However it was really easy for me to use the fieldset.

Mostly great!

jhodgdon's picture

I like it, mostly! Great work! A few thoughts:

a) There doesn't seem to be a way to change the text format for the comment or summary? Maybe user "bacon" just doesn't have permission for any other text format, but you might want to check on that. Hiding that in a field set seems like a good idea, since on an issue I would rarely want to change the text format anyway.

b) 99.9% of the time, on an issue, if I'm uploading a new patch file, I go back and hide the 2nd oldest patch and interdiff, to reduce the clutter at the top of the issue (which would otherwise become HUGE on older issues). So I don't agree with the decision to remove the ability to hide files. If you decide to leave this out of the "quick edit" form, I'll still have to be jumping between pages to use the full form, like we are now.

c) Let's get rid of the "update this issue" button at the top, unless you just make it jump down to the bottom of the page. The only difference now between the comment/edit section at the bottom of the page and the full node edit form, as far as I can tell, is that the full node edit form has the ability to hide files (which, as I said, I really think we need on the "quick" form). And it's not organized as well. :) And it doesn't have fieldsets. So... I don't think we need both. Let's just not have the full page form? We're 95% of the way there to not needing it.

d) The "Add new comment" link in the right column is jumping me someplace weird. I end up half-way down the comment box. Make sure it jumps to the top of the Comment/edit form area.

e) I second the motion for fixing the tabbing problem. Try it and you'll see -- in the Issue Metadata box, tabbing changed the sizes of boxes and ended up closing the box. Eek!

f) I guess you haven't quite taken care of the idea of removing the help text beneath the meta-data fields yet, or reorganizing into two columns?

Let's just not have the full

joachim's picture

Let's just not have the full page form? We're 95% of the way there to not needing it.

Agreed. We only granted access to the node edit form for issues to the average user when we made the change to use the node body as an issue summary, and that change was because it wasn't something that could be edited in a comment.

There doesn't seem to be a

tvn's picture

There doesn't seem to be a way to change the text format for the comment or summary? Maybe user "bacon" just doesn't have permission for any other text format,

That's right, regular users have access to 'filtered html' format only.

I guess you haven't quite taken care of the idea of removing the help text beneath the meta-data fields yet, or reorganizing into two columns?

Yep, the prototype is there to show the basic idea of the fieldsets, it's not close to "implementation" yet.

99.9% of the time, on an

tvn's picture

99.9% of the time, on an issue, if I'm uploading a new patch file, I go back and hide the 2nd oldest patch and interdiff, to reduce the clutter at the top of the issue (which would otherwise become HUGE on older issues).

Precisely because some of the issues have lots of files, we probably won't ever display all of them on the comment form. We might display a few recent ones if it'll help with the workflow of hiding a few files when uploading new ones.

The normal edit form will stay there to:
- give access to all of the files uploaded to an issue
- give access to all the admin options in vertical tabs, such as Publishing options, Comment settings, Authoring information, Url path/redirects, etc.
We can improve the edit form as well, it's just not a part of the current iteration.

We will need to change logic of the big "Update this issue" button or remove it when this changes go live indeed.

Thanks for the feedback!

Perhaps dreditor could help

joachim's picture

Perhaps dreditor could help with this workflow in due course.

Each file on a comment have a dreditor-created link on it that says "Replace this patch", which jumps you down to the comment form, and fills in the necessary to hide the file from that comment.

I would prefer this kind of

markhalliwell's picture

I would prefer this kind of functionality be handled on d.o itself. The less "fixes" we put in Dreditor, the better. Also, putting this only in Dreditor will create a disconnect between those who use Dreditor and those who don't. If we want this as a "standard" workflow, then it should be for everybody on d.o. Otherwise we'll have a lot of comments going back and hiding the files the novice user forgot when uploading a new patch.

Thanks! B) I will get back on

Bojhan's picture

Thanks!

B) I will get back on this one, I think that's been the major feedback on this issue. Its also the hardest to resolve without introducing a whole bunch of complexity into that fieldset. It will probably need more thought and iteration, to come up with a solution to this problem (for example, automating the process more, only showing a part of the file list with collapse function, etc).

C) I think that we can do that. That is if we can adequately resolve B).

D, E) I think tvn is tackling those bugs.

F) I am actually not quite sure what you mean? I did indeed rearchitect a bunch of the help text, this was mostly because its now kind of all over the place. Although its in context, because its in between very busy form elements its hard to notice and makes the form less scannable. Placing it more together, in one line we elevate it more and make the form easier to scan. If you mean the prototype, then yes that probably still needs much more work.

The proposed changes are an

moshe weitzman's picture

The proposed changes are an improvement. In addition, I think inline editing of issue metadata is a real breakthrough solution here. Maybe someone could add some technical detail around the quote below. A beta release of Edit module will likely happen this week. Perhaps d.o will reconsider it.

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.

I think the main issue there

webchick's picture

I think the main issue there is it could lead to 10+ comments by the same person just going around and editing little bits of info. We could certainly try it on a sandbox and see how it goes, but it feels like that might be iteration 4-5 rather than iteration 1, to me.

Yes, indeed. A comment is

tvn's picture

Yes, indeed. A comment is automatically generated when something is changed, so inline editing will make that and conflict resolution troublesome.

Yeah, I just want to point

webchick's picture

Yeah, I just want to point out that technically that is not how it works, and technically you can tab around to different fields within the same edit "session" and then hit Save to commit changes only once. But since the save button is always there it's ever-so-tempting to hit it all the time. :D

Exactly. We have the

moshe weitzman's picture

Exactly. We have the technology built to allow inline editing with only one revision at the end. So it is a matter of UX to lead users to using and enjoying the tool correctly. And UX design is exactly what this effort is about.

I think you are right, that

Bojhan's picture

I think you are right, that the direct functional issues of moving over to edit in place could be resolved. I think there are a two primary concerns:

1) There are some serious technical concerns by dww, on several levels from performance, fit with d.o overall to how it will work on the detail level (e.g. do we post a comment on every tiny edit in place revision). These issues should be resolvable, probably at some development cost.

2) Fundamentally the flow will still be disconnected, since you are changing the summary on top and then having to go to the bottom to "comment" on your change. Ideally we figure out a way to bring both closer, as providing arguments for your change might otherwise be forgotten.

Given that we have very limited capacity to figure all of this out, develop it and deploy it. We postponed this part for now. I'd like to emphasize the "for now" part because I'd love if we can do a whole lot more on the D.O issue queue front in 2014.

I think you are right, that

Bojhan's picture

I think you are right, that the direct functional issues of moving over to edit in place could be resolved. I think there are a two primary concerns:

1) There are some serious technical concerns by dww, on several levels from performance, fit with d.o overall to how it will work on the detail level (e.g. do we post a comment on every tiny edit in place revision). These issues should be resolvable, probably at some development cost.

2) Fundamentally the flow will still be disconnected, since you are changing the summary on top and then having to go to the bottom to "comment" on your change. Ideally we figure out a way to bring both closer, as providing arguments for your change might otherwise be forgotten.

Given that we have very limited capacity to figure all of this out, develop it and deploy it. We postponed this part for now. I'd like to emphasize the "for now" part because I'd love if we can do a whole lot more on the D.O issue queue front in 2014.

This comment by dww basically

tvn's picture

This comment by dww basically lists a lot of our concerns: https://drupal.org/comment/8237151#comment-8237151

GREAT stuff! On your specific questions...

webchick's picture

I'll answer them in a weird order. :)

4. Can we start implementing this design on D.o?

FOR THE LOVE OF ALL THAT IS HOLY, YES!!!! :D

On this point, I do want to emphasize to everyone chiming in on this thread (including myself :D) that while sharing detailed feedback is awesome and very much welcome, we are going to need to strike a balance here between speed and perfection. I think we can all agree that the sooner the large "stakes" of this redesign land (e.g. collapsed field sets for issue metadata on the comment form itself), the sooner every single thing we do on Drupal.org will be vastly improved, even if it takes a couple of iterations/deployments to get 100% perfect (well, we'll never be 100% perfect, but you know what I mean :)).

So if there are things that seem particularly "deployment blocking" to you, maybe call them out as such so the team can factor that in to their scoping decisions. Of the comments so far, the only one that feels that way to me is keyboard navigation between issue status fields because in addition to a power-user tool, that's also an important accessibility barrier (and likely a performance improvement to kill that unnecessary AJAX request). I would also personally put off some of the UI smoothiness (e.g. the reducing the text format noise, adding libricons to BUEditor) to a later iteration as those will just be a soothing "Ahhhh" balm on the eyeballs in iteration 2-3, rather than a jarring "who moved my cheese?!" kind of thing. However, I leave that up to the folks working on this to decide. :)

Speaking of people working on this, what's the proper way for people who care about this getting deployed faster to help hack on it? Should they follow the instructions at https://drupal.org/node/1018084 and ask to get their SSH key added to devwww so they can work on the page-redesign sandbox? What's the proper issue queue(s) to submit patches, etc?

2. What is your first impression using it?

So for very first impressions, I might just be weird, so take this with a grain of salt, but honestly when I first went to the comment form I totally missed the collapsible field sets! Despite the fact that I knew they would be there! :) That's probably fine, though, because that's what we want most users on Drupal.org (in terms of the overall raw #s) to do. ;) But the reason I had that impression is the theming was slightly wonky/off in the prototype.

In other words, https://groups.drupal.org/files/fieldsets-early.png looks fine to me, but the prototype has weird non-standard styling (almost zebra striping) between collapsed field sets. That's fine, it's probably just a bug in the prototype.

Hopefully this is also a bug in the prototype, but when uploading a file, it spun for a few seconds and then seemed not to work. This is because the Files field set went back to collapsed. The file is actually there, but invisible. Fixing this is a deployment-blocker, IMO.

Uh, and then when you upload a file it deletes all of the old ones. :) http://page-drupal.redesign.devdrupal.org/comment/8252276#comment-8252276 That's not good. Fixing this is a deployment-blocker, period! ;)

"Add another item" is also broken on related issues, the first time. it sits and spins and jumps you somewhere totally wonky, without having actually added another. Then when you go back and hit it again, it does work. Fixing this is probably a deployment-blocker.

1. To what extent does this solve or not solve the current pain points?

I would say it pretty much solves all of the important ones for me:

  1. As a core committer, pretty much the only thing I ever do on issues is change their metadata. I'm marking patches from RTBC to needs work or to fixed, and/or I'm adding tags, etc. But it's not always clear that I need to do those things from the outset of writing my comment; it often doesn't come up until I'm halfway through. But when it happens, it invariably results in cursing loudly, cutting the comment, opening up the edit tab (and waiting ages for a server round-trip), pasting the results (always having to be very careful not to accidentally paste it in the issue summary field instead of the comment field, per msonnabaum's feedback), press submit, wait for another server round-trip, and then scroll down manually to find my new comment (since I'm no longer redirected there automatically) to see if everything turned out ok. The workflow changes introduced here eliminate almost all of that.
  2. Another frequent task I do is patch review work. I use Dreditor to review patches, which doesn't work on the node edit form, only on the comment stream form, and almost always results in an issue status change. So having those fields available right there as in the prototype once again makes this super easy.
  3. Frequently I scan back and forth over the comment stream to incorporate responses to others in my comments. Now I can just scroll up, rather than having to have two tabs open and bounce back and forth between them.
  4. I review a lot of UX patches and so frequently upload screenshots of what I'm looking at to illustrate a point. I have two problems with the new D7 upgrade: 1) image secure filter (or whatever that module is called) breaks with spaces in the filename, so Mac OSX's "Screenshot taken at 2006-12-24 at 13:37 pm.png" or whatever it does break every. single. time. My workaround has been a very elaborate manual copy/pasting/modifying process which is time-consuming and irritating. This would be eliminated by Dreditor's nice "embed" feature, except that 2) because file uploading is now on a separate edit tab, Dreditor no longer can do this for me. By moving the file uploads to the comment form, this workflow issue should be eliminated as well.
  5. Probably other things I'm not thinking of. I'll continue to play with this.

3. Do you have any suggestions to improve the current design?

I actually kind of agree with dddave who said issue metadata at the top looks rather bizarre on first impressions. I'm wondering why that was moved above the comment form, other than "because that's where it used to be." While issue status changes are certainly the most common thing to do on comments that change something about the issue itself, making a comment at all is definitely the most common thing people do, since that applies to almost 100% of comments. Once again, https://groups.drupal.org/files/fieldsets-early.png looks fine to me, the prototype looks off (but in this case it seems deliberately so). It does feel like if we're going to muck about with the location of the issue status fieldset, we should do it prior to deployment because that's going to be really annoying to get used to it one way and have it move on you later.

(Incidentally, take the issue summary update stats post-upgrade with a grain of salt; post-D7 upgrade, the first time an issue has anything about it changed it will also show a body change as well, even though that is not necessarily the case. So it's basically impossible now to know issue summary edit stats from now on, afaik. :)

Speaking of issue summaries, I actually do like that issue summary is now a deliberate click away, so it's clear what I'm editing and when. By putting "Issue summary" at the beginning of the field set title it still helps escalate the importance of this for those issues that need it.

I might have other suggestions as I play with this more, but mostly I just want this live as quickly as possible. :D GREAT WORK, everyone!!!

Thanks for review!Uh, and

sanchiz's picture

Thanks for review!

Uh, and then when you upload a file it deletes all of the old ones. :) http://page-drupal.redesign.devdrupal.org/comment/8252276#comment-8252276 That's not good. Fixing this is a deployment-blocker, period! ;)

What did you do to delete all the files? I can't to reproduce this. Can you explain your actions? Files not should be deleted.

"Add another item" is also broken on related issues, the first time. it sits and spins and jumps you somewhere totally wonky, without having actually added another. Then when you go back and hit it again, it does work.

Works for me, weird :)

Maybe it only happens the

webchick's picture

Maybe it only happens the first time a new comment w/ a file is posted on an issue? Not sure?

I used Firefox but otherwise wasn't doing anything weird, just using the comment form the way I usually do.

Lending a hand to make it happen

eliza411's picture

I've created an implementation issue at https://drupal.org/node/2159409 If people want to lend a hand, they should make it known with a comment on the issue.

They should definitely go ahead and request their keys be added per https://drupal.org/node/1018084 (citing their intent to work on issue #2159409).

There's a little more planning and coordination to be done before the hacking commences, but that will get the ball rolling! Expect to hear more from tvn on next steps, especially the correct dev environment and plans already in the works.

Angie, thanks for this

Bojhan's picture

Angie, thanks for this thorough response! The reason the issue metadata fieldset is above the comment form, is because it holds the "title" which is essential for more seasoned contributors who move between many issues. We can have it below the comment form depending on how we can make the #jump to last comment interaction work. I personally have no particular position on this, I actually had it below the comment area before but after feedback to place it above moved it.

Let me know what you think, we should definitely decide upon it pre-deploy.

Collapser

vijaycs85's picture

We will need to figure out how to make this efficient in “remembering” the state for more advanced users.

In general this looks like a

pwolanin's picture

In general this looks like a big improvement.

A minor suggestion would be to consider putting the files fieldset 2nd or at the top, since I think uploading a file might be more common for humans, while I'd guess a lot of the issue status changes are by the testbot (unless you excluded those?).

Omg... yes. Please let's get

markhalliwell's picture

Omg... yes. Please let's get this put back in. It would fix so much in Dreditor.

Thank you very much for

salvis's picture

Thank you very much for taking this on. I agree with webchick to deploy this asap and keep discussions of the finer points for later.

  1. To what extend does this solve or not solve the current pain points?
    It goes a long way — it's definitely worth deploying.
    The complete removal of comment preview is a new regression, but this should not hold up deployment of a first iteration, because comment preview is already broken (it doesn't show the existing comments). To write a comment that needs previewing I already now open a second browser tab, so, removing the Preview button might even be considered a helpful reminder. :-)
  2. What is your first impression using it?
    Great relief! If only I could keep the metadata fieldset open. Using Dreditor for that would be fine for now, but ultimately we should not have to rely on a tool that is not even hosted on d.o to make d.o usable.
  3. Do you have any suggestions to improve the current design?
    1. Please keep the metadata above the comment field. After opening an issue from a "new" link and reading the new comments, it's essential to glance at the metadata before starting to reply.
    2. The Issue Status proposal in "two columns" looks OK, but...
      • http://page-drupal.redesign.devdrupal.org/node/2152085 doesn't look like the screenshot in the proposal, at least on my FF: The controls take up five rows rather than three.
      • The theme uses a fixed width of about 770px for the content region. The metadata fieldset-wrapper extends into the right margin to take about 900px. It could take all of the right margin and go to about 1170px, but I think it would still not be enough, and it can conflict with the blocks in the right margin (if the issue is short enough).

      I'll post a screenshot of what I'm seeing as soon as we have an issue...

    3. I would support adding the full files management to the view page, but this needs more discussion in a later iteration.
    4. More later...
  4. Can we start implementing this design on D.o?
    Yes, please!

For those who like this and want to help...

webchick's picture

For those who like this and want to help, here are the two spots to be aware of:

[Meta] Implement first iteration to improve issue queue workflow is where we're coordinating things. Still in flux as we work out various technical details.

Display parts of the issue edit form instead of the comment form on issue pages is the main implementation issue. It could definitely use technical guidance from folks who have experience embedding custom node forms in D7.

I still think a real edit form via AJAX would be better

dww's picture

I still think the best approach would be to improve the actual edit form along the lines of the design here, and just load that (in full) into place at the bottom of an issue page when you click "Update this issue". I don't understand this objection at all:

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.

Huh? You'd never go back and forth. The tab would just basically convert the comment form into a full update things form (and there would be 5-10 lines of JS to copy the value of the "Comment" field between the two). Once you decided you wanted to update things, you'd load the real edit form and you're done -- why would you ever go back?

Doing it this way:

A) Makes it vastly easier to implement since we're not trying to alter a comment form back into an entity edit form. This could probably be done with existing contrib modules or very little custom code.

B) Exposes us to less x-posting badness since we'd only load the edit fields once you're actually wanting to update something, not as soon as you load the page to start reading.

C) Leaves us with one happy edit UI, not the optimized UI on the comment form vs. the unloved edit tab itself.

The one thing this solution does not solve on its own is that you don't see all the current issue metadata values (and node title) down at the bottom of the page once you've scrolled down to read new comments and you're only commenting (for now). That context would be missing until you click on "Update" but could be solved via other means (having the sidebar block scroll down, printing a summary of it again above the comment form, whatever). That seems a lot easier to solve than the handstands people are doing to re-implement the horrific D6 project_issue codebase where the comment form becomes a node edit form.

Anyway, for reasons I don't fully understand, my objections to this approach continue to be ignored or overruled, so I'll just try to do what I can to help people implement it The Bad Way(tm). :) But, for the record, I think this is a mistake on multiple levels.

Cheers,
-Derek

@dww I dont really understand

Bojhan's picture

@dww I dont really understand your objection. We are largely loading the edit form here, the tweaks are mostly on an organisational/visual design standpoint - than a technical one. If technically you wish to fully load it in, as that is the better approach its best to chime in the issue queue.

The back and forth is real, I don't see how thats not understandable. When you change the status, you often also want to put forth a comment, same goes for most of the other fields. Having to move between tabs for a one activity, means it still caters after the implementation model and not the workflow people desire.

I don't think its fair to say we are ignoring, I always take your opinion very serious. But in this case it seems to conflict the model that is from my point of view most effective and usable. Surely we can hack away around it, and have the sidebar scroll, etc. but frankly thats suboptimal to the solution we are proposing here.

Drupal.org Improvements

Group categories

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week