north 0.1.1 → 0.2.0
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/README.md +66 -38
- data/lib/north.rb +2 -2
- data/north/north/_aspects.scss +1 -1
- data/north/north/_components.scss +1 -1
- data/north/north/_elements.scss +2 -2
- metadata +4 -4
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA1:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: 7cd89a584a3cfabbdeeae988febec93734a485ec
|
|
4
|
+
data.tar.gz: cffbe411572b260dd8b6b182394054f525ec201e
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: 99c169d890e2443aaf4be7dc9be3b355d3c16d00a48ce71725d6b507fa0cf47fb71e1897c87d351f5e584ddefa8f288dce287285ca0c2ccf2276c9cc15639a45
|
|
7
|
+
data.tar.gz: b6524c025d711cb6804018da0710eb7ca8f8c6e45b1dae040d5797a3d0e8f71b93b81a8c57ccf0c9cc71eb05a6bf09389e2f1957d187bde7ef8a6fb75aad44f2
|
data/README.md
CHANGED
|
@@ -17,12 +17,13 @@ North is meant to be a living document. Standards and best practices change, and
|
|
|
17
17
|
* [Designer](#designer)
|
|
18
18
|
* [Developer](#developer)
|
|
19
19
|
* [Quality Assurance](#quality-assurance)
|
|
20
|
-
* [
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
20
|
+
* [Agile Scrum](#agile-scrum)
|
|
21
|
+
* [User Stories](#user-stories)
|
|
22
|
+
* [Benefit Statement](#benefit-statement)
|
|
23
|
+
* [Requirements](#requirements)
|
|
24
|
+
* [Size and Value](#size-and-value)
|
|
25
25
|
* [Backlog](#backlog)
|
|
26
|
+
* [Iterations](#iterations)
|
|
26
27
|
* [Version Control](#version-control)
|
|
27
28
|
* [Feature Branches](#feature-branches)
|
|
28
29
|
* [Tags and Releases](#tags-and-releases)
|
|
@@ -53,6 +54,7 @@ North is meant to be a living document. Standards and best practices change, and
|
|
|
53
54
|
* [Plugins](#plugins)
|
|
54
55
|
* [Outdated User Experience Patterns](#outdated-ux-patterns)
|
|
55
56
|
* [Design in Browser](#design-in-browser)
|
|
57
|
+
* [Parallel Design](#parallel-design)
|
|
56
58
|
* [Mobile First](#mobile-first)
|
|
57
59
|
* [Pair Design](#pair-design)
|
|
58
60
|
* [Sketching](#sketching)
|
|
@@ -105,11 +107,13 @@ North is meant to be a living document. Standards and best practices change, and
|
|
|
105
107
|
|
|
106
108
|
# Development Process
|
|
107
109
|
|
|
108
|
-
Much like [visual design](#visual-design), the process of developing a product has changed as the understanding of the medium being worked in has changed from an extension of print design to
|
|
110
|
+
Much like [visual design](#visual-design), the process of developing a product has changed as the understanding of the medium being worked in has changed from an extension of print design to its own entity. Whereas in print design a final product was always the deliverable and designs for that product would be handed from one role to another without back and forth communication, the web requires a new process better suited for the complex and interactive nature of the final product.
|
|
111
|
+
|
|
112
|
+
Often referred to as *waterfall*, the old method of a static page being created by a designer, approved by a product owner, and then handed off to developers without further communication does not produce results in the best interests of anyone involved. The product owner doesn't see the final product until it is all finished and ready for launch, much too late to make any significant corrections or alter the path of the project.
|
|
109
113
|
|
|
110
|
-
|
|
114
|
+
Instead, a more *agile* process, where product owners, designers, and developers all work in conjunction with one another to build value in a product throughout its development cycle, is needed. One where a small amount of work and constant feedback between all parties can build a large project out of small parts. One where the final project may not have every bell and whistle hoped for, but rather has an array of features that fulfill the maximum potential of the cost of development based on business and user needs. This is a large change in the way most individuals and organizations have done this type of work in the past, but by sticking to this process, a better product will be built in the long run, and those involved in the building will not be exhausted or burnt out by the process.
|
|
111
115
|
|
|
112
|
-
|
|
116
|
+
There are many different agile methodologies that all fulfill the same purpose of building projects in a more collaborative environment with constant communication between all roles involved in a project. The Scrum methodology described below is one such methodology that has found much success across many teams and organizations.
|
|
113
117
|
|
|
114
118
|
## Roles and Responsibilities
|
|
115
119
|
|
|
@@ -117,11 +121,11 @@ In any given project, there are a variety of roles that each play a part in the
|
|
|
117
121
|
|
|
118
122
|
### Product Owner
|
|
119
123
|
|
|
120
|
-
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 a fully involved individual in the lifecycle of a project. They are responsible for prioritizing the [backlog](#backlog)
|
|
124
|
+
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.
|
|
121
125
|
|
|
122
126
|
### Project Manager
|
|
123
127
|
|
|
124
|
-
The individual in charge of
|
|
128
|
+
The individual in charge of ensuring the product cycle is being kept on track. They take charge in managing expectations of product owners, ensuring that designers and developers are able to deliver what they have [committed to](#commitment) during a [sprint](#iterations), and working with the product owner to ensure there are enough defined, consumable, prioritized [user stories](#user-stories) to work on for the upcoming [iterations](#iterations). Project managers often run [scrums](#scrum) if there is not a dedicated person to do so. There should only be a single project manager per project.
|
|
125
129
|
|
|
126
130
|
### Designer
|
|
127
131
|
|
|
@@ -135,27 +139,33 @@ Much like designers, there are two types of developers, front end developers and
|
|
|
135
139
|
|
|
136
140
|
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.
|
|
137
141
|
|
|
138
|
-
##
|
|
142
|
+
## Agile Scrum
|
|
139
143
|
|
|
140
|
-
|
|
144
|
+
### User Stories
|
|
145
|
+
|
|
146
|
+
A user story describes work that needs to be done for a feature of a particular product. User stories contain [benefit statements](#benefit-statement), [requirements](#requirements), [a size, and a value](#size-and-value). [Project Managers](#project-manager) and [product owners](#product-owner) should work together to create the basics of a user story ([benefit statements](#benefit-statement), [requirements](#requirements), [value](#size-and-value); often called a **stub**), flush out [requirements](#requirements) with a [user experience designer](#designer), and have work with the team to ensure stories are [sized](#size-and-value). Once all of these items are complete, a user story is considered **defined**. Once a product owner has prioritized them in the [backlog](#backlog), they are considered **consumable**. It behooves teams to have enough user stories defined and consumable to cover the current [iteration](#iterations) and one to two iterations in the future at any given time.
|
|
141
147
|
|
|
142
148
|
When determining what user stories to stub out first, it is important to look to the [content strategy](#content-strategy) of a product. [Content types](#content-modeling) that are most valuable should have their features prioritized when it comes to creating user stories. The [information architecture](#information-architecture) will also assist in determining what features are needed and therefore what user stories should be generated. Features based off of content strategy should have the value of their content types associated to them in order to provide insight into overall value being generated by a given feature.
|
|
143
149
|
|
|
144
|
-
|
|
150
|
+
#### Benefit Statement
|
|
145
151
|
|
|
146
152
|
Benefit statements describe why a feature is important to be built based on [user personas](#user-personas) and business needs. Useful in helping to determine value for a feature and can thus help in organizing the [backlog](#backlog), benefit statements are written in the form *As [persona], I want [desire] so that [rationale].*
|
|
147
153
|
|
|
148
|
-
|
|
154
|
+
#### Requirements
|
|
149
155
|
|
|
150
156
|
The functional requirements of a user story are based on the desired user experience of a feature and should be thorough enough to be completed by a [designer](#designer) or [developer](#developer) without additional question. An example of incomplete requirements would be "Create a photo gallery". On the other hand, "Create a rotating display that holds five items, paginates with swipe or mouse click, draws in an image from the Image content type displayed at a 16:9 ratio with the title and short description and can resize fluidly, ordered by most recent item" is much more thorough and can be built and designed without further input.
|
|
151
157
|
|
|
152
|
-
|
|
158
|
+
#### Size and Value
|
|
153
159
|
|
|
154
160
|
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).
|
|
155
161
|
|
|
156
|
-
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.
|
|
162
|
+
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).
|
|
157
163
|
|
|
158
|
-
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 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.
|
|
164
|
+
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.
|
|
165
|
+
|
|
166
|
+
### Backlog
|
|
167
|
+
|
|
168
|
+
The backlog is the list of prioritized user stories that have not been worked on yet. It is up to the [product owner](#product-owner) to prioritize the user stories in the backlog. Prioritizing the backlog allows the [team](#roles-and-responsibilities) to know what the most important items are to work on and therefore what to size. Product owners should use each user story's value as a guide. While they do not need to explicitly order the backlog based on the value of each user story, the value provides an unbiased look at each feature in the overall scheme of the build, so it should be used to guide decisions on backlog priority.
|
|
159
169
|
|
|
160
170
|
### Iterations
|
|
161
171
|
|
|
@@ -165,11 +175,7 @@ Once a day during each sprint, all [team members](#roles-and-responsibilities) s
|
|
|
165
175
|
|
|
166
176
|
Towards the end of each iteration the team should come together to determine what stories to work on for the next iteration. This is called **commitment**. When determining capacity, remember to take into account meetings an individual may need to take part in, including time spent sizing user stories and this, and the acceptance, meeting.
|
|
167
177
|
|
|
168
|
-
At the end of each iteration, the team should come together to present the work they have accomplished to the product owner. At this time, the work done should be compared to the stories committed to. For each story committed to, if what was produced matches the requirements laid out in the story, the [product owner](#product-owner) should accept the story as complete. If the result was not what was expected by the product owner but meets all requirements as laid out in the story, the product owner should still accept the story and create a new story for changes. If all stories are complete and accepted, the iteration passes; if not, the iteration fails. It is OKAY to fail an iteration, it just means estimations were off and need to be adjusted for the next iteration.
|
|
169
|
-
|
|
170
|
-
### Backlog
|
|
171
|
-
|
|
172
|
-
The backlog is the list of prioritized user stories that have not been worked on yet. It is up to the [product owner](#product-owner) to prioritize the user stories in the backlog. Prioritizing the backlog allows the [team](#roles-and-responsibilities) to know what the most important items are to work on and therefore what to size. Product owners should use each user story's value as a guide. While they do not need to explicitly order the backlog based on the value of each user story, the value provides an unbiased look at each feature in the overall scheme of the build, so it should be used to guide decisions on backlog priority.
|
|
178
|
+
At the end of each iteration, the team should come together to present the work they have accomplished to the product owner. At this time, the work done should be compared to the stories committed to. For each story committed to, if what was produced matches the [requirements](#requirements) laid out in the story, the [product owner](#product-owner) should accept the story as complete. If the result was not what was expected by the product owner but meets all requirements as laid out in the story, the product owner should still accept the story and create a new story for changes. If all stories are complete and accepted, the iteration passes; if not, the iteration fails. It is OKAY to fail an iteration, it just means estimations were off and need to be adjusted for the next iteration.
|
|
173
179
|
|
|
174
180
|
## Version Control
|
|
175
181
|
|
|
@@ -181,6 +187,8 @@ The version control system of choice is [Git](http://en.wikipedia.org/wiki/Git_\
|
|
|
181
187
|
|
|
182
188
|
When developing using Git, there should be one canonical branch, usually called `master`. No developer should ever commit code directly into `master`; instead, each developer should branch off of `master` named after the feature they are working (usually from a [user story](#user-stories)) and develop in that branch. These are called **feature branches**. Feature branches should only contain one feature. When a feature is complete, a request to merge that branch into `master` should take place (in [GitHub](https://github.com/) parlance, a *pull request*). At that point, a developer who did not write the code should review the request and make sure it meets the development standards of the group and, primarily, that it works. Assuming it meets all of the basic requirements, it should be merged by the reviewing developer. A [continuous integration system](http://en.wikipedia.org/wiki/Continuous_integration) can assist greatly in this merge request process by automating most of it, including running tests against the developed code. At no point should a developer merge their own code into `master`.
|
|
183
189
|
|
|
190
|
+
GitHub has created a fantastic visualization of [this process flow](http://guides.github.com/overviews/flow/) as part of their [GitHub Guides](http://guides.github.com/) documentation.
|
|
191
|
+
|
|
184
192
|
### Tags and Releases
|
|
185
193
|
|
|
186
194
|
When a section of work has been completed (usually after a [sprint](#sprint)), whatever code is ready to be released (the current state of `master`, usually after quality assurance testing has taken place) should be tagged for release. Tags should be created using [SEMVER](http://semver.org/) versioning and should begin with the letter **v**. A single designated member of the team, usually the Lead Developer (when using a [continuous delivery system](http://en.wikipedia.org/wiki/Continuous_delivery), it should take care of this), should create the tag and push it to each Git remote. They should then release that tag (and only that tag) into production.
|
|
@@ -253,17 +261,17 @@ When building content inventories, it's often convenient to include limits for e
|
|
|
253
261
|
* `(0)` - Soft limit, when a known limit isn't known, but a known minimum is
|
|
254
262
|
* `000x00` - Dimensions. Width before height
|
|
255
263
|
* `^foo` - Begins with (in this case, foo)
|
|
256
|
-
*
|
|
264
|
+
* `bar$` - Ends with (in this case, bar)
|
|
257
265
|
* `.jpg|png` - Multiple options (in this case either jpg or png file extensions)
|
|
258
266
|
|
|
259
|
-
|
|
260
268
|
|
|
261
269
|
## Content Audit
|
|
262
270
|
|
|
263
271
|
A content audit provides a first look at what content is available and how it is written as a way of sussing out if what is currently available is worth keeping, editing, or removing. Ask the following questions about the content and content types gathered from a [content inventory](#content-inventory).
|
|
264
272
|
|
|
265
273
|
* Is the content too long, too short, or just right? Can longer content be cut into shorter chunks and still make sense?
|
|
266
|
-
* Is the copy wordy? Does it ramble? Can it be cleaned up without
|
|
274
|
+
* Is the copy wordy? Does it ramble? Can it be cleaned up without losing its meaning?
|
|
267
275
|
* Does each page or chunk get to the point quickly?
|
|
268
276
|
* Is content even broken up into chunks?
|
|
269
277
|
* Is the content relevant and important?
|
|
@@ -488,7 +496,7 @@ While building out an IA, the product's [content mode](#content-mode) may need t
|
|
|
488
496
|
|
|
489
497
|
# Visual Design
|
|
490
498
|
|
|
491
|
-
|
|
499
|
+
[](http://en.wikipedia.org/wiki/The_Treachery_Of_Images)
|
|
492
500
|
|
|
493
501
|
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.
|
|
494
502
|
|
|
@@ -520,7 +528,7 @@ This hierarchy can be applied to websites as well.
|
|
|
520
528
|
|
|
521
529
|
As with Maslow's hierarchy of needs as it relates to humans, a website's base needs must be fulfilled in order for self-actualization to occur. If any step negatively affects a step below it, that needs to be rethought. Self-actualization cannot have a negative impact on esteem, belonging, safety, or physiological needs, and so on.
|
|
522
530
|
|
|
523
|
-
|
|
524
532
|
|
|
525
533
|
|
|
526
534
|
## Consistency and Predictability
|
|
@@ -564,7 +572,7 @@ There are three parts that make up a grid; they are the columns, the gutters, an
|
|
|
564
572
|
|
|
565
573
|
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.
|
|
566
574
|
|
|
567
|
-
|
|
568
576
|
|
|
569
577
|
### Asymmetric Grids
|
|
570
578
|
|
|
@@ -574,25 +582,25 @@ Unlike the common symmetric grid, the uncommon asymmetric grid provides for inte
|
|
|
574
582
|
|
|
575
583
|
Custom asymmetric grids are asymmetric grids where column sizes are determined by the designer. Any set of columns of differing sizes can be used to create an asymmetric grid. This example shows a split gutter grid with columns in relation of `1 4 1`.
|
|
576
584
|
|
|
577
|
-
|
|
578
586
|
|
|
579
587
|
#### Compound Grids
|
|
580
588
|
|
|
581
589
|
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.
|
|
582
590
|
|
|
583
|
-
|
|
584
592
|
|
|
585
593
|
#### Ratio Based Grids
|
|
586
594
|
|
|
587
595
|
Ratio based grids are grids where each column is based on a ratio of the previous column. This allows for interesting constraints, such as allowing the ratios for vertical rhythm (font size, line height) to also be used for horizontal rhythm (the grid).
|
|
588
596
|
|
|
589
|
-
|
|
590
598
|
|
|
591
599
|
#### Spiral Based Grids
|
|
592
600
|
|
|
593
601
|
Spiral based grids are similar to ratio based grids in that they are likewise based on a ratio, but instead of each column getting progressively larger or smaller, the columns are determined based on parallel lines running through a spiral that degrades based on the ratio. Twitter for a time [used a golden ratio based spiral design](http://mashable.com/2010/09/29/new-twitter-golden-ratio/).
|
|
594
602
|
|
|
595
|
-
|
|
596
604
|
|
|
597
605
|
## Anti Patterns
|
|
598
606
|
|
|
@@ -610,7 +618,7 @@ Dark patterns are UX patterns that are anti user. They include patterns such as
|
|
|
610
618
|
|
|
611
619
|
### Signal to Noise Ratio
|
|
612
620
|
|
|
613
|
-
Signal to noise ratio (SNR or S/N) is a measure of what is being looked for (signal) to the background it is against (noise). If there is too much noise, the signal gets lost. In web design, signal is the content and noise is the chrome or extra items around the content. When designing sites, the goal is to have as high a signal to noise ratio as possible (lots of signal, little noise). This is not to say that there should be no chrome around content, but rather that the ratio is kept in check so the content is the most prominent piece of a design. Steven Bradley has a great writeup
|
|
621
|
+
Signal to noise ratio (SNR or S/N) is a measure of what is being looked for (signal) to the background it is against (noise). If there is too much noise, the signal gets lost. In web design, signal is the content and noise is the chrome or extra items around the content. When designing sites, the goal is to have as high a signal to noise ratio as possible (lots of signal, little noise). This is not to say that there should be no chrome around content, but rather that the ratio is kept in check so the content is the most prominent piece of a design. Steven Bradley has a great writeup titled [What's The Signal to Noise Ratio Of Your Design](http://www.vanseodesign.com/web-design/signal-to-noise-ratio/) that goes in depth about how to improve the SNR in a design. In addition, there is a terrific Flickr photo set called [Noise-to-Noise Ratio](http://www.flickr.com/photos/merlin/sets/72157622077100537/) containing screenshots of websites that get SNR wrong and what is presented is mostly only noise.
|
|
614
622
|
|
|
615
623
|
### Plugins
|
|
616
624
|
|
|
@@ -633,10 +641,10 @@ Just like how presentations deprecate, so do UX patterns. There are a plethora o
|
|
|
633
641
|
* **App-Like Interfaces** - While some app-like interface patterns can be transitioned to the web (such as the drawer slide out menu), websites are not apps the design conventions of native apps for a given platform should not be used to mimic their look and feel on the web. Examples of this happening include [jQuery Mobile](http://jquerymobile.com/) and mimicking iOS headers/bottom icon based navigation.
|
|
634
642
|
* **Back Buttons** - Popularized by iOS, back buttons have become popular especially with designed that try to mimic app-like interfaces. Don't use them. Every browser has a native, easily accessible, well integrated back button; one that behaves better than any that could or should be built.
|
|
635
643
|
* **Page Preloaders** - Users want to get to a site's content as quickly as possible. If instead of providing it a preloader is put up that is designed to halt a user from getting content until every piece that makes up that content is available, a user is likely to [leave and not come back](#performance)
|
|
636
|
-
* **Social Integration** - While social integration is often seen as a great boon, more often than not the plethora of third party logos scattered throughout a page make a site look more like NASCAR than a finely crafted brand. While the effect of this hasn't been
|
|
644
|
+
* **Social Integration** - While social integration is often seen as a great boon, more often than not the plethora of third party logos scattered throughout a page make a site look more like NASCAR than a finely crafted brand. While the effect of this hasn't been thoroughly researched yet, there is one truth; social integration provides free advertising for those social networks and ties the site's branding to those social networks, for better or worse.
|
|
637
645
|
* **Buttons** - Social share buttons are one of the worst additions one can make to a site. Besides being [terrible](http://zurb.com/article/883/small-painful-buttons-why-social-media-bu) for [performance](http://lastdropofink.co.uk/market-places/the-true-cost-of-adding-social-buttons/) (findings suggest that they bloat load times enough to break ideal and maybe even maximum [page load times](#payload-performance)), they have a tendency to add lots of clutter to a page; Facebook, Twitter, and Google+ for the page, the article, the gallery, and each image at a given URL? As pointed out by [Oliver Reichenstein](http://theoatmeal.com/comics/facebook_likes), users who use these social networks already know how to find content and certainly know how to share URLs. In fact, Smashing Magazine removed Facebook buttons from their site and traffic from Facebook increased because [users shared the content organically instead](https://twitter.com/smashingmag/status/204955763368660992). As stated in Oliver's article, and reinforced (humorously) by [Matthew Inman](http://theoatmeal.com/comics/facebook_likes), the best way to increase social traffic to a site is to have good content that people organically want to share, not to have social media buttons.
|
|
638
646
|
* **Login** - While less harmful than social share buttons, social login buttons should be approached with a similar amount of caution, but for different reasons. Social login buttons put security into the hands of a 3rd party and tie users to that 3rd party; if either go down or are compromised for any reason, there is nothing that can be done by a site owner. They also have the possibility of increasing cognitive load by making a user remember which method they used to log in last time. Finally, as MailChimp found out [after they added, then removed social login](http://blog.mailchimp.com/social-login-buttons-arent-worth-it/), that improving failed login attempts is more about good error handling and content than adding social login.
|
|
639
|
-
* **Content Pagination** - Users are very comfortable scrolling vertically on a page and have a tendency to get frustrated when content is paginated unnecessarily. Only paginate content if it is absolutely necessary, and even then provide users a way of viewing the full contents on a single page.
|
|
647
|
+
* **Content Pagination** - Users are very comfortable scrolling vertically on a page and have a tendency to get frustrated when content is paginated unnecessarily. Only paginate content if it is absolutely necessary, and even then provide users a way of viewing the full contents on a single page.
|
|
640
648
|
* **Content Insertionals** - Seen often in article views, content insertionals are usually links to other tangentially related content in-between paragraphs as a stand-alone paragraph or as non-hyperlink "links" in an article that produce a hover or click modal of other, likewise tangentially related content. These items take the user's attention and prevent them from being immersed in the content.
|
|
641
649
|
* **Auto Play Media** - Auto playing media, audio or video, is something a user never likes to see. The choice to play media should be triggered explicitly by the user.
|
|
642
650
|
* **Non User Triggered Actions** - When actions take place that are disruptive to the user that the user did not trigger, it takes them out of being immersed in the content. Examples of non-disruptive, non user triggered actions that are OK are infinite pagination or bringing in a next article flag at the bottom of an article. Examples of disruptive non user triggered actions include loading content above where the user is, pushing the page down, and refreshing a gallery of images as a user is browsing them.
|
|
@@ -658,6 +666,26 @@ Designing in browser also allows for creative opportunities that would otherwise
|
|
|
658
666
|
|
|
659
667
|
Because design decisions will need to be made throughout the lifespan of a project, the designers (both UI and UX) responsible for the design of a site need to be part of the full lifecycle of a project and cannot simply hand off initial designs and walk away from a project when development starts.
|
|
660
668
|
|
|
669
|
+
### Parallel Design
|
|
670
|
+
|
|
671
|
+
When designing in browser, the process of design changes from a purely visual one to a combined team effort. The following roles are involved in the visual design process. Like in the general [roles and responsibilities](#roles-and-responsibilities), these roles may be filled by the same person, and should be the same set of individuals throughout the duration of a project. This process is for designing and implementing a project simultaneously:
|
|
672
|
+
|
|
673
|
+
* The [product owners](#product-owner) and [project managers](#project-manager) help to prioritize what gets designed and what the requirements of the design should be.
|
|
674
|
+
* The [designers](#designer) do the visual and user experience design. During the transition phase before all of a team's designers can code and work in browser, designers are divided into *visual designers* and *production designers*. Visual designers are designers who cannot code and work directly in browser, and production designers are those who can.
|
|
675
|
+
* The [developers](#developer) do the production development work. There are two types of developers involved in this, *back end developers* and *front end developers*. Back end developers generally work with server side languages and front end developers on the client side languages (although this depends on the actual implementation).
|
|
676
|
+
* The [qa members](#quality-assurance) test the work developed to ensure it works as expected.
|
|
677
|
+
|
|
678
|
+
1. **Story** - The product owners, project managers, visual and production designers, front and back end developers, and QA members agree upon the requirements for a given item. In Agile Scrum, this is a [user story](#user-stories). Each story should be for a single [component](#components), a single [layout](#layouts), or placing components and layouts together. The story should be based on the project's [information architecture](#information-architecture) and should include information about where content is coming from based on the project's [content models](#content-modeling).
|
|
679
|
+
2. **HTML** - The visual and production designers and front and back end developers agree upon the [markup](#markup) to use for the story they are working on, including the [classes](#css-naming-conventions) that will be used. The markup used needs to work for both the [in-browser design](#style-prototyping) and the implementation. [Rapid prototyping](#rapid-prototyping) can be employed to suss out the markup.
|
|
680
|
+
3. **Design** - The visual and production designers work on creating the look, feel, and [interaction](#interaction) for the story. This can be done at the same time as development.
|
|
681
|
+
4. **Development** - The front and back end developers work together in the actual implementation of the project to output the agreed upon markup. This can be done at the same time as design.
|
|
682
|
+
5. **Cross-browser QA** - The visual and production designers and QA team ensures that the in-browser design works cross-browser to the best of the browser's capabilities. What features any given browser supports, and therefore what features should be supported, can be referenced using [Can I Use…](http://caniuse.com/). This happens after a story's design is complete and is part of that story's design cycle.
|
|
683
|
+
6. **Feature QA** - The front and back end developers and QA team ensure that the implementation has the correct markup and the content is being drawn from the correct places. They also make sure story related code functions properly. This happens after a story's development is complete and is part of that story's design cycle.
|
|
684
|
+
7. **Integration** - The visual and production designers and the front and back end developers work together to integrate the in-browser design with the implementation, resolving any issues that may arise.
|
|
685
|
+
8. **Regression QA** - The visual and production designers, front and back end developers, and QA team ensure that the in-browser design have been fully integrated into the implementation and that no previous work has broken by doing so.
|
|
686
|
+
|
|
687
|
+
|
|
688
|
+
|
|
661
689
|
### Mobile First
|
|
662
690
|
|
|
663
691
|
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):
|
|
@@ -724,7 +752,7 @@ When starting projects, RWD should not be a line item, something to throw on at
|
|
|
724
752
|
|
|
725
753
|
## Future Friendly
|
|
726
754
|
|
|
727
|
-
The methodology of RWD is a methodology of creating sites that are [Future Friendly](http://futurefriend.ly/). The core
|
|
755
|
+
The methodology of RWD is a methodology of creating sites that are [Future Friendly](http://futurefriend.ly/). The core tenets of being future friendly are as follows:
|
|
728
756
|
|
|
729
757
|
1. Acknowledge and embrace unpredictability.
|
|
730
758
|
2. Think and behave in a [future-friendly way](http://futurefriend.ly/thinking.html).
|
|
@@ -839,7 +867,7 @@ In addition to the below, sites should be able to hit and maintain certain perfo
|
|
|
839
867
|
* [Web Page Test](http://www.webpagetest.org/)
|
|
840
868
|
* First Byte Time: 85
|
|
841
869
|
* Use persistent connection: 85
|
|
842
|
-
* Use gzip compression for transferring
|
|
870
|
+
* Use gzip compression for transferring compressible responses: 90
|
|
843
871
|
* Compress Images: 90
|
|
844
872
|
* Use Progressive JPEGs: 90
|
|
845
873
|
* Leverage browser caching of static assets: 90
|
|
@@ -898,7 +926,7 @@ There are a number of optimization techniques that can be employed in order to e
|
|
|
898
926
|
* Employ a Responsive Image solution. Until a standard exists, look for one based on image width over viewport size.
|
|
899
927
|
* `ASYNC` and `DEFER` all on-page scripts (for instance, DART tags). See [$script.js](https://github.com/ded/script.js) for a light weight async JavaScript loader
|
|
900
928
|
* `ASYNC` all ads
|
|
901
|
-
* When utilizing a CDN such as
|
|
929
|
+
* When utilizing a CDN such as Akamai, use it to serve scripts such as jQuery instead of Google's CDN as it will be faster on a cold cache
|
|
902
930
|
* Inline small but important files (generally <3Kb) to reduce HTTP requests. Aggregate other small files to reduce HTTP requests
|
|
903
931
|
|
|
904
932
|
### Experimental Optimizations
|
data/lib/north.rb
CHANGED
|
@@ -6,6 +6,6 @@ stylesheets_dir = File.join(base_directory, 'north')
|
|
|
6
6
|
Compass::Frameworks.register("north", :path => base_directory, :stylesheets_directory => stylesheets_dir)
|
|
7
7
|
|
|
8
8
|
module North
|
|
9
|
-
VERSION = "0.
|
|
10
|
-
DATE = "
|
|
9
|
+
VERSION = "0.2.0"
|
|
10
|
+
DATE = "2014-02-17"
|
|
11
11
|
end
|
data/north/north/_aspects.scss
CHANGED
data/north/north/_elements.scss
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
//////////////////////////////
|
|
2
2
|
// Functions
|
|
3
3
|
//////////////////////////////
|
|
4
|
-
@function element($name) {
|
|
4
|
+
@function n-element($name) {
|
|
5
5
|
@return to-lower-case($name);
|
|
6
6
|
}
|
|
7
7
|
|
|
@@ -9,7 +9,7 @@
|
|
|
9
9
|
// Mixins
|
|
10
10
|
//////////////////////////////
|
|
11
11
|
@mixin element($name) {
|
|
12
|
-
|
|
12
|
+
&--#{n-element($name)} {
|
|
13
13
|
@content;
|
|
14
14
|
}
|
|
15
15
|
}
|
metadata
CHANGED
|
@@ -1,14 +1,14 @@
|
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
|
2
2
|
name: north
|
|
3
3
|
version: !ruby/object:Gem::Version
|
|
4
|
-
version: 0.
|
|
4
|
+
version: 0.2.0
|
|
5
5
|
platform: ruby
|
|
6
6
|
authors:
|
|
7
7
|
- Sam Richard
|
|
8
8
|
autorequire:
|
|
9
9
|
bindir: bin
|
|
10
10
|
cert_chain: []
|
|
11
|
-
date:
|
|
11
|
+
date: 2014-02-17 00:00:00.000000000 Z
|
|
12
12
|
dependencies:
|
|
13
13
|
- !ruby/object:Gem::Dependency
|
|
14
14
|
name: sass
|
|
@@ -16,14 +16,14 @@ dependencies:
|
|
|
16
16
|
requirements:
|
|
17
17
|
- - ~>
|
|
18
18
|
- !ruby/object:Gem::Version
|
|
19
|
-
version: 3.3.0.rc.
|
|
19
|
+
version: 3.3.0.rc.3
|
|
20
20
|
type: :runtime
|
|
21
21
|
prerelease: false
|
|
22
22
|
version_requirements: !ruby/object:Gem::Requirement
|
|
23
23
|
requirements:
|
|
24
24
|
- - ~>
|
|
25
25
|
- !ruby/object:Gem::Version
|
|
26
|
-
version: 3.3.0.rc.
|
|
26
|
+
version: 3.3.0.rc.3
|
|
27
27
|
description: Really simple media queries in Sass
|
|
28
28
|
email:
|
|
29
29
|
- sam@snug.ug
|