Closed Bug 991123 Opened 10 years ago Closed 10 years ago

[UX] Design - Places async transactions: Implement "new folder" ui

Categories

(Firefox :: Bookmarks & History, defect)

x86
macOS
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 31

People

(Reporter: MarcoM, Assigned: zfang)

References

Details

(Whiteboard: [ux] p=8 s=it-31c-30a-29b.3 [qa-])

+++ This bug was initially created as a clone of Bug #984902 +++
Flags: firefox-backlog+
our plan is to use inline editing wherever possible.
Basically a user selects New Folder in the menu, we create a new folder named New Folder and we create an inline-editing textfield in place of the name. It would work basically the same as in Windows Explorer.
Now the problem is that we can do this in the Library and on the toolbar, but in menus there may be focus issues (especially on native menubars) that make this impossible, so for those we either need to not provide the option at all, or to fallback (like creating the folder and opening the Library on the folder, though this would be awkward). It's possible this issue is limited to native menubars, we can't tell until we reach that point.
We'd like feedback about the proposal and possible ideas for a fallback.
Whiteboard: [ux] p=0 → [ux] p=8
Assignee: nobody → zfang
Status: NEW → ASSIGNED
Whiteboard: [ux] p=8 → [ux] p=8 s=it-31c-30a-29b.3 [qa-]
Hi Marco, inline editing sounds great! I have a few question about this bug:
1. You mentioned we can do the inline editing in library, do we already have a design on that? is this the main UX ask in this bug? and is the design based on the current library window or in-content?
2. You mentioned we can't do the inline editing in the menubar, do you mean bookmarks toolbar? or the menu panel?  

Feel free to email or ping me on IRC.
Flags: needinfo?(mak77)
(In reply to Zhenshuo Fang (:fang) - Firefox UX Team from comment #2)
> 1. You mentioned we can do the inline editing in library, do we already have
> a design on that? is this the main UX ask in this bug? and is the design
> based on the current library window or in-content?

We don't have a design, but we are already doing that when creating a new folder in the star panel (double click the star, open the folder expander, click new folder). I think the first implementation may just work like that, it's basically just a textfield in place of the label.

> 2. You mentioned we can't do the inline editing in the menubar, do you mean
> bookmarks toolbar? or the menu panel?  

We can do the inline editing in the toolbar.
What we are worried about is doing inline editing in popups, cause that may have many issues with focus management. And even more specifically the native menubars on all of the platforms. We may need to fallback to something else in those case, but we don't have very clean ideas about those fallbacks.
Flags: needinfo?(mak77) → needinfo?(zfang)
I don't think we're worried about native menubars - those just don't have context menus. It's xul menupopups (under the toolbar, under the menubar on windows and under the bookmarks button popup) that are problematic. It's not just technical issues. Rather, it's the fact that such native UIs don't exist, as far as I know.
(In reply to Mano from comment #4)
> I don't think we're worried about native menubars - those just don't have
> context menus.

Well, sorry, I said native to distinguish from the menu we open from the bookmarks widget, but it's indeed not "native" in the sense we usually intend (as "provided by the OS"). I should have said "Legacy menubar" probably.
Regardless, what you say is correct, both it may be problematic to handle focus bugs and it's really not native to do inline editing into a menupopup. Though, if you look at IE, they present sort of a sidebar inside the bookmarks menupopup and they do inline editing there, so it's not even so exotic for the users.
Thanks for answering my questions! I can certainly ui-review the in-line editing in library and toolbar when we have them. 

I agree that in-line editing in the native menus or menu pop-ups are weird. IE's approach is not very natural and doesn't quite apply with our UI. IMO the fall back would be just not providing the inline editing and keep the current modal dialog for menu pop-ups. Another alternative mentioned is opening the library and using the edit interface there, but I think that's probably something we want to do after we have the in-content library since currently it's a window that can get lost easily and doesn't add much value than the modal dialog.
Flags: needinfo?(zfang)
Mark this fix for now, but we should keep the discussion if necessary.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Target Milestone: --- → Firefox 31
You need to log in before you can comment on or make changes to this bug.