> > In a way I want to at least think about the changes that might be needed > for a user configurable layout as I don't want to have to go through a > whole pile of refactoring of the underlying menu code if we do decide we > want to do this, but at the same time I don't want to overcomplicate the > design now based upon a future requirement that we might not implement for > a long time, if ever.
I'm not sure I'd be focusing on this right now. The existing design of using a collection view would lend itself to user re-ordering, and the storage and maintenance of a sort order would be a relatively simple addition. (see https://developer.apple.com/library/ios/documentation/UIKit/Reference/UICollectionView_class/index.html#//apple_ref/doc/uid/TP40012177-CH1-SW67 ) Some thought needs to be made around exposing new menu items to a reordered/filtered list, though this is even further out in the future. On Wed, Mar 9, 2016 at 11:36 AM, Emily Toop <et...@mozilla.com> wrote: > also, is this something that we should even be taking into account now at > this stage or do we just build for the existing design and work out > potential future needs when they come about? > > In a way I want to at least think about the changes that might be needed > for a user configurable layout as I don't want to have to go through a > whole pile of refactoring of the underlying menu code if we do decide we > want to do this, but at the same time I don't want to overcomplicate the > design now based upon a future requirement that we might not implement for > a long time, if ever. Either way, thinking about the challenges of user > configuration will help us make design decisions now that will allow for > ease of extendability later. > > On 9 March 2016 at 11:30, Emily Toop <et...@mozilla.com> wrote: > >> 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 > >
_______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
