Regression: new pageloads / form submissions required for every issue update

If the goal is to hide the issue fields based on the assumption that the majority of comments are just comments and not field changes, then perhaps the fields can be made toggleable via JS when you click a button or something? That way we could at least use a userscript to show them by default, and we'd avoid extra page loads and form submissions.

I don't see a single improvement in the way issue updates are now handled.
What we have now is slower and more confusing (due to the megaform that loads on the next page and allows me to do 15 different things)

Since my impression is that we're trying to copy redmine quite a bit (not saying this in a bad way at all!) I think we should just admit it and copy their flow as well.

Essentially, what this means for our issue page is that we would show both forms (node + comment), and the node form would be contained in a fieldset that is collapsed by default. This way, if all you want is to enter a comment, the current flow remains unchanged, but if you also want to edit the node, you just need to open the fieldset and you won't lose the context anymore.

For the record, here's the post that explains the reasoning behind the current design: https://association.drupal.org/node/17983

That said, it doesn't really address why the fields can't be on the same form as the regular comment and just collapsed by default.

I have to agree with everything said here. The new issue workflow is inferior to the old one.

Some of the new features are nice; I love that we finally have issue relationships, and the new header area is pretty. But for day to day usage, it's a big step backward.

In addition to what's been said already, when I'm down at the bottom of a thread now, I have *no idea* what issue I'm looking at or what it's status is. I have to scroll back up to the top of the window (500 comments away) to see if the issue is even RTBC or not.

The split summary-vs-comment problem before was real; but the solution taken seems to be entirely backwards. It's forced all of the actually useful changes into the node-edit form. Instead, all that was needed was to add a hidden "update the summary" textarea to the comment form. That would have solved the problem much more easily (and in a manner consistent with Redmine, as #6 notes) and without a major regression in usability.

This is a major WTF. Maybe the authors did "take a look at how people use the queue" as https://association.drupal.org/node/17983 claims, but it seems they've never actually used it themselves. Maybe the new issue view page could be an improvement for users who have never been on d.o before. But for those of us who have been spending hours on this page most every day for a couple of years, it's obvious that it's a major step backwards.

Some examples in addition to those given above:

1. Look at an issues list and click on an "N new" link. This puts you near the bottom of the issue view page, where the first unread comment is. You start typing a reply and would like to check the Category: you have to scroll all the way to the top to find out, and back all the way to the bottom.
2. You did the drill above to find out against which version this was reported -- say it's 6.x-1.8, but you don't remember what the current version of this branch of this project is. We used to be able to drop down the versions list and immediately see where we are. Not anymore! Now we have to go to the edit page to find out! And to scroll around the terrible layout to find the version drop-down! When we finally get there, our train of thought is broken...
   [IOW, it would not be enough to have the version number listed at the bottom, we need the drop-down right there because it carries essential information!]
3. So, maybe we should just forget about the view page and always go to the edit page? But no, the edit page is an abomination, too! Where were the usability experts when this was designed?
   1. It does not show the existing comments.
   2. It has no comment preview.
   3. It creates new revisions even if you just add the comment.
   4. When you save, you save the entire issue -- hard to tell what happens if someone made some other change in the meantime (added a file or tag, for example, or changed the priority).
      There's the...

      The form has become outdated. Copy any unsaved work in the form below and then reload this page.

      message, but a) copying is a pain on a page with so many features and b) the nature of the web has taught us that such things are never 100% safe.

   5. The preview seems to show only the issue body (and the teaser...) but no changes of the issue settings (like Priority).
   6. You have to be ultra-careful that you don't inadvertently edit the issue summary rather than the comment, especially when you have to keep flipping back and forth among multiple pages.
4. After reading through a lengthy issue, you're likely to have forgotten what the status of the issue is (displayed only at the top). In D6 you naturally ended up at the settings field at the bottom where you could check the fields (and tags) without any conscious effort. Now you'd have to scroll back up to the top to do this, and and if any of them need changing you have to go to the unsightly edit page, find the settings fields again [or the (collapsed!) tags — now what was that tag that got lost somewhere along the road and that you meant to put back??], and finally, maybe, change them...
   Putting the settings into a collapsed fieldset is not the solution. Having it in plain view is an important feature.
5. It's too early to comment on the updated file handling, except for this: the new "Upload new files" link encourages uploading new files without adding a comment to explain what they are. This is yet another way to make the life of the maintainer harder.
6. ... and this: managing the visibility of uploads is a new chore for the maintainer, and a stressful one, too, because it can easily turn into a source of bad feelings and even arguments.

I could go on and on, but the essence is this: working the issues queue is volunteer work. If you put roadblocks into the volunteers' workflow or do anything else to make it less pleasant for them to do their work, then they're less likely to spend their scarce spare time doing it. This hurts the newbies and everyone else much more in the long run than having to overcome a little bump to get used to something slightly quirky like the D6 format.

Throwing something out of the door that has worked reasonably well for many years for those who do the actual work, just because it may be a little confusing to casual non-technical browsers, who are likely to be confused by anything technical anyway, is not bringing us forward.

So, please, put the Issue Title, Issue Settings, and Issue Tags back on the issue view page where they need to be to enable a reasonable workflow.

@salvis, all your points basically boil down to one thing: issue queue "power users" cannot handle this loss of context.

I have to play the devil's advocate a little here. There are two types of users that interact with the issue queue: regular users and project maintainers. While the new flow might benefit regular users who mostly post comments and rarely patches, the reality is that people who are actually spending a lot of their time in the queues were kind of left behind.

This is why I think the hidden fieldset by default still makes sense, but it needs to be configurable *per user*, so people who actually need the node form visible at all times can have it.

I'm interested :)

FWIW https://drupal.org/comment/8148007#comment-8148007

Not covered in the threads anywhere (I believe) is that one benefit of using the comment form and adding a few extra fields is that the edit lock would not kick in on save. Having the main node form is going to make this more likely.

So while losing status updates / tags was irritating on D6, completely filling in the form again would be a pain in the ....

PS: I am assuming this is how the D6/7 systems were / are working...

I think given the number—and caliber—of contributors affected by this significant workflow change, it deserves to be a "major" priority.

Adding this as a child of a META issue about a bunch of inter-related problems that could all be solved with a relatively simple solution.

I've suggested this elsewhere (and mentioned to @mcrittenden this morning), but I think in-place editing for the summary and metadata might go along way toward getting rid of the extra hassle we've added to the workflow since the upgrade while still focusing on the "summary first" issue model and workflow that the redesign was intended to promote.

I made a quick video of what I mean for those who aren't familiar with the quick edit module in D8 (also available in D7 as https://drupal.org/project/edit):
https://www.dropbox.com/s/diaq31ftkpskjpb/in-place_editing.mp4

My biggest problems with in-place editing are:

1) There appears to be no way to add your revision log/comment to explain your changes.

2) From what I understand, they're all pretty bad for accessibility reasons. See #1545952-16: [META] UI for updating an issue in D7

3) If the workflow is that you open an issue, see the most recent comments/updates/patches, then you want to reply and do stuff, you'd have to scroll all the way back up to the top of the issue again and lose context.

4) It's not clear how well something like edit.module would work with some of the fields showing up in "the node" and others showing up in sidebar blocks.

5) I fear that if each field is separately editable, it's going to generate a lot of noise as people edit one thing at a time and press save. I definitely think the current implementation is way too much friction to change something, but I think a little friction is actually a good thing so that people don't just edit, save, edit, save, edit, save, etc. for 10 comments in the span of 2 minutes of thinking through what they're trying to say/do.

6) I don't know how well in-place editing would handle trying to preview all your changes before you save them.

I vastly prefer just turning the current "Update this issue" link into a tab that AJAX-loads the node edit form "inline" with the bottom of the page, more or less like the D6 UI. See #2125269-22: [META] Regressions in issue queue workflow.

p.s. I don't know if we should be having this discussion in here or in the meta issue itself...

I too think that putting the edit form in a set of AJAX-loaded tabs makes better sense and that it would improve UX.

...as I said though: a set of tabs - not a single monster tab to rule them all (see #2127443: The issue update mega form is unwieldy and distracting for reasons why). My proposal is to split the form into self-contained, task-oriented tabs so we would have:

Add new comment | Edit the issue summary | Upload files | Change issue status & meta-data | Update issue relations

...or if we (mostly) used the fieldsets already in the edit form (and for keeping tab titles short):

New comment | Issue summary| Recent files | Issue status | Issue relations

...or reduce it even further by adding a "Edit issue properties:" title and then simply having:

Comment | Summary | Files | Status | Relations

Thoughts? Perhaps file a separate, dedicated issue with this specific suggestion (use AJAX tabs) only?

I think #2159813: Display parts of the issue edit form instead of the comment form on issue pages fixed this. Please re-open if I am mistaken.