I agree we do need to address the request for easier customize settings to display information to the user on connecting devices. But I have some concern about the conclusion (FE/BE split).
I've checked what we already have (TV settings and Smart feature phone settings) to figure out what connecting devices may use settings. I found Settings customization (if they want reuse existing Settings) could be filed into 5 categories: 1. remove unused panels 2. new panel with new settings items 3. new panel with current settings items 4. current panel with removed settings items 5. current panel with new settings items The FE/BE split might help 4, but can't fulfill the rest of requests. >From my point of view, It might bring more value (for connect device developers) to deal with following items: 1. wrap features under preprocessor flag (to fullfil 1, 4), which B2Gdroid already starting to deal with some of them. 2. Make better documentation and helper classes to easy write a new panel (to fullfil 2, 3. And 5: we may not want to maintain some vendor specific feature settings inside of Gaia) 2.1. or go further, create definition based panel class to auto generate simple settings panel (to fullfil 2, 3), which works like android's PreferenceActivity regards -- Fred On Sat, Nov 14, 2015 at 5:52 AM, Marcus Cavanaugh <[email protected]> wrote: > What kind of timeline are we aiming for? Given that it's a sorted priority > list, what kind of progress would we need to see for 2.6, 2.7, and beyond > to consider this effort a success? > > Nearly half of these key apps are understaffed at best: contacts, > calendar, calculator, and clock have no full-time engineers allocated > afaik. We'll need to actively dedicate people to this project for this to > be successful. (We're hiring, but I wouldn't expect any meaningful > acceleration from hiring efforts until the start of 2.7 development at > best.) > > > On Fri, Nov 13, 2015 at 9:40 AM, Wilfred Mathanaraj <[email protected]> > wrote: > >> Hi all, >> >> Given the Music app splitting we have done in time for 2.5 we want to >> move ahead - I think it makes sense to be executed in a “train model” >> fashion. >> We should start from the top of the list and work through the list. >> >> When I say splitting of the apps, we are looking for the following >> activities to be done: >> 1. FE/BE split >> 2. Split views >> 3. Page transition >> >> Why did I choose the priority below? - for now we have 2 products that we >> work on: smartphone and TV, but moving forward we need to investigate what >> are the products that make sense for us and when we enter the connected >> devices market 3rd party developers need to be able to develop differing >> views for our core apps. >> >> With this is mind we went through some exercise to define a priority for >> the apps to be ported to the updated architecture. >> >> Priority list: >> >> - *Settings* - this is a key app for any product mozilla may be >> planning to release; different apps will have different needs to display >> information to the user in the settings >> - *Camera *- again a key app for a lot of the modern devices >> - *Contacts* - everyone wants to have contacts on their devices - but >> they need different level of information - creating differing views is >> going to key here >> - *Calendar* - as with contacts its critical to have differing views >> but not as high priority as contacts >> - *Gallery* - another core app that every connected device may need >> to have >> - *E-mail* - typing emails on smaller devices will be a problem and >> therefore creating readable email view may be needed for some connected >> deviceds >> - *Calculator *- table stake app >> - *Clock *- table stake app >> - *Browser *- one of core mozilla apps but a table stake app for some >> of the connected devices >> >> >> Some of the engineering teams, who have already worked on this split, >> will be reaching out in smaller teams to discuss best practices and quick >> wins for this activity. >> >> BR >> Wilfred >> >> --- >> FxOS Product Management >> Mozilla Corp., UK >> >> >> >> >> >> _______________________________________________ >> dev-fxos mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-fxos >> >> > > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos > >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
