Posted by dww on October 24, 2012 at 7:42am
6 followers
| Project: | Project issue tracking |
| Version: | 7.x-2.x-dev |
| Component: | Issues |
| Category: | task |
| Priority: | major |
| Assigned: | dww |
| Status: | closed (fixed) |
| Issue tags: | bluecheese, Drupal.org D7, project, Usability |
Issue Summary
Issue status part of the D7 issue edit form needs improvement. We are going to re-create D6 issue status update UI.
Remaining tasks
1. Re-arrange the fields
2. Move labels above field values
Related Issues
#1545952: [META] UI for updating an issue in D7
Original report by dww:
Since field_group is already deployed, and based on the success of #1821390: Improve the UI for creating/editing projects by using vertical tabs, we should help the issue add/update UI via defining some field groups. Instead of having all the issue metadata fields in a big serial pile, we can group them all into a fieldset (since they're the main fields of the form we don't want to use vertical tabs) and split them up into container-inline divs so they wrap nicely.
Comments
#1
Here's a start. Before + after screenies on my local dev box using bartok. I'll have to deploy this on a d.o dev box to get screenies with bluecheese, but I suspect it's still going to be a huge win (and if we need to tweak it, so be it).
#2
Better still. Probably the two most common operations when updating an issue are to update the status and the assigned field. So, I split those two out as the first two options under the project in their own div, instead of having each of them be the end of a long pile of other choices.
#3
Committed, pushed, and deployed to git7site. We can always tweak this more later down the road.
#4
@hackwater of the Bluecheese Team is currently handling the theming of issues and issue edits, has been made aware of this change, and has declared, "I like where their head is at with this one!"
Carry on.
#5
From a themer's perspective, I find that grouping the fields vertically makes them easier to work with than if they're grouped horizontally (as in the patch in #2). Here's a draft patch that makes the group class(es) semantic and sets up the fields in two columns of three fields, as opposed to three rows of two fields each.
This change would require that we add some CSS to support column spacing (instead of the container-inline class currently used) via the newly added semantic classes, which should probably go in the project_issue.css file (as opposed to in Bluecheese itself). What I currently have in mind is the two columns showing some separation, with each element in its respective column left-aligned. I've also toyed with adding a light gray background to either column to make it stand out more.
I'd love some feedback on these changes. Thanks!
ETA: Oh, and I moved the issue tags into the field group; it seemed to make sense up there.
#6
Can you provide a screenshot?
Thanks!
-Derek
#7
#8
#9
I was waylaid by work and holidays; here, finally, is the requested screenshot (very minimal theming; just showing structure/position).
#10
Cool, thanks. That helps me understand what you're proposing. However, bumping to needs work because:
A) We can't have project_issue.field_group.inc being aware of the issue tags field, since that's just a d.o customization, not something provided by project_issue.
B) If we're going to switch to these semantic classes on the field groups, it'd be nice to have the CSS that makes the UI visually appealing directly in project_issue.css instead of only turning semantic into functional via bluecheese.
C) I think the actual layout of the fields in screenshot #9 doesn't make as much sense. I'm not sure #2 is perfect, but I suspect the single most frequently-changed field is the issue status, so that should be the most obvious (even though that's not how it is on d.o right now). I also tend to like to group the things that are project-specific together (component, version and assigned), separate from the things that are site-wide (category, priority, status).
#11
Just wanted to say that 'version' and 'component' fields both refer to the project and help narrow the spec, so it feels natural to be grouped together and best grouped and listed along the 'project' field itself too.
For similar reasons I feel that 'category', 'priority' and 'status' belong grouped together. They describe the issue. 'assigned' feels a bit off, but if I was asked to group it with one of the fields, then that field would be the 'status' field.
So, I would either go with:
[ Project o ] [ version v ] [ component v ][ category v ] [ priority v ] [ status v ] [ assigned v ]
or:
[ Project o ][ version v ] [ component v ]
[ category v ] [ priority v ]
[ status v ] [ assigned v ]
#12
I like having extra space for Project, so perhaps:
[ Project o ] [ version v ] [ component v ][ category v ] [ priority v ] [ status v ] [ assigned v ]
?
Note: that's almost exactly what we have now on d.o, other than moving assigned from the first row down to the 2nd. However, I agree assigned makes more sense next to the status, so +1 on that.
This should really be settled via a holistic UI/UX review of project_issue. Added a link to this issue to #1545952: [META] UI for updating an issue in D7 so this doesn't get lost.
#13
Note: 2nd option in #11 makes status and assigned more prominent on their own row, and those are the 2 most likely to change. In that sense, it's better than #12.
#14
Well, the main reason I proposed the two different mockups in #11 was to account for mobile and smaller screens with not much horizontal space to spare. You can add that to the +s of the 2nd option ;)
Also, I would really like to see the 'Assigned' field turn into an autocomplete that accepts uids/usernames. That way we could extend its use for the 'needs review' and 'postponed (more info required)' statuses.
OTOH, sticking it next to the 'Status' field gets in the way of implementing the 'duplicate of' feature I suggested over at #44162-32: Relationships between issues: support for parent issue and related issues (unless we hide it in that case).
#15
...and do keep in mind that we need to be thinking ahead for where we'd accommodate the 'blocks'/'depends on' field from #569552: Provide a mechanism for issue meta discussions
#16
@klonos: Any kind of 'blocked on' or 'depends on' field is more for #44162: Relationships between issues: support for parent issue and related issues and I don't think we need to get too concerned about that until we're implementing it. There's a fine line between "thinking ahead" and premature-optimization or over-engineering. ;)
#17
We discussed this at length with dww, Bojhan and yoroy, and decided that for initial launch we will recreate the order of fields we currently have on the comment form on D6. This order is familiar for everyone, we'll have less changes and less new things for people to get used to (and be unhappy with) once we launch on D7. We do have enough changes already.
Updating the summary accordingly. For specific ideas/improvements for the current issue status update UI please open separate issues, which will be post-launch tasks.
#18
I think this is all we need on the issue side.
Something about the weights isn't quite right when I rebuild my site locally ... but perhaps that's because there's a bug in how the issue version field is being created.
It'd be nice to tweak the CSS some more, but we're at least closer to what we really want with this.
#19
The weight problem was from weights associated with the fields themselves when they were created. That's fixed here.
Do we actually want the issue title inside that fieldset? That's what we have for the D6 UI, but it seems really wrong on the edit tab. Screenies attached. This patch leaves title out of the fieldset, but it's trivial to put it back.
#20
Title outside of the fieldset looks good.
#21
Great. Based on some IRC discussions, decided to remove the "container-inline" class from the field group definitions, use an "issue-settings" class, and add our own CSS to make the UI compact:
http://drupalcode.org/project/project_issue.git/commit/f2a3464
I think bluecheese is going to want to limit the width of various elements. E.g. if someone makes a particularly long component name it breaks the layout.
But, otherwise, I think this is done, so I'm calling this fixed.
p.s. I also pushed a fix to drupalorg to deal with how that "Descriptions of the Priority and Status..." thing is being injected:
http://drupalcode.org/project/drupalorg.git/commit/4b170fe
#22
Actually, I decided that the max-width should just be here, not bluecheese:
http://drupalcode.org/project/project_issue.git/commit/e8a1589
#23
Automatically closed -- issue fixed for 2 weeks with no activity.