Sooo many buttons... is this really necessary?! In reality this project has little to do with buttons. It's an exercise in separation of concerns regarding structure, style, content and data.
CSS JavaScript
Latest commit ef897dd Sep 9, 2013 @jonschlinkert jonschlinkert Merge pull request #4 from nschonni/patch-1
Fix grunt link syntax
Permalink
Failed to load latest commit information.
_demo Added i18n examples (#1) Sep 6, 2013
button-000 adds more examples, removes prettify layout Aug 30, 2013
button-010 adds more examples, removes prettify layout Aug 30, 2013
button-011 adds more examples, removes prettify layout Aug 30, 2013
button-020 adds more examples, removes prettify layout Aug 30, 2013
button-021 adds more examples, removes prettify layout Aug 30, 2013
button-030 adds more examples, removes prettify layout Aug 30, 2013
button-040 adds more examples, removes prettify layout Aug 30, 2013
button-041 adds more examples, removes prettify layout Aug 30, 2013
button-050 rename directories Aug 18, 2013
button-060 rename directories Aug 18, 2013
button-070 rename directories Aug 18, 2013
button-080 rename directories Aug 18, 2013
button-090 rename directories Aug 18, 2013
button-100 adds more examples, removes prettify layout Aug 30, 2013
button-i18n Added i18n examples (#1) Sep 6, 2013
data rename directories Aug 18, 2013
templates updates remaining layout to use prettify helper instead of grunt plugin Sep 4, 2013
.bowerrc first commit Aug 14, 2013
.editorconfig first commit Aug 14, 2013
.gitignore remove grunt as a dependency of prettify helper. update js-beautify d… Aug 18, 2013
AUTHORS first commit Aug 14, 2013
CHANGELOG first commit Aug 14, 2013
Gruntfile.js Added i18n examples (#1) Sep 6, 2013
LICENSE-MIT remove duplicate license, fix metadata Aug 14, 2013
README.md Fix grunt link syntax Sep 9, 2013
package.json remove grunt as a dependency of prettify helper. update js-beautify d… Aug 18, 2013

README.md

Buttons

How many ways are there to assemble a button?

This project is an exercise in separation of concerns regarding structure, style, content and data. The primary goal is to clearly demonstrate how to construct UI components, from simple to advanced, using only buttons as the example.

Conventions

For the purposes of this project let's agree that:

  • component refers to a user interface abstraction, such as a navbar, modal dialog, or (as with the main attraction of this project) a button.
  • style refers to CSS, including pre-processors (here we use LESS, possibly SASS).
  • structure refers to HTML, including templates (here we use Handlebars templates).
  • content refers to any audial (sound), visual (video or images) or textual content that can be experienced directly by the user on a website or web application.
  • data, as distinguished from "content", refers to any data that is used for configuration and will not be directly experienced by the user. So while "Click Me!" would be considered the "content" of a button, any "modifier classes" of the button stored in JSON or YAML would be considered "data". To be pragmatic, sometimes "data" and "content" are clumped together, but we try to differentiate when it makes sense.

Approach

Separation of concerns

As a rule of thumb, each example in the project demonstrates a different approach to separating concerns between content, structure and style, and in general each example will build upon the last in order to demonstrate:

  • increasing levels of complexity
  • progressively higher levels of abstraction
  • when applicable, different approaches or conventions for accomplishing the same goal, allowing you to decide what is or isn't "idiomatic" as it relates to your own projects

Not all examples explicitly focus on "separation of concerns" as the sole purpose of the example. Some examples show how to leverage JavaScript helpers alongside advanced templates, some offer alternatives for maintaining metadata about a component, while others are simply intended to help non-programmers get started or to give experienced programmers ideas.

Flow

In general, the examples progress from "basic" to "advanced", beginning with button-000, which should be more approachable for designers who have very little to no programming experience, eventually building up to more "complex" examples that might appeal to more experienced programmers.

Also, since the project is expressly intended to be instructive, by necessity some of the examples should not be idiomatic. Furthermore, no judgement is made concerning how much abstraction is necessary, good, bad, idiomatic or otherwise. The driving assumption being that it is equally instructive to see examples of code that is, say, more abstracted than it should be, as it is to see shining examples of perfection. Especially when the user has the larger perspective of seeing multiple approaches for solving the same or similar problems.

In other words, this project will give you examples but the opinions will be left to you.

Contributing

Would you like to add an example? Please do! Just fork the project and do pull request. I only ask that you attempt to number the example appropriately, according to the relative level of complexity of the example.

Also, in lieu of a formal styleguide, take care to maintain the existing coding style. Add unit tests for any new or changed functionality. Lint and test your code using grunt.

Author

Jon Schlinkert

Release History

License

Copyright (c) 2013 Jon Schlinkert, and the authors of examples utilized herein.

Licensed under the MIT license.