459958 - Standardize bookmarks property dialogs both in terms of code and user interface

Status: RESOLVED WORKSFORME

(Firefox :: Bookmarks & History, defect)

Description

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: This is pretty strange

In https://bugzilla.mozilla.org/show_bug.cgi?id=411261#c25 Dietrich wrote:

>Thanks for the patch Andrew, but I don't think we should be extending that
>dialog. Instead, we should be standardizing on the new bookmark properties
>panel, and removing the old one.
>
>I think that the dialog should embed the new panel, like the library does. This
>will reduce code and provide a consistent experience for users.
>
>I also don't like that there are two versions of bookmark properties UI
>available via primary UI that are so radically different in appearance, but
>that's an issue for another bug.

To review all of the motivations here:
1) reuse code to reduce complexity
2) use a consistent interface so that users are not confused

I think everyone is on board with both of those motivations, but I'm not sure how far we go with matching the bookmark contextual dialog (the thing that hangs off of the star in the location bar) in the other instances of the bookmark properties dialog.  Here is the list Marco gave me on irc:

1. history sidebar, right click and choose Bookmark this link
2. places views (menu, toolbar) context menu New Bookmark, New Folder
3. subscribe a livemark
4. Add keyword for this search
5. add a sidebar panel clicking on a link or through js function addPanel
6. drop a bookmark over the bookmarks Library icon after customize toolbars
7. Bookmark all tabs
8. Context menu properties

Also, I think:
9. Library window properties pane (?)
10. "Bookmark this Link" on the contextual menu of a hyperlink in the content area (screenshot in attachment).

There might be more instances of creating / editing a bookmarks properties, but those are all of the ones I know about.

In terms of Dietrich's comment:

>I also don't like that there are two versions of bookmark properties UI
>available via primary UI that are so radically different in appearance

The bookmark contextual dialog is instant apply, and has a click outside to dismiss behavior (the click outside to dismiss behavior is conveyed visually by referencing other interfaces that are click outside to dismiss).

Adapting the instant apply nature of the interface to other instances of the bookmarks property dialog is fine, but carrying over click outside to dismiss behavior doesn't make any sense in the other contexts.  For instance, the "Bookmark this Link" interface isn't visually associated with anything that could recreate the interface (like the star in the location bar) and it is kind of awkward in the upper left hand corner of the content area.

So I propose that we leverage some of the existing code, which means that they will become instant apply.  However, they should really remain (including the "Bookmark this Link" instance) real modal dialog boxes, with Done / Cancel buttons.

Also, the large star icon, title and "Remove bookmark" items don't need to appear in these other instances of the bookmarks property interfaces, since a contextual command already set the context of what the user is doing, and there was also a contextual delete command.

I probably still need to clarify a bunch of stuff, but what do people think of that overall approach?

Comment 1

[Marco Bonardo [:mak]]

imho the hardest part is is mixing up in a sane way the need for a common UI with the user need of a dialog-like panel (as you said for example screen reader users, but i can tell for sure mostly Windows users prefer a classic panel to instant apply). I agree with the idea of a MODAL dialog with a border and Done/Cancel buttons so the user has to take a decision.

Instant apply is quite easy and straight-forward for the edit case (so "properties"), it's already used when clicking the active star and in the Library pane. In the add case we will have to guess some data.

Case 2 is maybe the most strange since we don't know anything about the bookmark (but probably the position where the user wants to create it, so we should create an about:blank bookmark with title New Bookmark, and let the user edit it, but we should present empty fields that are easier to fill).

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Alex, one thing I noticed some days back is the complicated way how to chance the URL of an already saved bookmark. Currently we aren't able to do this via the contextual dialog. Users have to open the Library, navigating to the folder the bookmark resists in or doing a search within the Library. Afterwards they can change the URL in the details pane. But this is the only place. IMO this simple action is really complicated and needs a lot of user interaction until the aim can be achieved.

At least the bookmark properties dialog shouldn't miss this field. It will make the life a lot easier for users who only want to update an outdated URL without the need of removing, re-adding, and retagging.

Comment 3

[Alex Faaborg [:faaborg] (Firefox UX)]

This because we are thinking about bookmarking being more like flagging an email, just a quick gesture to mark something interesting.  If someone wants to change the URL of a bookmark, I would argue that what they really want to do is bookmark something else (just like you don't change the email of an existing flagged email, you flag some other email).  Changing the folder, set of tags and name is extra work, but urls don't change all that often, and someone who sets all of this information will probably be familiar with the library window or sidebar to select "properties."

Comment 4

[Marco Bonardo [:mak]]

Alex any news here?

I have a first working implementation (instant apply in a dialog) with following situation, hope this helps you telling what should be hidden and what should be changed here, after your first suggestions i would create a trybuild so you could suggest further refinements:

1. in history sidebar, right click on a visit and choose Bookmark this link
   Contents: name(filed), folder picker(bookmarks menu), Tags(empty)
   Title: "Add Bookmark"
   AcceptButton: "Add"

2. on Places views (menus, toolbars, trees) right click and choose New Bookmark
   contents: name("New Bookmark"), location("about:blank"), tags(empty), keyword(empty), description(empty), load in sidebar(unchecked)
   Title: "Add Bookmark"
   AcceptButton: "Add"

3. on Places views (menus, toolbars, trees) right click and choose New Folder
   contents: name("New Folder"), description(empty)
   Title: "Add Folder"
   AcceptButton: "Add"

4. go to a livemark, click subscribe using live bookmarks
   contents: name(filed), folder(bookmarks toolbar)
   Title: "Add Live Bookmark"
   AcceptButton: "Add"

5. right click on a search field, "Add keyword for this search"
   name, keyword, folder picker
   contents: name(empty), folder(bookmarks menu), tags(empty), keywords(empty)
   Title: "Add Bookmark"
   AcceptButton: "Add"

6. add a sidebar panel on http://www.google.com/mozilla/google-search.html
   contents: name(filed), folder(bookmarks menu), tags(empty)
   Title: "Add Bookmark"
   AcceptButton: "Add"

7. click on a panel Add link with rel="sidebar" (tested on
http://tntluoma.com/sidebars/ Add links)
   contents: name(filed), folder(bookmarks menu), Tags(empty)
   Title: "Add Bookmark"
   AcceptButton: "Add"

8. add bookmarks button through customize toolbars, drag & drop a link upon it
should show name (filled) and folder picker
   contents: name(filed), folder(bookmarks menu), Tags(empty)
   Title: "Add Bookmark"
   AcceptButton: "Add"

9. right click a bookmark and choose properties
   contents: name, location, folder, tags, keyword, description, load in sidebar
   Title: "Properties for "title""
   AcceptButton: "Save Changes"

10. right click a livemark and choose properties
   contents: name, feed location, site location, folder, description
   Title: "Properties for "title""
   AcceptButton: "Save Changes"

11. right click a folder and choose properties
   contents: name, folder, description
   Title: "Properties for "title""
   AcceptButton: "Save Changes"

12. right click a smart bookmark and choose properties
   contents: name, folder, description
   Title: "Properties for "title""
   AcceptButton: "Save Changes"

13. open 2 tabs, from bookmarks menu choose Bookmark all tabs
   contents: name("[Folder Name]"), folder(bookmarks menu)
   Title: "Bookmark All Tabs"
   AcceptButton: "Add Bookmarks"

14. "Bookmark this Link" in context menu of a hyperlink in the content area
   contents: name(filed), folder(bookmarks menu), Tags
   Title: "Add Bookmark"
   AcceptButton: "Add"

15. "Bookmark this Link" in context menu of an already bookmarked hyperlink in the content area
   contents: name, location, folder, tags, keyword, description, load in sidebar
   Title: "Properties for "title""
   AcceptButton: "Save Changes"

Comment 5

[Marco Bonardo [:mak]]

also, i think we agree all dialogs should be modal since we instant apply, actually only complete dialogs are, while minimal ui is modal only on OS X, so for example if i choose "Bookmark All Tabs" the dialog on Windows is not modal, so the user could close the browser without closing the dialog, losing bookmarks.

Comment 6

[Marco Bonardo [:mak]]

Alex you can test with trybuilds in https://bugzilla.mozilla.org/show_bug.cgi?id=411261#c45, the final result is slightly different from comment 4, more similar to actual behaviour... so i think it would be easier for you trying the build and put comments over dialogs

Comment 7

[Alex Faaborg [:faaborg] (Firefox UX)]

I'll try to get to this soon, if I don't reply within 48 hours can you ping me again.

Comment 8

[Marco Bonardo [:mak]]

Attachment: 1. history sidebar / bookmark this link [modal, resizeable]

to help Alex i'm posting screenshots of the different dialogs

Comment 9

[Marco Bonardo [:mak]]

Attachment: 2. context menu / New Bookmark [modal, not resizeable]

Comment 10

[Marco Bonardo [:mak]]

Attachment: 3. context menu / New Folder [modal, not resizeable]

Comment 11

[Marco Bonardo [:mak]]

Attachment: 4. livemark subscribe [modal, resizeable]

Comment 12

[Marco Bonardo [:mak]]

Attachment: 5. add keyword for this search [modal, resizeable]

Comment 13

[Marco Bonardo [:mak]]

Attachment: 6. Add sidebar panel [modal, resizeable]

Comment 14

[Marco Bonardo [:mak]]

Attachment: 7. bookmark a rel="sidebar" link [modal, resizeable]

Comment 15

[Marco Bonardo [:mak]]

Attachment: 8. drop on Bookmarks in the toolbar [modal, resizeable]

Comment 16

[Marco Bonardo [:mak]]

Attachment: 9. Properties of a bookmark [modal, not resizeable]

Comment 17

[Marco Bonardo [:mak]]

Attachment: 10. properties of a livemark [modal, not resizeable]

Comment 18

[Marco Bonardo [:mak]]

Attachment: 11. properties of a folder [modal, not resizeable]

Comment 19

[Marco Bonardo [:mak]]

Attachment: 12. properties of a smart bookmark [modal, not resizeable]

Comment 20

[Marco Bonardo [:mak]]

Attachment: 13. bookmark all tabs [modal, resizeable]

Comment 21

[Marco Bonardo [:mak]]

Attachment: 14. bookmark this link in content [modal, resizeable]

Comment 22

[Marco Bonardo [:mak]]

Attachment: 13. bookmark this link in content when bookmark exists [modal, not resizeable]

Comment 23

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: Spacing issues

This isn't a huge deal, but a lot of the dialogs have different spacing between the fields.  Ideally the spacing would be the same across the board.  Also, the progressive disclosure controls should ideally be the same height as the text field so that it visually groups a little more, and just so things look aligned.

Comment 24

[Alex Faaborg [:faaborg] (Firefox UX)]

In terms of wording, I've been giving some thought to the window titles and commit buttons for each dialog.

-I think we should alter the titles to be a little closer to the action the user just took

-In cases where there is pre-populated information, I think the commit button should just be "Save" (not "Save Changes" or "Add").  This is because the dialogs are instant apply, and "Save Changes" implies the changes haven't been saved yet (they have), and "Add" implies it hasn't been added yet (it has). 

-In cases where there is no pre-populated information, I think the commit button should be "Add." This is intentionally inaccurate, the bookmark or folder has already been created, but I think it reads a little better and feels more natural.

-In cases where the user is clicking a link to get a dialog box to add a new bookmark, the commit button should be "Add," since the pre-populated information is coming from a third party, and they might not have even expected to see a dialog when they clicked on the link.

Here is all the suggested text in the form:

user action > "window title text" > "commit button text"


1. history sidebar / bookmark this link > "New Bookmark" > "Save"
2. context menu / New Bookmark          > "New Bookmark" > "Add"
3. context menu / New Folder            > "New Folder"   > "Add"
4. livemark subscribe                   > "Subscribe to Live Bookmark" > "Subscribe"
5. add keyword for this search          > "New Bookmark" > "Save"
6. Add sidebar panel                    > "New Bookmark" > "Add"
7. bookmark a rel="sidebar" link        > "New Bookmark" > "Add"
8. drop on Bookmarks in the toolbar     > "New Bookmark" > "Save"

9. Properties of a bookmark        > "Properties for [name]" > "Save"
10. properties of a livemark       > "Properties for [name]" > "Save"
11. properties of a folder         > "Properties for [name]" > "Save"
12. properties of a smart bookmark > "Properties for [name]" > "Save"

13. bookmark all tabs                    > "New Bookmarks" > "Add Bookmarks"
14. bookmark this link in content        > "New Bookmark"  > "Save"
13. bookmark this link in content when bookmark exists  > "Properties for [name]" > "Save"

I think for 6 and 7 we should show the URL (since hte user hasn't seen it yet), and we should show the check box "load this bookmark in the sidebar", with the box checked.

How are 3 and 13 instant apply if they don't have a folder name yet?

Comment 25

[Marco Bonardo [:mak]]

(In reply to comment #24)
> How are 3 and 13 instant apply if they don't have a folder name yet?

I use the default folder name

so also on IRC we ponted out that about:blank for a new bookmark should be hidden if possible.

actually I could fix code and strings, and let further css refinements like spacing for a second pass after the string freeze

Comment 26

[Marco Bonardo [:mak]]

next nightly will contain changes, so feel free to add suggestions here (that are not part of known bug 413053)

Comment 27

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #24)
> -In cases where there is no pre-populated information, I think the commit
> button should be "Add." This is intentionally inaccurate, the bookmark or
> folder has already been created, but I think it reads a little better and 
> feels more natural.

This makes sense assuming that there is an associated "Cancel" button which destroys the newly created resource. That indeed seems to be the case as far as I can tell.

Those strings all look much better, yes.

> How are 3 and 13 instant apply if they don't have a folder name yet?

Items I create using 3 don't seem to show up until I click "Add", fwiw. Or is that part of the change you're making? It's important that in those cases "Cancel" means "don't actually create the thing" as opposed to "don't rename the thing from the default name to what I just said".

Comment 28

[Marco Bonardo [:mak]]

(In reply to comment #27)
> > How are 3 and 13 instant apply if they don't have a folder name yet?
> 
> Items I create using 3 don't seem to show up until I click "Add", fwiw. Or is
> that part of the change you're making? It's important that in those cases
> "Cancel" means "don't actually create the thing" as opposed to "don't rename
> the thing from the default name to what I just said".

It should appear as New Folder, and if you click Cancel it should disappear. It's working like that for me.

Comment 31

[Marco Bonardo [:mak]]

Alex, what is left to do here from a UI perspective?

Comment 33

[Marco Bonardo [:mak]]

Unless Alex has something against this (in such a case feel free to reopen and elaborate on that), i'm going to mark this as WFM based on changes in bug 411261 and followers, further changes should have their own bug.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1pre) Gecko/20090619 Shiretoko/3.5pre

Comment 34

[Gervase Markham [:gerv]]

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