In the menu demo at the Product meeting yesterday, Robin mentioned that a future update to the menu will allow for user configuration of the menu order. The current design of the configuration doesn't account for this.
I'm having a think about the changes that need to be made to accommodate this, but I'd also like to open the question out. What are good ways to make the menus user configurable? As always, feedback/comments/ideas are welcome. On 3 March 2016 at 18:15, Emily Toop <et...@mozilla.com> wrote: > Thank you all for attending the menu meeting. All your feedback and > comments were greatly appreciated. > > Next steps (Please remind me of anything I have forgotten): > > * Update DisplayLocation enum to become MenuState enum that will contain > the current state required by the menu based on display location, current > URL etc. > * Pass this into the MenuViewController on creation and whenever the state > changes (i.e. the URL changes in the background) > * When setting a menu state, invalidate the menu causing a reload of the > menu data & relayout of the components so the menu is always in sync with > the current menu state (The design of the menu as a datasource/delegate > view controller a la UITableViewController makes this trivial) > * Create a MenuViewControllerDelegate that takes an instance of MenuItem > as argument. Objects implementing this delegate would then be responsible > for calling the associated Action on the MenuItem, injecting the delegate's > requirements as needed. The delegate should be set on menu creation. > * Create Pre and Post menu dismissal animators to handle animation actions > that MenuItems might have to perform (i.e. bookmark twiddling or display of > Find In Page dialog). Attach to MenuItems so they are called in sequence on > menu item selection. > > Once again I will update the sample project and send around for feedback. > > Thanks again. > > On 3 March 2016 at 16:03, Richard Newman <rnew...@mozilla.com> wrote: > >> If this was not clear: The menu is presented modally: it greys out the >>> content under it. >> >> >> That's good to know! >> >> So we can start noting some constraints: >> >> >> - The menu is always displayed modally, even on iPads: the user can't >> interact with anything but the menu. >> - The menu must always close after the first interaction: we will >> never support multi-step actions like tap-toggles, slide-out choices, etc. >> within the menu itself. >> >> >> Now we can return to asking more questions: >> >> >> - What happens when pages do in-page navigation? Is the menu >> closed, do items need to respond to page navigation events, are we going >> to >> suspend page navigation when the menu is open, or are we willing to have >> the menu reflect the state of some page that's not the one the user can >> see >> behind the menu? Some of these require that the menu 'capture' the current >> tab state at the instant of open; others require that the UI reflect >> navigation changes. >> - Similarly, what happens when pages trigger a new tab open? (Our >> current behavior if Block Pop-ups is unchecked is that window.open opens >> and focuses a new tab without user involvement.) >> - What happens if a page shows an alert while the menu is open? >> Alerts are modal, too. Do we just queue them? Are races possible here? >> >> >
_______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
