Closed Bug 311286 Opened 20 years ago Closed 1 year ago

Re-organise bookmarks manager to an iTunes-like library

Categories

(Camino Graveyard :: Bookmarks, enhancement)

Product:
Camino Graveyard
Component:
Bookmarks
Platform:
PowerPC
macOS
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE
Milestone:
Future

People

(Reporter: jbrsh, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050914 Camino/1.0a1 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050914 Camino/1.0a1 I believe the bookmarks manager should be re-organised to resemble an iTunes like library. Instead of having a bookmarks manager, it should be called "URL Manager" or "Links Manager". The "Groups" sidebar could be renamed "Source" and there could be a "Library" of all links including all bookmarks from the bookmarks menu, bar, address book, as well as links from the history. Bookmarks and history could become permanent subsets of the library- like playlists. The history and top-10 links could become "Smart folders" which can be edited to include more or less links etc. This would make it easy to search all bookmarks at once since they can all be seen in the library view. They could even be browsed by host. People could create smart folders with certain criteria or regular bookmarks folders. This would also help avoid the issue raised in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=285096 regarding the confusion caused by the history being a subset of the bookmarks and so cannot be toggled with the history menu. Both the bookmarks and history buttons could then be toggles which bring up the folder in the "URL Manager" I understand this would be a huge undertaking but I believe it would make Camino unique and far superior in managing bookmarks. Reproducible: Always
Also, one more thing, If RSS is going to be implemented in Camino, it could get integrated straight into the "URL Manager". There could be a separate folder for feeds like in safari but clicking on a feed could somehow bring up an RSS viewer right within the manager window where the bookmarks are normally displayed. I know this has probably already been thought of.
After some detailed explanation from smorgan on the mozillazine forums as to the logic behind Mike's decision, I take back what I said about having two toggle buttons as it would introduce inconsistent behaviour. Instead, there could be a single toggle for the URL Manager which would bring up whatever view was last selected- history, top-10 bookmarks etc. There could also be normal shortcut buttons to history and bookmarks separately if people desired so that it would be easy to get straight to what you wanted rather than having to get stuck with the view you last selected. These buttons would be one-way, not toggles. Once in the manager, you could either select the url manager toggle to go back to your web page or there could also be a close button in the top right or left hand corner of the url manager to close it and go back to your page. This would eliminate confusion if people opened history by the bookmarks via the one way button and wondered why they had to click another button to toggle it off. Anyway, I've said my bit, I hope I haven't pestered you guys the developers too much with all the **** I have written ;) Ben
i believe simon just fixed the bug where it wouldn't remember the selected collection when reopening the bookmarks.
Cool, thanks Mike, that's definitely an improvement.
Ben, could you please: A: Download a nightly build from caminobrowser.org and re-evaluate the features you listed below. B: File each of these feature requests as a seperaate bug so we can keep track of them better. Thanks.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
(In reply to comment #5) > Ben, could you please: > A: Download a nightly build from caminobrowser.org and re-evaluate the features > you listed below. > B: File each of these feature requests as a seperaate bug so we can keep track > of them better. > > Thanks. Is this really neccessary? *This bug was filed on Oct 5th, not much has changed since then. *There is only one feature request here: Put history and bookmarks together in a Library. Rest is just ideas that spring from that. Bug comments: This is the only sensible thing to do; when I use the history and bookmarks managers (or is it a single manager?) I always find border-line situations where Camino doesn't do what I'd like it to do. This request is ''the right thing to do'', and I think it would put us in a very good position against any other browser out there.
(In reply to comment #5) > Ben, could you please: > A: Download a nightly build from caminobrowser.org and re-evaluate the features > you listed below. > B: File each of these feature requests as a seperaate bug so we can keep track > of them better. > > Thanks. > A: I have been using a nightly from the 18-10 for the last week. The fact that the manager now remembers the collection is still an improvement but my opinion remains the same about re-organising the bookmarks. B: I agree with Ulrik, I don't really see the point in separating the requests when they are all minor and stem from the main idea (having a library). Surely it would be easier to track them if they are in one bug, especially since they are so closely related. I'm don't know much about bugzilla so please feel free to corect me if I am wrong.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Jamie Diamond: While we appreciate interested parties helping triage Camino bugs, please check with Wevah or me (co-leads of the Camino Bug Triage team) or Samuel Sidler to get "on the same page" with how we manage bugs first :-) Thanks! Ben: Since this bug is about a complete re-orientation of the Bookmarks Manager, it's OK to describe the complete change in one bug, but, yes, normally feature requests or bugs should be "one issue per report" to make tracking and implementing them clear and easy. That said, I'm not really sure what you're proposing other than changing the names of parts of the Manager UI, smart folders (there's a bug on that already), and a collection that is a superset of the others--and I'm not sure how the latter would be useful.
I'm sorry. I was only following bug-writing and QA procedures. If they differ for Camino, they should be officially published.
(In reply to comment #8) >I'm not really sure what you're proposing other than changing the > names of parts of the Manager UI, smart folders (there's a bug on that > already), and a collection that is a superset of the others--and I'm not sure > how the latter would be useful. > I just think a library that is a superset of all others would be more intrinsic. It makes sense to me to be able to see all my links at once, it would be easy to search for any link, including history. It seems odd to me that the search bar in the bookmarks gives the option to search "all" when in fact it only searches all in the current collection. Surely it would be more useful if it searched all bookmarks and urls, like spotlight. I think some people would be confused as to why they can't find the bookmark they know they have when they are searching "all". Like I said, I also think it would eliminate any inconsistencies arising from the current system where the bookmarks button is a toggle but the history button is not. There would be no confusion as to whether the person must click the bookmarks or the history button to toggle it off as it would be the one "URL manager" button.
I am in favor of this idea.
(In reply to comment #10) >It seems odd to me > that the search bar in the bookmarks gives the option to search "all" when in > fact it only searches all in the current collection. That's because it's asking what attributes/metadata you want to search (title, URL, keyword, etc.), not which collection. Maybe that needs to be changed to "All fields" or "All columns" or something to be more clear. I dislike the idea of everything being lumped together (because I can organize and separate things according to my needs and workflow; maybe I'm old-fashioned, but I like to create order), but as long as the superset was an addition to what we have now and I could still select/view/create/have keystoke access to individual collections, I could live with it. For a less-drastic way of addessing just the toggle/non-toggle issues, there's always bug 311781 :-)
Confirming as a RFE. We should go over exactly what's wanted in this bug and file new bugs for each issue, if the idea is accepted by the devs.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Future
Not sure if the devs are interested in implementing the changes I have described, but it seems the Firefox crew are proposing pretty much exactly what I have suggested: "The Places Pane is the pane on the left that shows the top level of the Places root. Its contents include several predefined entries. Some are "special" and cannot be removed because doing so would obscure access to areas of the user's navigation history or Bookmarks. Users may also add items to the list" See: http://wiki.mozilla.org/Places:User_Interface Maybe this would help the Camino team in organising a new system. I am willing to create separate bugs for individual features but I'd rather if someone more experienced with reporting bugs could do it. For more information on the plans for Firefox's bookmarks/history, see: http://wiki.mozilla.org/Places
*** Bug 341549 has been marked as a duplicate of this bug. ***
I support this idea. Take a look at the folllowing link: http://www.plasticbag.org/archives/2004/10/towards_tagbased_bookmark_management_in_web_browsers.shtml It's pretty safe to say that most browsers will eventually utilize tag-based bookmark management. Firefox will have Places in version 3.0, the Vista version of IE will probably utilize Virtual Folders, and some browsers on GNOME already has this built-in.
*** Bug 341613 has been marked as a duplicate of this bug. ***
Isn't this a duplicate of this bug?: https://bugzilla.mozilla.org/show_bug.cgi?id=310888
Mass-reassign of bugs still assigned to pinkerton to nobody; filter on "NoMoPinkBugsInCamino".
Assignee: mikepinkerton → nobody
QA Contact: bookmarks
Status: NEW → RESOLVED
Closed: 20 years ago → 1 year ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.