Yes, that is, the idea is having a demo page per component and another page demoing all the components
Thanks a lot for your feedback! On Fri, Nov 27, 2015 at 10:54 AM, Sam Giles <[email protected]> wrote: > > On 27 Nov 2015 10:51 am, "Michael Henretty" <[email protected]> wrote: > > > > Very sane and rational plan. > > > > Quick question: when we move to the fxos-components organization, are we > still going to have a demo page that shows all the components in one place? > To me that is one of the coolest and most useful features of > gaia-components, so long as we are dedicated to keeping it up to date. > > At the FT we had a page like this, but it was generated automatically by > querying the github API and using data in the repositories. ( > registry.origami.ft.com) > > I think we should do something similar, it works very well there. > > > > > On Thu, Nov 26, 2015 at 4:39 PM, Maria Oteo <[email protected]> wrote: > >> > >> Thanks Wilson! I'd like to emphasize it is a proposal drafted among > some of the Web Components team members and that any feedback is, as usual, > more than welcome. > >> > >> Thanks a lot! > >> > >> On Thu, Nov 26, 2015 at 3:26 PM, Wilson Page <[email protected]> wrote: > >>> > >>> Maria has written up a formal plan [1] for moving Web Components > forward post v2.5. > >>> > >>> [1] > https://docs.google.com/document/d/1BmGLrm1tVsgv2S8mt-nTkNUN0kj8PqXq_7Wt-PP3lwE/edit > >>> > >>> W I L S O N P A G E > >>> > >>> Front-end Developer > >>> Firefox OS (Gaia) > >>> London Office > >>> > >>> Twitter: @wilsonpage > >>> IRC: wilsonpage > >>> > >>> On Thu, Nov 12, 2015 at 8:59 AM, Chris Mills <[email protected]> > wrote: > >>>> > >>>> Thanks Harly — this will be a great help for getting the material on > MDN! > >>>> > >>>> So yeah, I think from what you are saying it would make sense to put > the web components on their own separate section completely, and then just > link back to the old building blocks section for reference. > >>>> > >>>> Chris Mills > >>>> Senior tech writer || Mozilla > >>>> developer.mozilla.org || MDN > >>>> [email protected] || @chrisdavidmills > >>>> > >>>> > On 12 Nov 2015, at 03:13, Harly Hsu <[email protected]> wrote: > >>>> > > >>>> > Hi Chris, > >>>> > Nice to know that you will be working on the documenting on MDN, > and it is such a coincident that the UX team were just talking about > reaching out to you for MDN assistance. The UX team are currently working > on a document of the current web component similar to what we did during > Building Blocks for 2.x, and will provide the document to you for review > once we are completed. Also, we will provide the necessary assets like > visuals and animations to be put on MDN. > >>>> > > >>>> > For the version and naming, I think building block will still exist > for current 2.x release, so probably make sense to still have the old > building block guideline page on MDN as reference, and put web component at > its own section to avoid misunderstanding. But that just my thoughts on > this. Thanks > >>>> > > >>>> > Harly > >>>> > > >>>> > > >>>> > > >>>> > On Wed, Nov 11, 2015 at 10:05 PM, Chris Mills <[email protected]> > wrote: > >>>> > Hi is indeed great news — I’ve bene waiting for this for a long > time, with an eye to updating the Building Blocks docs on MDN. I currently > have some of the web components documented here: > >>>> > > >>>> > > https://developer.mozilla.org/en-US/Apps/Design/Firefox_OS_building_blocks/2.3 > >>>> > > >>>> > Although that was along time ago and updates will probably be > needed, along wth adding all the others. > >>>> > > >>>> > Questions: > >>>> > > >>>> > * When would be appropriate to start documenting these? I’d imagine > Q1 2016 would be good after our Shadow DOM v1 implementation comes out, so > people can at least start testing them in Nightly or whatever. > >>>> > * Are we sticking with the “building blocks” name, or dropping it? > At the moment, I have the web components listed under the building blocks > section, but I’m wondering whether I need to split them out to their own > section. > >>>> > > >>>> > Chris Mills > >>>> > Senior tech writer || Mozilla > >>>> > developer.mozilla.org || MDN > >>>> > [email protected] || @chrisdavidmills > >>>> > > >>>> > > On 5 Nov 2015, at 11:05, Eric Pang <[email protected]> wrote: > >>>> > > > >>>> > > +1 this sounds amazing Wilson, been waiting for this day! > >>>> > > > >>>> > > Especially the idea of using a live guide. Would be great if we > can have a process in place that ensures it always stays update to date. > >>>> > > IMO The change to the workflow would be worth it to stay aligned. > >>>> > > > >>>> > > Eric > >>>> > > > >>>> > >> On 4 Nov 2015, at 14:56, Wilson Page <[email protected]> wrote: > >>>> > >> > >>>> > >> The following is an initial strategy, along with some insight > behind our thinking. > >>>> > >> > >>>> > >> RENAMING TO FXOS-* > >>>> > >> > >>>> > >> We will be renaming the Github organisation 'gaia-components' -> > 'fxos-components' along with namespaces for each component (eg. > <gaia-header> -> <fxos-header>). > >>>> > >> > >>>> > >> This is to improve transparency and solidify our message. Many > people have heard of FirefoxOS, but not 'Gaia'. Let's tear-down these > confusing barriers to contribution/understanding and align our vocabulary. > >>>> > >> > >>>> > >> PLATFORM STABILITY > >>>> > >> > >>>> > >> We've been using web-components in production across FirefoxOS > for over a year in various places: > >>>> > >> • <gaia-header> (all apps) > >>>> > >> • <gaia-dialog> (spark apps) > >>>> > >> • <gaia-switch> (spark apps) > >>>> > >> • <gaia-toast> (system app) > >>>> > >> • Vertical homescreen > >>>> > >> • New homescreen > >>>> > >> • All Music NGA UI > >>>> > >> • Other stuff I've forgotten :) > >>>> > >> This has given us confidence that what we have in the platform > right now is fast and reliable enough for production. > >>>> > >> > >>>> > >> Shadow DOM V1 (the latest spec all vendors agree on) has shipped > in Chrome and WebKit Nightly. We're currently working on our > implementation. Word from DOM team is, that once complete, they too will be > happy to ship. I have been given a *ballpark* estimate of Q1 2016. > >>>> > >> > >>>> > >> All vendors have not yet agreed on the intricacies of Custom > Elements. They will be meeting in Dec/Jan for a face-to-face to present > proposals and iron our the remaining kinks of a more ES6 centric design. > >>>> > >> > >>>> > >> In Gaia we're using Google's initial specification which we > haven't preffed on by default yet. Third-parties are able to use this API > (and Shadow DOM V0) by using the > "moz-extremely-unstable-and-will-change-webcomponents" permission in their > app manifest. > >>>> > >> > >>>> > >> Imagining optimistically by May 2016 we'll have Shadow DOM V1 > preffed on, third-parties will be able to use our fxos-components in Gecko > by either using the above pref, or a custom-elements polyfill (currently > used by the Google AMP project). > >>>> > >> > >>>> > >> For the time being we have confidence that the current > implementation is sufficient for our internal needs. New Shadow DOM and > Custom Element APIs will land parallel alongside the old, before being > deprecated, giving us ample time to upgrade. We have also abstracted core > APIs behind our gaia-component wrapper, which reduces the number of code > changes required to migrate if/when platform changes. > >>>> > >> > >>>> > >> SEPARATE REPOS > >>>> > >> > >>>> > >> Component will continue to live in their own repos on Github > under the newly named 'fxos-components' organisation. Each repo will > contain source-code, live demo(s), tests and documentation. > >>>> > >> > >>>> > >> PACKAGE MANAGEMENT > >>>> > >> > >>>> > >> After much discussion both on mailing lists and person to > person, we have decided to make the following changes to how we manage > external components in Gaia. > >>>> > >> > >>>> > >> We will move from Bower to NPM3. NPM has become the package > manager of choice for the majority, with NPM3, comes with several nice > front-end features (some borrowed from Bower). > >>>> > >> > >>>> > >> Due to the reasons I outlined in this thread, components will be > installed locally to each app referenced within a `package.json` at the app > root. This adds a small amount of learning/friction to our workflow, but > brings stability to our process (similar to writing tests). > >>>> > >> > >>>> > >> Today external dependencies are checked-in to the Gaia tree. > This avoid complexities with install, version mismatches, build systems and > dependency on third-party servers. The downside is that it adds weight to > the tree and noisy diffs. We'll be sticking to this approach unless more > attractive options come to light. > >>>> > >> > >>>> > >> 'LIVE' STYLE GUIDE > >>>> > >> > >>>> > >> We will build a single style-guide index page that will link to > each component's individual gh-page demo. This will act as an index of the > components that we deem 'production ready' and will be Gaia devs' go-to > catalogue. > >>>> > >> > >>>> > >> The style-guide will link to each demo, which is turn will link > to source Github repo with code, documentation, tests and issues. > Incorporating a 'readiness' checklist within README, following on from the > hard work Fred did, would quickly highlight stability and feature gaps. > >>>> > >> > >>>> > >> I'd also love to have visual/UX specs checked in alongside > source-code as a proof implementation matches specs, but this may require > significant changes to visual/UX workflow. > >>>> > >> > >>>> > >> FOSTERING CONTRIBUTION > >>>> > >> > >>>> > >> Many of these changes are an attempt to lower the barrier to > entry for contribution to FirefoxOS. Having components separated from Gaia > increases discoverability and sends the message that these components can > be used stand-alone. > >>>> > >> > >>>> > >> The scope of 'required understanding for first commit' is shrunk > dramatically when contributors have less code to look at. Using common > tools and patterns of the community, we're doing open-source in a > familiar/approachable way to others. > >>>> > >> > >>>> > >> --- > >>>> > >> > >>>> > >> Let's stop duplicate efforts, save engineering time, give > designers a fast/reliable upgrade channel and overall increase quality. > >>>> > >> > >>>> > >> If you're as excited by this as me, we're looking for help to > make this a success. Ping me if you have questions, suggestions or time to > lend. > >>>> > >> > >>>> > >> Peace :) > >>>> > >> > >>>> > >> W I L S O N P A G E > >>>> > >> > >>>> > >> Front-end Developer > >>>> > >> Firefox OS (Gaia) > >>>> > >> London Office > >>>> > >> > >>>> > >> Twitter: @wilsonpage > >>>> > >> IRC: wilsonpage > >>>> > >> _______________________________________________ > >>>> > >> 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 > >>>> > > >>>> > > >>>> > > >>>> > -- > >>>> > Harly Hsu > >>>> > UX Manager, Firefox OS > >>>> > Mozilla Taiwan > >>>> > Tel:+886.2.8786.1100 ext:220 > >>>> > e-mail:[email protected] > >>>> > >>> > >>> > >>> _______________________________________________ > >>> dev-fxos mailing list > >>> [email protected] > >>> https://lists.mozilla.org/listinfo/dev-fxos > >>> > >> > >> > >> > >> -- > >> Maria Oteo > >> Program Manager, Firefox OS > >> > >> Office: Zaragoza (Spain) > >> Mobile: +34 657881658 > >> Email: [email protected] > >> IRC: mariaoteo > >> > >> _______________________________________________ > >> 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 > > > -- Maria Oteo Program Manager, Firefox OS Office: Zaragoza (Spain) Mobile: +34 657881658 Email: [email protected] IRC: mariaoteo
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
