Community
Participate
Working Groups
The header is important because it is always visible and needs to provide a concise and editable summary of the task.
Created attachment 137189 [details] proposed design
Created attachment 137190 [details] proposed design
Created attachment 137191 [details] cramped button Steffen: The submit button is looking a little cramped to me. Could you try the default spacing and we can tweak from that? Awesome that you figured out how to make this position work!!
> Steffen: The submit button is looking a little cramped to me. Could you try the > default spacing and we can tweak from that? I can look into that. Forms has hard coded constants for the layout and it's a bit tricky to get the toolbar items work properly cross platform but I can look into that.
Thanks. It will also help perception on Windows, since with the current size the button currently looks like it has shrunk by a third.
All manual size hints that I have tried seem to be ignored by Win32. I think we need to add some padding to the image if we want to make the button bigger.
Interesting. Could you try to stick in a wizard image and see if that works? A concern I have about removing the Submit from the Actions section is that the user now has to mouse far left. Should we consider having it in both locations?
In response to: bug 274790 (In reply to comment #20) > Created an attachment (id=137312) > Proposed screenshot of inserting 'submit' action on top-right > > (In reply to comment #19) > > Alex: To briefly address your accusations, no we do not have proof that this > is > > better UI nor do we have user study data, or the resources to perform another > > user study on Mylyn. > > OK. So citing a 'bigger is better' report doesn't particularly address this case > then, either. The UI research from Microsoft that lead to the "Scenic Ribbon" UI in Office 2007 and Windows 7 indicates that frequently used actions should have bigger buttons. The idea is similar to that used by Apple, e.g., with iTunes having a large Play/Stop button. I agree with these results unless we see some results to the contrary. If needed I could dig up the actual research results. > > * The button needs to be big enough to hit easily, since it is equivalent to > > Send in an email editor > > This is basically the point that I have problems with. There's pretty much no > other UI guidelines (for any app/os) that says something like 'Make the most > used button bigger than others'. In a dialog, do you make 'OK' bigger than > 'Cancel' because you think that's most frequently used? What about any of the > other operations/toolbars/actions in Eclipse? Do you make the Git icon that much > bigger because I'm always using Git? > > The point is that this 'requirement' is a somewhat arbitrary decision and not > actually based on any key metrics. In fact, it's perfectly possible for the > submit button to be added to the existing icons on the top-right, as the > attached shows. Arguably, that provides a more consistent user interface than > the split view above (although note this was put together with a cut-n-paste > image editor, rather than through code, so the position of the icon in the list > is suggestive rather than prescriptive). One could imagine it being on the > right-most icon of the actions to ensure a consistent location. > > The further can-o-worms that opens up is what happens when others ask for > different icons to be put there. With the massive-sized button (relatively) > taking up that much space, you won't get more than a few icons before the > toolbar becomes full. So what criteria are used to decide whether to put > something here, especially if others then start contributing actions to this > point? Note that arguments like 'it's the most frequently used ...' then start > to go out the window if others can add any other buttons to this list, or the > set grows over time (they can't all be the most frequently used). > > Having already got action-specific buttons in the top-right of the editor, I > don't really see any reason (or special-case) why the 'submit' button can't also > be there. Eclipse users are already familiar with view actions (e.g. JUnit's > re-run tests, which gets used a lot more than the 'submit' bug does; debugger's > pause/play/resume; enable/disable breakpoints; minimise/maximise buttons). These > are all of equivalent size, and there's no suggestion that these aren't easy to > hit. > > Lastly, Mylyn's editors already diverge from the standard Eclipse model. I don't > think there's any great benefit in making that division wider than it otherwise > needs to be. Users are familiar with view actions, and though infrequent, other > editors support icon-based actions in the top right (update site has 'build' and > 'help' in top-right; PDE's manifest editor has 'play', 'debug', 'help' etc.). In > other words, to date, no editor has had any kind of clickable action on the top > left; and none have a 'button' anywhere at the top of the header, preferring > instead the icon-based actions. Regarding the divergence, this is something that we discussed at length with the UI designers of Eclipse Forms, who are now working on the Jazz project. We are all in the same boat, in terms of the PDE implementations not being representative of the functionality we need for a collaborative application. As far as I can tell we have diverged less from the PDE style usage of Forms than Jazz has. In my opinion such diversions are justified if they significantly improve usability. But I agree that each diversion has to be evaulated. I just did a quick image search, and Jazz also decided to make the Submit/Save action be a button: https://jazz.net/library/content/docs/platform-overview/images/work-item-editor.png Steffen: Take a look at that screenshot. It looks like they follow our previous pattern of making the left-hand label be "<kind> <id>". However, they give it a drop-down, which means that it's not useless and redundant information with the editor tab text. I have been wanting us to have a pull-down menu to of this sort in order to address the fact that the popup menu is not discoverable. We should discuss this further. > So, I ask again - why do we have this pseudo requirement of 'it must be a big > button'? What gives the 'submit' button this much specialness that it's worth > diverging further from the Eclipse standards? If there's no data to show it's > better as a button (but rather a gut feeling) then why not try to keep the > current standards in place and see how that goes? There's already actions that > are repository-based here (refresh, show in browser, new task etc.) so it will > fit in well with those kind of actions - but at the same time, being standard > and unobtrusive yet still facilitating easy submission throughout the UI > regardless of scrolling location. Alex: There is data. There are a variety of publications about this, but as far as I know most of them boil down to Fitt's Law (http://en.wikipedia.org/wiki/Fitts's_law). I can dig up the readings from my HCI classes if that would help. If you have found research or usage results to the contrary please let me know. Otherwise, I think we need to agree on the statement that "bigger affordances are easier to hit with the mose" in order to continue this discussion, or agree to disagree? Then we can evaluate whether the benefit of a bigger button justifies the inconsistency with the Forms UIs that Eclipse SDK users are accustomed to.
(In reply to comment #8) > In response to: bug 274790 > > > OK. So citing a 'bigger is better' report doesn't particularly address this case > > then, either. > > The UI research from Microsoft that lead to the "Scenic Ribbon" UI in Office > 2007 and Windows 7 indicates that frequently used actions should have bigger > buttons. The Microsoft Scenic Ribbon is actually a pretty good example of a horrible way of doing things. Instead of having actions that are visible, and usable, they go and hide them across a number of different locations (different tabs, drop-downs that are represented with about 3 pixels worth of space) and different sized icons for actions like 'check names'. It's god awful. If Mylyn is striving to emulate the ribbon, my efforts on trying to raise bugs or discussions on the UI might as well stop now. > The idea is similar to that used by Apple, e.g., with iTunes having a > large Play/Stop button. I agree with these results unless we see some results > to the contrary. If needed I could dig up the actual research results. The iTunes Play/Stop button isn't significantly different in size/style to the surrounding rewind/fast-forward buttons. They certainly don't look like completely different styles. Partially that's because iTunes is trying to emulate a hand-held remote control, where the buttons are different sized (and yes, there is a parallel - the large buttons are more frequently used in physical devices. That doesn't necessarily imply that the same is true of computer software). In fact, iTunes and its style has been consistently about trying to represent an actual physical device (indeed, that's Apple's HCI guidelines on the brushed look at one point). I'd be interested if you could dig up actual research results on people liking the ribbon though. Like clippy, the research might have been good but that doesn't mean acceptance by end users. > > > * The button needs to be big enough to hit easily, since it is equivalent to > > > Send in an email editor > > > > This is basically the point that I have problems with. There's pretty much no > > other UI guidelines (for any app/os) that says something like 'Make the most > > used button bigger than others'. > > > > Lastly, Mylyn's editors already diverge from the standard Eclipse model. I don't > > think there's any great benefit in making that division wider than it otherwise > > needs to be. Users are familiar with view actions, and though infrequent, other > > editors support icon-based actions in the top right (update site has 'build' and > > 'help' in top-right; PDE's manifest editor has 'play', 'debug', 'help' etc.). In > > other words, to date, no editor has had any kind of clickable action on the top > > left; and none have a 'button' anywhere at the top of the header, preferring > > instead the icon-based actions. > > Regarding the divergence, this is something that we discussed at length with > the UI designers of Eclipse Forms, who are now working on the Jazz project. We > are all in the same boat, in terms of the PDE implementations not being > representative of the functionality we need for a collaborative application. > As far as I can tell we have diverged less from the PDE style usage of Forms > than Jazz has. In my opinion such diversions are justified if they > significantly improve usability. But I agree that each diversion has to be > evaulated. I just did a quick image search, and Jazz also decided to make the > Submit/Save action be a button: > https://jazz.net/library/content/docs/platform-overview/images/work-item-editor.png That looks less bad than the current proposed Mylyn one, because the 'save' button doesn't have the extra padding and icon, so it fits in a smaller space. But I'd argue consistency is more important than size in this case. As an example, I often work with ~10 perspectives open at any one time. If I have them configured to show 'show text and icon', which is the Eclipse default, I get to see maybe three of them at any one time. If I have 'show as icon only', then I get to see - and click on - any of them. Just because an icon's not big, doesn't mean it can't have good results. > > So, I ask again - why do we have this pseudo requirement of 'it must be a big > > button'? What gives the 'submit' button this much specialness that it's worth > > diverging further from the Eclipse standards? > > Alex: There is data. There are a variety of publications about this, but as > far as I know most of them boil down to Fitt's Law OK, so we need to start getting more concrete here. Bigger buttons are easier to hit than smaller buttons. However, they are not *much* easier to hit. The advantaged amount is pretty minimal, especially when you're used to it. From the wikipedia example you cite: * It describes untrained movements, not movements that are executed after months or years of practice Many people using Eclipse will be capable of clicking on the same sized icons as anywhere else in the application. Using a theory based on untrained users doesn't really hold much water when you consider the end user group of Eclipse applications, particularly those used to filing bugs. The button-as-icon is no bigger/smaller than a checkbox; are you suggesting that these checkboxes should be similarly large? Furthermore, consistency of an application is often far more important than absolute size. That's the big concern I have here - one aspect is overruling other aspects, and I don't believe that they are in the right order. > Then we can evaluate whether the benefit of a bigger button justifies the inconsistency > with the Forms UIs that Eclipse SDK users are accustomed to. That has been exactly my point over the last few responses. My belief is that it does not, regardless of whether a big button is easier to hit than a little buton, since I am capable of using Eclipse which has similarly sized icons for pretty much everything else.
Created attachment 137439 [details] current implementation
Created attachment 137731 [details] header ideas Thought I'd chime in here as well. I think that we need to retain the task kind on the left (and id) and make the id selectable (label). We could loose the repo name and perhaps make the repo icon open the settings dialog when clicked (hovering could just reveal the repo label). This screenshot shows an alternate button layout as well and shows the look with the attributes in the section header. Thoughts?
Having the submit button on the right makes a lot more sense than on the left. I still contend it doesn't need to be a button; if it is going to be a button, can we have a simple text one without the submit icon? Or better yet, have an option (like the perspective tabs) which allows text/icon/text+icon for the rendering. Robert, I'm not sure what else is different. I seem to recall that the 'refresh' icon was in the action bar; that seems to have moved down next to the next section header. I'd much prefer keeping all the actions together in the top-right where they can be collected. To be honest, I've never used the 'set active task' from the editor, and I've never used the calendar drop-down. To increase space, if needed, I'd prefer to lose those than other icons like the refresh and submit. But I still contend we don't actually need the whole button and the cut down icon (as in https://bugs.eclipse.org/bugs/attachment.cgi?id=137312) is both compact and usable. I'd really like to see some stats from common Mylyn users (like yourselves) about how different a button and icon hitting really is; for novice users, there might be a difference but for experienced users I think the difference would be negligible.
Created attachment 137734 [details] another proposal
(In reply to comment #11) > Created an attachment (id=137731) > Thought I'd chime in here as well. I think that we need to retain the task kind > on the left (and id) and make the id selectable (label). We could loose the > repo name and perhaps make the repo icon open the settings dialog when clicked > (hovering could just reveal the repo label). This screenshot shows an > alternate button layout as well and shows the look with the attributes in the > section header. Thoughts? I think the repository label contains important information and should be in the always visible part of the header. Rob, what do you think about moving that to the left? The bug id is already displayed in two other places (editor tab, status bar) therefore it is not necessary to have it in the header. I would like to reserve the header of the attributes section for information that is in the attributes section, e.g. the component and product for Bugzilla. That way these details could be made visible when the section was collapsed. With the tall priority icon there is also not enough space in the header without making it look very cramped if there is only a single row. (In reply to comment #8) > Steffen: Take a look at that screenshot. It looks like they follow our previous > pattern of making the left-hand label be "<kind> <id>". However, they give it a > drop-down, which means that it's not useless and redundant information with the > editor tab text. I have been wanting us to have a pull-down menu to of this > sort in order to address the fact that the popup menu is not discoverable. We > should discuss this further. I considered adding the drop-down in the last release but I find that it gives the header an odd look. It is also not clear to me what kind of action to expect in the drop-down. My sense is that Eclipse users are familiar with context menu since it is otherwise difficult to use a lot of the functionality, e.g. the Team menu which is not in the menu bar or contributions to the additions group. We can investigate adding a Task menu to the menu bar that is only visible when the Task Editor is active. That would make the actions from the context menu easily accessible and discoverable. The main reason why I am in favor of separating the submit button from the buttons on the right is to avoid accidental submits. That said, having a textual label on the button helps to clarify it's effects and also makes it stand out. That is probably sufficient to avoid accidental submits and if button is moved to the right we could maintain better consistency with other Forms editors while still getting the benefits of a large, always visible submit affordance.
Created attachment 137737 [details] left vs right
Created attachment 137738 [details] patch
I have committed the patch to experiment with having the button on the top right of the editor. What I like about this approach is that separates the repository label which looks like a title from the actions on the right. Let me know what you think. It's easy to revert the change.
Created attachment 137757 [details] The submit button is cuttoff on the button on windows vista
Hello? Is this thing on? Why don't we ditch the button and have it as an icon, rather than fighting for ways to get the button to render properly? Yada yada yada UI experience report etc., but realistically there does not appear to be any difficulty for an average Eclipse/Mylyn user to be able to hit an icon instead of an overly-massive button that renders at a different pixel height and style from a simple iconic representation. So, has anyone actually *tried* to represent this as an icon and reported any difficulty in doing so? Or are we just brushing that idea under the carpet on point of principle?
(In reply to comment #19) > So, has anyone actually *tried* to represent this as an icon and reported any > difficulty in doing so? Or are we just brushing that idea under the carpet on > point of principle? If someone tries this, and says 'Yeah, I have difficulty with this' I'll shut-up.
(In reply to comment #14) > We can investigate adding a Task menu to the menu bar that is only visible when > the Task Editor is active. That would make the actions from the context menu > easily accessible and discoverable. That would be great - many people don't end up looking at context menus but a menu which is shown when the editor is active would address one of my concerns about the inconsistency that Mylyn brings to the UI experience.
Created attachment 137872 [details] mac screenshot (In reply to comment #18) > Created an attachment (id=137757) > The submit button is cuttoff on the button on windows vista Also on mac
The Task Editor had a submit button icon in the toolbar a while back but it was taken out (bug 266600 comment 2). After discussion with other committers I have decided to revert the changes and remove the submit button from the toolbar for 3.2. We are out of time to fix the remaining UI nits (comments 18 and comment 22) and haven't converged on the best placement of the button. We'll revisit this UI change in the next release cycle. For now the recommended option for submitting without scrolling to the bottom of the Task Editor is to use Alt+S key-binding. Note that the toolbar is extensible through the org.eclipse.ui.menu extension point and I could probably be convinced to make that a sandbox feature to get more usage mileage before this goes into the main stream.
I have opened bug 278705 to track adding of a Task menu to the Task Editor.
Resetting to 3.2 for discussion, as I have a concern that in the current state we have made some changes without adding substantial value (e.g., always visible Submit button) so I think that we have to improve on that or revert the shaded portion of the header to the one from Mylyn 3.1. (In reply to comment #19) > So, has anyone actually *tried* to represent this as an icon and reported any > difficulty in doing so? Or are we just brushing that idea under the carpet on > point of principle? We had that going for a while in the last release cycle and the results woren't great, so we removed it. It just too different an action than the other stuff that we have on the toolbar and as Steffen said it was too easy to hit accidentally. Regarding the activate and schedule actions, those are key to the focusing parts of the UI, we got a lot of feedback that resulted in their current locations, and I think we need to retain them somewhere prominent. But we could probably inline the Open with Browser and History actions into the editor header as hyperlinks in order to make more room. I'm concerned that with the latest iteration we've lost some of the benefits that we tried to introduce. For example, the repository is now extremely prominent, but our model of the typical user is that they only access one or two repositories. By contrast, open source contributors and all of us are likely to have multiple repositories since some of us have a dozen. I'm not saying it's necessarily bad, and I personally like it because I work with so many repositories, but we definitely need to have another design discussion before committing to this. Consider the feedback and other constraints, here is what I would like us to try. We may need to have a design discussion before committing to this, in case there are any challenges like showing the button. I can create a mockup in case that helps. The biggest change here is to accept the fact that the Submit button was not working on the left and put it on the right. Putting it on the right takes the very important corner real-estate from the Activate button, which seems worth trying on the left. This also creates the nice consistency of putting all the repository specific actions together. [Activate] Bug 111 Eclipse [Open with Browser] [New Subtask] [Synch] [Submit] * The Open with Browser button becomes the current button that's on the far-left of the header, i.e., the one with the repo branding overlay. * The Submit button is the large button format unless this is not feasible. * The Schedule drop-down moves to the right-justified portion of the collapsed Private section * The History button can stick around if it's too hard to hyperlink the "Modified" attribute.
I am using the activate quite a lot, so moving it might confuse users like me. However the beauty is that the new action is now at the spot where I am looking for an old one, so I immediately stumble over the new one and will probably realize that it's there. But the activate itself on the left...I think having just the dot might be a bit weird...maybe we can make (additionally) the whole "Bug 111" clickable (toggle) to show activation state (some custom widget that does not look like a rectangular button but more like the draggable thing we had so far in that corner, but is in fact something that can be toggled)
(In reply to comment #25) > I'm concerned that with the latest iteration we've lost some of the benefits > that we tried to introduce. For example, the repository is now extremely > prominent, but our model of the typical user is that they only access one or two > repositories. By contrast, open source contributors and all of us are likely to > have multiple repositories since some of us have a dozen. I'm not saying it's > necessarily bad, and I personally like it because I work with so many > repositories, but we definitely need to have another design discussion before > committing to this. That's a good point. I was trying to free up additional space for the submit button. The task label also adds some redundancy without adding much informational value, e.g. Bugzilla tasks always display "Bug". I have reverted the changes for now and moved the repository label back to the right side. I have removed the bug id from the header though since it's already displayed in the editor title tab and in the task editor summary line. > Consider the feedback and other constraints, here is what I would like us to > try. We may need to have a design discussion before committing to this, in case > there are any challenges like showing the button. I can create a mockup in case > that helps. The biggest change here is to accept the fact that the Submit > button was not working on the left and put it on the right. Putting it on the > right takes the very important corner real-estate from the Activate button, > which seems worth trying on the left. This also creates the nice consistency of > putting all the repository specific actions together. > > [Activate] Bug 111 Eclipse [Open with Browser] [New Subtask] > [Synch] [Submit] > > * The Open with Browser button becomes the current button that's on the far-left > of the header, i.e., the one with the repo branding overlay. > * The Submit button is the large button format unless this is not feasible. > * The Schedule drop-down moves to the right-justified portion of the collapsed > Private section > * The History button can stick around if it's too hard to hyperlink the > "Modified" attribute. That sounds like a great proposal. Unfortunately I do not have the bandwidth to incorporate this change for the 3.2 release but would be happy to work on this for the next release cycle.
I have moved the planning toolbar item from the Task Editor header to the Private section so that it is closer to the rest of the planning information.
We were able to address the remaining layout nits, so I have committed the changes proposed in comment 25. The next weekly build will have the streamlined header with activation button on the left and the submit button on the right: https://bugs.eclipse.org/bugs/attachment.cgi?id=138230 . I have decided to leave the history action for now since there is now obvious other affordance. I am concerned that making the Modified date a hyperlink would not be obvious enough and not necessarily backwards compatible since a task may not have a modification date but still provide a history url. Note that I have removed all separators from the toolbar. I am not sure if we still need any now that the activation and schedule buttons have moved but that is certainly up for debate. Please post here if you have any thoughts about the new layout.
*** Bug 279142 has been marked as a duplicate of this bug. ***
In latest Mylyn good changed interface. I propose next: - move bug title to up line (replace "Bug" word) - move new big button with priority value to up line (header) right to "activete task" button - remove "Priority" line from Attributes (save space) - not collaps Action and People windows - remove button Submit from Actions (button exists in header line)
As per discussion on today's conference call: * The task ID has moved back into the header, e.g. Bugzilla displays "Bug 272093". * The header now uses a StyledText widget which makes the task ID selectable and copyable. This may cause confusion so we may want to revert that change.
Fixed: * Summary part maintains selection when unfocused * The task editor now supports the F5 key-binding to refresh
Proposition: * show closed tasks in Task list n in task exists changes (added comment, for example). This need work if activate option "Filter complited tasks". * rename "Filter complited tasks" to "Hide completed tasks"
Steffen: *Great* work. It's fantastic that you managed to get all these improvements in, and I realize how hard some of them were to get right. Also, having the left header text selectable seems like a very good compromise and I think that we should stick with that change. Just make sure to document it in the New & Noteworthy, mentioning that you can double click to select the ID. Anton: bug 211011 is probably the best place to comment on Task List suggestions. Good suggestion on changing "Filter" to "Hide", please comment on that task and we should be able to do that.
Thanks Mik. Looks like we are all done here.
