Add demo web page to reflect components

first time i visit this repo, feeling that I’m missing some level of engagement. IMO reviewing a web page with demos before diving into cloning this repo would help reflect what it offers.

I can make a PR with demos on gh-pages, as long as it’s not in progress already

[larserikfinholt]

As a non-designer I find it hard to get started - everyting looks so great at https://material.io/guidelines/ but when I try putting a few components together it does not look good.

I understand that the working out a good demo site might take some time. While we wait for the docs site to be created it would be really great if the team could put a designer the task of creating a few simple starter templates.

Thanks for the hard work on this project.

[jonboj]

Each developer may have own expectations. Correct the first impression of the demopage, could be some bleak. Still a demopage serve different purposes.

I have experience with Polymer elements catalog, which served as a sort of spec and reference. To have the demos as spec and reference is especially useful, when the number and complexity of the components grow. So when working headdown fulltime towards a framework the requirements evolves. In my case they ended up to something like:

• One-to-one correspondence between component and demo.

• Try to minimize inter-component references in demos. Of course some features don’t make sense without, like button in dialog. But here the focus is on the dialog.

• The demo reflects current version of a component, when a component is updated the corresponding demo is updated if needed.

• When hitting “View page source” on the hosted demopage, the source code of a demo to a component should be identifiable.

• Short roundtrip from hosted demo to “Hello world” in own environment.

Building the demos into an advanced and glossy demo texture framework, could easy conflict with workflow in the points above. This could be: Complex inter-component relations. “View page source” non transparent, with a lot of wrappings. Demo textures depending on a specific component version, making updates of demo complicated. Hard to “port” demos into own environment.

To me current structure of the mdc-web demos fulfill the workflow better. Maybe the one-to-one correspondence could be tighten.

Somehow clear that https://github.com/material-components/material-components-web/blob/master/demos/button.html

Matches https://github.com/material-components/material-components-web/tree/master/packages/mdc-button

Hosted at the “Button” link http://material-components-web.appspot.com/

As the number of components grows the opportunities for mistakes will grow. e.g. “Select” link to hosted demo of mdc-select is located between “List” and “Menu”, not between “Ripple” and “Snackbar”.