Permalink
Browse files

Use spaced em dashes instead of hyphens

The choice between spaced and unspaced, or between em and en dashes,
is a question of style, but hyphens are wrong.
  • Loading branch information...
1 parent 3d30f78 commit 7cba760949274ccd8cf004377d9895eebeb16b4e @tomstuart tomstuart committed Apr 5, 2012
Showing with 19 additions and 19 deletions.
  1. +18 −18 index.html
  2. +1 −1 styleguide.html
View
@@ -93,9 +93,9 @@ <h1 id="first">Start with needs*</h1>
<div class="outline">
<p>
The design process must start with identifying and thinking about real
- user needs. We should design around those - not around the way the
+ user needs. We should design around those not around the way the
‘official process’ is at the moment. We must understand those needs thoroughly
- - interrogating data, not just making assumptions - and we should
+ interrogating data, not just making assumptions and we should
remember that what users ask for is not always what they need.</p>
</div>
@@ -152,8 +152,8 @@ <h1 id="second">Do less</h1>
<div class="outline">
<p>Government should only do what only government can do. If someone else
- is doing it - link to it. If we can provide resources (like <a href="http://en.wikipedia.org/wiki/Application_programming_interface">APIs</a>)
- that will help other people build things - do that. We should
+ is doing it link to it. If we can provide resources (like <a href="http://en.wikipedia.org/wiki/Application_programming_interface">APIs</a>)
+ that will help other people build things do that. We should
concentrate on the irreducible core.</p>
</div>
@@ -193,17 +193,17 @@ <h1 id="second">Do less</h1>
<h1 id="third">Design with data</h1>
<div class="outline">
- <p>Normally, we’re not starting from scratch - users are already using
+ <p>Normally, we’re not starting from scratch users are already using
our services. This means we can learn from real world behaviour. We
should do this, but we should make sure we continue this into the
- build and development process - prototyping and testing with real
+ build and development process prototyping and testing with real
users on the live web. We should understand the desire paths of how we are designing with data and use
them in our designs.</p>
</div>
<section class="why">
<div class="content">
- <p>This is the great advantage of digital services - we can watch and
+ <p>This is the great advantage of digital services we can watch and
learn from user behaviour, shaping the system to fit what people
naturally choose to do rather than bending them to a system we’ve
invented.</p>
@@ -250,13 +250,13 @@ <h1 id="fourth">Do the hard work to make it simple</h1>
<div class="outline">
<p>Making something look simple is easy; making something simple to use
- is much harder - especially when the underlying systems are complex -
+ is much harder especially when the underlying systems are complex
but that’s what we should be doing.</p>
</div>
<section class="why">
<div class="content">
- <p>With great power comes great responsibility - very often people have
+ <p>With great power comes great responsibility very often people have
no choice but to use our services. If we don’t work hard to make them simple and
usable we’re abusing that power, and wasting people’s time.</p>
</div>
@@ -300,7 +300,7 @@ <h1 id="fifth">Iterate. Then iterate again.</h1>
<p>Iteration reduces risk. It makes big failures unlikely and turns small
failures into lessons. This avoids the 200 page spec document
which can turn into a bottleneck. This, again, is the core advantage of
- digital: we’re not building bridges - things can be undone.</p>
+ digital: we’re not building bridges things can be undone.</p>
</div>
</section>
@@ -371,14 +371,14 @@ <h1 id="sixth">Build for inclusion</h1>
<div class="outline">
<p>Accessible design is good design. We should build a product that’s as
inclusive, legible and readable as possible. If we have to sacrifice
- elegance - so be it. We shouldn’t be afraid of the obvious, shouldn’t
+ elegance so be it. We shouldn’t be afraid of the obvious, shouldn’t
try to reinvent web design conventions and should set expectations
clearly.</p>
</div>
<section class="why">
<div class="content">
- <p>We’re designing for the whole country - not just the ones who are used
+ <p>We’re designing for the whole country not just the ones who are used
to using the web. In fact, the people who most need our services are
often the people who find them hardest to use. If we think about those
people at the beginning we should make a better site for everyone.</p>
@@ -571,7 +571,7 @@ <h1 id="eighth">Build digital services, not websites</h1>
<section class="why">
<div class="content">
<p>We shouldn’t be about websites, we should be about digital services.
- Right now, the best way to deliver digital services is via the web -
+ Right now, the best way to deliver digital services is via the web
but that might change, and sooner than we might expect.</p>
</div>
</section>
@@ -601,7 +601,7 @@ <h1 id="ninth">Be consistent, not uniform</h1>
<div class="outline">
<p>Wherever possible we should use the same language and the same design
- patterns &ndash; this helps people get familiar with our services. But, when
+ patterns this helps people get familiar with our services. But, when
this isn’t possible, we should make sure our underlying approach is
consistent. So our users will have a reasonable chance of guessing
what they’re supposed to do.</p>
@@ -613,7 +613,7 @@ <h1 id="ninth">Be consistent, not uniform</h1>
services by rote. We can’t imagine every scenario and write rules for
it. Every circumstance is different and should be addressed on its own
terms. What unites things, therefore, should be a consistent approach
- - one that users will hopefully come to understand and trust - even as
+ one that users will hopefully come to understand and trust even as
we move into new digital spaces.</p>
</div>
</section>
@@ -649,7 +649,7 @@ <h1 id="tenth">Make things open: it makes things better</h1>
<p>We should share what we’re doing whenever we can. With colleagues,
with users, with the world. Share code, share designs, share ideas,
share intentions, share failures. The more eyes there are on a service
- the better it gets - howlers get spotted, better alternatives get
+ the better it gets howlers get spotted, better alternatives get
pointed out, the bar gets raised.</p>
</div>
@@ -658,7 +658,7 @@ <h1 id="tenth">Make things open: it makes things better</h1>
<p>Partly because much of what we’re doing is only possible because of
open source code and the generosity of the web design community. So we
should pay that back. But mostly because more openness makes for
- better services - better understood and better scrutinised. If we give
+ better services better understood and better scrutinised. If we give
away our code, we’ll be repaid in better code. That’s why we’re giving
away all this...</p>
</div>
@@ -735,7 +735,7 @@ <h1 id="tenth">Make things open: it makes things better</h1>
<p class="status tried">Tried &amp; tested</p>
</header>
<div class="caption">
- <p>Tools like <a href="http://www.github.com">Github</a> are useful because people can make ‘<a href="http://help.github.com/send-pull-requests/">pull requests</a>’ to help you improve your code. Find out more in our blog post - <a href="http://digital.cabinetoffice.gov.uk/2012/02/02/gov-uk-truly-open-platform/">GOV.UK - a truly open and collaborative platform</a></p>
+ <p>Tools like <a href="http://www.github.com">Github</a> are useful because people can make ‘<a href="http://help.github.com/send-pull-requests/">pull requests</a>’ to help you improve your code. Find out more in our blog post <a href="http://digital.cabinetoffice.gov.uk/2012/02/02/gov-uk-truly-open-platform/">GOV.UK - a truly open and collaborative platform</a></p>
</div>
</article>
<article class="process no-image">
View
@@ -55,7 +55,7 @@
<p>Our analysis of our content needs spawned a suite of content formats. These allow us to effectively answer user needs by designing content that’s clear and rummageable and gives people confidence that they’ve got the right answer.</p>
</div>
<h2>Guides</h2>
- <p>Our guides are a set of related information about a specific topic (eg <a href="https://www.gov.uk/council-housing"> Council housing</a>) or life event (eg <a href="https://www.gov.uk/after-a-death"> After someone dies</a>). One guide has one or more related ‘parts’ - people can see the edges of a topic and choose to read the whole lot or simply home in on a specific element.</p>
+ <p>Our guides are a set of related information about a specific topic (eg <a href="https://www.gov.uk/council-housing"> Council housing</a>) or life event (eg <a href="https://www.gov.uk/after-a-death"> After someone dies</a>). One guide has one or more related ‘parts’ people can see the edges of a topic and choose to read the whole lot or simply home in on a specific element.</p>
<h2>Answers</h2>
<p>Our answers assume prior knowledge of a subject and answer one specific need, eg <a href="National Minimum wage rates."></a> We answer the question only and don’t crowd the answer with surplus information. We also use answers to address popular needs (eg <a href="https://www.gov.uk/child-benefit-rates">Child Benefit rates</a>). We go into <a href="https://www.gov.uk/child-benefit">detail on Child Benefit</a> in our guide.</p>
<h2>Benefits and schemes</h2>

0 comments on commit 7cba760

Please sign in to comment.