>
> … 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.
>
This. We have so much else on our list of things to do that as soon as the
menu as-is tests well, we'll be prioritizing other work. We might find that
we ne
> On Mar 9, 2016, at 6:36 AM, Emily Toop 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?
We need to ship the menu in 4.0. So I would keep i
>
> 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
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 do
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,
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 locat
>
> 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 alway
> On Mar 2, 2016, at 1:37 PM, Richard Newman 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
>
> I wanted to get feedback on the general menu definition/configuration
> approach before spending too long working out how all of the actions will
> fit in, both here and elsewhere in the project.
>
Thumbs up on those bits :D
___
mobile-firefox-dev ma
Yeah, I've kinda left the Action stuff a little hazy for now. I wanted to
get feedback on the general menu definition/configuration approach before
spending too long working out how all of the actions will fit in, both here
and elsewhere in the project.
You made some good points about the async na
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 exampl
[Discussion moved to public channel for openness]
iOS folks,
After last weeks meeting with Steph & James, we decided to try a different
approach with the menu and to try out a table view/ collection view style
datasource/delegate pattern with the things that the menu items perform
encapsulated as
12 matches
Mail list logo
