north 0.1.0 → 0.1.1
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/README.md +231 -219
- data/lib/north.rb +2 -2
- metadata +2 -2
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA1:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: 509888720f12aeda24866370f951f62da7ec663a
|
|
4
|
+
data.tar.gz: ebd8cfc0c6216c82fe98425122be96f3da7af82d
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: 9816c2cc4d1c49f29eebf3caa0bdeefd88cae3b854876b0e47692fd0bd18491cffa68d7ac3f0d7918a298da2f83caade8fb315bc4ec6ddd17be51409d7a3b7f9
|
|
7
|
+
data.tar.gz: da9777e15f3a0b3fd8b666dd1cced12c35ede8e40cb43a93ae02181b0526fb75ad800a99c4cd47348e1dc1e816a4359cdeb12e7c3b554ae9547dbc54a435feaf
|
data/README.md
CHANGED
|
@@ -4,103 +4,103 @@ North
|
|
|
4
4
|
|
|
5
5
|
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.
|
|
6
6
|
|
|
7
|
-
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.
|
|
7
|
+
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.
|
|
8
8
|
|
|
9
|
-
*Currently open to review, first
|
|
9
|
+
*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.*
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
# Table of Contents
|
|
12
12
|
|
|
13
13
|
1. [Development Process](#development-process)
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
14
|
+
* [Roles and Responsibilities](#roles-and-responsibilities)
|
|
15
|
+
* [Product Owner](#product-owner)
|
|
16
|
+
* [Project Manager](#project-manager)
|
|
17
|
+
* [Designer](#designer)
|
|
18
|
+
* [Developer](#developer)
|
|
19
|
+
* [Quality Assurance](#quality-assurance)
|
|
20
|
+
* [User Stories](#user-stories)
|
|
21
|
+
* [Benefit Statement](#benefit-statement)
|
|
22
|
+
* [Requirements](#requirements)
|
|
23
|
+
* [Size and Value](#size-and-value)
|
|
24
|
+
* [Iterations](#iterations)
|
|
25
|
+
* [Backlog](#backlog)
|
|
26
|
+
* [Version Control](#version-control)
|
|
27
|
+
* [Feature Branches](#feature-branches)
|
|
28
|
+
* [Tags and Releases](#tags-and-releases)
|
|
29
|
+
* [Preprocessed Languages](#preprocessed-languages)
|
|
30
|
+
* [Brooks's Law](#brookss-law)
|
|
31
31
|
2. [Content Strategy](#content-strategy)
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
32
|
+
* [Project Vision](#project-vision)
|
|
33
|
+
* [User Personas](#user-personas)
|
|
34
|
+
* [Content Inventory](#content-inventory)
|
|
35
|
+
* [Content Audit](#content-audit)
|
|
36
|
+
* [Content Modeling](#content-modeling)
|
|
37
|
+
* [Information Architecture](#information-architecture)
|
|
38
38
|
3. [Visual Design](#visual-design)
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
39
|
+
* [Website Needs](#website-needs)
|
|
40
|
+
* [Consistency and Predictability](#consistency-and-predictability)
|
|
41
|
+
* [Complexity and Complication](#complexity-and-complication)
|
|
42
|
+
* [Grids](#grids)
|
|
43
|
+
* [Parts of a Grid](#parts-of-a-grid)
|
|
44
|
+
* [Symmetric Grids](#symmetric-grids)
|
|
45
|
+
* [Asymmetric Grids](#asymmetric-grids)
|
|
46
|
+
* [Custom Grids](#custom-grids)
|
|
47
|
+
* [Compound Grids](#compound-grids)
|
|
48
|
+
* [Ratio Based Grids](#ratio-based-grids)
|
|
49
|
+
* [Spiral Based Grids](#spiral-based-grids)
|
|
50
|
+
* [Anti Patterns](#anti-patterns)
|
|
51
|
+
* [Dark Patterns](#dark-patterns)
|
|
52
|
+
* [Signal to Noise Ratio](#signal-to-noise-ratio)
|
|
53
|
+
* [Plugins](#plugins)
|
|
54
|
+
* [Outdated User Experience Patterns](#outdated-ux-patterns)
|
|
55
|
+
* [Design in Browser](#design-in-browser)
|
|
56
|
+
* [Mobile First](#mobile-first)
|
|
57
|
+
* [Pair Design](#pair-design)
|
|
58
|
+
* [Sketching](#sketching)
|
|
59
|
+
* [Rapid Prototyping](#rapid-prototyping)
|
|
60
|
+
* [Style Prototyping](#style-prototyping)
|
|
61
|
+
* [Style Tiles](#style-tiles)
|
|
62
|
+
* [Style Guide](#style-guide)
|
|
63
|
+
* [Component Guide](#component-guide)
|
|
64
|
+
* [Layout Guide](#layout-guide)
|
|
65
65
|
4. [Responsive Web Design](#responsive-web-design)
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
66
|
+
* [Future Friendly](#future-friendly)
|
|
67
|
+
* [Device Detection](#device-detection)
|
|
68
|
+
* [Progressive Enhancement](#progressive-enhancement)
|
|
69
|
+
* [Feature Detection](#feature-detection)
|
|
70
|
+
* [Graceful Degradation](#graceful-degradation)
|
|
71
|
+
* [Advertising](#advertising)
|
|
72
|
+
* [Resolution Independence](#resolution-independence)
|
|
73
|
+
* [Media Queries](#media-queries)
|
|
74
|
+
* [Iconography](#iconography)
|
|
75
|
+
* [Images](#images)
|
|
76
76
|
5. [Performance](#performance)
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
77
|
+
* [Testing and Grading Performance](#testing-and-grading-performance)
|
|
78
|
+
* [Payload Performance](#payload-performance)
|
|
79
|
+
* [Page Performance](#page-performance)
|
|
80
|
+
* [Front End Optimizations](#front-end-optimizations)
|
|
81
|
+
* [Critical Optimizations](#critical-optimizations)
|
|
82
|
+
* [Recommended Optimizations](#recommended-optimizations)
|
|
83
|
+
* [Experimental Optimizations](#experimental-optimizations)
|
|
84
84
|
6. [Website Building Blocks](#website-building-blocks)
|
|
85
85
|
* [Markup](#markup)
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
86
|
+
* [HTML Semantics](#html-semantics)
|
|
87
|
+
* [Accessibility](#]accessibility)
|
|
88
|
+
* [RDFa](#rdfa)
|
|
89
|
+
* [Viewport Meta Tag](#viewport-meta-tag)
|
|
90
90
|
* [Styling](#styling)
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
91
|
+
* [Base Browser Styling](#base-browser-styling)
|
|
92
|
+
* [Components](#components)
|
|
93
|
+
* [Layouts](#layouts)
|
|
94
|
+
* [Aspects](#aspects)
|
|
95
|
+
* [Elements](#elements)
|
|
96
|
+
* [States](#states)
|
|
97
|
+
* [CSS Naming Conventions](#css-naming-conventions)
|
|
98
|
+
* [Sass and Compass](#sass-and-compass)
|
|
99
|
+
* [Mixin/Extend Pattern](#mixinextend-pattern)
|
|
100
|
+
* [Partial Structure](#partial-structure)
|
|
101
101
|
* [Interaction](#interaction)
|
|
102
|
-
|
|
103
|
-
|
|
102
|
+
* [Style and Syntax](#style-and-syntax)
|
|
103
|
+
* [Libraries, Plugins, and Frameworks](#libraries-plugins-and-frameworks)
|
|
104
104
|
7. [License and Acknowledgements](#license-and-acknowledgements)
|
|
105
105
|
|
|
106
106
|
# Development Process
|
|
@@ -113,7 +113,7 @@ Instead, a more *agile* process where product owners, designers, and developers
|
|
|
113
113
|
|
|
114
114
|
## Roles and Responsibilities
|
|
115
115
|
|
|
116
|
-
In any given project, there are a variety of roles that each play a part in the success of a project. The following is a list of the basic roles required to accomplish a project. Some individuals may fall into multiple categories, that's okay. The key is that each role has certain responsibilities and these roles need to have members throughout the entire development process, ideally with each role filled by the [same individuals](#brookss-law) for the duration of a project. Projects work best when the
|
|
116
|
+
In any given project, there are a variety of roles that each play a part in the success of a project. The following is a list of the basic roles required to accomplish a project. Some individuals may fall into multiple categories, that's okay. The key is that each role has certain responsibilities and these roles need to have members throughout the entire development process, ideally with each role filled by the [same individuals](#brookss-law) for the duration of a project. Projects work best when the total number of individuals are kept to a minimum (but that is not to say that it is better to have one of each, rather make sure that there aren't too many individuals on a project at once).
|
|
117
117
|
|
|
118
118
|
### Product Owner
|
|
119
119
|
|
|
@@ -125,7 +125,7 @@ The individual in charge of the ensuring the product cycle is being kept on trac
|
|
|
125
125
|
|
|
126
126
|
### Designer
|
|
127
127
|
|
|
128
|
-
There are two types of [designs](#visual-design) that need to happen during a typical product lifecycle: user interface design, the look and feel of a product
|
|
128
|
+
There are two types of [designs](#visual-design) that need to happen during a typical product lifecycle: user interface design, the look and feel of a product; and user experience design, how users interact with the product. User experience designers should be working with [rapid prototypes](#rapid-prototyping) to flush out interaction patterns and create rough flows, where user interface designers should be working with [style prototypes](#style-prototyping) to determine the look and feel of components that are developed by user experience designers' work. Both should work closely with developers. User experience designers should take their cues and be part of the creation process of a product's [content strategy](#content-strategy).
|
|
129
129
|
|
|
130
130
|
### Developer
|
|
131
131
|
|
|
@@ -153,7 +153,7 @@ The functional requirements of a user story are based on the desired user experi
|
|
|
153
153
|
|
|
154
154
|
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
155
|
|
|
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
|
|
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.
|
|
157
157
|
|
|
158
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.
|
|
159
159
|
|
|
@@ -161,25 +161,25 @@ Value should be determined for each aspect that provides value, generally not to
|
|
|
161
161
|
|
|
162
162
|
Work should be divided up into 2 week iterations. Each iteration represents a set of user stories that [designers](#designer), [developers](#developer), and [QA](#quality-assurance) have agreed that they can accomplish in that period of time based on how much time each individual has available (often called **capacity**, measured not in hours but in unitless numbers similar to size and value) and how difficult each user story is. Each two week iteration is often referred to as a **sprint**.
|
|
163
163
|
|
|
164
|
-
Once a day during each sprint, all [team members](#roles-and-responsibilities) should get together, either by phone, in person, or both, to quickly discuss progress so far. These meetings are called **scrum** meetings. During these meetings, [designers](#designer), [developers](#developer), and [QA](#quality-assurance) give a quick overview of what they have accomplished, what they are going to accomplish, if anything is impeding their progress (often called **blockers**), and arrange to meet with individuals that can help to lift those blockers.
|
|
164
|
+
Once a day during each sprint, all [team members](#roles-and-responsibilities) should get together, either by phone, in person, or both, to quickly discuss progress so far. These meetings are called **scrum** meetings. During these meetings, [designers](#designer), [developers](#developer), and [QA](#quality-assurance) give a quick overview of what they have accomplished, what they are going to accomplish, if anything is impeding their progress (often called **blockers**), and arrange to meet with individuals that can help to lift those blockers. Scrum meetings should be fast, no more than 15 minutes, and should not include the writing of stories or prolonged discussion; follow-up meetings are encouraged.
|
|
165
165
|
|
|
166
166
|
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
167
|
|
|
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
|
|
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
169
|
|
|
170
170
|
### Backlog
|
|
171
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
|
|
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.
|
|
173
173
|
|
|
174
174
|
## Version Control
|
|
175
175
|
|
|
176
|
-
All projects, no matter how big, no matter how small, should be put under a [version control system](http://en.wikipedia.org/wiki/Version_control)(VCS) before work begins on the project. Introducing version control early and enforcing its use will ensure a solid understanding of where code comes from in a project and eliminates the need for user-centric naming conventions such as `item-final.js`, `item-final-really.js`, `item-really-really-final.js`. It makes it easy to track how an item has changed over time and roll changes back if need be. Using version control systems also allows gates to be put up to allow for processes to be put in place before an item becomes finalized.
|
|
176
|
+
All projects, no matter how big, no matter how small, should be put under a [version control system](http://en.wikipedia.org/wiki/Version_control) (VCS) before work begins on the project. Introducing version control early and enforcing its use will ensure a solid understanding of where code comes from in a project and eliminates the need for user-centric naming conventions such as `item-final.js`, `item-final-really.js`, `item-really-really-final.js`. It makes it easy to track how an item has changed over time and roll changes back if need be. Using version control systems also allows gates to be put up to allow for processes to be put in place before an item becomes finalized.
|
|
177
177
|
|
|
178
|
-
The version control system of choice is [Git](http://en.wikipedia.org/wiki/Git_(software)), allowing for a fully decentralized VCS that is designed for non-linear, distributed development. It has very strong safeguards against corruption of the chain of changes and can version just about any file type that can be thrown at it. It is open source and works across all major platforms. For a full introduction to Git, see the freely-available [Pro Git](http://git-scm.com/book) book.
|
|
178
|
+
The version control system of choice is [Git](http://en.wikipedia.org/wiki/Git_\(software\)), allowing for a fully decentralized VCS that is designed for non-linear, distributed development. It has very strong safeguards against corruption of the chain of changes and can version just about any file type that can be thrown at it. It is open source and works across all major platforms. For a full introduction to Git, see the freely-available [Pro Git](http://git-scm.com/book) book.
|
|
179
179
|
|
|
180
180
|
### Feature Branches
|
|
181
181
|
|
|
182
|
-
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
|
|
182
|
+
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
183
|
|
|
184
184
|
### Tags and Releases
|
|
185
185
|
|
|
@@ -191,8 +191,8 @@ When working with preprocessed languages, such as [Sass](#sass-and-compass), the
|
|
|
191
191
|
|
|
192
192
|
## Brooks's Law
|
|
193
193
|
|
|
194
|
-
> Nine women can't make a baby in one month
|
|
195
|
-
>
|
|
194
|
+
> Nine women can't make a baby in one month.
|
|
195
|
+
>
|
|
196
196
|
> *Fred Brooks*
|
|
197
197
|
|
|
198
198
|
[Brooks's Law](http://en.wikipedia.org/wiki/Brooks's_law), which was coined in Fred Brooks's 1975 book [The Mythical Man-Month](http://en.wikipedia.org/wiki/The_Mythical_Man-Month), states that "adding manpower to a late software project makes it later". The law, while described even by Brooks as an oversimplification, captures two factors of a general rule of software development (as from the Wikipedia article):
|
|
@@ -220,17 +220,23 @@ Before knowing what content will best serve a site, and therefore what features
|
|
|
220
220
|
|
|
221
221
|
Vision statement provide a single grounding point for all decisions needed to create a successful product. The following is an example vision statement for a made-up news organization:
|
|
222
222
|
|
|
223
|
-
> In order to provide for a well-informed electorate who want to stay up-to-date and relate to high quality relevant worldwide news and information on an ever growing array of platforms, our editorial team will utilize an easy-to-use platform that can be accessed from any device from across the world to quickly and effortlessly
|
|
223
|
+
> In order to provide for a well-informed electorate who want to stay up-to-date and relate to high quality relevant worldwide news and information on an ever growing array of platforms, our editorial team will utilize an easy-to-use platform that can be accessed from any device from across the world to quickly and effortlessly update and create new stories.
|
|
224
224
|
|
|
225
225
|
## User Personas
|
|
226
226
|
|
|
227
|
-
User personas are a tool to distill different types of people who may interact with a product into caricatures in order to work with the different types of people effectively. *[
|
|
227
|
+
User personas are a tool to distill different types of people who may interact with a product into caricatures in order to work with the different types of people effectively. *[Product owner](#product-owner)*, *editor*, and *user* personas should be built for each product, with additional user personas or expanded base user personas as needed. In order to create user personas, interviews (ideally in person one-on-one or focus groups) should be conducted with different types of users in order to get a statistically relevant overview of each user type. The creation of user personas can happen in parallel along with the creation of a product's [vision statement](#vision-statement), [content inventory](#content-inventory), and [content audit](#content-audit).
|
|
228
228
|
|
|
229
229
|
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.
|
|
230
230
|
|
|
231
|
-
Once rough sketches of starting user types are determined, it is time for interviews. Ask users questions
|
|
231
|
+
Once rough sketches of starting user types are determined, it is time for interviews. Ask users questions such as:
|
|
232
|
+
* What do you find most valuable about the existing product and similar, including competitors', products?
|
|
233
|
+
* Is anything of value is missing from the existing product and the similar products?
|
|
234
|
+
* How do you most often access the product?
|
|
235
|
+
* What are the pain points?
|
|
236
|
+
* What is the target demographic information?
|
|
237
|
+
Interview not only users that meet the starting user types, but users from outside those initial types as it may come to light that users outside of the initial types actually make use of the product. Once all user interviews have been finished, it is time to create final user personas.
|
|
232
238
|
|
|
233
|
-
When creating user personas, do not fall into the trap of assigning stereotypes to personas, such as young adults only know how to write through text message shorthand or that [mobile users](#mobile-first) are rushed and distracted. Personas should be generated based on
|
|
239
|
+
When creating user personas, do not fall into the trap of assigning stereotypes to personas, such as that 'young adults only know how to write through text message shorthand' or that '[mobile users](#mobile-first) are rushed and distracted'. Personas should be generated based on statistical analysis of the interviews performed. Take all of the information gathered from all of the interviews and, based on analysis, break up the results into similar groups of people. What should divide users into similar groups are significant areas where multiple users use the product in similar ways, not small differences (or potentially even seemingly large differences like demographic). User personas are about how users *use* a product and what they expect from it. Finally, create a profile representing each group to be used as a final user persona. Each profile should contain the following information:
|
|
234
240
|
|
|
235
241
|
* Name
|
|
236
242
|
* Description of typical use of the product
|
|
@@ -239,7 +245,7 @@ When creating user personas, do not fall into the trap of assigning stereotypes
|
|
|
239
245
|
|
|
240
246
|
## Content Inventory
|
|
241
247
|
|
|
242
|
-
A content inventory takes an objective, broad strokes look at content that is currently available. If content is not currently available, create a content inventory based on perceived content needs. Built as a spreadsheet, it can include both intrinsic (title, owner, last updated) and analytics (page views, rank, notes) data. Content inventories are not just about pages or screens but rather the different pieces, or chunks, that go into making those larger items. Content is not just about long blobs of text; content is also images, videos, charts, and any other form of information a user may want. It is important to understand that not every single piece of content available must be inventoried, but rather
|
|
248
|
+
A content inventory takes an objective, broad strokes look at content that is currently available. If content is not currently available, create a content inventory based on perceived content needs. Built as a spreadsheet, it can include both intrinsic (title, owner, last updated) and analytics (page views, rank, notes) data. Content inventories are not just about pages or screens but rather the different pieces, or chunks, that go into making those larger items. Content is not just about long blobs of text; content is also images, videos, charts, forms, and any other form of information a user may want. It is important to understand that not every single piece of content available must be inventoried, but rather there are enough representative pieces to get a holistic view of each type of content available. By inventorying all the different types of content as well as the chunks that make up the content, a deep understanding of the content can be achieved that will make [modeling the content](#content-modeling) easier.
|
|
243
249
|
|
|
244
250
|
When building content inventories, it's often convenient to include limits for each widget or content chunk. Each item can have multiple limits, each separated by a space. The most prevalent limit (often character count) can have its type excluded. Other types include total number of items and dimensions. The following are some useful shorthand for describing limits:
|
|
245
251
|
|
|
@@ -287,7 +293,7 @@ The following is an example of two content types related to the example [vision
|
|
|
287
293
|
|
|
288
294
|
Description:
|
|
289
295
|
|
|
290
|
-
* Short to long form text with possible accompanying images of recent factual stories
|
|
296
|
+
* Short to long form text with possible accompanying images of recent factual stories
|
|
291
297
|
|
|
292
298
|
Benefits:
|
|
293
299
|
|
|
@@ -358,7 +364,7 @@ Attributes:
|
|
|
358
364
|
* Minimum: 1
|
|
359
365
|
* Maximum: 5
|
|
360
366
|
* Description: Taxonomy allows content types to be related to each other in a meta sense
|
|
361
|
-
|
|
367
|
+
|
|
362
368
|
|
|
363
369
|
Relationships
|
|
364
370
|
|
|
@@ -432,7 +438,7 @@ Attributes:
|
|
|
432
438
|
* Minimum: 1
|
|
433
439
|
* Maximum: 5
|
|
434
440
|
* Description: Taxonomy allows content types to be related to each other in a meta sense
|
|
435
|
-
|
|
441
|
+
|
|
436
442
|
Relationships
|
|
437
443
|
|
|
438
444
|
* Person
|
|
@@ -451,44 +457,48 @@ Architectures should be constructed so that the [most valuable content](#content
|
|
|
451
457
|
|
|
452
458
|
While building out an IA, the product's [content mode](#content-mode) may need to be revised. When building IAs, especially when the content model needs to be revised, keep the following rules of thumb in mind.
|
|
453
459
|
|
|
454
|
-
* **Truncation is not a content
|
|
455
|
-
|
|
456
|
-
|
|
457
|
-
|
|
458
|
-
|
|
459
|
-
|
|
460
|
+
* **Truncation is not a content strate…**
|
|
461
|
+
* Content that is truncated is usually not written for summary or reuse
|
|
462
|
+
* Truncated content usually doesn't contain [trigger words](#consistency-and-predictability)
|
|
463
|
+
* Never truncate headlines
|
|
464
|
+
* Always provide summaries for long copy
|
|
465
|
+
* Provide alternative copy when needed
|
|
460
466
|
* **Build systems of content**
|
|
461
|
-
|
|
462
|
-
|
|
463
|
-
|
|
464
|
-
|
|
467
|
+
* Content isn't always one-size-fits-all, allow for different sizes and styles of content attributes
|
|
468
|
+
* Small, medium, large images
|
|
469
|
+
* Short and long human readable and SEO friendly headlines
|
|
470
|
+
* *DO NOT* build content for [specific contexts](#device-detection) such as iPhones, Androids, Tablets, or Desktops
|
|
465
471
|
* **Content should be easy to navigate**
|
|
466
|
-
|
|
467
|
-
|
|
468
|
-
|
|
469
|
-
|
|
470
|
-
|
|
471
|
-
|
|
472
|
-
|
|
473
|
-
|
|
474
|
-
|
|
475
|
-
|
|
476
|
-
|
|
472
|
+
* Don't paginate long pieces of content unnecessarily
|
|
473
|
+
* Make it easy to navigate to sections in long pieces of content
|
|
474
|
+
* Always provide enough context for a user to make their own navigation decisions
|
|
475
|
+
* A user with location services might not exclusively want location-based information
|
|
476
|
+
* Provide plenty of [trigger words](#consistency-and-predictability)
|
|
477
|
+
* Keep navigation uncluttered
|
|
478
|
+
* More than 5 main navigation categories gets hard to scan
|
|
479
|
+
* Only provide secondary navigation when absolutely necessary
|
|
480
|
+
* Try to avoid having more than three levels of navigation
|
|
481
|
+
* If navigation gets cluttered, stop and rework to make the architecture more [comprehensible](#complexity-and-complication)
|
|
482
|
+
* Think about if headlines can be used as links, or if alternative copy should be used
|
|
477
483
|
* **Content should be available**
|
|
478
|
-
|
|
479
|
-
|
|
480
|
-
|
|
481
|
-
|
|
482
|
-
|
|
484
|
+
* Don't restrict content, especially [based on device](#device-detection)
|
|
485
|
+
* Provide [alternative formats of content](#progressive-enhancement) if one format can't be made available, such as through device capabilities or business needs
|
|
486
|
+
* Do not store content as HTML, but rather as raw attributes that can be presented in multiple ways. This is especially true for tabular data and images related to long copy
|
|
487
|
+
* Make all content available and in a way best suited for the display at hand
|
|
488
|
+
|
|
483
489
|
# Visual Design
|
|
484
490
|
|
|
485
491
|
<a href="http://en.wikipedia.org/wiki/The_Treachery_Of_Images" style="padding-left: 2em"><img alt="The Treachery of Images, René Magritte" src="https://github-camo.global.ssl.fastly.net/dcd607b42abcde7f1a96394f797a700270f6e7db/687474703a2f2f75706c6f61642e77696b696d656469612e6f72672f77696b6970656469612f656e2f622f62392f4d61677269747465506970652e6a7067" align="right"></a>
|
|
486
492
|
|
|
487
|
-
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
|
|
493
|
+
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
|
+
|
|
495
|
+
> The control which designers know in the print medium, and often desire in the web medium, is simply a function of the limitation of the printed page. We should embrace the fact that the web doesn’t have the same constraints, and design for this flexibility. But first, we must 'accept the ebb and flow of things.'
|
|
496
|
+
>
|
|
497
|
+
> *John Allsopp, “[A Dao of Web Design](http://alistapart.com/article/dao)”*
|
|
488
498
|
|
|
489
499
|
The first big change is moving away from designing pages. **The page metaphor is killing the web**. By thinking in pages instead of systems of design, design gets focused on the wrong thing; the big picture look and feel as opposed to the content; what a user actually comes to a site for. Designing reusable [components](#components) and [layouts](#layouts) instead of pages allow for a more modular design, providing better flexibility and a more consistent user interface (UI) and user experience (UX).
|
|
490
500
|
|
|
491
|
-
The second big change is moving to [in-browser design](#design-in-browser), utilizing [rapid prototyping](#rapid-prototyping) and [style prototyping](#style-prototyping) as well as the web's [building blocks](#website-building-blocks) to build designs,
|
|
501
|
+
The second big change is moving to [in-browser design](#design-in-browser), utilizing [rapid prototyping](#rapid-prototyping) and [style prototyping](#style-prototyping) as well as the web's [building blocks](#website-building-blocks) to build designs, not the static graphic design tools many clients and designers are use to. It's a big change, but it needs to happen in order to progress past thinking of web pages as extensions of printed material and create truly web-first experiences.
|
|
492
502
|
|
|
493
503
|
## Website Needs
|
|
494
504
|
|
|
@@ -500,13 +510,13 @@ In much the same vein of [Maslow's hierarchy of needs](http://en.wikipedia.org/w
|
|
|
500
510
|
4. **Esteem** - Respect and evaluation of self. In humans this includes confidence and respect by and of others.
|
|
501
511
|
5. **Self-Actualization** - To become the most one can be. In humans this includes morality, creativity, and problem solving.
|
|
502
512
|
|
|
503
|
-
This hierarchy can be
|
|
513
|
+
This hierarchy can be applied to websites as well.
|
|
504
514
|
|
|
505
|
-
1. **Physiological** - Basic core needs for survival. For websites this is [content](#content-strategy) and navigation.
|
|
506
|
-
2. **Safety** - A sense of security. For websites this is [information architecture](#information-architecture) and [predictability](#consistency-and-predictability).
|
|
507
|
-
3. **Belonging** - A need to be an accepted member of a group. For websites this is [performance](#performance) and [progressive enhancement](#progressive-enhancement); accepting to any and all who come to the site.
|
|
508
|
-
4. **Esteem** - Respect and evaluation of self. For websites this is content-first [branding](#style-tiles).
|
|
509
|
-
5. **Self-Actualization** - To become the most one can be. For websites this is all additional bells and whistles to make a site stand out and be individual, from design flair and animations to interactions, advertising, and social integration.
|
|
515
|
+
1. **Physiological** - Basic core needs for survival. For websites, this is [content](#content-strategy) and navigation.
|
|
516
|
+
2. **Safety** - A sense of security. For websites, this is [information architecture](#information-architecture) and [predictability](#consistency-and-predictability).
|
|
517
|
+
3. **Belonging** - A need to be an accepted member of a group. For websites, this is [performance](#performance) and [progressive enhancement](#progressive-enhancement); accepting to any and all who come to the site.
|
|
518
|
+
4. **Esteem** - Respect and evaluation of self. For websites, this is content-first [branding](#style-tiles).
|
|
519
|
+
5. **Self-Actualization** - To become the most one can be. For websites, this is all additional bells and whistles to make a site stand out and be individual, from design flair and animations to interactions, advertising, and social integration.
|
|
510
520
|
|
|
511
521
|
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.
|
|
512
522
|
|
|
@@ -534,11 +544,11 @@ With a want to reduce often the Siren's cry of usability studies, a lot of empha
|
|
|
534
544
|
|
|
535
545
|
Where the challenge lies is in creating complex but comprehensible systems. Having a strong [content strategy](#content-strategy) and interfaces that are [consistent and predictable](#consistency-and-predictability) are the first steps to creating complex but comprehensible systems. Build rich and complex interaction up from small and easy to comprehend [components](#components) instead of attempting to build large complex monoliths all at once. Draw upon humans' natural, rich tradition of story telling and conversation to assist in reducing complication in a complex system.
|
|
536
546
|
|
|
537
|
-
For generations, humans have used conversation to pass down stories and learn about the world. Leverage this tradition. Instead of providing all information at once, allow a user to explore through the content, inviting conversation with them. This is often referred to as **Progressive Disclosure**. Respond to users as they ask for more information, don't throw it all at them at once. Focus on one item at a time and push secondary items off to the sides, waiting for user interaction.
|
|
547
|
+
For generations, humans have used conversation to pass down stories and learn about the world. Leverage this tradition. Instead of providing all information at once, allow a user to explore through the content, inviting conversation with them. This is often referred to as **Progressive Disclosure**. Respond to users as they ask for more information, don't throw it all at them at once. Focus on one item at a time and push secondary items off to the sides, waiting for user interaction. Just as clarity will always trump density, tap or click quality will always trump quantity.
|
|
538
548
|
|
|
539
549
|
## Grids
|
|
540
550
|
|
|
541
|
-
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
|
|
551
|
+
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.
|
|
542
552
|
|
|
543
553
|
Grids are primarily [layouts](#layouts) in CSS.
|
|
544
554
|
|
|
@@ -580,13 +590,13 @@ Ratio based grids are grids where each column is based on a ratio of the previou
|
|
|
580
590
|
|
|
581
591
|
#### Spiral Based Grids
|
|
582
592
|
|
|
583
|
-
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/).
|
|
593
|
+
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/).
|
|
584
594
|
|
|
585
595
|
|
|
586
596
|
|
|
587
597
|
## Anti Patterns
|
|
588
598
|
|
|
589
|
-
Anti patterns are patterns, many times common
|
|
599
|
+
Anti patterns are patterns, many times common patterns, that even if popular, should be avoided as they go against either best user intentions, best technological intentions, best business intentions, or a combination of all three. There are three big places where anti patterns tend to pop up, these are:
|
|
590
600
|
|
|
591
601
|
* [Dark Patterns](#dark-patterns)
|
|
592
602
|
* [Signal to Noise Ratio](#signal-to-noise-ratio)
|
|
@@ -613,19 +623,21 @@ Just like how presentations deprecate, so do UX patterns. There are a plethora o
|
|
|
613
623
|
* **Carousels** - Consistently put on landing pages, carousels have been found [time and time again](http://shouldiuseacarousel.com/) to not be effective with only the first item getting any meaningful traction.
|
|
614
624
|
* **Large Background Images** - Large background images add a large amount of weight to a page for very little actual gain. Any user whose screen is generally smaller than 1024px will absolutely not see the background image. Small screens simply don't have the screen real estate to display content and background images.
|
|
615
625
|
* **Hover States for Additional Information** - Hiding additional information exclusively in hover states precludes that information from being accessible to users without fine pointers.
|
|
616
|
-
* **Mega Menus** - Mega menus became popular for providing infinitely nested menus or, in the worst cases, micro sites for each menu. These create complexity issues for uses are
|
|
626
|
+
* **Mega Menus** - Mega menus became popular for providing infinitely nested menus or, in the worst cases, micro sites for each menu. These create complexity issues for uses are particularly hard to navigate without fine pointers.
|
|
617
627
|
* **Mega Footer** - Usually thought of as a boon to search engine optimization (SEO) or a place to stick long lists of secondary navigation, large footers with links and/or tertiary content are hard for most users to follow as they tend to not be conducive to [how users read](http://www.nngroup.com/articles/f-shaped-pattern-reading-web-content/) and become absolutely unwieldy for anything other than large screen sizes. Instead, if the content in those footers is important, it should be made prominent. If secondary navigation is important, make it as usable as primary navigation, just in the footer. Google's own [SEO Guidelines](https://support.google.com/webmasters/answer/35291?hl=en) suggest that the best way to improve search engine optimization is good content.
|
|
618
628
|
* **Large Sticky Headers/Footers** - Sticky headers or footers (headers or footers that do not scroll with the page but rather stay put in their position) aren't necessarily bad in and of themselves, it's when they are large and take up a lot of screen real estate (regardless of the size of the screen). Having both sticky headers and sticky footers significantly reduces screen real estate and should likewise be avoided.
|
|
619
|
-
* **
|
|
629
|
+
* **Text In/As Images** - Text that is part of an image makes that text inaccessible to screen readers without the proper `alt` attributes and becomes hard to read (in most cases, impossible) if that image is resized, which happens often in responsive web design. Text that is an image, such as is common in font replacement techniques like [cufón](http://cufon.shoqolate.com/generate/), have the same potential `alt` attribute issues, remove the ability for that text to be selected, hurt the accessibility of that text by making it be displayed to the screen reader as an image, and remove the fluidity of that text to have its line length/size changed easily as is common with responsive web design. For the later, use [web fonts](http://en.wikipedia.org/wiki/Web_typography) and [CSS3 Fonts](http://www.w3.org/TR/css3-fonts/) instead.
|
|
630
|
+
* **Text Over Images** - Placing text over images should be avoided for variable length text as the combination of the two has a tendency to produce unexpected results and has a high likelihood of obscuring important parts of the image or overrunning and potentially covering the entire image if not well controlled. This later is especially likely to happen if a user changes their default text size. When images are small, covering the entirety of an image becomes very likely.
|
|
631
|
+
* **Accordions and Tabs** - While fine if used for their designated purpose, accordions and tab panes used to contain sub-pages hide navigation and content which is bad for user experience and are generally hard to make work in a responsive manner.
|
|
620
632
|
* **Overlays** - Overlays are a UX pattern popular for everything from insertional to modal content or interaction. Overlays, while seemingly a boon for user experience, wind up creating countless issues for users without keyboards, fine pointers, who resize their browser, or generally would like to exit one without going forward through the user interface.
|
|
621
633
|
* **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.
|
|
622
634
|
* **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.
|
|
623
635
|
* **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)
|
|
624
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 throughly 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.
|
|
625
|
-
|
|
626
|
-
|
|
637
|
+
* **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
|
+
* **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.
|
|
627
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. If pagination is required, give users the ability to view the entire contents on a single page.
|
|
628
|
-
* **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
|
|
640
|
+
* **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.
|
|
629
641
|
* **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.
|
|
630
642
|
* **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.
|
|
631
643
|
* **Infinite Pagination** - Infinite pagination that truly is infinite should be reconsidered for a more measured approach where two to four pages are automatically loaded with additional loads being triggered by user interaction.
|
|
@@ -648,23 +660,23 @@ Because design decisions will need to be made throughout the lifespan of a proje
|
|
|
648
660
|
|
|
649
661
|
### Mobile First
|
|
650
662
|
|
|
651
|
-
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):
|
|
663
|
+
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):
|
|
652
664
|
|
|
653
665
|
> 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.
|
|
654
666
|
|
|
655
667
|
Instead of thinking about mobile first as designing for a mobile device first, think of it as using mobile as a focusing lens. Luke Wroblewski has a phrase he uses when [describing this lens](http://alistapart.com/article/organizing-mobile): **One Eye, One Thumb**.
|
|
656
668
|
|
|
657
669
|
> Mobile devices require software development teams to [focus on only the most important data and actions](http://www.lukew.com/ff/entry.asp?870) in an application. There simply isn't room in a 320 by 480 pixel screen for extraneous, unnecessary elements. You have to prioritize.
|
|
658
|
-
>
|
|
670
|
+
>
|
|
659
671
|
> So when a team designs mobile first, the end result is an experience focused on the key tasks users want to accomplish without the extraneous detours and general interface debris that litter today's desktop-accessed Web sites. That's good user experience and good for business.
|
|
660
672
|
|
|
661
673
|
Using mobile as a focusing lens will also help to inform a site's [information architecture](#information-architecture) and help to create [complex, but not complicated](#complexity-and-complication) interfaces. It is important to keep in mind that larger screens do not mean that the learnings gained by the mobile lens can be tossed away simply because there is more screen real estate. The goal is to improve the UX for *all* sizes of a site, not just the small version. Do not give in to the desire to fill up whitespace on larger screens with additional, unneeded items simply because there is more room that should be filled.
|
|
662
674
|
|
|
663
675
|
### Pair Design
|
|
664
676
|
|
|
665
|
-
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
|
|
677
|
+
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.
|
|
666
678
|
|
|
667
|
-
During this process, it is also helpful for front end developers to create reusable
|
|
679
|
+
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.
|
|
668
680
|
|
|
669
681
|
Eventually, the designer should be allowed to take over full responsibility of coding and designing with the front end developer moving on to focus their efforts on [semantics](#html-semantics), [accessibility](#accessibility), and [JavaScript](#interaction).
|
|
670
682
|
|
|
@@ -674,7 +686,7 @@ While designing in browser is the standard to achieve for, many times a designer
|
|
|
674
686
|
|
|
675
687
|
## Rapid Prototyping
|
|
676
688
|
|
|
677
|
-
Rapid prototyping is a technique used to quickly create example interactions, styles, or flows. Traditionally done through code, although [paper prototyping](http://alistapart.com/article/paperprototyping) would fall under rapid prototyping, rapid prototypes are meant for demonstration purposes. Built as stand-alone projects to demonstrate a single purpose, they are used to demonstrate an idea or suss out a UI or UX problem. They also are a great tool for experimenting different options quickly. When finished, rapid prototypes can be used to create production ready code (once all
|
|
689
|
+
Rapid prototyping is a technique used to quickly create example interactions, styles, or flows. Traditionally done through code, although [paper prototyping](http://alistapart.com/article/paperprototyping) would fall under rapid prototyping, rapid prototypes are meant for demonstration purposes. Built as stand-alone projects to demonstrate a single purpose, they are used to demonstrate an idea or suss out a UI or UX problem. They also are a great tool for experimenting different options quickly. When finished, rapid prototypes can be used to create production ready code (once all steps for production ready code, including cross-browser testing, have been completed).
|
|
678
690
|
|
|
679
691
|
## Style Prototyping
|
|
680
692
|
|
|
@@ -690,23 +702,23 @@ The main idea behind style tiles is that moodboards are too vague to get a real
|
|
|
690
702
|
|
|
691
703
|
### Style Guide
|
|
692
704
|
|
|
693
|
-
A style guide is the core set of styling for each element on a page. It is the combined [base browser styling reset](#base-browser-styling) and the [base component](#base-component) styling, so it may be referred to as either the base guide or element guide as well. Items styled in the style guide should be contained under the `.base--STYLED` class as basic styling should not bleed outside of that class. Each element in
|
|
705
|
+
A style guide is the core set of styling for each element on a page. It is the combined [base browser styling reset](#base-browser-styling) and the [base component](#base-component) styling, so it may be referred to as either the base guide or element guide as well. Items styled in the style guide should be contained under the `.base--STYLED` class as basic styling should not bleed outside of that class. Each element in a style guide should include the markup required to create it as well as the styling applied to allow for easy reference and self documentation.
|
|
694
706
|
|
|
695
707
|
### Component Guide
|
|
696
708
|
|
|
697
|
-
A component guide is a listing of each [component](#components) for a project, grouped by component, with a rendered display of each aspect utilizing each of the component's elements. Accompanying each aspect display should be the markup and styling used. Each component group should include a listing of available
|
|
709
|
+
A component guide is a listing of each [component](#components) for a project, grouped by component, with a rendered display of each aspect utilizing each of the component's elements. Accompanying each aspect display should be the markup and styling used. Each component group should include a listing of available elements, the available extendable classes, mixins, and variables. If a component has JavaScript associated with it, the JavaScript filename should be included along with the source code.
|
|
698
710
|
|
|
699
711
|
### Layout Guide
|
|
700
712
|
|
|
701
|
-
A layout guide is a listing of each [layout](#layouts) for a project
|
|
713
|
+
A layout guide is a listing of each [layout](#layouts) for a project, grouped by layout, with a rendered display of each aspect utilizing each of the layout's elements. Accompanying each aspect display should be the markup and styling used. Each layout group should include a listing of available elements, the available extendable classes, mixins, and variables. If a component has JavaScript associated with it, the JavaScript filename should be included along with the source code. Layout guides should not include components in their display, but should rather use placeholder components (generally, a grey box).
|
|
702
714
|
|
|
703
715
|
# Responsive Web Design
|
|
704
716
|
|
|
705
|
-
> 'Responsive' is not a line item. It's Design
|
|
717
|
+
> 'Responsive' is not a line item. It's Design.
|
|
706
718
|
>
|
|
707
719
|
> *Jason Pamental*
|
|
708
720
|
|
|
709
|
-
Responsive web
|
|
721
|
+
[Responsive Web Design](http://alistapart.com/article/responsive-web-design) (RWD) is an approach to design that, as [Brad Frost](http://bradfrostweb.com/blog/web/responsive-web-design-missing-the-point/) eloquently puts it, attempts to "…create functional (and hopefully optimal) user experiences for a growing number of web-enabled devices and contexts." Users don't care if a site is responsive or not, what users care about is that all content is available, navigable, and predictable at the same place regardless of what device they choose to access a given site from. They care that it is fast, reliable, and accessible. [Performance](#performance) is of the utmost importance. This is especially true for mobile, where a [57% of users will abandon a site after waiting 3 seconds for a page to load](http://www.strangeloopnetworks.com/web-performance-infographics/) and 80% of those users will not return. So RWD is not about making a design squish to fit phones, tablets, and desktops; it is really a methodology to deliver content in a compelling and performant manner regardless of how a user chooses to access that content.
|
|
710
722
|
|
|
711
723
|
When starting projects, RWD should not be a line item, something to throw on at the end or not included. Responsive web design should be the standard for all projects from the beginning.
|
|
712
724
|
|
|
@@ -716,12 +728,12 @@ The methodology of RWD is a methodology of creating sites that are [Future Frien
|
|
|
716
728
|
|
|
717
729
|
1. Acknowledge and embrace unpredictability.
|
|
718
730
|
2. Think and behave in a [future-friendly way](http://futurefriend.ly/thinking.html).
|
|
719
|
-
|
|
720
|
-
|
|
721
|
-
|
|
722
|
-
|
|
723
|
-
|
|
724
|
-
|
|
731
|
+
* We can't be all things to **all** devices.
|
|
732
|
+
* Create meaningful content and services.
|
|
733
|
+
* Design services and information architecture [content](http://adactio.com/journal/4523/) and [mobile](http://www.lukew.com/ff/entry.asp?933) first
|
|
734
|
+
* Design content models to be used across presentations (website, apps, APIs, etc…)
|
|
735
|
+
* Design content models around standards to be interoperable. Focus on its long term integrity
|
|
736
|
+
* Having well-structured content is essential to art direction. Structure and store content accordingly
|
|
725
737
|
3. Help others do the same.
|
|
726
738
|
|
|
727
739
|
The set of suggestions from the Future Friendly manifesto that should not be followed as written are those dealing with device categorization and [device detection](#device-detection). The sentiment is correct, enhance any given device with a user experience that is tailored to its capabilities, but that should be done using [progressive enhancement](#progressive-enhancement) and [feature detection](#feature-detection) instead. Creating enhanced experiences this way, and encouraging users to take advantage of those enhanced experiences (as opposed to forcing them upon users based on their user agent string) allows for a more sustainable and future looking approach to delivering these experiences.
|
|
@@ -742,7 +754,7 @@ and
|
|
|
742
754
|
|
|
743
755
|
> If it's not good for the mobile user, it's not good for any user. We're the same people.
|
|
744
756
|
|
|
745
|
-
While talking about mobile, the point is as follows: users are the same regardless of the device they choose to use. Assuming a user has a different set of wants or needs exclusively based on the fact a user agent string says they are using a tablet device will always be wrong. Bring personal experience into decision making; when browsing a
|
|
757
|
+
While talking about mobile, the point is as follows: users are the same regardless of the device they choose to use. Assuming a user has a different set of wants or needs exclusively based on the fact a user agent string says they are using a tablet device will always be wrong. Bring personal experience into decision making; when browsing a website on your phone, are your wants and needs there all that different than when you do so on a desktop computer?
|
|
746
758
|
|
|
747
759
|
> Mobile users want to see our menu, hours, and delivery number. Desktop users definitely want this 1MB .png of someone smiling at a salad.
|
|
748
760
|
>
|
|
@@ -756,13 +768,13 @@ Take away what we can't know: screen size, device capabilities, concurrent activ
|
|
|
756
768
|
>
|
|
757
769
|
> *Jason Pamental*
|
|
758
770
|
|
|
759
|
-
Since about 2003, [Progressive Enhancement](http://alistapart.com/article/understandingprogressiveenhancement) has been a technique that has been used to create sites that work across any and all browsers and devices, from screen readers and
|
|
771
|
+
Since about 2003, [Progressive Enhancement](http://alistapart.com/article/understandingprogressiveenhancement) has been a technique that has been used to create sites that work across any and all browsers and devices, from screen readers and search engine spiders to the most bleeding edge alpha browsers on the highest end computers. The technique can be boiled down fairly simply: start with content that is richly marked up with semantic HTML and layer on everything else, from styling to interactions, after. By building websites content and markup first, it allows everything from the most sparse browser to the most robust one (and everything in between) to get an experience that works well for their capabilities.
|
|
760
772
|
|
|
761
773
|
When building sites, they should always be built content first. Once the content is built, each enhancement that is added, from styling to interaction, should be added with this in mind. A good experience needs to be available to all users; do not design pages for the most cutting-edge browsers, design for the content.
|
|
762
774
|
|
|
763
775
|
### Feature Detection
|
|
764
776
|
|
|
765
|
-
Progressive Enhancement isn't regulated to broad features like all styling or all interactions, but can and should be done on a feature-by-feature level as well.
|
|
777
|
+
Progressive Enhancement isn't regulated to broad features like all styling or all interactions, but can and should be done on a feature-by-feature level as well. The best way to determine what level of support a given browser has is to ask it. The most widely used feature detection library is [Modernizr](http://modernizr.com/). Modernizr is a tool built and maintained by some of the leading minds in web development today, and should be considered the go-to solution for feature detection.
|
|
766
778
|
|
|
767
779
|
Where feature detection based progressive enhancement differs from standard progressive enhancement is that where standard progressive enhancement is concerned with the whole site and the overall user experience, feature detection based progressive enhancement is generally based around a single user experience enhancement, such as a flexbox powered layout or a location based enhancement to search.
|
|
768
780
|
|
|
@@ -779,12 +791,12 @@ Advertising on responsive sites is hard. Most ads are still sold fixed size and
|
|
|
779
791
|
Fortunately, some advertising companies, such as Google, have started to offer [responsive ad units](https://support.google.com/adsense/answer/3213689?hl=en) that should be used. If asynchronous responsive ad units are not available, the following best practices should be followed:
|
|
780
792
|
|
|
781
793
|
* **Device Specific Ads** - Do not do [device detection](#device-detection) to place ads sold for "mobile" or "desktop". Instead, even though it goes against the device detection best practice, determine a screen size that constitutes the switch between "mobile" ads and "desktop" ads and swap load ads based on that size instead. Work with ad sales to stop selling ads targeted to devices and instead sell general advertising.
|
|
782
|
-
* **
|
|
794
|
+
* **Asynchronous Ads** - A [performance](#performance) best practice, do not load ads in-line, load them asynchronously
|
|
783
795
|
* **Background Ads** - Ads that are placed outside of the content area of a page, such as background ads or rail ads, encounter all of the same issues as [large background images](#outdated-ux-patterns) do and should be avoided for the same reason.
|
|
784
796
|
|
|
785
797
|
## Resolution Independence
|
|
786
798
|
|
|
787
|
-
Unlike when designing for print, there is an ever growing array of resolutions, both pixel density and available viewable area, that a single design may show up on, and designs must be made to accommodate these varying resolutions. This huge swatch of
|
|
799
|
+
Unlike when designing for print, there is an ever growing array of resolutions, both pixel density and available viewable area, that a single design may show up on, and designs must be made to accommodate these varying resolutions. This huge swatch of resolutions that need to be taken into account can be extremely daunting to work with if a design is not done [in browser](#design-in-browser). Adapting designs for the available viewable area should be handled by media queries, whereas pixel density gets handled differently depending upon the item that needs to be resolution independent.
|
|
788
800
|
|
|
789
801
|
### Media Queries
|
|
790
802
|
|
|
@@ -792,7 +804,7 @@ Media queries are a [CSS3 directive](http://www.w3.org/TR/css3-mediaqueries/) ai
|
|
|
792
804
|
|
|
793
805
|
When choosing media queries, avoid falling into the indirect [device detection](#device-detection) trap of picking values based on devices. This includes both direct correlations, like widths of an iPhone and iPad, and indirect correlations, like a generalized width of a mobile and a tablet device. Sites should not be built to devices and should likewise not have 3 or 4 values (often called breakpoints) that are used for everything. Instead, build [components](#components) that react to their own needs and [layouts](#layouts) that change and adapt based on content. It is not uncommon to have 50+ breakpoints in any given project.
|
|
794
806
|
|
|
795
|
-
Do not group like media queries together. Media queries should be written with the component or layout they are working for
|
|
807
|
+
Do not group like media queries together. Media queries should be written with the component or layout they are working for to ease maintainability and readability. Grouping media queries together makes it very hard to tweak individual media queries as needed and update styling to only specific items. Make each use of a media query meaningful and connected to the component or layout it is dealing with.
|
|
796
808
|
|
|
797
809
|
### Iconography
|
|
798
810
|
|
|
@@ -803,7 +815,7 @@ Iconography is usually an integral part of complex designs and therefore it is i
|
|
|
803
815
|
|
|
804
816
|
### Images
|
|
805
817
|
|
|
806
|
-
Images, usually either content images or background images in CSS, need to be handled slightly differently depending on the situation. For all images, if they can be expressed as an `.svg` (logos are a good place to use an `.svg`), they should be, with a [fallback](#graceful-degradation). If they cannot be, or if a fallback needs to be generated, an [optimized](http://www.smashingmagazine.com/2009/07/15/clever-png-optimization-techniques/) and compressed `.png` file should be used if transparency is needed, an [optimized](http://www.smashingmagazine.com/2009/07/01/clever-jpeg-optimization-techniques/) and compressed [progressive](http://calendar.perfplanet.com/2012/progressive-jpegs-a-new-best-practice/) `.jpg` should be used.
|
|
818
|
+
Images, usually either content images or background images in CSS, need to be handled slightly differently depending on the situation. For all images, if they can be expressed as an `.svg` (logos are a good place to use an `.svg`), they should be, with a [fallback](#graceful-degradation). If they cannot be, or if a fallback needs to be generated, an [optimized](http://www.smashingmagazine.com/2009/07/15/clever-png-optimization-techniques/) and compressed `.png` file should be used if transparency is needed, an [optimized](http://www.smashingmagazine.com/2009/07/01/clever-jpeg-optimization-techniques/) and compressed [progressive](http://calendar.perfplanet.com/2012/progressive-jpegs-a-new-best-practice/) `.jpg` should be used.
|
|
807
819
|
|
|
808
820
|
* **High Pixel Density Images** - Instead of serving different sized images for pixel densities, utilize [compressive images](http://filamentgroup.com/lab/rwd_img_compression/) to serve low weight and crisp images.
|
|
809
821
|
* **Content Images** - Content images should be loaded in using a responsive image solution. Unfortunately, there is currently no standard for responsive images, so one of two responsive image solutions should be used. The primary solution should be [Borealis](https://github.com/Snugug/borealis) which provides for element query based, lazy loaded responsive images. Because it is element query based, it may not work for all instances where an image is needed. For those instances, use [Picturefill](https://github.com/scottjehl/picturefill).
|
|
@@ -811,13 +823,13 @@ Images, usually either content images or background images in CSS, need to be ha
|
|
|
811
823
|
|
|
812
824
|
# Performance
|
|
813
825
|
|
|
814
|
-
When building modern websites, performance is a real design and development constraint and must be taken into account at every level of the development process. The reason it is a design and development constraint is fairly simple: with the explosion of an everything-
|
|
826
|
+
When building modern websites, performance is a real design and development constraint and must be taken into account at every level of the development process. The reason it is a design and development constraint is fairly simple: with the explosion of an everything-connected world and the rise of the mobile-only user, the chances that a site is going to be viewed primarily by someone sitting at a workstation with a high speed internet connection diminishes daily. This constraint isn't new either; way back in 2006, Amazon reported that a [100ms delay cost them 1% of sales](https://sites.google.com/site/glinden/Home/StanfordDataMining.2006-11-28.ppt?attredirects=0). This was before the great reach of broadband took hold and before the current mobile computing boom came full swing, which have only lessened the patience of consumers. As [Compuware reports](http://e-commercefacts.com/research/2011/07/what-usrs-want-from-mobil/19986_WhatMobileUsersWant_Wp.pdf), *75% of mobile web users expect a site to load as fast or faster* on their mobile devices as they do their desktop computers, with *60% of mobile web users leaving a site and not coming back if it takes more than 3 seconds to load, with 78% of users trying only one more time*. Moreover, if a user abandons a mobile site, *33% will go to a competitor's site*. What all this means is that **performance affects website revenue**. Google, helpfully, provides some interesting insight into how performance could have affected their 2011 revenue:
|
|
815
827
|
|
|
816
828
|
* Google made approximately [$18.8 Million](http://blog.hubspot.com/blog/tabid/6307/bid/33784/An-Industry-Breakdown-of-Google-s-100-Million-Per-Day-Advertising-Revenue-INFOGRAPHIC.aspx) per day on search advertising.
|
|
817
829
|
* A 400ms delay (less than half of a second) [reduces average number of daily searches by 0.59%](http://www.igvita.com/slides/2013/breaking-1s-mobile-barrier.pdf) (and is about twice their warning threshold)
|
|
818
830
|
* That amounts to a **daily loss of $111,000**, or about **$40.5 Million a year**
|
|
819
831
|
|
|
820
|
-
When discussing and testing performance, it is important to do both with an eye toward mobile. This means that all performance testing needs to take place on actual devices, not just emulations, and on actual networks. Many of the standards have some wiggle room, but presented are the ideals and maximums for performance standards. The ideals and maximums have been chosen with an eye towards the realities of a media heavy site, including the realities of advertising and heavy multimedia usage. As [80% of the end-user response time is
|
|
832
|
+
When discussing and testing performance, it is important to do both with an eye toward mobile. This means that all performance testing needs to take place on actual devices, not just emulations, and on actual networks. Many of the standards have some wiggle room, but presented are the ideals and maximums for performance standards. The ideals and maximums have been chosen with an eye towards the realities of a media heavy site, including the realities of advertising and heavy multimedia usage. As [80% of the end-user response time is spent on the front-end](http://developer.yahoo.com/blogs/ydn/high-performance-sites-rule-1-fewer-http-requests-7163.html), most of the performance suggestions are front-end based.
|
|
821
833
|
|
|
822
834
|
## Testing and Grading Performance
|
|
823
835
|
|
|
@@ -825,18 +837,18 @@ In addition to the below, sites should be able to hit and maintain certain perfo
|
|
|
825
837
|
|
|
826
838
|
* [Page Speed](https://developers.google.com/speed/pagespeed/insights) - 85
|
|
827
839
|
* [Web Page Test](http://www.webpagetest.org/)
|
|
828
|
-
|
|
829
|
-
|
|
830
|
-
|
|
831
|
-
|
|
832
|
-
|
|
833
|
-
|
|
834
|
-
|
|
840
|
+
* First Byte Time: 85
|
|
841
|
+
* Use persistent connection: 85
|
|
842
|
+
* Use gzip compression for transferring compressable responses: 90
|
|
843
|
+
* Compress Images: 90
|
|
844
|
+
* Use Progressive JPEGs: 90
|
|
845
|
+
* Leverage browser caching of static assets: 90
|
|
846
|
+
* Use a CDN for all static assets: 85
|
|
835
847
|
* [YSlow](http://developer.yahoo.com/yslow/) - 85
|
|
836
848
|
|
|
837
849
|
## Payload Performance
|
|
838
850
|
|
|
839
|
-
Load times, load sizes, and number of requests are
|
|
851
|
+
Load times, load sizes, and number of requests are extraordinarily important and often overlooked or left to the end of a development cycle to start to optimize. Ideal statistics are presented first, with maximums presented second that should only be broached under edge circumstances. It is always best to keep actual performance as much under these numbers as possible.
|
|
840
852
|
|
|
841
853
|
* *Time To First Byte:* **200ms** - 350ms
|
|
842
854
|
* *DOM Content Loaded:* **1000ms** - 2000ms
|
|
@@ -864,19 +876,19 @@ There are a number of optimization techniques that can be employed in order to e
|
|
|
864
876
|
|
|
865
877
|
* Avoid page redirects
|
|
866
878
|
* Provide proper headers for all files
|
|
867
|
-
|
|
868
|
-
|
|
869
|
-
|
|
870
|
-
|
|
879
|
+
* Static files (fonts, js, css) should have sufficiently long cache, at least 30 days
|
|
880
|
+
* Images should have a slightly shorter cache, at least 15 days
|
|
881
|
+
* HTML should have a short cache, around 15 minutes
|
|
882
|
+
* Internet Explorer Edge header should always be passed
|
|
871
883
|
* All JavaScript should be moved to the footer
|
|
872
884
|
* `document.write` should be avoided
|
|
873
885
|
* Images with no transparency should be served as progressive JPEGs, not as PNG files
|
|
874
886
|
* CSS and JavaScript should be minified and aggregated
|
|
875
887
|
* Reduce all blocking in the [critical path](http://sethgodin.typepad.com/seths_blog/2013/11/understanding-critical-path.html) to only page HTML and CSS
|
|
876
|
-
* Do not group CSS by media in `<link>` tags; all of the CSS gets downloaded
|
|
888
|
+
* Do not group CSS by media in `<link>` tags; all of the CSS gets downloaded anyway. Instead, reduce the number of aggregates and wrap internal CSS in media queries.
|
|
877
889
|
* Use a CDN
|
|
878
890
|
* Cache page requests
|
|
879
|
-
* Utilize [progressive enhancement](http://alistapart.com/article/understandingprogressiveenhancement) with [feature detection](http://modernizr.com/) to
|
|
891
|
+
* Utilize [progressive enhancement](http://alistapart.com/article/understandingprogressiveenhancement) with [feature detection](http://modernizr.com/) to serve only what is needed to a user
|
|
880
892
|
* Ensure that files that are only useful on particular pages only load on those pages, not all pages
|
|
881
893
|
* Always load CSS before JavaScript
|
|
882
894
|
|
|
@@ -886,7 +898,7 @@ There are a number of optimization techniques that can be employed in order to e
|
|
|
886
898
|
* Employ a Responsive Image solution. Until a standard exists, look for one based on image width over viewport size.
|
|
887
899
|
* `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
|
|
888
900
|
* `ASYNC` all ads
|
|
889
|
-
* When utilizing a CDN such as Akami, use
|
|
901
|
+
* When utilizing a CDN such as Akami, use it to serve scripts such as jQuery instead of Google's CDN as it will be faster on a cold cache
|
|
890
902
|
* Inline small but important files (generally <3Kb) to reduce HTTP requests. Aggregate other small files to reduce HTTP requests
|
|
891
903
|
|
|
892
904
|
### Experimental Optimizations
|
|
@@ -898,7 +910,7 @@ There are a number of optimization techniques that can be employed in order to e
|
|
|
898
910
|
|
|
899
911
|
# Website Building Blocks
|
|
900
912
|
|
|
901
|
-
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 browser using [Style Prototypes](https://github.com/Team-Sass/generator-style-prototype).
|
|
913
|
+
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).
|
|
902
914
|
|
|
903
915
|
## Markup
|
|
904
916
|
|
|
@@ -906,11 +918,11 @@ The core of every website is the underlying markup that, through [styling](#styl
|
|
|
906
918
|
|
|
907
919
|
### HTML Semantics
|
|
908
920
|
|
|
909
|
-
When developing websites, HTML semantic tags should be used and the HTML5 standard should be utilized. Any elements that are obsolete or deprecated as of HTML5 should not be used. For a complete listing of available HTML elements and their defined meaning, see the [Web Platform Elements Reference](http://docs.webplatform.org/wiki/html/elements). The proper semantics for each element should always be used, for instance, the `<table>` element should only be used to mark up tabular data, never for layout or lists. Elements designed for style, such as `<b>` and `<center>` should never be used and should be done through styling instead. Should confusion arise as to exactly how to use a given element, or if its definition is not clear, [HTML5 Doctor](http://html5doctor.com/)is an excellent supplementary resource to Web Platform. If support is needed for browsers that do not natively implement all semantic elements, the [HTML5 Shiv](https://github.com/aFarkas/html5shiv) should be conditionally made available.
|
|
921
|
+
When developing websites, HTML semantic tags should be used and the HTML5 standard should be utilized. Any elements that are obsolete or deprecated as of HTML5 should not be used. For a complete listing of available HTML elements and their defined meaning, see the [Web Platform Elements Reference](http://docs.webplatform.org/wiki/html/elements). The proper semantics for each element should always be used, for instance, the `<table>` element should only be used to mark up tabular data, never for layout or lists. Elements designed for style, such as `<b>` and `<center>` should never be used and should be done through styling instead. Should confusion arise as to exactly how to use a given element, or if its definition is not clear, [HTML5 Doctor](http://html5doctor.com/) is an excellent supplementary resource to Web Platform. If support is needed for browsers that do not natively implement all semantic elements, the [HTML5 Shiv](https://github.com/aFarkas/html5shiv) should be conditionally made available.
|
|
910
922
|
|
|
911
923
|
### Accessibility
|
|
912
924
|
|
|
913
|
-
The accessibility of a web site's content, including its source order without any applied CSS or JavaScript, must be taken into account. [Web Platform's Accessibility Basics](http://docs.webplatform.org/wiki/concepts/accessibility) article is a good introduction to accessibility for those unfamiliar with them. During development, websites should be checked with a screen reader to ensure they are easy to use. All developers using
|
|
925
|
+
The accessibility of a web site's content, including its source order without any applied CSS or JavaScript, must be taken into account. [Web Platform's Accessibility Basics](http://docs.webplatform.org/wiki/concepts/accessibility) article is a good introduction to accessibility for those unfamiliar with them. During development, websites should be checked with a screen reader to ensure they are easy to use. All developers using computers running OS X or have access to iOS device have access to [VoiceOver](http://www.apple.com/accessibility/osx/voiceover/) as it is installed on both operating systems. Another popular screen reading application, especially for Windows machines, is [JAWS](http://www.freedomscientific.com/products/fs/jaws-product-page.asp), although that is proprietary software and fairly expensive at that. A final resource for testing accessibility is to access a website using the [Lynx Browser](http://lynx.browser.org/). As a text-only browser, it will strip out styling and interactions, leaving raw content in the order it is presented. As an added bonus, this is also a good analogue to how crawlers and search engines view a given page.
|
|
914
926
|
|
|
915
927
|
### RDFa
|
|
916
928
|
|
|
@@ -922,7 +934,7 @@ When building responsive websites, for the time being, a non-standard meta tag n
|
|
|
922
934
|
|
|
923
935
|
`<meta name="viewport" content="initial-scale=1.0">`
|
|
924
936
|
|
|
925
|
-
There is currently a [CSS Device Adaptation](http://dev.w3.org/csswg/css-device-adapt/) development specification in the works which, when done, will move this from a markup tag to a CSS directive known as the [`@viewport`](http://dev.w3.org/csswg/css-device-adapt/#the-atviewport-rule) directive. Currently, Internet Explorer 10 and up, including on mobile devices, does not use the viewport tag, but rather the viewport directive, so both should be included on all projects.
|
|
937
|
+
There is currently a [CSS Device Adaptation](http://dev.w3.org/csswg/css-device-adapt/) development specification in the works which, when done, will move this from a markup tag to a CSS directive known as the [`@viewport`](http://dev.w3.org/csswg/css-device-adapt/#the-atviewport-rule) directive. Currently, Internet Explorer 10 and up, including on mobile devices, does not use the viewport meta tag, but rather the viewport CSS directive, so both should be included on all projects.
|
|
926
938
|
|
|
927
939
|
## Styling
|
|
928
940
|
|
|
@@ -930,11 +942,11 @@ If markup is the skeleton of a website, styling is the funny hat. Through CSS, a
|
|
|
930
942
|
|
|
931
943
|
### Base Browser Styling
|
|
932
944
|
|
|
933
|
-
Due to lack of standards around it, each browser manufacturer creates their own styling for their browser, leaving each browser's default base rendering of elements different. This, of course, causes inconsistencies across browsers that must be fixed. The two most prominent ways of doing this is through either to [reset](http://meyerweb.com/eric/tools/css/reset/) or [normalize](http://necolas.github.io/normalize.css/) the appearance of all elements. While normalization has become the go-to method for many projects recently, it
|
|
945
|
+
Due to lack of standards around it, each browser manufacturer creates their own styling for their browser, leaving each browser's default base rendering of elements different. This, of course, causes inconsistencies across browsers that must be fixed. The two most prominent ways of doing this is through either to [reset](http://meyerweb.com/eric/tools/css/reset/) or [normalize](http://necolas.github.io/normalize.css/) the appearance of all elements. While normalization has become the go-to method for many projects recently, it can introduce new issues into the cascade. This is the same reason it is recommended to create a [base component](#base-component) instead of allowing site-specific base styling to cascade throughout the entire site. Because of this, it is recommended to use the **reset** method; preferable one that discreetly targets the elements that need resets, fixes the bugs that the common Normalize.css fixes, and adds the correct baselines for HTML5 elements if they are not otherwise recognized (for instance, applying `display: block` to the `<main>` element).
|
|
934
946
|
|
|
935
947
|
### Components
|
|
936
948
|
|
|
937
|
-
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 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.
|
|
949
|
+
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.
|
|
938
950
|
|
|
939
951
|
#### Base Component
|
|
940
952
|
|
|
@@ -946,11 +958,11 @@ Layouts are the structure of an interface. Providing structure to pages and comp
|
|
|
946
958
|
|
|
947
959
|
### Aspects
|
|
948
960
|
|
|
949
|
-
Aspects are a specific implementation of a component or layout. Components and layouts always should have an aspect when used to determine what kind 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 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.
|
|
961
|
+
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.
|
|
950
962
|
|
|
951
963
|
### Elements
|
|
952
964
|
|
|
953
|
-
Elements are the individual pieces that make up a component or layout, each being component or layout specific. Think of them as individual elements (`h2`, `blockquote`, `p`, etc…) in components and regions and items in layouts. When styling an item inside components or layouts, it is strongly discouraged to use raw tag selectors and instead use element classes for each. This is to avoid any potential conflicts, such as would happen if
|
|
965
|
+
Elements are the individual pieces that make up a component or layout, each being component or layout specific. Think of them as individual HTML elements (`h2`, `blockquote`, `p`, etc…) in components and regions and items in layouts. When styling an item inside components or layouts, it is strongly discouraged to use raw tag selectors and instead use element classes for each. This is to avoid any potential conflicts, such as would happen if there would be a pager component inside of a slider component (`.slider li` and `.pager li`). The only exception to this rule is for the [base component](#base-component).
|
|
954
966
|
|
|
955
967
|
### States
|
|
956
968
|
|
|
@@ -991,13 +1003,13 @@ Components and layouts form prefixes the prefixes for aspects and elements, sepa
|
|
|
991
1003
|
<!-- Heading element of Related component -->
|
|
992
1004
|
<div class="related--heading">
|
|
993
1005
|
<!-- Tertiary Heading aspect of Typography component -->
|
|
994
|
-
|
|
995
|
-
|
|
996
|
-
|
|
997
|
-
|
|
998
|
-
|
|
999
|
-
|
|
1000
|
-
|
|
1006
|
+
<h2 class="typography--TERTIARY-HEADING">Block Title</h2>
|
|
1007
|
+
</div>
|
|
1008
|
+
<!-- Body element of Related component -->
|
|
1009
|
+
<div class="related--body">
|
|
1010
|
+
<p>Yay Copy!</p>
|
|
1011
|
+
</div>
|
|
1012
|
+
</div>
|
|
1001
1013
|
<aside>
|
|
1002
1014
|
</div>
|
|
1003
1015
|
```
|
|
@@ -1038,9 +1050,9 @@ line_comments = false
|
|
|
1038
1050
|
|
|
1039
1051
|
#### Mixin/Extend Pattern
|
|
1040
1052
|
|
|
1041
|
-
Mixins are best used when they don't needlessly duplicate the properties they write. We can do this using placeholder selectors and `@extend`. The only properties that should be
|
|
1053
|
+
Mixins are best used when they don't needlessly duplicate the properties they write. We can do this using placeholder selectors and `@extend`. The only properties that should be directly written to the selector calling a mixin should be properties that have been directly altered due to mixin arguments. Any other properties should be extended. All arguments that have default values should have those default values controlled by globally namespaced `!default` variables to make overriding those defaults easy and accessible. All mixins that provide extends should also have an `$extend` optional argument, ideally as its last argument, also globally defaulted.
|
|
1042
1054
|
|
|
1043
|
-
Mixins should also be divided up by purpose. While an omni mixin may be easier to write, having smaller mixins will make maintaining and using
|
|
1055
|
+
Mixins should also be divided up by purpose. While an omni mixin may be easier to write, having smaller mixins will make maintaining and using said mixins, as well as changing discrete parts of a rendered component, easier to do.
|
|
1044
1056
|
|
|
1045
1057
|
Let's take a look at a typical message component mixin as an example of how to re-write it using our mixin/extend pattern.
|
|
1046
1058
|
|
|
@@ -1117,12 +1129,12 @@ $message-extend: true !default;
|
|
|
1117
1129
|
@if not $extend {
|
|
1118
1130
|
box-sizing: border-box;
|
|
1119
1131
|
padding: $padding;
|
|
1120
|
-
|
|
1132
|
+
|
|
1121
1133
|
width: $width;
|
|
1122
1134
|
margin: 0 auto;
|
|
1123
|
-
|
|
1124
|
-
// Border's color is based off of the `color` property, so we can write valid
|
|
1125
|
-
// shorthand without the color. Border options aren't dynamic to clearly show a
|
|
1135
|
+
|
|
1136
|
+
// Border's color is based off of the `color` property, so we can write valid
|
|
1137
|
+
// shorthand without the color. Border options aren't dynamic to clearly show a
|
|
1126
1138
|
// succinctly show this short hand method.
|
|
1127
1139
|
border: 2px solid;
|
|
1128
1140
|
}
|
|
@@ -1196,25 +1208,25 @@ $message-extend: true !default;
|
|
|
1196
1208
|
}
|
|
1197
1209
|
```
|
|
1198
1210
|
|
|
1199
|
-
While this approach certainly requires more work up front to build the mixins and extendables, it produces much more controlled and succinct output CSS, which is what we're aiming to write.
|
|
1211
|
+
While this approach certainly requires more work up front to build the mixins and extendables, it produces much more controlled and succinct output CSS, which is what we're aiming to write.
|
|
1200
1212
|
|
|
1201
1213
|
#### Partial Structure
|
|
1202
1214
|
|
|
1203
1215
|
Sass partials are a way for us to organize our styling knowledge into maintainable and easily grokable chunks. An example Sass partial structure is available in the folder `sass`.
|
|
1204
1216
|
|
|
1205
|
-
At the root of our Sass folder is our `style.scss` file, which holds the core of our styling, and a `no-script.scss` file to provide a CSS fallback if scripting isn't available. In the `sass` folder, create an `enhancements` folder a `fallbacks` folder, and a `partials` folder for
|
|
1217
|
+
At the root of our Sass folder is our `style.scss` file, which holds the core of our styling, and a `no-script.scss` file to provide a CSS fallback if scripting isn't available. In the `sass` folder, create an `enhancements` folder, a `fallbacks` folder, and a `partials` folder for stylesheets that provide enhanced styling for powerful browsers, fallback styling for less powerful browsers, and partials for all to draw from, each respectively.
|
|
1206
1218
|
|
|
1207
|
-
Each feature
|
|
1219
|
+
Each feature being enhanced with or fallback being provided for should be named `feature.scss` and be placed into their respective folder; for instance, enhancements and fallbacks for CSS Animations would have a folder structure that looked something like `sass/enhancements/css-animations.scss` and `sass/fallbacks/css-animations.scss`.
|
|
1208
1220
|
|
|
1209
|
-
The `partials` directory should be divided up into 3 sub directories, `global`, `components`, and `layouts`. Inside of `global`,
|
|
1221
|
+
The `partials` directory should be divided up into 3 sub directories, `global`, `components`, and `layouts`. Inside of `global`, there should be a folder a piece for `variables`, `functions`, `mixins`, and `extendables`, with partials to match. Inside each of those folders should go partials whose content should be made available globally and aren't component specific. For instance, global color and typographic variables, background/text color contrast mixins, ligature extendables, etc…
|
|
1210
1222
|
|
|
1211
|
-
Both
|
|
1223
|
+
Both components and layouts should be built using a similar partial structure, henceforth known as the component partial structure. Each component should have a partial and matching folder, and inside that folder a partial a piece for `variables`, `functions`, `mixins`, and `extendables`. Each of these partials should hold styling knowledge specific to that component; for instance, `variables` could have color variables specific to that component, but the color it is set to should come from the global color partial. An example of this can be seen in the example `sass` folder.
|
|
1212
1224
|
|
|
1213
1225
|
The Import Once extension should be utilized to prevent duplication of selectors for extendable classes. Mixins should share their naming convention with the object they are used to style.
|
|
1214
1226
|
|
|
1215
1227
|
#### Variable Naming
|
|
1216
1228
|
|
|
1217
|
-
Global, private variables (ones that users should not touch but are needed to hold information for functions or mixins) should start with a capital letter as Sass variables are case sensitive.
|
|
1229
|
+
Global, private variables (ones that users should not touch but are needed to hold information for functions or mixins) should start with a capital letter as Sass variables are case sensitive.
|
|
1218
1230
|
|
|
1219
1231
|
## Interaction
|
|
1220
1232
|
|
|
@@ -1232,11 +1244,11 @@ A most reasonable approach to JavaScript is the [Airbnb JavaScript Style Guide](
|
|
|
1232
1244
|
var intro = 'Once upon a time, ',
|
|
1233
1245
|
$princess = $('#princess'),
|
|
1234
1246
|
$button = $('#button');
|
|
1235
|
-
|
|
1247
|
+
|
|
1236
1248
|
function fairytale(name) {
|
|
1237
1249
|
$princess.html(intro + name + '…');
|
|
1238
1250
|
}
|
|
1239
|
-
|
|
1251
|
+
|
|
1240
1252
|
$button.click(function() {
|
|
1241
1253
|
fairytale($princess.text());
|
|
1242
1254
|
});
|
|
@@ -1248,10 +1260,10 @@ A most reasonable approach to JavaScript is the [Airbnb JavaScript Style Guide](
|
|
|
1248
1260
|
|
|
1249
1261
|
When building site, very often a point will come when a decision must be made as to if a certain JavaScript library, plugin, or framework should be used. In addition to evaluating 3rd party scripts based on the quality of their code and their adherence to the JavaScript Style Guide, the following questions should be considered:
|
|
1250
1262
|
|
|
1251
|
-
* Is the added functionality worth the weight? A lot can be accomplished with very little in JavaScript. If a minified version of a script is larger than 5KB, seriously consider if everything that it offers is needed or if something smaller and lighter weight can be just as effective. Is a 21.5KB slider library plus the weight of jQuery really
|
|
1263
|
+
* Is the added functionality worth the weight? A lot can be accomplished with very little in JavaScript. If a minified version of a script is larger than 5KB, seriously consider if everything that it offers is needed or if something smaller and lighter weight can be just as effective. Is a 21.5KB slider library plus the weight of jQuery really worth the precious few bytes and HTTP requests needed for a fast and performant site?
|
|
1252
1264
|
* If the script builds off of another framework, such as a jQuery Plugin, examine the problem and determine if writing a custom solution can be as effective and lighter. Not everything needs to be a jQuery Plugin.
|
|
1253
1265
|
* If a script does not come with a minified version, determine if it can be minified. All scripts should be minified, so if a script being evaluated cannot, that should be taken into consideration.
|
|
1254
|
-
* 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.
|
|
1266
|
+
* 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.
|
|
1255
1267
|
* 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?
|
|
1256
1268
|
|
|
1257
1269
|
# License and Acknowledgements
|
|
@@ -1267,4 +1279,4 @@ One of the primary goals of North was to create a set of development standards t
|
|
|
1267
1279
|
* [Nicole Henninger](https://github.com/nikkiana)
|
|
1268
1280
|
* [Marianne Maguire Flanagan](http://www.linkedin.com/in/mariannemaguire)
|
|
1269
1281
|
* [Miguel Blanco](http://www.mikho.com/)
|
|
1270
|
-
* [Adam Asch](http://www.linkedin.com/pub/adam-asch/2/135/973)
|
|
1282
|
+
* [Adam Asch](http://www.linkedin.com/pub/adam-asch/2/135/973)
|
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.1.
|
|
10
|
-
DATE = "2013-12-
|
|
9
|
+
VERSION = "0.1.1"
|
|
10
|
+
DATE = "2013-12-31"
|
|
11
11
|
end
|
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.1.
|
|
4
|
+
version: 0.1.1
|
|
5
5
|
platform: ruby
|
|
6
6
|
authors:
|
|
7
7
|
- Sam Richard
|
|
8
8
|
autorequire:
|
|
9
9
|
bindir: bin
|
|
10
10
|
cert_chain: []
|
|
11
|
-
date: 2013-12-
|
|
11
|
+
date: 2013-12-31 00:00:00.000000000 Z
|
|
12
12
|
dependencies:
|
|
13
13
|
- !ruby/object:Gem::Dependency
|
|
14
14
|
name: sass
|