Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
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
branch: master
Failed to load latest commit information.
_demo Added i18n examples (#1)
button-000 adds more examples, removes prettify layout
button-010 adds more examples, removes prettify layout
button-011 adds more examples, removes prettify layout
button-020 adds more examples, removes prettify layout
button-021 adds more examples, removes prettify layout
button-030 adds more examples, removes prettify layout
button-040 adds more examples, removes prettify layout
button-041 adds more examples, removes prettify layout
button-050 rename directories
button-060 rename directories
button-070 rename directories
button-080 rename directories
button-090 rename directories
button-100 adds more examples, removes prettify layout
button-i18n Added i18n examples (#1)
data rename directories
templates updates remaining layout to use prettify helper instead of grunt plugin
.bowerrc first commit
.editorconfig first commit
.gitignore remove grunt as a dependency of prettify helper. update js-beautify d…
AUTHORS first commit
CHANGELOG first commit
Gruntfile.js Added i18n examples (#1)
LICENSE-MIT remove duplicate license, fix metadata
README.md Fix grunt link syntax
package.json remove grunt as a dependency of prettify helper. update js-beautify d…

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.

Something went wrong with that request. Please try again.