Community
Participate
Working Groups
Let's use this bug to collect and work on ideas of how to do it. Regarding the Attachments section: I suggest collapsing by default, then putting in parentheses the number of attachments, e.g.: * Attachments (3) * Attachments (0)
Rob: I think that the CC stuff should be exactly where you put it, but in it's own Section (i.e. a section like Actions, called People for now, to the right of the Actions section). I also think we should move Assigned to and Reporter to that section. The top is looking good, but try to get rid of some of the blank vertical space between Summary and Status.
Update: Improved density of attributes/people/actions sections and change layout position of some sections.
Created attachment 51128 [details] mylar/context/zip
Looking great, but I think we need to leave Actions on the left and have Peopel on the right.
Don't you think it would be more compact representation if you'd use popup dialogs to edit cc list, keywords, dependent and blocked bugs and just show them all as links with [edit] button next to that section. I kind of hate to see "assignee" and "reporter" info at the bottom. Reassign bug to "[ ]" or to "default assignee" should not be separate actions. You should be allowed to edit it directly, and perhaps have button or link to select default assignee (see Jira web interface for this). I think it would make more sense to have the following layout at the top (if you want to stay with single column) [id] [opened] [modified] [status] [resolution] [summary] or [id] [opened] [modified] [summary] [status] [resolution] not sure if priority is needed there. BTW, priority drop down does not have border.
One more thing. It doesn't seem make sense to have separate section for dependencies. It would take less screen space if these fields would stay within Attributes section.
I really like having all the "People" stuff next to the actions, because the actions affect the people. However, as Eugene I'm not thrilled having it at the bottom. So we should consider moving both up. I think that it's really important to see as much of the CC list as possible, because that's who you know your comments will get "sent" to. That said it could be better to have an "Edit" or "Add/Remove" buttons for that section, consistent with how the PDE editor allows tables of this sort to be edited. Regarding Eugene's other proposed changes, I think we need to consider them all for the next rev. The one I think that's important to do today for 0.7.0 is to move the dependencies back into Attributes. I realize that I originally suggested pulling it out because of how they were bloating, but now that Attributes is so compact it would be better to get them in there and avoid making people do the additional click.
Mik, what about "reassign" actions?
I like your suggestion for that. Even if we don't have the default assignee in the task data from Bugzilla, we could simply stick in "<default assignee>" into the "Reassign to", and that gets rid of a whole line :) Btw, I think we could start imagining what it would be like to put the Actions and People right no top, because we're all wasting time scrolling down. So the order would be something like: * [header] * [attributes] (collapsed) * [actions] [people] (expanded) (expanded) * [comments] (all new expanded) * [description] Alternatively we could auto-scroll to new comments.
(In reply to comment #9) > I like your suggestion for that. Even if we don't have the default assignee in > the task data from Bugzilla, we could simply stick in "<default assignee>" into > the "Reassign to", and that gets rid of a whole line :) Two lines actually. > Btw, I think we could > start imagining what it would be like to put the Actions and People right no > top, because we're all wasting time scrolling down. So the order would be > something like: > * [header] > * [attributes] (collapsed) > * [actions] [people] > (expanded) (expanded) > * [comments] > (all new expanded) > * [description] You forgot attachments. Another thing that probably makes sense is to move submit actions into a popup dialog. So, could have [Submit Comment] and [Submit...] buttons in the editor. First button will just act as default submit (not changing status, just adding comment) and second will show a dialog with all those radio buttons. PS: what about field ordering in the header lines? PPS: are you still considering two column layout?
Setting for 0.9, at which point we should have the editor layout stabilized.
I'll do the editor re-arrange here asap so we can try it out in the next dev build.
Because the people section can be much higher than the actions section, the proposed layout can end up with a large amount of whitespace (under the actions). Perhaps if we look at Eugene's suggestion regarding pop dialog.... Personally I'd like to leave the editor's layout (order) as is so that (recent) new users have some consistency/familiarity moving into the 1.0 release. Then we could revamp post 1.0.
Yes, I think that a revamp of the magnitude of moving the people section has to wait post-1.0, but we can do it early in the 2.0M cycle. For now just focus on incremental improvements for getting the density up, and on bug 142039.
*** Bug 137627 has been marked as a duplicate of this bug. ***
Update: Committed use of new form headers, work in progress....
Added branding icons to headers...
Progress now shows in form banner icon location during submit.
Fixed TasksUiUtil merge problem. Moved attach context. Removed space after planning section in new bug editor. Etc.
Rob, Mik, don't you think that sections like "Personal Planning" and "Notes" are redundant on Planning tab? There is already header that says Planning, and "Notes" should be really just a label before the text area.
Created attachment 59214 [details] current look of the Mylar editors It seems like Status: fields reads as "New Priority", etc. Also note non-flat looking controls in local task planning tab and missing border for the url field. Date fields on local task planning tab are using several different date formats. Neither of those formats match format used for Bugzilla or JIRA editor. Estimated time entry field is way too long. The spinner control with "hours" label should probably sit on some nested panel and should be not bigger then 3 or 4 digit places.
Rob: of Eugene's points we should try hard to get all but the 3rd into the release. Point (1) will be the trickiest.
Rob: we need to indent "Status". Both a 3.2 and 3.3 dev build should now be avaiable with the latest.
(In reply to comment #23) > Rob: we need to indent "Status". I think that labels are indented too far from the values. You should reduce whitespace between label and the value, but increase whitespace after the value.
(In reply to comment #24) > I think that labels are indented too far from the values. You should reduce > whitespace between label and the value, but increase whitespace after the value. +1
(In reply to comment #25) > +1 On a second thought, sidebar would work better for those attributes. That sidebar can be also made collapsable, and comments and other sections could sit in their own scroll pane...
For M1 have Improved spacing and label color.
Should we make the description collapsed by default if this is not the first time the bug is opened? I find that most of the scrolling I have to do is due to long descriptions, and if collapsed it will be an easy click away...
(In reply to comment #28) > Should we make the description collapsed by default if this is not the first > time the bug is opened? I find that most of the scrolling I have to do is due > to long descriptions, and if collapsed it will be an easy click away... I would prefer to scroll every time, then every time expand collapsed sections. It is already quite big issue for collapsed attributes section, and users section moved down. From my observation, really big descriptions came from the stack traces. So, if we can collapse stack trace only or show top N frames (and then link "show all")... On the other hand, Task Editor should scroll to the new comments automatically and it doesn't do that now.
(In reply to comment #29) > I would prefer to scroll every time, then every time expand collapsed sections. > It is already quite big issue for collapsed attributes section, and users > section moved down. I agree with this. I find myself having to expand the attributes section often and this interrupts my flow. I am not sure if this is a personal thing, but I am used to scanning (and scrolling) a page with a lot of information and quickly finding what I want. If I don't find the information and have to use an alternative way to show it (e.g. expand the attributes section), it's a bigger problem. Perhaps I will get used to this with time, but it's still a problem for me after using Mylar for many months.
BTW, I think it is acceptable to collapse "New comment" section. I'd say it is used less frequently then attributes section.
We removed the collapse from New Comment so that it could fill vertical space when available, which is very helpful for writing long comments. Perhaps we could set its minimum height to be smaller. I also experience the pain of frequently having to click the Attributes section. However, the Attributes sections can get *very* long (e.g. Bugzilla with lots of Attributes and time tracking on) so we have to tread carefully there, but should try to figure out something better for 2.0. Let's leave the description expanded, as Eugene points out the problem is dominated by stack traces, which we might be able to add custom folding support for (bug 166402, but note it's not on for 2.0).
(In reply to comment #32) > We removed the collapse from New Comment so that it could fill vertical space > when available, which is very helpful for writing long comments. Why don't you uncollapse it when space is available? > Perhaps we could set its minimum height to be smaller. Please don't do that. I think it is better to collapse it and increase the height instead. Ideally it would be the best if user could resize comment area, but we'll need an JFace/Forms wizard to help us with that. Though there is an easy "hack" that may work for the time being. I think I showed it to you or to Rob at EclipseCon. so, the idea is to have "increase" "decrease" actions on comment section bar, so those actions would allow to adjust the height of the comment area. > I also experience the pain of frequently having to click the Attributes > section. However, the Attributes sections can get *very* long (e.g. Bugzilla > with lots of Attributes and time tracking on) so we have to tread carefully > there, but should try to figure out something better for 2.0. Should I repeat again that we should move those attributes into the side bar? And maybe even use separate tab for all other fancy atributes, as wel as for attachments.
Should we move the History button to the header toolbar? Also see bug 142906.
Seems to me like a good place for it.
(In reply to comment #34) > Should we move the History button to the header toolbar? Done.
Major improvements made for 2.0, but this is an ongoing effort so leaving open.
We also need to address the duplication of the task summary as seen in the local task editor tab, banner, and summary field. Perhaps we could make the banner editable if we can retain the message area or resize it dynamically in event of a message. Thoughts?
Some ideas on merging the planning page with the normal page came up during conversation yesterday. We could create an extended editor hearder that contained the key personal planning information (scheduled date, collapsable notes area). This would make the personal/repository split explicit.
Need to defer: http://wiki.eclipse.org/index.php/Mylyn/3.0_Plan#Deferred_Items
(In reply to comment #5) > Don't you think it would be more compact representation if you'd use popup > dialogs to edit cc list, keywords, dependent and blocked bugs and just show them > all as links with [edit] button next to that section. > > I kind of hate to see "assignee" and "reporter" info at the bottom. I think it'd be really cool if users could reorg sections so those users could set up the default to show Actions/People right below the status summary, then custom fields & flags, then New Comments, then comments in reverse order (latest first). > Reassign bug to "[ ]" or to "default assignee" should not be separate actions. > You should be allowed to edit it directly, and perhaps have button or link to > select default assignee (see Jira web interface for this). ... or Reassign to default or [ ] > I think it would make more sense to have the following layout at the top (if you > want to stay with single column) > > [id] [opened] [modified] [status] [resolution] > [summary] Actually, I'd like to see the first two rows of the display docked so they're always available even if scrolling "past" them in today's interface. That would make it easy to see the most critical information at a glance. I would also want to see Severity included there too, however. Then again, if we had the ability to move fields around as well as blocks, this would be trivial and would allow users to rearrange the display in the most meaningful way to help them. (In reply to comment #9) ... > * [actions] [people] > (expanded) (expanded) > * [comments] > (all new expanded) > * [description] > > Alternatively we could auto-scroll to new comments. I believe it's critical to show the description above comments always, but that's me. What I've done with the web-based UI in the past is to provide links to sections of the bug UI using anchors throughout the web page. The same could be done here or at least by improving the list shown in the outline to be more than description, comments, and new comments (and don't collapse the current bug outline when entering a new comment). It would be helpful if there was a top link, and one for each of the rest of the collapsible outline blocks. ... Thinking through the rest of these changes, I am beginning to think the way I'd really like to see it is if each field (comments as one field or comments as old vs. new each as a field) should be movable into blocks and allow users to define their own blocks along with where fields are placed in those blocks by default. Yes - it adds significant complexity, but tremendous flexibility giving the user full control over where things are placed, not just whether or not a block is expanded / collapsed.
Oh - one more thought - maybe part of the solution is to break up some of the fields into tabs and provide an "All" tab which contains all the data for those who would rather not look at the bug through tabs.
We'll take a pass through the editor and task list design for Mylyn 3.2.
*** Bug 289045 has been marked as a duplicate of this bug. ***
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
