Closed Bug 13012 Opened 25 years ago Closed 12 years ago

automatically promote/demote bookmarks based on access frequency

Categories

(SeaMonkey :: Bookmarks & History, enhancement)

Product:
SeaMonkey
Component:
Bookmarks & History
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: CodeMachine, Unassigned)

References

(
URL
)

Details

(Whiteboard: [2012 Fall Equinox])

This is a request for an agent embedded within the browser which can intelligently examine your bookmarks. The above blue sky URL is about these capabilities. They include: (a) Searching for permanent errors like 404, and giving a list of failed bookmarks. (b) Automatically moving permanently redirected sites (related to bug #8648, except you don't actually have to go to the site). (c) Searching for updated pages. (d) Arbitrary searches, giving a list of matching pages, like with history, or better, filters. (e) Some sort of agent that tries to work out whether you should promote or demote bookmarks depending on how often you access them. This would be especially useful for the personal toolbar. Ideally you'd have some way of choosing the pages to apply this to, to reduce the traffic and time taken. It would work similarly to the filter message selection in Messenger. It could be done using dates first/last accessed, number of times accesses, URL, etc. You would also want to be able to take some sort of action of the returned pages for the searches. This might be remove, prompt, open in new window, etc. You might have a scheduling capability for some of these to. This would allow you to set up rules like "every 10 days do a search on sites I haven't accessed in a month and report to me which have 404s". When the 10 days was up, it would pop up a dialog with choices like "Do Now"/"Don't Do"/"Ask Me In A Day".
I'll comment a bit more on how well (d) is implemented when the smart search gets a little farther along.
Target Milestone: M14
Move to M14 with the rest of the RFEs (for now anyway :-)
Component: Browser-General → Bookmarks
QA Contact: leger → claudius
Updating QA Contact/component.
Move to M20.
Target Milestone: M20 → Future
Move to "Future" milestone.
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy
Assignee: don → vishy
Netscape Nav triage team: this is not a Netscape beta stopper.
Keywords: nsbeta1-
Even though this bug is olde, I still reckon it's worth thinking about. Maybe just a "Clean Old Bookmarks" menu item in the bookmark manager, which scans all the bookmarks in the folder for 404 errors, and either disables them or tags [Not Found] on the end (or, optionally, gives us an option to just delete them)? So we could go through our bookmarks every so often, hit Clean Old Bookmarks, and marvel at a job well done. Also, I reckon a cool thing would be to have a "Frequently Accessed Pages" folder in bookmarks, which contains the user's ten most frequently accessed pages in the last few days, as reported by global history. Which, of course, we could set as the Personal Toolbar folder, or whatever. Somewhat more ambitiously, we could periodically scan the root-level bookmarks folder, adding very frequently accessed pages, and deleting ones which aren't accessed frequently at all (or which haven't been accessed in, say, three months). And, finally, a few features which I'd personally like, but which aren't necessarily related to "smart" bookmarking... the ability to have bookmarks automatically sorted in alphabetical order, on the menu (to make it easier to find them), and a search box on the sidebar bookmark tab. Hope I'm not too demanding :-)
-> bookmarks, possibly some UI:DF input needed here, cc'ing ui guys.
Assignee: vishy → ben
This should probably be more than one bug...
Nice to have, but there's still worse afflictions plaguing us. Down a notch in priority. Accepting.
Status: NEW → ASSIGNED
Priority: P3 → P4
Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter email notifications caused by this by searching for 'ilikegoats'.
Assignee: ben → pchen
Status: ASSIGNED → NEW
mass reassign of pchen bookmark bugs to ben
Assignee: pchen → ben
Blocks: 168902
Depends on: 93058
(a), (b), (c) --> bug 8648 (d) --> 93058
No longer blocks: 168902
No longer depends on: 93058
Summary: [RFE] Intelligent bookmarking. → automatically promote/demote bookmarks based on access frequency
Blocks: 168902
Honestly, this sounds to me like the kind of feature a third-party app could provide, or even may already provide. Something like wget's spider functionality can check for the basic existance of pages easily enough. Some intelligence to have such a program understand redirection/broken link webpages and to then update the file with this info is definitely blue sky. =) Btw, adding a quick 'number of visits' column to the bookmark manager would allow one to sort based on this number.. to view a top ten list of pages most visited. Of course, some intelligence thrown in, in order to calculate the frequency of visits (not the total number, but the number based on how many days a bookmark has been around perhaps).. something like that would be cool.
*** Bug 174373 has been marked as a duplicate of this bug. ***
I'm not sure that (e) is a good idea. Automatically promoting and demoting bookmarks is not too far from Microsoft's awful "Personalized Menus" - both features can defeat the user's spatial/muscle memory. Is mpt still around? Prog.
Product: Browser → Seamonkey
Assignee: bugs → nobody
QA Contact: claudius → bookmarks
Priority: P4 → --
Target Milestone: Future → ---
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: UNCONFIRMED → NEW
Ever confirmed: true
so... How do you know how much usage determines whether something sticks around? do you enter in a percentage? it should probably be very very low so I would want a floating point number. And is the percentage's 100% based on "all bookmark clicks"? or is it something else? for 404 errors, there is a link rot checking link you can use that comes from the O'Reilly book 'CSS Cookbook': javascript:void(document.location='http://validator.w3.org/checklink?url='+escape(document.location)) I only want this as an OPTION or some sort of MENU ACTION not the default. I don't want my precious bookmarks disappearing on me or shifting around! how would you like your mysql or postgresql database to suddenly start zapping entries automatically based on usage? I wouldn't! I don't know what this query tag is all about.
(a) may be done as add-on (b) covered by Bug 8648 (c) looks similar to Bug 10488 (proposed WONTFIX) (d) now you can't create duplicate bookmark (Bug 789468), so it don't need anymore (e) not sure, what "promote" and "demote" mean here In general, this request contain several different requests, some of which covered by other bugs, so I'm proposing to close this bug and fill separate request for missing parts if still needed, any other thoughts?
Whiteboard: [2012 Fall Equinox][CLOSEME 2012-11-01 WONT?]
I'll close this as INCOMPLETE. If any of these item are still wanted you should file new bugs one per issue.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [2012 Fall Equinox][CLOSEME 2012-11-01 WONT?] → [2012 Fall Equinox]
something like the original idea (not the headline, which totally doesn't match the idea at all) - you could have a process-in-batch command or menu item under view all bookmarks, maybe called "update bookmarks". - should only work when the browser is not busy, like microsoft BITS. in fact, maybe it could use BITS (Background Intelligent Transfer Service). many packages are doing this now for updates. - should only work if the user does not have some sort of an internet "cap" like 5GB or 2GB (which is worse) for cell/mobile, because this surely will generate a lot of traffic. I have 4117 bookmarks (and growing - ff refuses to show them all). this would be a lot of traffic done in batch. some pages like w3c stuff can be up to 14MB for a single HTTP GET for something like the HTML5 standard (one of my bookmarks). - should be able to remember where it left off between sessions, like keeping an index/pointer/cursor/id into the database. this technology is similar to what online backup programs use. - 301's should be automatically fixed. - 404's should be queued for user action, to drop or keep, where the user can process them in batch or singly (their choice). I personally don't like the idea of my precious bookmarks getting demoted. when I need them, I need them. I bookmark them for a reason. if they are 404, it is always possible they might come back because they are only 404 *temporarily*.
You need to log in before you can comment on or make changes to this bug.