403699 - a usability problem with the "edit bookmark" contextual dialog, how do you undo / cancel? (" add bookmark ": for bugzilla queries only)

Status: VERIFIED FIXED

(Firefox :: Bookmarks & History, defect, P2)

Description

[(not reading, please use [e-mail] instead)]

a usability problem with the "add bookmark" popup/dialog, how do you undo / cancel?

this is something that dolske pointed out to me:

1)  go to yahoo.com, click the star once to bookmark it
2)  click the star again, and attempt to change the title from "Yahoo!" to "abc" (or change the folder, or tags or something else)
3)  decide, before you hit "delete" or "done" that you don't want to change the bookmark.

if you hit delete, the bookmark is gone completely
if you hit done, your changes are are set.

I think we need some way to cancel out of this dialog.

upon further testing, it looks like changes made to the bookmark title and the folder are effective on blur, so perhaps cancel is omitted by design?

Comment 1

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

Cancel is omitted by design.  The rational is that if we add cancel then we also have to add ok, and if we have ok then we can't create an instant apply interface that allows you to click anywhere outside of the dialog to close it (because are the changes going to be saved, or not?).  So to streamline the entire interaction, we broke a usability rule and are not supporting undo in the current design.  We'll get feedback during the beta process to see if user's find this an acceptable tradeoff.

Comment 2

[(not reading, please use [e-mail] instead)]

thanks alex.

based on your comments, marking this as WONTFIX.

I've found a bug, which is:  on escape (to close the panel), we don't seem to be forcing the blur which should be saving changes.  I'll go log that.

Comment 3

[(not reading, please use [e-mail] instead)]

> I've found a bug, which is:  on escape (to close the panel), we don't seem to
> be forcing the blur which should be saving changes.  I'll go log that.

logged bug #403715

Comment 5

[John]

Having the Delete button there would mean that you would assume that people would often accidentally star things and decide, I don't really want to "star" this.

Or that it would be another way to delete bookmarks, by going to the URL that you don't care for anymore, clicking star, then delete.

Both seem like really ridiculous scenarios to me.

Comment 6

[Al Billings [:abillings - ex-MoCo]]

This is the new design. There are no plans to change this. 

Bookmarks are created when the page is starred instantly, not after confirmation. This makes it much easier to quickly save a page and move on.

Comment 7

[Rudolf Krist]

Did you read my argumentation? So you think it is a good idea to throw away the work of creating a well descripting title of a bookmark, if accidently the title was modified by user and he wants to cancel the modification? That is a strange design.

Comment 8

[Rudolf Krist]

Sorry I thought it was the bug, that I have reported, there I have written my argumentation. With my argumentation I mean the bug description of https://bugzilla.mozilla.org/show_bug.cgi?id=409391
I think I describe a common scenario there.

Regards
Rudi

PS: sorry for my poor English, I'm not a native English speaker.

Comment 9

[John]

"Did you read my argumentation? So you think it is a good idea to throw away the
work of creating a well descripting title of a bookmark, if accidently the
title was modified by user and he wants to cancel the modification? That is a
strange design."

Never considered that. Yeah, touche!

"This makes it much easier to quickly save a page and move on."

Since it's so much slower and harder as it is now...

Comment 10

[John]

"The rational is that if we add cancel then we
also have to add ok, and if we have ok then we can't create an instant apply
interface that allows you to click anywhere outside of the dialog to close it
(because are the changes going to be saved, or not?)."

Why is there a need for an instant apply interface? You'd only need to click outside the box to exit if you were trying to close it quick which would only happen if you're a frequent accidental starrer which I don't think you guys assume of most users. Why not revert it to a traditional dialog? Makes it less ugly, more normal, allows for Rudolf's argument which is if you entered in some **** but then thought it was ****, revert to whatever it was.

Comment 11

[Rudolf Krist]

"This makes it much easier to quickly save a page and move on."

Why the bookmarking should be slower or more complex, when you added the cancel button.

my suggestion is following behaviour

(1) [star] -> bookmark is added to "non-sorted-in bookmarks" (*1
                                          /bm:state0/

(2) prereq: bookmark is already stored    /bm:state1/
    -> [star], [modify sth.], [click outside dialog]
    -> modified bookmark is stored        /bm:state2/

(3) prereq: bookmark is already stored    /bm:state1/
    -> [star], [accidentl. modify sth.], [click on cancel button] (*2
    -> the modifications are discarded    /bm:state1/

the scenario (3) illustrates my point.
I don't think that we need to revert the star/bookmark dialog to a traditional dialog, just add the cancel button to discard the bookmark modification made accidently.

regards
rudi

Comment 12

[Rudolf Krist]

__
(*1 - I don't know what is the correct English name of this folder, 
      because I use the German localized Version of Firefox

Comment 13

[Al Billings [:abillings - ex-MoCo]]

This is by design for Firefox 3. Barring large amounts of negative feedback, at this point, this design isn't going to be re-done from scratch.

Comment 14

[Rudolf Krist]

Sorry, I tried to understand why it is not possible to add the cancel button, but I couldn't.

You say that there is by design no cancel button - what does it mean?? This answer is too abstract for me. Does it mean that it would need too much effort to add a button to a dialog? Why?

You also say: "The rational is that if we add cancel then we also have to add ok" this argument, I cannot follow too. Instead of reacting to the event "press OK button" the modification can be stored on any other event, "click outside dialog", "press done button". Why are you bound to modify the stored data on any modification of the dialog contents?

Regards
Rudi

Comment 15

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

>I tried to understand why it is not possible to add the cancel button,
>but I couldn't

If we have a traditional dialog, similar to what we have now, the same percent of users (not very many) will bookmark the same number of pages (also not very many).  People will continue to ignore bookmarking and just search google every time to revisit sites.  The purpose of these dialog changes is to create a streamlined interface, one that you can finish using in an incredibly short period of time (click on star to bookmark, click outside dialog to close).  People who dislike this new interface the most tend to bookmark a lot of pages with the current interface, but these users are a minority of our overall user baser.

>This is by design for Firefox 3. Barring large amounts of negative feedback, at
>this point, this design isn't going to be re-done from scratch.

We've received sufficient amounts of negative feedback, also interfaces that don't support some level of undo suck.  Beltzner and I have come up with a design that keeps the instant apply nature and also supports undo.  Mockups will be posted to bug 393509 as soon as I get time, and hopefully we will be able to get the change in for beta 3.

I'm marking this bug as a dupe so we can get discussion in a central place.

Comment 16

[John]

Do you have actual user interface labs (actual human survey groups) to suggest that the traditional bookmarking method repels users and that starring will attract them? I can understand that most users don't bother to bookmark but I don't see how starring will encourage them to nor do I see how much a repellent a traditional dialog box is.

"The purpose of these dialog changes is to create a
streamlined interface, one that you can finish using in an incredibly short
period of time"

...

"(click on star to bookmark, click outside dialog to close)"

Well if they double clicked the star to pull down the dialog box, I don't see why it would be so much faster to click out the box when they're right at it...

 

Comment 17

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

>Do you have actual user interface labs (actual human survey groups) to suggest
>that the traditional bookmarking method repels users and that starring will
>attract them?

We do the bulk of our analysis through our large number of users of the nightly builds, and in field ethnographic observation (as opposed to controlled lab environments).  While we have limited data, it is very clear the current bookmark interface is failing to meet user's needs.  If the star interface will perform better is less conclusive.

>Well if they double clicked the star to pull down the dialog box, I don't see
>why it would be so much faster to click out the box when they're right at it...

Because the target area is several orders of magnitude larger (technically infinite if the user hits a screen edge).

Comment 18

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

Reopening so that I can request blocking+, design discussion will still happen over in bug 393509

Comment 19

[Tracy Walker [:tracy]]

adjusting summary to reflect the true function of the "edit bookmark" contextual dialog.

Comment 20

[Tony Mechelynck [:tonymec]]

Question: Will this dialog get Cancel/OK buttons when browser.preferences.instantApply is FALSE? If not, why not?

Comment 21

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

I'm not familiar with why we have browser.preferences.instantApply, what was the rational of adding the pref?

Comment 22

[Asaf Romano (gone)]

That preference applies to the preferences (options) dialog and its default is set differently for each OS.

Comment 23

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

The design now in the nightly builds (based on i9) contains three different states, and each state has a direct visual affordance for undo/cancel.  The design might still get refined in the future, but I believe this usability problem has now been directly addressed.

Comment 24

[Al Billings [:abillings - ex-MoCo]]

Verified in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008050904 Minefield/3.0pre. We have the cancel options now.

Comment 25

[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