Community
Participate
Working Groups
The two UIs have redundancy and there is a user expectation to be able to open a task by ID from the search page. We can consider leaving Open Repository Task but having that action set off by default.
This either needs to be completed for 2.0 or the action needs to be visible in the perspective again.
Need to hide Ctrl+Shift+F12 keybinding along with this.
-1. "Open Repository Task" is crafted to more specific use case, hence much simpler UI and it also don't open its results in the Search view. So, it hardly fits into the search pages. If you are looking for simplicity, just make possible to use "Find" in the Task List to open repository tasks.
We have a bug for such Find functionality but it is obviously post 2.0. How is the dialog more simple than allowing someone to put an ID/key into search? In my experience that's where people expect to see this functionality because this is how the Web UIs present it.
If I recall correctly, web UI has completely separate page for searching by id (which is kind of in the same line with current separate "open" UI) or use completely obscure "advanced search". Besides, I would expect Search to deal multiple expected results, while "Open..." would open a single thing. So, all in all it would make more sense to merge "Open Repository Task..." with other "Open Task..." dialog, and not with the heavy Search wizard.
The way the web UI works for many issue tracker and project management tools is that if there is a single hit the hit is opened. That's how this would work, and the enter key/id would be common and right under the repository selection. (In reply to comment #5) > So, all in all it would make more sense to merge "Open Repository Task..." with > other "Open Task..." dialog, and not with the heavy Search wizard. Yes, we spent quite a bit of time on the last call trying to figure out a suitable merge for that because it seemed like a promising approach. We could not figure out a way to do that where the UI was clean and retained the key benefit and simplicity of Open Task: the fact that it works across repositories. Willian: please note this since you contributed the UI so it would be good to get your thoughts. If the merge doesn't work to everyone's satisfaction I'm happy leaving the action set in, but I do think that it should be off by default because the less UI redundancy we have the better.
I would think that those two dialogs should merge perfectly. Here is a mockup: Select key/task: [ search entry field ] Matching Tasks: [ list with search results ] Task Repository: [ repo dropdown ] [ Add... ] [x] Add to task list: [ category dropdown] [ Add... ] [Open] [Open in Browser] [Cancel] Adding key/id into search dialog won't be as usable because it will even more clutter already complicated search UI and won't provide handy completion/preview. BTW, current "Open Repository Task" need to be fixed to show preview for inexact task key match (like it works for "Open Task" dialog). This is actually nearly the same to your favorite JDT UI. "Open Type/Resource" dialog is using same idiom, instead of clutter Search UI.
I do not thin the merge proposed in comment#7 is a good idea for the reasons discussed in comment#6. That said I do agree that we want to avoid complicating the Search dialog further. What I have done to address the common use cases is: 1) Add an "Open Repository Task by Key/ID" link to the Search dialog, this pops up the current "Open Repository Task..." dialog. The action set containing the menu command for that dialog is now disabled by default. We ccan still consider a merge down the road. 2) Added a "Search Repository..." action to the Task List which opens up the Search dialog to the Tasks page. This will help some at facilitating the discoverability of both the search and the Open Repository Task actions.
Created attachment 72436 [details] mylyn/context/zip
(In reply to comment #8) > I do not thin the merge proposed in comment#7 is a good idea for the reasons > discussed in comment#6. It is still unclear to me what reasons you referring there? Cross repository is going to work like before and if there is no selection in the matching list that dialog would try to open task with entered id. > 1) Add an "Open Repository Task by Key/ID" link to the Search dialog, this pops > up the current "Open Repository Task..." dialog. Hmm. Hyperlink color is odd again, dialog opened from that link don't preselect repository chosen in Search dialog and it is completely odd that popup dialog jumps on top of the Search dialog and editor is opened under that search dialog. So, you may want to close that search dialog. > The action set containing the menu command for that dialog is now > disabled by default. We ccan still consider a merge down the road. What is the reason for disabling this action? Most of the users are not aware of perspective configuration and the only option for them would be to go trough new link in search dialog, as opposed to action in Navigation menu. > 2) Added a "Search Repository..." action to the Task List which opens up the > Search dialog to the Tasks page. This will help some at facilitating the > discoverability of both the search and the Open Repository Task actions. Hmm. It might make more sense to have that action in popup menu instead. And it should also pickup repository from the current selection and preselect it on the search page. BTW, we need to make repository selection in Search dialog and "New Query/Task" wizards use the same repository labels. Search dialog is now using repository urls and wizards are using labels. Also it would make sense to add "Search Repository..." action to the Task Repositories view.
(In reply to comment #10) > It is still unclear to me what reasons you referring there? Cross repository is > going to work like before and if there is no selection in the matching list that > dialog would try to open task with entered id. This means that the dialog has two very different modes of operating, which equals complexity. > What is the reason for disabling this action? Most of the users are not aware of > perspective configuration and the only option for them would be to go trough new > link in search dialog, as opposed to action in Navigation menu. The reason was to not make as accessible or visible in because the UI is not quite right yet and almost guaranteed to changed for 2.1. > Also it would make sense to add "Search Repository..." action to the Task > Repositories view. -1. That view is intended for configuring repositories, not as a primary view for interaction. So I do not think it is a good idea to enable all the relevant things that could be done to a repository from there, thereby encouraging it to be a primary entry point for functionality rather than configuration. I'm quite mixed about us having added the creation actions to repository contributions for the same reason. What pushed me over the edge on that is the fact that as 'objects' in the UI it makes sense for repositories to have such object contributions.
We're still note done with this UI and it would be great to do some more streamlining and merging of dialogs and functionality and make opening repository tasks a bit easier. I'm reopening this bug since it has some good discussion. We should consider some of these changes for 2.1, hopefully we'll get some additional complaints or feedback about the current UI. Willian: you are the original contributor of the current UI, what are your thoughts on this?
(In reply to comment #11) > This means that the dialog has two very different modes of operating, which > equals complexity. Not quite. However it would make "Open Task" dialog capable of opening tasks that are not in the task list. Also note that these dialogs overlap in 95% of the functionality (i.e. show task history and search trough task in the task list) and the only missing part is to add a missing link when task is not in the task list.
I have added this as a pending UI discuss item: http://wiki.eclipse.org/index.php?title=Mylyn_Meetings
+1, this is a PITA issue for me when dealing with bugs that aren't in my task list (which is often).
*** Bug 198899 has been marked as a duplicate of this bug. ***
It should be as simple as me entering a URL. If I enter something like https://bugs.eclipse.org/bugs/show_bug.cgi?id=197821, it should be detected if it is or isn't in the current lists of tasks. If it isn't, simply pop something up asking me where I want it.
(In reply to comment #6) > Willian: please note this since you contributed the UI so it would be good to > get your thoughts. If the merge doesn't work to everyone's satisfaction I'm > happy leaving the action set in, but I do think that it should be off by > default because the less UI redundancy we have the better. > Sorry for the delay, I was busy and left a lot of bugzilla emails accumulated. Regarding this request, I'm -1. Search dialog and open task have different purposes, IMHO. Search is for advanced use case, e.g, you have a set of task(s) you want to locate. Open task is for quickly opening a certain task, either by typing some keywords, or by entering the ID. Quick and simple. In my own experience, I use open task very much, open repository task sometimes (but enough to need it), and search rarely. Personaly I don't like the search dialog, because: - You type Ctrl+H, and unless your focus are in task list view, it opens the first tab, which in my case is "Remote Search", from RSE, which makes me use the mouse to click the "Task Search" tab, or type Ctrl+Page Down 2 times to advance the tabs. - The dialog is complex, the task search itself because of all its options, and the search dialog too, because of all that tabs. It scares me. I didn't like having the "open repository task" action disabled by default. It took me a while to figure out why it stopped to work, and I think it is essential, although not frequently used. Having said that, I don't see advantages merging something with something so complex like search dialog. Perhaps there is a better chance to merge "open task" and "open repository task", dialogs instead, but the problem is the interface. Personally I didn't like the current "open repository task" dialog. I don't think it has to be similar to "open task", because they serve to different purposes. "Open repository task" is to open a task by a known ID/repository. "Open task" is to open a known task by typing a filter and selecting it. I don't like the "matching tasks" list on "open repository task". It forcefully makes the dialog similar to "open task", but with no purpose. I never used to select a task from that list because every time I used that dialog, it was to open some bugzilla ID copied from some place (web page, blog post), and in this case, it does not matter if it is available locally or not, because you will hit OK and it will be opened. If I could choose, I'd simplify that dialog, removing the "matching tasks" list, and turning the repositories combobox into a list.
Complementing: I think I suggested initially to "open repository task" be named "open remote task", because it (IMHO) communicates better its purpose.
(In reply to comment #17) > It should be as simple as me entering a URL. If I enter something like > https://bugs.eclipse.org/bugs/show_bug.cgi?id=197821, it should be detected if > it is or isn't in the current lists of tasks. If it isn't, simply pop something > up asking me where I want it. Chris, do you really need url, or you are ok with entering bug id and selecting repository from the drop down? In other words, does present "Open Repository Task" dialog is sufficient for you?
Sure, that would work also. A common workflow for me is usually to see a bug fly by via my email, copy the URL, and try to do something with it. It would be sufficient to use the bug # itself and the ability to select a repo.
(In reply to comment #18) > Open task is for quickly opening a certain task, either by typing some keywords, > or by entering the ID. Quick and simple. I think there is an important point. After you entered search criteria, you still need to select from the list of matching tasks. > In my own experience, I use open task very much, open repository task sometimes > (but enough to need it), and search rarely. Same here. My major complain about search is that it doesn't allow to clarify search criteria, but require to create another search, which is flooding the Search view. > Having said that, I don't see advantages merging something with something so > complex like search dialog. +1 > Perhaps there is a better chance to merge "open task" and "open repository > task", dialogs instead, but the problem is the interface. +1 > Personally I didn't like the current "open repository task" dialog. I don't > think it has to be similar to "open task", because they serve to different > purposes. > > "Open repository task" is to open a task by a known ID/repository. > "Open task" is to open a known task by typing a filter and selecting it. > > I don't like the "matching tasks" list on "open repository task". It forcefully > makes the dialog similar to "open task", but with no purpose. I think there is a good purpose, because you can start typing id and if it is suddenly already in the task list task list, you can select it from the matches. Second idea I've been trying to suggest is that if there is no matching result selected, entered text (supposedly task id or key) will be sent to the repository selected in the drop down list.
(In reply to comment #21) > A common workflow for me is usually to see a bug fly by via my email, copy the > URL, and try to do something with it. It would be sufficient to use the bug # > itself and the ability to select a repo. BTW, you can drag url from your email app (you can still use Alt-Tab while dragging) right into the task list, so it will be added there. Some smart people are suggesting to register Eclipse with Mylyn as default URL handler, then it will automatically open rich task editor if it can recognize repository. :-)
(In reply to comment #21) > A common workflow for me is usually to see a bug fly by via my email, copy the > URL, and try to do something with it. It would be sufficient to use the bug # > itself and the ability to select a repo. Wouldn't it make sense to track a default repository per-project using project-scoped preferences in the .settings folder so you don't even have to ask? Are Task Repository setups something that can be shared in this way?
(In reply to comment #24) > Wouldn't it make sense to track a default repository per-project using > project-scoped preferences in the .settings folder so you don't even have to > ask? I believe it already does that, but you need to have selected one of the following: task repository or something in the task list, project or any resource, have focus on the text editor bound to resource. > Are Task Repository setups something that can be shared in this way? These .settings can be committed to version control, but they aren't part of the exported info for the task repository.
The current mechanism of the hyperlink to Open Repository Task dialog from the search page isn't working for me either. One use case I'd like to mention here is that upon pasting a bug number into the find field in the task list (only to see no result) I'd like to be able to invoke the open repository task dialog (or variant) pre populated with the text I entered into the find field.
(In reply to comment #26) > The current mechanism of the hyperlink to Open Repository Task dialog from the > search page isn't working for me either. One use case I'd like to mention here > is that upon pasting a bug number into the find field in the task list (only to > see no result) I'd like to be able to invoke the open repository task dialog (or > variant) pre populated with the text I entered into the find field. Only time for a quick reply, but the link in Search is just intended to be UI sugar to help with discoverability, it's not a work-around for the issues described here because it's far too many clicks. Regarding the use case of pasting into "Find:", I really find that one to be common as well both in terms of how I use this functionality and in terms of how I've seen others use it (first you see if it's in your Task List, and if not open it explicitly). So if there are no matches in the Task List I'd like to add a custom-drawn hyperlink that incorporates the find/open task functionality and grabs whatever String you inserted into Find so that you don't have to do that twice.
Open search dialog is an action really and it would make more sense to have regular dialog button for that. I think that is more natural UI idiom for anything actionable that closes the originating dialog.
Created attachment 76616 [details] screenshot of Outlook's UI for additional search Here's the new idiom used by MS for similar functionality. I like this approach, and other Eclipse views already put in similar hyperlinks for additional actions (e.g. the Synchronize view). I think that this would would be a convienent way of bridging between the "Find in Task List" and the Search repository functionality. We could provide a link called "Search Repository...", and pre-populate the Search dialog with the search string and the repsoitory selection (e.g. if visible matches are only for one repository).
One thing about those hyperlinks - when used like that they usually don't open other dialogs.
To summarize, the problem that we are working against is that each UI facility that we have for viewing and search tasks adds complexity and gets in the way of discoverability. Prior to 2.0 we had too many: * Task List * Search dialog & search results page * Open Task dialog * Open Repository Task dialog (removed for 2.0 with expectation that we merging with one of the above) Here's my summary of the key use cases: 1) Search in Task List using "Find:" for key, task not found, need to open repository task via key 2) Same as (1) but looking for summary String and not key 3) Given a task ID, need to view task, and possibly add it to the Task List I have explored and prototyped the various options and think that the following best addresses the key use cases without overly complicating the UI. The goal of this approach is to facilitate discoverability, while maintaining the simplicity of the current UIs (i.e. the fact that the Task List and Open Task always operate on tasks in the Task List, and that only Search operates on repository tasks). Since I know that some advanced users are likely to have a preference for the separate Open Repository Task dialog, I propose leaving it for now, having all CC'd try this new UI over the course of 2.1M1, and then for us to try to settle on a single UI for 2.1. * Task List: now has a hyperlink that dynamically appears when below the search box prompting to find by key or summary, text, and pre-populating the key in the Search dialog if found. * Search: in the place of the "Open Repository Task by Key/ID" you can now insert they key in a text box, causing the task to open. Since this is pre-populated you can hit "enter" immediately after clicking the hyperlink in the Task List. The task can then be added to the Task List via the editor's popup menu. I still have a few refinements to make and then will commit and notify here when that's done. Since this kind of link between a filtered viewer and full-blown search dialog could generalize to other search-based navigation UIs I will add this to the discussion items for the UI Best Practices Working group and make sure that we have their input before 2.1.
In my experience I more often using the 3rd use case using the task key, and not description (much preferable without opening the Task List view) and rarely need to add task to the task list before opening it in the editor. I am also concerned about having key entry field in the search dialog, because that dialog is already overloaded and bound to the Search view, and currently doesn't allow to refine entered query. In result Search view is rarely useful because it is faster to run same query on the web UI and then search trough the search results, which Search view doesn't allow.
Here's a draft of the New & Noteworthy for this item. I did a fair amount of streamlining to make sure that the use cases listed, especially the 3rd, required a minimal number of clicks in the typical scenarios. Dev build uploading now, please try out the new functionality and post any comments. Sorry for the late stage in 2.1M1 that this was added, but the key thing is that we get it right for the 2.1 GA. The opening of repository tasks has been streamlined and integrated into the top of the Search (Ctrl+H) dialog. This facilitates opening tasks that are not in the Task List by either key/ID or by searching for their summary or contents. Entering text into the Find box of the Task List will cause a hyperlink to the search dialog to appear. If the Find text looks like a key/ID, the value will populate the Search dialog. Ctrl+Shift+F12 can be used as a shortcut for this action, and will additionally use the contents of the clipboard to look for a task key/ID to populate the Search dialog with. The Ctrl+F12 Open Task dialog also provides a link to the Task Search page. Note that off a task is selected in the active editor or the Task List, the repository in the Search dialog will be now automatically set to the corresponding repository, otherwise the previous repository will be used. The previous Open Repository Task dialog, disabled by default in Mylyn 2.0, can still be accessed via Ctrl+Shift+F12. Since the new functionality replaces this dialog the plan is to remove the old dialog for Mylyn 2.1 (see bug 193423).
Created attachment 77078 [details] mylyn/context/zip
will look forward to the dev build
It sounds like it is missing one important use case: call "Open Repository Task", enter task key and immediately see if it is already in the task list, or if not, open task directly from repository.
Use cases are best to be de-coupled from specific UI implementation, so that one can be restarted as: * Given a particular task key I would like to see if the task is in my Task List, and if not open it from the task repository (and then do operations on it like adding it to my Task List). Supporting this was one of the primary drivers, and this now takes very few clicks. You either paste or type the key into "Find", open the task if in the Task List, if not hit the shortcut or hyperlink, then hit Enter to open the task editor for that task (note that the Search results view is bypassed in this scenario, which you pointed out was a pain).
When's the first build I can pickup this functionality? This kills me daily.
(In reply to comment #37) > Supporting this was one of the primary drivers, and this now takes very few > clicks. You either paste or type the key into "Find", Do you mean that I need to open the task list? Which, by the way can be showing some working set or have "go into"... > open the task if in the > Task List, if not hit the shortcut or hyperlink, then hit Enter to open the task > editor for that task (note that the Search results view is bypassed in this > scenario, which you pointed out was a pain). Now, can we do all of that without the mouse and all the tabbing?
Chris: You can get it right now from the following update site: download.eclipse.org/tools/mylyn/update/dev/e3.3 Eugene: no, you don't have to open the Task List unless you want to see whether the task is in the Task List. The Task List view is designed to make it easy to see which tasks are in the Task List and for a typical use seeing/opening the Task List is easier than discovering another dialog. Perhaps what you are concerned about is the following keyboard-only workflow: 1) Copy a Task ID into the clipboard 2) Hit Ctrl+Shift+F12, hit Enter 3) Task editor opens, and you know if the opened task is in the Task List based on whether it has the task icon in the editor tab If (3) is not obvious enough, we could consider adding an affordance in the editor to make it easier to both see this and add the task to the Task List.
(In reply to comment #40) > 3) Task editor opens, and you know if the opened task is in the Task List based > on whether it has the task icon in the editor tab Where do I select repository for that task id doe be opened from?
Usability and UI issues: Subconsciously, it feels odd to have task id on the right of the repository drop down on the Task Search tab (field is too small for such large dialog). Generally something doesn't seem right if you have to explain how UI actually works. No instant feedback about existing task when task key is entered in the Task Search tab. It also feel odd to have to use "Search" for opening something user already know where it is. It is like using "Java Search" instead of "Open Type" dialog. no keyboard accelerator for task field on Search Tasks tab. "search repository for key or summary" link is always shown once something is entered in the quick find field and it take vertical space from the list. It would be better to replace stuff on the right of the find field instead. Besides, link seem redundant, because there is already Search button on the main toolbar and the same action can be called with Ctrl-H. Link label is confusing because "summary" is not being populated automatically. Different icons for clearing Find field in the task list and key field in the Task Search tab. Labels in the repository drop down on Task Search tab should be the same as in New Task/Query wizards and on the Task Repositories view. Layout of the JIRA search panel is screwed when it is selected in Task Search tab. I am not sure if it caused by recent refactorings or something else. All in all I think old "Open Repository Task" dialog was more intuitive and natural and the only missing piece for "Open Task" dialog was to add select repository drop down instead of obscure hyperlink to the Search Task tab. That would have reduced number of clicks and also facilitated keyboard navigation.
I was very skeptical, but the result does not look bad. But I still like having different dialogs. I agree with Eugene that there are some UI annoyances: (In reply to comment #42) > Subconsciously, it feels odd to have task id on the right of the repository > drop down on the Task Search tab (field is too small for such large dialog). > Generally something doesn't seem right if you have to explain how UI actually > works. +1. It does not look intuitive for a new user. > no keyboard accelerator for task field on Search Tasks tab. +1 > Besides, link seem redundant, because there is already Search button on the > main toolbar and the same action can be called with Ctrl-H. +1. At least it could focus automatically at the "Task Key/ID" field when invoked by Ctrl+Shift+F12. > Different icons for clearing Find field in the task list and key field in the > Task Search tab. At some point in the past the "Clear" icon from task list was changed from the FilteredTree default. I don't see why the "X" icon actually used is better than the default. The default is more intuitive because it has a standard meaning, IMHO.
(In reply to comment #43) > +1. At least it could focus automatically at the "Task Key/ID" field when > invoked by Ctrl+Shift+F12. It'll automatically get focus if you have text in your clipboard that looks like a task key or ID. Not sure if it needs focus if you don't? > At some point in the past the "Clear" icon from task list was changed from the > FilteredTree default. I don't see why the "X" icon actually used is better than > the default. The default is more intuitive because it has a standard meaning, > IMHO. See bug 183581. I hope that we can standardize on this in the 3.4 cycle.
(In reply to comment #44) > (In reply to comment #43) > > +1. At least it could focus automatically at the "Task Key/ID" field when > > invoked by Ctrl+Shift+F12. > > It'll automatically get focus if you have text in your clipboard that looks like > a task key or ID. Not sure if it needs focus if you don't? I think that it would be good if it does get focus since I normally don't have an id that is copied. I use Ctrl+Shift+F12 when I know the id that I am looking for and Ctrl+H when I want to do a search. This could be due to me having used the open repository task dialog a lot, but I do think that the shortcut to open a repository task should work as expected (can type the id right away).
This will take away the ability to have a shortcut to directly search for a task by summary instead of by key/ID, but it won't be that bad, because you'll just be able to hit Tab and get to the summary. But these shortcuts are pretty advanced cases anyway, so if both you and Willian want this I think we could take a patch.
IMHO, it is really weird to have two different keyboard bindings for opening the same search dialog with slightly differend functionality.
