On Fri, Nov 20, 2015 at 5:38 AM, David Flanagan <[email protected]> wrote:
> I've been thinking a lot about this thread in the context of Ari's talk at > the All Hands meeting yesterday. We're working on an OS that has to run on > smartphones, smart tv's and other form factors tbd. Ari asked us to focus > on portability, and that obviously will be key to our ability to run on > different form factors. > > I had something of an epiphany today: In the future, teams inside and > outside of Mozilla will build devices that run FirefoxOS and will create > products that provide true user value and delight. At this moment we don't > know what those products will be. So for core FirefoxOS developers, our > users are these future product development teams. We need to be building an > OS that is so fast and flexible, so portable and performant that product > developers will feel delight using our platform. > "At this moment we don't know what those products will be". This sentence is extremely important to me. It should have been the first thing I noticed. As far as I know, this is correct. Nobody knows. Am I wrong to say this is true since last December ? But...based on Wilfred initial email, there are some hints. Various form factors. List of most wanted apps. The need for different views for those apps. This is something we can address. Ensuring the FE and the BE are properly splitted, with clear and documented APIs, will be helpful, to make it easier to write various views. My point is that this work should happens first. Once it has happens, you can parallelize work. Some people can work on transforming the front-end to use a components system, while some other may work on making the backend more pleasant, more abstract, more performant and add some new features. Also, once a lot of the business logic has been clearly separated, it would be much easier to have others helping the front-end of any apps. Concerning point #2. The idea is that porting all the front-end in once is hard. It is also hard to get many people working on various panels at the same time. Splitting things into multiple isolated contexts, may let many people working at the same time on a dedicated view, and limit the possible area of conflicts. One can argue that this can be more or less achieved using the right framework and beeing very cautious. This is likely. But once the team starts to be under heavy constraints this is something very hard to keep running. While strong isolations of views, prevent some changes to leak in other views, helping developers and reviewers in their daily job. If everybody rush into web components now, are we sure we will not beeing asked to ship something before everything has been converted ? And if so, do you really want to ends up in the same situation than one of two years ago ? I'm less confident in #3 if we want to do it at Gecko level. So far, and as you mentioned, we lack some platform features to do it properly. Hopefully, once we have #2 it can be emulated partly at the toolkit level (you will be happy there is a web component for that). Basically Web Components will help to write views faster, with globally a more unified experience across the target. But if you want more manpower from people out of your team in order to move very quickly, you will need to have a clearly isolated backends with clear APIs, ensure the work of one, will not conflict nor regress the work of an other, and have a incremental way to migrate. Also, Web Components will help a lot for the UI paradigm. But this part is undefined so far. Even by assuming all apps has been able to migrate to use components everywhere before the next rush - we may be in front of a target device that use completely a completely different metaphor. Yes, components will have clean the (UI) code base, and it sounds easier to replace just a component. But you will again have to fix all the app (UI) at once, working with the limited set of people that knows the app business logic and constraints, trying to avoid regressions abd collisions. Sound scary to me. Not saying #1 and #2 will fix everything. But they are trying to help at least. Vivien. > > With that in mind, I'd like to suggest that we'd be better served by > focusing on web components than by working on NGA. > > Converting our building blocks to web components and then refactoring our > apps to use those components and to be based on higher-level web components > will give us much of the modularity and portability that we're seeking from > NGA, but at the same time, it will also create a high-quality library of > reusable UI components that third party app authors (including those who > are embedding FirefoxOS in new products) can use to more easily create apps. > > David > > 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
