[META] UI for updating an issue in D7

Uploading v1 of the issue-editing-in-an-overlay wireframe .

Displaying the wireframe.

Uploading v2 of the issue-editing-in-an-overlay wireframe. Includes a file_upload field and a better modal overlay color.

Setting the width to 95%.

Not sure why the overlay is see-through.

The typical overlay has two properties:
* full-page covering of semi-transparent color (usually black) to make it modal (ie, other things can't happen whilst this overlay is open)
* content of the dialog has a solid background to make stuff visible (usable).

Consider more carefully the *purpose* of the elements in a design, instead of the tradition.

If you're asking for opinions/votes I'd personally go with option B

I'd like to propose

D: Hidden inline form

This is basically just the current form of having the update form at the end of the stream of comments, but make the div surrounding it hidden by default. Clicking the update button would toggle the visibility of the form, and be a link to an anchor so that clicking "update" would scroll the user to the form as well.

Pros: hidden by default, somewhat similar to current workflow, loads instantly (no page loads), allows the user to see and view other comments while composing their update
Cons: Form is at bottom of page, unexpected scrolling could disorient the user

Displaying v2 of the editing wireframe.

added cons to A & C

I'd prefer inplace editing but am concerned about the following things:

- with inplace edit separate for each field - sort of like in this wireframe - there might be too many comments as they are generated each time you edit something - title, summary, status, tags etc.
- will preview be available for issue summary in this case

@tvn, yes, that's my biggest problem right now with trying to integrate in-place editing and this new project.module issues concept. We'd have to make an 'edit all the things' button, and then take it out of edit mode with a 'save' button, which A) defeats the purpose of an in-place ajax editor, and B) essentially replaces the view|edit model we have now with something bordering on arcane (and which is not worth taking the time to iterate through because it's no better than what we have).

I'm working up a new set of wireframes today based upon a few conversations I had with Diana, Eliza411, and Webchick about who uses these tools and in what capacity. I'm also looking sideways at Leisa's mocks as I architect this thing, but it's apparent now that the initial ideas I captured aren't 'good enough'. :)

Back to the drafting table! (does anyone still use those things?)

Or we don't have to generate an actual comment for a change but instead have dynamic comments that are inserted at run time
i.e. Pull real comments from comments table, create dynamic comments from issue revisions table and display them both in the same list
Then in the dynamic comment creation code we can amalgamate adjacent entries in the revisions table by the same user into a single comment and work out an appropriate timestamp (I think of the first entry would make most sense)

Off the back of #10 feedback it makes a lot of sense so here is another suggestion to facilitate an edit-in-place solution without the multiple comment concern.

Clicking to edit one field turns all fields to editable and a save button appears. After making changes clicking save updates the issue, generates a comment and turns all fields back to view mode.

@akamustang Yeah, that's pretty much exactly what I posited earlier in this discussion, but as I said before, I don't see the value of coding and testing all of that new functionality during a D6->D7 upgrade if all it gets us is the same workflow as clicking an edit button and having the edit form pop up in a modal overlay. Smells like scope creep to me. :)

Yea fair enough, it is a bit of a scope creep. Perhaps more suited to a 3.0 release than an initial port/update.

C is an awful option and would require a fallback to (probably) A anyway.

So guess going for A or D would be the thing to do at this stage.
A - Meh cons massively outway the pros
D - Great suggestion!

I love all the advanced ideas, but realistically this will be an edit page - as far as I know, and the accessibility team can definitively proof me wrong here are there no fully accessible modal dialog/inline text editing interfaces.

I honestly, do not see this improvement as very useful - I am happy to be proven wrong though. Because we are investing all this time and resources into inventing a whole new UI model just to accommodate status change at the top instead of at the bottom. While from my point of view its going to be more common to change the status in the flow of a discussion (therefor at the bottom).

After reading the issue summary and 30 seconds of consideration A and D seem relatively low impact for accessibility. B / C would require a review of a prototype. I have never seen an inline edit widget that I really liked for accessibility, and modals are completely out for d.o as far as I'm concerned.

Happy to evaluate widgets, including modals, that others find and have reason to believe are accessible.

Turning the "Edit" link on the node into a jump link to the issue update/comment form at the bottom makes sense to me.

Why do we need separate "Update this issue" and "Add a comment" buttons?

Can't we just have it as one button that jump links to the form at the bottom of the page, submitted forms can then update the issue and generate a comment if anything has changed or just generate a comment if no issue settings have changed.

If you're worried about people changing issue settings when they don't need to then just hide that fieldset by default or put an "Also update the issue" button next to the form that magically makes the issue settings appear.

@akamustang in #18, adding a comment to an issue will *never* change any metadata about the issue, nor will it allow you to upload a patch file while doing so. Clicking 'save' on your newly typed comment will only ever generate a new comment that's attached to the node in a stream-of-discussion style. That's it.

*Everything* else is done by editing the node itself.

I thought during the "editing the node itself" there was going to be a box to explain the reason for the change which would then become the body of the generated comment.

If so, then what is the difference between:
- Editing the issue node without changing any metadata but adding a reason for the change
- Adding a comment in the tradition way

My presumption is that they are effectively the same...

So I had a chat with dww, one of the solutions we came up with is having one form at the bottom but having visual separation between Updating the issue and adding a comment. This is no perfect solution, because there is still an affordance that commenting is combined. But it does give you just one UI to do it all, and we are not making two custom UI's.

Personally, I am reluctant to anything that involves a dependency on the overlay module (or such effects), which should be left as an option to site developers.

In general, I am curious and positive to any development towards inline editing, and here option D) looks the most promising, "all things considered" (pros/cons, etc.).

@Taxoman

Can you please provide a rationale for your decision? Also, are you aware of any accessible (WCAG 2.0) inline edit widgets?

#27: Well, performance-wise, for one, and not everybody like the overlay feature, so I think there should be an option not to use it.

I have not dug into the accessibility issues with inline editing yet, but assume that it is possible to overcome such concerns if we decide to set the focus in that direction.
(Accessibility is important, and should not be neglected.)

#25
Yea, something like this is what I was driving at when I said we only need one button. So much less confusing for occasional users and more user friendly for regular users.

#25: They could even be vertically tiled; Meta data (update categories) on the left side with the save button beneath, and comment text field to the right, so that it might be even more obvious that one does not have to fill in anything in the comment field if only wanting to update the meta data.

That is actually almost like the initial sketch at the top here, possibly with everything from "Reason" and below behind collapsed labels.

Added option D

My opinion is any option that forces you to choose if you're going to either add a comment or update the issue fields ahead of time is a step backwards. Both should be able to be done in the same place and at the same time. So I think it's worth it to spend the effort getting this right first time around.

added two new options: E (Bojhan's #25) and F (something Senpai and I came up with in IRC)

I updated the issue summary to include the Editable Fields module as a possible means of implementing option B (editing in place)

From all options in the issue summary now I'd consider 2 only - A and E.

I see main benefit of E - keeping workflow same as right now, what most of "old" users got used to. But if we take a look at the current comment form from new user's eyes - the form is scary with all the options available.

Another thing about this approach - I find logic a bit broken when you update everything about the issue in one place but issue summary at another. Or other way around - you are updating issue summary in one place but to change issue title you have to go to comment form?
"Edit issue" operation should let you edit everything about an issue from title, to body, to tags etc.

We could possibly think of a way to fix this even with option E, but being pragmatic about our time/resource constraints, with option A being much easier to implement than E - I'd probably go with A, recognizing that it is not ideal at all.

The main concern about option A is the change to current workflow - you'll need to decide what you want to do - edit an issue or add a comment - before doing it. Generally I would think people mostly know what they are planning to do. Or if they don't - they often realize it after saving comment anyway, we often see double comments from people with 2nd one changing issue meta data.

However I might be wrong here and I definitely don't want to see everyone frustrated after we upgrade to D7. So I'd love if we could implement A, show it on some demo site and get initial reaction from users. If it is clearly very negative, we'd then have to consider another approach.

Since I see in-place editing being on the table here... Edit anybody?

Updated to include Editable Fields as an option

Adding an ordered list.

update

.

.

Any way to get a mockup of what it'll look like when done? It's a bit hard to tell from just the list of issues.

upd

.

upd

According to the issues linked in the summary, this is done.

#1965124: Perform detailed security review prior to inclusion in D7 drupal.org doesn't affect the UI and we are already running the module on D7 staging & dev sites.