north 0.2.0 → 0.3.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 7cd89a584a3cfabbdeeae988febec93734a485ec
-  data.tar.gz: cffbe411572b260dd8b6b182394054f525ec201e
+  metadata.gz: 94e7556021224e323fd17fec2f7ce638d745fd0d
+  data.tar.gz: 9ebe769a77e4254ccb9aa72abbc705f57f162005
 SHA512:
-  metadata.gz: 99c169d890e2443aaf4be7dc9be3b355d3c16d00a48ce71725d6b507fa0cf47fb71e1897c87d351f5e584ddefa8f288dce287285ca0c2ccf2276c9cc15639a45
-  data.tar.gz: b6524c025d711cb6804018da0710eb7ca8f8c6e45b1dae040d5797a3d0e8f71b93b81a8c57ccf0c9cc71eb05a6bf09389e2f1957d187bde7ef8a6fb75aad44f2
+  metadata.gz: c439b9d0f3490ade26d61e562f9c41d546c343d93875e231ffd359e44ab9992ebf6b3201010b86e3a0c4182a23b1db8a6c989c57d2ca98d701236f38855b1891
+  data.tar.gz: e6ee6f9a60b3fcfa9b91303870ff03ed5242c6ea9152442e69e61e18d7a9a64cc1f65bcb4851c35e651d88c5210e4115264f169c5bd62ce06c5b924813ac5117

data/README.md

@@ -4,9 +4,13 @@ North
 
 North is a set of standards and best practices for developing modern web based properties. Included are standards and best practices for all aspects of a project, from kick off through development. North encourages an agile, content-first, approach to product development and a mobile-first, in-browser, system based approach to design and development.
 
-North is meant to be a living document. Standards and best practices change, and as they do and have been vetted, North will grow and change with them. North will be versioned using [SEMVER](http://semver.org/) to provide a way for you to specify what version of North you are using for your project. Contributions are more than welcome, as long as the [Contribution Guidelines](https://github.com/Snugug/north/blob/master/CONTRIBUTING.md) are followed.
+North is meant to be a living document. Standards and best practices change, and as they do and have been vetted, North will grow and change with them. North is versioned using [SEMVER](http://semver.org/) in order to provide a way to specify what version of North is being followed for any given project.  The easiest way to ensure these standards are tracked as part of your project is to pull in North as a [Bower](http://bower.io/) dependency.
 
-*Currently open to review, [v0.1.1](https://github.com/Snugug/north/releases/tag/v0.1.1) is the first preview version. Once the review period is over, a branch for the current major version will be made.*
+```bash
+bower install north --save-dev
+```
+
+*Currently open to review, [v0.3.0](https://github.com/Snugug/north/releases/tag/v0.3.0) is a preview version of North. Once the review period is over, a branch for the current major version will be made. Contributions are more than welcome, as long as the [Contribution Guidelines](https://github.com/Snugug/north/blob/master/CONTRIBUTING.md) are followed.*
 
 # Table of Contents
 
@@ -17,6 +21,7 @@ North is meant to be a living document. Standards and best practices change, and
     * [Designer](#designer)
     * [Developer](#developer)
     * [Quality Assurance](#quality-assurance)
+    * [Leads](#leads)
   * [Agile Scrum](#agile-scrum)
 	  * [User Stories](#user-stories)
 	    * [Benefit Statement](#benefit-statement)
@@ -84,6 +89,7 @@ North is meant to be a living document. Standards and best practices change, and
     * [Recommended Optimizations](#recommended-optimizations)
     * [Experimental Optimizations](#experimental-optimizations)
 6. [Website Building Blocks](#website-building-blocks)
+  * [General Coding Syntax](#general-coding-syntax)
   * [Markup](#markup)
     * [HTML Semantics](#html-semantics)
     * [Accessibility](#]accessibility)
@@ -103,7 +109,10 @@ North is meant to be a living document. Standards and best practices change, and
   * [Interaction](#interaction)
     * [Style and Syntax](#style-and-syntax)
     * [Libraries, Plugins, and Frameworks](#libraries-plugins-and-frameworks)
-7. [License and Acknowledgements](#license-and-acknowledgements)
+7. [Tools and Resources](#tools-and-resources)
+	* [Intake Center](#intake-center)
+	* [Generator North](#generator-north)
+8. [License and Acknowledgements](#license-and-acknowledgements)
 
 # Development Process
 
@@ -121,7 +130,7 @@ In any given project, there are a variety of roles that each play a part in the
 
 ### Product Owner
 
-Either the individual who directly owns the product or company the product is being developed for, or a designated representative for the product or company who has been given direct permission to make decisions for the product being developed. This individual needs to be able to make decisions on their own without consulting others and acts as a fully involved individual in the lifecycle of a project. They are responsible for prioritizing the [backlog](#backlog) of, determining [requirements](#requirements) for, and assisting in writing [user stories](#user-stories). There should only be a single product owner per project.
+Either the individual who directly owns the product or company the product is being developed for, or a designated representative for the product or company who has been given direct permission to make decisions for the product being developed. This individual needs to be able to make decisions on their own without consulting others, acts as a fully involved individual in the lifecycle of a project, and must understand and be able to fully articulate the [vision](#project-vision) of the project. They are responsible for prioritizing the [backlog](#backlog) of, determining [requirements](#requirements) for, and assisting in writing [user stories](#user-stories). There should only be a single product owner per project.
 
 ### Project Manager
 
@@ -139,6 +148,10 @@ Much like designers, there are two types of developers, front end developers and
 
 Individuals working on quality assurance (QA) ensure that new code created during a [sprint](#iterations) matches the [requirements](#requirements) of the [user story](#user-stories) and does not break the functionality already in place from previous sprints. QA needs to understand how functionality may differ across platforms (on the web, [browsers and devices](#progresive-enhancement)) and work with developers when this is unclear. No code should be [released](#tags-and-releases) until QA has given sign off.
 
+### Leads
+
+It is often useful, although not necessary, for an individual Designer, Developer, or QA member be designated as a lead for each discipline. This can take the form of a Lead Designer, Lead Developer, and lead QA, or it can be more specific, taking the form of Lead Visual Designer, Lead UX Designer, Lead Front End Developer, Lead Back End Developer, Lead Functional QA, Lead Cross Browser QA, etc…. No matter how it is divided, leads all share the same extra responsibilities; leads are responsible for and have final say over direction (and if appropriate, architecture) for their discipline, communicating that direction to and mentoring the other individuals in their discipline, and communicating and explaining that direction to the product owner and project manager.
+
 ## Agile Scrum
 
 ### User Stories
@@ -159,6 +172,12 @@ The functional requirements of a user story are based on the desired user experi
 
 The size of a story is how much effort it will take to complete based on a relative scale of other similar features built, whereas value is a relative determination of how aligned with business needs a given feature is. Both size and value should be a [Fibonacci number](http://en.wikipedia.org/wiki/Fibonacci_sequence).
 
+> Out of the first six numbers of the Fibonacci sequence, four are prime. This limits the possibilities to break down a task equally into smaller tasks to have multiple people work on it in parallel. Doing so could lead to the misconception that the speed of a task could scale proportionally with the [number of people working on it](#brookss-law). The 2^n series is most vulnerable to such a problem. The Fibonacci sequence in fact forces one to re-estimate the smaller tasks one by one.
+>
+> [KillerInsect, StackOverflow](http://stackoverflow.com/questions/9362286/why-is-the-fibonacci-series-used-in-agile-planning-poker/9377005#9377005)
+
+This applies not only to tasks, but to value as well. One very popular technique for estimating sizes (and can likewise be applied to value) is [planning poker](http://en.wikipedia.org/wiki/Planning_poker). Planning poker is a consensus-based technique where team members secretly estimate what they believe size or value should be and all estimates are revealed at once. This is done to avoid the cognitive basis of [anchoring](http://en.wikipedia.org/wiki/Anchoring) where the first number spoken aloud sets the precedent for subsequent estimates. After the reveal, the team discusses their reasoning for their estimates, eventually coming to a consensus on the estimate. If the team cannot come to a consensus on estimates, the largest estimate is usually used. When planning, each team member's estimate holds equal weight, regardless of if they are a [lead](#leads).
+
 For sizes, any size above 21 is usually too much to work on in a single iteration and the work should be split into smaller pieces and an epic, or overarching story, should be created. Size is not just based on development difficulty; it includes difficulty for all [team members](#roles-and-responsibilities) that would work on a feature for an iteration, including design and QA. Size should also account for risk, which could increase size for features that otherwise require little actual work to do. The size of a story should be agreed upon by consensus by all team members working on a feature. Sizing should happen throughout an [iteration](#iterations).
 
 Value should be determined for each aspect that provides value, generally not to exceed 13 per aspect. A determination of how closely each [benefit statement](#benefit-statement) aligns with the [vision statement](#vision-statement) should always be included, with additional aspects such as importance in [information architecture](#information-architecture) or metrics for the feature or content type.
@@ -237,7 +256,7 @@ User personas are a tool to distill different types of people who may interact w
 User persona research should begin with a hypothesis of what the various final user types will be and what those user types wants and needs are. These hypotheses should be based on analytics of the current site (if available) and demographic information of target audience. Analytics will provide insight into what is important to users, but not why. Similarly, demographic information will provide insight into who to start with, but not necessarily describe everyone who may use a product.
 
 Once rough sketches of starting user types are determined, it is time for interviews. Ask users questions such as:
-* What do you find most valuable about the existing product and similar, including competitors', products?
+* What do you find most valuable about the existing product and similar, including competitors' products?
 * Is anything of value is missing from the existing product and the similar products?
 * How do you most often access the product?
 * What are the pain points?
@@ -264,7 +283,7 @@ When building content inventories, it's often convenient to include limits for e
 * `bar$` - Ends with (in this case, bar)
 * `.jpg|png` - Multiple options (in this case either jpg or png file extensions)
 
-![Content Inventory](http://snugug.github.io/images/content-inventory.png)
+![Content Inventory](http://snugug.github.io/images/content-inventory.jpg)
 
 ## Content Audit
 
@@ -496,7 +515,7 @@ While building out an IA, the product's [content mode](#content-mode) may need t
 
 # Visual Design
 
-[![The Treachery of Images, René Magritte](http://snugug.github.io/images/The_Treachery_Of_Images.jpeg)](http://en.wikipedia.org/wiki/The_Treachery_Of_Images)
+[![The Treachery of Images, René Magritte](http://snugug.github.io/images/The_Treachery_Of_Images.jpg)](http://en.wikipedia.org/wiki/The_Treachery_Of_Images)
 
 As the web comes into its own as a medium and the [rituals of print design](http://snugug.github.io/designing-the-modern-web/#/ritual) are cast off, websites can no longer be designed in the same tools built for print design. Websites have interaction, states change, items come in and out. The [differences in browsers](#progressive-enhancement) force designs to change based on capabilities available. Even something as simple as screen size is not static. As [Brad Frost put it](https://twitter.com/brad_frost/status/195241868383092736), "You can't articulate fluidity on paper." The reality of the web has always been that a single, static bitmap representation of a page isn't what a final site will be, it's just taken the push of [responsive web design](#responsive-web-design) to bring the web into its own as a medium. In order to accommodate for the fluidity and flexibility of the medium of the web, new tools and techniques are needed to create a site's look and feel.
 
@@ -556,27 +575,37 @@ For generations, humans have used conversation to pass down stories and learn ab
 
 ## Grids
 
-Grids should be utilized to keep order on a page. As described in [Responsive Grids](http://snugug.github.io/responsive-grids/#/), grids enforce proportion and constraint on a design and provide order and structure to information. The best grid is specific to the content and design of a site, as it is an extension of both. In print, grids are easy as everything from the display size to the reading mode is fixed, but this is not true on the web, so a one-size-fits-all approach to grids doesn't work. While the [960 Grid](http://960.gs/) may have been a useful stopgap as the web was treated like print, but as it evolves, so must the grids used. The grids from Twitter Bootstrap or Zurb Foundation are no better; they are a single (if flexible) grid meant to cover everything in a generic way. Instead of using another designer's grid, create grids for the design and the content of the current site. The preferred grid framework to work in is [Singularity](https://github.com/team-sass/singularity) as it provides the flexibility needed to create complex and responsive grids that are truly custom to design and content.
+Grids should be utilized to keep order on a page. As described in [Responsive Grids](http://snugug.github.io/responsive-grids/#/), grids enforce proportion and constraint on a design and provide order and structure to information. Ideally a grid is specific to the content and design of a site, as it should be an extension of both.
+
+> Grids do not exist in a vacuum. They exist in relation to the content. We never start with a grid. We start with an idea which is then translated into a form, a structure.
+> *Linda van Deursen*
+
+Grid Systems (Twitter Bootstrap, Zurb Foundation) flow content in a generic way that may be usable, but are not recommended as they neither an extension of a site's content nor its design.
+
+Instead of using generic grids, [content-out layouts](http://alistapart.com/article/content-out-layout) are recommended. Grid Frameworks ([Singularity](https://github.com/team-sass/singularity), [Susy](https://github.com/ericam/susy), [Gridset App](https://gridsetapp.com/) (paid service)) are excellent as they provide the flexibility needed to create complex and robust content-out responsive grids.
+
+Grids are primarily used in [layouts](#layouts) in CSS.
 
-Grids are primarily [layouts](#layouts) in CSS.
+The following grid examples are based on the Singularity Grid Framework.
 
 ### Parts of a Grid
 
 There are three parts that make up a grid; they are the columns, the gutters, and the gutter style:
 
-* **Columns** - In Singularity defined by the `$grids` variable, columns represent the relationship between each major piece of a grid. When attaching items to a grid, they are attached to whole pieces of a column or multiple columns (which would then include gutters).
-* **Gutters** - In Singularity defined by the `$gutters` variable, gutters are the whitespace between each column. Content is never snapped to a gutter, and each gutter is the same width.
-* **Gutter Styles** - In Singularity defined by the `$gutter-styles` variable, gutters can either be placed opposite each column with the last column not receiving a gutter (`|C|G|C|G|C|`) or split in half with each column getting one half of a gutter's width on either side, including the first and last columns (`|g|C|g|C|g|C|g`). Gutters can also either be fluid or fixed in width.
+* **Columns** - An individual section of a grid. Columns that are based on relationships between each other work best for content-out responsive grids and being able to create these types of columns are one of the hallmarks of a Grid Framework. Columns that are all equally sized are generic and what are usually found in Grid Systems.
+* **Grids** - Grids are a collection of columns. When attaching items to a grid, they are either attached to a whole column or multiple columns. If attached to multiple columns, the total span includes all of the gutters spanned.
+* **Gutters** - Gutters are the whitespace between each column. Content is never snapped to a gutter, and each gutter is the same width. Gutters can fluid in relation to column width or fixed (either a fixed value or a fixed percentage).
+* **Gutter Styles** - Gutters can either be placed opposite each column with the last column not receiving a gutter (`|C|G|C|G|C|`) or split in half with each column getting one half of a gutter's width on either side, including the first and last columns (`|g|C|g|C|g|C|g`).
 
 ### Symmetric Grids
 
-The most common type of grid is a symmetric grid. A symmetric grid is defined as a grid where each column is the same size. The most common type of symmetric grid is the 12 column symmetric grid. Symmetric grids have a tendency to constrain creativity in negative ways mostly due to the fact that for the most part designs built on symmetric grids have a tendency to look the same. There is an interesting mix of freedom and constraint in symmetric grids that, when used to lay out content on anything other than a column-by-column basis (4 columns, 4 identically sized pieces of content), provides enough flexibility to allow designs to meander.
+The most common type of grid is a symmetric grid, and usually what is defined by Grid Systems. A symmetric grid is defined as a grid where each column is the same size. The most common type of symmetric grid is the 12 column symmetric grid. Symmetric grids have a tendency to constrain creativity in negative ways mostly due to the fact that design then starts with the grid instead of with the content. There is also an interesting mix of freedom and constraint in symmetric grids that, when used to lay out content on anything other than a column-by-column basis (4 columns, 4 identically sized pieces of content), provides enough flexibility to allow designs to meander.
 
 ![Symmetric Grid](http://snugug.github.io/images/symmetric-grid-bootstrap.png)
 
 ### Asymmetric Grids
 
-Unlike the common symmetric grid, the uncommon asymmetric grid provides for interesting design constraints based on content and design by having columns that are different sizes from each other. This allows for grids and design to align without the providing wiggle room to break a design. There are four types of asymmetric grids, custom, compound, ratio based, and spiral based. [Singularity Extras](https://github.com/team-sass/singularity-extras) provides an easy to create these different kinds of asymmetric grids for use in Singularity.
+Unlike the common symmetric grid, the uncommon asymmetric grid provides for interesting design constraints allowing for content-out layouts and design by having columns that are different sizes from each other. This allows for grids and design to align without the providing wiggle room to break a design. There are four types of asymmetric grids: custom, compound, ratio based, and spiral based. [Singularity Extras](https://github.com/team-sass/singularity-extras) provides an easy way to create these different kinds of asymmetric grids for use in Singularity.
 
 #### Custom Grids
 
@@ -586,7 +615,7 @@ Custom asymmetric grids are asymmetric grids where column sizes are determined b
 
 #### Compound Grids
 
-Compound grids are asymmetric grids that are created by overlaying two or more symmetric girds on top of each other to create a new asymmetric grid. The example shows a 3-4 compound grid, where a 3 column symmetric and a 4 column symmetric grid are overlaid to create a 6 column asymmetric grid. Why not simply use a 12 column grid? With this compound grid, spans are constrained to multiples of 1/4 and 1/3, meaning that a span of 5/12 or 7/12 could not happen. The orange is the final grid, with the red showing the 3 column grid and blue showing the 4 column grid.
+Compound grids are asymmetric grids that are created by overlaying two or more symmetric girds on top of each other to create a new asymmetric grid. The example shows a 3-4 compound grid, where a 3 column symmetric and a 4 column symmetric grid are overlaid to create a 6 column asymmetric grid. Why not simply use a 12 column grid? With this compound grid, spans are constrained to multiples of 1/4 and 1/3, meaning that a span of 5/12 or 7/12 could not happen. The top section shows the final compound grid, with the middle section showing the grid split into thirds and bottom section showing the grid split into quarters.
 
 ![Compound Grid](http://snugug.github.io/images/asymmetric-grid-compound.png)
 
@@ -688,7 +717,7 @@ When designing in browser, the process of design changes from a purely visual on
 
 ### Mobile First
 
-Mobile first is a term used to describe designing and building sites from a minimal base first. At its core, mobile first is about [progressive enhancement](#progressive-enhancement), but on a site-wide, design-up. But it's more than just a mobile device (in fact, it's [not about devices at all](#device-detection)), mobile first is really an attempt to describe design and development in a content-centric way. As [Jeffery Zeldman puts it](http://www.ripariandata.com/mail-room-blog/blog/an-event-apart-sf-recap-the-message-is-the-medium):
+Mobile first is a term used to describe designing and building sites from a minimal base first. At its core, mobile first is about [progressive enhancement](#progressive-enhancement), but on a site-wide, design-up. But it's more than just a mobile device (in fact, it's [not about devices at all](#device-detection)), mobile first is really an attempt to describe design and development in a content-centric way. As [Jeffery Zeldman puts it](http://skimbox.co/blog/an-event-apart-sf-recap-the-message-is-the-medium):
 
 > It's not about mobile first (or just small screen first) - it's about content first. But it happens that thinking about what works for mobile does work for other things as well.
 
@@ -702,7 +731,7 @@ Using mobile as a focusing lens will also help to inform a site's [information a
 
 ### Pair Design
 
-One proven method of transitioning design teams from designing in bitmap tools to designing in browser is to pair designers with front end developers in a method similar to [pair programming](http://en.wikipedia.org/wiki/Pair_programming). With pair design, the front end developer acts as hands and the designer acts as the eyes. The two then work together to create a design. As this is happening, the developer should encourage the designer write code and the designer should encourage the developer to give input into the design and suggest technical solutions to design challenges or decisions.
+One proven method of transitioning design teams from designing in bitmap tools to designing in browser is to pair designers with front end developers in a method similar to [pair programming](http://en.wikipedia.org/wiki/Pair_programming). With pair design, the front end developer acts as hands and the designer acts as the eyes. The two then work together to create a design. As this is happening, the developer should encourage the designer to write code and the designer should encourage the developer to give input into the design and suggest technical solutions to design challenges or decisions.
 
 During this process, it is also helpful for front end developers to create reusable patterns in CSS (especially around creating functions and mixins in [Sass](#sass-and-compass)) and explain to and work with the designer to enhance these patterns, allowing the designer to get comfortable writing pattern-based code. This also lays the foundation for rapid iteration of a design idea.
 
@@ -940,6 +969,18 @@ There are a number of optimization techniques that can be employed in order to e
 
 No matter what back end technology is used to generate a website, when it gets rendered to a page it always becomes HTML, CSS, and JavaScript when displayed in browser. As such, a common set of best practices can be employed to ensure that what the user gets is as good as it can be, regardless of the device or method they choose to browse the site with. The methodology described below presents a content focused, component based, semantic, and accessible approach for building web sites. Designing this way is challenging, and requires a different approach than traditional desktop-sized Photoshop documents. That will be covered in other sections of this document, but one of the best ways to design this way is in the browser using [Style Prototypes](https://github.com/Team-Sass/generator-style-prototype).
 
+## General Coding Syntax
+
+[Mark Otto's Code Guide](http://mdo.github.io/code-guide/) is a set of best practices for writing coding syntax. They should be used with the following adendums:
+
+* Use North's [styling guidelines](#styling) for specific class naming conventions. This includes North's conventions on component/layout naming as well as using data attributes instead of `.js-*` classes.
+* If there is a conflict between the Coding Guide's standards and North's standards, defer to North's standards.
+* Generally, there should not be multiple CSS files unless it will absolutely benefit [performance](#performance). Use North's [partial structure](#partial-structure) standards instead.
+* In addition to the nesting rules present, the [inception rule](http://thesassway.com/beginner/the-inception-rule) for nesting should be followed
+* Prefixed CSS properties should be handled by mixins, not written by hand, and based on browser support. Compass 1.0's [Cross-Browser Support](http://beta.compass-style.org/reference/compass/support/) in conjunction with its [CSS3 Mixins](http://beta.compass-style.org/reference/compass/css3/) or [Autoprefixer](https://github.com/ai/autoprefixer) should be utilized to accomplish this (choose one or the other at the beginning of a project).
+* Mixins that affect multiple properties (such as grid mixins), should come before any individual properties to ensure declared styles are not overridden.
+* Extends should be declared first before any other properties are declared, including mixins.
+
 ## Markup
 
 The core of every website is the underlying markup that, through [styling](#styling) and [interaction](#interaction), gets transformed into a web experience. This underlying code is the heart and soul of every site and should be treated as such. By properly utilizing HTML5 semantic markup and ensuring content is accessible and properly marked up with Resource Description Framework in Attributes (RDFa), websites will be able to achieve better search engine optimization (SEO) and ensure that the content will be highly available no matter the accessing system and last long in to the future.
@@ -974,19 +1015,19 @@ Due to lack of standards around it, each browser manufacturer creates their own
 
 ### Components
 
-Components are the primary building block of any interface. They are the bits and bobs that combine to form a cohesive user interface; from menus to messages, pagers to pictures, and everything else in between. Components should be written to be able to be dropped in to any position in a layout. The way to accomplish this is to build components using [**eq.js**](https://github.com/snugug/eq.js). This will allow a component and its elements to respond appropriately regardless of where they land in a given document flow. Components should be simple layouts to position elements inside of themselves either through extends or by constructing a component with elements placed inside an internal layout (decide before starting a project and carry that decision through the lifespan of the project) if the layout is not component specific. They may choose to control their overall sizing and one-off sizing and positioning, but those choices should be relative the container they are dropped in to and not layout or position specific.
+Components are the primary building block of any interface. They are the bits and bobs that combine to form a cohesive user interface; from menus to messages, pagers to pictures, and everything else in between. If a component can be used in multiple positions in a layout (such as a message or a promoted item), [**eq.js**](https://github.com/snugug/eq.js) should be utilized to adapt their layouts (where appropriate) instead of media queries. This will allow a component and its elements to respond appropriately regardless of where they land in a given document flow. If a component will only be used in a single position (such as global headers or footers), media queries can be used. Basically, use what is most appropriate.
 
 #### Base Component
 
-Each project should contain a `base` component which contains base styling for raw tags (`h2`, `blockquote`, `p`, etc…). The `base` component's elements should be named after the tag they style, so basic styling for `h2` would provide both an extendable and full class `.base--h2`. To apply these styles, create a `styled` aspect, providing a `.base--STYLED` class. This aspect should have raw elements styled without classes, allowing it to be dropped into any section of a site and provide basic styling. Additional aspects can be created to create different base stylings.
+Each project should contain a `base` component which contains base styling for raw tags (`h2`, `blockquote`, `p`, etc…). The `base` component's elements should be named after the tag they style, so basic styling for `h2` would provide both an extendable and full class `.base--h2`. To apply these styles, create a `styled` aspect, providing a `.base--STYLED` class. This aspect should have raw elements styled without classes, allowing it to be dropped into any section of a site and provide basic styling. Additional aspects can be created to create different base stylings, such as `form` for base form styling.
 
 ### Layouts
 
-Layouts are the structure of an interface. Providing structure to pages and components, layouts are responsible for sizing and positioning of their elements. There are two kinds of layouts, simple and complex. The distinguishing factor between simple and complex layouts is that complex layouts adapt and change their sizing and positioning based on media queries whereas simple layouts do not. Complex layouts are generally used for laying out pages and regions within pages, with simple layouts being used for laying out sub-sections inside complex layouts and providing common layouts for components. While simple layouts may be used within components or even within other simple or complex layouts, complex layouts should never be used within one another.
+Layouts are the structure of an interface. Providing structure to pages and components, layouts are responsible for sizing and positioning of their elements. Layouts are generally used for laying out pages and regions within pages. Layouts that include viewport based media queries (`width`, `height`, etc…) should never be nested inside each other
 
 ### Aspects
 
-Aspects are a specific implementation of a component or layout. Components and layouts always should have an aspect when used to determine what kind of implementation is being worked with. Aspects can be used as a way to pivot styling of elements if need be or to control implementation-specific styling, such as changing colors in a message component or determining exact sizing of a body element of a layout. It is preferable to use aspects as pivot points rather than to create unique classes for each element as it allows for the reuse of identical elements regardless of the aspect of a component or layout they are used in.
+Aspects are a specific implementation of a component or layout. Aspects can be used as a way to pivot styling of elements if need be or to control implementation-specific styling, such as changing colors in a message component or determining exact sizing of a body element of a layout. It is preferable to use aspects as pivot points rather than to create unique classes for each element as it allows for the reuse of identical elements regardless of the aspect of a component or layout they are used in. Elements should only pivot off of aspects, not off of an aspect-less component or layout.
 
 ### Elements
 
@@ -994,24 +1035,24 @@ Elements are the individual pieces that make up a component or layout, each bein
 
 ### States
 
-States provide a way to alter how a component, layout, element, or aspect behaves. Common states include `active`, `open`, and `closed`. Because states live in the in-between world of JavaScript and CSS, often changing with interactions from the user, states are controlled by data attributes and get attached to the components, layouts, elements, or aspects they are modifying. This provides easy to maintain states on a per-object basis without needing per-object states.
+States provide a way to alter how a component, layout, element, or aspect behaves. Common states include `active`, `open`, and `closed`. Because states live in the in-between world of JavaScript and CSS, often changing with interactions from the user, states are controlled by data attributes (`[data-state="active"]`) and get attached to the components, layouts, elements, or aspects they are modifying. This provides easy to maintain states on a per-object basis without needing per-object states.
 
 ### CSS Naming Conventions
 
-Components and layouts form prefixes the prefixes for aspects and elements, separated by double dash (`--`). Simple layouts start with an underscore (`_`) and complex layouts start with two underscores (`__`) to distinguish them from components, and aspects are written in all caps (`CAPS`) to distinguish them from elements, written in all lowercase (`lowercase`). States are applied to the state data attribute (`data-state`) and queried using attribute selectors as they have the strong tendency to either be manipulated by JavaScript or be used as a hook for JavaScript. If an object has multiple states, each state should be space (`' '`) separated in the `data-state` data attribute. A sample document written up using this naming convention could look like the following:
+Components and layouts form prefixes for aspects and elements, separated by double dash (`--`). Layouts start with an underscore (`_`) to distinguish them from components. Aspects are written in all caps (`CAPS`) to distinguish them from elements, written in all lowercase (`lowercase`). States are applied to the state data attribute (`data-state`) and queried using attribute selectors as they have the strong tendency to either be manipulated by JavaScript or be used as a hook for JavaScript. If an object has multiple states, each state should be space (`' '`) separated in the `data-state` data attribute. A sample document written up using this naming convention could look like the following:
 
 ```html
 <!-- Article layout with Big Media aspect -->
-<div class="__article--BIG-MEDIA">
+<div class="_article--BIG-MEDIA">
   <!-- Main element of Article layout -->
-  <article class="__article--main">
+  <article class="_article--main">
     <!-- Heading element of Article layout -->
-    <div class="__article--heading">
+    <div class="_article--heading">
       <!-- PRIMARY Heading aspect of Typography component -->
       <h1 class="typography--PRIMARY-HEADING">Article Title</h1>
     </div>
     <!-- Media element of Article layout -->
-    <figure class="__article--media">
+    <figure class="_article--media">
       <!-- Video components, Full HD aspect -->
       <div class="video--FULL-HD">
         <!-- Video element of Video component -->
@@ -1019,13 +1060,13 @@ Components and layouts form prefixes the prefixes for aspects and elements, sepa
       </div>
     </figure>
     <!-- Body element of Article layout, Area aspect of Typography component  -->
-    <div class="__article--body typography--AREA">
+    <div class="_article--body typography--AREA">
       <h2>Some user entered copy goes here</h2>
       <p>Yay Copy!</p>
     </div>
   </article>
   <!-- Secondary element of Article layout  -->
-  <aside class="__article--secondary">
+  <aside class="_article--secondary">
     <!-- Popular aspect of Related component -->
     <div class="related--POPULAR">
       <!-- Heading element of Related component -->
@@ -1054,11 +1095,11 @@ When writing CSS, use [Sass](http://sass-lang.com/) with the [Compass](http://co
 * [Modular Scale](https://github.com/Team-Sass/modular-scale) - Numeric relationships, especially for typography
 * [Import Once](https://github.com/chriseppstein/compass/blob/master/import-once/README.md) - Changes the way `@import` works so that imports only happen once. Useful for deep nested or shared dependencies
 
-The following should be using the standard [Compass configuration](http://compass-style.org/help/tutorials/configuration-reference/) for all projects:
+The following should be using the standard [Compass configuration](http://compass-style.org/help/tutorials/configuration-reference/) for all projects (`http_path` is likely to change on a project-to-project basis):
 
 ```ruby
 # Set this to the root of your project when deployed:
-http_path = "/"
+http_path = "./"
 css_dir = "css"
 sass_dir = "sass"
 images_dir = "images"
@@ -1294,9 +1335,22 @@ When building site, very often a point will come when a decision must be made as
 * Is the script performant? Does it have performance benchmarks? If not, can it be benchmarked? If a script, regardless of weight, slows down a site significantly, its use should be reconsidered.
 * Given browser support, is a heavy JavaScript library like jQuery or Dojo needed? Can paired down versions of those libraries be used? Does usage require the full support behind one of these libraries, or can a small DOM/AJAX library such as [Chibi](https://github.com/kylebarrow/chibi) be effective?
 
+# Tools and Resources
+
+There have been a handful of tools that have been created in order to assist in working with the North standards, making building awesome things easier.
+
+## Intake Center
+
+[Intake.Center](https://github.com/Snugug/intake) is a webapp developed to assist with [role definitions](https://github.com/Snugug/north#roles-and-responsibilities) and [content strategy](https://github.com/Snugug/north#content-strategy). It includes tools for developing and recording [project vision](#project-vision), [user personas](#user-personas), and [content models](#content-modeling) based on [Schema.org](http://schema.org/) schemas. [Content inventory](#content-inventory) and [audit](#content-audit) should be performed before modeling takes place.
+
+## Generator North
+
+[Generator North](https://github.com/Snugug/generator-north) is a [Yeoman](http://yeoman.io/) generator designed to quickly spin up new North based projects, including integrations with [Sass and Compass](#sass-and-compass), [Bower](http://bower.io/), and [JSHint](http://www.jshint.com/), with an option to include [BrowserSync](http://browsersync.io/) server and live reloading. Either [Grunt](http://gruntjs.com/) or [Gulp](http://gulpjs.com/) can be chosen as a task runner. Generator North also provides an easy way scaffold out new components and layouts, reducing the overhead needed to create each new component or layout.
+
+
 # License and Acknowledgements
 
-Copyright © Sam Richard (Snugug) and made available under the [MIT License (MIT)](https://github.com/Snugug/north/blob/master/LICENSE).
+Copyright © [Sam Richard](https://github.com/snugug) ([Snugug](http://twitter.com/snugug)) and made available under the [MIT License (MIT)](https://github.com/Snugug/north/blob/master/LICENSE).
 
 One of the primary goals of North was to create a set of development standards that not only were designed for a modern workflow and process in mind, but also that came from the learnings and understandings of multiple industry leading experts, not a single person. These standards reach across multiple verticals, so having experts from each vertical is critical to the success of these standards. The following individuals assisted in brainstorming and developing North or otherwise directly influenced North and have not otherwise been acknowledged in the document itself, and for that I am grateful:
 

data/lib/north.rb

@@ -6,6 +6,6 @@ stylesheets_dir = File.join(base_directory, 'north')
 Compass::Frameworks.register("north", :path => base_directory, :stylesheets_directory => stylesheets_dir)
 
 module North
-  VERSION = "0.2.0"
-  DATE = "2014-02-17"
+  VERSION = "0.3.0"
+  DATE = "2014-04-27"
 end

data/north/_north.scss

@@ -1,3 +1,4 @@
+@import "north/helpers";
 @import "north/components";
 @import "north/layouts";
 @import "north/aspects";

data/north/north/_aspects.scss

@@ -9,8 +9,13 @@
 // Mixins
 //////////////////////////////
 @mixin aspect($name) {
-  &--#{aspect($name)} {
+  @include aspects($name) {
     @content;
   }
 }
 
+@mixin aspects($names...) {
+  @include north--core('aspect', $names) {
+    @content;
+  }
+}

data/north/north/_components.scss

@@ -8,9 +8,14 @@
 //////////////////////////////
 // Mixins
 //////////////////////////////
-@mixin component($name) {
-  @at-root .#{component($name)} {
+@mixin components($name) {
+  @include aspects($name) {
     @content;
   }
 }
 
+@mixin components($names...) {
+  @include north--core('component', $names) {
+    @content;
+  }
+}

data/north/north/_elements.scss

@@ -9,8 +9,13 @@
 // Mixins
 //////////////////////////////
 @mixin element($name) {
-  &--#{n-element($name)} {
+  @include aspects($name) {
     @content;
   }
 }
 
+@mixin elements($names...) {
+  @include north--core('element', $names) {
+    @content;
+  }
+}

data/north/north/_helpers.scss

@@ -0,0 +1,23 @@
+@mixin north--core($type, $names) {
+  @if (length($names) == 0) {
+    @if str-index($type, 'a') == 1 or str-index($type, 'e') == 1 {
+      @warn 'You need to include an #{$type}!';
+    }
+    @else {
+      @warn 'You need to include a #{$type}!';
+    }
+  }
+  @else {
+    $extend: unique-id();
+    @at-root {
+      %#{$extend} {
+        @content;
+      }
+    }
+    @each $name in $names {
+      &--#{call($type, $name)} {
+        @extend %#{$extend};
+      }
+    }
+  }
+}

data/north/north/_layouts--OLD.scss

@@ -0,0 +1,67 @@
+//////////////////////////////
+// Variables
+//////////////////////////////
+$north-layout-type: 'simple' !default;
+
+//////////////////////////////
+// Functions
+//////////////////////////////
+@function simple-layout($name) {
+  @return '_#{to-lower-case($name)}';
+}
+
+@function complex-layout($name) {
+  @return '__#{to-lower-case($name)}';
+}
+
+@function layout($name, $type: $north-layout-type) {
+  $type: to-lower-case($type);
+  $prefix: null;
+
+  @if $type == 'simple' {
+    @return simple-layout($name);
+  }
+  @else if $type == 'complex' {
+    @return complex-layout($name);
+  }
+  @else {
+    @warn '#{$type} is not a valid North layout type. Please use either `simple` or `complex`';
+    @return $name;
+  }
+}
+
+//////////////////////////////
+// Layout Mixins
+//////////////////////////////
+@mixin simple-layout($name) {
+  @at-root .#{simple-layout($name)} {
+    @content;
+  }
+}
+
+@mixin complex-layout($name) {
+  @at-root .#{complex-layout($name)} {
+    @content;
+  }
+}
+
+@mixin layout($name, $type: $north-layout-type) {
+  $type: to-lower-case($type);
+  $prefix: null;
+
+  @if $type == 'simple' {
+    @include simple-layout($name) {
+      @content;
+    }
+  }
+  @else if $type == 'complex' {
+    @include complex-layout($name) {
+      @content;
+    }
+  }
+  @else {
+    @warn '#{$type} is not a valid North layout type. Please use either `simple` or `complex`';
+    @content;
+  }
+}
+

data/north/north/_layouts.scss

@@ -1,67 +1,21 @@
-//////////////////////////////
-// Variables
-//////////////////////////////
-$north-layout-type: 'simple' !default;
-
 //////////////////////////////
 // Functions
 //////////////////////////////
-@function simple-layout($name) {
+@function layout($name) {
   @return '_#{to-lower-case($name)}';
 }
 
-@function complex-layout($name) {
-  @return '__#{to-lower-case($name)}';
-}
-
-@function layout($name, $type: $north-layout-type) {
-  $type: to-lower-case($type);
-  $prefix: null;
-
-  @if $type == 'simple' {
-    @return simple-layout($name);
-  }
-  @else if $type == 'complex' {
-    @return complex-layout($name);
-  }
-  @else {
-    @warn '#{$type} is not a valid North layout type. Please use either `simple` or `complex`';
-    @return $name;
-  }
-}
-
 //////////////////////////////
-// Layout Mixins
+// Mixins
 //////////////////////////////
-@mixin simple-layout($name) {
-  @at-root .#{simple-layout($name)} {
-    @content;
-  }
-}
-
-@mixin complex-layout($name) {
-  @at-root .#{complex-layout($name)} {
+@mixin layout($name) {
+  @include layouts($name) {
     @content;
   }
 }
 
-@mixin layout($name, $type: $north-layout-type) {
-  $type: to-lower-case($type);
-  $prefix: null;
-
-  @if $type == 'simple' {
-    @include simple-layout($name) {
-      @content;
-    }
-  }
-  @else if $type == 'complex' {
-    @include complex-layout($name) {
-      @content;
-    }
-  }
-  @else {
-    @warn '#{$type} is not a valid North layout type. Please use either `simple` or `complex`';
+@mixin layouts($names...) {
+  @include north--core('layout', $names) {
     @content;
   }
-}
-
+}

data/north/north/_states--OLD.scss

@@ -0,0 +1,24 @@
+//////////////////////////////
+// Variables
+//////////////////////////////
+$north-state-contains: false !default;
+
+//////////////////////////////
+// Functions
+//////////////////////////////
+@function state($name, $contains: $north-state-contains) {
+  $selector: '=';
+  @if $contains {
+    $selector: '~=';
+  }
+  @return '[data-state#{$selector}"#{$name}"]';
+}
+
+//////////////////////////////
+// Mixins
+//////////////////////////////
+@mixin state($name, $contains: $north-state-contains) {
+  @at-root &#{state($name, $contains)} {
+    @content;
+  }
+}

data/north/north/_states.scss

@@ -1,24 +1,21 @@
-//////////////////////////////
-// Variables
-//////////////////////////////
-$north-state-contains: false !default;
-
 //////////////////////////////
 // Functions
 //////////////////////////////
-@function state($name, $contains: $north-state-contains) {
-  $selector: '=';
-  @if $contains {
-    $selector: '~=';
-  }
-  @return '[data-state#{$selector}"#{$name}"]';
+@function state($name) {
+  @return '[data-state~="#{$name}"]';
 }
 
 //////////////////////////////
 // Mixins
 //////////////////////////////
-@mixin state($name, $contains: $north-state-contains) {
-  @at-root &#{state($name, $contains)} {
+@mixin state($name) {
+  @include layouts($name) {
+    @content;
+  }
+}
+
+@mixin states($names...) {
+  @include north--core('state', $names) {
     @content;
   }
 }

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: north
 version: !ruby/object:Gem::Version
-  version: 0.2.0
+  version: 0.3.0
 platform: ruby
 authors:
 - Sam Richard
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2014-02-17 00:00:00.000000000 Z
+date: 2014-04-27 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: sass
@@ -16,14 +16,14 @@ dependencies:
     requirements:
     - - ~>
       - !ruby/object:Gem::Version
-        version: 3.3.0.rc.3
+        version: '3.3'
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - ~>
       - !ruby/object:Gem::Version
-        version: 3.3.0.rc.3
+        version: '3.3'
 description: Really simple media queries in Sass
 email:
 - sam@snug.ug
@@ -38,7 +38,10 @@ files:
 - north/north/_aspects.scss
 - north/north/_components.scss
 - north/north/_elements.scss
+- north/north/_helpers.scss
+- north/north/_layouts--OLD.scss
 - north/north/_layouts.scss
+- north/north/_states--OLD.scss
 - north/north/_states.scss
 homepage: https://github.com/snugug/north
 licenses:
@@ -60,7 +63,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
       version: 1.3.6
 requirements: []
 rubyforge_project: north
-rubygems_version: 2.0.3
+rubygems_version: 2.0.14
 signing_key: 
 specification_version: 4
 summary: An easy to use system for writing and managing media queries.