993375 - [UX] Design - Places async transactions: edit properties ui and star ui

Status: VERIFIED FIXED

(Firefox :: Bookmarks & History, defect)

Description

[Tim Taubert [:ttaubert] (inactive)]

We need some UX feedback before we can continue work on bug 951651 and bug 984904.

"Mano is working on a new asynchronous transaction manager (undo/redo feature) for bookmarks. Now that the backend part is done we can start converting consumers.

Editing a bookmark through the Properties menuitem (from the contextual menu) currently opens an edit panel, that is instant-apply, but can be Canceled (in such a case we have to revert all of the instant-apply changes). Mano suggested to rather open the Library with the given bookmark selected and reuse the edit panel in the library to allows the user to modify it. This will probably work even better with in-content Library."

Comment 1

[Zhenshuo Fang (:fang) - Firefox UX Team]

Hi Tim & Mano,
Could you provide more information on the asynchronous transaction feature? My initial thoughts to the questions above is to just open the edit doorhanger that's not modal when user click on Properties to edit a bookmarks, instead of opening the library. But I'd like to know your thought process behind it. Feel free to email or ping me on IRC.

Comment 2

[Asaf Romano (gone)]

Hi Zhenshuo,

First of all, you should know that, from the point of view of UX, this feature may be considered technical details. These UI questions pop up because the work on this feature involves partial-to-full rewrites of various Places-UI code "modules", and since "some" people are unhappy with the current UI, it seems reasonable to sort out if rewriting the questionable UI just the way it is is the best way to go (in the second section, I'll elaborate on the specific UI design issues for this particular bug). But first, here's a brief overview of the "async transactions" feature (don't feel obligated to read it, it's here for a reference and for you, if you're interested).

1. Overview for this feature 

"transactions" (not just in Places) are what allows us to implement undo and redo for UI commands. It's implemented in the form of a "bridge" between the back-end and the the UI, so, for instance, in order to make "New Separator" undo-able, the "New Separator" UI command doesn't call directly the "new separator" code, but goes through a "new separator transaction" that calls the back-end function code, but also knows how to undo/redo it. For Places, this means that most places UI commands are unaffected by changes to the back-end API as long as they're not reflected in the "higher", transactions API.

Now, there's an ongoing effort (the "async project") to make Firefox's UI as asynchronous  as possible when it comes to I/O and database access, so that, for example, the "new separator" command discussed above does not block the UI until the necessary database modifications are applied. Most of the time this effort doesn't not involve major UI-code rewrites: some back-end synchronous functions replaced by an asynchronous one, and then the front-end functions that called it are fixed to work with the new API.

For Places UI commands, however, things are more complicated, and that's because the "transactions bridge" between the Places UI and the Places backend cannot be fixed one-step-at-a-time as we do elsewhere (with some commands being synchronous and some asynchronous, the undo stack would break easily). So, we decided to implement the new "async" transactions API on top of the "sync" backend API before we fix the write a new async-backend. This means that the Places front-end is going to be ready for an async back-end before it's in places. Of course, as long as there's no async-back-end, there's not going to be any performance difference. That's why the feature not more than "technical details" for UX.

2. The various problems with the Properties, Star-UI and "New Bookmark" UI(s).

Since Firefox 3.5, I think, there are 3.5 ways to edit the properties of a bookmark or a folder:

* Within the library one may edit the title, url, tags, keyword and the description properties of a bookmark in the bottom panel. This is an instant-apply UI with no cancel-it-all option (it's possible to undo though, and to cancel-it-all you just need to undo multiple times). The instant-apply behavior is very clear to the the user as the changes he does over there are reflected in the list above the panel.

* Within the "is-it-modal?" Star-Panel UI you can edit a different set of properties
  - If you hit Accel+D when an un-bookmarked page is loaded, it's first bookmarked (and the star reflects that), but the Star-Panel also opens up. Any changes applied through this dialog are applied instantly, but this fact can go unnoticed (you'd have to have the library open in the background to see the action taking place). The "cancel" button in this states removes the new bookmark.
  - If you hit Accel+D or click the star button when a bookmarked page is loaded, the Star-Panel opens. It's unnoticeable-instant-apply-ui just as well. There's a cancel button to undo all changes (by the way, you can actually create folders in this UI, and "Cancel" would undo that too). Note that in this mode there's also a "Remove Bookmark" button.

* The properties dialog - If you right click a bookmark in the bookmarks toolbar (invisible by default), in the bookmarks menu (power-users material; not possible on mac, by the way) or in the bookmarks sidebar, there's a "Properties" option that opens a *modal* dialog that has the same set of properties as in the Library bottom panel (without the more/less button though). Although it's modal, it's implement in an instant-apply manner (the cancel button there is, in fact, an undo-all button). If one alt-tabs to the library while this modal dialog blocks... just the browser, he could find an handful set of bugs (you can remove the bookmark while it's being edited; the cancel button may undo actions done in the Library). Of course, no one does such things, but it shows how broken this semi-instant-apply concept is. By the way, the only reason this issue does not apply to the Star-UI is that you cannot keep it open while doing something else. It closes as soon as you click/tab out of it, or switch to another window.

On top of that, the-modal-but-instant-apply-with-cancel-button properties dialog is used for few other UI actions:
1) Bookmarks This Link, Bookmark All Tabs, Bookmark This Frame (I think, not sure), Subscribe (Live Bookmarks option).
2) A "New Bookmark" UI command (accessible from the Library and from context menus) that allows one to create a bookmark with their own URL. The true use cases for this UI are limited, being only bookmarklets and "place:" URLs. Both are very-power-user features. Even without this command, it's possible to create them in other ways: Bookmark This Link for bookmarklets, if possible, or, at worst, creating a bookmark for the current page and modifying its URL (I don't think we care about place: URI bookmarks, but the later solution works for them too). 
3) A similar "New Folder" command - that's going to be covered in bug 991123.

In an asynchronous Places system - for which "async transaction" are the first step, as explained in the previous section - some of this UI interactions are problematic:
1) Having a Cancel/Revert button in an instant-apply properties dialog (modal or not) means that other ways of interacting with the places UI would be unresponsive as long as that dialog is open. That's because Cancel is implemented in the form of undo-all, and in order for undo-all to work, we need to make sure we know that "all" is limited to whatever happens in the dialog. In the current synchronous setup, it's just buggy (and only if you mess with the same bookmarks), but in the async-setup a cancel button in an instant-apply dialog hurts much more. It's less of an issue in the star panel, because, again, it cannot stay open as you go somewhere else.
2) The "dummy item" behavior of "New Bookmark" (a "New Bookmark" item shows up in the Library list while you're creating the bookmark would be buggy when Places becomes asynchronous for real.

Moreover, maintaining all those separate workflows is a pain, especially when some of them are rarely used.

Basically, for the asynchronous transactions feature to move on, we need to be strict on which actions are instant-apply, which aren't, and which have to stay in the middle (The Star UI, I guess. Even though "Remove Bookmark" could work). At the moment, we have neither an asynchronous or a synchronous edit-ui outside the Library. The "edit doorhanger" you referred in your comment is not something we have at the moment. It's available only in the Star UI and it allows editing a very limited set of properties. a doorhanger panel is also not useful within bookmarks menus.

Opening the Library for editing a bookmark is suboptimal, but it'll make sense, I think, when the Library moves to the content area. The question is whether or not opening the Library window until such time is acceptable. If it's not, we need to figure out what we do with these "Properties" menu items. The problem I see is that on Windows a dialog that's instant-apply doesn't make sense (and unlike the Library UI, it's not so clear how to undo changes in this window. Accel+Z would work, but there's no menubar/toolbar). So, I think that our alternatives are either: (*) Use a modal properties dialog with no instant-apply hidden behavior; (*) Open the Library.

Comment 3

[Zhenshuo Fang (:fang) - Firefox UX Team]

Hi Mano, thanks for explaining in detail about the background of the project!

For the star-panel UI, we do have a plan to redesign the UI as well as the behavior, see bug 978459. The star panel shows up right after the first click of the star and the behavior should be similar to when user hit Accel+D. We should probably also change the "cancel" (cancel-all) to "remove bookmarks" just to make it more clear what it does.

For the Properties dialog, is it possible to make it star-ui like? meaning that user cannot keep it open while doing something else? I think opening the library when user just want to edit the properties of one bookmark seems overkill, especially when we don't have an in-content library yet. I think opening the library when it's in-content might make sense, but we shouldn't block this work because of that. So for now using the modal properoties dialog would be my preference.

Comment 4

[Asaf Romano (gone)]

Star Panel:
If the popup always shows up, we can pretty much give up instant apply there, because it doesn't really matter if the page is bookmarked while the popup is open. That said... what's the time frame for this change to happen? (Btw, I still think it's a mistake, but that's out of the scope of this bug, or my job :) ).

The async-transactions project should be done sometime in the next couple of months. If you think The redesign isn't going to happen ahead of that, then we need some sort of mid-term solution.

Properties:
I think a popup-edit-properties ui isn't going to work well, esp. because it's just a little too odd to open such a popup when a menu is open. Plus, considering that you'd have a regular menu, on top of which a context menu that's closing (when you hit Properties) and a new popup showing up, the chance of that working without bugs (or just plain annoyance even if not bug per-se) is quite slim.

I'll go with a modal dialog then.

Comment 5

[Asaf Romano (gone)]

One more thing: we still need to figure out if the "New Bookmark" feature should be kept.

Comment 6

[Zhenshuo Fang (:fang) - Firefox UX Team]

(In reply to Mano from comment #4)
> Star Panel:
> If the popup always shows up, we can pretty much give up instant apply
> there, because it doesn't really matter if the page is bookmarked while the
> popup is open. That said... what's the time frame for this change to happen?
> (Btw, I still think it's a mistake, but that's out of the scope of this bug,
> or my job :) ).
> The async-transactions project should be done sometime in the next couple of
> months. If you think The redesign isn't going to happen ahead of that, then
> we need some sort of mid-term solution.
> 

I think the redesign of star panel is also happening next couple of months, but I would love to know your feedback on the "show star panel on first click" and coordinate on the timeline.

> Properties:
> I think a popup-edit-properties ui isn't going to work well, esp. because
> it's just a little too odd to open such a popup when a menu is open. Plus,
> considering that you'd have a regular menu, on top of which a context menu
> that's closing (when you hit Properties) and a new popup showing up, the
> chance of that working without bugs (or just plain annoyance even if not bug
> per-se) is quite slim.
> 
> I'll go with a modal dialog then.

Yeah that's kinda true. I think modal dialog for now until we figure out the new plan for in-content library. And I'd say the same goes for "New bookmarks" feature, we'll make sure to have a better "New bookmarks" experience in the new in-content page.

Comment 7

[Asaf Romano (gone)]

I'm not sure I understand your answer about "New Bookmark" - my question is, do we still need this feature?

Comment 8

[Zhenshuo Fang (:fang) - Firefox UX Team]

(In reply to Mano from comment #7)
> I'm not sure I understand your answer about "New Bookmark" - my question is,
> do we still need this feature?

Hey sorry somehow I missed this comment. For "New Bookmark" I think we should keep the feature as it is, which it a modal dialog in library, till we have a concrete plan for in-content library. Does it make sense?

Comment 9

[Zhenshuo Fang (:fang) - Firefox UX Team]

I think the UX input is enough to move the project forward, mark this fixed now, we can reopen it if necessary.