Closed Bug 515747 Opened 15 years ago Closed 15 years ago

bookmark manager is confusing to know if you are managing or not

Categories

(Firefox for Android Graveyard :: Bookmarks, defect, P1)

defect

Tracking

(fennec1.0+)

VERIFIED FIXED
fennec1.0b5
Tracking Status
fennec 1.0+ ---

People

(Reporter: jmaher, Assigned: vingtetun)

References

Details

(Whiteboard: [polish])

Attachments

(1 file, 2 obsolete files)

when clicking "manage" in the bookmark manager, I need visual indication that I am editing bookmarks. Also the "manage" text is really small and hard to read. Please: 1) make the manage text larger to match similar title bar font sizes 2) have a pressed state that toggled when it is pressed
22:02 <@mfinkle> jmaher: file a bug on the manage being pressed 22:02 <@mfinkle> and one for making the first row be in edit mode 22:02 < jmaher> first row in edit mode? 22:03 <@mfinkle> jmaher: madhava suggested it
I'm not completely sod on the above design. The user still has no idea how to edit other rows. My initial thought was a small banner across the top say "Click a row to edit the bookmark". Once the user clicked any row the banner would hide.
I really like the simplicity, I don't know how intuitive it really is. Maybe make all rows have the open edit feature and when you tap on it to edit it opens up the other fields (url, tags) and buttons?
Madhava Enros, from bug 517551: Right now, when you press the "Manage" button in the "All Bookmarks" list/manager, it remains visually inset, so you know that you've done _something_, but there is no other visual cue that anything has changed or how to proceed. I think the simplest thing we could do to show people how to proceed would be to pop open one of the rows to show its editable nature. If the one we open isn't the one that the user was looking to edit, it should be easier to make the leap to tapping on the one that they want. We could open up the first visible row on the screen - other thoughts?
tracking-fennec: --- → ?
Whiteboard: [polish]
Attached patch wip (obsolete) (deleted) — Splinter Review
* first row go into managed mode when we hit the 'Manage' button * disable the manage button is there is nothing to manage (or nothing more)
Assignee: nobody → 21
Comment on attachment 402591 [details] [diff] [review] wip >diff -r 867a2dac0998 chrome/content/bindings.xml > <setter> > <![CDATA[ > if (this._manageUI != val) { > this._manageUI = val; > if (this._manageUI) { > this.setAttribute("ui", "manage"); >+ this._children.firstChild.startEditing(); Not sure I like it here. Why not add it on the "Manage" button click? > if (aFolder) > query.setFolders([aFolder], 1); > let result = PlacesUtils.history.executeQuery(query, options); > let rootNode = result.root; > rootNode.containerOpen = true; >+ >+ let button = document.getElementById("tool-bookmarks-manage"); >+ if (aFolder == PlacesUtils.bookmarks.unfiledBookmarksFolder && rootNode.childCount == 0) { >+ button.disabled = true; >+ return items; >+ } >+ button.disabled = false; >+ Add this to the BookmarkList.show method > <method name="removeItem"> > <parameter name="aItem"/> > <body> > <![CDATA[ > this._children.removeChild(aItem); >+ >+ let isRootFolder = (this._parents.lastChild.getAttribute("itemid") == PlacesUtils.bookmarks.unfiledBookmarksFolder); >+ if (isRootFolder && this._children.childNodes.length == 0) { >+ this.manageUI = false; >+ >+ let button = document.getElementById("tool-bookmarks-manage"); >+ button.checked = false; >+ button.disabled = true; >+ } Hmm, "remove" method currently fires a "BookmarkRemove" event. You could make BookmarkList listen for the event. That would keep all of this code outside of the XBL.
Attachment #402591 - Flags: review-
Attached patch Patch (obsolete) (deleted) — Splinter Review
Address most of the comments. (In reply to comment #8) > (From update of attachment 402591 [details] [diff] [review]) > >diff -r 867a2dac0998 chrome/content/bindings.xml > > > <setter> > > <![CDATA[ > > if (this._manageUI != val) { > > this._manageUI = val; > > if (this._manageUI) { > > this.setAttribute("ui", "manage"); > >+ this._children.firstChild.startEditing(); > > Not sure I like it here. Why not add it on the "Manage" button click? I will be ok to move it into the toggleManage call if we equalize the behavior. Actually the manageUI property stops the edition when it is set to false, so I don't feels bad me to turn it on when manageUI is set to true. I can move the stop/start edit calls to the toggleManage code but it is much more easier and readable to do it here (after have tried).
Attachment #402591 - Attachment is obsolete: true
Attachment #406143 - Flags: review?(mark.finkle)
the .stopEditing call does not really need a balance. In this case, it's there to cleanup the editing mode if the manageUI is turned off while still in edit mode. If you want to keep the .startEditing code in this setter, then add a new attribute (autoedit="true") to the XUL and check for it in manageUI setter. If the attribute is "true", you can start editing. Sound ok?
Priority: -- → P1
tracking-fennec: ? → 1.0+
Attached patch Patch v0.2 (deleted) — Splinter Review
(In reply to comment #10) > the .stopEditing call does not really need a balance. In this case, it's there > to cleanup the editing mode if the manageUI is turned off while still in edit > mode. > > If you want to keep the .startEditing code in this setter, then add a new > attribute (autoedit="true") to the XUL and check for it in manageUI setter. If > the attribute is "true", you can start editing. > > Sound ok? Sounds perfect!
Attachment #406143 - Attachment is obsolete: true
Attachment #406360 - Flags: review?(mark.finkle)
Attachment #406143 - Flags: review?(mark.finkle)
Comment on attachment 406360 [details] [diff] [review] Patch v0.2 Works great. Thanks.
Attachment #406360 - Flags: review?(mark.finkle) → review+
We should add a test to one of the browser_bookmark files for this
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → B5
We'll need to update our litmus test case for this as well. verified FIXED on builds: Mozilla/5.0 (Windows; U; WindowsCE 5.2; en-US; rv:1.9.2b1pre) Gecko/20091021 Fennec/1.0a4pre and Mozilla/5.0 (X11; U; Linux armv7l; en-US; rv:1.9.2b1pre) Gecko/20091021 Fennec/1.0b5pre and Mozilla/5.0 (X11; U; Linux armv6l; en-US; rv:1.9.3a1pre) Gecko/20091021 Fennec/1.0b5pre
Status: RESOLVED → VERIFIED
Flags: in-litmus?
Component: General → Bookmarks
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: