Community
Participate
Working Groups
After using Mylar since 0.4.x release, I still think the "Archive" term strange and non-intuitive. It is strange when you start typing some filter and if the task is not on task list (like on bug#181386) it "automagically" appears on this "magical" archive category. It is strange because you don't "archive" a task; there isn't a "Archive" action like on gmail, so it is not intuitive how some task became "archived" if you never invoked a "archive" command. The best suggestion I can do for now is to rename the display name to something like "Others" or "Other tasks".
Still need to figure out design of this, related to bug 174799.
It is too late to change the current design for 2.0. We should reconsider the design post 2.0. Given the current design I can't think of a better label than "Archive (all tasks)" given that it stores all tasks. Notable we now have a UI improvement with task working sets which no longer show the Archive.
*** Bug 174799 has been marked as a duplicate of this bug. ***
Not sure if this is the right bug or if I should open a enhancement request but how about introducing virtual categories to circumvent the archive category. I'm thinking along the lines of virtual folders in some Emailprograms. The user can define categories which are not associated with any repository or query and can define select criterias for that category. All Tasks that correspond to the selection criteria will be shown in that category. Instead of showing the archived category Mylyn (this still feels strange ;) ) can show a virtual category with unread tasks, active tasks etc...
Stefan: this is pretty much how the special Archive and Uncategorized categories are implemented under the covers. They are effectively query categories, and in the 3.0 cycle we will be making their implementation even more like that. A key issue to consider here is that generic query categories are both very powerful and very complex. Microsoft Outlook is a great example of both how useful and how complex they can be, since it provides an arbitrarily queriable and nestable viewing mechanism that's able to use any field on any kind of object. The end result is highly configurable for very advanced users and integrators, but while Outlook 2003 and 2007 have done a very impressive job at hiding and selectively revealing this complexity it can still be very overwhelming to typical user. What we need to do in improving on the current design is gather the key use cases for the Archive and similar "query categories", then have the UI and implementation follow. The current key use cases for the archive that we're most familiar with is: * To maintain a self-evident UI queries should only show tasks that match the query parameters. Sometimes relevant tasks will disappear from the query (e.g. if the user sets up the query for only open tasks, which is not recommended). In this case the tasks need to show somewhere, and the Archive is currently where they show. We also know of the cases that are currently broken: * Local tasks show in the archive: they don't need to, the new Uncategorized category shows them. * The archive is flat: it shouldn't be, it should at least be organized by repository. * The archive shows duplicates of tasks that are already visible in queries: it shouldn't, this is an implementation detail that is showing through.
I understand that a configurable virtual category system is very complex and might overwhelm newbies but I still think that a use case in which you can mingle task from different repositories would be quite helpful and support organisational issues. This might also be addressed by subtasks etc... in which case a container category might hold different query categories. As a use case: I have a scenario where I would like to mingle local and remote tasks which isn't possible at the moment (or is it and I do not know about it yet? <-) ) Another thing: As Willian pointed out Archived isn't a very descriptive name for this purpose Other or Misc would be more acurate but that is simply a naming issue.
Stefan: you can mix local and repository tasks into a single container via a category (e.g. drag the repository tasks into the category). This is actually part of the complexity issue that we're dealing with and why we can't call the archive "Misc", because we already have the "Uncategorized" category which needs to be there for tasks that have either been removed from all categories or not put into any category. We will definitely need to do a holistic review and redesign so if you could describe your use cases, such as the mixing one, that would be helpful.
I would like to give my humble contribution to this. First of all, as long as I need to use the archive category, I would like that the state of the option "Filter archive category" persisted between Eclipse sessions: right now, when you close and reopen Eclipse, that option is always reset to checked. Moreover, regarding the archive category discussion (I also discussed with Mik about certain aspects of the issue in the newsgroup): maybe I'm missing something, but I think it would be very simple if: - there would be an "uncategorized" category where all tasks fall when they are no longer in other categories/queries (suppose a bug report that "exits" from a query and does not "enter" into any other...) - there would be a special category named "completed tasks" where tasks go whene they are marked as "completed". It could be useful, however, to let the user decide if he wants a unique "completed" category, one "completed" sub-category for each of his original categories or a unique "completed" category with as many sub-categories as the original categories from which the tasks come. In this way (except for the first option), you'll always be able to know from where a completed task comes from. My suggestions are based on my personal experience: if I set up a query with ALL my bugs (open and closed ones), when I fix one and the task is marked as completed, I would like it to be set apart, but not to get rid of it completely by filtering it out (as Mylyn can do right now)... Yes, I know that you can make a search to get to a task that is filtered out, but this is not so user-friendly, I think... With two such special categories, "uncategorized tasks" and "completed tasks", I think you're covering all the cases for which the disputed "archive" category is designed for: am I wrong? Mauro.
*** Bug 152710 has been marked as a duplicate of this bug. ***
Let's make some progress on this for 2.2.
*** Bug 202854 has been marked as a duplicate of this bug. ***
We just had a major design discussion about this and here is the outcome: * We get rid of the Archive as it exists today (yay!). * For local tasks, if the task is not in any category, it shows in the special Uncategorized category-like container (same as today). * For repository tasks, if the task is not in any query, it shows in a special Unmatched query-like container ("Unmatched" is the working term, might change). * One Unmatched container will exist per repository. We will use Archive like visibility rules to ensure that these don't show when they don't need to (e.g. in the uncommon case where the user has numerous repositories, like the committers do). * The Unmatched containers will contain every task for a repository that is not contained by any other container, i.e. all queries and categories. It is important that we include categories for the use case of users manually adding tasks to categories. * Since the Unmatched containers exist per repository, they will allow the user to do things repository specific clean-up (e.g. bug 202854). * Like the Uncategorized container, the Unmatched container can be added to a working set, ensuring that the user is not overloaded with incomings from other working sets, and that they don't miss incomings from the active working set. This resolves some of the main usability problems and bugs that we have seen with the archive such as duplication of tasks between it and other containers and lack of parallelism with other containers. Comments?
(In reply to comment #12) > * For repository tasks, if the task is not in any query, it shows in a special > Unmatched query-like container ("Unmatched" is the working term, might change). > * One Unmatched container will exist per repository. We will use Archive like > visibility rules to ensure that these don't show when they don't need to (e.g. > in the uncommon case where the user has numerous repositories, like the > committers do). How about issue from bug 201157?
(In reply to comment #13) > How about issue from bug 201157? As discussed on the conference call, I believe that UI change would cause more usability problems than it resolves. This approach should address some of those use cases, although it won't map back to the query the element disappeared from. I'll comment further on bug 201157.
Just one update to the plan here aimed at simplifying the ui further. I'm going implement this based on a single special 'Uncategorized' folder type that will act as a catch all for each repository (including local tasks). So there will be one fore local tasks just as there is one for each repository. The user will not be able to drag tasks into instances of this special folder, only out.
Hmm. Currently it is possible to drag stuff into Uncategorized folder for local tasks and it does make sense to not put new restrictions for that. Also, what would be handle ids for those per-repository folders? I wonder if we'll need new api for that, i.e. something like isArchive()
(In reply to comment #16) > Hmm. Currently it is possible to drag stuff into Uncategorized folder for local > tasks and it does make sense to not put new restrictions for that. Although upon 'removing from a category' local tasks will go to their archive folder perhaps for local tasks we should allow dragging into this folder. > Also, what would be handle ids for those per-repository folders? I wonder if > we'll need new api for that, i.e. something like isArchive() These objects will eventually extend AbstractTaskContainer and their handle will be a combination of the repository url and "orphans" or "archive".
Created attachment 84602 [details] Iteration 1 Still a ways to go but this patch is fully functional. (Not to be bootstrapped on though)
Created attachment 84662 [details] Small update
Created attachment 84842 [details] More progress. Up for debate is what to do with the public getter methods on TaskList getDefaultCategory and getArchive. The pach just returns null for both but this implicitly breaks the api.
Created attachment 85021 [details] For testing Here is my latest draft of the multiple archives support. Committers, please bootstrap on this (after backing up all your data). An let me know how it is working for you.
P.S. Don't forget to add the archives to your working sets (if desired).
Created attachment 85034 [details] Update patch Fixes some subtask issues and incoming status on Archive containers etc.
Created attachment 85037 [details] Updated patch
Created attachment 85039 [details] More fixes Patch includes overlapping fixes for other bugs.
Created attachment 85098 [details] Inclusion of more bug fixes
Created attachment 85142 [details] Final patch
* Archive ** label: Unmatched [eclipse.org] [FIXED] ** Jar icon for Uncategorized, blue server icon for archives [Created bug#213379] ** Category has expansion button but not expandable [FIXED] * Working set dialog [FIXED] ** Uncategorized remains in working set selection, archives are not available but automatically added to working set
Excellent!
Fixed.
Yay! I am very happy to see the quagmire of usability problems that was the Archive category finally go away and be reshaped into something more explicit.
