| Summary: | [client] organization of favorites in the UI | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Susan McCourt <susan> |
| Component: | Client | Assignee: | Susan McCourt <susan> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | andrew.eisenberg, mamacdon |
| Version: | 0.2 | ||
| Target Milestone: | 0.5 M2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Susan McCourt
In bug 347058 comment 2, Libing discusses how he works on the same group of files for a particular purpose. It would be nice to let the user group favorites however they like. We could always have default groups of "Favorites" and "Searches" as today if we like separating them (or want to preserve the old behavior) but these would be user-driven. See also bug 347058. If we have a "manage favorites" page, then there is a lot more room to work with all these ideas. removing milestone for now. It's not realistic that we'll put effort into organizing/managing favorites in 0.4. I think the important thing is bug 347058, a way to get to the favorites easily from non-nav pages. It would be nice to be able to have more control over organizing favorites, including a way to have multiple favorites folders, but I agree that this is a lower priority than bug 347058. The direction for now is to move away from "favorites as groupings of random links" and instead "favorites is a navigator for the navigator." So we moved searches to the search page and cleaned up the API so that saved searches are managed in a different preference. We may continue to evolve what "favorites" means but I think we can consider this particular bug closed. |