Closed
Bug 523523
Opened 15 years ago
Closed 7 years ago
Places UI: Bookmark folders and tags should be included in the awesome bar results as navigable items
Categories
(Firefox :: Bookmarks & History, enhancement)
Firefox
Bookmarks & History
Tracking
()
RESOLVED
INACTIVE
People
(Reporter: faaborg, Assigned: faaborg)
References
(Depends on 1 open bug, )
Details
(Keywords: meta)
Note: this is a meta tracking bug for UI mockups and discussion of the overall user experience.
All of the user's bookmarks folder and tags should be included in awesome bar results as items that they can directly navigate on. These items should over time pick up increased frecency values, just as web pages do in the awesome bar.
To make sure that these items appear at all in the beginning, I think we might have to start them out with some level of frecency even though they have not be navigated on yet (how did we handle the user's existing bookmark collection when transitioning users into Firefox 3?)
Assignee | ||
Updated•15 years ago
|
Summary: Places UI (3.7): Bookmark folders and tags should be included in the awesome bar as navigable items → Places UI (3.7): Bookmark folders and tags should be included in the awesome bar results as navigable items
Comment 1•15 years ago
|
||
Comment 2•15 years ago
|
||
notes:
- ancestral context should begin with "home", then bookmarks, etc
- does a folder have a zero frecency to begin with, or inherit the sum of it's contents? maybe start with a non-zero frecency that is high - it will organically decay if unused.
- no star menu for queries (make non-visible)
Comment 3•15 years ago
|
||
(In reply to comment #2)
> notes:
> - ancestral context should begin with "home", then bookmarks, etc
why? i think a common root is annoying here, the space is precious and paths can already be long enough. also, there is already the Home "tab"
Assignee | ||
Comment 4•15 years ago
|
||
>why? i think a common root is annoying here, the space is precious and paths
>can already be long enough. also, there is already the Home "tab"
I'm not entirely sure which way is better (have gone back on forth on it so far). Technically Home is more accurate, since you can literally mouse and browse-based navigate all the way to a bookmark by starting with clicking on the home button. This is another way for us to re-enforce that. Also, I kind of like the idea of the user's bookmarks ultimately being a part of the concept of the user's Home, it feels more personal.
On the downside, it takes up additional room, and it isn't entirely clear what should happen when you click on it. Normally you would navigate the content area to home, but the Home tab has special behaviors (for instance things opened in it launch in new tab) so I guess we could technically switch to the Home tab when selected. But this of course would feel really inconsistent and odd.
Comment 5•15 years ago
|
||
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".
In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body contains places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.
Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.
Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
Updated•13 years ago
|
Summary: Places UI (3.7): Bookmark folders and tags should be included in the awesome bar results as navigable items → Places UI: Bookmark folders and tags should be included in the awesome bar results as navigable items
Updated•11 years ago
|
Severity: normal → enhancement
Status: NEW → ASSIGNED
Target Milestone: Firefox 4.0 → ---
Version: Trunk → unspecified
Comment 6•7 years ago
|
||
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → INACTIVE
You need to log in
before you can comment on or make changes to this bug.
Description
•