Closed Bug 392976 Opened 17 years ago Closed 16 years ago

Cancel / Done Buttons in the new add bookmark dialog are in a "mac like" order

Categories

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

x86
All
defect

Tracking

()

VERIFIED FIXED
Firefox 3 beta5

People

(Reporter: moco, Assigned: fittysix)

References

Details

Attachments

(2 files, 1 obsolete file)

Delete / OK Buttons in the new add bookmark dialog are in a "mac like" order.

as a windows user, I'd expect "OK" then "Delete", instead of "Delete" then "OK".

I'll attach a screen shot.
And when this panel is shown for 'Bookmark This Link' for links in a page, the 'Delete' button doesn't make sense to me. For this scenario, the button must be labeled 'Cancel' as that is what is normal UI design for such actions. 
I talked to Beltzner about this before he left, we think we should have "remove" (renamed from delete) on the far left of the dialog, and then OK/Cancel (in platform correct order of course) on the right side.  I'll update the mockups and post them to the respective bugs.

>as that is what is normal UI design for such actions

Agreed, the OK button was tacked on in one of the designs because we were worried that users wouldn't realize they could just click outside the panel to dismiss it (changes are saved automatically), but we can't have OK with out having Cancel as well.
Er, I changed this to Delete/Done in the last patch since changes apply as they're done, I'm not sure what's the windows/*nix convention for this sort of dialog (in gnome, instant-apply preferences windows seem to have a "Close" button).
I think that this 'instant-apply' principle doesn't apply to bookmarking. Bookmarking is an active process where an user *creates* a bookmark (even if the star creates the bookmark immediately, after which the second click allows the user to add keywords and define location/folder).
At least when this panel is opened from the 'star' it must be labelled/titled to describe to the user what is really going on.

For the 'Bookmark This Link' action, it is really a 'Create' action, which should either be 'cancellable' or 'OK'ed.
From bug 385266, #26 (https://bugzilla.mozilla.org/show_bug.cgi?id=385266#c26):
Can the buttons receive an 'id' so that we can theme them with a nice icon?
Alfred, file bugs, please.
Created bug 393257 and bug 393253 and re-opened bug 394285.
Flags: blocking-firefox3?
This isn't a traditional dialog: the contextual dialog is instant apply to streamline the interaction.  We are going to rename delete to "remove," (which is functionally the same as cancel after clicking the star) and probably adding a close button that (along with clicking anywhere outside of the contextual dialog) functionally means "ok."
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
(In reply to comment #9)
> This isn't a traditional dialog: the contextual dialog is instant apply to
> streamline the interaction.  We are going to rename delete to "remove," (which
> is functionally the same as cancel after clicking the star) and probably adding
> a close button that (along with clicking anywhere outside of the contextual
> dialog) functionally means "ok."

I'm not sure why this comment means this bug is WONTFIX, especially given your comment 3 where it's said that what buttons are there are going to be in the right order. We still need a bug to track doing that correctly, right?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
It still feels like a traditional dialog for me.
And having Delete / OK in this order is just weird for me here on windows.
Why not change it to OK/ Delete and let the Mac users suffer? (ok, lame remark ;) )
Sorry, wontfixing because the next iteration of the design will have only one button, named "remove" and therefor it is hard for the single button to be out of platform-specific order :)

I'm actually not sure the best way to resolve a bug that gets invalidated by a design change, perhaps invalid makes more sense?
Status: REOPENED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → INVALID
Flags: blocking-firefox3?
Status: RESOLVED → VERIFIED
Why is this an invalid bug? In Windows OS, accept comes *before* cancel
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
Flags: blocking-firefox3?
The implemented design has changed, this bug is no longer valid.
Status: REOPENED → RESOLVED
Closed: 17 years ago16 years ago
Flags: blocking-firefox3? → blocking-firefox3-
Resolution: --- → INVALID
What do you mean by "has changed". It is still Cancel and Done, and this order is bad/invalid UI in Windows OS. I've been clicking the wrong buttons for the past four months.

Confirmed, this is still a problem for the "Already bookmarked" case. Not likely to be a blocker at this point, but renominating because the reason for minusing was invalid.
Status: RESOLVED → REOPENED
Flags: blocking-firefox3- → blocking-firefox3?
Resolution: INVALID → ---
Status: REOPENED → NEW
My mockups didn't specify using the correct order of dialog box buttons on each platform, but yes, we really need to do this.  beltzner: this is a pretty obvious usability problem with the dialog, I recommend we block on getting them in the right order.
Flags: blocking-firefox3? → blocking-firefox3+
Priority: -- → P2
Target Milestone: --- → Firefox 3
Assignee: nobody → mano
Keywords: uiwanted
Summary: Delete / OK Buttons in the new add bookmark dialog are in a "mac like" order → Cancel / Done Buttons in the new add bookmark dialog are in a "mac like" order
(In reply to comment #17)
> Confirmed, this is still a problem for the "Already bookmarked" case.

Why only for the "Already bookmarked" case ?
The problem is the same when the page isn't in the bookmarks. The only difference is the "Remove Bookmark" button.
Attached patch possible patch (obsolete) — Splinter Review
can we get this in for b5? this is really, really annoying.
Specifically uses ok/cancel on XP since that's what this bug is about, preserves current behavior on all other OSs.
It should be #ifndef XP_UNIX.
per comment #26
Attachment #311228 - Attachment is obsolete: true
Attachment #311266 - Flags: review+
Attachment #311266 - Flags: approval1.9b5?
Assignee: mano → fittysix
Keywords: uiwanted
(In reply to comment #26)
> It should be #ifndef XP_UNIX.

Well, it seems that the cancel button is on left under Mac as well as under *nix.
Keywords: uiwanted
Keywords: uiwanted
Right, and that's why it should be ndef XP_UNIX (XP_UNIX includes both mac and *nix builds).

See also dialog.xml
(In reply to comment #25)
> Created an attachment (id=311228) [details]
> possible patch
> 
> can we get this in for b5? this is really, really annoying.
> Specifically uses ok/cancel on XP since that's what this bug is about,
> preserves current behavior on all other OSs.

So will this fix Vista as well? The button order should be the same on Vista as XP.
This will fix all windows versions to be Done/Cancel (XP was just the first thing that came to my head when I thought windows for some reason)
More accurately the current version changes all non-unix(being linux, osx, others) to Done/Cancel.
Err, sorry for bugspam I worded that last one wrong.
Unix includes linux, osx, others
non-unix is being changed to done/cancel.
Comment on attachment 311266 [details] [diff] [review]
Possible patch v2

Probably good enough, not sure its quite the same logic as we used for dialog.xml, but it'll do.

whoever checks this in please fix the off by one alignment in the new ifdef.  I would probabvy have just inverted the order, but this is fine to land.
Attachment #311266 - Flags: approval1.9b5? → approval1.9b5+
Keywords: checkin-needed
Checking in browser/base/content/browser.xul;
/cvsroot/mozilla/browser/base/content/browser.xul,v  <--  browser.xul
new revision: 1.453; previous revision: 1.452
done
Status: NEW → RESOLVED
Closed: 16 years ago16 years ago
Keywords: checkin-needed
OS: Windows XP → All
Resolution: --- → FIXED
Target Milestone: Firefox 3 → Firefox 3 beta5
verified with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032606
Firefox/3.0b5
Status: RESOLVED → VERIFIED
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
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: