<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>The Design State &#187; usability</title>
	<atom:link href="http://thedesignstate.com/tag/usability/feed/" rel="self" type="application/rss+xml" />
	<link>http://thedesignstate.com</link>
	<description>A weblog about government web design.</description>
	<lastBuildDate>Fri, 30 Jul 2010 10:52:59 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
		<item>
		<title>Writing for Government Websites</title>
		<link>http://thedesignstate.com/2009/03/28/writing-for-government-websites/</link>
		<comments>http://thedesignstate.com/2009/03/28/writing-for-government-websites/#comments</comments>
		<pubDate>Sat, 28 Mar 2009 17:55:32 +0000</pubDate>
		<dc:creator>Adam Harvey</dc:creator>
				<category><![CDATA[Customer Service]]></category>
		<category><![CDATA[usability]]></category>
		<category><![CDATA[jakob nielsen]]></category>
		<category><![CDATA[writing]]></category>

		<guid isPermaLink="false">http://thedesignstate.com/?p=171</guid>
		<description><![CDATA[If you want to know how folks read webpages, Jakob Nielsen will tell you right away: They don&#8217;t. The average user skims and scans the pages they visit in order to determine whether the page content is relevant to their interests. The point: cut to the chase. No one wants to read mission statements, statements [...]]]></description>
			<content:encoded><![CDATA[<p>If you want to know how folks read webpages, <a href="http://www.useit.com/alertbox/9710a.html">Jakob Nielsen will tell you right away</a>: They don&#8217;t. The average user skims and scans the pages they visit in order to determine whether the page content is relevant to their interests. The point: <a href="http://www.useit.com/alertbox/intro-text.html">cut to the chase</a>. No one wants to read mission statements, statements from the director, or anything that doesn&#8217;t help direct them to the content they are looking for.</p>
<p>If you&#8217;re in Washington DC the week of April 5th &#8211; 10th, <a href="http://www.nngroup.com/events/washington_dc/agenda.html">you can take Jakob Nielsen&#8217;s class on writing for the web</a>.</p>
<p><a href="http://www.nngroup.com/">They&#8217;ll also be in London, San Francisco and Sydney this year</a>, but if you can&#8217;t make it to any of these conferences, you can always read through the section on his website devoted to <a href="http://www.useit.com/papers/webwriting/">Writing for the Web</a>.</p>
<p>I tried to make this post short, so you wouldn&#8217;t skim it. Did you?</p>
]]></content:encoded>
			<wfw:commentRss>http://thedesignstate.com/2009/03/28/writing-for-government-websites/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Accessible Accessibility Statements</title>
		<link>http://thedesignstate.com/2008/11/19/accessible-accessibility-statements/</link>
		<comments>http://thedesignstate.com/2008/11/19/accessible-accessibility-statements/#comments</comments>
		<pubDate>Wed, 19 Nov 2008 22:45:43 +0000</pubDate>
		<dc:creator>Adam Harvey</dc:creator>
				<category><![CDATA[Accessibility]]></category>
		<category><![CDATA[tutorials]]></category>
		<category><![CDATA[usability]]></category>
		<category><![CDATA[Tutorial]]></category>

		<guid isPermaLink="false">http://thedesignstate.com/?p=100</guid>
		<description><![CDATA[[Updated on 26 May 2009] What&#8217;s the good of having an accessibility statement on your website if a user who is using a text only browser or screen reader can&#8217;t find it right away? In other words, why bury all of the usability cues that you&#8217;ve provided somewhere on the page so that it is [...]]]></description>
			<content:encoded><![CDATA[<p>[<strong>Updated on 26 May 2009</strong>] What&#8217;s the good of having an accessibility statement on your website if a user who is using a text only browser or screen reader can&#8217;t find it right away? In other words, why bury all of the usability cues that you&#8217;ve provided somewhere on the page so that it is too late to do any good when a user finally stumbles across it?</p>
<p>This hide-and-seek is something I&#8217;ve noticed across a lot of sites with accessibility statements. These statements are by no means ubiquitous, so even if I&#8217;m trained to look for one I&#8217;m probably going to stop looking altogether after going to the hundredth site that doesn&#8217;t have one. Thankfully, the solution is one that is blindingly obvious once you think of it, and quite easy to implement.</p>
<p>If you look at <a href="http://www.diveintomark.com/">Mark Pilgrim</a>&#8216;s great accessibility resource, <a href="http://diveintoaccessibility.org/">Dive Into Accessibility</a>, with the stylesheet turned off, you&#8217;ll see a link near the top that says &#8220;Skip to Navigation.&#8221; This link is hidden by the <acronym title="Cascading Style Sheet">CSS</acronym>, so folks with regular browsers won&#8217;t see it. This navigation aid is supposed to make the site easier to use for the kind of people who need more accessible websites. So if you&#8217;re on a site that has an accessibility statement, you&#8217;re probably also on a site that has a hidden &#8220;Skip to&#8221; link or two. The markup is usually some variation of this:</p>
<p><code>&lt;h1 class="title"&gt;<br />
&lt;a href="/" accesskey="1"&gt;Dive Into Accessibility&lt;/a&gt;<br />
&lt;/h1&gt;<br />
&lt;p&gt;30 days to a more accessible web site&lt;/p&gt;<br />
<strong>&lt;a class="skip" href="#startnavigation"&gt;Skip to navigation&lt;/a&gt;</strong></code></p>
<p>and the <acronym title="Cascading Style Sheet">CSS</acronym> to hide it from view:</p>
<p><code>.divider, .invisibletitle, a.skip {<br />
display: none;<br />
}</code></p>
<p><ins datetime="2009-05-26T22:22:21+00:00"><strong>Update</strong>: Based on the post <a href="http://www.456bereastreet.com/archive/200905/hiding_with_css_problems_and_solutions/">Hiding with CSS: Problems and Solutions</a> from Roger Johansson, it turns out using display: none; will hide elements even from screen readers. The alternative is to use the off-left CSS hack:</p>
<p><code><br />
.divider, .invisibletitle, a.skip {<br />
position:absolute;<br />
left:-9999px;<br />
}</code></p>
<p>which is definitely hacky, but gets the job done, without breaking anything.</ins></p>
<p>If you try to find the accessibility statement, and you&#8217;re looking at the page without the benefit of layout from the stylesheet, the link to it is way down at the bottom in the site links, after all of the content and the navigation. There&#8217;s already a link up top to assist in jumping past the content to the navigation, so why not use that hidden space to invite the user to read the accessibility statement first thing? Here&#8217;s the additional markup:</p>
<p><code>&lt;h1 class="title"&gt;<br />
&lt;a href="/" accesskey="1"&gt;Dive Into Accessibility&lt;/a&gt;<br />
&lt;/h1&gt;<br />
&lt;p&gt;30 days to a more accessible web site&lt;/p&gt;<br />
<strong>&lt;a class="skip" title="Accessibility features of this site" href="/accessibility_statement.html"&gt;Please take a moment to review the accessibility features of this site.&lt;/a&gt;</strong><br />
&lt;a class="skip" href="#startnavigation"&gt;Skip to navigation&lt;/a&gt;</code></p>
<p><span lang="fr">Voilà</span>, the user gets an immediate prompt that you&#8217;ve taken the time to make the site easier for them to use. Now I&#8217;ve just got to go back and put this in to all of the old sites I&#8217;ve worked on.</p>
]]></content:encoded>
			<wfw:commentRss>http://thedesignstate.com/2008/11/19/accessible-accessibility-statements/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Gerry McGovern&#8217;s Driving License</title>
		<link>http://thedesignstate.com/2008/11/11/gerry-mcgoverns-driving-license/</link>
		<comments>http://thedesignstate.com/2008/11/11/gerry-mcgoverns-driving-license/#comments</comments>
		<pubDate>Tue, 11 Nov 2008 13:37:16 +0000</pubDate>
		<dc:creator>Adam Harvey</dc:creator>
				<category><![CDATA[Case Studies]]></category>
		<category><![CDATA[usability]]></category>
		<category><![CDATA[case study]]></category>
		<category><![CDATA[gerry mcgovern]]></category>

		<guid isPermaLink="false">http://thedesignstate.com/?p=62</guid>
		<description><![CDATA[Way back in 2004, Gerry McGovern, the guy who wrote Killer Web Content, tried to renew his driver&#8217;s license online. Here&#8217;s a list of some of the issues he ran into at the time: Conflicting information; Too much information; Too little information; Unnecessary information; Poorly scanned documents; Confusing terminology; Unavailable websites; Too many mouse clicks; [...]]]></description>
			<content:encoded><![CDATA[<p>Way back in 2004, <a href="http://www.gerrymcgovern.com/">Gerry McGovern</a>, the guy who wrote <a href="http://www.gerrymcgovern.com/killer-web-content.htm">Killer Web Content</a>, tried to renew his driver&#8217;s license online. Here&#8217;s a list of some of the issues he ran into at the time:</p>
<ul>
<li>Conflicting information;</li>
<li>Too much information;</li>
<li>Too little information;</li>
<li>Unnecessary information;</li>
<li>Poorly scanned documents;</li>
<li>Confusing terminology;</li>
<li>Unavailable websites;</li>
<li>Too many mouse clicks; and</li>
<li>A &#8220;simple&#8221; 10-page online form.</li>
</ul>
<p>Do any of these sound familiar? They&#8217;re mostly fundamental usability errors due to the website managers</p>
<blockquote><p>&#8220;&#8230;thinking that something is better than nothing. Many managers see a website as a project. They measure success based on things done. The website has an online application form, it has a search engine, and it has content. The form and search engine may not work well, the content may be badly written, but that&#8217;s not what&#8217;s important. What is important is that the project is completed.</p>
<p>No manager sets out to design a bad website. The problem is that too many managers view content as a commodity instead of the critical asset that it is.&#8221;</p>
<p><cite><a href="http://www.gerrymcgovern.com/nt/2004/nt_2004_10_18_egovernment3.htm">E-Government: No website is better than a bad one</a> 18 October 2004</cite></p></blockquote>
<p>Gerry went online to renew his driving license, found the correct form (which he downloaded but found to be a bad scan of a hard copy) and was told to call his local authority (which is actually called a council) to see if they accept forms downloaded from the web, found his council&#8217;s website (which was down), called another council that might also work in his case and was told that this council handled the driving licenses for the one whose website was down. Then he saw a link to a simple online form which happened to be a 10-page version of the one page badly scanned hard copy he&#8217;d downloaded before, and then on page 9 of that form, he discovered that it wasn&#8217;t an online application at all, but was going to print out the one page form he&#8217;d downloaded earlier. This is due to the fact the the driving license application requires a physical signature, a couple of photographs, a medical report and some other stuff to be mailed in to the local office.</p>
<p>If it was frustrating to read that, imagine how much easier it would have been to have found the following information on the first page of your search:</p>
<blockquote><p>To renew your driving license, please ring your local county council office. A contact list follows.</p>
<p><cite><a href="http://www.gerrymcgovern.com/nt/2004/nt_2004_10_18_egovernment3.htm">E-Government: No website is better than a bad one</a> 18 October 2004</cite></p></blockquote>
<p>While Gerry talks about this case-study in terms of the failure of the content, it&#8217;s actually a failure of the entire process that any eGovernment site or application should go through. There&#8217;s no indication time or care was spent in planning, implementing or testing any part of the process of renewing a driving license. In the private-sector such poorly executed projects would destroy the reputation of any business that provided them, but there is little impetus to strive for excellent usability, thorough planning and implementation in a government design shop. The jobs are safe, the money is guaranteed and there is usually such a high workload that the time simply isn&#8217;t there to give each site or application the care it deserves.</p>
<p>EGovernment services (such as driving license renewal) can be improved simply by sitting down with the developers and designers before the project starts and having a discussion about all the ways that the website or application can be simplified for the user. Getting everyone together and starting the conversation might seem a bit like cat herding, but it is sure to save time, money and end-user frustration in the long run.</p>
<p>Articles referenced in this post:</p>
<ol>
<li><a href="http://www.gerrymcgovern.com/nt/2004/nt_2004_10_04_egovernment1.htm">Renewing my driving license online in 50 tortuous steps: Part 1</a></li>
<li><a href="http://www.gerrymcgovern.com/nt/2004/nt_2004_10_11_egovernment2.htm">Renewing my driving license online: a Kafkaesque experience: Part 2</a></li>
<li><a href="http://www.gerrymcgovern.com/nt/2004/nt_2004_10_18_egovernment3.htm">E-Government: No website is better than a bad one</a></li>
</ol>
]]></content:encoded>
			<wfw:commentRss>http://thedesignstate.com/2008/11/11/gerry-mcgoverns-driving-license/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>
