Closed Bug 524071 Opened 15 years ago Closed 6 years ago

Places UI: Bookmark contextual dialog should be detachable into a persistent sidebar

Categories

(Firefox :: Bookmarks & History, defect)

Product:
Firefox
Component:
Bookmarks & History
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Firefox 4.0

People

(Reporter: faaborg, Assigned: faaborg)

References

(
URL
)

Details

(Keywords: meta) 

Note: this is a meta tracking bug for UI mockups and discussion of the overall user experience.

-Bookmarks contextual dialog picks up a small control to detach it in the upper
right hand corner
-Once detached:
--The panel turns into an actual window which is non modal but will stay on
top, and is re-sizeable
--The window has an inverse control that will reattach it to the star
--The window picks up the description field (as well as keyword and load in
sidebar behind a progressive disclosure control that holds state)
--The folder and tags areas are automatically expanded (first detach, later
they hold state)
--The window and panel maintain attached or detached state, so the next time a
bookmark is created (accelerator-D or click on star), the correct UI will
display for the user
Whether this window will be a panel or a separate window depends on whether the parent browser window should be deactivated when the panel opens. Should it?
I vote for a separate panel, even on a Mac. On my Mac, I hate it when the panels pop up, and then I can no longer access the information below them to fill the panel in! Keeping the platform look and feel should be subsidiary to functionality IMHO.
Alex,
By state, do you mean to get it to remember the user's preference (i.e. last position, size, as modal or non-modal, etc.) for next bookmark?
notes:
- perhaps right-sidebar?
- ui should update to the focused tab (eg: if a window, can't have >1 open)
Giving this some more thought, I think a right sidebar will end up working much better, it feels more like a properties pane and never overlaps and obfuscates content.  Also the dock to the right and close icons will likely be more visually descriptive than detach and re-attach.

>By state, do you mean to get it to remember the user's preference (i.e. last
>position, size, as modal or non-modal, etc.) for next bookmark?

If we go the route of the sidebar, it would probably stay open until directly closed.  So for instance if you switch to a tab that is not bookmarked, the sidebar would have a single "Bookmark" command, and probably an unfilled in star.

We probably want to make sure that the sidebar opens again once you click the star or hit command-d, although in that case we would need a very clear control to return back to using the menu off of the star instead of the sidebar.  I'll have to do some sketches and mockups to start to get a sense of how well this is going to work.
> Giving this some more thought, I think a right sidebar will end up working much
> better, it feels more like a properties pane and never overlaps and obfuscates
> content.  Also the dock to the right and close icons will likely be more
> visually descriptive than detach and re-attach.

Alex, great idea but why not integrate it into the existing bookmark pane whenever we hit on CTRL+B ?

Seeing some sketches or mockup will be helpful.
Not sure if it's just me but why do I always get the feeling that there are some kind of wall between different bookmarking features? We have:
1) CTRL+B (bookmark pane)
2) CTRL+SHIFT+D (Organize Bookmarks)
3) star icon

IMO integrating them all in one place will make more sense.
After talking with the places team we all felt that a right aligned sidebar would be easier to use, since it will be persistent until the user closes it, doesn't overlay content, and has some external consistency with other apps that place properties in a right aligned sidebar.
Summary: Places UI (3.7): Bookmark contextual dialog should be detachable and then re-sizable → Places UI (3.7): Bookmark contextual dialog should be detachable into a persistent sidebar
If we'll have a right sidebar, will it replace "Edit This Bookmark" dialog whenever we click on the star icon?
I need to get a full set of mockkups posted, but here is what we were thinking:

if the sidebar is open, and the page in the content area is not bookmarked, the sidebar will contain a button "bookmark page" (kind of similar to the remove bookmark button placement in the panel).  If the user clicks this button, or they click the star in the location bar, the right sidebar switches to showing all of the various properties of the bookmark (title, tags, folder, description).

Options for the keyword and load in sidebar will likely be behind a progressive disclosure control since they are very rarely used.
the sidebar has lot of vertical space compared to the star panel, that means we probably could just have all properties without the need for progressive disclosure controls (see bug 405795).
We could even expand the "remove all bookmarks" to actually allow the user to choose which bookmark to edit or remove (followup though).
I'm sorta thiking this panel as "hey the star panel is too strict for me, i want to have more control over my bookmarks".
Blocks: 405795
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
>the sidebar has lot of vertical space compared to the star panel, that means we
>probably could just have all properties without the need for progressive
>disclosure controls

True, but having a large text area for the description is potentially more useful.  Also, if the odds of the user setting a keyword (which is potentially conflated with tags) or setting the bookmark to open in a sidebar are astronomically small, we could have infinite space and still want to tuck them away under a progressive disclosure control :) 

Either way the progressive disclosure should hold it's state so the unlikely user who sets a bookmark to open in the left sidebar 50% of the time can remain very happy.
i see, indeed if we can persist users preferences we can adapt to his needs.
I'll wait for mockups to start hacking the new sidebar. Coding will be done in the dependent bug 529610.
Alex,  I think the sidebar is much too small to see the properties information we copy, paste and modify.  Also, and much more important,  please give us back our keyword entry area.
too small in which dimension? In terms of height I'm having a hard time imagining a separate window that could be much taller than the Firefox window.
and to answer the second part, we're thinking additional properties would be displayed after a persistent progressive disclosure control is hit.  So after one click you would have them back for good.  (but at the same time keywords isn't necessarily something we want to show every user right from the start since it semantically collides with tags, and is a pretty complex idea).
(In reply to comment #15)
Please give us back the keyword entry area, so that we can always enter and
view the keyword.   The  "Open Book" extension combines the features  that are
wanted, and fills in the description automatically and can be modified.  It
even has the tags if anyone actually uses them, that I think create a lot of
extra bookmark records.
(In reply to comment #16)
> too small in which dimension? 

In terms of width to be able to see the entire Title and modify it,
would also like to be able to see the entire URL to be able to modify it.
(In reply to comment #17)
> keywords
> isn't necessarily something we want to show every user right from the start
> since it semantically collides with tags, and is a pretty complex idea).

Why they've been there from before Firefox, and they are as simple or complex as you want to make them.   Actually it's the highly overrated tags that are messing up users not keywords.  Keywords are used as aliases (simple),  used with substitutions (still simple to create and use),  only when you combine those with JavaScript do the begin to get complicated.   Lest you forget originally users after installing Firefox could get to a page within two clicks to customize Firefox to include keywords.  Rather than simplifying Firefox the new changes have made things so much harder to use and harder to describe Firefox abilities to new users.
Suggest you guys look at the user comments against the "OpenBook" https://addons.mozilla.org/en-US/firefox/addon/42 and "Add Bookmark Here" https://addons.mozilla.org/en-US/firefox/addon/3880 add-ons to get a measure of which features users actually want.  I'd say that Keywords are quite high on the priority list.
Once you can have Firefox remember the width of the sidebar (don't forget most monitors today are 16:9 so you have plenty of horizontal space), and the collapsed/uncollapsed status of the additional options, both issues presented above will be no-issue.
I may just be a curmudgeon, but years ago bookmarks worked really well. We got a detachable and resizeable window. I now use a Mac, and IMHO Mozilla should ignore OS X GUI guidelines and make the window for "add bookmark" a separate window again. And make it resizeable. That would fix most of the complaints here. The current window is much too small to use, and changing its fixed size is a bad idea because I need a much bigger size on my 30" monitor than on my netbook.
Summary: Places UI (3.7): Bookmark contextual dialog should be detachable into a persistent sidebar → Places UI: Bookmark contextual dialog should be detachable into a persistent sidebar
Marco, I guess this and related bugs can be closed? Seems unlikely we'll be needing these after 6 years of radio silence... :-)
Flags: needinfo?(mak77)
We need a new design direction from UX, we have lots of old bugs suggesting new bookmarking UI that we'll never implement, exactly because they don't represent anymore our current direction.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(mak77)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.