> On Mar 2, 2016, at 1:37 PM, Richard Newman <rnew...@mozilla.com> wrote: > > Some scattered high-level feedback: > > > I like the definition of the menus as very simple, mostly declarative Swift > code. > > > Action definition is kinda thorny! Two particular things come to mind: > > Firstly, an action probably wants some input into what happens after the > action is triggered. > > For example, when we have bookmark 'foldering', the bookmark star might be a > two-step process, and we might want to keep the menu up until the user has > picked a folder. If the operation fails, the menu should stay up. Otherwise, > the menu should close.
If this was not clear: The menu is presented modally: it greys out the content under it. So ‘foldering’ (which is not one of the options that is in the design actually) cannot happen with the menu open. If, in theory, if we have an action item that requires this, then I assume this happens: • The menu closes. • After the menu animation, it runs some “Im closed!” callback • In that callback we open for example the bookmark browser/manager with the right form open No need to complicate this. > > There are a bunch of ways to do this kind of thing. One is to rely on > side-effects — e.g., have the action take the menu as an argument, and have > the action be responsible for dismissing the menu either before (when we open > settings?) or after (bookmark) it does its own work. > > Secondly, actions can be async and can fail. > > Perhaps one consequence of this is related to your animation concern: when I > tap the bookmark star, the item might not end up bookmarked, but if it does > it'll be 50-100msec later, at which point we want to animate the state of the > menu item (blue star). So the menu triggers the action, and the action pokes > the menu, perhaps even switching out menu items. My suggestion is to simplify this: just assume the operation will succeed. The change that this operation will fail is extremely small. Change the star color, close the menu. Run the bookmark operation in the background. I think we should prefer to make simple APIs Instead of trying to accomodate every edge case. This is not an ATM and we do not need that kind of UI consistency. Instead if the bookmark action fails, just queue an error dialog that shows when the menu is closed. > > Right now actions seem to be one-shot synchronous (or no handled result) > calls; this is a good time to think about if the 'signature' needs to be > different. > > I have no good suggestions about how to make sure that actions and the menu > interact well visually, beyond letting the action own everything — I'm > thinking about what happens when the menu triggers Find In Page, and we want > those two animations (menu dismissal, find in page bar appearance) to > coordinate. > > It's worth noting that there are concurrency worries here. The state of menu > items depends on async operations (isBookmarked), but the menu or even the > current tab could change while those operations are running. The current tab cannot change while the menu is open. The menu is modal. If the isBookmarked state of the page changes while the menu is open, for example because sync runs, that would be an edge case that we can ignore for the sake of keeping APIs simple in my opinion. S. _______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
