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
Are you searching the Demo Page?
yep, thanks!
edited the README.md to highlight it for new visitors.
https://github.com/material-components/material-components-web/pull/404
BTW have you considered hosting it on github pages?
Thanks for the PR @jossef! I believe @amsheehan reviewed it this morning.
We're still hashing out exactly what we want to do with our actual docs site, which is why we held off on GH Pages. For now, this appspot URL serves as our temporary demos site.
I understand the hard work being done to put out this project, but the demo page is a joke, seriously. Look at react-toolbox, that is how a demo should be done. You don't even material style the main list.
@eduardoinnorway As per @traviskaufman above, we are still hashing out exactly what we want to do with our actual docs site. Fear not! We have every intention of partnering with our designers to create an enjoyable experience for the community once we get closer to a Beta.
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".
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.
We appreciate all of the feedback on the demo site. Improving this experience is something we've been discussing among ourselves and with the design team. We have opened a discussion dedicated to this concept and would like to continue the conversation there. Thank you!