Adam SilverSharing what I've learned.2024-03-11T00:00:00+00:00https://adamsilver.io/Adam Silveradam@adamsilver.ioDon’t use paracetamol to fix bad UX2024-03-11T00:00:00+00:00https://adamsilver.io/blog/dont-use-paracetamol-to-fix-bad-ux/<p>My dad was a pharmacist.</p>
<p>Whenever I was ill, he’d tell me to take paracetamol.</p>
<p>So I did.</p>
<p>And it made me feel better.</p>
<p>But paracetamol doesn’t actually make you better. It only makes you feel better.</p>
<p><strong>It treats the symptoms, not the cause.</strong></p>
<p>For example, let’s say you have a headache because you’re dehydrated. But you don’t know you’re dehydrated so you take paracetamol. And the headache goes away.</p>
<p>But you’re still dehydrated so your headache comes back later.</p>
<p>In this case, what you needed was a glass of water.</p>
<p>You needed to treat the cause, not the symptom.</p>
<p>But the problem is that not all ailments go away instantly with a glass of water. Some ailments take longer to heal. So people take a pill, feel better and go about their life.</p>
<p>But over time this can lead to more problems.</p>
<p>I see the same thing happen all the time in UX.</p>
<p>Here’s a common problem:</p>
<ul>
<li>You have a page with a lot of content</li>
<li>Users have to wait a long time for the page to load</li>
<li>When it does load, it’s hard for users to find what they’re looking for</li>
</ul>
<p>So you think about all the ways you could simplify the long, slow, unwieldy page of content.</p>
<p>You decide to split the content into tabs.</p>
<p>Job done: the page is much cleaner.</p>
<p>But the underlying problem is still there, you’ve just relieved the symptoms.</p>
<p>And because you’ve just relieved the symptoms, you’ve made the UX even worse.</p>
<ul>
<li>Some users will fail to notice the tabs</li>
<li>Some users won’t understand how the tabs work</li>
<li>The page is slower than it was because there’s extra code for the tabs</li>
</ul>
<p>You’ve used paracetamol instead of a glass of water.</p>
<p>The actual problem is:</p>
<p><strong>There’s too much content, it’s badly organised and the server is slow.</strong></p>
<p>Here’s what you do instead:</p>
<ul>
<li>Reduce the amount of content</li>
<li>Make it clear and concise</li>
<li>Make the server fast</li>
</ul>
<p>No tabs needed.</p>
<p>But here’s the cool thing.</p>
<p>Once you stop treating the symptoms, you start solving real problems and avoid unnecessary complexity.</p>
<p>And you end up giving users great UX.</p>
<p>If you’d like to know how to treat the cause of badly designed forms, you might like my course, Form Design Mastery.</p>
<p>It’s the only place on the internet where you’ll learn how to treat forms with a glass of water, not paracetamol.</p>
<p><a href="https://formdesignmastery.com/">https://formdesignmastery.com</a></p>
Why Anthony Hobday’s sentence-style form is bad UX (and what to do instead)2024-03-07T00:00:00+00:00https://adamsilver.io/blog/why-anthony-hobdays-sentence-style-form-is-bad-ux-and-what-to-do-instead/<p>Anthony asked me to tell him why his sentence-style form is awful.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/why-anthony-hobdays-sentence-style-form-is-awful/mockup.png" alt=""><figcaption>A form to join a waiting list laid out as a sentence.</figcaption></figure>
</div>
<p>In case you didn’t know:</p>
<p>I love attacking bad UX.</p>
<p>So when I got Anthony’s message, I dashed to the computer to tap out a quick response (which I’ll share in a sec).</p>
<p>But I want to point out that most sentence-style forms (also known as natural language forms) are a lot more complicated than Anthony’s. They usually have multiple fields, longer sentences and other issues that Anthony’s design doesn’t have.</p>
<p>But his design still has plenty of issues, some of which are rarely found in other sentence-style forms.</p>
<p>I’ll also tell you what I’d do instead (the most boring, simple, obvious, uncontentious thing that gets you zero cool points but actually gives users the best UX).</p>
<p>Here goes:</p>
<h2>Issue #1: There’s more for users to read</h2>
<p>The words “Enter your” and “to” don’t add value.</p>
<p>This makes users work harder than they have to.</p>
<h2>Issue #2: The button label looks like a mistake</h2>
<p>Because the form only has one input it has to include the button to make it work as a sentence.</p>
<p>But this is unconventional, looks a bit like a mistake and is inconsistent with regular button text.</p>
<h2>Issue #3: There’s no space to show an error inline</h2>
<p>This is because the sentence layout means that showing an error would break the layout.</p>
<p>But good design accommodates different states.</p>
<h2>Issue #4: Translation can break the layout</h2>
<p>Some other languages have longer words which will break the layout.</p>
<p>But good design works for all languages.</p>
<h2>Issue #5: It’ll break on mobile</h2>
<p>This is because the button will wrap onto another line.</p>
<p>But good design works on all screen sizes.</p>
<h2>Issue #6: It uses placeholder text</h2>
<p>Placeholder text is a whole thing of it’s own but as a quick summary:</p>
<ul>
<li>it may get cropped</li>
<li>it may be mistaken for an answer</li>
<li>it’s harder to read</li>
</ul>
<p>Good design is the opposite of all 3.</p>
<h2>Issue #7: It doesn’t look like a real form</h2>
<p>While this doesn’t apply so much to Anthony’s design I wanted to mention this because most sentence-style forms don’t look like forms at all.</p>
<p>But forms should look like forms so users can recognise them as such without having to think.</p>
<p>There are many form design challenges that are complicated and need due care and attention…</p>
<p>But sentence-style forms aren’t one of them.</p>
<p>Just lay out the form normally with a:</p>
<ul>
<li>Label</li>
<li>Input</li>
<li>Button</li>
</ul>
<p>Then get back to solving real UX problems instead.</p>
<p>If you’d like to do just that, you might like my course, Form Design Mastery:</p>
<p><a href="https://formdesignmastery.com/">https://formdesignmastery.com</a></p>
Sliders degrade UX (so do this instead)2024-02-18T00:00:00+00:00https://adamsilver.io/blog/sliders-degrade-ux-so-do-this-instead/<p>My friend Victor shared this design tip on Twitter last week:</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/sliders-degrade-ux-so-do-this-instead/victor.jpeg" alt=""></figure>
</div>
<p>He said that if you put the slider values on top, your finger won’t cover them up.</p>
<p>It’s a useful tip.</p>
<p>But sliders aren’t just bad UX because your finger covers up the values. This is the least of your worries.</p>
<p>Here I’ll share why that is (plus what to do instead):</p>
<h2>Reason 1: They’re hard to control</h2>
<p>This is because it takes a lot of effort to move the slider into the position. This is even harder if you:</p>
<ul>
<li>need to be precise</li>
<li>have motor impairments</li>
<li>have ridiculously long purple nails (like my friend Rach)</li>
</ul>
<div class="image" style="max-width: 400px">
<figure><img src="https://adamsilver.io/assets/images/sliders-degrade-ux-so-do-this-instead/nails.jpeg" alt=""></figure>
</div>
<h2>Reason 2: The values cannot be clearly labelled</h2>
<p>This is because there’s limited space to fit labels in.</p>
<p>So you end up with gaps or line markers which are ambiguous and make users work harder.</p>
<h2>Reason 3: They’re hard to fit on small screens</h2>
<p>Sliders need to be big enough to interact with properly.</p>
<p>Squeezing the slider into a small space makes it even harder to use.</p>
<h2>Reason 4: They have an upper limit</h2>
<p>Sliders have an upper limit which is fine when it’s a percentage value.</p>
<p>But it doesn’t work well for values like price.</p>
<h2>Do this instead</h2>
<p>If the user needs to be precise, use two inputs:</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/sliders-degrade-ux-so-do-this-instead/inputs.png" alt=""><figcaption>Left: Slide with 2 handles for min and max price. Right: 2 separate inputs for min and max price.</figcaption></figure>
</div>
<p>If the user does not need to be precise, use checkboxes:</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/sliders-degrade-ux-so-do-this-instead/checkboxes.png" alt=""><figcaption>Left: Slide with 2 handles for min and max price. Right: 4 checkboxes with different price ranges.</figcaption></figure>
</div>
<p>Both patterns are easy to use and work on mobile.</p>
<p>But there’s an even more important lesson here.</p>
<p>Because Victor was thoughtful, no doubt. He looked at the slider, spotted an issue and came up with better UX.</p>
<p>But improving a bad pattern doesn’t make it good. You’re usually better off finding another pattern altogether.</p>
<p>If you’d like instant access to every bad form design pattern I know and the replacement for each one, you might like my course, Form Design Mastery:</p>
<p><a href="https://formdesignmastery.com/">formdesignmastery.com</a></p>
3 common examples of button text that degrades UX and how to rewrite them so they’re clear2023-09-17T00:00:00+00:00https://adamsilver.io/blog/3-common-examples-of-button-text-that-degrades-ux-and-how-to-rewrite-them-so-theyre-clear/<p>A lot of designers love to save space at the cost of clarity and prioritise aesthetics over content.</p>
<p>But once you nail the foundational interaction design patterns, content is often the most important part of design.</p>
<p>Button text is a perfect example of this.</p>
<p>Once you design your buttons, it’s time to focus on the text.</p>
<p>Now on the one hand it’s so subtle that it’s barely worth discussing.</p>
<p>But on the other hand, the small details matter. And once you follow the rules it’s only slightly more effort to get it right than it is to get it wrong.</p>
<p>And yet there are a lot of badly described buttons out there.</p>
<p>Here’s 3 common examples:</p>
<h2>Example #1: “Next”</h2>
<div class="image" style="max-width: 400px">
<figure><img src="https://adamsilver.io/assets/images/3-common-examples-of-button-text-that-degrades-ux-and-how-to-rewrite-them-so-theyre-clear/next.png" alt=""><figcaption>Using a next button in a multi-step form flow</figcaption></figure>
</div>
<p>“Next” is used a lot in multi-step form flows.</p>
<p>But it’s abrupt and inconsistent with 99% of button text. As it’s not a verb it cannot be used in combination with other actions. For example, “Save and next” doesn’t make sense.</p>
<p>Use these instead:</p>
<ul>
<li>Continue</li>
<li>Save and continue</li>
</ul>
<h2>Example #2: “Done”</h2>
<div class="image" style="max-width: 400px">
<figure><img src="https://adamsilver.io/assets/images/3-common-examples-of-button-text-that-degrades-ux-and-how-to-rewrite-them-so-theyre-clear/done.png" alt=""><figcaption>Using a done button to close the edit note screen</figcaption></figure>
</div>
<p>“Done” is sometimes used at the end of journeys or on edit screens.</p>
<p>But it lacks clarity. It doesn’t say what the action is.</p>
<p>Use these instead:</p>
<ul>
<li>Return to notes</li>
<li>Close note</li>
</ul>
<h2>Example #3: “OK”</h2>
<div class="image" style="max-width: 400px">
<figure><img src="https://adamsilver.io/assets/images/3-common-examples-of-button-text-that-degrades-ux-and-how-to-rewrite-them-so-theyre-clear/ok.png" alt=""><figcaption>Using an OK button to close the dialog</figcaption></figure>
</div>
<p>“OK” is often used in dialogs and banners as a way to close them.</p>
<p>But it’s ambiguous and unclear what will happen as a result of clicking it.</p>
<p>Use these instead:</p>
<ul>
<li>Close</li>
<li>Agree and close</li>
</ul>
7 reasons to replace advanced search with filters so users can easily find what they need2023-08-20T00:00:00+00:00https://adamsilver.io/blog/7-reasons-to-replace-advanced-search-with-filters-so-users-can-easily-find-what-they-need/<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/7-reasons-to-replace-advanced-search-with-filters-so-users-can-easily-find-what-they-need/advanced-search-link.png" alt=""><figcaption>Link to advanced search under the search box</figcaption></figure>
</div>
<p>I started making websites over 20 years ago.</p>
<p>Advanced search is probably one of the earliest patterns I remember from the early days. The pattern is a link under the search box that takes users to a page with search options.</p>
<p>How bad can something so simple be?</p>
<p>After all there’s just a link, a page and a form.</p>
<p>And yes, advanced search is certainly better than all of the other patterns I’ve roasted in the past. But in comparison to in-context filters, it gives users an unnecessarily bad experience.</p>
<p>Here’s why:</p>
<h2>Reason #1: Advanced search is long winded to use</h2>
<p>This is because the user has to navigate between the search form and the results every time they want to change their search criteria.</p>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/7-reasons-to-replace-advanced-search-with-filters-so-users-can-easily-find-what-they-need/flipflop.png" alt=""><figcaption>Moving back and forth is long winded</figcaption></figure>
</div>
<h2>Reason #2: Advanced search decreases the chance of getting results</h2>
<p>This is because every possible option is displayed even if they don’t have results.</p>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/7-reasons-to-replace-advanced-search-with-filters-so-users-can-easily-find-what-they-need/advanced-search-page.png" alt=""><figcaption>All options shown even if they’re not relevant to the current results</figcaption></figure>
</div>
<h2>Reason #3: Advanced search is more likely to make users give up</h2>
<p>This is because <a href="https://www.nngroup.com/articles/search-visible-and-simple/">not getting results the first time causes a lot of users to give up</a>.</p>
<h2>Reason #4: The link to advanced search is hard to spot</h2>
<p>This is because the link is not prominent.</p>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/7-reasons-to-replace-advanced-search-with-filters-so-users-can-easily-find-what-they-need/advanced-search-link.png" alt=""><figcaption>The link underneath main search box is hard to spot</figcaption></figure>
</div>
<h2>Reason #5: The advanced search options lack context</h2>
<p>This is because the form is shown on a separate page away from the list.</p>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/7-reasons-to-replace-advanced-search-with-filters-so-users-can-easily-find-what-they-need/advanced-search-page.png" alt=""><figcaption>It’s not clear what the options relate to</figcaption></figure>
</div>
<h2>Reason #6: Advanced search increases cognitive load</h2>
<p>This is because all possible options are shown in one big form.</p>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/7-reasons-to-replace-advanced-search-with-filters-so-users-can-easily-find-what-they-need/advanced-search-page.png" alt=""><figcaption>Displaying all the options in one form increases cognitive load</figcaption></figure>
</div>
<h2>Reason #7: Advanced search may cause users to fill out all the fields</h2>
<p>This is because most users expect every form field to be required unless marked optional (which makes reason #3 worse).</p>
<h2>Use filters instead</h2>
<p>Because they solve every problem that advanced search creates.</p>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/7-reasons-to-replace-advanced-search-with-filters-so-users-can-easily-find-what-they-need/filters.png" alt=""><figcaption>Filters in context of the results</figcaption></figure>
</div>
3 questions to evaluate design patterns and avoid unnecessary work that degrades UX2023-08-06T00:00:00+00:00https://adamsilver.io/blog/3-questions-to-evaluate-design-patterns-and-avoid-unnecessary-work-that-degrades-ux/<p>There’s a new form design trend going around:</p>
<p>Buttons inside inputs.</p>
<p>Anthony Hobday mentioned it by asking his audience if there was any significant difference in usability between these 3 designs:</p>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/3-questions-to-evaluate-design-patterns-and-avoid-unnecessary-work-that-degrades-ux/designs.png" alt="3 layouts for a single-input form"><figcaption>3 different layouts for an input and button combination</figcaption></figure>
</div>
<ol>
<li>Button inside the input</li>
<li>Button touching input</li>
<li>Button next to the input with space between</li>
</ol>
<p>Guess which one I recommend.</p>
<p>One thing I know is that it’s hard to convince fancy-pants designers to practice boring design. And I hear the same from other UXers all the time.</p>
<p>It’s a tough one.</p>
<p>But when it comes to the button-inside-input pattern, it’s funny because on the face of it, it’s not that fancy and it seems harmless?</p>
<p>But then again, that’s just not how I design. The idea of doing something like this, and then testing to see if it <em>doesn’t</em> degrade UX. That’s backwards.</p>
<p>Because what’s the purpose of design?</p>
<h2>The purpose of design is to solve problems</h2>
<p>Not made up “I’m bored so I’ll come up with something new” problems.</p>
<p>Real ones.</p>
<p>That’s literally what design is.</p>
<p>So then you have to question why you’d put the button inside the input in the first place. And I think you’ll find the answer is…</p>
<p>“It’s cool”.</p>
<p>It’s definitely not because the designer did research and watched people struggle when the button was separate from the input (unless of course they positioned the button miles away but that’s obviously bad design).</p>
<p>And really that’s where the story should end.</p>
<p>Because it’s not solving an actual problem.</p>
<p>But as designers we’ll be faced with these patterns in one way or another. A colleague asks for crit. Someone shares a blog post advocating the new cool thing. Etc.</p>
<p>So how can we evaluate these patterns, avoid unnecessary work and ultimately avoid patterns that degrade UX?</p>
<p>Start by asking these 3 questions:</p>
<h2>Question #1: Does research show this pattern solves a problem?</h2>
<p>This question gets to the heart of the matter.</p>
<p>Most fancy patterns have come directly out of a designer’s head. They aren’t born out of using boringly simple patterns and watching users struggle with them.</p>
<p>It’s ironic that the act of being novel is the very thing that degrades UX.</p>
<h2>Question #2: Are there any potential usability issues with this pattern?</h2>
<p>This question helps to evaluate the specific solution.</p>
<p>Does the thing look like what it is? Is it unconventional? Does it work on small screens? Does it work well for keyboard users? Etc.</p>
<p>This gives rationale against a particular design.</p>
<h2>Question #3: How much effort is it to build?</h2>
<p>This question helps to prioritise the pattern against other work.</p>
<p>If the pattern takes a lot of effort, or more effort than it should, then that’s a good reason to deprioritise it.</p>
<p>Designers should be pragmatic.</p>
<h2>Here’s my response to Anthony</h2>
<blockquote>
<p>I’d avoid anything contentious unless you want to spend time researching with a diverse set of users to prove it doesn’t degrade UX (effort and value aren’t in balance here).</p>
<p>Option 1 (button inside input) is contentious because it’s not clear where the input starts and ends. The focus outline of the input should be around the input, not the input and button. It’s also more effort to build.</p>
<p>Option 2 (button touching input) is fine as long as the button is clearly distinguishable from the input (by using different a colour perhaps).</p>
<p>Option 3 (button next to the input with space between) is best and clearly distinguishes the separate elements which do different things.</p>
<p>Bonus: lose the placeholder text as it degrades UX</p>
</blockquote>
The problem with disabling paste and what to do instead2023-08-06T00:00:00+00:00https://adamsilver.io/blog/the-problem-with-disabling-paste-and-what-to-do-instead/<p>Disabling paste is usually done in the name of security.</p>
<p>For example, let’s say the user has to type their email address twice. Using 2 separate inputs means a mismatch can be caught. But that doesn’t work if they paste an error from the first input into the second.</p>
<p>But disabling paste degrades UX and is a terrible way to stop users from making mistakes.</p>
<p>Here’s why:</p>
<h2>Problem #1: It makes the interface feel broken</h2>
<p>This is because users expect to be able to paste but instead it just gets ignored with no feedback.</p>
<div class="image" style="max-width: 600px">
<figure><video controls="">
<source src="https://adamsilver.io/assets/images/the-problem-with-disabling-paste-and-what-to-do-instead/01-broken.mp4#t=0.001" type="video/mp4">
</video><figcaption>Trying to paste into the password field gets ignored as paste is disabled</figcaption></figure>
</div>
<h2>Problem #2: It slows users down</h2>
<p>This is because the user has to type everything again from scratch.</p>
<div class="image" style="max-width: 600px">
<figure><video controls="">
<source src="https://adamsilver.io/assets/images/the-problem-with-disabling-paste-and-what-to-do-instead/02-slow.mp4#t=0.001" type="video/mp4">
</video><figcaption>User has to type the password manually because paste is disabled</figcaption></figure>
</div>
<h2>Problem #3: It increases the chance of error</h2>
<p>This is because typing manually increases the chance of a mistake.</p>
<h2>Give control and let users check answers</h2>
<p>To do this consider using:</p>
<ul>
<li>an email verification step</li>
<li>a ‘check answers’ page</li>
<li>a password reveal</li>
</ul>
5 key design system elements to build trust and maximise uptake2023-07-09T00:00:00+00:00https://adamsilver.io/blog/5-key-design-system-elements-to-build-trust-and-maximise-uptake/<p>Since 2016 I’ve used, created and contributed to multiple design systems.</p>
<p>I’ve seen what works and what doesn’t. By “doesn’t” I mean designers don’t trust it. And as a result they don’t use it.</p>
<p>When I’m feeling sassy, I call these people ‘cowboy designers’.</p>
<p>Now there are some designers that will ignore your design system no matter how good it is.</p>
<p>These people are true cowboys and they wear the hats 🤠. But most designers would prefer to use tried and tested patterns. As long as they can trust them.</p>
<p>And I’ve found that there are 5 key elements a design system needs to have in order to make it so good that designers choose it over doing their own thing.</p>
<p>Here they are:</p>
<h2>Key element #1: research findings and rationale</h2>
<p>Designers need to know they can trust a pattern.</p>
<p>If a pattern is included without research, it diminishes trust. If your component hasn’t been tested, be honest about it. Provide rationale so users can fill the gaps when they’re testing it with their users.</p>
<p>Transparency builds trust.</p>
<h2>Key element #2: usage guidance</h2>
<p>Patterns without guidance result in misuse.</p>
<p>The perfect component deployed in the wrong situation is bad. Users need to know exactly when a pattern is appropriate to use. And crucially when it’s not.</p>
<p>Context is key.</p>
<h2>Key element #3: working code</h2>
<p>Pictures of components are not components.</p>
<p>A Figma file is valuable. But without code, components need to be built from scratch. And mistakes will be made in translation.</p>
<p>Design is done when it’s actually in front of users.</p>
<h2>Key element #4: feedback channels</h2>
<p>Without a way to feedback, designers feel isolated.</p>
<p>Most designers don’t need an excuse to go off-piste and do their own thing. But making it easy to feedback makes people feel part of the design system community.</p>
<p>It’s not a community without 2-way communication.</p>
<h2>Key element #5: support channels</h2>
<p>A design system without support is a side project.</p>
<p>No matter how clear your content is, you can’t cater for everyone all the time. Without an easy way to get support, users will get stuck. And when they do, they need someone to unstick them.</p>
<p>Treat your design system like the service it is.</p>
4 design principles I use every day to avoid bad UX and create products that work for everyone2023-07-02T00:00:00+00:00https://adamsilver.io/blog/4-design-principles-i-use-every-day-to-avoid-bad-ux-and-create-products-that-work-for-everyone/<!-- Good design is hard to achieve.
One way to make it easier is by following design principles. They work by course-correcting you as you flesh out solutions to problems.
For example, -->
<p>Picture this.</p>
<p>You’re designing a form but the questions are complicated. Users need a lot of guidance to understand each question. But this makes the page long and messy.</p>
<p>You run through various patterns.</p>
<p>‘Tooltips!’, you say to yourself.</p>
<p>And that’s cool because tooltips keep things clean while allowing users to access extra information. You polish the designs, get them ready for dev and you go to bed happy.</p>
<p>At least until you do some usability testing.</p>
<p>Now picture this.</p>
<p>You’re designing a form but the questions are complicated. Users need a lot of guidance to understand each question. But this makes the page long and messy.</p>
<p>You run through various patterns.</p>
<p>‘Tooltips!’, you say to yourself.</p>
<p>But this time you have 4 design principles to course-correct any potential bad decisions at the offset. After running tooltips through each principle you realise that they fail 2 of them:</p>
<ul>
<li>Good design makes things obvious</li>
<li>Good design puts users in control</li>
</ul>
<p>This used to be a conscious process for me.</p>
<p>But now it’s subconscious.</p>
<p>And that’s because I didn’t start with design principles. The design principles emerged after watching 100s of people struggle to use the things I designed. Every struggle failed at least one principle.</p>
<p>After years of doing this, they’ve become second nature.</p>
<p>These are tried, tested and timeless.</p>
<p>Wow each of those words starts with T so they must be good.</p>
<p>Here they are:</p>
<h2>Principle #1: Good design works for everyone</h2>
<p>There are many reasons for this principle but my favourite is that designing for a minority makes things better for everyone.</p>
<p>Examples:</p>
<ul>
<li>Subtitles don’t just help deaf people; they allow people to watch a video in a loud cafe</li>
<li>Plain language isn’t just easier to read for people with low literacy; experts find it easier to read too</li>
<li>Large radio buttons don’t just help people with motor impairments; everyone finds them easier to click</li>
</ul>
<h2>Principle #2: Good design makes things obvious</h2>
<p>Chris Pratley, founder of OneNote said “You know you have a good design when people say ‘oh yeah, of course’ like the solution was obvious”.</p>
<p>Examples:</p>
<ul>
<li>Instead of using a hamburger menu, just show the navigation items and let them wrap if necessary</li>
<li>Instead of using sticky menus, just let users scroll and put calls to action in context</li>
<li>Instead of hiding hint text in tooltips, just show the hint inline</li>
</ul>
<h2>Principle #3: Good design puts users in control</h2>
<p>Design for real life. People prefer to interact in different ways. And we should design for both an idealised work flow as well as when things don’t go to plan.</p>
<p>Examples:</p>
<ul>
<li>Instead of expecting users to fill out a form in one go, expect them to get interrupted and let them save and finish later</li>
<li>Instead of showing a menu on hover, show it on click</li>
<li>Instead of infinite scrolling, let users paginate</li>
</ul>
<h2>Principle #4: Good design is lightweight</h2>
<p>According to Google increasing the page load time from 1 to 3 seconds increases the chance of abandonment by 32%. Go to 6 seconds and the chance goes up by 106%. Slow interfaces cause stress and feel untrustworthy.</p>
<p>Examples:</p>
<ul>
<li>Kill the background video and prioritise the content and flow</li>
<li>Kill those tooltips and reduce the content to its irreducible core</li>
<li>Kill that carousel and show the content inline</li>
</ul>
The problem with input masks and what to do instead2023-06-25T00:00:00+00:00https://adamsilver.io/blog/the-problem-with-input-masks-and-what-to-do-instead/<p>In 2010 I discovered input masks.</p>
<p>They seemed like a smart way to prevent errors. Because they help users follow a format. And they do so without taking up space.</p>
<p>But the truth is that this fancy pattern degrades UX.</p>
<p>Here’s why:</p>
<h2>Problem #1: They’re confusing</h2>
<p>For example, the cursor advances automatically to the next position. And placeholder characters can’t be deleted.</p>
<div class="image">
<figure><video controls="">
<source src="https://adamsilver.io/assets/images/the-problem-with-input-masks-and-what-to-do-instead/input-masks--confusing.mp4#t=0.001" type="video/mp4">
</video><figcaption>Telephone input mask replacing characters and advancing to the next position automatically</figcaption></figure>
</div>
<h2>Problem #2: They may be mistaken for an actual answer</h2>
<p>This is because the mask looks like an input causing using to submit the form with errors.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-input-masks-and-what-to-do-instead/filledout.png" alt="Top: input looks filled out (bad). Bottom: input looks empty (good)"><figcaption>Input masks make the input look like it’s been answered</figcaption></figure>
</div>
<h2>Problem #3: They make the interface feel broken</h2>
<p>This is because typing a restricted character gets ignored.</p>
<div class="image">
<figure><video controls="">
<source src="https://adamsilver.io/assets/images/the-problem-with-input-masks-and-what-to-do-instead/input-masks--restrictive.mp4#t=0.001" type="video/mp4">
</video><figcaption>Restricted characters get ignored without giving users any feedback</figcaption></figure>
</div>
<h2>Problem #4: The format may be unfamiliar</h2>
<p>For example, a phone number may require a country code which isn’t always expected and makes users work harder.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-input-masks-and-what-to-do-instead/unfamiliar.png" alt="Top: Phone input with placeholder showing the format (bad). Bottom: Phone input empty (good)"><figcaption>Input masks may use unfamiliar formats that don’t make sense to everyone</figcaption></figure>
</div>
<h2>Problem #5: They’re misleading and verbose in screen readers</h2>
<p>For example, they announce placeholder characters which aren’t part of the answer. And they don’t announce characters that were typed but ignored.</p>
<div class="image">
<figure><video controls="">
<source src="https://adamsilver.io/assets/images/the-problem-with-input-masks-and-what-to-do-instead/input-masks--screen-readers.mp4#t=0.001" type="video/mp4">
</video><figcaption>Voiceover announces placeholder characters. And fails to announce characters that were typed but ignored.</figcaption></figure>
</div>
<h2>Problem #6: They can break text expansion</h2>
<p>For example, using the text replacement feature on iOS, typing ‘zpho’ should be automatically replaced with my phone number. But a phone input mask will ignore it.</p>
<div class="image" style="max-width: 375px">
<figure><video controls="">
<source src="https://adamsilver.io/assets/images/the-problem-with-input-masks-and-what-to-do-instead/breaks-text-expansion.mp4#t=0.001" type="video/mp4">
</video><figcaption>Input mask ignores text expansion</figcaption></figure>
</div>
<h2>What to do instead</h2>
<ol>
<li><strong>Leave the input empty</strong> to make it obvious where the answer goes</li>
<li><strong>Let users type what they like</strong> so the interface doesn’t feel unresponsive and broken</li>
<li><strong>Allow multiple formats</strong> so users don’t have to fix something unnecessarily</li>
<li><strong>Allow users to check their answers</strong> either on a separate page or just below the field</li>
</ol>
The problem with sticky menus that appear on scroll and what to do instead2023-06-18T00:00:00+00:00https://adamsilver.io/blog/the-problem-with-sticky-menus-that-appear-on-scroll-and-what-to-do-instead/<p>I’ve previously written about the <a href="https://adamsilver.io/blog/the-problem-with-sticky-menus-and-what-to-do-instead/">problems with regular sticky menus</a>.</p>
<p>In response to those issues, some people suggest showing and hiding the menu as the user scrolls up and down.</p>
<div class="image">
<figure><video controls="">
<source src="https://adamsilver.io/assets/images/the-problem-with-sticky-menus-that-appear-on-scroll-and-what-to-do-instead/bondir.mp4#t=0.001" type="video/mp4">
</video><figcaption>Bondir’s sticky menu appears and disappears as the user scrolls</figcaption></figure>
</div>
<p>This seems smart because:</p>
<ul>
<li>the menu gets out of the way to allow users to focus on the content</li>
<li>it allows users to access the menu without having to scroll back to the top</li>
</ul>
<p>But this approach is worse than regular sticky menus.</p>
<p>Here’s why:</p>
<h2>Problem #1: They’re distracting</h2>
<p>This is because as the user scrolls the content to fit in the viewport, the menu will suddenly appear.</p>
<p>Good design doesn’t guess (wrongly) about what users need.</p>
<h2>Problem #2: They’re hard to control</h2>
<p>This is because scrolling up too much reveals the menu when it’s not wanted. And scrolling down a bit by accident will hide it when it is wanted.</p>
<p>Good design doesn’t take control away.</p>
<!-- *Scrolling is for bringing content into view, not for revealing menus.* -->
<h2>Problem #3: They cause dizziness and nausea</h2>
<p>This is because <a href="https://alistapart.com/article/designing-safer-web-animation-for-motion-sensitivity/">animation can cause dizziness, nausea, headaches and more</a>.</p>
<p>Good design avoids physical stress.</p>
<h2>Problem #4: They can impact performance</h2>
<p>This is because JavaScript is needed to react to the scroll event which can drain the battery and degrade performance especially on low-powered devices.</p>
<p>Good design is lightweight.</p>
<h2>What to do instead</h2>
<ol>
<li><strong>Keep pages short:</strong> Sticky menus are a symptom of long pages so fix the root cause.</li>
<li><strong>Just let users scroll:</strong> It’s a myth that scrolling is a problem. Even on mobile, the top of the page is a flick or 2 away mostly.</li>
<li><strong>Put relevant links in context:</strong> For example, add a subscribe form to the end of a post or add a CTA to a pricing section.</li>
<li><strong>Use a back-to-top link:</strong> They’re relatively unobtrusive (but only do this once you exhaust the other options).</li>
</ol>
4 common mistakes UI/UX designers make when trying to help users spot required form fields (and what user research shows is better)2023-06-11T00:00:00+00:00https://adamsilver.io/blog/how-to-highlight-required-and-optional-form-fields/<p>“Just whack a red asterisk next to each field and call it a day.”</p>
<p>Back in 2008 I worked for a software house. We specialised in e-commerce sites for big organisations like Boots, Argos and Homebase.</p>
<p>They had the usual forms.</p>
<p>Registration, forgot password, sign in and checkout. We whacked little red asterisks next to each required field; added some text to the top to explain what it means; and called it a day.</p>
<p>But we never tested it.</p>
<p>We never even really thought about it.</p>
<p>We just followed what everyone else did.</p>
<p>Fast forward 15 years and the same thing happens today. Which is a shame as these little asterisks (and other techniques used to denote required) fields can be a real problem.</p>
<p>Seeing as I get asked about this topic, I thought I’d cover it off so you can focus on more important problems.</p>
<p>As usual, I’ll start with what doesn’t work before revealing what does.</p>
<h2>Mistake #1: Using an asterisk to highlight required fields</h2>
<p>This is because many users don’t notice the asterisk or understand what it means.</p>
<p>Good design doesn’t make users think.</p>
<div class="image" style="max-width: 380px">
<figure><img src="https://adamsilver.io/assets/images/how-to-highlight-required-and-optional-form-fields/asterisks.png" alt="A form with red asterisks to denote required fields"><figcaption>Asterisks are often missed or misunderstood</figcaption></figure>
</div>
<h2>Mistake #2: Explaining that required fields are marked with an asterisk</h2>
<p>This is because most users don’t read instructions especially if they don’t relate to a question.</p>
<p>Good design doesn’t need to be explained.</p>
<div class="image" style="max-width: 380px">
<figure><img src="https://adamsilver.io/assets/images/how-to-highlight-required-and-optional-form-fields/explanation.png" alt="A form with red asterisks to denote required fields"><figcaption>Having to explain what something means is usually bad design</figcaption></figure>
</div>
<h2>Mistake #3: Highlighting both required and optional fields</h2>
<p>This is because highlighting both fields increases visual noise and slows users down.</p>
<p>Drawing attention to everything means drawing attention to nothing.</p>
<div class="image" style="max-width: 380px">
<figure><img src="https://adamsilver.io/assets/images/how-to-highlight-required-and-optional-form-fields/both.png" alt="A form highlight both required and optional fields"><figcaption>Highlighting everything means highlighting nothing</figcaption></figure>
</div>
<h2>Mistake #4: Highlighting required form fields only</h2>
<p>This is becaue most users assume all fields are required by default (and rightly so) so it’s unnecessary to draw attention to them.</p>
<p>Good design doesn’t do more than it needs to.</p>
<div class="image" style="max-width: 380px">
<figure><img src="https://adamsilver.io/assets/images/how-to-highlight-required-and-optional-form-fields/required-only.png" alt="A form highlighting required fields only"><figcaption>Highlighting required fields diminishes the value of highlighting</figcaption></figure>
</div>
<h2>Only highlight optional fields</h2>
<p>Well designed forms usually avoid optional fields (one way is with <a href="https://adamsilver.io/blog/how-to-avoid-optional-form-fields-with-branching-questions/">branching questions</a>).</p>
<p>This means optional fields should be rare. Given the point of highlighting is to draw attention to what’s different, it’s better to mark optional fields.</p>
<p>To do that add “(optional)” to the label.</p>
<p>Minimal noise, maximum clarity.</p>
<div class="image" style="max-width: 380px">
<figure><img src="https://adamsilver.io/assets/images/how-to-highlight-required-and-optional-form-fields/optional-only.png" alt="A form highlighting optional fields only"><figcaption>Highlighting optional fields only reduces noise</figcaption></figure>
</div>
The problem with automatically focusing the first input and what to do instead2023-06-04T00:00:00+00:00https://adamsilver.io/blog/the-problem-with-automatically-focusing-the-first-input-and-what-to-do-instead/<p>In 2009 I was working on the Argos checkout flow.</p>
<p>We were considering focusing the first input when the page loads. The idea was to save users a click (never a good sign). Back then we had to use JS, but now we have the HTML5 autofocus attribute.</p>
<p>Either way, automatically focusing the first input causes 5 specific problems that degrade UX.</p>
<p>Here they are:</p>
<h2>Problem #1: it makes the page jump unexpectedly</h2>
<p>When any normal web page loads, focus remains at the top.</p>
<p>With autofocus, focus jumps suddenly to the first input.</p>
<p>But this is disorientating and may cause users to think something has gone wrong.</p>
<div class="image">
<figure><video controls="">
<source src="https://adamsilver.io/assets/images/the-problem-with-automatically-focusing-the-first-input-and-what-to-do-instead/autofocus--jump.mp4#t=0.001" type="video/mp4">
</video><figcaption>Automatically focusing the input makes the page jump</figcaption></figure>
</div>
<h2>Problem #2: it stops users scrolling with the keyboard</h2>
<p>Users often scroll a web page after page load by pressing <kbd>↑</kbd> and <kbd>↓</kbd>.</p>
<p>With autofocus, the keys are ignored because the input is focused.</p>
<p>This makes the interface feel broken.</p>
<div class="image">
<figure><video controls="">
<source src="https://adamsilver.io/assets/images/the-problem-with-automatically-focusing-the-first-input-and-what-to-do-instead/autofocus--up-and-down.mp4#t=0.001" type="video/mp4">
</video><figcaption>The up and down keys get ignored as focus is inside the input</figcaption></figure>
</div>
<h2>Problem #3: it stops users going back with the keyboard</h2>
<p>Some users navigate back by keyboard using <kbd>#+←</kbd> for example.</p>
<p>With autofocus, the shortcut is ignored because the input is focused.</p>
<p>This slows users down.</p>
<div class="image">
<figure><video controls="">
<source src="https://adamsilver.io/assets/images/the-problem-with-automatically-focusing-the-first-input-and-what-to-do-instead/autofocus--back.mp4#t=0.001" type="video/mp4">
</video><figcaption>The keyboard shortcut to go back is ignored as focus is inside the input</figcaption></figure>
</div>
<h2>Problem #4: it’s unexpected for screen reader users</h2>
<p>When a web page loads, a screen reader announces the page title.</p>
<p>With autofocus, the input’s label is announced instead.</p>
<p>This is disorientating and causes users to lose context.</p>
<div class="image">
<figure><video controls="">
<source src="https://adamsilver.io/assets/images/the-problem-with-automatically-focusing-the-first-input-and-what-to-do-instead/autofocus--screen-reader.mp4#t=0.001" type="video/mp4">
</video><figcaption>The screen reader announces the input instead of the page</figcaption></figure>
</div>
<h2>Problem #5: it works badly on mobile</h2>
<p>On mobile, focusing an input usually opens the keyboard.</p>
<p>With autofocus this doesn’t happen. On Android, for example, the input is focused but the user has to tap again to open the keyboard.</p>
<p>This makes the interface feel broken.</p>
<div class="image" style="max-width: 400px">
<figure><video controls="">
<source src="https://adamsilver.io/assets/images/the-problem-with-automatically-focusing-the-first-input-and-what-to-do-instead/autofocus--android.mp4#t=0.001" type="video/mp4">
</video><figcaption>On Android, the input is focused but the user needs to tap </figcaption></figure>
</div>
<h2>Just let users focus the first input</h2>
<p>Good design puts users in control.</p>
<!-- On iPhone, the input is visually focused but not scrolled to which is probably insignificant but worth pointin -->The problem with nested fieldsets and how to avoid them2023-05-28T00:00:00+00:00https://adamsilver.io/blog/the-problem-with-nested-fieldsets-and-how-to-avoid-them/<p>In 2016 I worked at the Department for Work and Pensions.</p>
<p>I was working on a complex form field made up of nested fieldsets. It was inaccessible which surprised me because I was only using fieldsets, legends, labels and radio buttons. Nothing fancy.</p>
<p>But as I did more research, it became clearer that nested fieldsets can be problematic.</p>
<p>Here’s why:</p>
<h2>Problem #1: screen readers only announce the inner legend</h2>
<p>Let’s say you have appointment times organised by day and period.</p>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-nested-fieldsets-and-how-to-avoid-them/dates.png" alt="Screenshot of nested fieldset used for appointment times. The most outer fieldset is date and time. Nested inside that is a fieldset for each day. Nested inside that is a fieldset for morning and afternoon fieldsets. Within those fieldsets are radio buttons for each time."><figcaption>A fieldset for each day and for morning and afternoon</figcaption></figure>
</div>
<p>If the user moves from 3:15pm on Tuesday to 9:55am on Wednesday, screen readers will announce ‘9:55am, morning’. They will not announce ‘Wednesday 23 October’.</p>
<p>This is confusing and may cause users to select the wrong date. Or it may cause them to traverse the page line by line because they don’t trust the interface.</p>
<h2>Problem #2: screen readers won’t announce the end of a fieldset</h2>
<p>Let’s say you have a question that says ‘Do you like chocolate?’ And selecting ‘Yes’ reveals a nested question that says ‘Do you prefer light or dark chocolate?’</p>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-nested-fieldsets-and-how-to-avoid-them/conditional-reveal.png" alt="‘Do you like chocolate?’ with yes and no radio buttons. Selecting ‘Yes’ reveals a nested question that says ‘Do you prefer light or dark chocolate?’ with ‘Dark chocolate’ and ‘Light chocolate’ radio buttons."><figcaption>Radio buttons that reveal another question</figcaption></figure>
</div>
<p>If the user moves from ‘Dark chocolate’ to ‘No’, screen readers will not announce that they left the inner fieldset.</p>
<p>This is confusing because ‘No’ does not make sense as an answer for ‘Do you prefer light or dark chocolate?’</p>
<h2>Avoid nested fieldsets where possible</h2>
<p>For appointment times the fieldset for morning and afternoon could be removed because each label already says ‘am’ or ‘pm’.</p>
<p>For the conditional reveal the nested question could be shown on the next page. This may sound long winded but it usually <a href="https://www.smashingmagazine.com/2017/05/better-form-design-one-thing-per-page/">reduces cognitive load and speeds users up</a>.</p>
<p><em>(Note: Some nested fieldsets may be okay. For example, I often use them to reveal a date field with day, month and year inputs after selecting ‘Yes’ to knowing that date. This hasn’t raised issues in accessibility audits.)</em></p>
The billion dollar unsubscribe link2023-05-21T00:00:00+00:00https://adamsilver.io/blog/the-billion-dollar-unsubscribe-link/<p>2 weeks ago I sent an email to 3,855 subscribers using ConvertKit.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-billion-dollar-unsubscribe-link/email-footer.png" alt="My newsletter email footer with a red arrow pointing to the unsubscribe link"><figcaption>My newsletter email footer</figcaption></figure>
</div>
<p>But 177 of them were instantly unsubscribed without clicking the unsubscribe link. What happened?</p>
<p>These subscribers work at organisations with strict security. Every link is automatically opened to check it’s not malicious.</p>
<p>Fine, except that:</p>
<ul>
<li>my subscribers were unsubscribed without their consent</li>
<li>support agents spent a lot of time dealing with me and the issue</li>
<li>I had to spot the issue; work out how to resubscribe everyone; and create a workaround so it doesn’t happen again</li>
</ul>
<h2>This is a billion dollar UX mistake</h2>
<p>Here’s why:</p>
<ul>
<li>Support costs go up</li>
<li>Customer retention rates go down</li>
<li>Customer satisfaction scores go down</li>
<li>Customer fees go down (you pay based on subscriber count)</li>
</ul>
<p>Scale this up to 580,084 ConvertKit customers and 633 million subscribers and you’ve got a billion dollar mistake caused by a teeny tiny link.</p>
<h2>Links are for navigation, buttons are for actions</h2>
<p>To solve the problem do this:</p>
<ol>
<li>Clicking the unsubscribe link takes users to a page with a form</li>
<li>Submitting the form unsubscribes the user.</li>
</ol>
<p>The links can still be checked automatically. But only users can submit the form.</p>
<p>Good design puts users in control.</p>
<p><em>(Note: I’ve messaged ConvertKit’s founder about this and offered to help fix the issue. For now, I’ve used a workaround that takes subscribers to a Tally.so form. When submitted it triggers a Zapier automation that removes them from my newsletter.)</em></p>
The problem with disabled buttons and what to do instead2023-05-14T00:00:00+00:00https://adamsilver.io/blog/the-problem-with-disabled-buttons-and-what-to-do-instead/<p>In 2009 I prototyped a form that disabled the submit button until all the answers were valid.</p>
<p>The idea being: the best error is the one the user never sees.</p>
<p>But disabled buttons takes this rule to the extreme.</p>
<p>And as a result it can frustrate users or worse, cause them to give up completely.</p>
<p>Here’s why:</p>
<h2>Problem #1: They don’t give feedback</h2>
<p>When a form has mistakes, the user has to look at each field, spot a mistake and work out how to fix it.</p>
<div class="image">
<figure><video controls="">
<source src="https://adamsilver.io/assets/images/the-problem-with-disabled-buttons-and-what-to-do-instead/kotak.mp4#t=0.001" type="video/mp4">
</video><figcaption>Kotak Bank’s disabled button does not give feedback</figcaption></figure>
</div>
<h2>Problem #2: They make the interface feel broken</h2>
<p>If the user thinks their answers are valid, the UI may feel broken. If there are multiple errors and 1 is fixed, the button stays disabled. This feels unresponsive.</p>
<div class="image">
<figure><video controls="">
<source src="https://adamsilver.io/assets/images/the-problem-with-disabled-buttons-and-what-to-do-instead/wetransfer.mp4#t=0.001" type="video/mp4">
</video><figcaption>WeTransfer disabled button feels broken</figcaption></figure>
</div>
<h2>Problem #3: They’re hard to see</h2>
<p>Disabled buttons have low contrast to signify they’re disabled. But this makes them hard to read, especially for users who have visual impairments.</p>
<div class="image" style="max-width: 500px">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-disabled-buttons-and-what-to-do-instead/kotak.png" alt=""><figcaption>Kotak Bank’s disabled button is hard to see</figcaption></figure>
</div>
<h2>Problem #4: They’re not focusable</h2>
<p>This means keyboard users won’t be able to tab to the button. And users with poor vision won’t see the button.</p>
<p>This is confusing as most users expect to find a button to illuminate a clear path to proceed.</p>
<div class="image">
<figure><video controls="">
<source src="https://adamsilver.io/assets/images/the-problem-with-disabled-buttons-and-what-to-do-instead/kotak-not-focusable.mp4#t=0.001" type="video/mp4">
</video><figcaption>Kotak Bank’s disabled button cannot be focused</figcaption></figure>
</div>
<h2>Problem #5: They’re deceptive</h2>
<p>While disabled buttons have low contrast to signify that they’re disabled. It’s not always obvious. So some users still try and click them.</p>
<div class="image" style="max-width: 500px">
<figure><video controls="">
<source src="https://adamsilver.io/assets/images/the-problem-with-disabled-buttons-and-what-to-do-instead/facebook.mp4#t=0.001" type="video/mp4">
</video><figcaption>Facebook’s form to create a post may be too subtle</figcaption></figure>
</div>
<h2>Problem #6: Users may not notice the button becoming enabled</h2>
<p>This is because the button may be off screen (due to screen size or the length of the form). And if the button is on screen, users are focused on filling out the fields, not the button changing state.</p>
<div class="image" style="max-width: 400px">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-disabled-buttons-and-what-to-do-instead/ebay.png" alt=""><figcaption>Ebay’s button is out of view</figcaption></figure>
</div>
<h2>‘Just validate as the user types’</h2>
<p>No. <a href="https://adamsilver.io/blog/the-problem-with-live-validation-and-what-to-do-instead/">Live validation is problematic</a>. And it doesn’t solve all of the problems.</p>
<h2>What to do instead</h2>
<ol>
<li><strong>Write clear label and hint text</strong> so users understand the question</li>
<li><strong>Start with one thing per page</strong> to reduce cognitive load</li>
<li><strong>Enable the button</strong> so users always get feedback</li>
<li><strong>Forgive trivial mistakes</strong> to avoid unnecessary errors</li>
<li><strong>Give clear error messages</strong> to help users fix the issue</li>
</ol>
<p>Boring UX > clever UX</p>
The problem with sticky menus and what to do instead2023-05-07T00:00:00+00:00https://adamsilver.io/blog/the-problem-with-sticky-menus-and-what-to-do-instead/<p>Sticky menus (menus that stick to the edge of the viewport) are used to make them easy to access on long pages.</p>
<p>But this fancy pattern hurts UX far more than it improves it.</p>
<p>Here’s why:</p>
<h2>Problem #1: They constantly take up space</h2>
<p>They get in the way of the actual content. And it’s worse on small screens where space is more limited.</p>
<div class="image">
<figure><video controls="">
<source src="https://adamsilver.io/assets/images/the-problem-with-sticky-menus-and-what-to-do-instead/semplice.mp4#t=0.001" type="video/mp4">
</video><figcaption>Semplice’s menu sticks to the top</figcaption></figure>
</div>
<h2>Problem #2: They obscure content</h2>
<p>For example, Material Design’s floating action button always gets in the way of the content behind it.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-sticky-menus-and-what-to-do-instead/material-design.png" alt="Material Design example with button position bottom right over the top of the content"><figcaption>Material Design’s sticky button obscures the content beneath</figcaption></figure>
</div>
<h2>Problem #3: They break when you zoom in</h2>
<p>When zooming in, the size of the sticky menu can increase to a point where there’s little space for the content.</p>
<div class="image" style="max-width: 440px">
<figure><video controls="">
<source src="https://adamsilver.io/assets/images/the-problem-with-sticky-menus-and-what-to-do-instead/medium-iphone.mp4#t=0.001" type="video/mp4">
</video><figcaption>Medium’s website when zooming in and out shows how the content withint he menu gets obscured</figcaption></figure>
</div>
<p>On mobile, sticky menus may disappear upwards. They may also become <a href="https://technology.blog.gov.uk/2018/05/21/sticky-elements-functionality-and-accessibility-testing/">misaligned or slightly cropped</a>.</p>
<h2>Problem #4: They’re difficult to access</h2>
<p>If a sticky menu is taller than the content and viewport, users will be unable to access the bottom of the menu (in some browsers).</p>
<p>Even if the content is taller than the menu, users still have to scroll to the bottom of the content to see the menu which is long winded.</p>
<div class="image">
<figure><video controls="">
<source src="https://adamsilver.io/assets/images/the-problem-with-sticky-menus-and-what-to-do-instead/moj-patterns.mp4#t=0.001" type="video/mp4">
</video></figure>
</div>
<p>You could add an inner scroll bar to the menu. But <a href="https://baymard.com/blog/inline-scroll-areas">multiple scroll bars are hard to use</a>.</p>
<h2>Problem #5: Internal page anchors feel broken when clicked twice</h2>
<p>Some sticky menus contain links that take users to content down the page.</p>
<p>When the user clicks the same link for a second time nothing happens, which makes the interface feel broken.</p>
<div class="image">
<figure><video controls="">
<source src="https://adamsilver.io/assets/images/the-problem-with-sticky-menus-and-what-to-do-instead/sage.mp4#t=0.001" type="video/mp4">
</video><figcaption>Clicking a sticky CTA for a second time feels broken</figcaption></figure>
</div>
<h2>Problem #6: They appear closer than they are</h2>
<p>Sticky menus are always visually accessible, but in reality are far away for keyboard users navigating with the tab key.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-sticky-menus-and-what-to-do-instead/medium.png" alt="Medium’s article list with a focused heading appears visually close to the top of the page but is actually far away in terms of tab stops by keyboard"><figcaption>The currently focused link feels close to the menu, but it’s not</figcaption></figure>
</div>
<h2>Problem #7: They obscure links and other focusable elements</h2>
<p>Users who navigate back up the page by keyboard may end up focusing on a link that’s obscured by the sticky menu.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-sticky-menus-and-what-to-do-instead/gov.png" alt="GOV.UK Step By Step page with the focused link obscured by the sticky header"><figcaption>The focused link in the top right is obscured by the sticky header (credit: GOV.UK)</figcaption></figure>
</div>
<h2>What to do instead</h2>
<ol>
<li><strong>Keep pages short:</strong> Sticky menus are a symptom of long pages so fix the root cause.</li>
<li><strong>Just let users scroll:</strong> It’s a myth that scrolling is a problem. Even on mobile, the top of the page is a flick or 2 away mostly.</li>
<li><strong>Put relevant links in context:</strong> For example, add a subscribe form to the end of a post or add a CTA to a pricing section.</li>
<li><strong>Use a back-to-top link:</strong> They’re relatively unobtrusive (but only do this once you exhaust the other options).</li>
</ol>
Page title conventions2022-11-22T00:00:00+00:00https://adamsilver.io/blog/page-title-conventions/<p>A page title or document title describes a web page.</p>
<p>It’s the content that is placed inside the <code><title></code> element and appears in the browser window or tab.</p>
<p>The title is important because:</p>
<ul>
<li>it’s the first thing to be announed in screen readers</li>
<li>it distinguishes your website from other open websites</li>
<li>it helps search engines to index your website</li>
</ul>
<p>I recommend the following structure with hyphens inbetween:</p>
<ul>
<li>name of page (usually the <code>h1</code> heading but not always)</li>
<li>section name (if applicable)</li>
<li>name of service</li>
</ul>
<p>Here are some examples based on Amazon’s website.</p>
<table>
<thead>
<tr>
<th>Page</th>
<th>Page title</th>
</tr>
</thead>
<tbody>
<tr>
<td>Home page</td>
<td>Amazon</td>
</tr>
<tr>
<td>Your account</td>
<td>Your account - Amazon</td>
</tr>
<tr>
<td>Orders</td>
<td>Orders - Your account - Amazon</td>
</tr>
<tr>
<td>Books</td>
<td>Books - Amazon</td>
</tr>
<tr>
<td>Atomic Habits book</td>
<td>Atomic Habits, James Clear - Books - Amazon</td>
</tr>
</tbody>
</table>
Designing a time input2022-10-17T00:00:00+00:00https://adamsilver.io/blog/designing-a-time-input/<p>In 2021 I worked on a service that allows teacher training providers to set up interviews with trainees.</p>
<p>As part of this, we wanted to find out the best way of allowing users to enter a time in the correct format.</p>
<p>This is more challenging than you might think because:</p>
<ul>
<li>a time is made up of hours, minutes and a period (AM or PM)</li>
<li>there are many different formats for the same time like ‘12am’ ‘24:00’, 12.00am’, ‘12a.m.’ and ‘00’</li>
</ul>
<p>We played around with all sorts of patterns like autocompletes and using multiple inputs for hours and minutes.</p>
<p>But after several rounds of research and data analysis we ended up with something much simpler.</p>
<p>To give you all the details I’m going to walk through:</p>
<ul>
<li>how to avoid the complexity of entering time in the first place</li>
<li>the 4 different patterns we considered</li>
<li>the 1 simple pattern that works the best and why</li>
</ul>
<h2>How to avoid making users enter a time</h2>
<p>When it comes to forms, whenever we can help users avoid having to fill them out in the first place, we should.</p>
<p>When it comes to time there are certain ways to do that.</p>
<p>For example, I’m working on a service that has a closing time field for a job advert.</p>
<p>We could avoid making users enter a time by automatically setting the closing time to 11:59pm.</p>
<p>But as our users need greater control we provide 4 common times as radio buttons. Users just pick one and move on.</p>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/designing-a-time-input/radios.png" alt=""><figcaption>Radio buttons with options for 9am, 12pm, 5pm and 11:59pm</figcaption></figure>
</div>
<h2>Different ways of entering a time</h2>
<p>Different techniques can be used for time. They are:</p>
<ol>
<li>Native time input</li>
<li>Multiple inputs</li>
<li>Autocomplete</li>
<li>Single input</li>
</ol>
<p>By looking at the pros and cons of these, it’ll become clear why I recommend using a single text input.</p>
<h3>1. Using the native time input (<code>type="time"</code>)</h3>
<p>As usual, the first approach to look at is what browsers give us for free - the native time input.</p>
<p>It works differently depending on the browser or device.</p>
<p>Chrome on desktop, for example, gives users a text input with slot for the hour and minute separated by a colon.</p>
<p>It also provides a clock icon, which when clicked reveals a menu to select the hour and minute.</p>
<div class="image" style="max-width: 450px">
<figure><img src="https://adamsilver.io/assets/images/designing-a-time-input/time-input--chrome.png" alt=""><figcaption>Chrome’s native time input</figcaption></figure>
</div>
<p>This is problematic for a few reasons.</p>
<p>Firstly, once the hour has been selected, focus is moved automatically to the minute slot. If the user made a mistake, they have to move the focus back to the hour slot.</p>
<p>Due to the colon, it may not be clear that the focus can be moved back by pressing <kbd>Left</kbd>. I think a lot of users will opt to use their mouse. Either way it’s long winded.</p>
<p>Secondly, the colon cannot be selected even though it’s inside the box. This is misleading because normally the contents of an input can be selected.</p>
<p>Thirdly, it’s not clear that the clock icon reveals a menu or what that menu will consist of.</p>
<p>Finally, users cannot cut and paste a time into the input.</p>
<p>Chrome on Android gives users an empty text input with a little down arrow. When focused it reveals a dial.</p>
<div class="image" style="max-width: 450px">
<figure><img src="https://adamsilver.io/assets/images/designing-a-time-input/time-input--android.png" alt=""><figcaption>Android’s time input</figcaption></figure>
</div>
<p>This is also problematic.</p>
<p>Firstly, before the user focuses the input, it looks a bit like a select box due to the down arrow. Opening a dial may be unexpected.</p>
<p>Secondly, the dial isn’t particulary intuitive and has action labels that cannot be customised.</p>
<p>Finally, sometimes hint text is needed - but that’s covered up by the dialog.</p>
<p>(Note: browsers that lack support for the native time input will get a standard text input.)</p>
<h3>2. Using multiple inputs</h3>
<p>The second approach involves using multiple inputs for:</p>
<ul>
<li>hour - as a text input or select box</li>
<li>minute - as a text input or select box</li>
<li>AM or PM - as a select box or radio buttons</li>
</ul>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/designing-a-time-input/multiple-fields.png" alt=""><figcaption>Multiple inputs for hours, minutes and AM or PM</figcaption></figure>
</div>
<p>This avoids having to deal with different formats.</p>
<p>But <a href="https://www.youtube.com/watch?v=CUkMCQR4TpY">select boxes should be used as a last resort</a>. And <a href="https://adamsilver.io/blog/form-design-multiple-inputs-versus-one-input/">multiple inputs are problematic</a> because:</p>
<ul>
<li>they stop users from cutting and pasting</li>
<li>they require more effort to use</li>
<li>they can be difficult to label (‘AM or PM’ is a bit awkward here)</li>
</ul>
<p>(Note: the input for ‘AM and PM’ is needed because otherwise some users incorrectly enter ‘12’ or ‘00’ for midnight.)</p>
<h3>3. Using an autocomplete</h3>
<p>The third approach is to use an autocomplete input. This is like a text input and a select box combined.</p>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/designing-a-time-input/autocomplete.png" alt=""><figcaption>Google Calendar’s autocomplete input</figcaption></figure>
</div>
<p>Clicking the input reveals a list of times - typically at 30 minute intervals.</p>
<p>Users can select a time or type to narrow down the suggestions.</p>
<p>The problem with this approach is that:</p>
<ul>
<li>users are less aware of how to operate an autocomplete</li>
<li>users may enter a time in 24 hour format with the options shown in a 12 hour format (see above screenshot)</li>
<li><a href="https://adamsilver.io/blog/building-an-accessible-autocomplete-control/">making an accessible autocomplete is hard</a></li>
<li>autocompletes rely on JavaScript which means a non-JavaScript solution needs to be considered before enhancement</li>
</ul>
<h3>4. Using a single text input (recommended)</h3>
<p>The final approach - which I recommend - uses a single text input for time.</p>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/designing-a-time-input/single-input.png" alt=""><figcaption>A single input for time</figcaption></figure>
</div>
<p>It works well. It’s consistent across all browsers and devices. Users just type what they like.</p>
<p>My research shows that using a single input works very well as long as you <a href="https://bat-design-history.netlify.app/manage-teacher-training-applications/allowing-a-wider-range-of-input-formats-for-interview-time/">accept a wide range of formats</a>.</p>
<p>The only argument against this approach is the effort required to accept all these formats.</p>
<p>But I don’t count this as a problem because:</p>
<ul>
<li>it’s doing the hard work to make it simple</li>
<li>it’s far easier to build than an autocomplete</li>
<li>we have to do this anyway when considering progressive enhancement</li>
<li>it’s not that much effort to build (we used <a href="https://github.com/adzap/timeliness">Timeliness</a> with minimal configuration)</li>
</ul>
<p>I also want to highlight that even:</p>
<ul>
<li>if research showed that an autocomplete works better we’d still need to use a single input <a href="https://adamsilver.io/blog/javascript-isnt-always-available-and-its-not-the-users-fault/">when JavaScript is unavailable</a></li>
<li>if research showed that the native time input works best, we’d still need to use a single input for browsers that lack support</li>
</ul>
<p>So we may as well start with a single input and prove through research that it’s worth the extra effort of doing anything more.</p>
<!-- ## Summary
While entering time appears to be challenging at first, it’s not that bad.
If you can avoid making users enter a time in the first place, do so.
But if you do need to give users the ability to enter a time, use a single text input that accepts a wide range of formats.
This is the most simple, consistent and accessible approach we can take. -->
Material Design text fields are badly designed2021-02-24T00:00:00+00:00https://adamsilver.io/blog/material-design-text-fields-are-badly-designed/<p>I’ve been designing forms for over 20 years now, and I’ve tested many of them for large organisations like Boots, Just Eat and GOV.UK.</p>
<p>One topic that comes up a lot with forms is: where to put the label. In the early days, we talked about left aligned labels versus top aligned labels.</p>
<p>These days the focus is more about placeholders that replace labels and float labels. The latter start off inside the input. When the user starts typing, the label ‘floats’ up to make space for the answer.</p>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/material-design-text-fields-are-badly-designed/material-design-text-field.png" alt=""><figcaption>Material Design text fields use the float label pattern</figcaption></figure>
</div>
<p>Some people assume float labels are best because Google’s Material Design uses them - you know, because “it’s Google”. But in this case, Google is wrong.</p>
<p>Instead I recommend using conventional text fields which have:</p>
<ul>
<li>the label outside the input (to tell the user what to type)</li>
<li>a distinct border all the way around (to make it obvious where the answer goes)</li>
</ul>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/material-design-text-fields-are-badly-designed/conventional-text-field.png" alt=""><figcaption>A conventional text field</figcaption></figure>
</div>
<p>Here, I’ll explain why I recommend conventional text fields and why Google is wrong about using float labels for Material Design.</p>
<h2>Float labels are better than a common alternative but they’re still problematic</h2>
<p>Float labels were designed to address some problems with a commonly used alternative: placeholder labels.</p>
<p>This is where the label is placed inside the input but disappears when the user starts typing.</p>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/material-design-text-fields-are-badly-designed/placeholder-label.png" alt=""><figcaption>Placeholder label text field</figcaption></figure>
</div>
<p>Having seen lots of people interacting with forms through my work first hand I know that <a href="https://adamsilver.io/blog/the-problem-with-placeholders-and-what-to-do-instead/">placeholder labels are problematic</a>.</p>
<p>This is because, for example, they:</p>
<ul>
<li>disappear as soon as the user types which can make it harder to remember what the input is for, especially for users with cognitive impairments</li>
<li>may be <a href="https://www.uxmatters.com/mt/archives/2010/03/dont-put-hints-inside-text-boxes-in-web-forms.php">mistaken for an actual answer causing users to accidentally skip the field</a></li>
<li>are ‘greyed out’ to indicate that it’s a label and not an answer - but this can make it harder to read</li>
</ul>
<p>Float labels don’t solve 2 of these problems: poor contrast and the chance of the label being mistaken for an actual answer.</p>
<p>And while they attempt to address the problem of the label disappearing, in doing so, <a href="https://adamsilver.io/blog/the-problem-with-float-labels-and-what-to-do-instead/">float labels introduce a range of other problems</a>.</p>
<p>For example, the size of the label has to be tiny in order to fit inside the box, which can make it hard to read. And long labels cannot be used as they’ll get cut off by the input.</p>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/material-design-text-fields-are-badly-designed/float-label-overflow.png" alt=""><figcaption>Long labels get cut off with Material Design’s float labels</figcaption></figure>
</div>
<h2>Conventional text fields are better than both placeholder labels and float labels</h2>
<p>Conventional text fields don’t have the above problems because it’s clear where the answer goes and they have a legible, readily available label.</p>
<p>The labels can be of any length and hint text, should it be needed, is easy to accommodate as well.</p>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/material-design-text-fields-are-badly-designed/long-conventional-text-field.png" alt=""><figcaption>Conventional text fields can accommodate long labels</figcaption></figure>
</div>
<p>I’ve watched hundreds of people interact with forms and seen many of them struggle. But not once was that down to the use of a conventional text field.</p>
<p>They take up a bit more vertical space. But saving space at the cost of clarity, ease of use and accessibility is a bad tradeoff to make.</p>
<h2>Google’s test didn’t include conventional text fields</h2>
<p>Google’s article, <a href="https://medium.com/google-design/the-evolution-of-material-designs-text-fields-603688b3fe03">The Evolution of Material Design’s Text Fields</a> shows that only 2 variants were tested, both of which used float labels.</p>
<div class="image" style="max-width: 700px">
<figure><img src="https://adamsilver.io/assets/images/material-design-text-fields-are-badly-designed/test.png" alt=""><figcaption>The 2 variants of text fields that Google tested: float labels with underlines and a white transparent background (left) and float labels with grey backgrounds (right).</figcaption></figure>
</div>
<p>Crucially the test didn’t include conventional text fields which means they haven’t actually compared the usability of their float label design against conventional text fields.</p>
<p>And having read Google’s responses to the comments on their article, it seems usability was not their top priority.</p>
<h2>Google inadvertently prioritised aesthetics over usability</h2>
<p>I looked into why Material Design uses float labels, and discovered comments from Michael Gilbert, a designer who worked on them.</p>
<p>The comments indicate that they tried to balance aesthetics and usability.</p>
<p><a href="https://medium.com/@mattericsson/this-seems-to-imply-that-there-was-more-of-an-emphasis-on-form-over-function-in-the-original-dbefb328c21e">Matt Ericsson commented</a>:</p>
<blockquote>
<p>This seems to imply that there was more of an emphasis on form over function […] or even a desire to simply differentiate Material components from tried and true (boring) input boxes. […] was there research conducted on the original inputs that validated that they met a goal that was not being met by box inputs? Is there something that stood out as valuable going with a simple underline?</p>
<p><cite>Matt Ericsson</cite></p>
</blockquote>
<p><a href="https://medium.com/@mdgilbert/hi-matt-1ab1b86e53a4">Google’s response</a>:</p>
<blockquote>
<p>The design decisions behind the original text field predate my time on the team, but I think the goal was likely similar [to this research]: Balance usability with style. I believe at the time we were leaning towards minimalism, emphasizing color and animation to highlight usability.</p>
<p><cite>Matt Gilbert</cite></p>
</blockquote>
<p><a href="https://medium.com/@denislesak/really-appreciate-you-sharing-the-behind-the-scenes-story-98c5d2896637">Denis Lesak commented</a>:</p>
<blockquote>
<p>[…] this is one of those moments were I wonder why all of this research was necessary as I have long thought that the old design was flawed for all the reasons you mentioned.</p>
<p><cite>Denis Lesak</cite></p>
</blockquote>
<p><a href="https://medium.com/@mdgilbert/hello-denis-a0fcdb7c40a4">Google’s response</a>:</p>
<blockquote>
<p>[…] the goal of the research here wasn’t to simply determine that one version was better than another […]. This study was instead focused on identifying the characteristics of design that led to the most usable, most beautiful experiences.</p>
<p><cite>Matt Gilbert</cite></p>
</blockquote>
<p>Even though Google aimed for balance, in the end they inadvertently sacrificed usability for ‘minimalism’ and ‘a beautiful experience’.</p>
<p>But <a href="https://uxdesign.cc/accessibility-drives-aesthetics-5aef77b5d2aa">aesthetics and usability are not in competition with each other</a>. Interfaces can look good without causing problems for users. In fact, these qualities go hand in hand.</p>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/material-design-text-fields-are-badly-designed/example-form.png" alt=""><figcaption>An example form using conventional text fields that look good and function well too.</figcaption></figure>
</div>
<h2>In conclusion</h2>
<p>Float labels are certainly less problematic than placeholder labels.</p>
<p>But conventional text fields are better than float labels because they look like form fields and the label is easy to read and available at all times.</p>
<p>Aesthetics are important. But putting the label inside the box does not make it look beautiful. What it does do, however, is make it demonstrably harder to use.</p>
<p><em>Thanks to <a href="https://twitter.com/cjforms">Caroline Jarrett</a> and <a href="https://twitter.com/Amy_Hupe">Amy Hupe</a> for helping me write this. And thanks to <a href="https://twitter.com/maedmaex">Maximilian Franzke</a>, <a href="https://twitter.com/ovan">Olivier Van Biervliet</a>, <a href="https://twitter.com/danvdrsn">Dan Vidrasan</a>, <a href="https://twitter.com/Fabien_UX">Fabien Marry</a> for their feedback on an earlier draft of this article.</em></p>
Stopping Chrome from ignoring autocomplete=off2021-02-04T00:00:00+00:00https://adamsilver.io/blog/stopping-chrome-from-ignoring-autocomplete-off/<p>Autofill (or autocomplete) attributes tell browsers to automatically fill out an answer for the user if the user has stored that information in the browser.</p>
<p>And this little feature <a href="https://twitter.com/lukew/status/922630320293265408">saves users well over a million days per month</a> .</p>
<p>But there’s a problem with Chrome: it sometimes ignores <code>autocomplete="off"</code>.</p>
<p>Now even though this is annoying, it might be the right thing to do and it may also be <a href="https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofilling-form-controls%3A-the-autocomplete-attribute">abiding by the specification</a>.</p>
<blockquote>
<p>The autocomplete content attribute can be used to hint to the user agent how to, or indeed whether to, provide such a feature.</p>
</blockquote>
<p>This is because with HTML, this attribute (like any other), is a suggestion to the browser.</p>
<p>To make things a little more complicated, browsers may also autofill form fields based on the field’s <code>name</code> or <code>id</code> attributes.</p>
<p>This is how browsers did it before the <code>autocomplete</code> attribute came along.</p>
<p>So for maximum support use both the <code>name</code> and <code>autocomplete</code> attributes.</p>
<p>But if you want Chrome (and other browsers) to stop autofilling fields then you need to use a <code>name</code>, <code>id</code> and <code>autocomplete</code> value that the browser doesn’t recognise.</p>
<pre><code><input
name="xyz123"
id="xyz123"
autocomplete="xyz123"
>
</code></pre>
<p>As a side note: Chrome will correctly not autofill a ‘create password’ field if you use these attributes:</p>
<pre><code><input
name="new-password"
id="new-password"
autocomplete="new-password"
>
</code></pre>
<p>As above, this could have still been achieved with a random value, but it’s nice to have a readable field name.</p>
<p>Maybe a prefix of <code>new-</code> should become the readable convention for browsers to ignore autofill?</p>
A few notes about A/B testing from Jared Spool2021-02-01T00:00:00+00:00https://adamsilver.io/blog/ab-testing-notes-from-jared-spool/<p>A few notes from <a href="https://twitter.com/jmspool/status/1190411665684279296?s=09">Jared Spool’s twitter thread on A/B testing</a>.</p>
<blockquote>
<p>A/B testing is an effective approach to use science to design and deliver deeply-frustrating user experiences.</p>
</blockquote>
<blockquote>
<p>A/B testing without upfront research is just random monkeys testing random designs to see which of those designs do “best” against random criteria.</p>
</blockquote>
<blockquote>
<p>If drug testing was actually implemented like most A/B tests, you’d give 2 drugs to 2 groups of people and pick the “winner” by whichever group had fewer deaths.</p>
</blockquote>
<blockquote>
<p>A big issue is the A/B test zealots confuse conversion rate optimization with delivering great user experiences.</p>
</blockquote>
<blockquote>
<p>There are excellent reasons that users don’t desire to “convert.” CRO doesn’t think those experiences are important to the business.</p>
</blockquote>
<blockquote>
<p>A/B testing is not the same as understanding how users behave.</p>
</blockquote>
<blockquote>
<p>You have no idea if their behavior is what they wanted.</p>
</blockquote>
<blockquote>
<p>There’s a difference between someone who takes an action because that’s what they wanted vs someone taking action they didn’t want to take.</p>
</blockquote>
<blockquote>
<p>A/B testing doesn’t tell you which it is. So, what do you really understand?</p>
</blockquote>
<h2>How do you decide between 2 options that have tested well qualitatively?</h2>
<blockquote>
<p>Flip a coin.</p>
</blockquote>
<blockquote>
<p>The implementation costs of a coin flip are far better than an A/B test.</p>
</blockquote>
<blockquote>
<p>Not comfortable flipping a coin? Then you haven’t done enough research.</p>
</blockquote>
<h2>But Amazon do a lot of A/B testing?</h2>
<blockquote>
<p>IMO: Amazon has done a great job of teaching us to accept mediocre user experiences in exchange for convenience.</p>
</blockquote>
<blockquote>
<p>The big case-in-point: can you tell me about a big, innovative UX capability Amazon e-commerce has introduced in the last 5 years?</p>
</blockquote>
<blockquote>
<p>Experimentation culture works against experience innovation, because it basically is about refinement of ideas, and not new idea creation.</p>
</blockquote>
<blockquote>
<p>The key thing that I think hurts orgs like Amazon is that you can’t learn why certain tests came out the way they did.</p>
</blockquote>
<blockquote>
<p>So the design efforts never get smarter about their users.</p>
</blockquote>
<blockquote>
<p>They just become blind “followers” of the test results, not knowing the reasons behind anything.</p>
</blockquote>
<blockquote>
<p>It creates a cargo cult/superstition approach to design knowledge.</p>
</blockquote>
<blockquote>
<p>“We don’t know why we do this, but we know it works.” (as far as we can tell based on test results that only measure easy-to-measure business indicators).</p>
</blockquote>
<blockquote>
<p>So, yes, for short term gains, you can justify building the experimentation culture.</p>
</blockquote>
<blockquote>
<p>But teams have found that it creates excessive design debt that makes it hard in the long term to stay competitive.</p>
</blockquote>
<blockquote>
<p>(Amazon stays competitive through means other than the UX of their site.)</p>
</blockquote>
<h2>Can it be effective?</h2>
<blockquote>
<p>I think it can be used effectively.</p>
</blockquote>
<blockquote>
<p>But I see that organizations that invest heavily in it tend to produce poorly designed products and services.</p>
</blockquote>
<blockquote>
<p>It’s seen as a cheap solution to doing hard work. I believe it’s not the panacea that everyone thinks it is.</p>
</blockquote>
<blockquote>
<p>I think if you control the sample of participants to be sure they all have the same goal, can control variations in stimuli, and can be assured that you understand why one condition outperformed the other, A/B testing can be useful.</p>
</blockquote>
<blockquote>
<p>It’s rare to have that kind of situation.</p>
</blockquote>
<blockquote>
<p>Most experiments think they are doing that, but on further investigation, you find out that they aren’t testing in as controlled an environment as they believe.</p>
</blockquote>
<blockquote>
<p>This leads to a false faith in the results, which often come back to bite you later.</p>
</blockquote>
Avoiding tab styles for navigation2020-11-25T00:00:00+00:00https://adamsilver.io/blog/avoiding-tab-styles-for-navigation/<p>I work on a service that lets users manage teacher training applications.</p>
<p>The screen below shows our initial design of the navigation bar. The items are links but styled like tabs.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/avoiding-tab-styles-for-navigation/old.png" alt=""><figcaption>Initial design: navigation bar styled as tabs</figcaption></figure>
</div>
<p>But this design is potentially problematic. Here I’ll explain why that is and what we did about it.</p>
<h2>The problem with styling links as tabs</h2>
<p>Styling links as tabs is deceptive – when a link is clicked, the content is shown after a page refresh with the focus moving back to the top of the viewport.</p>
<p>But tabs don’t work like this – when a tab is clicked, the content is shown instantly without a page refresh and with the focus remaining on the tab.</p>
<p>Keyboard users may expect to be able to use the left and right arrow keys in order to switch tabs. This wouldn’t be expected with a list of links.</p>
<p>And (sighted) screen reader users may expect certain functionality, like using a shortcut to move focus to the associated tab panel or announcing which tab is selected.</p>
<p>Tabs should only look like tabs if they behave like tabs otherwise it can be in disorienting and confusing for users.</p>
<h2>What we did about it</h2>
<p>As our navigation bar doesn’t behave like tabs, and because we want to reduce the risk of confusion, we moved away from tab-like styles.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/avoiding-tab-styles-for-navigation/new.png" alt=""><figcaption>New design: navigation links styled to look less like tabs</figcaption></figure>
</div>
<h2>‘But they still look a bit like tabs’</h2>
<p>Admittedly the new design still looks a little like tabs.</p>
<p>I think that’s because many sites style their tabs in a less traditional way.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/avoiding-tab-styles-for-navigation/sage.png" alt=""><figcaption>Sage’s website has tabs that don’t look like traditional tabs</figcaption></figure>
</div>
<p>But there’s nothing we can really do about this.</p>
<p>Our service, like many others, consist of navigation bars and tabs that behave differently.</p>
<p>Using different styles for navigation and tabs gives users the best chance of using them effectively, efficiently and intuitively.</p>
<h2>In conclusion</h2>
<p>Styling links to look like tabs can make them harder to use.</p>
<p>This is unsurprising given one of the core principles of good design is that something should look like what it is.</p>
<p>Fortunately, it’s quite easy to avoid tab styles for navigation which gives users the best chance of operating tabs and links in the most optimal way.</p>
<p>And that means we can spend time researching more important and riskier assumptions.</p>
Interaction designers: how well do you work with developers and content designers?2020-10-20T00:00:00+00:00https://adamsilver.io/blog/interaction-designers-how-well-do-you-work-with-developers-and-content-designers/<p>I used to be a frontend developer.</p>
<p>I think there are broadly 2 types of frontend developer.</p>
<p>The first type prefers to be given a spec to follow and that’s that.</p>
<p>The second type has more of an interest in how well the UI ends up actually working for users.</p>
<p>If they’re handed something that can cause usability and accessibility issues, then they might push back and offer altnerative solutions.</p>
<p>I was the second type.</p>
<p>So I would push back.</p>
<p>But I think that most designers I worked with saw me as a developer and nothing more so only occasionally took onboard my comments.</p>
<p>A11y shma11y.</p>
<p>I don’t think this situation is unique to developers though.</p>
<p>A friend of mine is a content designer.</p>
<p>She’s great at words but she’s way more than that. She’s a good designer, who thinks about the end to end journey.</p>
<p>She’s told me about how some of the designers she’s worked with, often treat her as an afterthought.</p>
<p>Someone to improve the words after the designer has done the flow, the form fields and some close-to-finished words.</p>
<p>But remember how I said there were 2 types of developer?</p>
<p>There are also 2 types of content designer.</p>
<p>The first type likes to be told what to write and they focus on those words.</p>
<p>The second type looks at content and design as inseparable work partners and wants to be involved throughout because good content can avoid bad interactions.</p>
<p>So what do we do?</p>
<p>Looking back I think I could have been clearer to the designers on my team about how I like to work, what value I think I can provide.</p>
<p>That way I might have had the opportunity to provide feedback earlier in the design process.</p>
<p>Instead I received finished designs, and then gave unsolicited feedback.</p>
<p>That must have been annoying no matter how good my suggestions were (not saying they were but let’s imagine they were).</p>
<p>And I think if I was a designer who had mostly worked with the first type of content designer, I might accidentally start to assume all content designers like working that way.</p>
<p>Working with other people is hard but I think it’s so important to understand the strengths and preferences of your team mates.</p>
<p>That way you get the most out of each other and so do our users.</p>
Bidirectional scrolling: what’s not to like?2020-09-27T00:00:00+00:00https://adamsilver.io/blog/bidirectional-scrolling-whats-not-to-like/<div class="image">
<figure><img src="https://adamsilver.io/assets/images/bidirectional-scrolling-whats-not-to-like/netflix.png" alt=""><figcaption>Netflix’s user interface with bidirectional scrolling</figcaption></figure>
</div>
<p>Sites like Netflix organise programs into rows by category which can be horizontally scrolled into view.</p>
<p>This gives users an overview of every category without having to scroll through all programs.</p>
<p>This pattern is accessible, responsive and consistent across screen sizes. And it’s pretty easy to implement.</p>
<p>That’s a lot of pros for a pattern that in reality has some critical downsides.</p>
<p>Here, I’ll explain what those are, and how I’d go about it instead.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/bidirectional-scrolling-whats-not-to-like/horizontal-scrolling.png" alt=""><figcaption>Horizontally scrolling programs by category</figcaption></figure>
</div>
<p>Despite the pros, I still think horizontally scrolling content is overcomplicating matters.</p>
<p>Having to scroll down and across in a zig zag fashion can be tiresome, especially for people with motor impairments.</p>
<p><a href="https://adamsilver.io/blog/user-interfaces-hiding-content-should-be-a-last-resort/">Hiding content should always be a last resort</a> because:</p>
<ul>
<li>it increases the chance users won’t see it</li>
<li>there’s a greater reliance on digital literacy</li>
<li>it’s generally more labour intensive for users</li>
</ul>
<p>Performance wise, loading content that users can’t see and may not end up being viewed is slow and wastes people’s data allowance.</p>
<h2>What to do instead</h2>
<p>Instead, we could just load the 4 most popular items in each category.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/bidirectional-scrolling-whats-not-to-like/link-to-each-category.png" alt=""><figcaption>Loading less items and linking to each category page</figcaption></figure>
</div>
<p>This way, the content isn’t hidden; it’s easy to drill down into a category; data isn’t wasted; and an unconventional, labour intensive pattern is avoided.</p>
<p>However, there will be a bit more vertical scrolling on small screens as the items will stack but I’d start there and see how it goes in research.</p>
<p>My hunch is that the additional scrolling on small screens will be fine – things that seem problematic to us may not be problematic for users.</p>
<p>After all, flicking down the categories is low effort and really fast.</p>
<p>But if research shows it’s problematic then I’d look at ways to hide the content again – but just on smaller screens.</p>
<p>That could be a button that reveals more items. Or it could be reintroducing horizontal scroll.</p>
<h2>‘But that’s more clicks’</h2>
<p>You may be worried that splitting out content across pages increases the number of clicks.</p>
<p>But firstly the <a href="https://uxmyths.com/post/654026581/myth-all-pages-should-be-accessible-in-3-clicks">number of clicks is a poor indicator of usability</a>.</p>
<p>And in this case, it takes more clicks (or flicks) to horizontally scroll the content into view on desktop, compared with going to a dedicated page for that content.</p>
<h2>In conclusion</h2>
<p>Out of all the complex patterns out there, horizontal scrolling seems really good from a number of viewpoints.</p>
<p>But I still think it’s an overly complex pattern that can be avoided by keeping pages lightweight by default and using pages as a form of progressive disclosure.</p>
<p>Boring is not exciting, but it’s really easy to use.</p>
<p><em>Thanks to <a href="https://amyhupe.co.uk/">Amy</a> for editing this.</em></p>
Pressing back after deleting something2020-08-04T00:00:00+00:00https://adamsilver.io/blog/pressing-back-after-deleting-something/<p>After tweeting about using a page instead of a modal dialog, <a href="https://twitter.com/cjcheshire/status/1290536871282511874">Chris Cheshire</a> asked what should happen if the user presses back after deleting a customer’s account.</p>
<p>I had a look at the service I‘m working on at the moment and we show a 404 page.</p>
<p>This makes sense technically as the account no longer exists.</p>
<p>But I discussed with <a href="https://twitter.com/@duncanjbrown">Duncan Brown</a> how we could do this better.</p>
<p>And we came up with this custom 404 page:</p>
<pre><code># You cannot delete this customer’s account – it does not exist
It looks like you may have deleted it already.
[Continue to account list page]
</code></pre>
<p>This way the user knows why they cannot see the page and they can click the button to get back to a working page.</p>
The trouble with mailto email links and what to do instead2020-07-13T00:00:00+00:00https://adamsilver.io/blog/the-trouble-with-mailto-email-links-and-what-to-do-instead/<p>Co-written with <a href="https://amyhupe.co.uk/">Amy Hupe</a> 🌟.</p>
<p><em>A couple of months ago, my friend <a href="http://amyhupe.co.uk/">Amy Hupe</a> and I launched a joint venture called <a href="http://wearefrankly.co/">Frankly</a>—aiming to help teams create clear, accessible and user-centred digital products.</em></p>
<p><em>Amy and I share a passion for getting the basics right. That means thinking carefully about the big picture—but also paying close attention to the finer details.</em></p>
<p><em>This is a post we wrote together about one of those details, which we wrestled with along the way.</em></p>
<h2>The problem with mailto links</h2>
<p>It was really important to us that our website represented our core values by being simple, accessible and usable.</p>
<p>One of the decisions we faced whilst trying to achieve this was whether or not to include a standard mailto link for our email address.</p>
<p>We were reluctant to include one because, despite being commonly used across the web, they present a number of problems.</p>
<p>Firstly, mailto links make it hard to copy the address, for example if you want to share the email address with someone else.</p>
<p>Secondly, some users use more than one mail app, and the link just uses whichever has been setup as the default, without giving them the option to use the other.</p>
<p>And finally, many users don’t have an email application set up, which means the link can take them to a dead end or down a rabbit hole.</p>
<p>For example, when you click an email address on our Macbook using Chrome, the Mail application loads asking me to set up an email account. We both use Gmail, and getting that set up on Chrome is really challenging.</p>
<p>For these reasons, we initially decided to leave the mailto link out and include the email as normal text.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-trouble-with-mailto-email-links-and-what-to-do-instead/mailto1.png" alt="A paragraph of plain text that says ‘Email us at hello@wearefrankly.co’"><figcaption>Iteration 1: no mailto link</figcaption></figure>
</div>
<p>But this solution had its own drawbacks.</p>
<h2>The pros of mailto email links</h2>
<p>We weren’t entirely comfortable with our decision to omit the mailto link because:</p>
<ul>
<li>they’re used everywhere—so people may be expecting the behaviour they’re used to</li>
<li>on mobile devices, users pretty much have to set up a default email address, so clicking this link does exactly what most mobile users intend: it opens up their compose dialog</li>
</ul>
<p>But this still doesn’t provide a great experience for someone who wants to copy the email address and add it to a note or send it to a contact.</p>
<h2>Offering choice</h2>
<p>Given that there are clear advantages and disadvantages to both including and omitting a mailto link, we decided it was best to give users the choice, which happens to be one of the <a href="https://inclusivedesignprinciples.org/">inclusive design principles</a>.</p>
<p>So the day after launch, and after a brief <a href="https://twitter.com/Amy_Hupe/status/1253222964243435521">Twitter discussion</a>, we added a mailto link next to the email address, whilst keeping the address itself as plain text.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-trouble-with-mailto-email-links-and-what-to-do-instead/mailto2.png" alt=""><figcaption>Iteration 2: ‘Email us’ as the mailto link and the email adress as normal text</figcaption></figure>
</div>
<p>People who want to go straight to sending email using a mailto link can do so, and people who want to copy the email can do that, too.</p>
<h2>Tidying things up with a copy address button</h2>
<p>This solution was probably fine, but mailto links are so common that we were concerned some users would still expect to be able to click or tap the email address itself.</p>
<p>To fix this, we decided to add the mailto link to the email address and introduce a “copy address” button next to it, which lets users quickly copy the address to their clipboard.</p>
<p>From there, they can paste it into their mail application to compose an email, add it to their notes or share it with a contact.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-trouble-with-mailto-email-links-and-what-to-do-instead/mailto3.png" alt=""><figcaption>Iteration 3: the email address is the mailto link but with a copy button beside it</figcaption></figure>
</div>
<p>This gives users the same choice described above, but it looks a little cleaner and more conventional.</p>
<p>However, it’s worth noting that this only solves one of the three mailto link problems we mentioned above: that they make it hard for users to copy the address.</p>
<p>Even with the solution we’ve used, people who follow the link still:</p>
<ul>
<li>get taken to a dead end if they don’t have an email application set up</li>
<li>won’t get a choice about which application to use, if they use more than one</li>
</ul>
<h2>What we’d really like</h2>
<p>This is such a common problem and it feels like something browsers and operating systems should fix.</p>
<p>We think the ideal solution would be for users who click or tap on the mailto link to see a menu with choices like:</p>
<ol>
<li>Send an email from Gmail</li>
<li>Email from another account</li>
<li>Copy email address</li>
<li>Share email address via…</li>
</ol>
<p>This would answer the most common needs, and gives most users a way forward.</p>
<p>And that’s our little story about mailto links. What do you think?</p>
A quick crit of HEY email2020-06-24T00:00:00+00:00https://adamsilver.io/blog/hey-review/<p>HEY.com is a new email service by Basecamp.</p>
<p>It’s great, I love it.</p>
<p>But it’s got a fair amount to improve on which are some pretty surprising oversights.</p>
<p>So I thought I‘d jot down some notes here – maybe the peeps at HEY will see this and act.</p>
<h2>1. It’s not accessible</h2>
<p>HEY isn’t very accessible. I haven’t done a proper audit but here’s some things I spotted.</p>
<ol>
<li>It doesn’t work very well <a href="https://adamsilver.io/blog/javascript-isnt-always-available-and-its-not-the-users-fault/">when JavaScript isn’t available</a>. This is a shame because they do a fair chunk of rendering on the server which is great, but not enough to show users an actual email.</li>
<li>When tabbing through the page, focus is lost and so you don’t know where you are.</li>
<li>The keyboard shortcuts are cool but I don’t think they’ll work very well for screen reader users who shouldn’t have to learn custom shortcuts to move around the UI.</li>
</ol>
<p>All of these things are really easy to fix.</p>
<h2>2. There’s no way to sort different emails by the same email address</h2>
<p>HEY lets you put email into 3 buckets: the ‘imbox’, ‘the feed’ and ‘paper trail’. This is brilliant. But it does it based on the email address.</p>
<p>So if you get some emails that are marketing and some that are directly from that person, from the same address then really I‘m forced to keep the marketing email in the imbox.</p>
<p>The same goes for emails in the paper trail.</p>
<h2>3. It’s very easy to forget about the feed and paper trail</h2>
<p>This is for 2 reasons:</p>
<ol>
<li>They’re second class citizens and completely out of view. There’s no notification of way for me to know that I’ve received emails in these sections.</li>
<li>The HEY menu is basically a fancy looking hamburger menu. This means that as much as I know those links are there, it’s a suprisingly big barrier to getting into this sections.</li>
</ol>
<p>This is really bad and puts the onus on users to remember to check these things on a regular basis. This is exacerbated by issue (2) above.</p>
<h2>4. The feed items don’t get read and they’re difficult to scan</h2>
<p>The feed is a great idea for a bucket but it would be so much better off it worked and looked like the imbox.</p>
<p>Just show users new and seen marketing emails. These are easy to scan and they disappear once I’ve read them.</p>
<h2>5. They call the ‘inbox’ the ‘imbox’</h2>
<p>This is not a typo but it’s not good. Just call it inbox. Plain english is good. You need a really good reason not to keep things simple. And despite the sales pitch, I don’t think it’s a good enough reason.</p>
Form design: multiple inputs versus one input2020-05-18T00:00:00+00:00https://adamsilver.io/blog/form-design-multiple-inputs-versus-one-input/<p><em>There’s been some <a href="https://twitter.com/adambsilver/status/1263025914386034688">comments about this on Twitter</a>.</em></p>
<p>While most fields are made up of just one input, like an email address, some fields (that are essentially one value) could be split into multiple inputs, like a sort code.</p>
<p>This is done to help users read back their answer more easily, in small chunks, or to help users meet the formatting requirements of something like a reference number.</p>
<p>While using multiple inputs can be helpful, most of the time it’s completely unnecessary and it has a number of drawbacks.</p>
<p>Here, I’ll explain why that is and I’ll show you how to help users check their answers and meet formatting requirements without using multiple inputs.</p>
<p>And I’ll provide guidance about when it’s actually beneficial to use multiple inputs.</p>
<h2>The problem with multiple inputs</h2>
<h3>1. They stop users from pasting easily</h3>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/form-design-multiple-inputs-versus-one-input/cut-and-paste.png" alt=""><figcaption>Left: pasting into a multi-input field means the value only ends up in first input and gets cropped. Right: pasting into a single input works appropriately.</figcaption></figure>
</div>
<p>Using multiple inputs stops users from being able to paste values easily.</p>
<p>JavaScript can be used to let users paste a value across multiple inputs.</p>
<p>However, multiple-input fields are not always implemented in this way – even if they were, users may not realise that they’re able to do this.</p>
<h3>2. They require more effort to use</h3>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/form-design-multiple-inputs-versus-one-input/more-effort.png" alt="Left: a multi-input field for card number with arrows showing how focus moves between the inputs. Right: a single input field without any arrows."><figcaption>Left: a multi-input field for card number with arrows showing how focus moves between the inputs. Right: a single input field without any arrows.</figcaption></figure>
</div>
<p>It takes effort to move from input to input. Remembering where you are and fixing mistakes also increases cognitive load.</p>
<p>Screen reader announcements are more frequent and verbose, because the group label is announced in combination with the individual input label.</p>
<p>Some sites use JavaScript to automatically move focus to the next input once the previous input is complete. But even though this seems like a good way to save users from moving focus manually it’s really troublesome.</p>
<p>Firstly, it can be disorientating because this is not how focus works by default. Normally, focus remains on the input until the user decides to move on.</p>
<p>Secondly, a lot of the time focus moves too early. What is technically complete – say the first 2 numbers of a sort code – may not be complete from the user’s point of view.</p>
<p>For example, if they typed the wrong number by accident, they‘d have to move back to the input manually – something that automatic focus was trying to avoid.</p>
<p>If you make it one input then all these problems go away because they can type freely or move back without focus moving and losing context.</p>
<h3>3. They can be difficult to label meaningfully</h3>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/form-design-multiple-inputs-versus-one-input/labels.png" alt=""><figcaption>Left: a multi-input field with meaningless labels that are hard to lay out. Right: a single input field doesn’t need additional labels.</figcaption></figure>
</div>
<p>Writing labels for each input can be challenging.</p>
<p>For example, the individual inputs of a sort code would be something like ‘Digits 1 and 2’. This isn’t particularly useful.</p>
<p>And there’s not enough room for these labels because fields that consist of multiple inputs tend to be small, to reflect the required length, and close together, to show they relate to each other.</p>
<p>You could visually hide the labels but this only solves the problem for sighted users – it still creates unnecessary noise for screen reader users.</p>
<p>If it’s a struggle to write a meaningful label, it should probably be one field anyway.</p>
<h2>Bad reasons to use multiple inputs and what to do instead</h2>
<p>There are 2 usability issues which can be solved by using multiple inputs for one field. However, you can get around these issues in other ways.</p>
<h3>1. To help users avoid error</h3>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/form-design-multiple-inputs-versus-one-input/errors.png" alt=""><figcaption>Left: field causes an error when using spaces instead of dashes. Right: field forgives the use of spaces instead of dashes.</figcaption></figure>
</div>
<p>Multiple inputs are used is to help users avoid error.</p>
<p>For example, imagine the user needs to type a reference number that is 10 digits long, in a 3-3-4 format, separated by dashes.</p>
<p>Using multiple inputs encourages the user to leave out unnecessary formatting such as spaces or dashes. This reduces the likelihood of error messages coming up, such as ‘Reference number must be in the format of 123-123-1234’.</p>
<p>But it’s better to forgive these sorts of mistakes by ignoring extra spaces or dashes, which lets users enter the value however they like.</p>
<h3>2. To help users check their answers</h3>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/form-design-multiple-inputs-versus-one-input/check-answers.png" alt=""><figcaption>Left: multiple inputs used in order to play back the answer in chunks. Right: a single input with the answer played back just underneath the input in chunks.</figcaption></figure>
</div>
<p>The other common reason to use multiple inputs is to help users read back the information they inputted to check it’s correct.</p>
<p>But you can help users with this without using multiple inputs by playing back the answer in chunks either underneath the field or on a <a href="https://design-system.service.gov.uk/patterns/check-answers/">check answers</a> page.</p>
<h2>Input masks are problematic</h2>
<p>Input masks are meant to help users avoid mistakes and check their answers.</p>
<p>They work by automatically placing characters into the input as the user types, like placing a dash after the user types the first 3 numbers of a reference number.</p>
<p>But I don’t recommend them because they may confuse users as a new character appears (visually or audibly in a screen reader) and they restrict users to a particular format.</p>
<p>Forms expert Caroline Jarrett has also seen <a href="https://twitter.com/cjforms/status/1239958611612307461">users struggle to work out why the information they typed changed when they thought that what they typed was an appropriate answer</a>.</p>
<h2>When to use multiple inputs</h2>
<p>Even though multiple inputs should be used as a last resort, that doesn’t mean they should never be used.</p>
<p>Multiple inputs should be used if one input causes users to struggle to answer the question or means it’s impossible to validate the answer.</p>
<p>Dates are a good example of this. The way a user writes dates depends on where they come from – 10/9/12 could mean 10 September or 9 October (assuming the year always comes last).</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/form-design-multiple-inputs-versus-one-input/dates.png" alt=""><figcaption>Left: a single input date field is ambiguous and impossible to validate accurately. Right: a multiple input date field is clear and can be valided accurately.</figcaption></figure>
</div>
<p>Using separate inputs removes ambiguity both to the user and the server doing the checking.</p>
<h2>Summary</h2>
<p>While using multiple inputs for one field may be necessary at times, doing so has a number of downsides.</p>
<p>If you need to play back the answer in chunks, do it underneath the field or separately on a check answers page.</p>
<p>Multiple inputs are usually completely unnecessary anyway. It’s better to give control to users and forgive simple formatting mistakes.</p>
<p><em>Thanks to <a href="https://twitter.com/EmmaFrith13">Emma Frith</a> for editing this.</em></p>
Routing conventions2020-04-18T00:00:00+00:00https://adamsilver.io/blog/routing-conventions/<p>Rails has a nice section on <a href="https://guides.rubyonrails.org/routing.html#crud-verbs-and-actions">naming routes and actions</a>.</p>
<table>
<thead>
<tr>
<th>Route</th>
<th>File</th>
<th>Used to show</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>/photos</code></td>
<td>index</td>
<td>List of photos</td>
</tr>
<tr>
<td><code>/photos/new</code></td>
<td>new</td>
<td>Form for creating new photo</td>
</tr>
<tr>
<td><code>/photos/:id</code></td>
<td>show</td>
<td>Show photo</td>
</tr>
<tr>
<td><code>/photos/:id/edit</code></td>
<td>edit</td>
<td>Form for editing photo</td>
</tr>
<tr>
<td><code>/photos/:id/delete</code></td>
<td>delete</td>
<td>Form for deleting photo</td>
</tr>
</tbody>
</table>
<p>But this doesn’t cover multi-step flows, so I’ll note here the way I do it.</p>
<p><em>(Note: I’ll focus on the GETs becuase all the POSTs should be to the same url with a redirect.)</em></p>
<h2>Creating a profile</h2>
<p>So let’s say you need to create your profile which is made up of your name and email address just to keep things simple enough to demonstrate.</p>
<table>
<thead>
<tr>
<th>Route</th>
<th>File path</th>
<th>Used to show</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>/profile/new</code></td>
<td>profile/new/name</td>
<td>Form asking for first and last name</td>
</tr>
<tr>
<td><code>/profile/new/email-address</code></td>
<td>profile/new/email-address</td>
<td>Form asking for email address</td>
</tr>
<tr>
<td><code>/profile/new/check-answers</code></td>
<td>profile/new/check-answers</td>
<td>Check answers page</td>
</tr>
<tr>
<td><code>/profile/new/confirmation</code></td>
<td>profile/new/confirmation</td>
<td>Confirmation page</td>
</tr>
</tbody>
</table>
<p>I still use <code>/new</code> to point to the first screen of the flow. But then I’ll sub directories to identify the additional steps.</p>
<h2>Edit your email address</h2>
<p>Now, let’s say you want to edit your email address which is part of your profile.</p>
<table>
<thead>
<tr>
<th>Route</th>
<th>File path</th>
<th>Used to show</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>/profile/edit-email</code></td>
<td>profile/edit-email/current-email-address</td>
<td>Form asking for current address</td>
</tr>
<tr>
<td><code>/profile/edit-email/new-email-address</code></td>
<td>profile/edit-email/new-email-address</td>
<td>Form asking for new address</td>
</tr>
<tr>
<td><code>/profile/edit-email/check-answers</code></td>
<td>profile/edit-email/check-answers</td>
<td>Check answers page</td>
</tr>
<tr>
<td><code>/profile/edit-email/confirmation</code></td>
<td>profile/edit-email/confirmation</td>
<td>Confirmation page</td>
</tr>
</tbody>
</table>
<p>Instead of <code>/edit</code> I’m using <code>/edit-email</code> to be specific about what part of the profile is being edited.</p>
<p>And again the first screen is just the intended action with sub directories for the additional steps.</p>
<p><em>(Note: if you were editing an item in a collection, just whack the id in the URL. Something like <code>/photos/:id/edit-photo</code>.)</em></p>
Rules for cookie banners2020-04-13T00:00:00+00:00https://adamsilver.io/blog/rules-for-cookie-banners/<p><a href="https://twitter.com/AliUK12">Alistair Laing</a> did a show and tell a few weeks back on the awesome cookie banner work he did for the <a href="https://www.find-postgraduate-teacher-training.service.gov.uk/">Find postgraduate teacher training</a> service.</p>
<p>Here’s what I noted. You must:</p>
<ol>
<li>Tell people the cookies are there</li>
<li>Explain what the cookies are doing and why</li>
<li>Get the user’s consent to store a cookie on their device</li>
</ol>
<p>You can still use cookies without asking for consent if they’re absolutely necessary. For example, if users need to login or if they need to add items to their shopping cart.</p>
<p><a href="https://ico.org.uk/for-organisations/guide-to-pecr/cookies-and-similar-technologies/">Read more about cookies</a></p>
Tips for running a good remote meeting2020-04-10T00:00:00+00:00https://adamsilver.io/blog/tips-for-running-a-good-remote-meeting%20copy/<p>Awesome tips from Julie Zhuo’s article, <a href="https://lg.substack.com/p/managing-remotely">managing remotely</a>:</p>
<p><strong>Cancel as many meetings as you can.</strong> Video meetings seem to sap more energy than in-person meetings and require more effort to stay focused, especially if your primary job is to listen.</p>
<p>I read an interesting explanation that this may be because we don’t feel the bodily presence of others in the room (through eye contact, etc.) so our brains have to work harder to convince ourselves to behave as normally would socially.</p>
<p>It could also be that it’s easier to sneak in a distraction like opening another tab, or simply that a bunch of pixels on the screen are less compelling than a full, real-life human in holding our attention.</p>
<p>Regardless, take a hard look at your recurring meetings—do you still need that series? Do you still need to call a meeting to disseminate information, or can you share a doc? Do you need 3 back-and-forth review meetings, or can you do a majority of the discussions via comments and chats and just call one meeting to make a decision?</p>
<p><strong>Send out a clear agenda for meetings ahead of time to give everyone time to prepare.</strong> If it’s hard to come up with an agenda, or the agenda looks sparse, consider cancelling the meeting.</p>
<p><strong>More documents, less powerpoints and keynotes.</strong> A document’s more narrative structure makes it easier to pass around and consume asynchronously. We can all do with fewer synchronous presentations right now.</p>
<p><strong>Establish team norms for getting airtime.</strong> For example, the meeting organizer goes “around-the-room” and specifically calls on individuals for their thoughts, or establish a system where folks who want to ask a question or share a comment can raise their hand on the screen or type 🙋🏻♀️or Q in the video call’s chat.</p>
<p><strong>Mute if you don’t expect to be saying much or you’re in a noisy environment.</strong></p>
<p><strong>Smile or nod more vigorously when someone speaks if you’re in a smaller meeting where you’ll be seen on the screen.</strong> It makes a big difference to someone who otherwise feels they’re presenting in an empty room.</p>
<p><strong>Take advantage of one key plus of remote meeting—you can take notes more easily!</strong> Don’t do it to the distraction of not paying attention to what’s being said, obviously, but no one is going to get distracted if you’re typing away.</p>
<p><strong>Turn off video cameras if anyone on the meeting has a bad Internet connection.</strong></p>
3 little rules for good team communication2020-03-30T00:00:00+00:00https://adamsilver.io/blog/3-little-rules-for-good-team-communication/<p>Bad communication creates more work and more stress.</p>
<p>Good communication creates less work and less stress.</p>
<p>So I thought I’d jot down 3 little rules for good team communication:</p>
<h2>1. If you have a thing, show the thing</h2>
<p>When I’m in a meeting and someone is describing a thing, I find it really hard to understand things.</p>
<p>But if someone is showing the thing they’re describing at the same time it’s so much easier.</p>
<p>The thing could by anything. For example, it could be:</p>
<ul>
<li>a user story</li>
<li>a problem from research</li>
<li>a prototype you want feedback on</li>
</ul>
<p>So if you have a thing, then show the thing.</p>
<h2>2. Avoid real time meetings, aim for async communication</h2>
<p>Look for ways to avoid meetings. Because unless you record (and edit) or take really good notes, then you’ll need follow up meetings to discuss the same thing again.</p>
<p>Meetings also only help people that were there at that time. And some people prefer having time to think before responding.</p>
<p>Where you can, write things down, share a Google Doc, or record a mini show and tell. This way people can collaborate asynchronously, in the their own time.</p>
<h2>3. Discuss the thing in context of the thing</h2>
<p>Where possible put the discussion on the thing being discussed.</p>
<p>Discussing a Github PR - put it on the PR.</p>
<p>Discussing a Trello card - put it on the card.</p>
<p>This helps understand what’s being discussed and means the discussion doesn’t get lost in email or chat.</p>
The problem with toast messages and what to do instead2020-03-15T00:00:00+00:00https://adamsilver.io/blog/the-problem-with-toast-messages-and-what-to-do-instead/<p><em>There’s been some <a href="https://twitter.com/adambsilver/status/1156819472231141376">comments about this on Twitter</a>.</em></p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-toast-messages-and-what-to-do-instead/snackbar.png" alt=""><figcaption>Snackbar as shown on Google’s Material Design guidelines</figcaption></figure>
</div>
<p>Snackbars—also known as toast messages—are little messages shown on top of the interface to give users feedback in response to an action they just did.</p>
<p>They’re designed to keep users focused on what they’re doing, which is why they’re small and automatically disappear after a few seconds.</p>
<p>But snackbars are problematic for lots of reasons. Here I’ll share what they are and offer some alternative solutions that don’t have these problems.</p>
<h2>Problem #1: They disappear automatically</h2>
<p>Snackbars automatically disappear after a number of seconds. This rushes users to read or access them which can cause anxiety and stress.</p>
<p>Snackbars are especially challenging for people with cognitive and motor impairments, and people working in a busy environment.</p>
<p>Take someone who gets a phone call just as a snackbar appears and misses the message. They won’t know what’s happened after they put the phone down.</p>
<h2>Problem #2: They’re hard to use via keyboard</h2>
<p>When snackbars appear, they don’t receive keyboard focus.</p>
<p>This makes it difficult for keyboard users to select the available actions because the snackbar is far away in terms of the tab sequence and will probably have disappeared by the time they get to it.</p>
<h2>Problem #3: They can change state erratically</h2>
<p>Snackbars can change multiple times within a short space of time which makes them difficult to use.</p>
<p>For example, when you send an email with Gmail, the snackbar status changes 3 times:</p>
<h3>It’s being sent</h3>
<p>Firstly, it says the email is being sent. The user can cancel or close the message.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-toast-messages-and-what-to-do-instead/email-being-sent.png" alt=""><figcaption>Gmail’s snackbar as an email is being sent</figcaption></figure>
</div>
<p>This state is shown for less than a second which makes it almost impossible to click cancel. And there’s little point in closing the snackbar because the next state appears almost instantly.</p>
<h3>It’s been sent but you can undo the send</h3>
<p>The snackbar updates to say the email has been sent. The user can undo, view the email or close the snackbar.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-toast-messages-and-what-to-do-instead/email-sent-with-undo-button.png" alt=""><figcaption>Gmail’s snackbar when it’s just been sent</figcaption></figure>
</div>
<h3>It’s been sent and you can’t undo the send</h3>
<p>After 5 seconds ‘Undo’ disappears, which leaves the user with the ability to view the email or close the snackbar.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-toast-messages-and-what-to-do-instead/email-sent-without-undo-button.png" alt=""><figcaption>Gmail’s snackbar when it’s been sent and 5 seconds has passed</figcaption></figure>
</div>
<p>It stays visible for 10 seconds before disappearing.</p>
<p>This erratic nature makes snackbars really hard to use.</p>
<h2>Problem #4: They’re distracting and can obscure the screen</h2>
<p>Snackbars block out some of the screen which may cause users to stop what they’re doing in order to dismiss them. Or they could just wait for them to disappear.</p>
<p>Either way, distracting the users like this can be highly frustrating.</p>
<h2>Problem #5: They’re hard to spot</h2>
<p>Snackbars are small and are shown at the bottom of the page—to the edge of the user’s view. This means there’s a risk the user won’t see them.</p>
<p>This problem is even worse for users who zoom in using a screen magnifier because there’s a good chance the snackbar will be completely out of view.</p>
<h2>Problem #6: They’re inconsistently located compared to other messages</h2>
<p>Most system messages appear at the top of the page above the content. But snackbars appear at the bottom of the screen.</p>
<p>As different messages will appear in different locations, users will need to keep an eye on both locations which increases cognitive load.</p>
<h2>Problem #7: It may not be clear what the message relates to</h2>
<p>If the user archives 2 emails in quick succession the toast message will not appear to update.</p>
<p>And this also makes the interface feel unresponsive.</p>
<div class="image">
<figure><video controls="">
<source src="https://adamsilver.io/assets/images/the-problem-with-toast-messages-and-what-to-do-instead/archiving-emails.mp4#t=0.001" type="video/mp4">
</video><figcaption>Archiving 2 emails in quick succession</figcaption></figure>
</div>
<h2>What to use instead</h2>
<p>The short answer is to:</p>
<ul>
<li>show a prominent message at the top of the page</li>
<li>draw focus to the message</li>
<li>keep the message on screen until the user navigates away (or dismisses it)</li>
</ul>
<p>The long answer is that alerts and notifications are complicated and need to take the specific context into account. More on this at the end.</p>
<h2>Handling constant feedback</h2>
<p>Sometimes you need to give users constant feedback.</p>
<p>For example, when working on a Google doc the file is constantly switching between saved and unsaved states.</p>
<p>While the user needs to know whether the file is saved or not they don’t want to be constantly interrupted while they’re writing.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-toast-messages-and-what-to-do-instead/google-doc.png" alt=""><figcaption>A Google doc showing a status area in the header</figcaption></figure>
</div>
<p>Google Docs puts a status message next to the menu at the top which works well in this context because it:</p>
<ul>
<li>doesn’t get in the way</li>
<li>doesn’t draw user’s attention</li>
<li>can be viewed at a glance</li>
<li>can be clicked on to see what’s previously happened</li>
</ul>
<h2>Summary</h2>
<p>Notifications are meant to give users confidence about an action they perform so that they can proceed with confidence.</p>
<p>But, snackbars take control away from the user and can cause stress— turning the interface into a race against time.</p>
<p>If the user is working on something that requires close-to-constant feedback—like working on a Google doc—then add a persistent status area to the UI that users can check at a glance.</p>
<p>In most other cases just show the message front and center, without it automatically disappearing so users can see it and act on their own terms.</p>
<p><em>Thanks to Amy Hupe for editing this.</em></p>
Building an accessible autocomplete control2020-02-02T00:00:00+00:00https://adamsilver.io/blog/building-an-accessible-autocomplete-control/<p><em>This is an excerpt from my book, Form Design Patterns.</em></p>
<p><em>This article starts in the middle of chapter 3, A Flight Booking Form where I’ve been looking at ways to let users enter a destination country.</em></p>
<p><em>Unfortunately, native HTML form controls just aren’t good enough for this type of interaction.</em></p>
<p><em>And so we need to build a custom autocomplete control from scratch.</em></p>
<p><em>A word of warning though: this is one of the hardest UI components I’ve ever had to make—they’re just way harder than they look.</em></p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/autocomplete.png" alt=""><figcaption>An autocomplete control showing 3 suggestions with the second option highlighted.</figcaption></figure>
</div>
<p>An autocomplete control shows suggestions that match what the user types as they type.</p>
<p>Users can select a suggestion to complete their entry quickly and accurately or keep typing to further refine the suggested options.</p>
<h2>The basic markup</h2>
<p>To make it work <a href="https://adamsilver.io/blog/javascript-isnt-always-available-and-its-not-the-users-fault/">when JavaScript is unavailable</a> we need to start with a native form control that browsers provide for free.</p>
<p>As explained earlier, there are too many options for radio buttons; a search box is slow to use and can lead to zero results; and datalist is too buggy - which leaves us with the select box.</p>
<pre><code><div class="field">
<label for="destination">
<span class="field-label">Destination</span>
</label>
<select name="destination" id="destination">
<option value="">Select</option>
<option value="1">France</option>
<option value="2">Germany</option>
<!-- … -->
</select>
</div>
</code></pre>
<h2>The enhanced markup</h2>
<p>When JavaScript is available, our yet-to-be-written <code>Autocomplete()</code> constructor will enhance the basic HTML into this:</p>
<pre><code><div class="field">
<label for="destination">
<span class="field-label">Destination</span>
</label>
<select name="destination" aria-hidden="true" tabindex="-1" class="visually-hidden">
<!-- options here -->
</select>
<div class="autocomplete">
<input aria-owns="autocomplete-options--destination" autocapitalize="none" type="text" autocomplete="off" aria-autocomplete="list" role="combobox" id="destination" aria-expanded="false">
<svg focusable="false" version="1.1" xmlns="http://www.w3.org/2000/svg">
<!-- rest of SVG here -->
</svg>
<ul id="autocomplete-options--destination" role="listbox" class="hidden">
<li role="option" tabindex="-1" aria-selected="false" data-option-value="1" id="autocomplete_1">
France
</li>
<li role="option" tabindex="-1" aria-selected="true" data-option-value="2" id="autocomplete_2">
Germany
</li>
<!-- more options here -->
</ul>
<div aria-live="polite" role="status" class="visually-hidden">
13 results available.
</div>
</div>
</div>
</code></pre>
<h3>Hiding the select box without stopping its value being submitted</h3>
<p>To hide the select box without stopping its value from being submitted to the server involves adding:</p>
<ul>
<li><code>visually-hidden</code> to hide it from sighted users</li>
<li><code>aria-hidden="true"</code> to hide it from screen reader users</li>
<li><code>tabindex="-1"</code> to stop keyboard users from being able to focus it</li>
</ul>
<p>If you’re using all 3 attributes, it’s normally better to use <code>display: none</code> because it achieves the same affect with cleaner code.</p>
<p>But this would stop the select box’s value from being submitted to the server. This is important because while the user won’t be interacting with the select box directly, its value still needs to be submitted for processing.</p>
<h3>Reassociating the label</h3>
<p>The select box’s <code>id</code> attribute is transferred over to the text box because the label must be associated to it so it’s read out in screen readers, and to increase the hit area of the control as explained in chapter 1, “A Registration Form”.</p>
<p>The text box’s <code>name</code> attribute isn’t needed because its value isn’t sent to the server – it’s purely for interaction purposes and is used as a proxy to set the select box value behind the scenes.</p>
<h3>Text box attribute notes</h3>
<p>The <code>role="combobox"</code> attribute will ensure the input is announced as a combo box. A combo box is “an <a href="https://developer.mozilla.org/en-US/docs/Web/Accessibility/AT-APIs/Gecko/Roles/ROLE_COMBOBO">edit control with an associated list box that provides a set of predefined choices</a>.”</p>
<p>The <code>aria-autocomplete="list"</code> attribute tells users that a list of options will appear. The <code>aria-expanded</code> attribute tells users whether the menu is expanded or collapsed by toggling its value between <code>true</code> and <code>false</code>.</p>
<p>The <code>autocomplete="off"</code> attribute stops browsers from showing their own suggestions, which would interfere with those offered by our component.</p>
<p>Finally, the <code>autocapitalize="none"</code> attribute stops browsers from automatically capitalizing the first letter. More on this in chapter 4, A Login Form.</p>
<p>The SVG icon is overlaid on the text box using CSS. The <code>focusable="false"</code> attribute fixes the issue that in Internet Explorer SVG elements are focusable by default.</p>
<h3>Menu attribute notes</h3>
<p>The <code>role="list"</code> attribute is used to communicate the menu as a list, because it will be populated with a list of options. Each option has a <code>role="option"</code> attribute.</p>
<p>The <code>aria-selected="true"</code> attribute tells users which option within the list is selected or not by toggling the value between <code>true</code> and <code>false</code>.</p>
<p>The <code>tabindex="-1"</code> attribute means focus can be set to the option programmatically when users press certain keys. We’ll look at keyboard interaction later.</p>
<p>The <code>data-option-value</code> attribute stores the select box option value. When the user clicks an autocomplete option, the select box value is updated to keep them in sync. This ties the interface (what the user sees) with the select box value (what the user can’t see) that’s sent to the server.</p>
<h3>Using a live region to make sure screen reader users know when options are suggested</h3>
<p>Sighted users will see the suggestions appear in the menu as they type, but the act of populating the menu isn’t determinable to screen reader users without leaving the text box to explore the menu.</p>
<p>To provide a comparable experience (inclusive design principle 1), we’ll use a live region as explained in “A Checkout Form.”</p>
<p>As the menu is generated, the live region will be populated with how many results are available; for example, “13 results available.” With this information to hand, users can decide to keep typing to narrow the results or to select a suggestion from the menu.</p>
<p>As the feedback is only useful to screen reader users, it’s hidden using <code>visually-hidden</code> again.</p>
<h2>Handling text input from the user</h2>
<p>When the user types into the text box, we need to listen for certain keystrokes using JavaScript.</p>
<pre><code>Autocomplete.prototype.createTextBox = function() {
this.textBox.on('keyup', $.proxy(this, 'onTextBoxKeyUp'));
};
Autocomplete.prototype.onTextBoxKeyUp = function(e) {
switch (e.keyCode) {
case this.keys.esc:
case this.keys.up:
case this.keys.left:
case this.keys.right:
case this.keys.space:
case this.keys.enter:
case this.keys.tab:
case this.keys.shift:
// ignore otherwise the menu will show
break;
case this.keys.down:
this.onTextBoxDownPressed(e);
break;
default:
this.onTextBoxType(e);
}
};
</code></pre>
<p>The <code>this.keys</code> object is a collection of numbers that correspond to particular keys by their names. This is to <a href="https://en.wikipedia.org/wiki/Magic_number_(programming)">avoid magic numbers</a>, which makes the code easier to understand.</p>
<p>The switch statement filters out <kbd>Escape</kbd>, <kbd>Up</kbd>, <kbd>Left</kbd>, <kbd>Right</kbd>, <kbd>Space</kbd>, <kbd>Enter</kbd>, <kbd>Tab</kbd>, and <kbd>Shift</kbd> keys. If it didn’t, the default case would run and incorrectly show the menu.</p>
<p>Instead of filtering out the keys we aren’t concerned with, we could’ve specified the keys that we are concerned with. But this would mean specifying a huge range of keys, which would increase the chance of one being missed.</p>
<p>We’re mainly interested in the last two statements: when the user presses <kbd>Down</kbd> and the default case above which means everything else (a character, number, symbol, and so on). In this case the <code>onTextBoxType()</code> function will be called.</p>
<pre><code>Autocomplete.prototype.onTextBoxType = function(e) {
// only show options if user typed something
if(this.textBox.val().trim().length > 0) {
// get options based on value
var options = this.getOptions(this.textBox.val().trim().toLowerCase());
// build the menu based on the options
this.buildMenu(options);
// show the menu
this.showMenu();
// update the live region
this.updateStatus(options.length);
}
// update the select box value which
// the server uses to process the data
this.updateSelectBox();
};
</code></pre>
<p>The <code>getOptions()</code> method (covered later) filters the options based on what the user typed.</p>
<h2>Composite controls should have a single tab stop</h2>
<p>The autocomplete control is a composite control which means it has different interactive and focusable parts. For example, users type in the text box and they move to the menu to select a suggestion.</p>
<p>Composite components should only have one tab stop like the <a href="https://www.w3.org/TR/wai-aria-practices-1.1/#kbd_generalnav">WAI-ARIA Authoring Practices 1.1 specification</a> says:</p>
<blockquote>
<p>A primary keyboard navigation convention common across all platforms is that the tab and shift+tab keys move focus from one UI component to another while other keys, primarily the arrow keys, move focus inside of components that include multiple focusable elements. The path that the focus follows when pressing the tab key is known as the tab sequence or tab ring.</p>
</blockquote>
<p>A set of radio buttons is a composite control too.</p>
<p>Once the first radio button is focused, users can use the arrow keys to move between each option. Pressing <kbd>Tab</kbd> will move focus to the next focusable control in the tab sequence.</p>
<p>Back to the autocomplete.</p>
<p>The text box is naturally focusable by the <kbd>Tab</kbd> key. Once focused, the user will be able to press the arrow keys to traverse the menu, which we’ll look at shortly.</p>
<p>Pressing <kbd>Tab</kbd> when the text box or menu option is focused should hide the menu to stop it from obscuring the content beneath when not in use. We’ll look at how to do this shortly.</p>
<h3>ARIA activedescendant doesn’t work for an autocomplete control</h3>
<p>A lot of autocompletes use the <a href="https://www.w3.org/WAI/GL/wiki/Using_aria-activedescendant_to_allow_changes_in_focus_within_widgets_to_be_communicated_to_Assistive_Technology">aria-activedescendant attribute</a> as an alternative way to make sure there’s just one tab stop.</p>
<p>It works by keeping focus on the component’s container at all times and referencing the currently active element.</p>
<p>But this doesn’t work for an autocomplete control because the text box is a sibling—not a parent—of the menu.</p>
<h2>Hiding the menu onblur doesn’t work</h2>
<p>The <code>onblur</code> event is triggered when the user leaves an in-focus element. In the case of the autocomplete, we could listen to this event on the text box.</p>
<p>The virtue of using the <code>onblur</code> event is that it will be triggered when the user leaves the field by pressing <kbd>Tab</kbd> and by clicking or tapping outside the element.</p>
<pre><code>this.textBox.on('blur', function(e) { // hide menu });
</code></pre>
<p>Unfortunately, the act of moving focus programmatically to the menu triggers the blur event, which will hide the menu. This makes the menu inaccessible to keyboard users.</p>
<p>One solution involves using <code>setTimeout()</code>, which lets us put a delay on the event. The delay gives us time to cancel the event using <code>clearTimeout()</code> should the user move focus to the menu within that time.</p>
<p>This stops the menu being hidden making it accessible again.</p>
<pre><code>this.textBox.on('blur', $.proxy(function(e) {
// set a delay before hiding the menu
this.timeout = window.setTimeout(function() {
// hide menu
}, 100);
}, this));
this.menu.on('focus', $.proxy(function(e) {
// cancel the hiding of the menu
window.clearTimeout(this.timeout);
}, this));
</code></pre>
<p>But this doesn’t work because there’s a problem with the blur event in iOS 10. It incorrectly triggers the blur event on the text box when the user hides the on-screen keyboard. This stops users from accessing the menu altogether.</p>
<p>The actual solution is next.</p>
<h2>Hiding the menu by listening out for the tab key instead</h2>
<p>Instead of hiding the menu using the <code>blur</code> event, we can use the <code>keydown</code> event to listen out for when the user presses the <kbd>Tab</kbd> key.</p>
<pre><code>this.textBox.on('keydown', $.proxy(function(e) {
switch (e.keyCode) {
case this.keys.tab:
// hide menu
break;
}
}, this));
</code></pre>
<p>But unlike the <code>blur</code> event, this solution doesn’t cover the case where users blur the control by clicking outside of it.</p>
<p>So we’ll cover that by listening to the document’s <code>click</code> event and making sure we only hide the menu if the user clicks outside of the control.</p>
<pre><code>$(document).on('click', $.proxy(function(e) {
if(!this.container[0].contains(e.target)) {
// hide the menu
}
}, this));
</code></pre>
<h2>Pressing down to focus the menu</h2>
<p>When the text box is focused, pressing <kbd>Down</kbd> triggers <code>onTextBoxDownPressed()</code>.</p>
<pre><code>Autocomplete.prototype.onTextBoxDownPressed = function(e) {
var option;
var options;
var value = this.textBox.val().trim();
/*
When the value is empty or if it exactly
matches an option show the entire menu
*/
if(value.length === 0 || this.isExactMatch(value)) {
// get options based on the value
options = this.getAllOptions();
// build the menu based on the options
this.buildMenu(options);
// show the menu
this.showMenu();
// retrieve the first option in the menu
option = this.getFirstOption();
// highlight the first option
this.highlightOption(option);
/*
When there’s a value that doesn’t have
an exact match show the matching options
*/
} else {
// get options based on the value
options = this.getOptions(value);
// if there are options
if(options.length > 0) {
// build the menu based on the options
this.buildMenu(options);
// show the menu
this.showMenu();
// retrieve the first option in the menu
option = this.getFirstOption();
// highlight the first option
this.highlightOption(option);
}
}
};
</code></pre>
<p>If the user presses <kbd>Down</kbd> without having typed anything, the menu will show all options and then focus the first one.</p>
<p>The same thing will happen if the user types an exact match. This will be rare because most users who spot the suggestions will select one as it’s quicker.</p>
<p>The <code>else</code> condition will populate options that match (if any), and then focus the first one. At the end of both scenarios <code>highlightOption()</code> is called, which we’ll look at shortly.</p>
<h2>Scrolling the menu</h2>
<p>The menu may contain hundreds of options. To ensure the menu items are visible, we’ll use the following styles.</p>
<pre><code>.autocomplete [role=listbox] {
max-height: 12em;
overflow-y: scroll;
-webkit-overflow-scrolling: touch;
}
</code></pre>
<p>The <code>max-height</code> property lets the menu grow to a maximum height. Once the content inside the menu surpasses that height, users can scroll the menu thanks to the <code>overflow-y: scroll</code> property.</p>
<p>The last, non-standard property enables momentum scrolling on iOS. This ensures the autocomplete control scrolls the same way as it would everywhere else.</p>
<h2>Selecting an option</h2>
<p>We’ll use <a href="https://javascript.info/event-delegation">event delegation</a> to listen to when the user clicks an option which is more efficient than adding a click event to each option.</p>
<pre><code>Autocomplete.prototype.createMenu = function() {
this.menu.on('click', '[role=option]', $.proxy(this, 'onOptionClick'));
};
Autocomplete.prototype.onOptionClick = function(e) {
var option = $(e.currentTarget);
this.selectOption(option);
};
</code></pre>
<p>The event handler retrieves the option (<code>e.currentTarget</code>) and hands it off to <code>selectOption()</code>.</p>
<pre><code>Autocomplete.prototype.selectOption = function(option) {
var value = option.attr('data-option-value');
this.setValue(value);
this.hideMenu();
this.focusTextBox();
};
</code></pre>
<p>The <code>selectOption()</code> method takes the option to be selected and extracts the value of the <code>data-option-value</code> attribute. It’s then passed to <code>setValue()</code> which populates the text box and hidden select box. Finally, the menu is hidden and the textbox is focused.</p>
<p>This same routine is performed when the user selects an option with the <kbd>Space</kbd> or <kbd>Enter</kbd> keys.</p>
<h2>Menu interaction via keyboard</h2>
<p>Once focus is within the menu, we can let users traverse the menu with the keyboard by listening to the keydown event.</p>
<pre><code>Autocomplete.prototype.createMenu = function() {
this.menu.on('keydown', $.proxy(this, 'onMenuKeyDown'));
};
Autocomplete.prototype.onMenuKeyDown = function(e) {
switch (e.keyCode) {
case this.keys.up:
// Do stuff
break;
case this.keys.down:
// Do stuff
break;
case this.keys.enter:
// Do stuff
break;
case this.keys.space:
// Do stuff
break;
case this.keys.esc:
// Do stuff
break;
case this.keys.tab:
// Do stuff
break;
default:
this.textBox.focus();
}
};
</code></pre>
<table>
<thead>
<tr>
<th>Key</th>
<th>Action</th>
</tr>
</thead>
<tbody>
<tr>
<td><kbd>Up</kbd></td>
<td>If the first option is focused, set focus to the text box. Otherwise set focus to the previous option.</td>
</tr>
<tr>
<td><kbd>Down</kbd></td>
<td>Focus the next menu option. If it’s the last menu option, do nothing.</td>
</tr>
<tr>
<td><kbd>Tab</kbd></td>
<td>Hide the menu.</td>
</tr>
<tr>
<td><kbd>Enter</kbd> or <kbd>Space</kbd></td>
<td>Select the currently highlighted option and focus the text box.</td>
</tr>
<tr>
<td><kbd>Escape</kbd></td>
<td>Hide the menu and focus the text box.</td>
</tr>
<tr>
<td>Everything else</td>
<td>Focus the text box (so users can continue typing).</td>
</tr>
</tbody>
</table>
<h2>Highlighting the focused options</h2>
<p>When the user focuses an option by pressing the <kbd>Up</kbd> or <kbd>Down</kbd> keys, <code>highlightOption()</code> is called.</p>
<pre><code>Autocomplete.prototype.highlightOption = function(option) {
// if there’s a currently selected option
if(this.activeOptionId) {
// get the option
var activeOption = this.getOptionById(this.activeOptionId);
// unselect the option
activeOption.attr('aria-selected', 'false');
}
// set new option to selected
option.attr('aria-selected', 'true');
// If the option isn’t visible within the menu
if(!this.isElementVisible(option.parent(), option)) {
// make it visible by setting its position inside the menu
option.parent().scrollTop(option.parent().scrollTop() + option.position().top);
}
// store new option for next time
this.activeOptionId = option[0].id;
// focus the option
option.focus();
};
</code></pre>
<p>The method performs several tasks.</p>
<p>First, it checks to see if there’s a previously active option. If so, the <code>aria-selected</code> attribute is set to <code>false</code>, which ensures the state is communicated to screen reader users.</p>
<p>Second, the new option’s <code>aria-selected</code> attribute is set to <code>true</code>.</p>
<p>As the menu has a fixed height, the newly focused option could be out of the menu’s visible area. So we check whether this is the case using <code>isElementVisible()</code>.</p>
<p>If it’s not visible, the menu’s scroll position is adjusted using <code>scrollTop()</code>, which makes sure it’s in view.</p>
<p>Next, the new option is stored so that it can be referenced later when the method is called again for a different option. And finally, the option is focused to ensure its value is announced in screen readers.</p>
<p>To provide feedback to sighted users we can use the same <code>[aria-selected=true]</code> CSS attribute selector like this:</p>
<pre><code>.autocomplete [role=option][aria-selected="true"] {
background-color: #005EA5;
border-color: #005EA5;
color: #ffffff;
}
</code></pre>
<p>Tying state and style together is good because it ensures that state changes are communicated interoperably. Form should follow function, and doing so directly keeps them in-sync.</p>
<h2>Filtering the options</h2>
<p>A good filter forgives small typos and mixed letter casing.</p>
<p>A quick recap: remember that the data driving the suggestions reside in the <code><option></code>s.</p>
<pre><code><select>
<option value="">Select</option>
<option value="1">France</option>
<option value="2">Germany</option>
</select>
</code></pre>
<p>As noted above, <code>getOptions()</code> is called when we need to populate the menu with matching options.</p>
<pre><code>Autocomplete.prototype.getOptions = function(value) {
var matches = [];
// Loop through each of the option elements
this.select.find('option').each(function(i, el) {
el = $(el);
// if the option has a value and the option’s text node matches the user-typed value
if(el.val().trim().length > 0 && el.text().toLowerCase().indexOf(value.toLowerCase()) > -1) {
// push an object representation to the matches array
matches.push({ text: el.text(), value: el.val() });
}
});
return matches;
};
</code></pre>
<p>The method takes the user-entered value as a parameter. It then loops through each of the <code><option></code>s and compares the value to the option’s text content (the bit inside the element).</p>
<p>It does so by using <code>indexOf()</code> which checks to see if it contains an occurence of the specified value. This means users can type incomplete parts of countries and still have relevant suggestions shown to them.</p>
<p>The value is trimmed and converted to lowercase, which means options will still be shown if the user has, for example, turned on caps lock. Users shouldn’t have to fix problems we can fix for them automatically.</p>
<p>Each matched option is added to the matches array, which will be used by the calling function to populate the menu.</p>
<h2>Supporting endonyms and typos</h2>
<p>An endonym is a name used by the people from a particular area of that area (or themselves or their language).</p>
<p>For example, Germany in German is “Deutschland.” We can follow inclusive design principle 5, “Offer choice,” by letting users type an endonym.</p>
<p>To do this, we first need to store it somewhere. We can put the endonym inside a data attribute on the <code><option></code> element.</p>
<pre><code><select>
<!-- more options -->
<option value="2" data-alt="Deutschland">Germany</option>
<!-- more options -->
</select>
</code></pre>
<p>Now we can change the filter function to check the alternative value like this:</p>
<pre><code>Autocomplete.prototype.getOptions = function(value) {
var matches = [];
// Loop through each of the option elements
this.select.find('option').each(function(i, el) {
el = $(el);
// if the option has a value and the option’s text node matches the user-typed value or the option’s data-alt attribute matches the user-typed value
if( el.val().trim().length > 0
&& el.text().toLowerCase().indexOf(value.toLowerCase()) > -1
|| el.attr('data-alt')
&& el.attr('data-alt').toLowerCase().indexOf(value.toLowerCase()) > -1 ) {
// push an object representation to the matches array
matches.push({ text: el.text(), value: el.val() });
}
});
return matches;
};
</code></pre>
<p>You can use the same attribute to store common typos if you like.</p>
<h2>Demo</h2>
<p>And that’s it. Here’s a <a href="https://nostyle.onrender.com/examples/autocomplete">demo</a>.</p>
Form design patterns webinar, course update, January resolutions2020-01-19T00:00:00+00:00https://adamsilver.io/blog/week-notes-16/<p>Webinar, course update, bullet journaling, job update, Veganuary and Red January.</p>
<h2>I did a webinar on form design patterns</h2>
<p>Vitaly from Smashing Magazine invited me to do a webinar on my book <a href="https://www.smashingmagazine.com/printed-books/form-design-patterns/">Form Design Patterns</a>.</p>
<p>I talked about why form design is so important and then I did a live redesign of the ASOS checkout flow.</p>
<p>It was really fun and I even though I was dreading the Q&A at the end, the audience asked a load of awesome questions which I think I managed to answer okay.</p>
<p>In fact, it went so well, that I might be doing another one.</p>
<p><a href="https://vimeo.com/385388156">Watch it here</a></p>
<p><em>(Note: FIRE stands for Financial Independence Retire Early. ‘Fire’, as in the hot stuff you shouldn’t touch, doesn’t play a significant role in my life :). You’ll understand why I mention this once you watch the webinar.)</em></p>
<h2>Design course update</h2>
<p>Some of you may know that I’m creating a course on interaction design.</p>
<p>But I’ve been worried about the amount of work it’s going to be—and I want to be sure that it’ll meet people’s expectations in terms of subject and content.</p>
<p>So my plan now is to create a couple of lessons and send it out to a few of my subscribers for some early feedback. Thanks to <a href="https://amyhupe.co.uk/">Amy</a> for the idea.</p>
<h2>Work is good</h2>
<p>I’ve been working at the Department for Education recently and our mission is to get more people into teaching.</p>
<p>So far I’ve helped the team get the ‘Apply for teacher training’ service into private beta, conducted an internal accessibility audit and made a bunch of improvements to the user experience.</p>
<p>I’m now focusing on the training provider and service support side of things.</p>
<p>There’s lots to do but I’m really enjoying the mission and working with such a friendly, talented and productive team.</p>
<h2>I started bullet journalling</h2>
<p>I’ve started bullet journalling and so far I’m really enjoying it. It doesn’t take much effort and it’s helped me focus and get things out of my head.</p>
<h2>I’m doing Veganuary and RED January</h2>
<p>At the tail end of last year, I decided to try and reduce my meat intake and adopt a more plant-based diet.</p>
<p>I’ve been surprised by how easy I’ve found it, especially having gone from being a huge meat eater.</p>
<p>So now I’m doing Veganuary to see if I can go a whole month without meat. So far so good.</p>
<p>I’m also doing RED (Run Every Day) January which is where you run (or do some form of exercise) every day. It’s going well but I’ve missed 2 days already.</p>
<p>That’s it, short and sweet.</p>
Building trust as a designer2019-11-25T00:00:00+00:00https://adamsilver.io/blog/building-trust-as-a-designer/<p>Being a designer is a constant balancing act. Whether it’s finding a balance between users’ needs and an organisation’s needs, or forgoing a better design to deliver something quickly, we’re always making trade offs.</p>
<p>One of the trade offs I’ve been thinking about lately has been the one between building trust with your users and fostering positive relationships with your teammates.</p>
<p>In an ideal world, we’d all be fighting the good fight and prioritising user needs at all costs, regardless of objections from others, or logistical constraints like time and money.</p>
<p>But in reality, it’s very hard to advocate for users if you’ve lost the trust of your team.</p>
<p>To do our work effectively, we need to build trust in both directions.</p>
<h2>Being a developer working with designers</h2>
<p>I began my career as a frontend developer. Designers would hand me mock-ups and I’d code them up. The designers I worked with were passionate about getting things to look right.</p>
<p>I took pride in making interfaces cross-browser, accessible and ‘pixel perfect’.</p>
<p>But I also learned that <a href="http://dowebsitesneedtolookexactlythesameineverybrowser.com/">websites don’t need to look the same in every browser</a> and that users don’t really care about pixels—not beyond being able to use and trust your product.</p>
<p>I tried to influence my team to consider user needs. But the designers I used to work with wanted absolute adherence to their designs.</p>
<p>They also valued the ability to code past constraints—embracing constraints and pushing back didn’t elicit the best response—and the conversation would quickly break down.</p>
<h2>Putting users first</h2>
<p>I was left frustrated, and hoped to find work that would let me prioritise user experience and simplicity.</p>
<p>And thankfully I managed to do that when I joined Just Eat. I worked closely with a designer called Mark, who shared my ethos, advocating for simplicity over pixel-perfect design.</p>
<p>It was possible to put users first and I was happy doing that.</p>
<h2>Facing constraints</h2>
<p>I’ve always faced constraints in some form, both as a designer and a developer.</p>
<p>One story I have involved <a href="https://adamsilver.io/blog/how-we-cut-our-mvp-in-half-to-launch-kidly/">cutting the scope of our MVP by 50% to launch Kidly</a>, an online store for baby products.</p>
<p>But more recently, working in government, I’ve had to deal with different kinds of constraints that I hadn’t encountered in the private sector.</p>
<p>Budget restrictions are a different ball game when you’re talking about taxpayers’ money, and policy and legislative requirements mean you can’t always take the most user-centred approach.</p>
<p>I met some amazing designers, doing the best work they could within the parameters they faced, and I began to empathise with the need to accept constraints and respect the limitations of those around me.</p>
<h2>Designing the impossible</h2>
<p>Some years later, I came across Craig Abbott’s article, <a href="http://www.craigabbott.co.uk/designing-the-impossible-makes-it-possible">designing the impossible</a>.</p>
<p>Craig says it’s our job as designers to push for better, a lot better. Not to bow down to pressure when developers push back on our designs because of [insert technical constraint here].</p>
<p>And it’s true. If you embrace every constraint that comes your way, you’ll only ever design a subpar experience.</p>
<p>But, pushing for the impossible isn’t always conducive to building trust with your colleagues. And it got me thinking some more.</p>
<h2>Finding a balance</h2>
<p>We gain trust with teammates by being valuable and practical. By being a team player. It’s a difficult balancing act when you want to help your colleagues do the basic thing but also push to make things better.</p>
<p>I’ve been to many backlog refinement sessions, where my work has been scaled back to deliver faster.</p>
<p>And I’ve been okay with that. Not just because I want to deliver faster, but I want to build trust by taking my ego out of the equation — something that I learnt from Mark.</p>
<p>But I sometimes wonder if I should have fought harder to make sure our users get a better experience.</p>
<p>Is it my job to be realistic and empathetic to constraints, or to be the persistent voice of the user who makes stuff better at the cost of momentum and team morale?</p>
<p>As with most things, it depends.</p>
<p>The length of time spent on a team, your team’s size and capacity, and the deadlines you’re facing, all factor into the equation.</p>
<p>I’ve found both approaches are valid, and which I choose depends on the situation at hand.</p>
<h2>Building trust</h2>
<p>Being a designer is full of challenges and tradeoffs. But that’s why it’s a job. That’s why we call it work.</p>
<p>We have to learn to push for the impossible while navigating and respecting the constraints of the people and organisations we work with.</p>
<p>Working out when to push our products to work harder for our users, or let go and accept a bit less is a skill. But it’s a skill worth honing, and one I’m still continuing to learn.</p>
<p>Push too hard and things fall apart. But avoid conflict and we may as well not be there.</p>
<p>Thankfully trust can be built up over time. And it’s reciprocal. So when you give it, you tend to get some back.</p>
<p>By working to give trust and to earn it back, with both our users and our teammates, we create the space we need to do our best work.</p>
<p><em>Thanks to <a href="https://amyhupe.co.uk/">Amy Hupe</a> for turning my messy thoughts into something coherent.</em></p>
JavaScript isn’t always available and it’s not the user’s fault2019-11-04T00:00:00+00:00https://adamsilver.io/blog/javascript-isnt-always-available-and-its-not-the-users-fault/<p><em>There’s been some <a href="https://twitter.com/adambsilver/status/1191281844794384384">comments about this on Twitter</a>.</em></p>
<p>You might have heard that the percentage of users without JavaScript is approximately 1% and that these people actively turn it off. And on that basis that it’s okay to exclude them.</p>
<p>First of all, 1% of a large number is still a large number. A 1% increase in users is not usually something to be sniffed at.</p>
<p>But more importantly, the problem is less about the 1% of <em>users</em> who always visit your site without JavaScript and more about the 1% of <em>visits</em> to your site which result in users experiencing your site without JavaScript. And through no fault of their own.</p>
<p>For Buzzfeed, for example, 1% of visits is actually <a href="https://twitter.com/philhawksworth/status/990890920672456707?lang=en">13 million requests per month</a>.</p>
<p>Stuart Langridge visualises the difference between 1% of <em>users</em> not having JavaScript versus 1% of <em>visits</em> not having JavaScript in <a href="https://kryogenix.org/code/browser/why-availability/">why availability matters</a>.</p>
<p>Crucially, these users don’t turn off JavaScript nor are they using an old feature phone. They’re just like you and me.</p>
<p>Here I’ll jot down all of the reasons users experience sites as if they don’t have JavaScript and at the end I’ll explain what we can do about it.</p>
<h2>1. The browser doesn’t recognise your JavaScript code</h2>
<p>If your JavaScript file contains methods or properties the browser doesn’t understand, the script won’t run.</p>
<p>This happens a lot because every day new browsers come out and new websites are published which rely on new APIs and JavaScript frameworks that will only work in a narrow range of cutting edge browsers.</p>
<p>All it takes is for one method not to be recognised and users experience the site as if JavaScript is off.</p>
<h2>2. Browser extensions can break JavaScript</h2>
<p>Browser plugins use JavaScript to change and add functionality to web pages. But, this is at risk of breaking depending on how well the site’s JavaScript and the plugin’s JavaScript is written.</p>
<p>Specifically, if JavaScript is written without feature detection, it <a href="https://adamsilver.io/blog/thinking-differently-about-progressive-enhancement/#feature-detection">can cause the interface to break</a>.</p>
<p>As a result, users get the ‘JavaScript off’ experience.</p>
<h2>3. Some browsers turn off JavaScript on slow connections</h2>
<p>Chrome on Android, for example, <a href="https://www.xda-developers.com/google-chrome-android-disable-javascript-2g-connections/">automatically turns off JavaScript on slow connections</a> in order to speed up page load times.</p>
<p>Again, under these circumstance users get the ‘JavaScript off’ experience. So all the links you put inside a hamburger menu will be laid out somewhere (or not at all) depending on your implementation.</p>
<h2>4. JavaScript might fail to download</h2>
<p>Like any HTTP call, the request for your site’s JavaScript can fail to load. This can happen—and has happened to me—on a train because the connection stops before the script is downloaded.</p>
<p>Similarly, Content Delivery Networks (CDN) can go down, so even if <em>your</em> connection is stable, the server responsible for sending back JavaScript might not be.</p>
<p>Intermittent connection or intermittent server means: the user gets the ‘JavaScript off’ experience.</p>
<h2>5. Corporate firewalls and mobile operators block JavaScript</h2>
<p>Some corporate firewalls block or change JavaScript files before they are sent to the browser.</p>
<p>For example, <a href="https://www.theguardian.com/technology/2014/jan/28/sky-broadband-blocks-jquery-web-critical-plugin">Sky Broadband once accidentally blocked Jquery</a> which caused lots of sites to break. And this is another one I’ve experienced myself—when I worked at T-Mobile they blocked certain scripts to improve performance.</p>
<p>It’s not the users’ fault, but once again they are denied the use of JavaScript.</p>
<h2>6. Some browsers don’t run JavaScript</h2>
<p><a href="https://en.wikipedia.org/wiki/Lynx_(web_browser)">Some browsers, such as Lynx, don’t run JavaScript</a>. So if your site shows nothing without JavaScript, then that’s what users will get— nothing.</p>
<p>(And that’s just one of the problems that I noted in my discussion of <a href="https://adamsilver.io/blog/the-problem-with-single-page-applications/">single page applications</a>.)</p>
<h2>What to do about it</h2>
<p>The more your site relies on JavaScript, the more fatal the experience is likely to be when JavaScript is unavailable.</p>
<p>So the first thing to do is follow Tim Berners-Lee’s <a href="https://www.w3.org/DesignIssues/Principles.html">rule of least power</a> by doing as much work further down the stack as we can.</p>
<p>In other words, if you’re dealing with text, images, video and forms—which is most of us, most of the time—then render the HTML on the server. No JavaScript needed, more robust and more performant.</p>
<p>For the remaining enhancements that genuinely need JavaScript to work, use <a href="https://adamsilver.io/blog/thinking-differently-about-progressive-enhancement/#feature-detection">feature detection</a> to stop browsers that aren’t able to apply the enhancement and therefore breaking the interface unnecessarily.</p>
<h2>Summary</h2>
<p>While some users actively turn off JavaScript, the vast majority of users experience an equivalent experience through no fault of their own.</p>
<p>It’s not a matter of <em>if</em> your users don’t have JavaScript—it’s a matter of <em>when</em> and how often.</p>
<p>The answer to that is around 1% of the time.</p>
<p>If you had an application bug which occurred 1% of the time, you’d fix it. No team I’ve come across would put up with that level of reliability.</p>
<p>The same goes for JavaScript. It’s not about people who turn it off. It’s about the nature of the web itself.</p>
<p>When it fails, it’s our job to make sure we don’t exclude users from accessing the products we make by designing resilient interfaces.</p>
<p><em>Thanks a lot to <a href="https://www.effortmark.co.uk/">Caroline Jarrett</a> for her feedback and suggestions.</em></p>
Where to put buttons on forms2019-09-16T00:00:00+00:00https://adamsilver.io/blog/where-to-put-buttons-on-forms/<p><em>There’s been some <a href="https://twitter.com/adambsilver/status/1173503130069295105">comments about this on Twitter</a>.</em></p>
<p>Button placement on forms is often ignored or prioritised based on what looks good.</p>
<p>But button placement can make or break a form, and a form can make or break a user’s experience. That’s why it’s essential to get it right.</p>
<p>This is more challenging that in sounds because it depends on the buttons and the form in question.</p>
<p>It also requires us to analyse different forms holistically. Otherwise we could end up with the same button appearing in different places which is inconsistent and confusing.</p>
<p>Here I’ll explain where to put buttons across a range of different forms based on research and best practice.</p>
<h2>Align the primary button to the left edge of the inputs</h2>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/button-placement/alignment.png" alt=""><figcaption>Left: a right aligned button (not recommended). Right: a left aligned button (good).</figcaption></figure>
</div>
<p>In his article reporting on eye-tracking research, Luke Wroblewski says the <a href="https://www.lukew.com/ff/entry.asp?571">primary button should be aligned with the left-hand edge of the input</a>:</p>
<blockquote>
<p>“illuminate a clear path to completion. Aligning inputs and actions with a strong vertical axis clearly communicates how to go about completing a form.”</p>
</blockquote>
<p>This layout also helps screen magnifier users to see it without having to pan across.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/button-placement/zoomed.png" alt=""><figcaption>Left: right aligned button when zoomed in—can't be seen. Right: left aligned button when zoomed in—still visible.</figcaption></figure>
</div>
<h2>Put the back button above the form</h2>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/button-placement/back-button.png" alt=""><figcaption>Left: back button next to the primary button (not recommended). Right: back button above the form (good).</figcaption></figure>
</div>
<p>Some forms or questionnaires appear across multiple pages and some people want to go back to check or change their answers.</p>
<p>Unfortunately some users don’t trust the browser back button because of their experiences of poorly designed forms that lose data when they click back. The solution is to provide a form-specific back button.</p>
<p><a href="https://surveypractice.wordpress.com/2011/02/14/navigation-buttons/">Research carried out by Mick Couper, Reg Baker and Joanne Mechling shows</a> that placing the back button to the right of the primary button is confusing and it should go either to the left or underneath instead.</p>
<p>Underneath is preferable because it keeps the primary button consistently located and lets keyboard users tab directly to it from the last field.</p>
<p>But their research did not include an option with the back button at the top of the page.</p>
<p>Joe Lanman, a designer at the Government Digital Service, put the back button at the top of the Register To Vote exemplar digital service. It’s now the standard approach for all government services.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/button-placement/register-to-vote.png" alt=""><figcaption>A question page from the Register To Vote service which shows the back link at the top of the page.</figcaption></figure>
</div>
<p>Joe said putting the back button at the top works well because it’s:</p>
<ul>
<li>in a similar place to where most browsers put the browser back button</li>
<li>most likely to be needed soon after the user lands on a page that looks wrong or if the user wants to check what they just entered</li>
<li>probably not needed once the user fills out the form—if they fill out the form and click back, they will lose their answers</li>
</ul>
<p>This approach clearly differentiates the back button from the primary button which should <a href="https://lawsofux.com/hicks-law">decrease the time it takes users to proceed</a>. And it makes room for additional buttons when needed which I’ll cover later.</p>
<h2>Put tangentially related actions above the form</h2>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/button-placement/tangential-links.png" alt=""><figcaption>Left: ‘forgot password’ link within the form (not recommended). Right: ‘forgot password’ link outside of the form (good).</figcaption></figure>
</div>
<p>Some forms have actions that don’t submit data and are only tangentially related to the form itself.</p>
<p>For example, a ‘forgot password’ link on a login form lets users reset their password—but it’s not part of the login process itself.</p>
<p>You’ll often see the ‘forgot password’ link next to the password field, but this is problematic because users:</p>
<ul>
<li>expect the tab key to focus the next field/button</li>
<li>might have to scroll to find the link</li>
<li>might waste time typing in their email address before clicking the link</li>
</ul>
<p>Putting the link above the form solves all of these problems.</p>
<h2>Place extra buttons based on what they do</h2>
<p>Forms with multiple buttons are problematic.</p>
<p><a href="https://lawsofux.com/hicks-law">The time it takes to make a decision increases with the number and complexity of choices</a>, so extra buttons add extra choice and extra time.</p>
<p>Also, keyboard users can’t be sure which action will be taken when they press the <a href="https://adamsilver.io/blog/forms-with-multiple-submit-buttons-are-problematic/">enter key to submit the form</a>.</p>
<p>That said, sometimes having multiple buttons is necessary.</p>
<p>Thinking about what the buttons do makes it easier to decide where to put them.</p>
<p>Let’s look at 3 examples that need different treatment.</p>
<h3>1. Put the cancel button below the primary button</h3>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/button-placement/cancel-button.png" alt=""><figcaption>Left: cancel button alongside the primary button (not recommended). Right: cancel button underneath the primary button (good).</figcaption></figure>
</div>
<p>Luke Wroblewski’s research shows the cancel button should be to the right of the primary button and styled less prominently as a link.</p>
<p>But putting the cancel button below the primary button has some advantages:</p>
<ul>
<li>Firstly, it conforms to forms expert, Caroline Jarrett’s rule, <a href="http://www.effortmark.co.uk/seven-basic-best-practices-buttons/">make it harder to find destructive buttons</a>.</li>
<li>Secondly, as explained in the back button and additional links sections, the cancel button is not directly related to the form itself so it makes sense to put it below the primary button.</li>
<li>Lastly, it frees up space for other, directly related buttons to be on the same row. If you put lots of buttons in a row then it’s harder for users to work out which is most important.</li>
</ul>
<h3>2. Put the ‘add another’ button above the primary button</h3>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/button-placement/add-another-button.png" alt=""><figcaption>Left: ‘add another’ button next to the primary button (not recommended). Right: ‘add another’ button just above the primary button (good).</figcaption></figure>
</div>
<p>Sometimes users need to add additional information. For example, if they need to add the names of their family members to a booking.</p>
<p>Putting the ‘add another’ button above the primary button has the following benefits:</p>
<ul>
<li>users don’t have to go past the primary button to select it, which conforms to Caroline Jarrett’s rule, <a href="http://www.effortmark.co.uk/seven-basic-best-practices-buttons/">put buttons in a sensible order</a></li>
<li>the primary button stays consistently located on the left hand side as explained earlier</li>
<li>like Erik Kennedy explains in The 3 Laws of Locality, <a href="https://learnui.design/blog/the-3-laws-of-locality.html#1-put-the-control-where-it-affects-change">it’s located where it affects change</a>—next to the field being cloned</li>
</ul>
<h3>3. Put the ‘save and exit’ button next to the primary button</h3>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/button-placement/save-and-exit-button.png" alt=""><figcaption>Left: ‘save and exit’ button button above the primary button (not recommended). Right: ‘save and exit’ button next to the primary button (good).</figcaption></figure>
</div>
<p>Sometimes users might need to <a href="https://github.com/alphagov/govuk-design-system-backlog/issues/87">save their progress</a> on a long form.</p>
<p>Putting the ‘save and exit’ button above the primary button implies it’s more important, when it isn’t.</p>
<p>Putting it below can cause an unwieldy list of stacked buttons and uses the area reserved for the cancel button.</p>
<p>That leaves us with putting it next to the primary button which makes sense as the action is directly related to the form.</p>
<h2>In some single field forms put the button next to the input</h2>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/button-placement/single-field-form.png" alt=""><figcaption>Left: button below search box (not recommended). Right: button next to search box (good).</figcaption></figure>
</div>
<p>On rare occasions, you can put the button next to the input, which is often seen in global search forms in site headers.</p>
<p>While there’s nothing especially wrong with putting the button below the input, putting it next to it saves space and looks a bit neater.</p>
<p>But do not do this on standard forms that happen to have just 1 field. It’s inconsistent and unconventional.</p>
<h2>Put buttons on multi select forms above the form</h2>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/button-placement/multi-select-buttons.png" alt=""><figcaption>Left: multi-select buttons below the list (not recommended). Right: multi-select buttons above the list (good).</figcaption></figure>
</div>
<p>Multi-select forms let users select and action multiple items at once. For example, in Gmail you can select multiple emails and archive them in one go.</p>
<p>In this special case, put the buttons above the form.</p>
<p>This is another example that works because of Erik Kennedy’s rule, <a href="https://learnui.design/blog/the-3-laws-of-locality.html#2-if-a-control-affects-change-across-an-entire-area-put-it-above-that-area">if a control affects change across an entire area, put it above that area</a><em>.</em></p>
<p>Putting the buttons above the list makes them easier to discover and leaves room at the bottom for pagination controls which are often needed in such interfaces.</p>
<h2>Summary</h2>
<p>In this article, we’ve looked at where to place buttons across a range of different forms.</p>
<p>Whether it’s 1 button on a standard form or multiple buttons on a multi-select form, button placement is crucial and needs due care and attention.</p>
<h3>Checklist</h3>
<ul>
<li>Align the primary button to the left edge of the inputs</li>
<li>Put the back button above the form</li>
<li>Put tangentially related actions above the form</li>
<li>Place extra buttons based on what they do</li>
<li>In some single field forms put the button next to the input</li>
<li>Put buttons on multi select forms above the form</li>
</ul>
<p><em>Thanks to Caroline Jarrett for helping me write this.</em></p>
Launching a service, contribution the bank details pattern, design system community building2019-09-15T00:00:00+00:00https://adamsilver.io/blog/week-notes-15/<p>It’s been ages since I wrote one of these.</p>
<p>I’ve actually had things to say, but just not mustered up the energy to sit down and write.</p>
<p>So this weeknote covers more than just this week, but hey, rules are there to be broken.</p>
<h2>What’s gone well recently</h2>
<h3>Launching the child funeral fund service in 6 weeks</h3>
<p>Last time I mentioned a few successes we had around designing the form that lets parents and friends of the family claim the cost of a child’s funeral.</p>
<p>We were working to a very tight and fixed deadline for this to make sure we met the policy launch date. I’m so chuffed with the work the team and I did on this and I’ve got a blog post and case study coming out on this soon.</p>
<h3>Contributing a bank details pattern to the GOV.UK Design System</h3>
<p>When designing the child funeral fund service, we had to ask users for their bank details to let them claim back the incurred cost. This includes making payments to non-UK bank accounts.</p>
<p>From our research, we could see that there were lots of services that do this, but they all do it slightly differently—and we couldn’t find any that asked for non-uk bank account details.</p>
<p>In theory it’s just a bunch of form fields. But, like everything else, I hasten to add, this turned out to be far more complicated than it first appeared.</p>
<p>We were confident enough in our approach to contribute a pattern to the GOV.UK Design System.</p>
<p>That way, new services will find it easier to design this sort of thing for their users and we won’t end up forgetting all the things we’ve just learnt from tackling this problem.</p>
<p>I worked really closely with <a href="https://twitter.com/GemmaHutley">Gemma</a> (user research) and <a href="https://twitter.com/amanda_kerry">Amanda</a> (content design) to:</p>
<ul>
<li>research and speak to other teams and departments including DWP, HMRC and GOV.UK Pay at GDS about their designs</li>
<li>refine and unify the pattern based on everything we found out</li>
<li>create guidance for the GOV.UK Design System pattern page</li>
</ul>
<p>It was a challenge working out what falls in scope for this pattern. Like, there’s a lot of additional things to consider when asking for bank details in order to set up a Direct Debit. But we left those details out—maybe there will be a separate pattern for that, that references the bank details pattern.</p>
<p>Similarly, it was a balancing act trying to decide how much detail to provide around things like why we chose to give users 1 input as opposed to 3 for the sort code field.</p>
<p>After a lot of back and forth, I’m really proud of what we produced. It’ll hopefully be launched in a few weeks time.</p>
<h3>Slowly building a community around the MOJ Design System</h3>
<p>We have a small but dedicated team now working on the MOJ Design System, which is a huge milestone considering it’s been done in people’s spare time up to now.</p>
<p>In the last few weeks, we’ve onboarded 13 people to the working group. They’re responsible for reviewing new components and patterns before they go into the MOJ Design System.</p>
<p>Their first task was to review the bank details pattern before we sent it off to the GOV.UK Design System team for review. It was really helpful because as I said earlier, we had some concerns around certain aspects of the guidance.</p>
<p>Sharing it with the working group meant that we were able to get some really useful feedback and a helpful sense check.</p>
<p>We’ve also been reaching out to designers and developers to encourage people to contribute to the MOJ Design System. Everyone I’ve spoken to so far is keen, so I’m looking forward to working with them over the coming months.</p>
<p>We also have a Slack channel for the MOJ Design System where people can make suggestions and get support. And I’ve definitely noticed an increase in activity, which is another good sign that the community is growing.</p>
<h3>Collaborating with Caroline Jarrett on a new article</h3>
<p><a href="https://twitter.com/cjforms">Caroline Jarrett</a>, if you don’t already know, is an expert on form design. We got chatting on Twitter about where to put buttons in forms.</p>
<p>Caroline suggested I write an article on this topic. Buttons, forms—what more could anyone want to write about?</p>
<p>But even better is that Caroline agreed to review my article. I’ve been wanting to work with Caroline for ages so this has been sweet. I’ve learnt a lot from her in writing just this 1 article.</p>
<p>I look forward to publishing it very soon.</p>
<h2>What’s not gone so well</h2>
<p>Only 1 thing has not gone well and that’s doing too many things at once. In the last 2 weeks, on any given day I’ve probably worked on 4 or 5 different things.</p>
<p>Context switching like this is not only draining, but less productive. Don’t get me wrong, While I’m getting things done I’ve not been able to work on deeper challenges that require a more focused effort.</p>
<p>I’ll attempt to sort this out by foreplanning my week better.</p>
<h2>Things I’d like to read and watch again</h2>
<ul>
<li><a href="https://www.figma.com/blog/design-critiques-at-figma/">Design crits at Figma</a></li>
<li><a href="https://articles.uie.com/beans-and-noses/">Beans and noses</a></li>
<li><a href="https://www.youtube.com/watch?v=MdwO6LhA4_4&list=FL5podOJHf838DfMFAuGIktg&index=2&t=0s">Psychology and your Product</a></li>
</ul>
The problem with tooltips and what to do instead2019-08-26T00:00:00+00:00https://adamsilver.io/blog/the-problem-with-tooltips-and-what-to-do-instead/<!-- *There’s been some [comments about this on Twitter](https://twitter.com/adambsilver/status/1151797374043525121).* -->
<p>In 2006 I coded up my very first tooltip.</p>
<p>Tooltips are messages that appear when the user hovers over part of an interface—usually an icon—to explain how certain things work or what they mean.</p>
<p>Despite some of the coding challenges, I thought tooltips were a cool way to declutter the UI.</p>
<p>But what I didn’t do was think about how they impact UX.</p>
<p>How are keyboard or touch screen users meant to operate them? What if the user wants to read the tooltip at the same time as filling out a text input?</p>
<p>Turns out there are 6 good reasons to avoid this pattern.</p>
<p>Here I’ll explain what they are and what to do instead if you want to give users a good experience.</p>
<h2>1. They’re hard to spot</h2>
<p>Some users won’t notice a tooltip which means there’s a high risk they’ll never see the content it contains.</p>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-tooltips-and-what-to-do-instead/spot.png" alt=""><figcaption>Tooltips are hard to spot</figcaption></figure>
</div>
<h2>2. They require effort</h2>
<p>Let’s say users need additional information to help them satisfy a password field with complex rules. Making users reveal the content first is an unnecessary burden.</p>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-tooltips-and-what-to-do-instead/effort.png" alt=""><figcaption>Revealing content requires effort</figcaption></figure>
</div>
<h2>3. They obscure the screen</h2>
<p>Tooltips are shown on top of the screen blocking some of the interface.</p>
<p>This means you can’t read the tooltip and operate the rest of the screen at the same time.</p>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-tooltips-and-what-to-do-instead/obscure.png" alt=""><figcaption>Part of the screen is obscured</figcaption></figure>
</div>
<p>Users have to work hard to remember the hint, or switch between 2 modes of operation repeatedly.</p>
<h2>4. They could be cropped in small screens</h2>
<p>As tooltips are overlaid, there’s a chance they’ll be cropped by smaller viewports.</p>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-tooltips-and-what-to-do-instead/cropped.png" alt=""><figcaption>Tooltips could be cropped</figcaption></figure>
</div>
<h2>5. They don’t work well with speech recognition</h2>
<p>Tooltips that consist of icons need an accessible label. But even if you have one, voice users have to interpret what they see and guess what it is.</p>
<div class="image" style="max-width: 450px">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-tooltips-and-what-to-do-instead/speech.png" alt=""><figcaption>Icons are hard to target with speech recognition software</figcaption></figure>
</div>
<p>Imagine a bell icon. It’s not clear whether users should say ‘Click bell’, ‘Click notifications’ or something else entirely in order to activate it.</p>
<h2>6. Revealing content on hover is inaccessible</h2>
<p>Firstly, you need to use a mouse or other pointing device to use a tooltip which excludes keyboard and touch screen users.</p>
<p>Secondly, hovering is not always an intention to activate a control. The user might move the cursor over a tooltip which accidentally activates it.</p>
<p>Thirdly, it requires fine motor skills to operate. Users have to move their mouse accurately over the hit area and hold it steady to avoid accidentally hiding it.</p>
<p>Fourthly, it’s not possible for screen magnifier users to move their field of view without hiding the tooltip.</p>
<p>Finally, users can’t select or interact with the content within the tooltip.</p>
<p>You could provide a comparable experience for keyboard users by showing the tooltip on focus. But this is unconventional and still excludes touch screen users.</p>
<h2>What to do instead</h2>
<h3>1. Do the hard work so users don’t have to</h3>
<p>Having content just to help users understand your interface is a sign of bad design.</p>
<p>If you’re using an icon to convey meaning, use text instead, or use icons and text together.</p>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-tooltips-and-what-to-do-instead/simplify.png" alt=""><figcaption>Top: just an icon (bad). Middle: just text (good). Bottom: text and icon (good).</figcaption></figure>
</div>
<p>If you’ve got one complex question, can you make it simpler by asking several shorter questions?</p>
<p>Either way, do the hard work to make it simple.</p>
<h3>2. Just show the extra content</h3>
<p>If you really do need to provide users with clarification <a href="https://adamsilver.io/blog/user-interfaces-hiding-content-should-be-a-last-resort/">just show the content</a>.</p>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-tooltips-and-what-to-do-instead/show.png" alt=""><figcaption>Top: content in a tooltip (bad). Bottom: content inline (good)</figcaption></figure>
</div>
<p>Give users what they need when they need it.</p>
<h3>3. Use a better pattern for toggling content</h3>
<p>If (1) and (2) don’t work, use an <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details">inline toggle component</a>.</p>
<div class="image" style="max-width: 600px">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-tooltips-and-what-to-do-instead/toggle.png" alt=""><figcaption>A toggle component</figcaption></figure>
</div>
<p>This is better because it:</p>
<ul>
<li>doesn’t rely on iconography alone</li>
<li>won’t be cropped by the viewport</li>
<li>doesn’t obscure content</li>
<li>is activated on click which works well in all contexts</li>
</ul>
<!-- ## Summary
While tooltips provide a way to hide and show content, needing to clarify how your interface works indicates bad design.
At best, tooltips make users jump through a series of hurdles in order to access the content. At worst, they’re not seen and totally inaccessible.
A better alternative is to just show the content in situ, or better yet, design the interface so that users don’t need the additional guidance in the first place.
If all else fails, use an inline toggle component. It provides all of the benefits of progressive disclosure without the pitfalls of tooltips. -->
<p><em>Thanks to Amy Hupe for editing this.</em></p>
Form design: from zero to hero all in one blog post2019-07-22T00:00:00+00:00https://adamsilver.io/blog/form-design-from-zero-to-hero-all-in-one-blog-post/<p>Hi there. If we haven’t met before, I’m Adam and I’m obsessed with designing forms. And I have been for almost 20 years.</p>
<p>What is it about forms then?</p>
<p>Every meaningful interaction on the web is achieved by a form of some sort. Whether it’s letting users renew their passport, send an email or buy something.</p>
<p>Basically anything that isn’t just reading content.</p>
<p>What’s interesting though is that on first glance, forms are easy. In a few minutes you can have text boxes and radio buttons on screen and working.</p>
<p>But look around the internet for a minute, and you’ll find a million and one usability issues revolving around forms.</p>
<p>I’m pretty sure I’ve come across every single one of them. And spent hours solving each one in a way that works for everyone.</p>
<p>And some forms have more than just fields and buttons. They can contain complex interactions or form part of a wider journey—both of which need due care and attention.</p>
<p>So, if I was designing a new form, I’d want to know how to avoid the common issues. And to use my time to solve newer and perhaps more difficult problems.</p>
<p>Seriously, who wants to spend time solving something that’s already been solved?</p>
<p>That’s right—nobody.</p>
<h2>A note before we begin</h2>
<p>Much of what I’m going to say might sound obvious and boring. But <a href="https://capwatkins.com/blog/the-boring-designer">boring is good</a>, we don’t need to over complicate matters.</p>
<p>So if you’re looking for new and innovative ways to design forms, this is not for you.</p>
<p>This is about designing forms that everyone can use and complete as quickly as possible. Because nobody actually wants to use your form. They just want the outcome of having used it.</p>
<p>This guide is quick and to the point—a whistle stop tour of the knowledge I’ve accrued in my years of form design. It’s not exhaustive, but rather an entry point, designed to save you time on the basics.</p>
<p>Many points I make link off to other articles. If you read each of them, you’ll be more than equipped to make simple and accessible forms that get out of the user’s way.</p>
<p>Let’s begin.</p>
<h2>Don’t mess with labels</h2>
<p><a href="https://adamsilver.io/blog/always-use-a-label/">Every input needs a label</a>. Sighted users can see them, visually-impaired users can hear them and motor-impaired users can more easily set focus to the related input.</p>
<p>Put labels above the input. This works well with varying content, states, screen sizes and needs fewer <a href="https://www.uxmatters.com/mt/archives/2006/07/label-placement-in-forms.php">eye fixations</a>.</p>
<p><a href="https://adamsilver.io/blog/the-problem-with-placeholders-and-what-to-do-instead/">Placeholders are problematic</a>—both as makeshift labels and as a means of storing additional hint text. <a href="https://nostyle.onrender.com/examples/registration-form">Instead put hint text below the label and above the input</a>.</p>
<p><a href="https://adamsilver.io/blog/the-problem-with-float-labels-and-what-to-do-instead/">Float labels are also problematic</a>. They have many of the same problems that placeholders have—and some of their own.</p>
<p>Seriously, don’t mess with labels.</p>
<h2>Crafting questions</h2>
<p>Only ask for information you definitely need.</p>
<p><a href="https://service-manual.nhs.uk/content/how-to-write-good-questions-for-forms/get-the-questions-into-order#watch-out-for-double-barrelled-questions">Avoid double-barrelled questions</a>. They’re hard to understand.</p>
<p>Don’t mark required fields, mark optional ones. Or better yet <a href="https://adamsilver.io/blog/how-to-avoid-optional-form-fields/">avoid optional questions by using a branching question</a>.</p>
<p>Use hint text to tell users why you’re asking them for certain information—it’s not always obvious.</p>
<p>Add hint text when users are more likely to make a mistake, like when having to satisfy a complex set of password rules. Error messages should be a last resort.</p>
<h2>Style and microcopy</h2>
<p>Make form fields look like form fields. Apply a border and make sure they start empty so it’s obvious where the input goes. Make fields easy to tap—44px height or more is good.</p>
<p>The width of the field gives users a clue as to the length of the content it requires. So don’t make all fields the same width for aesthetic purposes when you know the expected length.</p>
<p>Avoid <a href="https://baymard.com/blog/avoid-multi-column-forms">multi column form layouts</a>. They’re error prone, slower to use and can cause abandonment.</p>
<p>Make buttons look like buttons. <a href="https://adamsilver.io/blog/where-to-put-buttons-on-forms/">Align them to the left edge of the last input</a> where users naturally look for them which also makes it easier for screen magnifier users.</p>
<p><a href="https://medium.com/@jsaito/making-a-case-for-letter-case-19d09f653c98">Use sentence case for labels, hints and error messages</a>. It’s easier to read and spot nouns. Use a verb for button text because the user is <em>doing</em> something.</p>
<h2>Form validation</h2>
<p><a href="http://adrianroselli.com/2019/02/avoid-default-field-validation.html">Avoid default validation</a>, <a href="https://adamsilver.io/blog/the-problem-with-disabled-buttons-and-what-to-do-instead/">don’t disable buttons</a> and <a href="https://adamsilver.io/blog/the-problem-with-live-validation-and-what-to-do-instead/">don’t validate as the user types</a>.</p>
<p>Validate the form when it’s submitted. Server side first. Optionally enhance with JavaScript.</p>
<p>Be tolerant of mistakes like extra spaces.</p>
<p>Show errors at the top of the page. When the user clicks on an error, focus the input.</p>
<p>Put each error just above the input too. <a href="http://adrianroselli.com/2017/01/avoid-messages-under-fields.html">Placing it below is problematic</a>.</p>
<p>Prefix the word “Error” to the document’s title. It’s the first thing announced by screen readers when the page loads.</p>
<p>Style error messages in red and use a warning icon to provide a <a href="https://developer.paciellogroup.com/blog/2018/01/inclusive-design-principle-provide-a-comparable-experience/">comparable experience for colour blind users</a>.</p>
<p>Error messages should be concise, specific, use plain language and avoid pleasantries like ‘please’.</p>
<h2>Flow and order</h2>
<p><a href="https://www.smashingmagazine.com/2017/05/better-form-design-one-thing-per-page/">Start with one thing per page</a>. Then put the questions in a sensible order. For example, in a checkout flow, put payment after delivery.</p>
<p><a href="https://design-system.service.gov.uk/patterns/question-pages/#using-progress-indicators">Start without a progress indicator</a>. They’re often not noticed and can be tricky to design for dynamic flows.</p>
<!-- Tell users what they need and how long the form will take to complete before they start. -->
<p>In long forms, let users save their progress and return to finish it later. Consider using the <a href="https://design-system.service.gov.uk/patterns/task-list-pages/">task list</a> pattern.</p>
<p>Put <a href="https://adamsilver.io/blog/where-to-put-buttons-on-forms/#put-the-back-button-above-the-form">back links in the top left of the page</a> so users don’t have to scroll past the form to go back. Avoid putting links within the body of the form as it <a href="https://adamsilver.io/blog/where-to-put-buttons-on-forms/#put-tangentially-related-actions-above-the-form">disrupts the tab sequence</a>.</p>
<p>Let users <a href="https://design-system.service.gov.uk/patterns/check-answers/">check their answers</a> and make changes to <a href="https://inclusivedesignprinciples.org/#give-control">keeps users in control</a>.</p>
<p>After completion, show a <a href="https://design-system.service.gov.uk/patterns/confirmation-pages/">confirmation page</a> and send users an email confirmation. Tell users what will happen next.</p>
<p>Now’s a good a time to let your brand shine through. This is the beginning of the relationship—not the end.</p>
<h2>Go faster</h2>
<!-- [Design for common circumstances](https://www.gov.uk/service-manual/design/form-structure#design-for-the-most-common-scenarios-first) by putting the most used option first and marking it as selected. Except when you need to avoid bias—like in surveys. -->
<p>Use the <a href="https://www.smashingmagazine.com/2017/03/improve-billing-form-ux/">browser’s autofill routine</a> to stop users from typing data manually. This also reduces the risk of typos.</p>
<p>Avoid the <code>maxlength</code> attribute. Many users don’t look at the screen as they type, so they won’t notice that some of their keystrokes were ignored until they look up.</p>
<p>Use a <a href="https://nostyle.onrender.com/components/character-countdown">character count</a> instead.</p>
<p>Use <code>autocapitalize="none"</code>, <code>autocorrect="off"</code> and <code>spellcheck="false"</code> to stop browsers automatically changing user input on fields that expect grammatically incorrect data—like email addresses and passwords.</p>
<h2>Field design</h2>
<p>Use the right input type. On touch devices it’ll provide a dedicated keyboard.</p>
<p>Learn <a href="https://adamsilver.io/blog/form-design-when-to-use-the-number-input/">when and when not to use the number input</a>.</p>
<p>Don’t mix up radio buttons and checkboxes. Remember <a href="https://uxmyths.com/post/931925744/myth-23-choices-should-always-be-limited-to-seven">you can include more than 7 options</a>.</p>
<p><a href="https://www.youtube.com/watch?v=CUkMCQR4TpY">Select boxes should be a last resort</a> because they’re really hard to use.</p>
<p>Don’t use <code>datalist</code> as it’s <a href="https://caniuse.com/#feat=datalist">buggy and lacks support</a>. Autocompletes are really tricky, so you can <a href="https://nostyle.onrender.com/components/autocomplete">use mine</a>.</p>
<p>Use <a href="https://nostyle.onrender.com/components/memorable-date">three separate text boxes for dates</a>. Only use a date picker when users need to find a date in relation to another, or if they need to know the day, week or month that the date relates to. Date pickers are tricky, so you can <a href="https://nostyle.onrender.com/components/date-picker">use mine</a>.</p>
<p>Use a <a href="https://nostyle.onrender.com/components/stepper">stepper component</a> to help users make small numerical adjustments quickly and easily.</p>
<p><a href="https://adamsilver.io/blog/form-design-multiple-inputs-versus-one-input">Don’t use multiple inputs when one will do</a>, like when asking for a sort code. If you do have multiple inputs for a field, don’t auto tab between them. It causes users to make mistakes.</p>
<p>File uploading: try to accept large files and as many file types as possible. Don’t <em>rely</em> on the <code>multiple</code> attribute. Besides a lack of support, it can only be used to select files from a single directory.</p>
<p>Here’s one accessible way to let <a href="https://nostyle.onrender.com/examples/dropzone">users upload multiple files</a>.</p>
<h2>The end</h2>
<p>If you like this, you’ll probably like <a href="https://formdesignmastery.com/">Form Design Mastery</a>.</p>
Defining graceful degradation, Patterns Day, journey mapping, question protocol mapping2019-06-30T00:00:00+00:00https://adamsilver.io/blog/week-notes-14/<p>I haven’t written weeknotes in a little while because I don’t always have loads to say. So I think I’ll say things when I have something worth saying. Seems sensible to me.</p>
<h2>In defence of graceful degradation</h2>
<p>I finally published the <a href="https://adamsilver.io/blog/in-defence-of-graceful-degradation-and-where-progressive-enhancement-comes-in/">article</a> I paired on with Amy. This one, as Amy said, <a href="https://twitter.com/Amy_Hupe/status/1143557596697284608">nearly killed us</a>. I think that’s because it comes down to semantics and that’s always a difficult thing to tackle.</p>
<p>Jeremy Keith commented on my article and said he thinks <a href="https://adactio.com/links/15391">graceful degradation, the ‘approach’, is different to graceful degradation, the ‘result’</a>.</p>
<p>This in itself captures the problem I was trying to tackle.</p>
<p>I’m not an expert in words, but I do know that words are complicated. They often have several meanings that depend on the context in which they are used.</p>
<p>But what Jeremy said does leave me thinking there’s plenty of room for confusion.</p>
<p>Firstly, using <code><noscript></code> to expose a shortcoming—or making things work in new browsers first doesn’t result in a graceful degradation.</p>
<p>Secondly, it probably doesn’t matter that much. If people avoid using the <code><noscript></code> tag and make sure to provide a baseline experience before enhancing, then great.</p>
<p>Call it what you want.</p>
<h2>Patterns Day 2</h2>
<p>I got to see a bunch of brilliant talks at Patterns Day. The day was really fun. From the content of the talks to watching Heydon operate a keyboard wearing lobster claws.</p>
<p>My favourite talk was <a href="https://amyhupe.co.uk/">Amy’s</a>. She spoke about the role of content design in the context of design systems. This is not only a crucial subject, but is one that’s not talked about very often.</p>
<p>And Amy’s content was executed with absolute clarity and a whole bunch of jokes that kept the audience entertained throughout.</p>
<h2>Journey mapping</h2>
<p>A few weeks back I started a new role. On my first day we had a project kick off with the need to go live in 7 weeks. That’s nobody’s fault but sometimes this is how it goes.</p>
<p>Normally each phase (discovery, alpha etc) lasts longer than that.</p>
<p>I was asked to create some journey maps for our main user types to get everyone on the same page, to spot gaps, and understand the end to end journey as best as we can.</p>
<p>While I’ve helped fill out journey maps in the past, I’ve never facilitated the sessions myself. I was pretty nervous.</p>
<p>But with some help from my friends, I made a plan and created the maps with the content designer, service owner, researcher and business architect.</p>
<p>And it was nice to get over my fear of mapping. There’s no one way to do it and you just do your best and refine as you go.</p>
<p>Maybe I’ll share my, ahem, journey in a separate article.</p>
<h2>Question protocolling the shit out of a form</h2>
<p>After creating the journey maps we began working on the digital form.</p>
<p>One of the common points of friction in form design, is thinking you need to ask lots of questions to the user in order to run the service.</p>
<p>But we should <a href="https://www.gov.uk/service-manual/design/form-structure#know-why-youre-asking-every-question">know why we’re asking every question</a>. If it’s not absolutely necessary to run the service and stop fraud, then we shouldn’t be asking for it.</p>
<p>We’ve been struggling a bit here, so we used the guidance in the service manual by creating a question protocol map in Google Sheets.</p>
<p>We mapped policy guidance to operational needs with different ways to get the data. Importantly, we did this as a team with policy and operations.</p>
<p>After getting to the bottom of how the data will be used, designing the form became a lot easier for us and a lot better for users.</p>
<p>For us to justify asking questions to users, we need to first justify asking questions to ourselves.</p>
<h2>Agile family updates</h2>
<p>We’ve now been using the family kanban board for enough time for Danny to fill up his points board.</p>
<p>He’s now completed his morning checklist enough times to get himself a new lego helicopter.</p>
<p>He seems chuffed so hopefully the reward is enough for him to continue doing his thing. He’s even asked for some things to be taken off his list and new things put on. Pretty good for 5 years old.</p>
<p>It’s worth noting that there’s a lot more to agile families than just the board, the checklist and family meetings. We’ll be introducing more things when we have the energy to implement them.</p>
<h2>New article about form design on the way</h2>
<p>I’ve got an article ready to go, subject to a review and edit. It’s an article that tells you everything I know about the fundamentals of form design, so that you can avoid all the mistakes I’ve made when designing forms in the last 20 years.</p>
<h2>Links</h2>
<ul>
<li>Matthew Strom’s <a href="https://matthewstrom.com/writing/delight-comes-last/">delight comes last</a></li>
</ul>
In defence of graceful degradation and where progressive enhancement comes in2019-06-25T00:00:00+00:00https://adamsilver.io/blog/in-defence-of-graceful-degradation-and-where-progressive-enhancement-comes-in/<p>The concept of graceful degradation predates the web. It describes a way to design fault tolerant systems:</p>
<blockquote>
<p>“The ability of maintaining functionality when portions of a system break down is referred to as graceful degradation.”—Wikipedia</p>
</blockquote>
<p>And although we strive to design resilient digital experiences, we’ve come to view graceful degradation as the wrong way to do it.</p>
<p>In the context of the web, graceful degradation has become a bit of a dirty word and I think that’s a problem.</p>
<p>Because building shared knowledge first requires us to use shared language. If we start to misrepresent concepts in how we define them, there’s a risk we’ll apply them incorrectly too.</p>
<p>In this article, I’ll explain how I think graceful degradation has come to earn its bad rep, and why I believe it’s time to rethink it.</p>
<h2>What is graceful degradation?</h2>
<p>Escalators are a good example of graceful degradation—when they break down, they become steps.</p>
<p>Similarly, HTML and CSS are also designed to degrade gracefully when things go wrong:</p>
<blockquote>
<p>“The loose error‐handling of HTML and CSS means that many authoring mistakes or browser support issues are handled gracefully; the browser simply ignores what it doesn’t understand and carries on.”—Jeremy Keith, Resilient Web Design</p>
</blockquote>
<p>When, for example, a browser doesn’t support the <code><video></code> element, it renders the content inside the element and continues parsing the rest of the HTML without a problem.</p>
<pre><code><video>
Put transcript and images in here instead.
</video>
</code></pre>
<p>This gives us an easy way to provide a fallback for users with less capable browsers.</p>
<p>The same goes for CSS:</p>
<pre><code>div { border-radius: 3px; background-colour: blue }
</code></pre>
<p>If a browser doesn’t support border-radius, the browser will simply skip it and use angled corners instead.</p>
<p>HTML and CSS degrade gracefully by design. All we need to do is use them and we get resilience for free. That’s why the web is such a success.</p>
<p>But graceful degradation is often thought of as bad—especially when compared with its close relative, progressive enhancement.</p>
<h2>Why people think graceful degradation is bad and progressive enhancement is good</h2>
<p>For an understanding of why graceful degradation is often painted in an unflattering light, we can look to some of the common definitions.</p>
<h3>Graceful degradation is just progressive enhancement in reverse</h3>
<p>MDN, for example, describes graceful degradation as designing an optimised experienced first, and working backwards to consider how to make things work for less capable browsers:</p>
<blockquote>
<p>“Graceful degradation […] centers around trying to build a modern web site/application that will work in the newest browsers, but fall back to an experience that while not as good still delivers essential content and functionality in older browsers.”</p>
</blockquote>
<p>Progressive enhancement, MDN says, is “seen as going in the opposite direction to graceful degradation”.</p>
<p>With progressive enhancement, we start with a baseline experience that works for everyone, and enhance the experience where possible for people using better browsers.</p>
<p>The implication here is that the order of events affects the outcome: if you start with the optimised experience, the baseline becomes an afterthought.</p>
<p>As Aaron Gustafson puts it:</p>
<blockquote>
<p>“[with graceful degradation] older browsers are expected to have a poor, but passable experience. […] Because they are not the focus, little attention is paid beyond fixing the most egregious errors.”</p>
</blockquote>
<p>Theoretically we may still end up in exactly the same place, but whether we start with the basic experience or the enhanced one by default is considered synonymous with our priorities.</p>
<p>If you prioritise everyone, then you’re good. If you prioritise the privileged few who use the latest browsers then you’re bad.</p>
<p>And I agree, that is bad. I just don’t think this should be attributed to graceful degradation.</p>
<h3>Graceful degradation is making users aware of a shortcoming</h3>
<p>W3 states that:</p>
<blockquote>
<p>“[Graceful degradation is] providing an alternative version of your functionality or making the user aware of shortcomings of a product as a safety measure to ensure that the product is usable.”</p>
</blockquote>
<p>Both graceful degradation and progressive enhancement provide alternative versions when things fail, which means that while this part of the definition is true, it’s not specific to graceful degradation.</p>
<p>But what about making users aware of a shortcoming?</p>
<p>It’s true that making users aware of a shortcoming is usually unhelpful and unnecessary. But attributing this approach to graceful degradation is part of what causes people to think it’s bad.</p>
<p>I’ll explain with a common example—the one W3 uses to demonstrate graceful degradation in relation to letting users print a web page.</p>
<p>Here’s the pertinent code:</p>
<pre><code><a href="javascript:window.print()">Print</a>
<noscript>
<p>Turn on JavaScript to print.</p>
</noscript>
</code></pre>
<p>When JavaScript is enabled, clicking the link calls <code>window.print()</code> which prints the web page. But when JavaScript is disabled, clicking the link does nothing, and the user sees the message inside the <code><noscript></code> element.</p>
<p>This is problematic because:</p>
<ul>
<li>The user is provided with a print button that does nothing when clicked, which results in a broken experience.</li>
<li>The user sees a message about the lack of support and workaround. But the user may not be able to use the workaround, and the browser might not be able to run JavaScript.</li>
<li>Even if the user has JavaScript turned on, the browser might block the script or not recognise the code.</li>
</ul>
<p>This is why the <code><noscript></code> element is fragile and not recommended. It doesn’t create an alternative, degraded experience—it creates a broken one.</p>
<p>Instead, the print button should be injected into the page when the browser supports <code>window.print()</code>. This is known as feature detection and is covered by part of W3’s definition of progressive enhancement:</p>
<blockquote>
<p>“Starting with a baseline of usable functionality, then increasing the richness of the user experience step by step by testing for support for enhancements before applying them”</p>
</blockquote>
<p>Given W3’s fragile example of how to let users print—and the fact they’re calling it graceful degradation—it’s no wonder that some people think progressive enhancement is good and graceful degradation is bad.</p>
<p>With progressive enhancement, users are only ever given a working print button on the page, when the browser is able to do so.</p>
<p>As there’s no equivalent solution to printing a page without JavaScript, the degraded experience isn’t equitable, and it certainly isn’t graceful.</p>
<p>But crucially, none of this means that graceful degradation is bad.</p>
<p>The <code><noscript></code> element is just not an appropriate way to cover the something-went-wrong-with-JavaScript problem. Progressive enhancement—that is, feature detection—is the only way to do that.</p>
<h2>Progressive enhancement makes JavaScript degrade gracefully</h2>
<p>HTML and CSS are declarative languages. You declare how you want something to be and then the browser does its best to apply them.</p>
<p>JavaScript is an imperative language. When you write a script, all of it needs to run in order for it to work. A program would be very hard to debug if you made a mistake and it didn’t tell you.</p>
<p>The problem is that, unlike HTML and CSS, if you give a browser some badly-formed JavaScript or try to use an unsupported method, not only will the browser throw an error, it will stop parsing the script and refuse to go any further.</p>
<p>To solve this problem we have to:</p>
<ul>
<li>Create a baseline experience using HTML and CSS that all users get. This becomes the fallback users get when the JavaScript enhancement fails.</li>
<li>Use feature detection to check the browser supports the JavaScript methods before using them as an enhancement. This stops browsers throwing an error half way through resulting in a broken experience.</li>
</ul>
<p>This is progressive enhancement. An approach to making interfaces that ensures JavaScript degrades gracefully—something that HTML and CSS do automatically.</p>
<p>So graceful degradation isn’t in opposition with progressive enhancement at all.</p>
<h2>In conclusion</h2>
<p>Graceful degradation is an integral part of designing resilient, fault-tolerant systems.</p>
<p>Despite the common narrative, graceful degradation is not in competition with progressive enhancement—it’s simply an approach that makes JavaScript degrade gracefully, like HTML and CSS do by default.</p>
<p>Graceful degradation and progressive enhancement have the same objective—to create robust, accessible and broad-reaching solutions that work for everyone no matter their choice of browser.</p>
<p>And that’s a very good thing indeed.</p>
<p><em>Huge thanks to <a href="https://amyhupe.co.uk/">Amy Hupe</a> who paired with me on this from start to finished. And distilled this difficult message down to its irreducible core. If it wasn’t for her, I’d have either made a total mess of it, or worse, binned it altogether.</em> 🙌</p>
The problem with web components2019-06-10T00:00:00+00:00https://adamsilver.io/blog/the-problem-with-web-components/<p><a href="https://www.webcomponents.org/introduction">Web components</a> are becoming increasingly popular within the web community. They offer a way to standardise and encapsulate JavaScript-enhanced components without a framework.</p>
<p>However, web components have a number of drawbacks. For instance, they have a number of technical limitations and are easy to misuse in a way that excludes users.</p>
<p>It’s possible—and certainly my hope—that web components will improve over time and these issues will be resolved. But for now, I’m holding fire on them.</p>
<p>In this article I’ll explain why that is, and suggest an alternative way to develop components in the meantime.</p>
<h2>They’re constraining</h2>
<p>In his <a href="https://thenewobjective.com/a-criticism-of-web-components/">criticism of web components</a>, Michael Haufe explains that:</p>
<ul>
<li>custom CSS pseudo selectors can’t be used with web components</li>
<li>they don’t work seamlessly with native elements and their associated APIs</li>
<li>if we wanted to create a custom button, for example, we can’t extend the <a href="https://developer.mozilla.org/en-US/docs/Web/API/HTMLButtonElement">HTMLButtonElement</a> directly, we have to extend the <a href="https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement">HTMLElement</a></li>
</ul>
<p>Additionally, web components have to be defined with ES2015 classes which means they can’t be transpiled to give more people the enhanced experience.</p>
<p>So, straight off the bat, there are a number of technical constraints to work around when it comes to using web components.</p>
<h2>They’re not widely supported</h2>
<p>Currently, web components have relatively poor cross-browser support, so the enhanced experienced won’t work for everyone.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/web-component-can-i-use.png" alt=""><figcaption>Web component support on caniuse.com</figcaption></figure>
</div>
<p>That doesn’t mean we can’t use them, it just means we’ll need to <a href="https://adamsilver.io/blog/thinking-differently-about-progressive-enhancement/">provide a baseline experience that works for everyone else</a>. That’s progressive enhancement.</p>
<p>But we should think seriously about whether the choice to use web components is the most accessible option. If we don’t use web components, we can provide the same rich experience to a significantly wider group of people. I’ll explain how later.</p>
<p>Polyfills offer a way to provide broader support. But they are <a href="https://adamsilver.io/blog/the-disadvantages-of-javascript-polyfills/">slow, unreliable and hard to work with</a> in general, and have a number of <a href="https://www.webcomponents.org/polyfills#known-limitations">specific limitations</a> when used to make web components work more broadly.</p>
<p>So while it may be preferable for us as code authors to use standards-based technologies, it’s not necessarily beneficial to our users—which should always be our first priority.</p>
<h2>They’re easily misunderstood and misused</h2>
<p>Jeff Atwood said that any application that can be written in JavaScript, will eventually be written in JavaScript.</p>
<p>But just because we can use JavaScript to do something, doesn’t mean we should. There’s even a W3 principle that says we should use the <a href="https://www.w3.org/2001/tag/doc/leastPower.html">least powerful tool for the job</a>.</p>
<p>Web components are made up of JavaScript APIs which means we should use them only when we need JavaScript. But as Jeff Atwood predicted, people sometimes use web components when they don’t need to.</p>
<p>When we make JavaScript a dependency and don’t provide a fallback, users get a broken experience. Even webcomponents.org, built using web components, shows a blank web page <a href="https://kryogenix.org/code/browser/everyonehasjs.html">when JavaScript isn’t available</a>.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/web-components-org-no-js.png" alt=""><figcaption>Completely broken experience on webcomponents.org when experiencing a JavaScript failure</figcaption></figure>
</div>
<p>By the same token, it can encourage people to make components that request their data with AJAX and render themselves, like little iframes.</p>
<p>This type of approach causes a number of avoidable issues which I’ll explain by way of an example.</p>
<p>Imagine we want to load a table showing the sales figures for a product our website sells using AJAX like this:</p>
<pre><code><sales-figures></sales-figures>
</code></pre>
<p>Firstly, it’s just a table. There’s no column sorting and therefore no need for JavaScript. Browsers provide the <code><table></code> element for this exact purpose and it works everywhere.</p>
<p>Secondly, as mentioned above, when a browser doesn’t support web components, or JavaScript fails to run, users won’t see anything.</p>
<p>To make our table work in these situations, we would need to put a <code><table></code> inside <code><sales-figures></code>. This is known as <a href="https://adamsilver.io/blog/in-defence-of-graceful-degradation-and-where-progressive-enhancement-comes-in/">graceful degradation</a>.</p>
<pre><code><sales-figures>
<table>...</table>
</sales-figures>
</code></pre>
<p>If the component already has a populated table on the page when the page loads, wrapping <code><sales-figures></code> around it gives us and our users nothing.</p>
<p>Finally, using AJAX can introduce a number of usability and accessibility issues.</p>
<ol>
<li><a href="https://jakearchibald.com/2016/fun-hacks-faster-content/">AJAX is often slower than a page refresh</a>, not faster.</li>
<li>We’ll need to create custom loading indicators, which are usually inaccurate and unfamiliar to users, unlike browsers’ loading indicators.</li>
<li>We’ll need to <a href="https://zinoui.com/blog/cross-domain-ajax-request">make AJAX work cross-domain</a>, which isn’t straightforward.</li>
<li>As the components load the page will jump around causing <a href="https://twitter.com/chriscoyier/status/1057303249902952448">visual glitches</a> and potentially making users click the wrong thing. You may have heard about <a href="https://medium.com/@rohit971/boost-your-ux-with-skeleton-pattern-b8721929239f">skeleton interfaces</a> as a way to solve this problem. They are placeholders put where the components will end up being shown once loaded. But while they help a bit, they don’t fully solve the problem because they can’t always predict the exact size of the content that will load.</li>
<li>Point 4 affects screen reader users too because they won’t know whether the components have loaded, have failed to load or are in the process of loading. ARIA live regions provide a way to communicate these states to screen readers. But when several components are being loaded, the user will be bombarded with announcements.</li>
</ol>
<p>Scale this up to several web components on a screen and we risk giving users a very unpleasant, exclusive and slow experience to contend with.</p>
<p>Components that depend on AJAX requests to the server are no longer framework agnostic and therefore interoperable. This somewhat defeats the object of using web components, given that interoperability and technology agnosticism are 2 of the main benefits they aim to provide.</p>
<p>Importantly, none of these problems are the fault of web components per se. We could easily develop components to work like this without web components. But, as demonstrated, it’s easy to misinterpret web components and unknowingly use them in a way that hurts both users and code authors.</p>
<h2>They’re hard to compose</h2>
<p>Let’s say we have just 2 web components. One for sortable tables and another for expandable rows.</p>
<pre><code><sortable-table>
<table>...</table>
</sortable-table>
<expandable-rows>
<table>...</table>
</expandable-rows>
</code></pre>
<p>But if we want a sortable table with expandable rows then we need to nest the components like this:</p>
<pre><code><expandable-rows>
<sortable-table>
<table>...</table>
</sortable-table>
</expandable-rows>
</code></pre>
<p>The relationship between <code><expandable-rows></code> and <code><table></code> is unclear. For example, it’s hard to tell whether <code><expandable-rows></code> is operating on the <code><table></code> or the <code><sortable-table></code>.</p>
<p>The order matters, too. If each component enhances the table it could create a conflict. Also, it’s not clear which component initialises first—the inside one or the outside one.</p>
<p><em>(Note: you may have heard about the <code>is</code> attribute as a way around this but Jeremy Keith explains that browsers aren’t going to implement this in <a href="https://medium.com/@adactio/extensible-web-components-e794559b8c2e">extensible web components</a>.)</em></p>
<h2>They can’t just be dropped into an application</h2>
<p>One of the supposed benefits of web components is that we can drop one script per component onto the page and they just work—regardless of the application or tech stack.</p>
<p>But unlike standard elements, we may need to add additional code to get them to work properly. In some ways this is a bit like adding a framework or library.</p>
<p>One example of this is polyfills which I mentioned earlier. If you choose to use a polyfill to provide broader support, then that code needs to be ready and waiting in your web page.</p>
<p>Another example would be when you need to stop JavaScript-enhanced components from making the <a href="https://twitter.com/adambsilver/status/1119123828884434945">page judder while initialising</a>.</p>
<p>This is usually fixed by adding a script in the <code><head></code> of your document to <a href="https://css-tricks.com/snippets/javascript/css-for-when-javascript-is-enabled/">provide a hook for CSS</a>. This in turn is used to style the component based on JavaScript being available and avoids the page judder.</p>
<p>This is perhaps of little consequence overall, but it does considerably negate one of the supposed benefits of using web components.</p>
<h2>Framework agnostic components without web components</h2>
<p>You may have heard <a href="https://medium.com/@oneeezy/frameworks-vs-web-components-9a7bd89da9d4">web components being sold as an alternative to using frameworks</a>.</p>
<p>While I’m in favour of creating interfaces without client-side frameworks, this is misleading for a number of reasons.</p>
<p>Firstly, client-side frameworks usually provide additional features besides enhancing pieces of the interface.</p>
<p>Secondly, web components can be used in tandem with frameworks.</p>
<p>Lastly, we’ve been able to create JavaScript-enhanced components without frameworks and web components for a very long time.</p>
<p>By creating components like this we can avoid the drawbacks I’ve described in this article.</p>
<p>Let’s use the same sortable table and row expander to do this.</p>
<p>Firstly, we need to create a JavaScript file for each component—the same as if we were using web components. We can define the <code>SortableTable</code> and <code>RowExpander</code> classes inside.</p>
<pre><code>SortableTable.js // define SortableTable class and behaviour
RowExpander.js // define RowExpander class and behaviour
</code></pre>
<p>Once that’s done, we can initialise the components like this:</p>
<pre><code>// grab table
var table = document.querySelector('table');
// initialise sortable table
var sortable = new SortableTable(table);
// initialise row expander
var expander = new RowExpander(table);
</code></pre>
<p>We can make these components fire events just like web components. Something like this:</p>
<pre><code>sortable.addEventListener(‘sort’, fn);
expander.addEventListener(‘expand’, fn);
</code></pre>
<p>By using regular JavaScript in this way, not only can we write clean code, free from technical constraints, but we get to give that code to a significantly wider user base.</p>
<h2>In conclusion</h2>
<p>Web components hold a lot of promise because they give code authors a way to create interoperable components based on standards.</p>
<p>As a result, it should be easier to understand other people’s code and create components that can be reused across projects.</p>
<p>But even if we choose to provide enhancements exclusively for cutting edge browsers that support them, there’s still several limitations and issues we need to tackle.</p>
<p>My hope is that web components get better in future. But until then, I’m sticking with regular JavaScript to avoid the current technical limitations and provide the most equitable experience to users.</p>
<p><em>Thanks to <a href="https://amyhupe.co.uk/">Amy</a> for editing this article.</em> 🙌</p>
Caseworking meetup notes, design system uptake, writing is hard, soft skills are hard2019-05-19T00:00:00+00:00https://adamsilver.io/blog/week-notes-13/<p>Caseworking meetup, agile programming for families, design system humble brag, article updates and soft skills.</p>
<h2>Cross-government caseworking meetup</h2>
<p>On Wednesday, I went to the third cross-government caseworking meetup run by <a href="https://twitter.com/ctdesign">Chris Taylor</a>. I went to the first one a couple years ago, but unfortunately missed the second one.</p>
<p>There were 3 workshops in the morning and an unconference in the afternoon. It was great and I had a lot of fun. The workshops got me thinking lots and I met a lot of nice people.</p>
<p>In one of the workshops we split off into small groups and within 5-10 mins we had to write some principles for designing case working systems.</p>
<p>Here’s what my group came up with:</p>
<ul>
<li>Repeat users first but remember first-time users too</li>
<li>Start with existing (GOV.UK) patterns</li>
<li>One thing per page can still work</li>
<li>Structured data first</li>
<li>Accessible technology still matters</li>
</ul>
<p>While I’m sure the principles can be honed, they’re quite useful and practical for case working systems.</p>
<p>Amy wrote a thread about some of the <a href="https://twitter.com/Amy_Hupe/status/1128733673417842688">things she learned from the day</a> which resonates with me too.</p>
<h2>Agile families</h2>
<p>When our first born, Danny, was about a year old, I stumbled on a Ted Talk about <a href="https://www.ted.com/talks/bruce_feiler_agile_programming_for_your_family">agile programming for families</a> by Bruce Feiler.</p>
<p>Now Danny is 5, and now Tali, almost 2—with all the manic in our home, we’ve decided to try it out.</p>
<p>We’ve done one “sprint” including a family meeting at the end (the retro). And I can definitely say that we’ve all got a lot out of it.</p>
<p>Talking on a regular basis, listening to what people feel and rewarding good behaviour. Turns out this stuff is good for us. Maybe we should do this at work :).</p>
<p>I’ve started reading Bruce Feiler’s book, <a href="https://www.amazon.com/Secrets-Happy-Families-Improve-Mornings/dp/0061778745">The Secret to Happy Families</a> on the subject. And David Starr’s <a href="https://pluralsight-free.s3.amazonaws.com/david-starr/files/PID922221.pdf">white paper</a> is a great free, to the point alternative.</p>
<h2>Several departments are using the HMCTS Design System</h2>
<p>A number of different people across departments have told me they have been using the HMCTS Design System to prototype and design their services to varying degrees:</p>
<ul>
<li>Some install HMCTS Frontend directly</li>
<li>Some copy the components into their own project</li>
<li>Some reskin the components which is what NHS do</li>
</ul>
<p>I just want to remember how bloody cool this is and that’s all I have to say about that.</p>
<h2>Writing about graceful degradation has been hard work</h2>
<p><a href="https://amyhupe.co.uk/">Amy</a> and I have been pair writing an article on graceful degradation. It’s been really really really hard work.</p>
<p>I’m trying to make it clear what the difference between graceful degradation and progressive enhancement. Specifically without saying “graceful degradation is x and progressive is the opposite of x”.</p>
<p>That’s because they are not really opposites at all. They are different things that help us create interfaces that work for everyone, no matter their choice of browser.</p>
<p>While it’s been really hard going, it’s also been really good for me. Amy’s taught me indirectly that it’s totally okay to sweat this stuff. To take your time. To rethink your position, again and again.</p>
<h2>Soft skills are bloody hard</h2>
<p>I’ve been thinking about soft skills and hard skills recently. Triggered by watching talented, friendly people run the sessions at the case working meetup.</p>
<p>While we need hard skills to design screens and build software, it’s the soft skills that get the best out of everyone and make sure the right thing gets built.</p>
<p>And that’s bloody hard work, at least for me. It’s constant effort because everyone is different. Every team is different. And every day is different.</p>
<p>I’m in awe of people who do this constantly, making your team work better and making it look easy in the process.</p>
Semantic HTML and ARIA explained2019-05-14T00:00:00+00:00https://adamsilver.io/blog/semantic-html-and-aria-explained/<p><em>Originally <a href="https://css-tricks.com/why-how-and-when-to-use-semantic-html-and-aria/">published on CSS-Tricks</a></em>.</p>
<p>Semantic HTML and ARIA (Accessible Rich Internet Applications) help create interfaces that work for everyone in the most performant, robust, and simple way possible.</p>
<p>They add essential meaning to your content, which lets web browsers, search engines, screen readers, RSS readers, and ultimately users understand it.</p>
<p>And yet many people still don’t use them. I wanted to know why that was, so I set up a <a href="https://twitter.com/adambsilver/status/1113502475800260608">Twitter poll</a>. The most common reason people gave was a lack of awareness and understanding.</p>
<p>So here I’ll describe the benefits of using them, and explain why you should start with semantic HTML, and only use ARIA as a last resort.</p>
<h2>Starting with raw text</h2>
<p>The <code><body></code> element of an HTML document contains the main content a user sees on a page. If content is put inside the body without any additional elements, the browser has no way of differentiating between different types of content, like paragraphs and headings.</p>
<pre><code><body>
I’m the page heading.
I’m a paragraph.
I’m a sub-heading.
</body>
</code></pre>
<p>If the browser can’t differentiate between pieces of content, then it can’t present that content to the user in a meaningful way. That means:</p>
<ul>
<li>you can’t use CSS to style the headings differently from paragraphs</li>
<li>search engines can’t index the content, meaning it will rank poorly and users will struggle to find it</li>
<li>screen readers and other assistive technology can’t communicate it properly to the user</li>
</ul>
<h2>Adding some structure with HTML</h2>
<p>To provide some structure you can wrap your content in <code><div></code>s like this:</p>
<pre><code><div>I’m the page heading.</div>
<div>I’m a paragraph.</div>
<div>I’m a sub-heading.</div>
</code></pre>
<p>This is better because instead of one big block of text, each piece of content is displayed in the browser on its own line. But there’s still a distinct lack of meaning.</p>
<p>That’s because the headings and paragraph are wrapped in <code><div></code>s which are meaningless on their own. In this example, browsers, CSS, search engines and screen readers are still none the wiser.</p>
<h2>Styling content</h2>
<p>You can add visual styling to different elements using CSS:</p>
<pre><code>div:first-child { /* styles here */ }
div:nth-child(3) { /* styles here */ }
</code></pre>
<p>Here the CSS targets the first and third <code><div></code>s to apply heading styles. This isn’t maintainable because another paragraph added afterward, for example, would get styled as a heading.</p>
<p>You could give each <code><div></code> a unique attribute such as an ID or class name, to provide more control:</p>
<pre><code><div class="heading1">A Study of Butterflies</div>
<div class="paragraph">Butterflies are little bugs with cute wings.</div>
<div class="heading2">Butterfly Habitats</div>
</code></pre>
<p><em>(<strong>Note</strong>: I explain why you should use classes instead of IDs for styling in my online book, MaintainableCSS.)</em></p>
<p>You can now target the different elements with CSS like this:</p>
<pre><code>.heading1 { /* styles here */ }
.paragraph { /* styles here */ }
.heading2 { /* styles here */ }
</code></pre>
<p>This will make the paragraphs and headings look different, which works for sighted people who use a browser. But it doesn’t provide meaning to search engines, RSS readers and screen readers. In other words, it’s not semantic and it’s not very accessible.</p>
<h2>Giving content meaning</h2>
<p>HTML provides many elements that give meaning to content, including elements for headings and paragraphs.</p>
<p>So instead of <code><div></code>s with class attributes made up by the author (me in this case), you can use predefined HTML elements which are built specifically for this purpose.</p>
<pre><code><h1>I’m a heading</h1>
<p>I’m a paragraph</p>
<h2>I’m a sub-heading</h2>
</code></pre>
<p>With semantic HTML like this, your content will get some <a href="https://meiert.com/en/blog/user-agent-style-sheets/">default styles from the browser</a>. You can add other elements like <code><b></code> which means “bring to attention” to make text bold.</p>
<p>Crucially, using semantic HTML also means:</p>
<ul>
<li>you can use CSS to add your own styling</li>
<li>search engines can index the content so that it ranks well enough that users can find it</li>
<li>RSS readers can style the elements appropriately</li>
<li>screen readers and other assistive technologies can communicate it properly to the user</li>
</ul>
<p>The code is also more concise which, while not massively important in these short examples, makes a big difference when considering an entire site.</p>
<p>Semantic HTML is standards-based and stable. This means any HTML processor in the future will be able to understand it and present it correctly to users. It will also help other code authors to understand it if they’re editing the code in the future.</p>
<h2>Additional benefits of semantic HTML</h2>
<p>As well as the benefits I’ve described, some browsers add useful enhancements to semantic HTML for free.</p>
<p>For example, using the HTML telephone input (<code><input type=”tel”></code>) will give users a telephone-specific keypad on some mobile browsers.</p>
<p>Other browsers give users the option to switch on a simplified view of the page, like Safari’s Reader Mode. Without semantic HTML, this functionality won’t work.</p>
<p>You can read more about this in Mandy Michael’s article on <a href="https://medium.com/@mandy.michael/building-websites-for-safari-reader-mode-and-other-reading-apps-1562913c86c9">building websites for Safari Reader Mode and other reading apps</a>.</p>
<h2>Using ARIA</h2>
<p>Like semantic HTML, <a href="https://www.w3.org/TR/html-aria/">ARIA is a W3 standard</a> that helps you make interfaces more accessible to users of screen readers and other assistive technologies.</p>
<p>A good example is error messages. If a user leaves a required form field blank, the HTML for the error might look like this:</p>
<pre><code><label for=”first-name”>First name</label>
<input type=”text” name=”first-name” id=”first-name”>
<span>Enter your first name</span>
</code></pre>
<p>A sighted user will be able to see the error underneath the field. But when a screen reader focuses the input, the error won’t be announced, because the error message isn’t linked to the input.</p>
<p>You can use ARIA to associate the error with the input like this:</p>
<pre><code><label for=“first-name”>First name</label>
<input type=“text” name=“first-name” id=“first-name” aria-describedby=“first-name-error”>
<span id=“first-name-error”>Enter your first name</span>
</code></pre>
<h2>ARIA and JavaScript</h2>
<p>ARIA is most useful when JavaScript is involved. JavaScript is usually required to create more complex and dynamic interactions like hiding, showing and changing elements without a page refresh.</p>
<p>Think toggle menus, accordions, tabs, autocompletes, sortable tables, loading content and saving, sending or getting data. Enhancing interfaces like this often breaks the experience for screen reader users.</p>
<p>Take a button that, when selected, shows some other content. In the original state, a sighted user can see a button and no content showing. When they select the button, the content appears.</p>
<p>However, visually-impaired people who use screen readers are usually relying on things being announced as they move through an interface.</p>
<p>But when a screen reader user focuses the button, there’s nothing by default to tell them if the content is currently being shown or not.</p>
<p>You can add the <code>aria-expanded</code> attribute onto the button, and toggle it’s value between true (content is showing) and false (content is hidden). This helps to <a href="https://inclusivedesignprinciples.org/#provide-comparable-experience">provide a comparable experience</a> (inclusive design principle 1) to screen reader users.</p>
<pre><code><button aria-expanded=”false”>Toggle content</button>
<div hidden>Some content</div>
</code></pre>
<h2>Avoid using ARIA to fix unsemantic HTML</h2>
<p>ARIA attributes can be used to make unsemantic HTML more accessible to screen reader users. For example, a developer who is struggling to style a native checkbox across multiple browsers might decide to use a <code><div></code> and some JavaScript to emulate one.</p>
<p>To make the <code><div></code> identify itself as a checkbox to screen reader users, we can give it a role of checkbox like this:</p>
<pre><code><div role="checkbox"></div>
</code></pre>
<p>To indicate whether or not the checkbox is checked, we can use the <code>aria-checked</code> attribute like this:</p>
<pre><code><div role="checkbox" aria-checked="false"></div>
</code></pre>
<p>But, this still isn’t enough to make it behave like a checkbox because divs aren’t focusable by keyboards like <code><input type="checkbox"></code> is. You can make them focusable by adding <code>tabindex="0"</code>:</p>
<pre><code><div role="checkbox" aria-checked="false" tabindex="0"></div>
</code></pre>
<p>But even then, a real checkbox, when submitted as part of a form, will send its value. Because this isn’t an actual a checkbox, it won’t submit its value without using JavaScript.</p>
<p>And if that weren’t enough already, users can check or un-check a real checkbox by pressing the <kbd>Space</kbd> key. And, the form the checkbox belongs to can be submitted by pressing <kbd>Enter</kbd> when the checkbox is in focus. But the <code><div></code> checkbox won’t do this without even more JavaScript.</p>
<p>Not only is this more work and more code, but the approach only actually works for people who use technology that understands these particular ARIA attributes.</p>
<p>That’s a lot of effort, a lot of code and a lot of problems that we can avoid entirely if we just use semantic HTML:</p>
<pre><code><input type="checkbox">
</code></pre>
<p>There’s no denying that ARIA is useful in certain situations, but starting with semantic, accessible HTML where possible is infinitely simpler and more reliable.</p>
<p>That’s why the <a href="https://www.w3.org/TR/aria-in-html/#firstrule">first rule of ARIA is not to use it</a>.</p>
<h2>In conclusion</h2>
<p>Good design is about providing the best possible experience to the broadest range of users.</p>
<p>Semantic HTML helps technologies and therefore users understand your content. Enhancements offered by some browsers and devices mean your users get an even better experience baked in.</p>
<p>When semantic HTML alone is not enough, ARIA can provide more information for users of assistive technologies–but use it with caution. It’s not a sticking plaster for inaccessible code.</p>
<p>In short, do the hard work to make things work for everyone.</p>
<p><em>Thank you to <a href="https://amyhupe.co.uk/">Amy Hupe</a> for her feedback, guidance and editing on this article. This probably would have been a rant without her.</em></p>
Getting agreement on big decisions, versioning prototype routes, pair writing2019-05-12T00:00:00+00:00https://adamsilver.io/blog/week-notes-12/<p>Getting agreement on big decisions, good reception for my new article, how making things open made things better (for me), and pair writing a new article.</p>
<h2>Getting agreement on big decisions</h2>
<p>I’ve been trying to help my team make a decision on whether the collection of services we’re responsible for should be separate applications that live on multiple (sub) domains or just a single application that lives on one (sub) domain.</p>
<p>There are different views within the team but we need to decide as quickly as possible. Fortunately, I saw Marc O’Connor’s talk about how to <a href="https://adamsilver.io/blog/week-notes-11/#concon8">make sure the collective expertise is used within your team without pulling rank</a>.</p>
<p>I could draw a number of parallels between Marc’s team’s problem and my team’s problem. So last week I began documenting the pros and cons of each approach and getting all the experts in the team to feedback into it. Just acting as a shepherd really as well as sharing my views too.</p>
<p>The great thing about written words is that they don’t lie. You can’t forget about them as easily and they have to be easy to understand by everyone who reads the document.</p>
<p>But I also sent a message to Marc asking him if he would advise me on how to go about all this and to see if he thought the document was a good idea and what other things I should do to get the right decision made quickly.</p>
<p>Marc agreed to meet me and his experience and advice was invaluable to me. He gave me tips on how to think about the problem so that I could approach it in a way that reduces conflict and how to help the team feel like they own the problem collectively.</p>
<p>Even though the tips may sound obvious it takes effort to put them into practice—at least for me.</p>
<p>The document is still being worked on but we have a plan on how to move forwards which I’ll update again on my weeknotes as and when.</p>
<h2>Good reception for my new CSS-Tricks article on semantic HTML and ARIA</h2>
<p>My article, on <a href="https://css-tricks.com/why-how-and-when-to-use-semantic-html-and-aria/">semantic HTML and ARIA</a> has had a good reception I think. I’m particularly chuffed with some of the feedback that shows it’s really easy to read and understand for everyone:</p>
<blockquote>
<p>I feel like this made something I don’t know about and don’t do, much easier to understand 👏🏻 Plus making websites more accessible = good, so it’s worth the read…—<a href="https://twitter.com/CharlotteEmilyM">Charlotte Moore</a></p>
</blockquote>
<p>Again, this is hugely down to <a href="https://amyhupe.co.uk/">Amy Hupe</a>, who inspired me and helped me write an article with inclusivity in mind from the outset. I’m going to try very hard to write this way from now on.</p>
<h2>Making things open made my approach to prototype versioning better</h2>
<p>Last week, I wrote about <a href="https://adamsilver.io/blog/week-notes-11/#automatically-prefixing-the-version-path-in-the-gov%E2%80%8B.%E2%80%8Buk-prototype-kit">automatically prefixing the version path in my prototypes</a>. <a href="https://twitter.com/web_bert">Graham Veal</a> saw it and sent me a message with how to make it better:</p>
<h3>Router before and after</h3>
<pre><code>// Old
router.use('/:path/', function (req, res, next) {
res.locals.config = { path: `/${req.params.path}` };
next();
});
// New
router.use('/:version/', function (req, res, next) {
const version = `/${req.params.version}`;
res.locals.getUrl = function(url) {
return version+url;
};
next();
});
</code></pre>
<h3>Template before and after</h3>
<pre><code><!-- Before -->
<a href="{{config.path}}/details">
<!-- After -->
<a href="{{getUrl('/details')}}">
</code></pre>
<p>This is better because:</p>
<ol>
<li>Using a function means I only have to update the code in one place. It also simplifies the code within the template because concatenation happens within the function—not the template.</li>
<li>The variable and function name are more readable. “getUrl” and “version” are easier to understand than “config.path” and “path”.</li>
</ol>
<p>Even in this small way, this is nice reminder of the important of government design principle 10, <a href="https://www.gov.uk/guidance/government-design-principles">make things open makes things better</a>.</p>
<h2>Pair writing on graceful degradation</h2>
<p>Amy, who’s helped me write my last 3 articles recently suggested we pair write my next article. I’m really excited to learn how to do this, especially with Amy’s help.</p>
<p>We started last week on an article about graceful degradation and progressive enhancement. I’m writing the article because I think there’s some confusion about the practical difference between the two terms.</p>
<p>We started off with Amy asking me some questions to find out why I’m writing it and why it would be helpful to people. Then we discussed the structure and proposed an outline for the article.</p>
<p>After a break, we got started with the introduction. I must say it was really fun but also really hard for me. I usually write in one of two ways. One way is I just write and it comes out pretty well sort of first time.</p>
<p>Another way, is that I’m quite haphazard and I just start throwing bits down on paper and flesh them out in somewhat random order. Then I might rejig and rewrite a number of times.</p>
<p>But with Amy’s help she made us focus on getting the introduction right which while painful, really helped me define for my readers what I’m going to talk about and why.</p>
<p>It’s not perfect, and it might change as we write the body of the article. But it’s a really good start and the pain was worth the reward I think.</p>
<h2>Links</h2>
<ul>
<li>Ben Holliday on <a href="https://medium.com/leading-service-design/asking-the-right-questions-to-frame-the-problem-4df95a317983">asking the right questions to frame the problem</a> and <a href="http://www.hollidazed.co.uk/2019/04/26/the-importance-of-frameworks-and-first-principles-in-service-design/">the importance of frameworks and first principles in service design</a></li>
<li>Pablo Stanley’s sketches on <a href="https://thedesignteam.io/designer-first-world-problems-861e53c8ecf7">designer first world problems</a></li>
</ul>
Prototyping versioning, ConCon8, beyond screens2019-05-05T00:00:00+00:00https://adamsilver.io/blog/week-notes-11/<p>Concon8, prototype versioning, perseverance and article updates.</p>
<h2>Concon8</h2>
<p>I went to Concon 8 this year and it was brilliant (as expected). I went to 2 workshops and 6 talks. The highlights for me were:</p>
<ol>
<li>The content mapping workshop that <a href="https://twitter.com/gabytheresa">Gabrielle Acosta</a>, Katherine Dunne and <a href="https://twitter.com/matt_clear">Matt Clear</a> ran. In a very short space of time we mapped part of the learn to drive journey people go on. We quickly learnt that getting down what you know about a map is more important than making the map neat and tidy, at least early on. And that the process of mapping content helps to quickly spot issues that would be otherwise hard to spot when diving into a small part of the journey.</li>
<li><a href="https://twitter.com/Resh_Gman">Reshma Gumani’s</a> talk on why the NHS decided to use the words pee and poo to make health guidelines clear to everyone. The interesting thing to me is that the NHS decided to put the more technical terms in brackets after the plain language versions of the words which educates the general public at the same time. So the NHS guidelines are inclusive, informative <em>and</em> educational.</li>
<li><a href="https://twitter.com/MarcOConnor21">Marc O’Connor’s</a> talk on how to deal HiPPOs—the highest paid person’s opinion. He talked about a service that wasn’t working so well which in no small part was down to inconsistent language that confused users. That’s because some of the words were written by content designers and some by policy designers. To solve this, he got everyone from their respective disciplines in the same room to run through the options from their point of view. If the content satisfied the researcher, legal team, content designer and so on, then it was good to go. And so when the HiPPO later challenged the proposed change it wasn’t the content designer’s opinion against the HiPPO’s—it was the entire team’s collective view based on evidence, expertise and policy.</li>
</ol>
<h2>Automatically prefixing the version path in the GOV.UK Prototype Kit</h2>
<p>When I iterate a prototype using the GOV.UK Prototype Kit, I create a new folder like <code>/v2</code>. This means for all the links and forms to work from within that folder I need to prefix the paths with the name of the folder.</p>
<p>I usually have to do a quick find and replace which isn’t too much of a pain, but it’s an overhead that I’d prefer not to think about. So I came up with a simple way to not have to worry about it in the future.</p>
<p>First, I update any reference within the views to the hardcoded path with <code>config.path</code>.</p>
<pre><code>// Before
<a href="/v2/search-results">
// After
<a href="/search-results">
</code></pre>
<p>Then I add the following code to the routes file which takes the first part of the URL and makes it available in the views:</p>
<p>router.use(’/:path/’, function (req, res, next) {<br>
res.locals.config = { path: <code>/${req.params.path}</code> };<br>
next();<br>
});</p>
<h2>Web components article</h2>
<p><a href="https://amyhupe.co.uk/">Amy’s</a> been helping me loads with my web components article. Thanks to her, it’s way clearer for everyone <em>and</em> myself. It’s getting really close and I hope to have that published soon.</p>
<h2>Thought of the week</h2>
<p>Design isn’t just the bit when you design a screen—in fact that’s quite often not the hard bit at all.</p>
<p>It’s all the effort you go to get to the root of the problem and getting agreement on a solution. Like asking a question; challenging an assumption; having discussions; capturing rationale; curating that and making it easier to play back to yourself and the team. And having perseverance to do this over and over. All without causing stress within the team.</p>
<p>I say all this as if I know how to do this really well. I don’t. I just do my best and try to get better.</p>
<h2>Links</h2>
<ul>
<li>Ben Holliday’s <a href="https://medium.com/leading-service-design/building-blocks-55c28d998750?source=twitterShare-d4ffd600aceb-1556350012&_branch_match_id=618493401613629967">building blocks to visually represent work for an end to end service</a></li>
<li>Paul Smith’s <a href="https://medium.com/@paulmsmith/agile-walls-9313e49cbeac">agile walls and templates</a></li>
<li>Dan Saffer’s twitter thread capturing <a href="https://twitter.com/odannyboy/status/1115653460752359424">people’s favourite design books</a>.</li>
</ul>
Prototype versioning, namespacing design systems, discussing a header component2019-04-28T00:00:00+00:00https://adamsilver.io/blog/week-notes-10/<p>Versioning prototypes, design system bits and article updates.</p>
<h2>Versioning prototypes</h2>
<p>In the past 12 months I’ve created 5 different prototypes using the GOV.UK Prototype Kit. At times, due to the rapid pace of iteration, I’ve not been the most hygenic when it comes to versioning.</p>
<p>That means different versions sometimes share layouts and different journeys where the journeys have been developed in separate sprints.</p>
<p>And on one particular prototype where we are using a lot of data to make things realistic, I decided to use Git to version things which makes it harder to go back in time to see what things looked like.</p>
<p>But with the pace slowing down recently, I’ve managed to get some time to tidy things up. I now use one folder per version making it easier to keep separate and iterate.</p>
<p>The only exception to that is for NPM dependencies like GOV.UK Frontend and our own HMCTS Frontend. I’m not sure of a good way to handle this, but luckily there’s few major updates that make previous versions change or break.</p>
<p>One less than ideal idea I have floating in my head is to just spin up another prototype altogether if one of those dependencies has a major update.</p>
<p>Oh I’ve started to follow the guidance in Eliot Hill’s article on <a href="https://medium.com/@eliothill/improving-team-memory-by-using-the-gov-uk-prototyping-kit-2ca02bce7a9a">documenting iterations in the GOV.UK Prototype Kit</a> where up to now the prototype itself has been light on what’s changed and why.</p>
<h2>Namespaced HMCTS Frontend</h2>
<p>This week I updated HMCTS Frontend so that the components are namespaced according to the <a href="https://github.com/alphagov/govuk-frontend/issues/870">agreed x-government conventions</a>.</p>
<p>// Before<br>
{% from “badge/macro.njk” import hmctsBadge %}</p>
<p>// After<br>
{% from “hmcts-badge/macro.njk” import hmctsBadge %}</p>
<h2>Making it easier for everyone to use and contribute to the GOV.UK Design System</h2>
<p>I took part in a remote retro with the aim of making it as easy as possible for everyone to use and contribute to the GOV.UK Design System.</p>
<p>As usual, Amy facilitated a fun, focused and productive session. I always look forward to these and I think we got some really good ideas out of this to explore.</p>
<h2>Design System catch-up call—department headers</h2>
<p>We talked about headers—for citizen services and internal services across departments. There’s a lot of different designs floating about which I’m sure we can consolidate.</p>
<p>Headers aren’t simple. They need to be able to accomodate a number of elements some of which will not be needed. Things like department logos, service names, account navigation, primary navigation and search.</p>
<p>When we designed the HMCTS internal header we basically shoved all of this onto a small screen and did our best to take up as little space as possible without hiding things behind a hamburger menu (or equivalent).</p>
<p>I’m really looking forward to seeing what we can do across departments on this.</p>
<h2>Article updates</h2>
<p>I finished my article on semantic HTML and ARIA and CSS Tricks have scheduled it for early May. So looking forward to sharing this one.</p>
<p>I shared my first case study to the world about <a href="https://adamsilver.io/case-studies/designing-a-design-system-for-hmcts/">designing the HMCTS Design System</a> and I got a lot of nice feedback on it.</p>
<p>And I’m still working on my article about the problem with web components. Hopefully that will be ready to go out by the end of May.</p>
Prototype kit extensions, small checkboxes and radio buttons, multi-select autocomplete2019-04-21T00:00:00+00:00https://adamsilver.io/blog/week-notes-9/<p>So last week I missed doing my weeknotes so I’m going to combine the last two weeks together. But I do have the best excuse—much better than the dog ate my homework.</p>
<h2>I lost my vision</h2>
<p>My 18 month old baby girl poked my out so badly that I couldn’t see out of my one good eye.</p>
<p>My bad eye has been bad all my life as I have Daune Retraction Syndrome.</p>
<p>And while there is never a good time to get your eye fucked by your baby daughter, I had to spend the entire next day visiting two eye hospitals instead of being there to help out, at ya know, my boys 5th birthday party.</p>
<p>Why 2 hospitals? Because the first place, after a 4 hour wait, said to me that I just needed glasses. They couldn’t see a scratch on my cornea. They said I was just going mad that for the past umpteen years I could see. And the meer fact that Talia poked my eye out triggered me to become acutely aware of how I can’t see anymore.</p>
<p>Fuck that doctor.</p>
<p>I got home at 2pm and decided to trek all the way back into London for a second opinion. This time they found a scratch. I celebrated like a premier league footballer. The nurse thought I was a lunatic and has never seen anyone celebrate the news of a corneal abrasion.</p>
<p>So she’s my hero for the week.</p>
<p>My vision is healing nicely. Thank fuck, because I was pretty very worried.</p>
<h2>Recreated the GOV.UK Design System’s form components in Angular</h2>
<p>As I’ve been writing about in past weeknotes, this work is all done. We finally have Angular versions of the wonderful GOV.UK Design System form components. Big thanks to <a href="https://twitter.com/fazanki">Franco</a>.</p>
<p>I wrote a little <a href="https://twitter.com/fazanki">note of appreciation</a> to Franco in his copy of Form Design Patterns haha.</p>
<h2>Sent out a newsletter</h2>
<p>I mentioned in my last weeknotes that I haven’t sent out newsletter in a while. Sorted that out nicely by sending out a case study about the HMCTS Design System.</p>
<p>And the best bit is that someone from Ofgem replied to me declaring an interest in one of the components. Cool.</p>
<h2>GOV.UK Prototype Kit extensions</h2>
<p>Matt Carey, from HMRC has made the GOV.UK Prototype Kit even better by allowing third parties to create extensions for it.</p>
<p>For example, by adding a <a href="https://github.com/hmcts/frontend/blob/master/src/govuk-prototype-kit.config.json">single config file into the root of the HMCTS Frontend package</a>, a simple <code>npm install @hmcts/frontend --save</code> is all that’s needed for people to use it in the GOV.UK Prototype Kit.</p>
<p>We’ve had a few teething problems and we’ve <a href="https://github.com/alphagov/govuk-prototype-kit/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+extensions">raised some issues</a>. Thanks to <a href="https://twitter.com/joelanman">Joe Lanman</a>, the lead designer on the prototype kit who’s helped get it setup my end.</p>
<h2>Small checkboxes and radios</h2>
<p>The GOV.UK Design System now has small radios and checkboxes. It’s great work and I upgraded the HMCTS Design System’s <a href="http://hmcts-design-system.herokuapp.com/components/filter">filter component</a> to use them. They look a lot better.</p>
<h2>Multi-select autocompletes</h2>
<p>The accessible, single-select autocomplete component I created for <a href="https://www.smashingmagazine.com/printed-books/form-design-patterns/">Form Design Patterns</a> was one of the hardest things I’ve ever built.</p>
<p>So I can imagine that a multi-select autocomplete is even harder to build. To my fortune, this topic came up in the friday x-government design system call last week.</p>
<p>Read more about the solution GOV.UK ended up using in <a href="https://accessibility.blog.gov.uk/2019/04/08/accessibility-lessons-dealing-with-a-large-amount-of-form-inputs/">Accessibility lessons: dealing with a large amount of form inputs</a>. And you can <a href="https://www.gov.uk/search/news-and-communications">see them in action here</a>.</p>
<h2>Started writing an article web components</h2>
<p>Web components seem to be getting more and more attention. But despite their promise they have a number of drawbacks. So I’m writing about that and hope to share that with you soon.</p>
<h2>CSS Tricks article will be published soon</h2>
<p>I mentioned in last week’s weeknotes that I’ve submitted an article to CSS Tricks. They like it and the plan is for it to go live early May. Excited.</p>
<h2>Things I’d like to read again in the future</h2>
<ul>
<li>Jeremy Keith’s article about <a href="https://adactio.com/journal/15050">technology that affects the user experience and technology that doesn’t</a>.</li>
<li>Anne Gibson’s <a href="https://the-pastry-box-project.net/anne-gibson/2014-july-31">alphabet of accessibility issues</a>.</li>
</ul>
Semantic HTML, design crits, GOV.UK form components in Angular, pattern sharing2019-04-07T00:00:00+00:00https://adamsilver.io/blog/week-notes-8/<h2>Things that went well</h2>
<h3>I wrote about the benefits of semantic HTML and ARIA</h3>
<p>In last week’s weeknotes I said I’d like to write about the benefits of semantic HTML and ARIA one day. And this week I did just that. If only all my plans would happen so quickly.</p>
<p>I’m really happy with how it turned out and I’ll share it with the world as soon as possible. As it’s such an important topic I submitted it to CSS Tricks so I’m waiting to hear what they think.</p>
<p>I couldn’t have written this article so quickly or half as well without the help of <a href="https://amyhupe.co.uk/">Amy Hupe</a>. She’s been way more than an editor on this.</p>
<p>She didn’t just make the words vastly better, but she gave me feedback that inspired me to rewrite the whole thing from the ground up improving my tone, structure and content.</p>
<p>And because of that it’s been one of the most enjoyable articles I’ve ever written. Here’s a few of the things Amy taught me:</p>
<ul>
<li>Links work better at the end of a sentence.</li>
<li>One way to write a good summary is to start by bullet pointing the main points in the order you made them.</li>
<li>It’s okay to sweat over a single sentence for 15 minutes straight haha.</li>
<li>How to use less words to say the same thing better. I mean I don’t think I’ve learnt it but I’ve got better watching Amy do it many times this week.</li>
</ul>
<h3>Weekly design crits</h3>
<p>Over the last 12 months the attendance of the design crits at work have been hit and miss because everyone’s under a lot of pressure to deliver.</p>
<p>But recently the attendance has improved a lot which has made them more fun and valuable all round.</p>
<p>This week one of the designers shared an interesting pattern to help users complete a number of independent tasks that can be changed until a deadline passes.</p>
<p>The GOV.UK Design System’s task list pattern isn’t quite the right fit for this. I hope we document this pattern soon so we don’t forget about it.</p>
<h3>Almost finished recreating the GOV.UK Design System’s form components in Angular</h3>
<p><a href="https://twitter.com/fazanki">Franjo Zanki</a> has done some excellent work which I’ll be reviewing next week. Just conditional reveals and file upload to go.</p>
<h3>Sharing government department patterns directly</h3>
<p>In this week’s x-gov design system call, we talked about how departments are starting to use each other’s design system (and frontend code) directly and what problems it can create.</p>
<p>Things like, what happens if a department stops supporting their own design system. Or what if the size of a production codebase is unnecessarily large because of potential duplication across the GOV.UK Design System and the departmental one.</p>
<p>It came up because we at HMCTS want to use the HMRC Design System. And other departments, like DWP and BEIS are using our own HMCTS Design System.</p>
<p>This is a really good problem to have because it’s a sign we’re sharing our stuff more and more. I hope we can collectively move our patterns into the GOV.UK Design System to reduce the risk of such problems.</p>
<h3>I got a ticket to ConCon8</h3>
<p>I got a ticket to ConCon8 where some of the best content designers around give talks and run workshops for the day. I’m looking forward to learning tonnes.</p>
<p>This will be particularly helpful because my team has been without a full time content designer for a while now so this might help me fill the gap a bit.</p>
<h3>People are enjoying and recommending my book</h3>
<p>Obviously I love hearing positive feedback about my book. And I’ve had a number of nice comments since it’s release. And even <a href="https://twitter.com/brad_frost/status/1111274092177575937">Brad Frost recommended my book</a> so I’m really chuffed about that.</p>
<h2>Things that didn’t go well</h2>
<h3>I’ve not sent a newsletter in a while</h3>
<p>I try to send an article to my subscribers once a month but I’m starting to fall behind. Luckily I’ve written a few case studies for my portfolio.</p>
<p>So I’ll send one of those out soon and see how they go down with my subscribers.</p>
<h3>Too many meetings</h3>
<p>At work there’s been a lot of meetings going on and they have really depleted my energy. And they’ve left little time for design research and prototyping.</p>
<p>Hoping things settle down soon on that front.</p>
<h3>Not enough breaks</h3>
<p>And because there are so many meetings, I’ve not made time for proper breaks which is just reducing my energy even more.</p>
<p>I’m definitely better when I take breaks, so this is a mental note to do just that next week.</p>
<h2>Things I’d like to read again in the future</h2>
<ul>
<li>Stephanie Walter’s article on <a href="https://stephaniewalter.design/blog/solving-design-problems-finding-ux-tools-methods-activities/">solving design problems and finding UX tools, methods & activities</a></li>
<li>Chris Coyier’s twitter thread about <a href="https://twitter.com/chriscoyier/status/1106314815130095616">keeping code simple</a></li>
<li>Chris Ferdinandi’s article about how <a href="https://gomakethings.com/clever-javascript-does-not-mean-simple-or-readable/">clever code does not mean simple or readable</a></li>
<li>Cathy Dutton’s article on <a href="https://cathydutton.co.uk/posts/blurred-lines-and-job-titles/">blurred lines and job titles</a></li>
</ul>
React is not a library, Angular generates wrappers, semantic HTML, defining UX2019-03-31T00:00:00+00:00https://adamsilver.io/blog/week-notes-7/<h2>Finished Insanity Max 30</h2>
<p>After a very stressful day on Tuesday I woke up early on the Wednesday feeling like shit. So I ended up missing day 3—booooo! But hey that’s life.</p>
<p>I got the rest of the final week done just fine and I can say for certain that I feel way fitter than I did and I’ve lost a bit of fat and my arms are more defined.</p>
<p>I didn’t temper my diet at all. That is, I ate loads of shit. No doubt I would have done a lot better weight wise if I focused on my diet properly.</p>
<p>I highly recommend this workout program because it’s challenging, fun and only 30 minutes making it hard to come up with excuses not to do it.</p>
<p>First week fail times: 7:01 9:49 7:51 10:42 8:35</p>
<p>Second week fail times: 9:17 10:43 10:01 10:48 11:45</p>
<p>Third week fail times: 17:15 7:14 12:01 8:15 11:43</p>
<p>Fourth week fail times: 19:14 10:44 12:12 11:10 12:15</p>
<p>Fifth week fail times: 8:20 5:55 4:52 6:01 5:58</p>
<p>Sixth week fail times: 12:50 12:21 7:52 7:52 6:20</p>
<p>Seventh week fail times: 14:40 11:41 10:48 12:20 6:26</p>
<p>Eighth week fail times: 16:10 12:21 --:-- 12:22 6:32</p>
<h2>React is not a library</h2>
<p>I’ve always questioned React being referred to as a library. But that’s wrong unless you change the <a href="https://www.programcreek.com/2011/09/what-is-the-difference-between-a-java-library-and-a-framework/">definition of a framework</a> to mean ‘something that only solves part of a problem.’</p>
<p>And this week I came across a great explanation by Eric Elliott in response to an article on Medium. So I’m jotting it down here to refer back to.</p>
<blockquote>
<p>Another hallmark of a framework is Inversion of Control. Don’t call us. We’ll call you. Again, React satisfies that definition of Framework, because we don’t call React methods to do stuff — React calls the methods we create to do stuff. They define lifecycle methods, we fill in the details, and React calls our methods — not the other way around. We don’t even instantiate the views that are the building blocks of our app: React does.</p>
</blockquote>
<h2>Angular generates component wrappers (booo!)</h2>
<p>We’re creating form components for our Angular app which are copies of the components in the GOV.UK Design System (built with Nunjucks).</p>
<p>We wanted to create an Angular version of the <a href="https://github.com/alphagov/govuk-frontend/blob/master/src/components/label/template.njk">Label component from GOV.UK Frontend</a>. So we did exactly that but this caused a problem for checkboxes and radio buttons—the styling was missing.</p>
<p>This is because the CSS uses the sibling selector. And by making the label a component, Angular wrapped it in another element so the sibling wasn’t actually the label element.</p>
<p>Quite possibly the CSS could be rewritten to just target a class on the label within the wrapper element. But then you can’t use <code>:checked</code> and <code>:disabled</code> selectors to change the styles of the label based on the state of the checkbox without JavaScript.</p>
<p>Either way, when I write HTML I like that HTML to be the thing that users get. Not a framework’s opinionated intepretation of my HTML. And that’s another reason I don’t like Angular.</p>
<p>So what to do about it? I <a href="https://twitter.com/adambsilver/status/1110197861751422977">raised this problem</a> on Twitter and the cross government design channel on Slack and got some useful responses. The options were as follows:</p>
<ol>
<li>Change the CSS within GOV.UK Frontend—a package we’re not in control of.</li>
<li>Change the way Angular works—another package we’re not in control of.</li>
<li>Patch the CSS locally by duplicating CSS from GOV.UK Frontend into our application.</li>
<li>Use a directive.</li>
</ol>
<p><a href="https://twitter.com/lazarljubenovic">Lazar</a> suggested we use an Angular directive instead of a Angular component. Unlike components, directives don’t generate wrappers. This is true but it also means you can’t have templates which are needed because the GOV.UK Frontend label component has display logic for things like <code>isPageHeading</code>.</p>
<p>In the end we’ve actually used a directive and a component together. The directive is applied to the component and all it does is manually remove the generated wrapper. Nasty but we think it’s the easiest and quickest way to fix it.</p>
<h2>Semantic HTML—why wouldn’t you?</h2>
<p>I stumbled across Adam Rackis’ tweet which said:</p>
<blockquote>
<p>Are there any benefits to writing semantic html <em>besides</em> accessibility? Even within accessibility, is it not true that attributes can achieve that?</p>
</blockquote>
<p>I ended up responding with a number of tweets that I might even turn into an article one day so dumping them here for now:</p>
<blockquote>
<p>It’s not true, no. You can’t turn a div into a button with attributes alone.<br>
<br>You’ll need JavaScript to add events so that keyboard, mouse and touch users can actually do something with it.<br>
<br>And you’ll need additional attributes to make it focusable.<br>
<br>More work, less robust.<br>
<br>You’ll need to give it a class attribute to style it as opposed to using the button’s unique element selector.<br>
<br>And all of the above to say it’s less performant as you’re writing stuff the browser gives you for free.<br>
<br>And thats code your dev team needs to maintain.<br>
<br>The question of course becomes, why not use semantic html?<br>
<br>And then there is interoperability you’ll lose. For example, viewing a web page in RSS feeders. A list (ul) will be shown as a list.<br>
<br>If you used ARIA to do that, only (supporting) screenreaders will recognise it as a list excluding sighted users.<br>
<br>When most people say “for accessibility” they mean “people not like me” and that mostly means “I can see and I use a mouse”.<br>
<br>So you’d be hurting yourself and people like yourself too.<br>
<br>And besides SEO, interoperability affects the way results show in Google too.<br>
<br>You also get some styling for free. Like <code><b></code> makes things bold (and is semantic now btw).*</p>
</blockquote>
<h2>How to talk about UX</h2>
<p>While I’m usually part of the UX team, often referred to as a UX designer and tasked to ‘do the UX’, I still find it hard to define what UX actually is and what’s involved.</p>
<p>Luckily, I stumbled across <a href="https://medium.com/the-metric/how-to-talk-about-user-experience-ad8d8abd16cc">how to talk about user experience</a> by Michael Schofield. He covers the practical side of the profession:</p>
<ul>
<li>The <a href="https://en.wikipedia.org/wiki/Kano_model">Kano model</a></li>
<li><a href="http://www.sheldon-hess.org/coral/2013/07/ux-consideration-cmmi/">Coral Sheldon-Hess’s CMMI-based model</a></li>
<li>The <a href="http://semanticstudios.com/user_experience_design/">UX honeycomb</a></li>
</ul>
<p>For me there are just 3 guiding principles to designing services. They should be:</p>
<ul>
<li>Useful. The service is valuable to people. It’s something they want or need.</li>
<li>Usable. The service is easy to use.</li>
<li>Delightful. The service exceeds users’ expectiations.</li>
</ul>
<p>Most people think ‘delight’ means animation or something shallow like that. But that’s not really what it is. <a href="https://www.youtube.com/watch?v=ewpz2gR_oJQ">Delight</a> happens when you exceed someone’s expectation.</p>
<p>The problem is that once you’ve exceed their expectation it becomes the norm. So in my head a particular slice of delight is ephemeral due to hedonic adaptation.</p>
<p>Definitely something I’d like to flesh out a little more for my own piece of mind.</p>
<h2>Things I’d like to watch and read again in the future</h2>
<ul>
<li><a href="https://www.smashingmagazine.com/2019/02/accessibility-webinar/">How a screen reader user accesses the web by Leonie Watson</a></li>
<li><a href="https://www.youtube.com/watch?v=T2CjuAwrAq8">Accessibility, back to the future by Bruce Lawson</a></li>
<li><a href="https://m.signalvnoise.com/dont-solve-the-problem/?authuser=0">Leaders ask questions instead of solving problems</a></li>
<li><a href="https://twitter.com/KaviH/status/1110626979244433408">Edge cases are the job</a></li>
</ul>
Writing workflow, context switching and some useful links2019-03-24T00:00:00+00:00https://adamsilver.io/blog/week-notes-6/<h2>Insanity Max 30—week 7</h2>
<p>Definitely feeling fitter and with less wobbly bits. The workouts are horrible still but I’m lasting way longer in all the workouts expect the 5th day. Times below and one week to go. That rhymes.</p>
<p>First week fail times: 7:01 9:49 7:51 10:42 8:35</p>
<p>Second week fail times: 9:17 10:43 10:01 10:48 11:45</p>
<p>Third week fail times: 17:15 7:14 12:01 8:15 11:43</p>
<p>Fourth week fail times: 19:14 10:44 12:12 11:10 12:15</p>
<p>Fifth week fail times: 8:20 5:55 4:52 6:01 5:58</p>
<p>Sixth week fail times: 12:50 12:21 7:52 7:52 6:20</p>
<p>Seventh week fail times: 14:40 11:41 10:48 12:20 6:26</p>
<h2>Things that didn’t go well</h2>
<p>A number of things were happening this week to make things particularly stressful:</p>
<ul>
<li>We moved to a new office in Aldgate and there are no windows. This sucks after about an hour of work. I’ve ended up working in little breakout areas spread around the corridors to get some natural light. But that defeats the purpose of being co-located with my teammates.</li>
<li>Working on a number of complex things at once has made things worse. I’m a work on one thing well type of guy. But this week, we’ve kicked off a number of workstreams. Which has meant loads of meetings about different things affecting my rhythm a lot.</li>
<li>And on top of this, the people needed across these workstreams are dispersed in different locations and are working on different things. Breaking down silos and encouraging co-design is becoming a big challenge and something I’ll continue to work on.</li>
</ul>
<h2>Things that wen’t well</h2>
<ul>
<li>It’s been well over a month since I’ve been out to research, so that’s something that went really well and supported the complex work in one of our workstreams. Research never fails to be one of the best things about my job.</li>
<li>We did our first retro in 4 months. Now not doing one for so long is bad, but doing one was really important and for a number of teammates this was their first retro since joining.</li>
<li>More of the designers across the program have been able to attend the weekly design crits. This has made things more productive and more fun too.</li>
<li>Improving my writing workflow. I’ve got ideas, notes and drafts all over the place in Google Keep, Google Docs, Dropbox Paper, Medium and Github. I’m starting to move to a simple model of Google Keep and Google Docs.</li>
<li>The new office is near the GDS offices, so that’s helpful!</li>
<li>CSS Tricks shared my article</li>
</ul>
<h2>Things to watch and read</h2>
<ul>
<li><a href="https://www.hustwit.com/rams/">Rams: a documentary portrait of Dieter Rams</a></li>
<li><a href="https://grillopress.github.io/2019/01/31/one-thing.html">Andrew Duckworth on one thing per page</a></li>
<li><a href="https://gomakethings.com/building-accessible-websites-and-apps-is-a-moral-obligation/">Chris Ferdinandi on building accessible websites and apps is a moral obligation</a></li>
<li><a href="http://www.hollidazed.co.uk/playbook/">Ben Holliday’s design playbook</a></li>
<li><a href="http://www.myddelton.co.uk/blog/research-heresies">Will Myddelton’s on user research</a></li>
</ul>
Angular forms, hiding elements, boring development, responsive design mindsets2019-03-17T00:00:00+00:00https://adamsilver.io/blog/week-notes-5/<h2>Insanity Max 30—week 6</h2>
<p>The first week of month two was hell. But I did way better in the second week which you can see in my times.</p>
<p>First week fail times: 7:01 9:49 7:51 10:42 8:35</p>
<p>Second week fail times: 9:17 10:43 10:01 10:48 11:45</p>
<p>Third week fail times: 17:15 7:14 12:01 8:15 11:43</p>
<p>Fourth week fail times: 19:14 10:44 12:12 11:10 12:15</p>
<p>Fifth week fail times: 8:20 5:55 4:52 6:01 5:58</p>
<p>Sixth week fail times: 12:50 12:21 7:52 7:52 6:20</p>
<p>I’ve noticed a difference in how I feel as well. Really hoping to squeeze out even better results in the last two weeks.</p>
<h2>Making Angular forms behave</h2>
<p>For quite a while I’ve been told Angular forms have to work in a certain way. For example, you have to validate errors as the user types or that you can’t validate a <a href="https://design-system.service.gov.uk/components/date-input/">date input</a> because the three separate inputs have to be validated together.</p>
<p>But this week, I’ve had a massive break through thanks to <a href="https://twitter.com/fazanki">Franjo Zanki</a>. In just a few hours he’s managed to <a href="https://github.com/hmcts/prd-pui-manager/pull/37/files">make Angular forms work</a> based on the established patterns and guidance in the <a href="https://design-system.service.gov.uk/">GOV.UK Design System</a>. He’s made me so happy!</p>
<p>And it’s also been really fun pairing with him to get the components working just right. It’s a positive reminder of how great things can be when we break down silos and work together.</p>
<h2>Hiding elements the boring way</h2>
<p>I setup a <a href="https://twitter.com/adambsilver/status/1105789140824662016">Twitter poll asking how users prefer to hide elements</a>. By adding a class of <code>hidden</code> or by setting the style property on the element directly with <code>el.style.display</code>.</p>
<p>The best part of the poll was that a lot of people responded saying neither and that we should use the native <code>[hidden]</code> attribute for this. As I briefly explained on the thread <code>[hidden]</code> isn’t as well supported and could make some other things tricky.</p>
<p>This is something I’ve been meaning to write about for a very long time now. So note to self: write about it will ya!</p>
<h2>Be boring</h2>
<p>Chris Coyier asked his followers to share their favourite <a href="https://twitter.com/chriscoyier/status/1106314815130095616?s=20">articles about <em>boring</em> development</a>. There’s some really really good articles I don’t want to forget on there.</p>
<p>And <a href="https://andy-bell.design/">Andy Bell</a> mentioned <a href="https://adamsilver.io/blog/the-boring-front-end-developer/">The Boring Frontend Developer</a>. Thanks Andy.</p>
<h2>Mindsets: responsive design and accessible design</h2>
<p>I’ve been chatting with <a href="https://www.edwardhorsford.com/">Ed</a> again this week. This time about the ways an experience can change on small and big screens. Specifically:</p>
<ul>
<li>do we hide content on small screens to avoid scrolling and keep things focused. The main downside meaning that mobile users don’t get the same features/content available to them degrading the experience in other ways.</li>
<li>or, do we just let that content stack (or make it togglable) and keep things consistent with the same features on all screen sizes. The downside being potentially more scrolling and a less focused experience.</li>
</ul>
<p>My problem with the former is that most designers do this to keep things <em>looking</em> good on small screens. I think they jump to this without considering whether it was really a problem for mobile user to literally flick past the now more prominent content.</p>
<p>Either way, this is another article I want to write about.</p>
<h2>Tired of writing</h2>
<p>Not a week(note) goes by where I don’t have something else I want to write about. But I’m also really tired of writing. Nobody makes me write but me. And that’s because despite how difficult I find it, I know how valueable it is.</p>
<p>Either way, I’m overwhelmed by the increasingly large number of Google Keep notes, Google doc and Dropbox Paper drafts, Github issues, tweets and weeknotes that I want to sort out.</p>
<p>And while I’m finding these weeknotes useful, they are also taking up my previous writing energy of doing the hard work of writing a proper finished article.</p>
Extending the GOV.UK Design System, progressive enhancement, naming patterns2019-03-10T00:00:00+00:00https://adamsilver.io/blog/week-notes-4/<h2>Insanity Max 30—week 5</h2>
<p>The first month of this program was impossible. And yet, the second month is a level up, which you’ll see in my max out times.</p>
<p>First week fail times: 7:01 9:49 7:51 10:42 8:35</p>
<p>Second week fail times: 9:17 10:43 10:01 10:48 11:45</p>
<p>Third week fail times: 17:15 7:14 12:01 8:15 11:43</p>
<p>Forth week fail times: 19:14 10:44 12:12 11:10 12:15</p>
<p>Fifth week fail times: 8:20 5:55 4:52 6:01 5:58</p>
<p>Three weeks to go.</p>
<h2>Extending components from the GOV.UK Design System</h2>
<p>I’ve been designing a currency input component for the HMCTS Design System because it’s needed across a number of services.</p>
<p>The currency input is basically a text input with a currency symbol prefixed to the input. And some accessibility provisions that provide an equivalent experience for non-sighted users.</p>
<p>My first thought was to extend the Input component by overriding parameters using Nunjuck’s <code>set</code>. But you can’t use <code>set</code> to override properties of an object.</p>
<p><a href="https://www.edwardhorsford.com/">Ed</a> suggested using a Nunjucks filter. In Eleventy something like this:</p>
<p>eleventyConfig.addFilter(‘mergeObjects’, function(item, …rest) {<br>
return Object.assign({}, item, …rest);<br>
});</p>
<p>Then in the template:</p>
<p>{% set options = {} | mergeObjects({size: ‘large’}, options) %}</p>
<p>But then, I thought I’d check to see how the GOV.UK Design System is doing this. For example, the Select and the Input components are similar. And I noticed they just duplicate parts while ensuring the parameters are the same where possible.</p>
<p>This seems like a sensible approach so I’m going to try doing this first. This way I get to feel some of the pain of duplication (if any) before going down the complicated route.</p>
<h2>Progressive enhancement: things from the past don’t have to break in the future</h2>
<p>I read <a href="https://mobile.twitter.com/wesbos/status/1102640251141582849">a tweet by Wes Bos</a> talking about how a site built in Polymer (from a couple years back) will break in the latest version of Chrome.</p>
<p>It’s a good reminder of how the web doesn’t have to be built like this. <a href="https://twitter.com/NickColley/status/1103671648442638336">Good advice and technical design is timeless</a>.</p>
<h2>Pattern renaming with Amy</h2>
<p>The best part of my week was spent with <a href="http://amyhupe.co.uk/">Amy</a> working out a better name for the “Help users perform an action in bulk” pattern.</p>
<p>After a machine gun round of questions and plenty of back and fourth we came up with a much better name: “Help users to manage items in a list.”</p>
User interfaces: hiding content should be a last resort2019-03-04T00:00:00+00:00https://adamsilver.io/blog/user-interfaces-hiding-content-should-be-a-last-resort/<p>A disproportionate amount of time is spent designing complex interactions that hide content at the cost of usability.</p>
<p>Links are hidden within menus; hints behind tooltips; images in carousels; all sorts inside accordions and tabs; and <a href="https://adamsilver.io/blog/the-problem-with-float-labels-and-what-to-do-instead/">labels inside inputs</a>.</p>
<p>When we hide content, there’s a greater risk users won’t see it. There’s a higher reliance on digital literacy and it’s generally more labour intensive for users.</p>
<p>There’s also a widespread assumption that splitting content across pages is bad even when it mostly <a href="https://designnotes.blog.gov.uk/2014/07/14/things-we-learnt-designing-register-to-vote/">improves the experience</a>.</p>
<p>In my experience, content is hidden because:</p>
<ol>
<li>people mistake ‘clicking’ for ‘engaging’</li>
<li>people are trying to win an award for minimalism</li>
<li>people are trying to find ways to declutter an interface</li>
<li>people are trying to genuinely improve the experience</li>
</ol>
<p>Only the last point is of value to users.</p>
<p>In The Life Changing Magic of Tidying Up, Marie Kondo says:</p>
<blockquote>
<p>“Effective tidying involves only two essential actions: discarding and deciding where to store things. Of the two, discarding must come first.”</p>
</blockquote>
<p>I’ll rewrite her quote and apply it to design.</p>
<blockquote>
<p>“Effective design involves two essential actions: discarding the superfluous and deciding where to put things. Of the two, discarding must come first.”</p>
</blockquote>
<p>This means we have to push back against everyone’s natural inclination to add more stuff onto a page.</p>
<p>And instead, do the hard work to cut content to its irreducible core and then just show it.</p>
<p>When all that remains is essential, there’s less to read and less of a need to resort to patterns that hide content.</p>
<p>Both of which improves the experience for users.</p>
Form builders, design system thoughts, new design system components2019-03-03T00:00:00+00:00https://adamsilver.io/blog/week-notes-03/<h2>Insanity Max 30—first month done</h2>
<p>Let’s start with the easy one. I’m half way through this two month program. I have seen huge results in my fitness levels in just 4 weeks (results below).</p>
<p>Looking forward to and dreading month 2 in equal proportions as I am pretty sure the level goes up a notch. Not to mention how badly I’ve eaten in the last few days involving KFC and chinese takeaway.</p>
<p>First week fail times: 7:01 9:49 7:51 10:42 8:35</p>
<p>Second week fail times: 9:17 10:43 10:01 10:48 11:45</p>
<p>Third week fail times: 17:15 7:14 12:01 8:15 11:43</p>
<p>Forth week fail times: 19:14 10:44 12:12 11:10 12:15</p>
<p>Four weeks to go.</p>
<h2>Form builders—I’m dubious</h2>
<p>I’ve come across more form builders that I can count on my fingers. And they’ve always ended up being overly constraining and complex to change. The problem with form builders is that they run on config. If the config doesn’t do what you want, the form builder needs to adapt and change.</p>
<p>So I’ve started making some notes and I hope to write an article on this one day.</p>
<h2>Fun questions about design systems</h2>
<p>Rarely a week goes by where <a href="https://amyhupe.co.uk/">Amy</a> and I don’t talk about design systems. What normally happens is Amy asks a really interesting and difficult question.</p>
<p>Then we have a lot of fun chatting back and forth, she’s wrong, I’m right, stuff like that—joke, seriously, it’s usually the other way around—then I fall asleep dreaming about design systems.</p>
<p>Anyway, I really don’t want to forget some of our conversations as I think there’s some gold worth remembering. So I’m going to start by jotting down the questions here. Hopefully they’ll jog my memory in the future.</p>
<p>What’s a variant? Do they exist? When is something a variant versus just a way to apply the thing in a specific context? How configurable should a single component be? How flexible should a component be and what are the tradeoffs for making it flexible or not flexible enough? Delivering quickly vs delivering with quality. How to prioritise what to work on. And how the seemingly simplest design system problem is invariably full of complexity.</p>
<h2>Three new components added to the HMCTS Design System</h2>
<p>I felt particularly productive this week and that resulted in 3 new components being added to the design system. Namely: <a href="http://hmcts-design-system.herokuapp.com/components/badge">Badge</a>, <a href="http://hmcts-design-system.herokuapp.com/components/form-validator">Form Validator</a> and <a href="http://hmcts-design-system.herokuapp.com/components/sortable-table">Sortable Table</a>.</p>
<p>I love sharing my work and I love getting critique from the community as there’s always something to consider or improve.</p>
<h2>Banardo’s differentiates buttons and links</h2>
<p><a href="https://twitter.com/KellieDesigner/status/1101099295804219394">Banardo’s released their design system</a> recently and it looks great. I noticed that their calls to action (links) and submit buttons are styled differently while still keeping their respective signifiers intact. Both styles are prominent and in-keeping with the brand. Both have clear hover and focus states. Nice.</p>
<p>I’m interested to hear how users find them. My reckon is that they’ll get on just fine.</p>
<h2>Started learn UI design course</h2>
<p>I’ve enrolled on the Learn UI design course because I want to get better and faster at designing interfaces.</p>
<p>I’ve got a lot on in and outside of work so I’m not expecting to get through the course super quick. Plus I’ve recently redesigned my site and I’m happy with it.</p>
<p>But I will definitely get it done in the next few months. And I’ll be sure to report back with some results hopefully in the future. I might redesign <a href="https://maintainablecss.com/">maintainablecss.com</a> as part of the course.</p>
Handling links in Angular, buttons versus links, design system architecture, journey mapping2019-02-24T00:00:00+00:00https://adamsilver.io/blog/week-notes-02/<p>I found <em>finishing</em> last week’s weeknotes really fun. But I found writing them wasn’t as easy as I thought they’d be. That’s because it takes me a really long time to write things down with any clarity.</p>
<p>Still, they were really valuable to me. And like I said at the end of last week’s notes, having a more ‘official’ set of weeknotes will stop me drowning in Google Keep notes that, if I’m honest, I’m probably not going to look at again.</p>
<p>And then there’s the fact you can’t see them either 'coz their private.</p>
<p>One of the things I like already about writing weeknotes is that I can see how half-baked my thoughts are about things. And I hope to see how long it takes to find clarity on some of the topics I write down here.</p>
<p>There are so many interesting topics that crop up in my head, on the service I’m designing or more often that not talking to other people about an interesting thing. And to be able to remember them and realise how uncertain I am about them is useful to me.</p>
<p>Let’s go.</p>
<h2>Insanity Max 30 — week three done</h2>
<p>This training program is really hard and really fun. And in the third week it gets harder on day 2 and 4 with Tabata Strength. You’ll see that in my times below.</p>
<p>Also, I’m giving the optional 6th day a miss coz I’m to tired and I’m writing these notes instead.</p>
<p>First week fail times: 7:01 9:49 7:51 10:42 8:35</p>
<p>Second week fail times: 9:17 10:43 10:01 10:48 11:45</p>
<p>Third week fail times: 17:15 7:14 12:01 8:15 11:43</p>
<p>Five weeks to go.</p>
<h2>Angular can handle links (yay)</h2>
<p>Last week I noted down that <a href="https://adamsilver.io/blog/week-notes-01/#should-links-be-links-inside-single-page-applications%3F">Angular had problems with implementing links as links</a>. And it doesn’t. I was wrong to say that.</p>
<p>This is how you do it:</p>
<p><a [routerlink]="/url/goes/here"></p>
<p>And this will generate a regular link with an <code>href</code> that Angular knows to intercept. Lovely.</p>
<h2>Buttons versus links</h2>
<p>Last week I watched Oliver Byford’s brilliant talk at the London Accessibility Meetup. And at <a href="https://youtu.be/HJshEsMH_tg?t=663">11 minutes in he talks about how and why the GOV.UK start buttons (which are links) are converted into buttons</a>.</p>
<p>In short:</p>
<ul>
<li>JavaScript makes the <kbd>space</kbd> key activate the link</li>
<li><code>role="button"</code> is added to the link so that it’s recognised and announced as button by voice dictation and screen reader software.</li>
<li><code>draggable="false"</code> is added to the link so that people with dexterity impairments don’t accidentally drag the link instead of cliking it.</li>
</ul>
<p>Things swirling around in my head are:</p>
<ul>
<li>It’s a win for voice dictation users because they see a button and they interact with it as a button.</li>
<li>For screen reader users I’m less sure. Normally links would be part of the links list (activated with a special shortcut). If it was a link, users may want to bookmark or open it in a new window. On the other hand, start buttons in this context aren’t likely to be bookmarked. And sighted (screen reader) users might not realise it’s a link because it looks like a button, so they wouldn’t bother trying to do those things anyway.</li>
<li>Preventing the ability to drag the button (link) stops me from dragging it onto the bookmarks bar. And arguably we’d want to add the attribute to every link on the page, not just ones that look like buttons? Maybe more needs to be done here beyond just an attribute. Like if the user does a little drag ignore it, but a big drag might indicate a clearer intent to drag it.</li>
<li>Implementation wise, I’m thinking why not just make it a button (when JS is available and capable) and make it redirect. That should be a lot less code overall.</li>
<li>The team that worked on this are the most thoughtful designers I know so I’m interested to find out more about what went into the decision.</li>
</ul>
<p>Like always, design is about tradeoffs—more specifically making the right ones. Despite the points above, it still seems like a reasonable decision has been made.</p>
<h2>Design system architectural choices</h2>
<p>From the same talk I noticed that Ollie’s fictional service used bolder and bigger label/legend styles for the form fields than what the default provides in the GOV.UK Design System.</p>
<p>And I found that interesting because in the services I’ve been designing I’ve also made the labels/legends bigger and bolder. I’ve done this because:</p>
<ul>
<li>it’s more consistent with fields where the <code>label</code> or <code>legend</code> and <code>h1</code> are one and the same and therefore bold and much bigger.</li>
<li>it provides a better hierarchy by clearly differentiating between the field’s <code>label</code> and the hint text. Or the individual input label within the field like you’d find with radio buttons.</li>
</ul>
<p>That led me to asking the GOV.UK Design System team why the defaults are smaller and not bold. This was the response:</p>
<blockquote>
<p>The reason the labels have the standard font size / style as default is that in a lot of cases this is what you’d want. Any scenario that has a group of inputs, such as Addresses, Credit card numbers, Date Input want the lowest hierarchy on the inputs themselves so that you can bump up the legend one level.</p>
</blockquote>
<blockquote>
<p>In addition to that is also allows us to have a label component that can be used across radios and checkboxes. It’s not a technical constraint as such, it was a system choice.</p>
</blockquote>
<blockquote>
<p>Because most of the way we’ve constructed the components is additive , the default for something like this would be the base style and we give you the tools to add to it when your design requires.</p>
</blockquote>
<p>This is really useful to know because I can see how my suggestion is problematic within the current architecture. And while there are ways around it, there would be tradeoffs in changing the defaults to be what I thought they should be.</p>
<p>Which is another important point. The design system serves lots of users. This would need to become a much bigger problem to warrant the effort of changing this. Because ultimately with little effort I am able to configure the components as I need.</p>
<p>This is good example of how technology and design are intertwined and should be considered together.</p>
<h2>Confused by mapping</h2>
<p>One of my big skills gaps is in creating maps: journey maps, service blueprints and things like that.</p>
<p>I get confused partly because I’ve just not done very much of it, and because I am often finding myself getting hung up on what the columns and swimlanes should be. Other times I think I need a journey map, but what I need is more like a comic book strip.</p>
<p>What I’m very slowly learning is to not get hung up on the structure and think about the problem I’m trying to solve and who the map is intended for. That sounds great, but I feel this will take me a long time to grasp.</p>
<p>I really need someone to model this for me—like with 100 different maps. Any takers?</p>
Defining interaction design, scoping a rich text editor component, links inside SPAs, fudgability2019-02-17T00:00:00+00:00https://adamsilver.io/blog/week-notes-01/<p>I’ve decided to give weeknotes a go. I don’t really know if there’s a format I should follow but I’m just going to focus on things I did (or read) that I think are worth highlighting.</p>
<h2>What’s interaction design?</h2>
<p>Last week I changed various pieces of content on my site. For example, my home page sub title now reads:</p>
<blockquote>
<p>‘Hey 👋 I’m Adam. I help discover user needs and translate them into simple and inclusive digital services for the web.’</p>
</blockquote>
<p>I wanted capture what I do in as few words as possible. I was triggered to do this after being a guest on <a href="https://boagworld.com/season/23/episode/2304/">Paul Boag’s podcast</a> last week. He asked me what an interaction designer does and where the role starts and ends.</p>
<p>The overly short answer is in the one liner above. The long answer is in the podcast, but I’ll say that it’s hard to define because interaction design is a subset of service or user experience design.</p>
<p>And the whole team is responsible for that. And so the lines are blurry particularly between developers, content designers, architects, service designers and product owners.</p>
<p>If you listen to the podcast, you should know that I didn’t come up with the answers all on my own. I asked <a href="https://das.house/">Dave House</a> on Slack and I stole things <a href="https://wearehowdoi.com/news/2019/1/7/takefivewith-craig-abbott">Craig Abbott said in an interview</a> and other things from <a href="https://charlesrt.uk/blog/interaction-design-clearing-the-confusion/">Charles Reynolds-Talbot’s article</a>.</p>
<h2>Insanity Max 30 — finished week two</h2>
<p>Despite playing 3-5 hours of tennis a week for a good few months, I’ve noticed that I don’t need my belt anymore! That’s probably because I eat way too much chocolate when nobody’s watching.</p>
<p>In the past I’ve had good fun and good success with Insanity so when my friend told me about Insanity Max 30 I decided to give it a go. It’s a shorter regime (30 minutes) and full of fun crazy moves.</p>
<p>The way it works is that you follow the moves and the timing until your body gives out. Then you note down the time. Then you see your times improve over the weeks.</p>
<p>The first week was disgusting and I felt like giving up after a minute but managed some pretty decent times. But I felt an improvement in the second week. You can see my times below.</p>
<p>First week fail times: 7:01 9:49 7:51 10:42 8:35</p>
<p>Second week fail times: 9:17 10:43 10:01 10:48 11:45</p>
<p>Six weeks to go.</p>
<h2>Released a rich text editor component</h2>
<p>We added the <a href="http://hmcts-design-system.herokuapp.com/components/rich-text-editor">rich text editor component</a> into the HMCTS Design System. It uses the <code>contenteditable</code> browser API which is powerful and requires very little JavaScript.</p>
<p>The need for this came from judges needing to send questions to appellants (citizens) to hopefully avoid the need for an in-person hearing. Without formatting, citizens would have to read a large block of text. Bad.</p>
<p>The rich text editor had controls for bold, italic, underline, bulleted lists and numbered lists.</p>
<p>The problem was that citizens don’t always understand what bold and italic signify. And underlined text is reserved for links. Having underlines on text that you can’t click is confusing.</p>
<p>Given the above, I’d usually opt to kill all three controls to keep things lean. But when it comes to design systems that are used by many, we think it’s best to make things configurable.</p>
<p>This is something I’ve learnt from <a href="https://amyhupe.co.uk/">Amy Hupe</a>—she works on the GOV.UK Design System which our design system depends on—over one of our many Whatsapp design chats. I was going on about doing the leanest, simplest thing and making components specific so they can be delivered quickly.</p>
<p>Amy was saying how that doesn’t work so well in government because we can’t possibly understand the entire nuanced problem space. I’ve noticed this to be true for our design system too.</p>
<p>So for this component the three controls are turned off by default. This way, should there be a need for these controls (perhaps for judge to judge communication), we can turn them on individually through configuration alone.</p>
<p>Also, some browsers such as Chrome, let users format text using keyboard shortcuts whether you show toolbar controls or not. For example, pressing <kbd>CMD+B</kbd> makes text go bold. Other browsers such as Firefox will open the user’s bookmarks instead.</p>
<p>Because of this, we can’t just detect these keys and prevent the default behaviour. Instead I think we’ll need to consider filtering out the forbidden tags somehow.</p>
<p>If the tags are filtered out on the server then what the user sees is not what’s sent. Bad.</p>
<p>If the tags are filtered on the client (by listening to the <code>keydown</code> event or similar) I worry that the user might see a flicker or that the caret might move position.</p>
<p>I’ll need to learn more about this.</p>
<h2>Should links be links inside single page applications?</h2>
<p>The project I’m currently working on uses Angular. And for reasons I don’t fully understand yet, Angular doesn’t work when you use <code><a href="/path/to/resource"></code> for links. Urgh.</p>
<p>The suggestion was to use <code><button></code>s instead which feels wrong to me. To the user, navigating should feel like navigating and offer the same behaviours and signifiers.</p>
<p>I decided to see ask <a href="https://twitter.com/adambsilver/status/1095671870727307266">Twitter and I got some good responses</a>. Here’s a few:</p>
<blockquote>
<p>‘I’d use links. You’re still navigating somewhere. Unless you’re doing something like submitting a form I wouldn’t use a button.’—Craig Abbott</p>
</blockquote>
<blockquote>
<p>‘This is the mantra: If it goes somewhere, it’s a link. If it does something, it’s a button.’—Charlie Triplett</p>
</blockquote>
<blockquote>
<p>‘Screen readers don’t care. For deep linking and bookmarking and easier navigation out of the box with browsers, use hrefs. If purely UI use a button.’—Nick</p>
</blockquote>
<blockquote>
<p>‘If the control points to a resource, it may have a route (direct url) and so it should be an A tag with href. If the control only trigger an “in place” behavior, then I think it should be a button. FMPOV, Single Page Apps arn’t an excuse for not giving real URL (routes) to contents.’—Mab</p>
</blockquote>
<blockquote>
<p>‘I think for reasons of accessibility then links. We know as devs when a site is an SPA… end users, especially those using screen readers, probably still see it as a normal site.’—Michael</p>
</blockquote>
<h2>Fudgability</h2>
<p>Having worked on a number of internal case management systems there seems to be two approaches to design that crop up in my head and in conversations with teammates.</p>
<ol>
<li>You can get clever and try to change the interface to give users exactly what they need in order to send them down the path they should be taking. Or</li>
<li>You reflect back the true state of things and give users all the options so they can do whatever they choose.</li>
</ol>
<p>At first (1) sounded like the best approach. But in my experience it’s (2) that is the way to go. And then I stumble across <a href="https://twitter.com/MrAlanCooper/status/1094991467012022272">Alan Cooper’s tweet storm on fudgability</a> where he articulates this better than I ever could.</p>
<p>Here’s a few bits I’ve pulled out:</p>
<blockquote>
<p>‘A fundamental truth about any good white collar worker–manager or practitioner–is that they know how to react to different situations that arise on a daily basis, adapting and adjusting their behavior to suit. 1’</p>
</blockquote>
<blockquote>
<p>‘Virtually all such software is designed and built based on the insane idea that business processes are like a predictable series of sequential operations. A then B then C then D then check the box and move on to the next docket. 6’</p>
</blockquote>
<blockquote>
<p>‘Virtually all back office software is built on an idealized concept of how businesses work, and are utterly incapable of dealing with how businesses actually work. 7’</p>
</blockquote>
<blockquote>
<p>‘The job of the interaction designer is to deconstruct systems like this and create digital solutions that combine the best attributes of both approaches, both human and idealized work flow. 18’</p>
</blockquote>
<blockquote>
<p>‘A good designer creates a system that is adaptable, adjustable, revealing of state, willing to let the human lead, capable of holding parts of the information flow in a state of suspense. 19’</p>
</blockquote>
<h2>The five dysfunctions of a team</h2>
<p>My friend Dan is on a streak (of two) of recommending me books that are light but full of practical advice. His latest rec was <a href="https://www.tablegroup.com/books/dysfunctions">The Five Dysfunctions of a Team</a>. I almost cracked out the whole lot in a week of commutes.</p>
<p>A high performing team has individuals who trust each other, are comfortable in conflict and who are focused on the results of the group (not the individual). And the book explains how to go about building a team like this.</p>
<p>I’d love to be able to help build a team like this and I’ll try to apply things where I can. But I fear this is one of those books where I’ll read it and forget it. And that even if I manage to do tiny things here in there, they’ll effectively be, well, ineffective.</p>
<p>The book tells a story from the point of view of a CEO and while you don’t have to be CEO, I do think you need to be in a leadership position to implement the things in the book.</p>
<p>And that’s me done. That felt therapeutic. And this may also help me stop drowning in random Google Keep notes.</p>
How to avoid optional form fields with branching questions2019-02-05T00:00:00+00:00https://adamsilver.io/blog/how-to-avoid-optional-form-fields-with-branching-questions/<p>One crucial form design principle is <a href="https://www.gov.uk/service-manual/design/form-structure#know-why-youre-asking-every-question">knowing why you’re asking every question</a>.</p>
<p>We should only ask users for information we need to provide a service. For example, most sites that ask for age or sex, don’t need them to provide the service. Silly.</p>
<p>Silly because it requires more effort to complete more fields. It will probably stop some users from using the service. And it means having to store more data. All this for no purpose.</p>
<p>That said, sometimes we can ask users more questions. We can then use that information to improve their experience.</p>
<p>A simple way to show optional fields is to put ‘(optional)’ within the question’s label. But this is not necessarily the best experience for users. This is where branching can help.</p>
<h2>Option #1: conditional reveal</h2>
<p>Take a user who’s applying for a new passport. We could offer them the option to receive text message updates by providing their mobile number.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/how-to-avoid-optional-form-fields-with-branching-questions/1.png" alt=""><figcaption>Asking the user for their mobile number and explaining why with hint text</figcaption></figure>
</div>
<p>On the face of it, this looks well designed with a clear label and hint text explaining why the user might choose to provide this information.</p>
<p>The problem is that the design assumes users will read all the text to understand the question. But, most users <a href="https://www.nngroup.com/articles/f-shaped-pattern-reading-web-content/">do not read all the words on a page</a>. But even if they did, we can let the design do the hard work, so they do not have to.</p>
<p>The Service Manual says to <a href="https://www.gov.uk/service-manual/design/form-structure#design-for-the-most-common-scenarios-first">use ‘branching’ questions so people only have to answer questions that are relevant to them</a>.</p>
<p>We can follow this guidance by first asking the user if they want to receive text message updates. If the user selects ‘Yes’, we can <a href="https://design-system.service.gov.uk/components/radios/#conditionally-revealing-content">conditionally reveal</a> the mobile phone field.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/how-to-avoid-optional-form-fields-with-branching-questions/2.png" alt=""><figcaption>Conditionally revealing a form field based on selected radio buttons</figcaption></figure>
</div>
<p>Importantly, the label clearly tells the user what they need to do without any hint text.</p>
<p>Avoid using inline radio buttons to reveal content because it may <a href="https://github.com/alphagov/govuk-frontend/pull/970#issuecomment-422759580">not be clear what the content relates to</a>.</p>
<h2>Option #2: separate page</h2>
<p>I’ve been designing a registration flow for solicitors where we ask users to provide their DX reference. The whole question, which is two separate inputs, is optional.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/how-to-avoid-optional-form-fields-with-branching-questions/3.png" alt=""><figcaption>Asking for the DX reference is optional</figcaption></figure>
</div>
<p>If the user submits the form without entering a DX number or DX exchange, the user is taken to the next step. Simple enough.</p>
<p>But what if the user enters a DX number and leaves the DX exchange blank? I can think of three less than ideal ways to deal with this.</p>
<ol>
<li>
<p>Let users continue regardless. Give them a chance to clean up the details later, perhaps in a <a href="https://design-system.service.gov.uk/patterns/check-answers/">check answers</a> screen or beyond.</p>
</li>
<li>
<p>Blank out both fields for the user behind the scenes. Let them continue as if they left both fields empty.</p>
</li>
<li>
<p>Show a (verbose) error message if the user only completes one field. Something like ‘Enter a DX exchange — because you entered a DX number, the exchange is needed to complete the DX reference’.</p>
</li>
</ol>
<p>Instead of using the conditional reveal pattern from earlier, we could take the user to a separate page. First, ask the user if they have a DX reference.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/how-to-avoid-optional-form-fields-with-branching-questions/4.png" alt=""><figcaption>Asking a branching question to simplify the journey</figcaption></figure>
</div>
<p>If the user selects ‘Yes’, take them to a new page showing the DX number and DX exchange fields.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/how-to-avoid-optional-form-fields-with-branching-questions/5.png" alt=""><figcaption>A simplified version of the original DX reference screen where the question is required</figcaption></figure>
</div>
<p>Now we know the user has a DX reference both fields are required. Because of this, we do not need to:</p>
<ul>
<li>mark the question as optional</li>
<li>have complex validation rules with verbose error messages</li>
<li>mess up our database with partial data</li>
</ul>
<h2>Conditional reveal vs separate page</h2>
<p>Both patterns adhere to the branching guidelines but it’s not especially clear when to use one pattern over another.</p>
<p>The conditional reveal:</p>
<ul>
<li>keeps the original question on the screen to provide context</li>
<li>avoids a page load</li>
<li>makes it easier for the user to change their mind without moving back and forward between screens</li>
</ul>
<p>But revealing content in response to selecting a radio button may:</p>
<ul>
<li><a href="https://github.com/alphagov/govuk-design-system-backlog/issues/37#issuecomment-533134507">confuse users who do not expect it</a>—this may not be a problem as this approach becomes more common (within and outside the service)</li>
<li>make the experience inconsistent and less predictable—you cannot reveal every kind of field this way, for example radio buttons within radio buttons</li>
<li>not be spotted by all users, especially those who use a screen magnifier</li>
<li>overwhelm users who have cognitive impairments</li>
</ul>
<p>It needs JavaScript to work and gives a poor experience <a href="https://adamsilver.io/blog/javascript-isnt-always-available-and-its-not-the-users-fault/">when JavaScript fails</a>.</p>
<p>If you use something like a <a href="https://design-system.service.gov.uk/patterns/check-answers/">check answers</a> screen, it may be difficult to present the questions and answers. Do you leave out the original branching question? If yes, would users know how to change their answer from ‘Yes’ to ‘No’?</p>
<p>None of these issues arise when using a separate page. This is why I’d <a href="https://www.gov.uk/service-manual/design/form-structure#start-with-one-thing-per-page">start with one thing per page</a> and only merge pages together when research shows that it works better that way for a diverse range of users.</p>
<p><em>Thanks to <a href="https://twitter.com/mrstevenproctor">Steven Proctor</a> and <a href="https://twitter.com/Amy_Hupe">Amy Hupe</a>.</em></p>
Form design: when to use the number input2019-01-05T00:00:00+00:00https://adamsilver.io/blog/form-design-when-to-use-the-number-input/<p><em>This is an excerpt from <a href="https://www.smashingmagazine.com/printed-books/form-design-patterns/">Form Design Patterns</a>. We’re in the middle of chapter 2, A Checkout Form, where we’ve been looking at the payment details form consisting of card number, expiry, security code from fields etc.</em></p>
<p>The number input (<code><input type="number"></code>) lets mobile users more quickly type a number via a numeric keypad. On desktop, the input will contain increment and decrement buttons called spinners, which make it easy to make small adjustments without having to select and type.</p>
<p><em>(Note: spinner buttons are tiny and hard to use which I’ll address later. And <a href="https://twitter.com/PeteWilliams/status/1138012588866973696">scrolling can interfere with number inputs</a>.)</em></p>
<div class="image" style="max-width: 120px">
<figure><img src="https://adamsilver.io/assets/images/number/number-input.png" alt=""><figcaption>Number input with tiny spinner buttons inside</figcaption></figure>
</div>
<p>You might think the number input is appropriate for the card number, expiry date, and CVC number — after all, they all consist of numbers. But it’s more complicated than that. By looking at what the spec says, what browsers do, and what users want, we can more easily determine when the number input is appropriate or not.</p>
<p>Let’s start with some definitions. Wikipedia says that:</p>
<blockquote>
<p>“A number is a mathematical object used to count, measure, and label. […] numerals are often used for labels (as with telephone numbers), for ordering (as with serial numbers), and for codes (as with ISBNs).”</p>
</blockquote>
<p>Most of us think of numbers this way. We use them to count and measure, but equally we use them in dates and codes. However, the HTML specification only agrees in part with this definition. It says that:</p>
<blockquote>
<p>“The <code>type=number</code> state is not appropriate for input that happens to only consist of numbers but isn’t strictly speaking a number. […] When a spinbox interface is not appropriate, type=text is probably the right choice (possibly with a pattern attribute).”</p>
</blockquote>
<p>In other words, numbers and numerals are different. Numbers represent an amount of something such as:</p>
<ul>
<li>my age announced “thirty-four years old”</li>
<li>the price of an apple announced “forty-five pence”</li>
<li>the time it took me to cook breakfast announced “ten minutes”</li>
</ul>
<p>Conversely, numerals might be used for dates and codes such as:</p>
<ul>
<li>birth date announced “nineteenth of June, nineteen eighty-three”</li>
<li>pin code announced “eight, double five, three, two, six”</li>
</ul>
<p>There’s a difference between the way these values are announced. Understanding this helps us see that while the way browsers implement the number input may seem buggy at first — it isn’t.</p>
<p>For example, IE11 and Chrome will ignore non-numeric input such as a letter (not including <kbd>e</kbd> which is valid) or a slash. Some older versions of iOS will automatically convert “1000” to “1,000.” Safari 6 strips out leading zeros. Each example seems undesirable, but none of them stop users from entering true numbers.</p>
<p>Some numbers need a decimal point such as a price; negative numbers need a minus symbol. Unfortunately, some browsers don’t provide buttons for these symbols on the keypad. If that wasn’t enough, some desktop versions of Firefox will round up huge numbers.</p>
<p>In these cases, it’s safer to use a regular text box to avoid excluding users unnecessarily. Remember, users are still able to type numbers this way — it’s just that the buttons on the keypad are smaller. To further soften the blow, the numeric keyboard can be triggered for iOS users by using the pattern attribute.</p>
<pre><code><input type="text" pattern="[0-9]*">
</code></pre>
<p>In short, only use a number input if:</p>
<ul>
<li>incrementing and decrementing makes sense</li>
<li>the number doesn’t have a leading zero</li>
<li>the value doesn’t contain letters, slashes, minus signs, and decimal points.</li>
<li>the number isn’t very large</li>
</ul>
<p>Let’s apply these rules to the expiry date. Incrementing it doesn’t make sense, the number could start with a zero, and credit cards put a slash in the middle of the expiry date which users should be able to copy. Using a number input is not only inappropriate, but it creates a jarring experience as the user types a slash which would be ignored.</p>
<p>We’ll look at appropriate use cases of the number input in the next chapter.</p>
<h2>A note about the telephone input</h2>
<p>The telephone input (<code><input type="tel"></code>) is sometimes used as a makeshift number input because…and you’ll just have to get the book to continue reading 😉.</p>
Thinking differently about progressive enhancement2018-10-07T00:00:00+00:00https://adamsilver.io/blog/thinking-differently-about-progressive-enhancement/<p>Some people think progressive enhancement is more work and means designing for the least capable browser—at the cost of making better experiences for the latest browsers.</p>
<p>But progressive enhancement is often less work and lets us to create the best experience, using cutting-edge JavaScript without harming people who use older browsers.</p>
<h2>Starting with a problem</h2>
<p>Most interfaces contain text, images, links, videos and forms. None of this needs JavaScript, so we can avoid the complexity that JavaScript introduces.</p>
<p>To do this, we can server render <a href="https://adamsilver.io/blog/semantic-html-and-aria-explained/">semantic HTML</a>. This results in a fast, standards compliant, accessible experience in all browsers.</p>
<p>If you want, you can pick a nice templating library (I like Nunjucks) and a CSS preprocessor—these <a href="https://www.youtube.com/watch?v=jVq4G6KY56s">technological choices improve the developer experience without negatively impacting users</a>.</p>
<h2>Richer interfaces</h2>
<p>With server-rendered HTML covering the vast majority of things people need, lets look at ways to enhance the experience using JavaScript.</p>
<p>That could mean using <a href="https://medium.muz.li/design-technique-progressive-disclosure-1980def8dc97">progressive disclosure</a> to reveal content in menus, tabs and accordions.</p>
<p>Equally it could mean something more complex like letting users annotate a web page and having their comments shared with collaborators in real time—like Google Docs.</p>
<h2>Using JavaScript APIs</h2>
<p>Using JavaScript to do this stuff might sound difficult without a framework, but in reality there’s only a handful of methods you need to know:</p>
<ul>
<li>Find elements: <code>el.getElementById</code>, <code>el.querySelector[All]</code>, <code>el.getElementsByClassName</code></li>
<li>Change element attributes/properties: <code>el.setAttribute</code>, <code>el.getAttribute</code>, <code>el.classlist.*</code>, <code>el.propName =</code></li>
<li>Listen to events like click, drag, submit and viewport width changes: <code>el.addEventListener</code>, <code>window.matchMedia</code></li>
<li>Modify elements: <code>el.innerHTML</code>, <code>el.appendChild</code>, <code>el.removeChild</code>, <code>document.createElement</code></li>
<li>Make AJAX calls: <code>XMLHttpRequest</code></li>
<li>Native helpers: <code>Function.prototype.bind</code>, <code>Array.prototype.forEach</code>, <code>Array.prototype.map</code></li>
</ul>
<p>Some of these things work “everywhere”, like <code>el.innerHTML</code> and some of these things work in a few modern browsers like <code>window.matchMedia</code>.</p>
<p>But don’t worry about individual browsers. The <a href="https://adactio.com/journal/6692">web is a continuum</a> and so we can approach this the same way regardless of the browser or API.</p>
<h2>Feature detection</h2>
<p>Instead of thinking about browsers, we should focus on the methods the component needs to work.</p>
<p>To do this, we need to make sure these methods work. If they do, they can be used safely without the risk of breaking the experience in browsers that lack support. In other words, the component will <a href="https://adamsilver.io/blog/in-defence-of-graceful-degradation-and-where-progressive-enhancement-comes-in/">degrade gracefully</a>.</p>
<p>Let’s create a component that shows content when a button is clicked.</p>
<p>Firstly, we need to render HTML on the server which works for everyone.</p>
<pre><code><div class="stuff">
<div class="stuff-content">
<p>Stuff to show/hide</p>
</div>
</div>
</code></pre>
<p>Secondly, we need create and inject a button using JavaScript:</p>
<pre><code>// Create button
var button = document.createElement('button');
button.type = "button"
button.textContent = "Show content";
// Inject button
var container = document.querySelector('.stuff');
var content = document.querySelector('.stuff-content');
container.insertBefore(button, content);
</code></pre>
<p>Finally, we need to listen to the button’s click event so that the class name and button state are changed in order to reveal the content.</p>
<pre><code>button.addEventListener('click', function() {
if(content.classList.contains('hidden')) {
content.classList.remove('hidden');
button.textContent = "Hide content";
} else {
content.classList.add('hidden');
button.textContent = "Show content";
}
}, false);
</code></pre>
<p>This code works in browsers that support the methods. But if the user’s browser doesn’t support just one method, the component will break. So we need to feature detect <em>all</em> of them first.</p>
<p>To do this we should use the following functions described in <a href="http://peter.michaux.ca/articles/feature-detection-state-of-the-art-browser-scripting">Feature Detection: State of the Art Browser Scripting</a>:</p>
<pre><code>function isHostMethod() {
var objectMethod = object[method];
var type = typeof objectMethod;
return type == 'function' || type == 'object' && null !== objectMethod || type == 'unknown';
}
function isHostObjectProperty() {
var objectProperty = object[property];
return typeof objectProperty == 'object' || typeof objectProperty == 'function' && null !== objectProperty;
}
</code></pre>
<p>Once you have these, they can be used like this:</p>
<pre><code>if(isHostObjectProperty(document.body, 'textContent')
&& isHostMethod(document, 'createElement')
&& isHostMethod(document, 'querySelector')
&& isHostMethod(document.body, 'insertBefore')
&& isHostMethod(document.body, 'addEventListener')
&& isHostObjectProperty(document.body, 'classList')) {
// put the rest of the code inside here.
}
</code></pre>
<p>If a browser doesn’t support any of the APIs, the user always sees the content. The code doesn’t break for anyone. That’s a form of <a href="https://adamsilver.io/blog/11-things-to-consider-when-designing-for-everyone/">accessible design</a>.</p>
<h2>Libraries are useful</h2>
<p>What if we have lots of components in our application? And what if these components use the same APIs? Who wants to write the same, long-winded feature detection code over and over? Not me.</p>
<p>A collection of functions can help reduce the repetition. And a collection of functions is known as a library. With a library in place our code can look more like this:</p>
<pre><code>if(lib.hasFeatures( 'setText', 'querySelector', 'createElement', 'prependElement', 'addEventListener', 'addClass', 'hasClass', 'removeClass')) {
var button = lib.createElement('button', {
type: 'button', text: 'Show content'
});
var container = lib.querySelector('.stuff');
var content = lib.querySelector('.stuff-content');
lib.prependElement(button, content);
lib.addEventListener(button, 'click', function() {
if(lib.hasClass(content, 'hidden')) {
lib.removeClass(content, 'hidden');
lib.setText(button, 'Hide content');
} else {
lib.addClass(content, 'hidden');
lib.setText(button, 'Show content');
}
});
}
</code></pre>
<p>Read more about this approach in <a href="http://peter.michaux.ca/articles/cross-browser-widgets">Cross Browser Widgets</a>.</p>
<p>Even though it’s written in 2008 it’s perfectly applicable today which shows just how robust and future proof this technique is.</p>
<p>Such a library weighs in at just a few kilobytes. Cutting-edge, performant and accessible all at the same time. Nice.</p>
<p>And this really helps developers too.</p>
<p>Less checking caniuse.com. Less testing in multiple browsers. Less worrying about excluding users. Less worrying about using older technology. Less worry about wrangling with [insert popular framework here]. Less worrying about new browsers. <a href="https://adamsilver.io/blog/the-disadvantages-of-javascript-polyfills/">No more polyfills and their unavoidable caveats</a>. No more worrying about whether JavaScript is available or not.</p>
Content is the user experience and what the deuce is content design?2018-07-01T00:00:00+00:00https://adamsilver.io/blog/content-is-the-user-experience-and-what-the-deuce-is-content-design/<p>When I was making the final edits to <a href="https://formdesignpatterns.com/">Form Design Patterns</a>, I had to attribute this quote:</p>
<blockquote>
<p>“Content is the user experience”</p>
</blockquote>
<p>Caroline Jarrett told me it was Ginny Redish, the author of “Letting Go of the Words”. “Job done,” I thought but then my editor asked me for a reference.</p>
<p>So I asked Ginny and she said “I don’t think I have a reference for that exact phrase. However, it is the essence of much of my work. See, for example, page 1 of my book, Letting Go of the Words (2nd edition).”</p>
<p>She then asked me about my book, so I told her what it was about and she said “Do you consider forms a type of content? If so, I’m happy to have you attribute the concept that content is the user experience to me. […]. If, however, you consider “content” to be different from “forms,” I disagree. To my mind, forms are a very important type of content.”</p>
<p>I said “Yes, so forms are a conversation between the service/product/website and the user. The content (labels, hints, errors) is of vital importance so I reference your quote with regard to this.”</p>
<p>Ginny said “I’m not yet sure if we agree on defining content. If you are saying that only the words are content, not the entire form or the entire interactive process, I don’t agree. The entire form or process is content. The choice of what to ask, the order in which to ask it, how to divide it between web pages (for example, in a checkout process), the size of the fields, as well as the words you use — all that is content.”</p>
<p>Ginny’s message really got me thinking. Here’s a slightly edited version of what I said:</p>
<blockquote>
<p>“I’ve never really thought of content in the way that you describe but I do think the things you mentioned are vital in designing an experience that communicates to the user clearly. I’ve actually written about all of them in the book.”<br>
<br><br>“You seem to be saying that everything on an interface (including say whitespace) is content. Is that right?”<br>
<br><br>“Some content designers I’ve worked with focus mostly on the words. Others help design the flow, order, and other interface details such as size or type of field. These are my favourite content designers.”<br>
<br><br>“If everything is content, then it seems to me that content is almost a synonym for UX/design, which is actually where this conversation stemmed from.”<br>
<br><br>“If content designers design everything on the interface, would you say interaction designers are redundant?”<br>
<br><br>“Thinking more about this, I’m asking questions as if these roles are separate but of course they’re not…”<br>
<br><br>“When I design an interface, I very much think about and care about the words, but a content designer helps me make them much better. The best content designers help me make everything better, not just words.”<br>
<br><br>”I might also help make the words better, and more consistent with the service.”<br>
<br><br>“Still, I’m very interested in how you think about this.”<br>
<br><br>“Like you say in your book: people come for the content; they don’t come to admire the design.”<br>
<br><br>“But the design helps them consume the content right?”<br>
<br><br>“So users don’t come for the small text box that gives users a clue they need to enter something small (like a postcode). That just helps users complete the task or find out what they need.”<br>
<br><br>“I don’t think there’s a right and wrong way to think about this. I’m not aware of a universally agreed upon definition of content design.”</p>
</blockquote>
<p>(The conversation continues.)</p>
<p>So what is content design?<br>
If everything on a screen is content, are content designers responsible for everything?</p>
<p>Certainly, I would consider text, images and video as content. I also think working out how to display text (for example) as paragraphs, headings, lists and tables is most certainly content design but it’s also interaction design.</p>
<p>And, I also think flow and order comes into the realm of content design because its impact on understanding content may produce a confusing experience.</p>
<p>But the choice to split things up across pages or to make a form field smaller in width feels more like interaction design. But it’s definitely not a clear cut thing. It’s the boundaries of responsibility that are hard to define.</p>
<p>When I design an interface, I first like to understand what I’m trying to communicate. There are parts of Form Design Patterns that go into detail about how to present certain information. For example, when designing an inbox, should we present the list of emails as a <code><ul></code> or a <code><table></code> or something else?</p>
<p>Most of the time I’d say content drives design. But on some occasions design influences the content, this is applicable to form validation because how and where errors need to go, drives the content needed to make the errors clear.</p>
<p>Tangent aside—what is content design? I don’t know—it definitely has a grounding in the words and information on screen. But content designers can most definitely influence the rest of the experience.</p>
<h2>Is content really the user experience?</h2>
<p>So this whole thing started because I wanted to use the quote from this poster:</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/contentisux/poster.png" alt=""><figcaption>Poster saying “Content is the user experience”</figcaption></figure>
</div>
<p>Some people question this:</p>
<blockquote>
<p>“[…] isn’t interaction design, server performance, etc the user experience too?” — Joe Lanman</p>
</blockquote>
<blockquote>
<p>“Yeah, I agree with @joelanman - we say user experience is everybodies job. As a designer I can’t ever make it a good experience if the technology stack puts a 4 second lag in between every interaction.” — Craig Abbott</p>
</blockquote>
<p>Others seem more in favour:</p>
<blockquote>
<p>“I might be wrong, but I think the original intention of this quote was to say ‘don’t treat content as supplementary to the user experience”— Amy Hupe</p>
</blockquote>
<blockquote>
<p>“I don’t think it’s saying anything else isn’t user experience design, more that consuming content is the main experience OF the user.” — Dave House</p>
</blockquote>
<p>Despite the differing opinions, I agree with them all.</p>
<p>Content is not the only part of user experience. Everything and everyone is responsible for that. But because content, in my experience, is often seen as “just add the words later”, this poster is really important. It’s over the top, so that it draws people’s attention and makes them stop and think.</p>
<p>I instantly loved the poster the first time I saw it. Content is more important than anything else, because even if you had the most amazing, performant design but the content was rubbish it wouldn’t matter.</p>
<p>But good content, with a slow connection speed, at least is worth the wait (should someone have the patience).</p>
<p>So yes content is the user experience, but content is not the entirety of it.</p>
<p>Are interaction designers redundant?<br>
This is a bit of a rhetorical question because I don’t think for one minute Ginny thinks interaction designers are redundant, but it’s a fun and challenging exercise working out who does what.</p>
<p>But if everything is content, then I do wonder what officially an interaction designer’s remit is. I don’t really like job titles—they pigeon hole a person’s responsibilities, opinions and expertise.</p>
<p>A good team is made up of diverse people with diverse skill sets working on the same problem. That means you define the problem together. You prototype the MVP together. You iterate together. And all this happens taking into account everyone’s skills and viewpoints together.</p>
<p>In many ways, a designer’s role is to facilitate good design through collaboration. And I’ve worked on things before whereby it was the content designer who came up with a completely different and better design. This, I think, was made possible through collaboration.</p>
<p>So I don’t think content designers are solely responsible for content. Nor do I think interaction designers are ambivalent to content. It’s the whole UX thing again isn’t it.</p>
<p>In my confusion, I thought I’d ask Amy Hupe. She’s a brilliant content designer at GDS. Here’s just some of the great things she said to me on the subject:</p>
<blockquote>
<p>“I think good content and interaction designers have a good understanding and appreciation for the other’s discipline. They’ll work together to combine their strengths, and learn from each other.”<br>
<br><br>“Really good content and interaction designers will understand that their output is part of an ecosystem and is so intrinsically linked with the other parts of that ecosystem that they will necessarily consider and effect them when working.”<br>
<br><br>“Can a user achieve their goal using only words? Probably. Does interaction design make it faster, simpler and more reassuring for them to do so? 100%”<br>
<br><br>“Words are important - they might be the most fundamental thing - but the user experience would be weak, frustrating and slow without interaction design.”<br>
<br><br>“And I wouldn’t be able to do my job half as well if it wasn’t for the team of interaction designers I work with.”<br>
<br><br>“I think content design will always be coming at things from a words-first perspective. Not all content designers can, or want to, handle other elements.”</p>
</blockquote>
<p>Amy nailed it. But it still doesn’t make the boundaries of responsibility clearer, but that’s the point.</p>
<p>Remove the boundaries.</p>
Buttons shouldn't have a hand cursor part 22018-04-14T00:00:00+00:00https://adamsilver.io/blog/buttons-shouldnt-have-a-hand-cursor-part-2/<p>In <a href="https://adamsilver.io/blog/buttons-shouldnt-have-a-hand-cursor/">Buttons shouldn’t have a hand cursor</a> I explained that the hand (or pointer) cursor doesn’t mean clickable and that it’s meant to signify a link.</p>
<p>However, there were some important things I didn’t address: why did we start using the pointer cursor in the first place? Are conventions on the Web different to the OS? Have things changed? How does all of this affect users?</p>
<h2>The history of the pointer cursor</h2>
<p>In response to part one, <a href="https://medium.com/@TheBespokePixel">Mark Griffiths</a> explained the history behind the pointer cursor.</p>
<p>It first appeared in Apple’s HyperCard in 1987. It was used to signify things you can click. When the Internet came along, Mosaic used the pointer cursor just for links.</p>
<p>That’s the first time the convention changed as far as I know.</p>
<p>Some people think the convention has (or should be) changed back to its original meaning. In the context of HyperCard, the pointer cursor really did mean clickable. If you clicked anywhere that didn’t have the pointer cursor, nothing happened.</p>
<p>This is not the case with web pages. As I explained in the first part, pretty much everything is clickable: text, whitespace, images, form controls, buttons, and links. If the pointer does mean clickable, then the cursor should always be a pointer, rendering its meaning useless.</p>
<p>With the history somewhat laid out, why then, did we (designers, developers but not browsers!) start using the pointer for buttons? And was there a user need?</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/buttons2/mosaic.png" alt=""><figcaption>Mosaic's buttons (both in-page and part of the shell) look the same and have strong perceived affordance.</figcaption></figure>
</div>
<p>Notice how all the browser buttons are styled exactly the same as the search button within the page. Also notice how buttons and links look very different. None of these buttons have the pointer.</p>
<p>They didn’t need it. They had strong perceived affordance. <a href="https://www.nngroup.com/articles/clickable-elements">They looked like buttons</a>. They look like they can be pushed. And to top it of, they use the same styles as the OS, making them <a href="https://developer.paciellogroup.com/blog/2017/08/inclusive-design-principle-be-consistent/">consistent</a>.</p>
<p>Links, however, were signified by being blue and underlined. In those days, underlines were an alternative way to highlight words (like bold and italic). But, when the web came along that meaning changed.</p>
<p>Links were new and special — but they had weak affordance. Because of this they were given the pointer cursor, to give users an extra clue that this wasn’t just highlighted text. This was interactive, hyper text!</p>
<p>That’s why the original convention changed and browser vendors standardised it accordingly.</p>
<h2>Enabling style changes</h2>
<p>Today, the default styling for buttons still matches the OS. But now, browsers let you override the default styling with CSS. In the old days, we didn’t style them because we couldn’t style them.</p>
<div class="image" style="max-width: 100px">
<figure><img src="https://adamsilver.io/assets/images/buttons2/button.png" alt=""><figcaption>Mac default button style</figcaption></figure>
</div>
<p>Back then the way to give buttons an “on brand” style was to use <code><input type="image"></code> setting the <code>src</code> to an image URL. And for links (or calls to action), we’d be able to achieve the same thing by nesting an <code><img></code> inside a link.</p>
<p>So links and buttons started to look (but not behave) the same. Around this time, we noticed that some buttons had the default cursor and some links, styled as buttons, had the pointer. Inevitably, we normalised the cursor too.</p>
<p>Other sites started doing the same thing. Boom, another change of convention. This one, however, blurred the lines between links and buttons. And now we (or perhaps just me) have a bit of a debate going on.</p>
<p>The first mistake was that we took consistency too far by <a href="https://adamsilver.io/blog/but-sometimes-buttons-look-like-links/">making links and buttons look the same</a>. The second mistake was that we took away the one remaining signifier that tells users that they’re different.</p>
<p>The final and most important mistake was that none of this seemed to be driven by user needs.</p>
<h2>More than buttons</h2>
<p>Years ago, I was creating a form (my favourite thing to do by the way). I noticed that clicking a label would set focus to the text box. I wondered (as a designer, not a user!) why it didn’t have the pointer.</p>
<p>I reasoned that the pointer meant clickable. So I “fixed” it with CSS. No research, no usability testing—I didn’t read the specification—I just changed it because that’s what I thought I should do.</p>
<p>Not only did I not understand what the pointer cursor was for, but I changed the design without even knowing if it benefited users.</p>
<p>Even if I had ran tests, and those tests showed that these particular users found it useful, wouldn’t I also need to test that it doesn’t take away the perceived affordance of a link?</p>
<p>I can’t speak for everyone, but I’ve never seen nor heard users struggle to use a well-designed button that didn’t have the pointer cursor (and that’s considering the prevalent inconsistency and blurring of the lines).</p>
<p>And by well-designed, I mean a button that looks like a button and has a clear hover state. If you’re going to expect users to click a button that doesn’t look like one, then that’s another story altogether.</p>
<p>Now, if you asked a user what the pointer cursor means, they might well say that it means clickable. But <a href="https://alistapart.com/article/what-the-failure-of-new-coke-can-teach-us-about-user-research-and-design">what users say and what they do are different things</a>.</p>
<h2>“But Microsoft and Apple use the pointer cursor for buttons”</h2>
<p>That’s right, they don’t always follow their own standards and guidance. But is this a reason? I’ve worked in many teams that don’t follow their own standards due to a myriad of reasons. Maybe they forgot, or maybe they weren’t aware the standards existed.</p>
<p>Often the people who defined the standards aren’t always responsible for what’s produced in the end.</p>
<p>Just because someone wrote a thing, doesn’t mean people will listen. All it takes is a lack of attention, a lack of understanding. Designers and developers often do what they want, without research. As noted above, I did this myself.</p>
<p>Sometimes the mistake is by accident. Maybe the developer uses a third-party CSS framework. Maybe it sets the cursor incorrectly for buttons. And that’s all it takes.</p>
<h2>“But the web is different”</h2>
<p>Some say that the web is different. The web has its own set of conventions. But to most people—people that aren’t us—the web is not a distinct thing. It’s a thing people use on their computer and their phone.</p>
<blockquote>
<p>“There’s no distinction between what’s a browser, what’s a website, what’s an operating system” — <a href="https://www.youtube.com/watch?v=sELOUAmFHjA&feature=youtu.be&t=3m4s">Jakob Nielsen, Mobile Usability Futures</a></p>
</blockquote>
<p>If the lines weren’t already blurred, many apps are just shells around web apps. And with form fields being heavily integrated with the OS, it’s hard for users to tell where the OS/browser ends and the web begins.</p>
<h2>Should buttons and links look different?</h2>
<p>If buttons and links should look the same, shouldn’t they be the same? Shouldn’t they do the same thing? If they don’t behave the same way, surely they shouldn’t look the same.</p>
<p>If we agree that buttons and links are different, and we agree that (some) users will find value in knowing that difference, why would we try and normalise them by taking away the one (albeit subtle) signifier that differentiates them?</p>
<blockquote>
<p>“It’s better to make things visually apparent, rather than hoping people will discover them [by moving their mouse or tapping around the interface]” — <a href="https://www.youtube.com/watch?v=sELOUAmFHjA&feature=youtu.be&t=45m17s">Jakob Nielsen, Mobile Usability Future</a></p>
</blockquote>
<p>Presumably browser vendors would remove all the special behaviour tied to links if people weren’t right clicking on them (to open a context menu) and doing various things with them.</p>
<p>Sometimes links look like buttons for prominence but I’m not sure that’s a reason to normalise the cursor. It’s reason to create a design language that differentiates buttons from links. That’s the challenge.</p>
<h2>Does the pointer cursor on buttons stop users from achieving their goal?</h2>
<p><a href="https://twitter.com/jmspool/status/913003208792035328">Jared Spool asked this question on Twitter</a>, but I wasn’t sure it was the right question.</p>
<p>If we’re going against standards, then it seems more appropriate to ask: does the pointer cursor on (well-designed) buttons help the user achieve their goal?</p>
<p>I don’t believe so no. I’ve never seen a user stop and say “I’m not pressing the button because it doesn’t have a pointer.” Of course, on mobile devices, there’s no cursor available.</p>
<p>I also setup a little test (hardly definitive admittedly) with friends and family to see if users hesitated (or something) due to there being no pointer cursor, but everyone managed to get through the flow just fine.</p>
<h2>Summary</h2>
<p>If users need to know that a thing does something and that’s demonstrable in user research even with clear, well-designed buttons, then this would indicate we need a change of convention. And in that case, maybe we need a new cursor—not the same one as we use for links.</p>
<p>But let’s not say that the pointer means clickable. Everything means clickable including this “text select” cursor. It’s just that buttons and links, on the surface at least, appear to do similar things.</p>
<p>Is this over? I’ll end with a quote from Don Norman’s book, “The design of everyday things”:</p>
<blockquote>
<p>“Standards simplify life for everyone. At the same time, they tend to hinder future development. There are often political struggles in finding common agreement. Nonetheless, when all else fails, standards are the way to proceed.”</p>
</blockquote>
Progressive enhancement explained simply2018-04-01T09:00:01+00:00https://adamsilver.io/blog/progressive-enhancement-explained-simply/<p><em>This is an excerpt from <a href="https://www.smashingmagazine.com/printed-books/form-design-patterns/">Form Design Patterns</a>.</em></p>
<p>Progressive enhancement is about users. It just happens to make our lives as designers and developers easier too. Instead of keeping up with a set of browsers and devices (which is impossible!) we can just focus on features.</p>
<p>First and foremost, progressive enhancement is about always giving users a reasonable experience, no matter their browser, device, or quality of connection. When things go wrong – and they will – users won’t suffer in that they can still get things done.</p>
<p>There are a lot of ways an experience can go wrong. Perhaps the style sheet or script fails to load. Maybe everything loads, but the user’s browser doesn’t recognize some HTML, CSS, or JavaScript. Whatever happens, using progressive enhancement when designing experiences stops users having an especially bad time.</p>
<p>It starts with HTML for structure and content. If CSS or JavaScript don’t load, it’s fine because the content is there.</p>
<p>If everything loads OK, perhaps various HTML elements aren’t recognized. For example, some browsers don’t understand <code><input type="email"></code>. That’s fine, though, because users will get a text box (<code><input type="text"></code>) instead. Users can still enter an email address; they just don’t get an email-specific keyboard on mobile.</p>
<p>Maybe the browser doesn’t understand some fancy CSS, and it will just ignore it. In most cases, this isn’t a problem. Let’s say you have a button with <code>border-radius: 10px</code>. Browsers that don’t recognize this rule will show a button with angled corners. Arguably, the button’s perceived affordance is reduced, but users are left unharmed. In other cases it might be helpful to use feature queries.</p>
<p>Then there is JavaScript, which is more complicated. When the browser tries to parse methods it doesn’t recognize, it will throw a hissy fit. This can cause your other (valid and supported) scripts to fail. If your script doesn’t first check <a href="https://adamsilver.io/blog/progressively-enhanced-javascript/">that the methods exist (feature detection) and work (feature testing)</a> before using them, then users may get a broken interface. For example, if a button’s click handler calls a method that’s not recognized, the button won’t work. That’s bad.</p>
<p>That’s how you enhance. But what’s better is not needing an enhancement at all. HTML with a little CSS can give users an excellent experience. It’s the <a href="https://adamsilver.io/blog/content-is-the-user-experience-and-what-the-deuce-is-content-design/">content that counts</a> and you don’t need JavaScript for that. The more you can rely on content (HTML) and style (CSS), the better. I can’t emphasize this enough: so often, <a href="https://adamsilver.io/blog/4-steps-to-design-fast-experiences/">the basic experience is the best and most performant one</a>. There’s no point in enhancing something if it doesn’t <a href="http://inclusivedesignprinciples.org/#add-value">add value</a>.</p>
<p>Of course, there are times when the basic experience isn’t as good as it could be – that’s when it’s time to enhance. But if we follow the approach above, when a piece of CSS or JavaScript isn’t recognized or executed, things will still work.</p>
<p>Progressive enhancement makes us think about what happens when things fail. It allows us to build experiences with resilience baked in. But equally, it makes us think about whether an enhancement is needed at all; and if it is, how best to go about it.</p>
But sometimes buttons look like links2017-10-16T09:00:01+00:00https://adamsilver.io/blog/but-sometimes-buttons-look-like-links/<p>Sometimes links are made to look like buttons. Sometimes buttons are made to look like links.</p>
<p>This can be problematic but maybe there’s something we can do about it.</p>
<p>But before we get to it, let’s discuss the 4 different types of buttons and links.</p>
<h2>1. Submit buttons</h2>
<p>Submit buttons are used to submit forms like signing in, creating an account or adding a product to basket.</p>
<div class="image" style="max-width: 340px">
<figure><img src="https://adamsilver.io/assets/images/buttonslinks/01-submit.png" alt=""><figcaption>“Sign in” is a submit button</figcaption></figure>
</div>
<h2>2. Links</h2>
<p>Links are used for navigating to a (location within a) page.</p>
<p>They’re usually underlined so they can be distinguishd from regular text.</p>
<p>Or sometimes they are part of a menu and distinguished by their location like within a header.</p>
<div class="image" style="max-width: 340px">
<figure><img src="https://adamsilver.io/assets/images/buttonslinks/02-link.png" alt=""><figcaption>Links are underlined to stand out against copy</figcaption></figure>
</div>
<h2>3. Buttons</h2>
<p>Buttons (<button <code>type="button"></code>) are used for Javascript behaviour like revealing a menu or slide of a carousel.</p>
<div class="image" style="max-width: 340px">
<figure><img src="https://adamsilver.io/assets/images/buttonslinks/03-button.png" alt=""><figcaption>Clicking the person icon reveals a menun</figcaption></figure>
</div>
<h2>4. Calls to action</h2>
<p>Calls to action are actually links that look like buttons in order to make them prominent.</p>
<div class="image" style="max-width: 340px">
<figure><img src="https://adamsilver.io/assets/images/buttonslinks/04-cta.png" alt=""><figcaption>“Checkout” is a link styled to call users to action</figcaption></figure>
</div>
<h2>What’s the problem?</h2>
<p>In <a href="https://resilientwebdesign.com/">Resilient Web Design</a> Jeremy Keith talks about ‘material honesty’.</p>
<p>He says that “one material should not be used as a substitute for another, otherwise the end result is deceptive”.</p>
<p>Making a link look like a button is materially dishonest. It tells users that links and buttons are the same when they’re not.</p>
<p>In <a href="https://medium.com/eightshapes-llc/buttons-in-design-systems-eac3acf7e23">Buttons In Design Systems</a> Nathan Curtis says links should be distinguished from buttons because “button behaviours bring a whole host of distinct considerations from your simple anchor tag”.</p>
<p>For example, a link can be opened in a new tab, or copied or bookmarked for later. Buttons don’t share this behaviour.</p>
<p>Calls to action—which again, are just links—are deceptive. Their styling stops users from knowing they’re links and therefore obscures their function.</p>
<p>We could make calls to action look like regular links. But this makes them visually weak and hard to spot. That’s the problem.</p>
<p>And sometimes links and buttons appear next to each other as part of the same menu.</p>
<p>Kidly’s account menu button shown earlier is next to a basket link. You wouldn’t know it though because both are styled the same way with iconography.</p>
<p>Here’s another similar example: all 3 items in the menu look like links when ‘Choose day’ is a button that opens a calendar.</p>
<div class="image" style="max-width: 340px">
<figure><img src="https://adamsilver.io/assets/images/buttonslinks/05-menu.png" alt=""><figcaption>“Previous day” and “Next day” are links. “Choose day” is a button styled as a link.</figcaption></figure>
</div>
<p>But it looks like it goes to another page just like ‘Previous day’ and ‘Next day’ do. And that means users should expect to be able to open these items in a new tab etc.</p>
<p>Maybe ‘Choose day’ should open in a new page and that would solve the problem? But then again that might not be the best experience.</p>
<p>In any case, the reason all 3 items are styled the same is because consistency is a quality of good design.</p>
<p>But here the differences are indistinguishable because there are no relevant signifiers. this makes the UI a little deceptive.</p>
<p>Consistency is not about making different things the same. It’s about making the same things the same.</p>
<h2>Differentiating calls to action</h2>
<p>If you’ve been nodding in agreement so far, then you’ll probably agree that calls to action need to stand out, but they also need to look different to buttons to signify their true behaviour of a link.</p>
<p>Here’s the GOV.UK ‘start button’:</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/buttonslinks/06-start.png" alt=""><figcaption>“Start now” is a link styled prominently to call users to action</figcaption></figure>
</div>
<p>It stands out but looks different to a submit button. The start button is slightly bigger and has an arrow. The arrow may suggest the user is going to be taken to a new flow.</p>
<p>There’s a difference, but it’s pretty subtle and may be lost on users (more on this shortly).</p>
<p>Firstly, <a href="https://adamsilver.io/blog/buttons-shouldnt-have-a-hand-cursor/">submit buttons shouldn’t have a hand cursor</a>. This cursor helps people who use a pointing device provide an additional clue it’s a link.</p>
<p>Secondly, <a href="https://beta.nhs.uk/service-manual/styles-components-patterns/action-link">calls to action need to be less button-y and more link-y</a>.</p>
<p>This isn’t easy but I think we can use a combination of whitepsace, size, iconography to make them stand out. And maybe an underline.</p>
<p>It’s may help to remove as much content from the page as possible. The less there is the less it gets in the way of the call to action.</p>
<p>And if you can give users just one call to action that reduces choice and again helps that one thing stand out.</p>
<p>Granted it’s not always possible but we can try.</p>
<h2>Differentiating buttons and links that are part of the same menu</h2>
<p>The problem here is that we want the items to be equally weighted without removing the signifiers that help users differentiate them.</p>
<p>In other words buttons naturally overpower links.</p>
<p>Kidly’s menu, for example, looks consistent and equally weighted due to the use of iconography. But any meaning (subtle or otherwise) is lost.</p>
<p>With the schedule page ‘Choose day’ is not more or less important than ‘Previous day’ or ‘Next day’. Perhaps we need to make ‘Choose day’ look less link-y and more button-y without overpowering the links?</p>
<p>Locating them in the same place is a no brainer. Perhaps we can use whitespace and a separator. Maybe we just need a smaller button. But the button shouldn’t have an underline as that’s reserved for links.</p>
<h2>Do users care?</h2>
<p>Because we have made links look like buttons – and because we have exacerbated the problem by incorrectly using the hand cursor — some users may have acclimatised and the lines have blurred.</p>
<p>Perhaps, if users knew they could open a call to action in a new tab, they would? I certainly might.</p>
<p>Maybe others wouldn’t. But does that matter? <a href="https://inclusivedesignprinciples.org/#offer-choice">Choice</a> is a principle of inclusive design.</p>
<p>Same goes for labels. Many sites don’t connect labels to radio buttons. Due to this people don’t trust that clicking the label (which is often easier) will select the radio button.</p>
<p>If most sites got it right, users may start to use this and benefit.</p>
<p>Users shape design and design shapes users. If the majority of sites differentiated buttons from links, users might care and find value in the functionality that has been made more obvious.</p>
<p>In isolation we might think of this as a small problem. But when combined with other small problems it can noticeably degrade the user experience.</p>
<p>When we talk about getting the small details right, this is the sort of thing that comes to mind.</p>
<h2>It’s the journey, not the destination.</h2>
<p>Others say it’s a grey area because forms and links can both take users to another page.</p>
<p>While true the journey is not the same as the destination.</p>
<p>My TV and the remote control have power buttons. The one on the remote is rubbery, small, red and located in the top right corner. And there’s lots of other buttons in close proximity.</p>
<p>The one on the TV is solid, much bigger and concealed.</p>
<p>It would be odd if the designs were reversed or made ‘consistent’ by ignoring the context in which they are used.</p>
<p>Forms and links may take users to the same place. But just because the destination is the same, the journey (or interaction) is different.</p>
<p>Pretending they are the same and removing any signifiers isn’t useful.</p>
<p>Semantics are there for a reason and it’s a designer’s job to make them obvious.</p>
<h2>Summary</h2>
<p>Design is about solving problems.</p>
<p>While this may not be the biggest problem in the world, I do think there’s something we can do about it.</p>
<p>Links and buttons are a fundamental part of the web. Getting them right can only be a good thing.</p>
<p>In isolation this may not seem like a big deal, but in combination with other small details it could make a difference.</p>
4 steps to design fast experiences2017-07-28T09:00:01+00:00https://adamsilver.io/blog/4-steps-to-design-fast-experiences/<p>This is how it goes. We put a load of shit into a single web page. This makes the page slow. Slow to load, slow to render. Slow.</p>
<p>Instead of getting rid of the shit, we blame the page refresh. There’s only one way to avoid the page refresh and that’s AJAX.</p>
<p>However, AJAX still needs to render new (parts of) screens. More crucially, it still makes a request to the server. That’s not all—there are penalties in using AJAX and it frequently results in slow experiences—not faster ones.</p>
<p>Firstly, making requests; handling different responses; traversing document trees; and injecting HTML requires <em>more</em> code to be sent initally. And then the code needs to be evaluated and executed.</p>
<p>Secondly, AJAX engineers away progressive rendering—which browsers provide natively for free. To reinstate this functionality we resort to <a href="https://jakearchibald.com/2016/fun-hacks-faster-content/">hacks</a> which is more code. In reality nobody uses the hack anyway.</p>
<p>Thirdly, using AJAX means we forgo the browsers familiar, accurate and consistent loading indicator. With AJAX, we need to design and build a custom one. Not only is this more work and code, but they are usually an inferior replacement for those provided by browsers.</p>
<p>AJAX is not bad per se. It can be useful in some circumstances as it avoids requesting the same assets repeatedly and may well render faster if it’s a small update to the page like adding products to basket perhaps. But it’s not a solution to heavy, slow-loading pages.</p>
<p>The real problem is that we’ve designed something that can never be fast. So the question should be how do we design for performance?</p>
<h2>1. Simplify the interface</h2>
<p>The best way to make pages fast, is to have less stuff on them. I’ll forgive you for wanting to punch me in the face as this is obvious. And yet <a href="https://www.keycdn.com/support/the-growth-of-web-page-size/">web pages keep getting bigger</a>.</p>
<p>Do we need background videos, modal dialogs and social media buttons plastered everywhere? The answer from the people is a no. The fastest feature is one we never build.</p>
<p>What about hamburger menus, tabs, carousels, accordions, image galleries and expanding panels. All these things have one thing in common. They hide stuff but <a href="https://adamsilver.io/blog/user-interfaces-hiding-content-should-be-a-last-resort/">hiding stuff should be a last resort</a>.</p>
<p>We’re obsessed with saving space and making a clean interface. A clean interface is good but not at the cost of clarity. If pages only contain the essential, then there should be little and maybe even nothing to hide.</p>
<p>Effort aside, designing fully responsive and accessible components results in more code that users rarely appreciate. After all, it slows down the page and requires the user to exert energy to reveal the hidden content.</p>
<p>Heydon Pickering coined the seemingly satirical term ‘unprogressive non-enhancement’. He says:</p>
<blockquote>
<p>You take some structured content, which follows the vertical flow of the document in a way that everyone understands.<br><br>
Which people traverse easily by either dragging their scroll bar with their mouse, or operating the keyboard using the up and down keys, or using the spacebar.<br><br>
Or if they’re using a touch device, simply flicking backwards and forwards in that easy way that we’ve all become used to. What you do is you take that, and you fucking well leave it alone.</p>
</blockquote>
<p>Letting things stack naturally is good. Not only does this embrace the way the web works—it makes for a remarkably simple and fast experience with less effort.</p>
<p>A fast experience is a cornerstone of accessible design because some people don’t have fast connections and this shouldn’t cause exclusion.</p>
<p>But we can do more than just not hiding stuff. We can chunk stuff across pages. Once pages have less on them the page refresh ‘problem’ is no longer a problem. Pages are fast by design. Sometimes to the point where the <a href="http://uncrate.com/">page refresh is unnoticeable</a>.</p>
<p>Long, complex forms (or even shortish ones) should follow <a href="https://www.smashingmagazine.com/2017/05/better-form-design-one-thing-per-page/">one thing per page</a>.</p>
<p>But this approach isn’t just for forms. Product pages, for example, contain an image carousel, description, add to basket form, shipping information, related products, ratings and comments. We can split some of these things up.</p>
<p>Most users don’t read every single thing on a page on every visit. Instead give users a lightweight page and a clear information architecture that makes it easy to drill down. This is called information scent.</p>
<p>Give users one high-definition image without a carousel. Then let users show all which would take users to a page with all the images. No Javascript needed. Fast and accessible.</p>
<p>Using the natural building blocks of the web as a form of <a href="https://medium.muz.li/design-technique-progressive-disclosure-1980def8dc97?gi=361cf4735361">progressive disclosure</a> speeds things up drastically.</p>
<p>People on expensive data contracts benefit too. They can choose to see all the images by following the link or they can wait until they are connected to WI-FI.</p>
<p>Also, it’s easier to share content. Sending users to a page where most of the stuff is hidden is problematic.</p>
<p>Tabs: if stuff is hidden by default, how important is its existence on this page? Or if the tab contains a small amount of content just show it. Or consider putting it on a separate page.</p>
<p>If you’re feeling brave, put your site’s <a href="http://yaronschoen.com/table-of-contents/">navigation menu on a separate page</a> too. The page is light and loads quickly. Maybe this is too far. Maybe not.</p>
<p>Modal dialogs are often misused. All too often they contain too much content that would be better off as a new page. This improves performance and doesn’t break the back button like a dialog often does.</p>
<p>Less code, less problems and a faster, better experience. There’s a theme here. Scroll jacking, <a href="https://adamsilver.io/blog/the-problem-with-float-labels-and-what-to-do-instead/">floating labels</a>, <a href="http://adrianroselli.com/2016/12/dont-re-create-browser-features.html">font-size widgets</a>, <a href="http://usabilitygeek.com/ux-designers-ditch-sidebar-2016/">side bars</a>, custom select boxes—kill.</p>
<h2>2. Write less code</h2>
<p>By simplifying the interface we’ve already reduced the code by literally not writing any. But coding the remaining features leads to pillar number 2—write less code.</p>
<h3>Use lean and semantic HTML</h3>
<p>Sometimes developers use the wrong element. For example, a <code><button></code> is half the size of <code><div role="button" tabinidex="0"></code> and doesn’t require script to make it accessible again.</p>
<p><a href="https://csscreator.com/divitis">Divitus</a> is an antiquated buzzword that’s still prevalent today. We often use <a href="http://getbootstrap.com/components/#navbar-brand-image">additional elements unncessarily</a> which make payloads larger, and requests longer. We should be able to justify the existence of every element.</p>
<p>Similarly, classitus is the use of extra classes. Extra classes may decrease the size of CSS but they signifcantly increase the size of HTML.</p>
<p>Ensuring HTML is small is important. Unlike CSS, it can’t be easily cached. This is because HTML is likely to contain personalised and dynamic content which in turn encourages the <a href="https://adamsilver.io/blog/dont-use-ajax-for-personalised-content/">misuse of AJAX</a>.</p>
<p>Adding attributes for accessibility purposes could actually be <a href="https://silktide.com/i-thought-title-text-improved-accessibility-i-was-wrong/">completely unnecessary while also creating bloat</a>.</p>
<p>Similarly, the first rule of ARIA is not to use it. To associate errors to a form control we might use <code>aria-describedby</code>:</p>
<pre><code><label for="age">Age</label>
<div id="age_error">Enter your age</div>
<input id="age" aria-describedby="age_error">
</code></pre>
<p>Instead putting the error in the label is more performant <em>and</em> accessible:</p>
<pre><code><label for="age">
Age
<div>Enter your age</div>
</label>
<input id="age">
</code></pre>
<p>Using <a href="https://adamsilver.io/blog/dont-initialise-javascript-automagically/">HTML attributes to automagically initialise script</a> increases the size of the HTML and has other problems too.</p>
<p>Don’t add HTML hooks just for functional tests. Instead use, multipurpose, <a href="https://maintainablecss.com/chapters/semantics/">semantic hooks</a>.</p>
<h3>Simplify your design system</h3>
<p>GDS (Government Digital Services) design simple interfaces. Most components are left aligned and stack naturally. In this case we may be able to <a href="https://www.smashingmagazine.com/2016/11/css-inheritance-cascade-global-scope-new-old-worst-best-friends/">avoid CSS classes altogether</a> which further proves that a simple interface is a performant one.</p>
<h3>Use less script</h3>
<p><a href="http://openmymind.net/2012/5/30/Client-Side-vs-Server-Side-Rendering/">Single pages applications don’t necessarily render faster</a>. And they have a <a href="https://adamsilver.io/blog/the-problem-with-single-page-applications/">lot of downsides</a>. It takes a lot of code to create a robust client-side application, that typically causes people to employ large frameworks.</p>
<p>But maybe we don’t need the whole framework. That means users have to download a load of code they don’t need and we need to maintain stuff that we don’t need.</p>
<p><a href="http://www.heydonworks.com/article/look-at-this-shitty-tweet-button">Twitter’s sharing button script weighs 50k</a>. But we can do the same thing with 0 bytes by using a simple link.</p>
<h3>Use preprocessors responsibly</h3>
<p><a href="https://jaketrent.com/post/cons-css-preprocessors/#file-size-is-deceiving">Preprocessors are deceptive because they can generate large CSS</a>.</p>
<h3>Use content breakpoints</h3>
<p>Often a module may need just <a href="https://adamsilver.io/blog/stop-using-device-breakpoints/">one breakpoint or even no breakpoints</a>. Designing to a predefined set of breakpoints encourages the unnecessary tweaking of a design that results in more code.</p>
<h2>3. Images</h2>
<p>Not everyone has access to the <a href="https://www.smashingmagazine.com/2017/03/world-wide-web-not-wealthy-western-web-part-1/">world western web</a> on high-end devices. But if you can still justify sending users high resolution images:</p>
<ul>
<li><a href="https://www.sitepoint.com/gif-png-jpg-which-one-to-use/">use the right image</a></li>
<li><a href="https://imageoptim.com/mac">smush them</a></li>
<li><a href="https://blog.codinghorror.com/progressive-image-rendering/">use progressive rendering</a></li>
</ul>
<h2>4. Backend stuff</h2>
<p>Enable <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding#Chunked_encoding">chunking</a> and progressive rendering. Don’t engineer it away.</p>
<p>Use Command Query Responsibility Segregation (CQRS) to make database queries fast which is good when you have more reads than writes.</p>
<p>Use a Content Delivery Network (CDN) for your static resources. And cache HTML and AJAX responses too.</p>
<p>Cache assets with long expiry dates so that users don’t have to download assets again.</p>
<p>Place scripts at the bottom and use <code>async</code> and <code>defer</code> attributes. Async is good for completley independent scripts that can run later like analytics.</p>
<p>Use <a href="https://www.troyhunt.com/i-wanna-go-fast-https-massive-speed-advantage/">HTTPS over HTTP2</a> with Gzip compression. Gzip, by the way, works better with a well-designed and consistent design system—the more HTML is repeated the better the compression.</p>
<p>Use <a href="https://medium.com/reloading/preload-prefetch-and-priorities-in-chrome-776165961bbf">preload and prefetch</a> where appropriate. Addy Osmani says <em>preload resources you have high-confidence will be used in the current page. Prefetch resources likely to be used for future navigations across multiple navigation boundaries.</em></p>
<h2>Summary</h2>
<p>You know what’s better than perceived performance? Actual performance. Avoid techniques that merely provide a mirage of speed.</p>
<p>Instead, declutter and optimise the foundations of your design system which will result in less weight, less complexity, less distraction, less hassle and ultimately, less <a href="http://deathtobullshit.com/">bull shit</a>.</p>
<p>Together, these techniques produce fast and simple experiences that make users feel awesome.</p>
<!--
- https://alistapart.com/article/planning-for-performance
- https://boagworld.com/marketing/users-will-always-choose-the-easiest-option-so-if-we-want-a-competitive-advantage-we-must-focus-on-simplicity/
- who killed my battery.http://cdn.oreillystatic.com/en/assets/1/event/79/Who%20Killed%20My%20Battery_%20Analyzing%20Mobile%20Browser%20Energy%20Consumption%20Presentation.pdf
- https://ethanmarcotte.com/wrote/designed-lines/
-->
The problem with live validation and what to do instead2017-06-26T09:00:01+00:00https://adamsilver.io/blog/the-problem-with-live-validation-and-what-to-do-instead/<p>In 2009 I was given some new designs to implement for the forms on Argos.co.uk.</p>
<p>One requirement was to validate as the user answers each question.</p>
<p>But it wasn’t clear whether it was best to validate as the user types or as they leave the field.</p>
<p>In the end we went with the latter because otherwise, users would be shown errors before having a chance to answer the question.</p>
<p>Having been asked to implement live validation several times, I’ve collected 9 usability issues which I wanted to share with you today.</p>
<p>And I’ll also share 4 better ways of reducing error rates in forms without any complicated patterns.</p>
<h2>1. It can interrupt users before they have a chance to type their answer completely</h2>
<p>For fields that must be a certain number of characters, the first keystroke will constitute an error which interrupts users.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-live-validation-and-what-to-do-instead/typeform--too-early.gif" alt=""><figcaption>As soon as the user types, an error will be displayed before the user has answered the question</figcaption></figure>
</div>
<h2>2. It can distract users while they’re trying to answer the question</h2>
<p>Showing an error as the user tabs to the next field can cause users to be distracted by errors in the previous field.</p>
<p>When the user goes to fix the error, it’ll trigger an error in the field below.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-live-validation-and-what-to-do-instead/apple.gif" alt=""><figcaption>Blurring the field causes errors to show prematurely</figcaption></figure>
</div>
<p>Similarly, when a user opens their password manager, the blur event will fire causing an error to be shown prematurely.</p>
<h2>3. It can cause the page to judder</h2>
<p>As the input becomes invalid and valid, an error will appear and disappear state changes between valid and invalid, errors will appear and disappear respectively quickly.</p>
<p>This causes the page to jump which can be disorientating and cause users to make mistakes.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-live-validation-and-what-to-do-instead/04-judder.gif" alt=""><figcaption>The page judders as the field switches between invalid and valid</figcaption></figure>
</div>
<h2>4. It can’t be used with multi-input fields</h2>
<p>Fields that are made up of multiple inputs need to be validated as a whole.</p>
<p>For example, take a checkbox group that needs at least 1 to be checked. It would be premature to show an error when the user tabs over the first checkbox to focus on the second checkbox.</p>
<p>It would also be presumptious to validate after the user tabs past the last checkbox as they could be just exploring the options or tabbing back to a previous option.</p>
<p>The same issues apply to a date field consisting of day, month and year inputs.</p>
<p>An interface that relies on users doing things in a specific order is prone to error and takes control away unnecessarily.</p>
<p>We could validate these types of fields on submit, but this would be inconsistent with the way the other fields work.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-live-validation-and-what-to-do-instead/multi-input-fields.png" alt=""><figcaption>A checkbox group (left) and date field (right) can’t be validated as the user tabs between inputs</figcaption></figure>
</div>
<h2>5. It can mislead users into thinking that their answer is valid when it isn’t</h2>
<p>For example, account credentials can only be validated by the server. So if a user enters an email address in the correct format, an account may not exist for that email address.</p>
<p>Luke Wroblewski’s <a href="https://alistapart.com/article/inline-validation-in-web-forms/">research had similar findings</a>:</p>
<blockquote>
<p>Participants knew we had no way to know their correct name, so they knew that the green check mark didn’t mean “correct.” But they weren’t sure and that was the problem.</p>
</blockquote>
<h2>6. Different fields need to be validated at different times</h2>
<p>Some inputs can be validated as soon as the user types like typing a letter when only numbers are expected.</p>
<p>For other inputs, that would be too early so you would have to validate them after the user is finished which causes inconsistency.</p>
<h2>7. It’s tiresome to constantly switch between answering questions and fixing mistakes</h2>
<p>As errors are shown as users are answering, the user has to switch between 2 modes of operation repeatedly which is draining.</p>
<h2>8. It can create multiple screen reader announcements in quick succession</h2>
<p>Some screen reader users tab through the whole form to get a feel for what’s involved. But this would announce errors for each and every question which is tedious.</p>
<h2>9. Users may not notice the errors as they appear</h2>
<p>As many users don’t look at the screen as they type, users may not even notice the errors appearing.</p>
<h2>4 ways to stop users seeing errors without any downsides</h2>
<p>Instead of resorting to a complex validation pattern that causes more problems than it solves, instead you can:</p>
<ol>
<li>Make sure your questions are easy to understand so that users are more likely to not make mistakes</li>
<li>Start with <a href="https://www.smashingmagazine.com/2017/05/better-form-design-one-thing-per-page/">one thing per page</a> to reduce cognitive load</li>
<li>Allow users to make little mistakes like extra whitespace</li>
<li>Validate when the user submits to give users a chance to answer the question and proceed when they’re ready</li>
</ol>
<p>I’ve seen these approaches work time and time again in user research.</p>
The problem with float labels and what to do instead2017-05-24T09:00:01+00:00https://adamsilver.io/blog/the-problem-with-float-labels-and-what-to-do-instead/<p>Float labels are labels that start off inside the input. When the user starts typing, the label ‘floats’ up to make space for the answer.</p>
<p>Float labels were designed to address the problem with using <a href="https://adamsilver.io/blog/the-problem-with-placeholders-and-what-to-do-instead/">placeholder labels</a> – that the label disappears as soon as the user starts typing.</p>
<p>And while they’re certainly better than placeholder labels, they create several usability issues.</p>
<p>Here, I’ll run through them all and I’ll explain what to do instead.</p>
<h2>1. They’re small and hard to read</h2>
<p>Float labels have small text in order to make it fit inside the input. But that makes them hard to read.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-float-labels-and-what-to-do-instead/size.png" alt=""><figcaption>Float labels have small text which is hard to read</figcaption></figure>
</div>
<h2>2. They have poor contrast</h2>
<p>Float labels have poor contrast in order to distinguish itself from an actual answer. But this also makes them hard to read.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-float-labels-and-what-to-do-instead/contrast.png" alt=""><figcaption>Float labels have poor contrast</figcaption></figure>
</div>
<h2>3. They may be mistaken for an actual answer</h2>
<p>Like <a href="https://adamsilver.io/blog/the-problem-with-placeholders-and-what-to-do-instead/#7.-they-may-be-mistaken-for-an-answer">placeholder labels</a>, float labels may cause users to think the field has already been completed.</p>
<p>This often leads to users seeing validation errors when the user later goes to submit the form.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-float-labels-and-what-to-do-instead/filledout.png" alt=""><figcaption>Float labels make the input looked filled out</figcaption></figure>
</div>
<h2>4. A long float label will be cut off by the input</h2>
<p>Long float label text will get cut off by the input which makes the question difficult to understand.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-float-labels-and-what-to-do-instead/cropped.png" alt=""><figcaption>Long float labels get cropped</figcaption></figure>
</div>
<h2>5. Animation can cause problems for some people</h2>
<p>Float labels animate into position which can be disorientating and problematic for users who are <a href="https://alistapart.com/article/designing-safer-web-animation-for-motion-sensitivity/">sensitive to motion</a>.</p>
<p>When zoomed in, the label may disappear off screen as <a href="http://www.gerireid.com/blog/scaling-accessibility-with-a-design-system/">Geri Reid explains</a>:</p>
<blockquote>
<p>“I saw first hand what a headache [float labels] can be for a person using a zoom tool as the label can disappear off-screen as it floats up. And the testers who work at DAC are expert users […]”</p>
</blockquote>
<h2>6. They’re inconsistently located</h2>
<p>The float label function only really applies to a text input. They cannot really be applied to checkboxes, radio buttons and select boxes. This can make the label harder to scan across different types of fields.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-float-labels-and-what-to-do-instead/location.png" alt=""><figcaption>Float label location is inconsistent across different form controls</figcaption></figure>
</div>
<h2>7. They don’t make room for hint text inside the input</h2>
<p>With float labels there’s no space inside the input for hint text.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-float-labels-and-what-to-do-instead/hint.png" alt=""><figcaption>There’s no space for a hint when using float labels</figcaption></figure>
</div>
<p>Hint text could be placed underneath the text box but this means that:</p>
<ul>
<li>it can be obscured off by the browser’s autocomplete dialog or on-screen keyboard</li>
<li>it’s further disconnected from the label that it’s meant to be elaborating on</li>
</ul>
<h2>8. Any error message has to go under the input which isn’t ideal</h2>
<p>Any error message has to go under the input as there’s no other place for it to go.</p>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-float-labels-and-what-to-do-instead/error.png" alt=""><figcaption>There’s no space for an error above the field</figcaption></figure>
</div>
<p>But like the hint text issue above, <a href="https://adrianroselli.com/2017/01/avoid-messages-under-fields.html">putting the error under the input means the autocomplete dialog or on-screen keyboard can obscure them from users</a>.</p>
<h2>Float labels don’t actually save space</h2>
<p>Float labels need a place to move to.</p>
<p>Therefore, if float labels were given a legible font size, they wouldn’t really save space at all.</p>
<p>Maybe you could make space as the label animates into position, but that would make the page jump awkwardly as the user starts typing.</p>
<h2>Just use a static label above the input</h2>
<p>This means:</p>
<ul>
<li>the label can be read</li>
<li>it’s obvious where the answer goes</li>
<li>it’s obvious which fields need to be completed</li>
<li>the label can be as long as it needs to be</li>
</ul>
The problem with atomic CSS2017-04-16T00:00:00+00:00https://adamsilver.io/blog/the-problem-with-atomic-css/<p>When I published <a href="https://maintainablecss.com/">MaintainableCSS</a>, I compared semantic and non-semantic class names.</p>
<p>In response, atomic CSS advocates critiqued semantic class names. While this got me thinking, my mind remains mostly unchanged.</p>
<p>Here I’ll explain why that is and address some of the responses.</p>
<h2>1. “Semantic is a misleading word”</h2>
<p>In <a href="https://tink.uk/understanding-semantics/">Understanding Semantics</a>, Léonie Watson says that semantic means:</p>
<blockquote>
<p>“of code intended to reflect structure and meaning.”</p>
</blockquote>
<p>This is why “wrapper” is semantic. It’s an element that wraps another, always. Whether CSS clears floated “columns” on big screens or stacks them on small screens, it’s always a wrapper.</p>
<p>Therefore once HTML is written, it doesn’t need to change. Where as a class of <code>red</code>, or <code>clearfix</code> is not semantic — at least not in the context of HTML.</p>
<p>In the context of HTML, a semantic class name describes what it is, not what it looks like or how it behaves.</p>
<h2>2. “Semantic classes create sites that are slow to load”</h2>
<p>I’ve built many sites. They were never slow because we used semantic class names. One recent example of this is a fully custom, fussy and responsive e-commerce site which totalled just 48kb.</p>
<p>It’s not slow and I didn’t pay much attention to CSS performance. We could make some savings but the current 48kb of CSS isn’t hurting anyone.</p>
<h2>3. “Atomic CSS ensures design is consistent”</h2>
<p>Theoritically, if you can only use predefined classes, it’s easier to ensure the UI is consistent. This makes sense because it limits what the developer can use. But there’s nothing to stop someone adding a new margin-bottom class or using the wrong one.</p>
<p>Perhaps there’s an opportunity to create a tool as opposed to a naming convention for this?</p>
<h2>4. Analysing CSS performance in isolation</h2>
<p>The most celebrated aspect of atomic CSS is that it results in a small CSS footprint which speeds up the time to first paint. The problem is that this point is always discussed in isolation making this selling point misleading at best.</p>
<p>Firstly, the size of the HTML increases a lot. Remember CSS is cacheable and serves an entire site like the one I mentioned earlier. HTML is unique, dynamic, and often personalised. It can’t be cached.</p>
<p>Secondly, the amount of CSS saved, even with large codebases, would be relatively small. While there may be sites with ten trigabytes of CSS, not only are they rare, there are solutions for this too.</p>
<p>Finally, the size of CSS is not the only performance indicator. Others need to be considered holistically.</p>
<h2>5. Atomic classes are hard to read</h2>
<p>Atomic class names are usually abbreviated. Abbreviations are hard to read. They have to be understood and mentally mapped. We should strive for <a href="https://signalvnoise.com/posts/3250-clarity-over-brevity-in-variable-and-method-names">clarity over brevity</a>.</p>
<p>What does ‘blk’ mean, for example? Does it mean black or block? Let’s say it means black. Is that black text or a black background.</p>
<p>We can use verbose names that are easier to read, but this makes the HTML bigger and degrades performance — which is the reason for abbreviations in the first place.</p>
<p>And it shouldn’t be about saving keystrokes – text editors have autocomplete for this.</p>
<h2>6. Atomic CSS recreates CSS in HTML</h2>
<p>Atomic CSS recreates the same constructs found in CSS in order to use classes in HTML. CSS was designed for styling.</p>
<p>It’s wasteful recreating a convention for HTML which encourages developers to use the wrong tool for the job.</p>
<h2>7. We need semantic class names anyway</h2>
<p>In order to write functional tests and enhance websites with JavaScript we’re going to need semantic classes. So there’s going to be a mix of classes reserved for different things.</p>
<p>Inconsistent code is hard to reason about and if there are two ways of doing something, inevitably they’ll get mixed up.</p>
<h2>8. Semantic CSS doesn’t violate ‘Don’t repeat yourself’ DRY</h2>
<p>Trying to reuse a CSS rule is like trying to reuse a variable across different Javascript objects. It’s simply not in violation of DRY. CSS abstracted all the rules for us so that we can specify what we want when we want.</p>
<h2>9. Semantic class names are easier to delete</h2>
<p>A semantically-defined component is easy to delete because the related CSS is explicitly connected.</p>
<p>Whereas Atomic CSS is intertwined across a multitude of elements making the code hard to delete.</p>
<p>Before deleting the related CSS you need to look at each class on every element within the component, to determine if it’s used elsewhere. Only then can you decide if you can delete it.</p>
<p><a href="https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to">Good code is easy to delete</a> because it’s not intertwined.</p>
<h2>10. Atomic CSS is a responsive design anti-pattern</h2>
<p>As Ben Frain says in <a href="https://benfrain.com/oocss-atomic-css-responsive-web-design-anti-pattern/">Atomic CSS is a Responsive Design Anti Pattern</a> ‘making very specific changes at certain breakpoints and tying them to a class that has to be added to the HTML seems needlessly complex.’</p>
<p>He continues to say that ‘you inevitably end up with a raft of classes in your stylesheets that are obsolete.’ I agree.</p>
<h2>11. It’s harder to style pseudo classes</h2>
<p>For each style you want to change, you need an equivalent, verbose, hard to read class name. For example <code>.red-text-when-hover</code> or <code>.black-bg-when-focus</code>.</p>
<p>If the styles need to change at different breakpoints, it’s even harder. For example <code>.red-text-when-hover-on-large-screens</code>.</p>
<h2>12. It’s harder to style based on state</h2>
<p>Consider a basket that has an empty state. Each style that is different due to the state needs its own class.</p>
<h2>13. Javascript now needs to manage styles too</h2>
<p>JavaScript has to change several classes in response to a change of state.</p>
<p>For example, let’s say we have the following HTML:</p>
<pre><code><div class=”red-text float-left border-1px border-color-red”>
</code></pre>
<p>When the user clicks the <code><div></code> JavaScript needs to make sure the border becomes 2px thick and blue in colour.</p>
<p>Here you’d need to add (and maybe remove) several style declarations using JavaScript. Meaning that Javascript has to be “style aware” too.</p>
<h2>14. It’s harder to style based on reading direction</h2>
<p>As <a href="https://twitter.com/Cinsoft/status/835968849086394368?s=09">David Mark said on Twitter</a>, ‘invariably, “pull-left” contains float:right in RTL configurations. That’s a clue as to why it makes no sense.’</p>
<h2>15. It’s harder to enhance</h2>
<p>If we want to use <code>@supports</code> we would need a <code>.supports-x-do-y-class-name</code>.</p>
<h2>16. It’s harder to change layout mechanisms</h2>
<p>As Ben Frain says in the same article ‘suppose […] we change our product […] from float based layouts to Flexbox based layouts. We now have twice the maintenance burden.’</p>
<h2>17. It’s harder to fix Internet Explorer issues</h2>
<p>Sometimes we add conditional CSS to fix Internet Explorer bugs. We can’t target atomic class names to do this.</p>
<h2>18. Atomic classes are misleading and redundant</h2>
<p>For example, <code>overflow-hidden</code> is used to clear floated children. However, in small screens the children are stacked, not floated. This is misleading for developers and redundant for users.</p>
<h2>19. Every element needs classes</h2>
<p>With atomic CSS every element needs several classes. But sometimes we don’t need to add a hook, as we can do this: <code>.blah div</code> or this: <code>input[type=submit]</code>.</p>
<p>Also, Markdown, for example, forces us to style elements through a common ancestor with a semantic class name.</p>
<h2>20. It makes the inspector noisy</h2>
<p>It’s hard to work out where a component starts and ends because there’s nothing to demarcate it in the HTML. The content is obfuscated and the inspector has more lines of code to look at.</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/atomiccss/inspector.png" alt="" width="100%">
<figcaption>Many declarations are a cognitive burden on developers.</figcaption>
</figure>
</div>
<h2>21. It’s hard to find HTML</h2>
<p>It’s harder to search the codebase for a particular element because atomic class names aren’t unique to particular elements. While good file structure and templating helps, having to rely on it is less than ideal.</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/atomiccss/inspector2.png" alt="" width="100%">
<figcaption>Search for atomic class names is not going to help narrow in on the component in question.</figcaption>
</figure>
</div>
<h2>22. “Switching between HTML and CSS is hard”</h2>
<p>Of all the things developers habve to do, pressing <kbd>CMD+TAB</kbd> is hardly taxing. And in reality, the only way you won’t have to switch to the CSS file (or documentation) is if you memorise every available class name.</p>
<h2>23. “Atomic CSS makes it easy to reuse CSS across projects”</h2>
<p>Being able to reuse CSS across projects is a nice idea if your sites are going to look the same. But most sites are branded uniquely to look different.</p>
<h2>24. It’s hard to theme CSS</h2>
<p>When I worked on a white-label solution for several e-commerce sites it was the HTML that was reused, not the CSS. That’s because the HTML is similar, not the CSS.</p>
<h2>25. “Semantic classes are longer than atomic class names”</h2>
<p>Here’s a typical snippet of atomic CSS from a site that has basic styling:</p>
<pre><code><div class="w5 w6-m w-50-l center overflow-visible mt3 mt4-m dtc-l v-mid-l tr-l">
</code></pre>
<p>I’ve never seen a semantic class name that is close to this.</p>
<h2>Summary</h2>
<p>In many cases, atomic CSS will decrease the size of your CSS file. That’s to be expected. Just like if I decided to inline all styles, I would expect the size of the CSS file to be zero.</p>
<p>The problem is that this introduces other issues that shouldn’t be ignored. Performance is only an issue once it becomes an issue. There could be many factors to consider.</p>
<p>I’m not saying to wait for a problem, but I’m not saying we should discard tried, tested and technology-embracing techniques like semantic CSS either.</p>
<p>There are other ways of making websites load faster with regards to CSS. For example, we don’t have to load the entire site’s CSS at once. We could load page-specific CSS and cache progressively.</p>
<p>Focusing on CSS isn’t necessarily where our energy is best spent. Perhaps the page has too much stuff. Perhaps the visual design is wasteful and not a benefit to users. You might be using a framework, CSS or otherwise which you don’t need.</p>
<p>All in all, having to navigate our way through all the trade-offs to shave some CSS, which drastically increases the size of HTML, is just trading one problem for several other bigger problems.</p>
<p>In most cases, we’re going to need semantic classes to do the job regardless. We may as well make use of them for CSS too.</p>
Stop using device breakpoints2017-03-28T09:00:01+00:00https://adamsilver.io/blog/stop-using-device-breakpoints/<p>I see it all the time. Designers, and developers alike, setting breakpoints according to their favourite device. When will we learn from our past mistakes?</p>
<p>When the web came along we settled on 640 pixel widths. Then a few years later, when larger monitors came to market, we settled on 960 pixels. We no longer cared about people with smaller monitors.</p>
<p>Then more years passed. The mobile web was born. Or more accurately, we could consume websites on our phones, which happen to have small screens. A million browsers came out. A million devices came out. And browsers gave us media queries.</p>
<p>At about this time, we decided to use 320 pixels for mobile. Why? Because a lot of us had the iPhone, and this was its width in portrait.</p>
<p>Then landscape mode. Then tablet (that’s still mobile right?). Then desktop. Then big desktop like super size thunder screens or whatever the hell they’re called. (I’m not Googling it because you know what I mean). Then TV. Then wristwatch and then…</p>
<p>You get the point. The web is not print. The web is the web and we have no idea what size screen our users have. We just can’t control that. And even if we could, the proliferation of devices means that designing for them is futile.</p>
<p>But there’s a few things we do know. We know our brand and our design. And, more importantly, we know our content. Content isn’t just paragraphs of text. It’s <em>the things that are held or included in something</em>.</p>
<p>We should always start with content. Without content, design is meaningless. We design to help users consume content. We don’t use content to help users enjoy our designs.</p>
<p>We often start designing with a box. And then we put smaller boxes inside it. Then later we fill in these boxes with actual content.</p>
<p>As Frank Chimero beautifully explains in <a href="https://www.frankchimero.com/writing/the-webs-grain/">The Web’s Grain</a>, this is just about the worst thing we can do.</p>
<p>How can we possibly design something until we know what the content is?</p>
<p>I’ve witnessed designers finish their mock-ups and ask the resident content designer to make the content fit. Maybe even ask them to shorten their user-friendly content to make sure it doesn’t wrap and so forth. It may help the designer. It doesn’t help the user.</p>
<p>And when they check their design on landscape or on a device they don’t own, they get flustered. What they see as control, is really an unnecessary constraint on their design to a known set of device sizes.</p>
<p>Instead we should let content be our guide. We should set a breakpoint when and if the content requires it. We can call them content breakpoints or what Frank refers to as points of reassembly.</p>
<p>Take for example the subscribe form on <a href="http://maintainablecss.com/">MaintainableCSS</a>. Taking a content-led, small-screen first approach, the button sits under the text box. And when there’s room, they sit along side each other.</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/breakpoints/maintainablecss.png" alt="MaintainableCSS subscribe form" width="100%">
<figcaption>MaintainableCSS' responsive subscribe form</figcaption>
</figure>
</div>
<p>The media query uses a breakpoint of 36em. Why? Because that’s when there is an opportunity for content reassembly. The button and text control lose their affordance when they get really wide on bigger screens. So we can fix that.</p>
<p>And it’s only relevant to the subscribe form. There is no blanket rule that states that 36em means “big”. The breakpoint reflects the need of the module and content in question.</p>
<p>Technically it’s just a media query. But the mindset and the approach is what sets it apart. The design supports the content. Not the other way around.</p>
<p>This is why <a href="http://getbootstrap.com/css/">CSS frameworks</a> cause problems by unnecessarily constraining our content to fit into a predefined grid. How can a CSS framework know what our content is? It can’t.</p>
<p>The term mobile first encourages us to think in terms of device. But the web isn’t a set of devices. The web is a continuum of edgelessness. That’s the coolest sentence I’ve ever written.</p>
<p>What it means is this. There is absolutely no point — whatsoever — in trying to work out the size of a particular device, in order to then define a codified responsive grid.</p>
<p>At best it’s constraining and at its worst, it causes problems.</p>
<p>Instead, let the content be your guide. If and when it breaks we can reassemble it with the necessary content breakpoint.</p>
<p>Responsive design frees us from the shackles of designing based on devices, which is impossible to get a handle on. Content breakpoints give people better experiences no matter what size device they have.</p>
Universal design checklist2017-02-15T09:00:01+00:00https://adamsilver.io/blog/11-things-to-consider-when-designing-for-everyone/<p>The web has been around long enough for us to know its powers and constraints.</p>
<p>We know about the constraints because we’ve bent them as much as we can over the years. For example, before CSS, we used tables and spacer gifs for layout. And before <code>border-radius</code>, we used background images for rounded corners.</p>
<p>We use pre-existing mediums as a guide for how a new medium should work.</p>
<p>We take our preconceptions and apply them as best we can.</p>
<p>We’re much better now at embracing the web than we used to be but we still make too many <a href="https://resilientwebdesign.com/chapter7/#Assumptions">assumptions</a>. Many of those are wrong. For example, we used to think that all viewports were 640px wide. And we used to think that all computers had a keyboard and mouse.</p>
<p>More recently, we thought that small screens means swipeable, and big screens means mouse users.</p>
<p>These assumptions are also wrong.</p>
<p>The truth is, we don’t always know what users do. We don’t know their ability or preferences. We don’t know much. And that’s okay.</p>
<p>But we can still design simple experiences that embrace these constraints.</p>
<p>After all there’s no creativity without constraint.</p>
<p>Which is why I’ve created a universal design checklist which takes into account every constrant.</p>
<p>Let’s go:</p>
<h2>Constraint #1: Outlook, culture and understanding</h2>
<p>Everyone is different.</p>
<p>How people think and see the world is unique to the individual. We’re influenced by where we live, our upbringing and the people we spend time with.</p>
<h2>Constraint #2: Disabilities</h2>
<p><a href="http://www.serviceandinclusion.org/index.php?page=basic">48.9 million people suffer from disabilities</a>.</p>
<p>This disabilities affect <a href="https://the-pastry-box-project.net/anne-gibson/2014-July-31">mobility, hearing and eyesight</a>.</p>
<p>Not all disabilities are permanent. For example, a mother holding a baby only has one available arm.</p>
<h2>Constraint #3: Preferences</h2>
<ul>
<li>Some people prefer touch screens</li>
<li>Some people prefer keyboard</li>
<li>Some people prefer screen readers</li>
<li>Some people print web pages</li>
</ul>
<p>Designing for preferences is good design.</p>
<h2>Constraint #4: Speed and connectivity</h2>
<p>Industry pros often have fast connections. But many people don’t.</p>
<p>Make the slow fast and the fast, lightning.</p>
<h2>Constraint #5: Screen size</h2>
<p>People use multiple different devices from watches to TVs.</p>
<p>Responsive design isn’t about 3 different media queries. It’s about <a href="https://adamsilver.io/blog/stop-using-device-breakpoints/">fixing content where it breaks</a>.</p>
<h2>Constraint #6: Browsers</h2>
<p>Different browsers have different functionality and support.</p>
<p>This impacts what users can do or experience. Deliver a solid baseline experience and <a href="https://adamsilver.io/blog/progressively-enhanced-javascript/">use progressive enhancement</a>.</p>
<p>Everything but content is an enhancement.</p>
<h2>Constraint #7: Data cost</h2>
<p>While you and I may have expensive data contracts, many people don’t.</p>
<p>Even if data is cheap, it can run out. Let’s keep our interfaces and interactions lightweight.</p>
<p>Breaking up content across pages gives users the choice to load it.</p>
<h2>Constraint #8: Environment</h2>
<p>People’s experiences are affected by their environment.</p>
<p>For example, low lighting, screen glare from the sun or being outside in the cold wearing gloves.</p>
<h2>Constraint #9: Standards and conventions</h2>
<p>Use the same patterns to solve the same problems.</p>
<p>This is intuitive. You can <a href="https://medium.com/@mibosc/responsive-design-why-and-how-we-ditched-the-good-old-select-element-bc190d62eff5#.8m0u1kb7p">break convention</a> but you need a good reason to do that.</p>
<h2>Constraint #10: Interoperability</h2>
<p>Some people use Safari’s reading mode or a feed reader to access the web.</p>
<p>Some people rely on how Google displays search results.</p>
<p>We need to consider the experience outside of UIs and design for where people are.</p>
<h2>Constraint #11: Configuration</h2>
<p>We can’t assume people use their devices in factory settings.</p>
<p>People add plugins and adjust the font size.</p>
<h2>There’s no creativity without constraint</h2>
<p>Bad design ignores people.</p>
<p>And there’s a lot be said for design that ignores people. People ignore it.</p>
<p>Let’s embrace these constraints.</p>
<p>And make products that work for everyone.</p>
<p>That’s the challenge.</p>
Don’t initialise Javascript automagically2016-12-06T09:00:01+00:00https://adamsilver.io/blog/dont-initialise-javascript-automagically/<p>I used to write Javascript that initialises components automagically, like this:</p>
<pre><code>var datepickers = document.getElementsByClassName(‘datepicker’);
for(var i = 0; i < datepickers.length; i++) {
new DatePicker(datepickers[i]);
}
</code></pre>
<p>It works by looping over every element with a particular class name. For each element found a date picker is created automagically.</p>
<p>Developers like this because it’s just 4 lines of code. And it never needs updating—theoreticaly at least. If you want another date picker, just add a class of date picker and done.</p>
<p>Except it’s not as simple as that. This approach has many downsides which I’ll explain here.</p>
<h2>1. It’s harder to understand the codebase at a glance</h2>
<p>To understand the codebase at a glance, you need to know what behaviour exists<br>
and where.</p>
<p>The loop doesn’t tell you how many date pickers there are. There could be a thousand instances or there could be one (or none) — in which case the loop is misleading. Either way you don’t know.</p>
<h2>2. You might apply behaviour by accident</h2>
<p>If you happen to use a class that corresponds to a component, then you might accidentally initialise behaviour.</p>
<h2>3. It’s difficult to estimate stories</h2>
<p>If you can’t document what you’re changing and where, it’s difficult to define and estimate a story.</p>
<h2>4. It’s difficult to QA</h2>
<p>After modifying a date picker, a tester will ask you what parts of the system you’ve affected. The loop doesn’t help you answer this question.</p>
<h2>5. It’s harder to debug</h2>
<p>If there’s a problem with one date picker, finding and debugging it is more tricky. You will have to find the problematic instance by searching the HTML templates. Then you will need to step through the loop until you find the erroneous one.</p>
<h2>6. It’s harder to delete</h2>
<p>As you don’t know where the loop is executing, you can’t delete code in confidence. Thus, the code stays in the codebase for a long time.</p>
<h2>7. It’s hard to determine behaviour</h2>
<p>This approach forces you to store behaviour in HTML attributes. This isn’t an elegant way to define behavioural relationships. HTML becomes bloated and hard to read. Every attribute value is a string, when you might, for example, want a number.</p>
<pre><code><div class="datepicker otherComponent" data-datepicker-attr="etc" data-datapicker-event="listener" data-othercomponent-attr="blah">
</code></pre>
<h2>8. It’s painful to customise</h2>
<p>When you need to use models and XHR etc, it becomes painful to work with this approach.</p>
<p>For example, let’s say you have a form with two date pickers: start date and end date.</p>
<p>When the user chooses a start date, the end date values update. This is to ensure the end date is always comes after the start date.</p>
<p>This is hard to define in HTML. In Javascript it’s easy:</p>
<pre><code>var startDate = new DatePicker();
var endDate = new DatePicker();
startDate.on('changed', function() {
endDate.whatever();
});
</code></pre>
<h2>9. It’s painful to infer behaviour from HTML</h2>
<p>The loop doesn’t allow you to customise an instance by passing in options. Instead, you have to store behaviour in HTML. When you change behaviour, you must update the HTML. This goes against recommended <a href="https://en.wikipedia.org/wiki/Separation_of_concerns">practices</a>.</p>
<h2>10. It’s painful to override behaviour</h2>
<p>To override behaviour, you will need to add an extra class to the HTML. Then the date picker (or the loop) will determine the override by checking for this extra class. At this point, the component (or the loop) is no longer generic.</p>
<h2>11. It’s hard to destroy instances</h2>
<p>It’s easy to store the instances during initialisation. But, determining and retrieving one later so you can destroy it, is harder this way.</p>
<h2>12. It increases the chance of performance issues</h2>
<p>This approach means the Javascript has to crawl the DOM a lot more than is otherwise necessary. First to find elements that need enhancing, and second to determine behaviour from attributes.</p>
<p><a href="https://www.nczonline.net/blog/2009/02/03/speed-up-your-javascript-part-4/">Touching the DOM is expensive</a>, which increases the risk of performance issues. The risk increases further when you have many components and many instances of a component.</p>
<h2>13. It’s harder to unit test</h2>
<p>It’s difficult to unit test behaviour when you store behaviour in HTML. You might then decide to use HTML fixtures. But they are slow and you’re no longer writing unit tests. You <em>could</em> mock the DOM but this is tedious and problematic. The less you store in HTML the easier it is to test.</p>
<h2>14. It exposes a security hole</h2>
<p>You can read about the <a href="https://githubengineering.com/githubs-csp-journey/#object-src">security hole here</a>.</p>
<h2>Common responses</h2>
<h3>“But I don’t want to update Javascript every time I want a new instance?”</h3>
<p>I fail to see why updating Javascript is a problem. In fact, I would <em>expect</em> you to change Javascript when updating behaviour. Updating HTML instead of Javascript is not better.</p>
<h3>“Is this necessary—it feels like code bloat?”</h3>
<p>If code is valuable, it’s not code bloat.</p>
<h3>“But the Javascript will have a lot more code.”</h3>
<p>Maybe. Maybe not. It depends on your architecture and your requirements. Even if it did, good code is not just determined by the number of lines.</p>
<h3>“But let’s at least use it for simple components.”</h3>
<p>Even if it did work for simple components, you have to draw a line between simple and complex. This is arbitrary and having two ways of doing the same thing makes code inconsistent.</p>
<h3>“It’s easier for <strong>backend developers to add behaviour in HTML.</strong>”</h3>
<p>You need to decide whether backend developers should be writing Javascript or not. If they should be writing it, then help them do it right. They are software engineers. Trust them.</p>
<h2>Summary</h2>
<p>Good code is not about number of lines.</p>
<p>Good code is not about how easy it is to write the first time.</p>
<p>Good code is easy to reason about.</p>
<p>Good code is easy to update.</p>
<p>Good code is consistent.</p>
<p>Good code is easy to unit test.</p>
<p><a href="http://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to.">Good code is easy to delete.</a></p>
<p>Bad code is easy to write but hard to delete. Bad code is magical. Magic is<br>
entertaining. Code shouldn’t be entertaining.</p>
<p>Automagical loops obfuscate complexity. They make things appear simple when<br>
they’re not.</p>
<p>Help future-you by writing Javascript that doesn’t suffer from these problems.<br>
HTML isn’t good at defining behaviour. But Javascript is.</p>
Semantic class names: are you being too generic or too specific?2016-10-31T09:00:01+00:00https://adamsilver.io/blog/semantic-class-names-are-you-being-too-generic-or-too-specific/<p>Even if you’re completely sold on <a href="http://maintainablecss.com/chapters/semantics/">semantic class names</a> and avoid stylistic and behavioural class names altogether, choosing a good class name is hard.</p>
<p>The problem boils down to naming your classes either too generically or too specifically. Both of which have pros and cons. But I like to think we can choose a class name without any cons. Let’s see.</p>
<p>Most developers I’ve worked with tend to use overly generic class names. There’s a tendency to do this because—at least in theory—the more generic something is the more reusable it is. But for CSS this isn’t really the case.</p>
<p>It’s easier to explain what I mean by example. So, let’s build a login form together. The login form has an email and password field. I will leave out certain elements for brevity.</p>
<p>To start, we could name these elements as follows:</p>
<pre><code><form class=”loginForm”>
<div class=”loginForm-email”>
<label>…</label>
<input type=”email”>
</div>
<div class=”loginForm-password”>
<label>…</label>
<input type=”password”>
</div>
</form>
</code></pre>
<p>These class names are coupled to this one module. They can’t be reused elsewhere. This is good because we can style the form without affecting other forms. On the other hand, by using a mixin or comma-delimitting selectors we <em>can</em> reuse the <em>styles</em>:</p>
<pre><code>.loginForm-email,
.loginForm-password,
.someOtherForm-someField {
/* Common field style */
}
</code></pre>
<p>There are problems with this approach. First, you could end up with quite a lot of CSS which seems a bit unnecessary. Second, every new field requires CSS changes. Simple changes, but changes nonetheless.</p>
<p>Now if your forms have a different structure and aesthetic this isn’t a problem at all. In fact it’s a benefit. But I would guess that most, if not all forms will have the same styling. Afterall, good design is consistent.</p>
<p>We could improve our approach by upgrading a field to a module and naming it <code>.formField</code>. This feels better to me, at least at this stage of the analysis. This module doesn’t require a mixin or comma-delimitted selectors. And each new field does not require CSS changes.</p>
<p>Let’s continue by finding some problems with this generic, reusable <code>.formField</code> module. What if some fields need to accomodate a hint, for example? And for the purposes of this example this sort of field needs different styles to accomodate the hint.</p>
<p>This is where <a href="http://maintainablecss.com/chapters/modifiers/">modifiers</a> come in. Just add an extra class name and make the required tweaks.</p>
<pre><code><form class=”someForm”>
<div class=”formField”>
<label>…</label>
<input type=”text”>
</div>
<div class=”formField formField-withHint”>
<label>…</label>
<p>The hint goes here</p>
<input type=”text”>
</div>
</form>
</code></pre>
<p>In this case we just needed a few tweaks and so this generic class name works well. But what if we had something that’s significantly different? For example, you might need a field with radio buttons.</p>
<p>Using a modifier is problematic because there is little to inherit. When we named our module <code>.formField</code> we didn’t consider radio buttons, or any other type of control for that matter.</p>
<p>This isn’t necessarily a bad thing. In fact, in many ways this is good. If we try too early to find commonality in a design system, it can lead to over-engineered solutions.</p>
<p>Text fields are very different to radios. The latter requires a legend, fieldset and a different structure. They’re so different that despite them both being form fields, we shouldn’t consider them to be the <em>same</em> at all. This point is worth deliberating over.</p>
<p>Earlier, <code>.formField</code> felt like a good name for a class. But now, with this new information it doesn’t seem so good. We don’t want to update styles for a radio field and worry about regressing the text fields. And, we don’t want to work out the few bits of commanility between these two entities, just to shave a little CSS.</p>
<p>Having analysed the situation, it’s much easier to decide on a good name. I would suggest naming the text field <code>.textField</code> and the radios <code>.radioField</code>.</p>
<p>This enables us to treat them as the distinct modules they are. They’re specific enough to be able to differentiate. Yet they are generic enough to be reused across multiple forms, without writing unnecessary CSS.</p>
<p>In retrospect this seems rather easy. The problem is that we face decisions like this all the time. Or we don’t face them and end up with unmaintainable CSS. This is why I prefer to start with specific class names.</p>
<p>I’d rather have a little more CSS and the flexibility to style elements consistently (or differently whatever the case may be). Otherwise, I’d have to contend with overrides and regression.</p>
<p>This affords us the space and time to learn what is worth abstracting and what isn’t. You may learn that even <code>.textField</code> is too generic. For example, you might have many different types of text fields that are better off being their own modules. You might not.</p>
<p>What’s important is that we think about these things frequently and rigorously. I’ve found the following questions useful over the years:</p>
<p><strong>1) Do you have a module appearing in many places but with slightly different aesthetics based on proximity, location or content?</strong></p>
<p>If yes, you should probably use a <a href="http://maintainablecss.com/chapters/modifiers/">modifier</a>.</p>
<p><strong>2) Do you have a component that could be used elsewhere pretty much as is?</strong></p>
<p>If yes, you should probably convert the module into a component. But, be careful not to name it too generically.</p>
<p><strong>3) Do you have a module with many different modifiers? Or are you spending time working out what styles are common to all scenarios?</strong></p>
<p>If yes, you probably named the module too generically. Split it out into several dedicated modules.</p>
<p>Having to think about class names is hard. But not thinking about class names is much harder, at least down the line. If in doubt, go specific, but if you think about these problems frequently you may not have to.</p>
Browsers are different but so what?2016-09-01T09:00:01+00:00https://adamsilver.io/blog/browsers-are-different-but-so-what/<p>You know, it’s funny, when the web came along, we used the medium of print to set expectations for how things should be.</p>
<p>When you print out a business card it always looks the same, no matter who you are or where you are. It’s a physical thing.</p>
<p>This is not the case with browsers. Browsers are not identical to each other. They are largely similar, but they still have plenty of differences. Just like Mac and Windows. Both computers can be used to perform very similar tasks. But they <em>are</em> different.</p>
<p>When people first encountered this difference on the web they would be like “WTF”. Founders, business owners, testers and even designers and developers (you know the very people that are meant to know this shit ) all included.</p>
<p>This reaction is based on a belief system , the belief that the browser should behave a certain way, in this case like print.</p>
<p>The funny thing about belief systems, is that even if they are wrong, it doesn’t really matter right?</p>
<p>Well, kinda. Let me explain:</p>
<p>It’s true that if people paying for the project believe a website should look identical, then that’s what front-end developers (and testers etc) will be tasked with. And this is exactly what happened to me and many other people working in the industry.</p>
<p>It’s false because people’s beliefs change due to new experiences and education. Over time people learnt that the browser is different. It’s special and uniquely powerful. It’s not print.</p>
<p>This often leads to the realisation that the idea of making things look identical and “perfect” in all browsers is not only Sisyphean, but that it’s not required or even <em>valuable</em> to the user on the other end. I guess what I am trying say is users don’t care!</p>
<p>Most people use one or two browsers. And even if they use more than that, it still doesn’t matter, because users don’t even notice — they don’t care about your website like you do — they just want to use the service and get back to their day. And even if they did notice, so what?</p>
<p>Furthermore, those subtle differences would be the same across all the websites they browse to in that browser. For example, radio buttons are rendered slightly different in IE9. But that will be the case for every website that uses radios. It becomes an expectation and one that in almost all scenarios doesn’t hurt the experience.</p>
<p>If a client or tester or whoever else says “But [insert browser] does it like this…” this is typically a huge waste of time. My response is almost always “Yes, is that a problem?”. Invariably there is no actual reason to worry about this at all.</p>
<p>Case in point. On a recent project a download attribute was added to a link:</p>
<pre><code><a href=”/path/to/file.pdf” download>Download PDF file</a>
</code></pre>
<p>Without this, some browsers — depending on the file-type — will load that file in the browser like a web page. This is the case for a PDF file for example.</p>
<p>This attribute ensures that the file is to be treated as a download in the traditional sense i.e. downloaded into a folder on the user’s machine.<br>
The “problem” is that when the file can’t be found, FireFox displays a “special” screen that explains that it can’t be downloaded. Other browsers just show the regular 404 page served by the website typically “We can’t find what you’re looking for” etc.</p>
<p>Is this a problem? Of course not. Firefox will do this for all websites that use the download attribute. Arguably it’s an enhancement for FireFox Users — lucky them! In the future FireFox might change the behaviour. Maybe Chrome copies them. Maybe none of this happens. Who knows and who cares? Users don’t.</p>
<p>My point is this. The web is its own thing. It has its own ways. This is not something to be feared. There is nothing to bat into shape. The web and the browser is to be <a href="https://adamsilver.io/blog/embracing-simplicity/">embraced</a> to the user’s advantage.</p>
Making view templates as dumb as possible2016-08-08T00:00:00+00:00https://adamsilver.io/blog/making-view-templates-as-dumb-as-possible/<p>Products and services usually start with a set of user needs which are then translated into screens (and other things) that meet those needs.</p>
<p>The screens are translated into frontend code and while that’s all happening we may try to find the best way to split up the pieces into components.</p>
<p>Once that’s done, it’s time to integrate data and logic into the templates for the user to actually interact with.</p>
<p>The object that contains the data and logic is called a view model — it’s a model designed for the view.</p>
<p>We can’t design a view-model without first understanding the needs of the view. And we can’t understand the needs of the view without first understanding the visual and interaction design requirements etc.</p>
<p>Sometimes, a view model is badly designed or neglected. By that I mean it exposes too much low-level logic which makes templates difficult to work with.</p>
<p>For example, imagine a welcome message that consists of some text and a link. And imagine it renders differently depending on the following circumstances:</p>
<ul>
<li>When the user isn’t signed in it says <code>Welcome — [sign in]</code></li>
<li>When the user is signed in and the the user’s name is known it says <code>Welcome — [sign in]</code></li>
<li>When the user is signed in and the user’s name is unknown it says <code>Welcome back — [sign in]</code></li>
</ul>
<p>Consider the following template:</p>
<pre><code>
{% if isSignedIn %}
{% if firstName and lastName %}
<p>Hello {{firstName}} {{lastName}} - <a href="{{signOutLink.href}}">{{signOutLink.text}}</a></p>
{% else %}
<p>Welcome back - <a href="{{signOutLink.href}}">{{signOutLink.text}}</a></p>
{% endif %}
{% else %}
<p>Welcome - <a href="{{signInLink.href}}">{{signInLink.text}}</a></p>
{% endif %}
</code></pre>
<p>There’s no need for separate first and last name properties because they’re styled the same. And there’s no need to check whether the user is signed in.</p>
<p>See this instead:</p>
<pre><code>
<p>{{message}} — <a href=”{{link.href}}”>{{link.text}}</a></p>
</code></pre>
<p>The view model has been designed from the outside in. It contains just what the template needs in order to render itself.</p>
<p>As there’s always a message and a link, there’s no need for conditionality.</p>
<p>This template is 1 line compared to the original line and consists mostly of HTML which is far easier to read.</p>
<p>This template is dumb and means complex logic can live somewhere more appropriate. And as the logic lives outside the template, it can be unit tested.</p>
<p>Next, I’ll cover some other common scenarios where we can make our templates dumb.</p>
<h2>1. Views shouldn’t know where data comes from</h2>
<p>If, for example, your view displays a message of ‘Hello Adam’ the view model should be:</p>
<pre><code>{ message: "Hello Adam" }
</code></pre>
<p>The template would be:</p>
<pre><code><p>{{message}}</p>
</code></pre>
<p>The message may consist of text from resource files or the database but the view shouldn’t need to worry about that.</p>
<h2>2. Views shouldn’t know why something should be displayed</h2>
<p>If, for example, a message is only displayed when the user is signed in, the view model should be:</p>
<pre><code>// view model when signed in
{ showMessage: true, message: "Hello Adam"}
// view model when not signed in
{ showMessage: false }
</code></pre>
<p>The template would be:</p>
<pre><code>{% if showMessage %}
<p>{{message}}</p>
{% endif %}
</code></pre>
<p>The template shouldn’t be concerned about why the message is shown or not.</p>
<h2>Summary</h2>
<p>Without care, templates can become complex.</p>
<p>Templates shouldn’t have to infer display logic from multiple properties and they shouldn’t have to care where its data comes from.</p>
<p>Templates should be easy to read and consist mostly of HTML with just enough data to support the display.</p>
<p>This keeps templates simple and easy to maintain. It also means complex logic can be unit tested and live in files that are better suited to such logic.</p>
Buttons shouldn't have a hand cursor2016-07-15T09:00:01+00:00https://adamsilver.io/blog/buttons-shouldnt-have-a-hand-cursor/<p>Like many people in the web community, I used to believe that the hand (or pointer) cursor signifies an element is clickable. But that’s actually not what the pointer cursor was originally intended for.</p>
<p>In this article I’ll explain why that is and how using the pointer cursor might be harmful to users when it’s used to signify things that are clickable.</p>
<h2>The hand doesn’t mean clickable</h2>
<p>It’s no accident that browsers don’t apply the pointer cursor to buttons, and many other elements. See the screenshot below which shows a plethora of interactive elements that aren’t given the hand cursor.</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/buttons/chrome.jpeg" alt="Chrome on Mac OS" width="100%">
<figcaption>Google's search page on Chrome Mac OS</figcaption>
</figure>
</div>
<p>The screen shot shows an interface with menus, tabs, whitespace (context menus), browser buttons and text box. All of them are clickable, but none of them are given the pointer cursor.</p>
<p>The same goes for select menus, sliders, checkboxes, radio buttons, labels, images, and text. None of them are given the pointer cursor.</p>
<p>These things can be tapped, dragged, selected, pressed, left clicked, right clicked. But like buttons, they are not signified by the cursor changing to the pointer when the user hovers on them.</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/buttons/license.jpeg" alt="" width="100%">
<figcaption>License Agreement is a link and gets the pointer cursor. Buttons don’t.</figcaption>
</figure>
</div>
<p>The way users perceive an element’s behaviour is shaped by how something looks before interaction. This is important because not everyone uses a pointing device, like a mouse.</p>
<p>This is why, for example, <a href="http://danieldelaney.net/checkboxes">checkboxes are never round</a>. This is also why <a href="http://adrianroselli.com/2016/06/on-link-underlines.html">links are typically underlined</a> and given the pointer cursor.</p>
<h2>What the authorities say</h2>
<p>The reason links are given the pointer cursor is because they have weak perceived affordance.</p>
<p><a href="https://msdn.microsoft.com/en-us/library/windows/desktop/dn742466%28v=vs.85%29.aspx">Microsoft’s design guidelines</a> says:</p>
<blockquote>
<p>Text and graphics links use a hand […] because of their weak affordance. While links may have other visual clues to indicate that they are links (such as underlines and special placement), displaying the hand pointer on hover is the definitive indication of a link.</p>
<p>To avoid confusion, it is imperative not to use the hand pointer for other purposes. For example, command buttons already have a strong affordance, so they don’t need a hand pointer. The hand pointer must mean “this target is a link” and nothing else.</p>
</blockquote>
<p><a href="https://developer.apple.com/design/human-interface-guidelines/macos/user-interaction/mouse-and-trackpad/#pointers">Apple’s Human Interface Guidelines</a> says:</p>
<blockquote>
<p>The content beneath the pointer is a URL link to a webpage, document, or other item.</p>
</blockquote>
<p><a href="https://www.w3.org/TR/CSS21/ui.html#propdef-cursor">W3C User Interface Guidelines</a> says:</p>
<blockquote>
<p>The cursor is a pointer that indicates a link.</p>
</blockquote>
<h2>The pointer cursor is for links</h2>
<p>Links are not buttons. Links came along with the web. To help users understand that links are different from buttons and other interactive elements, they are given the pointer cursor.</p>
<p>This is because links open web pages or other downloadable resources without changing data like buttons are likely to do.</p>
<p>And users are also able to right click (or tap and hold on touch devices) to reveal additional options like opening in new windows, copying the address to the clipboard, bookmarking the link and more.</p>
<h2>In conclusion</h2>
<p>Buttons that have the point cursor indicate that the user is interacting with a link when they’re not. If you want to give users feedback on hover you can change the background colour for example.</p>
<p>A well-designed button—that is one that looks like a button—doesn’t need a pointer cursor to help users realise it’s clickable. It should look clickable anyway.</p>
<p>The pointer cursor signifies a link because links have special behaviour that’s worth signifying to users.</p>
<p><a href="https://adamsilver.io/blog/buttons-shouldnt-have-a-hand-cursor-part-2/">Continue to part 2</a>.</p>
<!--
http://ux.stackexchange.com/questions/3788/default-cursor-on-mouse-over-of-a-button-is-not-a-hand-pointer
-->
Always use a label2016-07-01T09:00:01+00:00https://adamsilver.io/blog/always-use-a-label/<p>Labels are often removed from form fields to save space and create a minimal aesthetic. However, <a href="http://uxmyths.com/post/115783813605/myth-34-simple-minimal">minimal doesn’t always mean simple</a>. Labels, in fact, are essential to the user experience because:</p>
<ul>
<li>sighted users can see the instructions.</li>
<li>visually-impaired users can hear the instructions when using a screen reader.</li>
<li>motor-impaired users can easily move focus to the field due to the larger hit area. (Clicking a label moves focus to the field).</li>
</ul>
<p>Let’s take a look at two examples whereby labels are ditched at the expense of users.</p>
<h2>An add to basket form</h2>
<p>Sometimes the first option in a select box is used as a makeshift label. See the ASOS <em>add to basket</em> form for an example:</p>
<div class="image" style="max-width: 400px">
<figure><img src="https://adamsilver.io/assets/images/labels/asos.jpeg" alt=""><figcaption>The select box has no label</figcaption></figure>
</div>
<ul>
<li>This is probably enough for sighted users when an option hasn’t been selected. But, when an option has been selected, it’s hard to understand as is the case with the colour menu shown above.</li>
<li>Motor-impaired users will find it harder to select the field due to the smaller hit area.</li>
<li>Screen reader users will struggle to understand what’s going on because the options are a mix of instructions and options to pick.</li>
</ul>
<h2>A search form</h2>
<p>Single-field forms often rely on placeholder text to provide instructions. You can see the Selfridges search form as an example of this here:</p>
<div class="image" style="max-width: 400px">
<figure><img src="https://adamsilver.io/assets/images/labels/selfridges.png" alt=""><figcaption>The search field is missing a label</figcaption></figure>
</div>
<ul>
<li>Sighted users may be able to manage with this but really <a href="https://adamsilver.io/blog/the-problem-with-placeholders-and-what-to-do-instead/"> placeholders are problematic</a> for many reasons.</li>
<li>Motor-impaired users will find it harder to select the field.</li>
<li>Screen reader users will find it difficult because placeholder text isn’t announced.</li>
<li>If a foreigner wants to translate the page using the browser’s translation routine, the placeholder is ignored.</li>
</ul>
<h2>Summary</h2>
<p>Trying to declutter an interface to reduce noise is a noble goal. But labels aren’t noise. Removing labels to save space causes unnecessary usability problems.</p>
<p>Accomodating a visual label may require extra thought, but that’s our job as designers to make sure the things we make work for everyone.</p>
The problem with placeholders and what to do instead2016-06-16T09:00:01+00:00https://adamsilver.io/blog/the-problem-with-placeholders-and-what-to-do-instead/<p>The <code>placeholder</code> attribute can be used to put hint text inside text inputs. When the user types, the placeholder text disappears to make room for the user’s answer.</p>
<p>Placeholders are popular because they save space and have a minimalist aesthetic. But using placeholder text for labels or even just hint text is problematic.</p>
<p>Here I’ll explain why that is and what you can do instead.</p>
<h2>1. They’re hard to remember</h2>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-placeholders-and-what-to-do-instead/remember.png" alt=""><figcaption>Placeholder disappears when typing</figcaption></figure>
</div>
<p>Placeholder text disappears when the user starts typing which means users have to remember the instructions while they’re trying to answer.</p>
<p>Users may need to delete their answer to check the instruction. This takes time and adds cognitive load.</p>
<h2>2. They don’t have full support</h2>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-placeholders-and-what-to-do-instead/support.png" alt=""><figcaption>Broken for browsers lacking support</figcaption></figure>
</div>
<p><a href="http://caniuse.com/#feat=input-placeholder">In browsers that lack support for placeholders</a> users won’t see any instructions.</p>
<h2>3. Fields lack clarity once answered</h2>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-placeholders-and-what-to-do-instead/populated.png" alt=""><figcaption>Populated fields lack clarity</figcaption></figure>
</div>
<p>When a field has been answered it’s not clear what the value relates to or if it meets the formatting requirements.</p>
<h2>4. It’s hard to check answers</h2>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-placeholders-and-what-to-do-instead/review.png" alt=""><figcaption>Checking answers is difficult</figcaption></figure>
</div>
<p>Some users check their answers before submitting them. As the placeholder text is no longer available, it’ll be hard to check their answers against the requirements.</p>
<h2>5. Errors are harder to fix</h2>
<p>Label and hint text helps users answer the question. An error message without these can make errors harder to fix.</p>
<h2>6. Some browsers hide them when the input is focused</h2>
<p>Some older browsers hide placeholder text as the input is focused. This means the user has to read ahead of the current field to see the hint.</p>
<h2>7. They may be mistaken for an answer</h2>
<p>Placeholder text has a lower contrast to signify it’s not user input. But this is subtle which means <a href="http://www.uxmatters.com/mt/archives/2010/03/dont-put-hints-inside-text-boxes-in-web-forms.php">users can mistake the hint for an actual answer</a>.</p>
<p>Once they submit the form, the user will have to fix an error that wasn’t their fault.</p>
<p>Some users do notice the text but try to select and delete it. This is frustrating as placeholder text cannot be selected.</p>
<h2>8. They have low contrast</h2>
<p>Placeholder text has low contrast to distinguish it from a user input. But this makes it ineligible for people with visual impairments or if the light causes screen glare.</p>
<h2>9. Some screen readers don’t recognise them</h2>
<p>Some screen readers don’t acknowledge placeholder text making the form inaccessible to screen reader users.</p>
<h2>10. They reduce the the label’s hit area</h2>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-placeholders-and-what-to-do-instead/hitarea.png" alt=""><figcaption>No label means a smaller hit area</figcaption></figure>
</div>
<p>When a label is clicked, its related input is focused. This is useful, especially for users with motor impairments.</p>
<p>The use of placeholder text reduces the hit area of the input.</p>
<h2>11. They crop long text</h2>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-placeholders-and-what-to-do-instead/cropped.png" alt=""><figcaption>Long placeholder text gets cropped</figcaption></figure>
</div>
<p>Long placeholder text gets cropped making it inaccessible.</p>
<h2>12. Some browsers don’t translate them</h2>
<p>Chrome, for example, will fail to translate placeholder text.</p>
<h2>13. They don’t work well with autocomplete</h2>
<p>The browser’s auto-complete routine populates fields automatically. This means users won’t know what the values relate to which makes it hard to check answers.</p>
<h2>14. They look like user input in Window’s High Contrast Modee</h2>
<div class="image">
<figure><img src="https://adamsilver.io/assets/images/the-problem-with-placeholders-and-what-to-do-instead/highcontrast.png" alt=""><figcaption>Placeholder text in Windows 10 High Contrast Mode</figcaption></figure>
</div>
<p>In Window’s High Contrast Mode, placeholder text is given a high contrast color which can be easily mistaken for user input.</p>
<h2>Summary</h2>
<p>Placeholder text saves space at the cost of usability and accessibility.</p>
<p>Instructional text is crucial content that users need to answer questions correctly and easily.</p>
<p>Putting that text above the input gives users access to the content they need, when they need it no matter the situation.</p>
<p>That’s just good design.</p>
How we cut our MVP in half to launch KIDLY2016-05-20T09:00:01+00:00https://adamsilver.io/blog/how-we-cut-our-mvp-in-half-to-launch-kidly/<!-- <div class="image">
<figure>
<img src="/assets/images/kidly.jpg" alt="The team" width="100%">
<figcaption>The team</figcaption>
</figure>
</div> -->
<p>For the last 9 months, we at KIDLY have been designing and building a brand new online shop with the following tagline:</p>
<blockquote>
<p>“The best stuff for baby, all in one place”</p>
</blockquote>
<p>Last week we launched silently to our many early adopters who we call VIPs. To do this we had to cut our original MVP in half.</p>
<p>This has been a challenging process because our founder James, has a hugely ambitious and wonderful vision for KIDLY.</p>
<p>Consider that the ‘Original’ MVP defined over 6 months ago was already a small slice of the vision, this meant that what was a 50% reduction to our MVP to us, probably felt more like a 75% reduction for James.</p>
<p>Let’s put this into context.</p>
<h2>Our ‘Original’ MVP</h2>
<p>Besides the teaser site (to get pre-launch sign ups), the original MVP defined in September 2015, consisted of designing and building a brand new responsive mobile-first bespoke e-commerce site with these features:</p>
<ol>
<li><strong>Browse:</strong> Homepage, category page, sub category page, brand page, brand directory and product pages. Basket page. Each product list page had filters and pagination.</li>
<li><strong>Editorial:</strong> Article list page, article page, articles by tag whereby a tag related to a browse sections of the site and article pages would link to featured products i.e. editorial is weaved into product and vice versa.</li>
<li><strong>Account:</strong> Managing your account, profile, child data, referral schemes, sign in, sign up, forgot password flows, returns flow etc.</li>
<li><strong>Checkout:</strong> Guest and logged in user flows. Capture+ integration for typing addresses. More than one method for delivery. PayPal and standard card integration (using Stripe) and the other usual bits you find in checkout.</li>
<li><strong>Static pages:</strong> About, privacy policy, 404, 500, help and many more.</li>
<li><strong>Credit mechanism:</strong> This included users getting credit for completing their profile, referring friends — then redeeming against their order automatically.</li>
<li><strong>Parent test:</strong> Every single product was sent to a real parent for testing before being added to the site on every product page.</li>
<li><strong>And much more:</strong> things such as Zendesk and Intercom integration. Launching our own brand of KIDLY products. Custom photography for every single product. To start with 1000 products across 18 categories etc.</li>
<li><strong>Admin:</strong> All of the above was to be supported by a rich web application — this included the management of products, categories, brands, articles as well as integration with the warehouse and 2 courier companies.</li>
</ol>
<h2>The original deadline</h2>
<p>Our original launch date was pencilled in for February 2016 and we began working on the MVP in September 2015 with a team of 6 people.</p>
<p>We didn’t manage to launch in February or even get close. It’s worth noting that this was an <em>internal</em> soft target to aim for — <em>not</em> hitting it wasn’t going to matter too much.</p>
<p>But let’s discuss why we didn’t meet the target, because that’s where this gets interesting.</p>
<h2>Why we ‘failed’?</h2>
<p>I put ‘failed’ in quotation marks because it wasn’t a critical failure as such. This is more of a “why we didn’t get as much done as we might have” type thing. Here’s why I think that was:</p>
<h3>1. The original MVP was too big in the first place</h3>
<p>When something is too big, it’s just too big. The problem wasn’t that it was too big, it was that it took us a while to come to terms with that — something I’ll explain shortly.</p>
<h3>2. We had a fixed deadline <em>and</em> a fixed scope.</h3>
<p>You can have either a fixed deadline or a fixed scope but not both. — we inadvertently set ourselves up for failure.</p>
<h3>3. We zoomed into details too early</h3>
<p>Every single piece of copy, pixel and micro interaction was scrutinised over and over. It was near-death by a thousand cuts.</p>
<blockquote>
<p>“Nobody cares about your product as much as you do”</p>
</blockquote>
<p>Instead of designing overall flows, screens and <a href="https://medium.com/swlh/the-nine-states-of-design-5bfe9b3d6d85#.9wrs8ne3o">states</a>, we spent a lot of time zooming in to make things perfect when perfect doesn’t exist.</p>
<p>These details are important to users in the end, but when everything is a priority, nothing is.</p>
<h2>Four weeks to go live</h2>
<p>April was approaching fast. While we cut a few minor items off the backlog it wasn’t enough to stop our t-shirt-sized estimate indicating a July launch date which wasn’t good enough.</p>
<p>This was because we had thousands of VIPs already signed up and eager to buy from us so they could use the credit they had earned through early sign up and referrals.</p>
<p>There were times where we sent our customers elsewhere to buy products until we were ready.</p>
<p>And while we were still motivated we wanted to launch. We weren’t making any money and franjly we wanted to get some feedback beyond low-fidelity prototypes.</p>
<blockquote>
<p>“We have to get this thing live in 4 weeks” — James</p>
</blockquote>
<p>James called a meeting and said “we have to get this thing live in 4 weeks — I don’t care how we do it, it’s important for KIDLY, it’s important for our customers and it’s important for morale.”</p>
<p>This pressure constrained us in a good way. It forced us to prioritise. Ahead of the meeting we prepared a few ideas that might mean we can make it happen.</p>
<p>James said “is everyone happy that we can do this in 4 weeks?” We were silent. Then he asked me (which I wonder about ha). I said the only way we’d deliver something in 4 weeks would be to launch a private beta behind a login for our VIPs.</p>
<p>This went down well and then we kept firing more suggestions at each other. Every reduction and simplification complimented each other. We were ready to start.</p>
<h2>Why launch behind a login?</h2>
<p>Our VIPs already had access to their account page. They could already login, complete their profile, and refer friends. Ensuring users had to be logged in to view the shop had 3 huge benefits:</p>
<ul>
<li>It drastically reduced the complexity of the site as we only needed to cater for logged in states. This meant that we could remove guest checkout from the backlog. We didn’t have to worry about SEO and social sharing, and of course it reduced the amount of development.</li>
<li>We could launch just to our VIPs which would also bring an aire of exclusivity to the experience.</li>
<li>Launching to VIPs meant we reduced the risk and enabled us to receive vital feedback before opening up to the public.</li>
</ul>
<h2>Other suggestions</h2>
<p>Here’s the other big things we suggested:</p>
<h3>1. We halved the amount of products</h3>
<p>Instead of launching with 1000 products we decided it would be okay to launch with less than 500.</p>
<p>This halved the effort required to produce and upload content. This included copywriting, photography, uploading product information and testing every product. And of course ensuring that we had enough stock for each of those products when they went on sale.</p>
<p>It also meant we could reduce the complexity of the site. For example we no longer needed sub categories, filtering or pagination as there was going to be less than 40 products in each category.</p>
<h3>2. We removed brand pages</h3>
<p>Brand pages are a nice-to-have feature but we still took the option to cut these out. In doing so we removed “super” brand, “simple” brand and brand directory pages. This also meant a simplified navigation where customers could only shop by category. Easy.</p>
<h3>3. No PayPal</h3>
<p>This was a difficult decision for us as we know how important PayPal is to increasing conversion in checkout. We already had to integrate Stripe and just didn’t have the capacity for this. It’s high up on the post launch backlog though.</p>
<h2>We did it in 5 weeks</h2>
<p>In the end we launched in 5 weeks but that was down to a third party courier not being able to test return labels in time to start shipping. We achieved what felt impossible due to a clear focus on what was most important.</p>
<h2>What our customers said</h2>
<p>We have had some wonderful feedback from our VIPs:</p>
<blockquote>
<p>“Love the site, really easy to navigate and ordering was a doddle, my face normally sinks if PayPal isn’t involved but checkout was so quick.”</p>
</blockquote>
<blockquote>
<p>“So so pleased with the speed of delivery, honestly didn’t expect them to arrive so quickly. So far so good on the website, I love the layout, the clean lines, and ease of use.”</p>
</blockquote>
<blockquote>
<p>“Awesome imagery, love the list of products with the big photos and the Ideas section. And many products look gorgeous.”</p>
</blockquote>
<h2>Results</h2>
<p>We have had a good sales rates (can’t disclose numbers) and a phenomenally successful conversion from basket at 26%.</p>
<p>This is still early days and these stats are based on low numbers overall, but early signs are great. Especially considering that we haven’t even told all of our VIPs that we’re open yet — we staggered the announcement, again to reduce risk.</p>
<h2>What did we learn?</h2>
<p>Here are all the things we learnt from this experience:</p>
<h3>1. Everyones idea of MVP is different</h3>
<p>James’ idea of MVP and my idea of MVP are different. We often disagreed on macro and micro aspects of the product but that’s to be expected not only because we are different people but because we are bound to see Kidly from different perspectives.</p>
<p>James is running an entire company and bringing every piece of the puzzle together. He has to consider the overall vision at all times during every small and large decision.</p>
<p>Couple that with the aim to provide a level of service to rival Amazon and you start to understand reducing various parts of an MVP is difficult.</p>
<p>For me it was more about getting an MVP in front of users as soon as possible because the real feedback on product design starts then. So I was happier to kill off features.</p>
<p>Ultimately, what is right for Kidly is somewhere in between. There is no “right” or “wrong” MVP — you just have to get your team on the same page quickly.</p>
<h3>2. “Good enough” is good enough</h3>
<p>During the first few months at Kidly James gave us <em>Rework</em> by Jason Fried, to read. In it there is a chapter explaining the concept of “Good Enough”.</p>
<p>If you can accept early on that perfect doesn’t exist, you can get the macro things done earlier. This in turn is good for momentum and morale because as a team you feel like your moving forwards quickly. Without momentum you can lose motivation.</p>
<p>If you avoid details early on then you get to have a rough copy of your product holistically. This is beneficial because a product is normally experienced as a whole not in piecemeal.</p>
<p>If it feels wrong holistically you can rectify without destroying the detail. If it feels right you can go ahead and dive into the detail. Win Win.</p>
<h3>3. Bite off half of what you think you can chew</h3>
<p>Whatever you think you are capable of achieving, stop and remove 50% of it. Get rid of the other half until the first half is complete.</p>
<h3>4. Give your teams problems to solve, not solutions to adopt.</h3>
<p>When it came to it, James gave us a difficult problem to solve and empowered us to make it work. There is nothing like challenge, accountability and trust to unite a team and set yourself up for success. James showed great leadership which lead us to success quickly.</p>
<h3>5. It’s either a fixed deadline or a fixed scope, not both!</h3>
<p>That’s all on that.</p>
<h3>6. Pressure forces you to think creatively</h3>
<p>Pressure can ignite a team to think differently, and accept the (what might have previously been deemed) unacceptable. I didn’t think we’d launch in 4 weeks and I didn’t think we could cut down the MVP but we did.</p>
<h3>7. A lack of features is a very good thing</h3>
<p>If you go by the feedback, sales and conversion, it would be easy to think that the product is great as it is — that’s because it <em>is</em> great as it is — even with half an MVP. It just goes to show that <em>less</em> is often <em>better</em>.</p>
<h2>What’s next for Kidly?</h2>
<p>To be expected after launch, we’ve been fixing bugs and improving UX but now we’re starting the next big phase of Kidly — going public.</p>
<p>We will be taking everything we have learnt with us, continuing to make parents lives easier, by bringing you the best stuff for your baby all in one place.</p>
<p><a href="http://kidly.co.uk/">See Kidly</a>.</p>
Everything I know about speaking at conferences2016-04-01T09:00:01+00:00https://adamsilver.io/blog/everything-i-know-about-speaking-at-conferences/<p>I spent almost 2 months preparing to speak at <a href="http://enhanceconf.com/">Enhanceconf<br>
2016</a> in front of 180 people at the RSA in London.</p>
<p>I never thought I would speak publicly — mostly because it’s bloody scary. But I decided it was time to do something out of my comfort zone.</p>
<p>So to prepare I read up on how to give a good talk from all sorts of places. And after making a few mistakes on the day, I thought I’d jot down some useful tips for next time.</p>
<h2>Before accepting the invitation</h2>
<h3>1. Choose a conference that aligns with your values</h3>
<p>Enhanceconf was a conference all about progressive enhancement. As a topic dear to me, even if I mucked up, at least I know the audience would be interested in my philosophy which made it a little less scary.</p>
<h3>2. Choose a topic you care about</h3>
<p>Maybe this is obvious but I went back and forth on things I could talk about. But in the end I talked about something I’m really passionate about. I think that’s something the audience can really feed off.</p>
<h3>3. Choose the right duration</h3>
<p>All Ted talks are somewhere between 15 and 20 mins because people can’t concentrate for longer than that. And if you can’t get your point across in that time then there’s a chance you’ll lose the attention of the audience.</p>
<h3>4. Give yourself time to prepare and start early</h3>
<p>I cleared my schedule for 2 months. Preparation is everything.</p>
<h3>5. Get paid around 5 times the ticket price</h3>
<p>I read in a few places that you should expect to get paid 5 times the price of a ticket. I didn’t actually negotiate but if you’re reading this, you can.</p>
<p>In reality it’s just about experience and spreading good ideas. But worth bearing this in mind.</p>
<h2>After accepting the the talk</h2>
<h3>1. Get a Kensington clicker</h3>
<p>You want to be able to move around the stage—not tired to your computer fumbling to move to the next slide. The Kensington clicker is good value and really good.</p>
<h3>2. Design your slides last</h3>
<p>Slides should be props. Nail the script first, then add slides as an enhancement.</p>
<h3>3. Write down your ideas</h3>
<p>Write down ideas as they pop into your head. Good ideas come to me in the shower or on a run or on my commute. Jot it down before you forget.</p>
<h3>4. Work out the why of your talk</h3>
<p>Work out the why first. Then you can work out how you’ll support that message.</p>
<h3>5. Start writing</h3>
<p>Find quiet time and make a start.</p>
<h3>6. Tell stories first</h3>
<p>Tell personal or other people’s stories to convey your message. Make sure the stories come first. Make sure they take up one third of your talk. This helps to connect emotionally to your audience.</p>
<h3>7. Practice early and out loud</h3>
<p>Start practicing early, even before the script is perfect. Words on paper and words out loud are different. It’ll help nail the script.</p>
<p>Refine and practice over and over. And get to the pint where you’re focused on delivery, not on the actual words.</p>
<h3>8. Tell something new or put your spin on it</h3>
<p>Lots of things have been talked about before but nobody is you. You can put a spint on it and tell a personal story that your audience has never heard before.</p>
<h3>9. Deliver stats later in the talk</h3>
<p>After telling stories, add stats to back up your message.</p>
<h3>10. Deliver a jaw dropping moment if you can</h3>
<p>You want to have some slides that your audience will reeally remember. It could be an amazing stat, a phrase, or anything else really.</p>
<h3>11. Don’t put lots of text on a slide</h3>
<p>This is my favourite tip. Lots of text is hard to read and the audience cannot listen to you and read the text at the same time.</p>
<h3>12. Be you</h3>
<p>This means act like you, speak like you. Get up there and chat with the audience.</p>
<h3>13. Watch other talks for inspiration</h3>
<p>I learnt from other people’s talks in my field as well as Ted talks. Watch what they do and try and use things that you think can help you. One tip I noticed was putting my spare hand in my pocket. This felt really comfortable and made me look relaxed (which I wasn’t).</p>
<h2>On the day of your talk</h2>
<h3>1. Arrive early</h3>
<p>Make enough time to arrive. Don’t start the day stressed.</p>
<h3>2. Find the bathroom</h3>
<p>I needed to go a lot. Find the bathroom.</p>
<h3>3. Travel light</h3>
<p>Bring your essentials, I brought too much stuff “just in case”, but I should<br>
have only brought my clicker (and spare batteries), my laptop and my charger.</p>
<h3>4. Check out the stage</h3>
<p>I was on in the afternoon, but I checked out the stage early to get a feel for things so it was less overwhelming by the time I did my talk.</p>
<h3>5. Bring a friend for support</h3>
<p>Having a friend really helped relax me. Maybe it’ll help you too.</p>
<h3>6. Speak to other people and speakers</h3>
<p>I found chatting to other presenters calmed me down. And they’re all nervous like you so it’s good to compare the jitters.</p>
<h3>7. Don’t eat too much or too little</h3>
<p>I felt too nervous to eat and I ended up with a headache. Work out your timings give yourself at least 1 hour to eat before you’re on.</p>
<h3>8. Do sound checks early</h3>
<p>My slot was in the afternoon so while people were at lunch I was on the stage making sure my computer hooked up to the projector and that my mic worked.</p>
<h3>9. Drink some water just before you start</h3>
<p>I got a really dry mouth as soon as I started which makes it hard to talk. So drink some water before you start.</p>
<h3>10. Bring water on stage</h3>
<p>I left my water off stage like an idiot. So I had to jump off stage for a few seconds to drink some water which made me feel awkward. Don’t do that.</p>
<h2>After your talk</h2>
<ol>
<li>Thank the organiser</li>
<li>Speak to people</li>
<li>Grab a snack</li>
</ol>
<h2>The next day</h2>
<ol>
<li>Post your <a href="https://adamsilver.io/blog/embracing-simplicity">transcript</a></li>
<li>Upload your slides to <a href="https://noti.st/adamsilver">Noti.st</a></li>
<li>Share the video on Twitter</li>
<li>Thank the people who helped you</li>
</ol>
Embracing simplicity2016-03-06T09:00:01+00:00https://adamsilver.io/blog/embracing-simplicity/<p>This is the talk I gave at <a href="http://enhanceconf.com/">Enhanceconf</a> 2016, a conference dedicated to Progressive Enhancement.</p>
<iframe width="100%" height="515" src="https://www.youtube.com/embed/UlzG6-fI00g" frameborder="0" allowfullscreen=""></iframe>
<!-- <div class="image">
<figure>
<img src="/assets/images/enhance/enhanceconf.jpg" alt="Enhanceconf Q&A" width="100%">
<figcaption>Photo by <a href="https://www.flickr.com/photos/psd/">Paul Downey</a></figcaption>
</figure>
</div> -->
<p>You can view my <a href="https://speakerdeck.com/adamsilver/embracing-simplicity">presentation slides</a> and the transcript for the video is below.</p>
<h2>Transcript</h2>
<p>I want to start by using our imagination.</p>
<p>I want you to imagine your life with less.</p>
<p>Less tooling. Less libraries. Less frameworks. Less debugging. Less noise. Less debates.</p>
<p>Less bullshit.</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/enhance/bullshit.jpg" alt="Enhanceconf Q&A" width="100%">
<figcaption><a href="http://deathtobullshit.com/">Death To Bullshit</a></figcaption>
</figure>
</div>
<p>The kind of bullshit <a href="http://bradfrost.com/">Brad Frost</a> talks about. Less of the superfluous. Less of the unnecessary. Less of the unnecessarily complex.</p>
<p>All of this while browsers get better and connections get faster, with no effort on your part whatsoever.</p>
<p>What you might be imagining is a more straightforward tech stack, particularly on the front-end side. And maybe a better experience — one that embraces the web and its conventions, rather than one that tries to trample all over it or enhance it too much.</p>
<p>With all of this complexity out of the way we would be able to focus on the basics which might just make the biggest difference to our product and make our lives as designers and developers a little easier too.</p>
<p>I’ve always been obsessed with simplicity, I think as designers and developers we have simplicity somewhat baked into us. We just need to unlock it.</p>
<p>One early memory I have of this was when I was 15 or 16 years old revising for my maths GCSE.</p>
<p>When it was time to revise I would find the quietest place in our house which was our dining room. We had this large dining table — it could seat 10 or so people.</p>
<p>I would go in there with just my essentials: my calculator, pencil case and mock exam paper. Even though I only needed a small part of this table, I would declutter the physical space so that I could declutter my mental space.</p>
<p>Today, this is what my desktop looks like…</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/enhance/desktop.jpg" alt="My desktop" width="100%">
<figcaption>My desktop</figcaption>
</figure>
</div>
<p>Clutter free. I am an Alfred keystroke away from my favourite application.</p>
<p>And, this is what my home screen looks like…</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/enhance/homescreen.jpg" alt="My homescreen" width="100%">
<figcaption>My homescreen</figcaption>
</figure>
</div>
<p>Clutter free again, and my most used apps in close proximity to my thumb.</p>
<p>And when I am at work, I meticulously close down program after program after I have finished using it which gives me two benefits on the same theme. The first is that I only have open what I need allowing me to focus. The second is that the computer works better when it’s doing less.</p>
<p>So when we’re both doing less, we both work better.</p>
<p><strong>Now, web design and development is hard. How can we make it simpler for ourselves and for our users?</strong></p>
<p>It’s true that simple is <em>complicated</em> but sometimes simple is <em><strong>simple</strong></em>.</p>
<p>And it’s this latter variety of simple that I want to focus on today because I think that’s what we’re missing. I think there is a huge opportunity to do the simple things and get big results.</p>
<p>Now, you might be wondering about what all this has to do with Progressive Enhancement?</p>
<p>Well, Progressive Enhancement revolves around people. People consuming an experience or people designing and building an experience to be consumed. And if there is one thing I know about people it’s that we love complicated.</p>
<p>We hone in on complicated and skip the basics and I recently came across a story with the same theme that I want to share with you…</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/enhance/gawande.jpg" alt="Atul Gawande" width="100%">
<figcaption>Atul Gawande, Professor of Surgery, Harvard Medical School</figcaption>
</figure>
</div>
<blockquote>
<p>Atul Gawande, Professor of Surgery, Harvard Medical School<br>
This is Atul Gawande. He is the professor of surgery at Harvard Medical School.<br>
<br><br>The World Health Organisation asked him to help reduce the number of deaths during surgery.<br>
<br><br>Did we need more training or more technology?<br>
<br><br>Gawande found they were looking in the wrong place.<br>
He talked to experts in other high-risk professions, such as aviation.<br>
<br><br>What he discovered was that there are usually three main problems.<br>
<br><br>1) Problems of ignorance.<br>
<br><br>2) Problems of technology.<br>
<br><br>3) Problems of ineptitude.<br>
<br><br>All surgical attention had been focused on the first two.<br>
<br><br>They had solved the problem of ignorance: the average surgeon now had ten to 15 years of training.<br>
<br><br>They had solved the problem of technology: surgeons performed up to 4,000 different procedures and prescribed up to 6,000 drugs.<br>
<br><br>But, unlike the aviation industry, they had ignored the third problem.<br>
<br><br>The problem that highly skilled people often make basic mistakes.<br>
<br><br>In the airline industry, this was covered by checklists.<br>
<br><br>Before any pilot takes off, he and his co-pilot run through a checklist.<br>
<br><br>“Brakes — set. Autopilot — disconnected. Fuel level — set”<br>
<br><br>Double-checking the absolute basics don’t get overlooked.<br>
<br><br>Gawande recommended checklists before surgical procedures.<br>
<br><br>Reading aloud and checking off the basics:<br>
<br><br>“Patient’s identity. Name and area for procedure. Known allergies”<br>
<br><br>At first, surgical staff resisted because it felt demeaning.<br>
<br><br>But then the results came in.<br>
<br><br>At the end of the trial, death rates across the hospitals tested had fallen by 47 per cent.<br>
<br><br>If they had seen that result from any drug or technology, it would have been hailed as a miracle cure.<br>
<br><br>But, here, the result came by checking the most basic things.<br>
<br><br><strong>Because the basics were actually the most important of all.</strong><br>
<br><br>It’s a normal human reaction to forget the importance of getting the basic things right.<br>
<br><br>Human beings get <strong>seduced by complexity</strong>.</p>
</blockquote>
<p>Which is exactly what’s happening in our industry. We’re so hypnotised by complexity, we forget the basics.</p>
<p>We’re so busy worrying about the Javascript this, the framework that, the AJAX, the carousel etc.</p>
<p>We’re often just rebuilding the same thing we did last year, this year in a new technology or architecture, and I am not sure this is adding value.</p>
<p>Now, there are many reasons we do complicated. I want to share two interesting ones with you today.</p>
<p>The first reason is <strong>contribution</strong>.</p>
<p>We feel that if we put a lot of effort in, then we get a lot of value out but this is often not the case.</p>
<p>And to demonstrate, I want to share with you a portion of an article I read recently by my friend <a href="http://www.theluckystrike.co.uk/embracing-simplicity/">Mark Jenkins</a>, a designer here in London. It’s entitled “<a href="https://medium.com/simple-human/contribution-3dff1af38ba4#.nl9814tbr">Contribution</a>” and it’s a tale of two designers —** Designer A** and <strong>Designer B</strong>.</p>
<blockquote>
<p><strong>Designer A</strong> spends an hour of their time making 5 screens because they know they need to design 5 screens. They’re not trying to change the world, they achieve what they set out to do.<br>
<br><br><strong>Designer B</strong> takes an entire day to make one screen because they are obsessed with moving pixels, but they are stuck. They can’t let go.<br>
<br><br>They end up doing less because of their own insecurities about their contribution.<br>
<br><br>They create the same thing over and over, they end up with unfinished design(s) or they go right back to the beginning.<br>
<br><br><strong>Designer A</strong> understands that there’s no ‘perfect’.<br>
<br><br><strong>Designer B</strong> believes ‘perfection’ exists, their belief of perfect is jaded by their own inability to understand the solution to the problem.<br>
<br><br>In some cases, they are making a solution for a non existent problem.<br>
<br><br><strong>Designer A</strong> thinks (differently).<br>
<br><br><strong>Designer B</strong> overthinks.<br>
<br><br><strong>Designer A</strong>’s contribution is greater because they think about the necessary.<br>
<br><br><strong>Designer B</strong>’s contribution is lower because they think about the unnecessary.<br>
<br><br><strong>Designer B</strong> is a blocker. To themselves (and the rest of their team).<br>
<br><br><strong>Designer B</strong> relies on what they know.<br>
<br><br><strong>Designer A</strong> relies on what they don’t know.<br>
<br><br><strong>Designer A</strong> releases early to learn. Then goes back to improve.<br>
<br><br><strong>Designer B</strong> releases late. They learn less because they believe they have perfected something, without testing.<br>
<br><br><strong>Designer A</strong> works with context.<br>
<br><br><strong>Designer B</strong> has no context.<br>
<br><br><strong>Designer A</strong> learns.<br>
<br><br><strong>Designer B</strong> thinks they don’t have to learn.<br>
<br><br>Both A and B are designers. However, there is a HUGE difference between the two of them.</p>
</blockquote>
<p>And I guess if I wanted to sum this up nicely for you it would be that value only has a value when it’s value is valued.</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/enhance/value.jpg" alt="Value only has a value when it's value is valued" width="100%">
</figure>
</div>
<p>And in the case of enhancements, I am not so sure all the enhancements we go about adding are creating better experiences.</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/enhance/boots.jpg" alt="Boots logo" width="100%">
</figure>
</div>
<p>One example I have of this was when I was working on Boots.com back in 2008, in particular their checkout flow. It was designed as a single page checkout.</p>
<p>It had all the enhancements including Accordions, AJAX, client-side validation, no page refreshes. As you go through each step, the accordions would expand and collapse.</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/enhance/boots_single.jpg" alt="Boots.com single-page checkout diagram" width="100%">
<figcaption>Boots.com single-page checkout diagram</figcaption>
</figure>
</div>
<p>We put in so much effort upfront in order to design, build, test, release and finally user test. When we did, we found out that it didn’t work well at all. The effort we put in was far greater than the value we got out.</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/enhance/boots_page.jpg" alt="Boots.com multi-page checkout diagram" width="100%">
<figcaption>Boots.com multi-page checkout diagram</figcaption>
</figure>
</div>
<p>So we ended up reverting to the basics. Each accordion step became it’s own page with very few enhancements. And the results were extremely positive.</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/enhance/justeat.jpg" alt="Just Eat logo" width="100%">
</figure>
</div>
<p>And as history repeats itself, almost 6 years later, I was working at Just Eat. We had a single page checkout too and we were tasked with improving conversion within the checkout flow.</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/enhance/justeat_checkout.jpg" alt="Multi-page checkout on Just Eat" width="100%">
<figcaption>Multi-page checkout on Just Eat</figcaption>
</figure>
</div>
<p>So we did the same thing. We put each step onto its own page. Each page had plenty of white-space. Each page had a page refresh. And there was a very clear single focus per page. There was a sprinkling of client-side form validation to save a server round-trip.</p>
<p>All of this resulted in almost 2 million extra orders per year. That’s orders, not revenue.</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/enhance/twomillion.jpg" alt="Two million extra orders per year" width="100%">
</figure>
</div>
<p>And this is what 2 million people look like.</p>
<p>Everyone benefited. The business and the users clearly benefited.</p>
<p>You could say that I became less marketable because my CV was far less “wow” — instead of “Built rich single page checkout with all the fancies”, it became “Built 4 web pages with a form on each”.</p>
<p>But it’s a little but like how the surgeons found it demeaning to do the most basic things and we saw what results they achieved. And afterall, it’s not about me or my CV, it’s about the results and the human being at the end of them.</p>
<p>Then comes <strong>technology</strong>…</p>
<p>Technology is easy to complicate. One very simple example of this is the use of Jekyll. For those unaware, Jekyll is a static website generator written in Ruby. It’s geared towards blogs so it basically produces a bunch of articles where each article is made of some simple HTML.</p>
<p>It’s great because it is just static, has no moving parts. No need for an application server and to note I use it myself.</p>
<p>The problem comes when we want to add dynamic content such as comments.</p>
<p>What I typically see is the use of Disqus, a Javascript library that asynchronously loads and injects comments in as an enhancement.</p>
<p>And of course this type of enhancement has many failure points and when it does fail there are no comments. Now, you could say that this is an acceptable degradation point in that at least everyone gets the article.</p>
<p>But if you think about it, comments can be really valuable and a comment is just text like the article itself. So ultimately this type of enhancement is completely unnecessary and detrimental to the user experience.</p>
<p><strong>So why do we do this?</strong></p>
<p>We do this because it makes our lives as developers easier — it’s so easy to throw a piece of Javascript at it.</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/enhance/problem.jpg" alt="Make it your problem, not your users." width="100%">
</figure>
</div>
<p>But ultimately we have put our needs before the needs of the user which as <a href="https://adactio.com/links/10335">Jeremy Keith</a> says…</p>
<blockquote>
<p>If I had to choose between making something my problem and making something the users problem, I would make it mine every time.</p>
</blockquote>
<p>And this for me is bang on.</p>
<p><strong>So what can we do with just the basics?</strong></p>
<p>Well I have already alluded to this somewhat with the Boots and Just Eat case studies. But I am thinking about text, links, forms, pages, headings, paragraphs etc.</p>
<p>And if we hone in on just text for a moment…</p>
<p>Is the copy legible? Are we choosing the right font? The right font-size, letter spacing, line height? Are we humanising our copy, making it appropriate for the audience? Have we got too much or too little text? Are we showing it at the right time.</p>
<p>You see, there is so much to explore with just the basics.</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/enhance/essential.jpg" alt="Mobile first is really just essential only" width="100%">
</figure>
</div>
<p>I am also thinking mobile first, which to <em>me</em> just means small screen first, which to me just <em>really</em> means essential first, which to me just really <em>really</em> means essential only.</p>
<p>And this has been a real boon for the industry because it has forced us to cater for small screens and picking what is truly essential to the experience which scales up easily to big screens.</p>
<p><strong>We must stop fearing the page refresh and stop fearing white space.</strong></p>
<p>When we trim the fat for all, and when we build these things in the right way the page refresh (something we have always had) goes unnoticed and can be responsible for some amazingly simple experiences.</p>
<p>And I am not saying that we should oversimplify, nor that there isn’t a place for complicated. But if “ten” is complicated, and “one” is simple, we spend way to much time near the ten mark and I think we need to bring it closer to one at least by default.</p>
<p>With regards to Progressive Enhancement…</p>
<p>Progressive Enhancement is not a prescription to enhance. It’s a wonderful strategy should we determine that an enhancement is going to add value. We don’t actually have to enhance — we can choose not to.</p>
<p><strong>So how might we get this into our everyday processes?</strong></p>
<p>We all know the benefits of iterative development and user-testing and I think Progressive Enhancement lends itself perfectly to this.</p>
<p>I suggest we design and develop the core experience. Then release and test with users. At this point, you might find that this core experience is all that is needed. Great — move on to the next feature.</p>
<p>If it doesn’t work well enough, we can iterate. I suggest we practice thoughtful reduction rather than mindless addition by exploring the basics a little deeper. If it works now, great — now move on.</p>
<p>If this still doesn’t work you have my permission to enhance.</p>
<p>But the great thing here is that you have delivered little and often, learnt little often which is great for team morale and momentum. And of course we know along the way that our effort is adding value in terms of team knowledge and product user experience.</p>
<p>It is also great because it can reduce the emotional attachment we are prone to. As designers and developers if we put a lot of upfront effort in then we get more attached to our work. If we let the results do the talking, then we remove this problem which again is great for morale and momentum.</p>
<p>And small steps can result in small wins, and small wins are worth celebrating.</p>
<p>But small steps can result in big wins, which are again well worth celebrating.</p>
<p>Ultimately, this is what I want for us, this is what I want for the industry, and this is what I want for our users.</p>
<hr>
<p><em>It was a pleasure to speak and share my knowledge and experiences alongside the others who were there: <a href="https://twitter.com/thatnatbuckley">Nat Buckley</a>, <a href="https://twitter.com/anna_debenham">Anna Debenham</a>, <a href="https://twitter.com/stilkov">Stefan Tilkov</a>, [Forbes Lindesay](Forbes Lindesay), <a href="https://twitter.com/OliverJAsh">Oliver Joseph Ash</a>, <a href="https://twitter.com/StuCoxMedia">Stu Cox</a>, <a href="https://twitter.com/philhawksworth">Phil Hawksworth</a>, <a href="https://twitter.com/bruised_blood">Stephen Waller</a>, <a href="https://twitter.com/jensimmons">Jen Simmons</a>, <a href="https://twitter.com/USA2DAY">Robin Christopherson</a>, <a href="https://twitter.com/radiomorillo">Stephanie Morillo</a>, <a href="https://twitter.com/AaronGustafson">Aaron Gustafson</a> and <a href="https://twitter.com/adactio">Jeremy Keith</a>.</em></p>
<p><em>Finally I want to thank <a href="https://twitter.com/simonmcmanus">Simon McManus</a> for inviting me to talk and a brilliantly organised conference — thank you!</em></p>
Design is not just how it looks2016-01-08T09:00:01+00:00https://adamsilver.io/blog/design-is-not-just-how-it-looks/<p>According to Paul Adams there are <a href="https://medium.com/intercom-inside/how-to-hire-designers-960663e3a3e6#.5het3jvgw">4 aspects to design</a>: outcome, system, interaction and visual.</p>
<p>Unfortunately, I think we often focus our attention on the visual side of things.</p>
<p>This can create all sorts of different usability issues.</p>
<p>Here I‘ll share some of the most common examples of this and why it’s problematic.</p>
<h2>1. Making buttons and links look the same</h2>
<p>There are quite a few reasons why we make <a href="https://adamsilver.io/blog/but-sometimes-buttons-look-like-links/">buttons and links look the same</a>.</p>
<p>But if we do, we’ll cause problems for some users.</p>
<p>For example, screen reader users would not see a link (which is a button styled like a link) in their list of links menu – even though they can see a link on screen.</p>
<p>If we know there are problems, then it’s our job to solve them.</p>
<h2>2. Disabling focus styles</h2>
<p>Sometimes the focus style is disabled because it’s ugly.</p>
<p>But good design means making users know where the focus is so they can orientate themselves accordingly.</p>
<p>Maybe even take this as an opportunity to design custom focus styles.</p>
<h2>3. Having small touch targets on desktop on the basis that most people use a mouse</h2>
<p>There are lots of large screen devices that are touch-enabled like the iPad Pro.</p>
<p>But even if that wasn’t true, large tap targets help all users including mouse users.</p>
<p>Especially those with fine motor impairments.</p>
<h2>4. Hiding buttons on small screens on the basis that mobile users swipe</h2>
<p>Firstly, not all small screens are mobile devices. You can have small desktop monitors or have two applications running side by side.</p>
<p>Secondly, not every small screen device supports gestures.</p>
<p>Thirdly, not all users are aware of gestures or know they’re available to use.</p>
<p>Giving users buttons makes things obvious for everyone no matter what.</p>
<h2>5. Checking colour contrast on a Macbook pro</h2>
<p><a href="https://backchannel.com/how-the-web-became-unreadable-a781ddc711b6#.c9zxfsiep">Low contrast text is unreadable</a>.</p>
<p>Content must be legible for it to be usable and so it’s vital colour contrast meets certain accessibility criteria.</p>
<h2>6. Removing labels to save space and keep things minimal</h2>
<p>There are very few cases where it’s okay to forgo a visible label.</p>
<p>We know <a href="https://adamsilver.io/blog/always-use-a-label/">labels are important</a> so we should make room for them from the outset.</p>
<h2>7. Providing high resolution images on the basis that most users have a fast connection</h2>
<p>A lot of people are interested in your service that don’t have high speed internet connections.</p>
<p>Even for people who do, sometimes they’ll be on slow, patchy connections.</p>
<p>Making services lightweight for all, <a href="https://adamsilver.io/blog/4-steps-to-design-fast-experiences/">makes the slow fast, and the fast super fast</a>.</p>
<h2>8. Assuming everyone has cutting edge JavaScript</h2>
<p>While most people have JavaScript enabled, not all do.</p>
<p>And in reality, it’s more about <a href="https://kryogenix.org/code/browser/why-availability/">visits than it is about users</a>.</p>
<p>Things go wrong which means good design means designing for when things fail.</p>
<p>If we know that <a href="https://adamsilver.io/blog/javascript-isnt-always-available-and-its-not-the-users-fault/">some people won’t have JavaScript</a> we should <a href="https://adamsilver.io/blog/progressively-enhanced-javascript/">design experiences for those with and without it</a>.</p>
<h2>9. Disabling zoom</h2>
<p>Disabling zoom on mobile browsers stops users who have poor vision from being able to read content.</p>
<p>Even users with good vision may like to zoom in on certain details depending on the situation.</p>
<p>Disabling zoom takes control away from users whereas good design gives users control.</p>
<h2>10. Reducing the amount of words so they fit the layout</h2>
<p>Users don’t visit websites for the perfectly aligned grid.</p>
<p>They come for the content and the service your provide.</p>
<p>Cutting words at the cost of clarity hurts the user experience.</p>
<p>Instead, design with realistic content so that users can consume it in the best possible way.</p>
<h2>11. Justifying something because someone else does it</h2>
<p>So many popular organisations like Google and Apple give users slow and inaccessible experiences.</p>
<p>Pointing to them as reason to use a contentious problematic pattern is not reason at all.</p>
<p>Instead, we should crit design on merit and not on authority or popularity.</p>
<h2>In conclusion</h2>
<p>Design is so much more than how it looks.</p>
<p>Visual design is important and should compliment the experience, not hinder it.</p>
<p>Our job is to marry all aspects of design together in order to provide a good experience for everyone.</p>
<p><em>If you know of other similar examples like this, please let me know.</em></p>
Hover menus are problematic2015-12-27T09:00:01+00:00https://adamsilver.io/blog/hover-menus-are-problematic/<p>Hover menus open and close when the user moves their mouse over or out of a menu.</p>
<p>Despite their popularity they have several downsides.</p>
<p>Here, I’ll explain what they are and what to do instead.</p>
<h2>1. They’re easy to open by accident</h2>
<p>Hovering the cursor over part of the interface is not an intention to activate it. Technically speaking, users are always hovering.</p>
<p>If a user moves the cursor across a menu it’ll open by accident, obscuring content beneath and disrupting the user’s intended action.</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/hover-menus/open-by-accident.gif" alt="" width="100%">
<figcaption>User moves across the menu which uninitentionally opens it</figcaption>
</figure>
</div>
<p>Even worse—if the intended action is to click an in-page link, when the menu opens the user could accidentally click a menu item instead.</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/hover-menus/click-by-accident.gif" alt="" width="100%">
<figcaption>User uninitentionally clicks menu item</figcaption>
</figure>
</div>
<p>You can solve this problem by adding a small delay before opening the menu, but this makes it feel unresponsive. And the menu could still be opened accidentally if the user happens to rest the cursor there.</p>
<h2>2. They’re easy to close by accident</h2>
<p>Once the menu is opened, the user has to keep the cursor within the bounds of the menu to stop it from closing. This is especially hard for people with motor impairments.</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/hover-menus/close-by-accident.gif" alt="" width="100%">
<figcaption>User accidentally closes the menu</figcaption>
</figure>
</div>
<h2>3. They’re difficult to operate with accuracy</h2>
<p>Moving the cursor directly and diagonally to the sub menu may cause it to close accidentally or activate a different sub menu.</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/hover-menus/another-menu-by-accident.gif" alt="" width="100%">
<figcaption>User tried to move the cursor diagonally to the sub menu but activated a different menu by accident.</figcaption>
</figure>
</div>
<p>To reliably activate the intended sub menu, users have to carefully and unintuitively move their cursor down and across. This is known as a hover tunnel.</p>
<h2>4. They don’t work with keyboard or touch devices</h2>
<p>Menus that open on hover exclude users who use a keyboard or touch device.</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/hover-menus/keyboard.gif" alt="" width="100%">
<figcaption>You can't open the menu with keyboard and hover.</figcaption>
</figure>
</div>
<h2>Open the menu on click</h2>
<p>To avoid the problems above let users open a menu when they click the menu.</p>
<p>Not only does it <a href="https://inclusivedesignprinciples.org/#give-control">give users control</a> but it also <a href="https://inclusivedesignprinciples.org/#be-consistent">provides a consistent experience</a> regardless of what device they user or method of operation.</p>
<h2>Conclusion</h2>
<p>While hover menus are everywhere, they’re really hard to use, especially for people with motor impairements.</p>
<p>Instead of trying to work around these issues with sub par solutions, let users open menus on click.</p>
<p>Not only will it avoid all the pitfalls of hover menus but it provides a number of benefits too, no matter what the situation is.</p>
Why we stopped breaking down stories into tasks2015-12-15T09:00:01+00:00https://adamsilver.io/blog/why-we-stopped-breaking-down-stories-into-tasks/<p>The Scrum process says to break down stories into tasks to make estimation easier, encourage collaboration and to be able to shoow more granular progress during a sprint.</p>
<p>But after a few sprints, we decided to do the next sprint without creating tasks. As a result we drastically increased our velocity and never went back.</p>
<p>Here I‘ll jot down some of the reasons we decided to do this:</p>
<h2>1. Breaking down stories into tasks is time consuming</h2>
<p>Our planning sessions took about 3 hours and at least 50% of that time was spent breaking down stories into tasks.</p>
<p>With 20 people in the team we got at least 30 hours back per week to do the actual work.</p>
<h2>2. The tasks we came up with invariably would change as we worked on the stories</h2>
<p>Things change and things are uncovered when doing the work. So we ended up doing a different task or not doing the task at all.</p>
<h2>3. Tasks are repetitive</h2>
<p>Many of the tasks were a repeat of what our definition of done was.</p>
<p>For example, our definition of done included that we would have unit tests. But we also had a task for unit tests.</p>
<p>We didn’t need to keep rewriting the same things over and over. We would just do these things as a matter of course.</p>
<p>Instead we relied on a clear Definition of Done and Acceptance Criteria which worked better with less work.</p>
<h2>4. Tasks were often carried out in parallel</h2>
<p>Tasks were often carried out at the same time. For example, we would write HTML and CSS at the same time.</p>
<p>This meant that a lot of tasks moved from “in-progress” to “complete” at the same time which meant we didn’t end up showing granular progress during the sprint anyway.</p>
<h2>5. Our estimates didn’t improves</h2>
<p>We found that we were only able to estimate our capacity after we got to know each other working on this project at this organisation. Tasks didn’t make a difference.</p>
<h2>6. It decluttered our task board</h2>
<p>As the board just had stories the board was a lot easier to scan and use.</p>
<h2>7. It encouraged collaboration throughout the sprint</h2>
<p>Not relying on tasking meant we could spend more time working closely together in sprint.</p>
<h2>Summary</h2>
<p>While we started our process by following Scrum to the letter, we soon realised that breaking down stories into tasks was something that wasn’t worthwhile for us.</p>
<p>In the end we realised that it was overplanning and poor use of our time.</p>
<p>In the end we used that time to get on with the work and deliver at a significantly faster pace.</p>
7 reasons why infinite scrolling is a bad idea2015-11-24T09:00:01+00:00https://adamsilver.io/blog/7-reasons-why-infinite-scrolling-is-a-bad-idea/<p>On more than one occasion I have found myself trying to convince team-mates that infinite scrolling and its close relative <em>show more</em> is more likely to degrade the experience than improve upon it. I thought I would jot down my notes on the matter and share them with you. Here they are:</p>
<h2>1. The footer becomes unusable</h2>
<p>People understand what a footer is and that it is likely to contain links to important secondary information. Infinite scrolling means the footer keeps getting pushed just out of reach by the freshly loaded content.</p>
<h2>2. Performance degrades</h2>
<p>If you’re using infinite scrolling on a long page, you’re constantly loading more and more content into memory. This will have a negative impact on page performance, since the browser has much more work to do in order to render the page.</p>
<p>Also, the page needs to listen constantly for scroll events which can cause client-side performance problems.</p>
<h2>3. Analytics is harder to implement</h2>
<p>Due to the way infinite scrolling works, dropping some Google Analytics code into the page isn’t going to give you much insight. Therefore you will need to write your own analytics implementation to track newly loaded content. This is then more costly to develop, maintain and test.</p>
<h2>4. Bookmarking and the back button become problematic</h2>
<p>You can’t easily bookmark a segment of results to come back to or share with your friends.</p>
<p>Even if you do manage it and you end up bookmarking segment 15 (where each segment is say 40 items) then when you return to that bookmark, you suffer from long page-load times.<br>
Similarly, you can’t use the back button as it doesn’t go back to the previous segment of results. Instead it goes back to the previous page.</p>
<h2>5. People may suffer from choice paralysis</h2>
<p>With very long pages people can feel paralysed by the amount of content and choices—infinite scrolling may well cause inaction and in-turn, lower click through rates. Just see <a href="http://danwin.com/2013/01/infinite-scroll-fail-etsy/">what happened to Etsy</a>.</p>
<h2>6. The scrollbar becomes unusable and untrustworthy</h2>
<p>The scroll bar inevitably becomes very small and hard to use. It’s hard to place your mouse on the scrollbar and the slightest movement might scroll a large part of the page when you only wanted to scroll a little bit.</p>
<p>Even worse, the scrollbar plays a trick on users as it displays the page length inaccurately — the scrollbar will be near the bottom and then suddenly when the items are loaded in, it will jump up and reveal there is now more content to scroll through. <strong>It’s dishonest design to tell people that they’re almost done when they’re not</strong>.</p>
<h2>7. It’s generally hard to use</h2>
<p>Design is about communication. When someone arrives at a set of results, they want to instantly be able to understand what’s going on…</p>
<blockquote>
<p>What am I looking at?<br><br>
How do I get to the next set of results?<br><br>
How many results are there?<br><br>
How long will it take me to browse through them all?<br><br>
Should I bother to browse through them?<br><br>
Or should I search again?<br><br>
Or should I try filtering instead?<br></p>
</blockquote>
<p>If the user doesn’t understand the answers to these questions, they will have a feeling of unrest, uncertainty and disorientation. When they do know the answers to these questions, they can make informed and quick decisions, without losing energy.</p>
<p>With pagination, people can anticipate the effort required to browse through the results. There is a happy sense of completion when a page is finished. There is a clear end. Pagination gives people control to decide whether or not to continue to the next page.</p>
<p>Also, smaller pages, means a faster, more focused, less overwhelming experience with none of the pitfalls described above. People don’t mind clicking links (to new pages) as long as each click is meaningful and leads them closer to their desired goal.</p>
The hidden cost of one bad design2015-11-14T09:00:01+00:00https://adamsilver.io/blog/the-hidden-cost-of-one-bad-design/<p>I once worked on a project where users wanted to pay using PayPal. We designed this:</p>
<div class="image image--small">
<figure>
<img src="https://adamsilver.io/assets/images/paymentchoice.png" alt="Payment choice page" width="100%" style="max-width: 400px;">
<figcaption>Payment options page</figcaption>
</figure>
</div>
<p>The business blocked the design because it was too easy to select PayPal. This is because we received a 50p transaction fee when users paid by card.</p>
<p>We we’re asked to put the PayPal option behind a click-to-reveal pattern encouraging users to choose card.</p>
<p>But, the hidden costs of doing this add up to way more than 50p per order.</p>
<p>Unhappy users use the service less or use competing services instead. They also stop recommending the service to their friends and family.</p>
<p>So, if you’re going to introduce a feature and make it hard to use, don’t bother.</p>
Designing honestly for the web2015-10-09T09:00:01+00:00https://adamsilver.io/blog/designing-honestly-for-the-web/<p>I admit: I’ve bent the web many times in the past. For example, I’ve:</p>
<ul>
<li>used tables for layout</li>
<li>given <a href="https://adamsilver.io/blog/buttons-shouldnt-have-a-hand-cursor/">submit buttons a pointer cursor</a></li>
<li>used a <a href="https://adamsilver.io/blog/select-boxes-shouldnt-submit-on-change/">select box as a makeshift navigation bar</a></li>
</ul>
<p>In <a href="http://alistapart.com/article/dao">A Dao of Web Design</a>, John Allsopp says:</p>
<blockquote>
<p>“If you’ve never watched early television programs, it’s instructive viewing. Television was at that time often referred to as “radio with pictures,” and that’s a pretty accurate description. Much of television followed the format of popular radio at that time.”</p>
</blockquote>
<p>Like the relationship between television and radio, there’s a relationship between print and web.</p>
<blockquote>
<p>“In print the designer is god. An enormous industry has emerged from WYSIWYG, and many of the web’s designers are grounded in the beliefs and practices, the ritual of that medium. As designers we need to rethink this role, to abandon control, and seek a new relationship with the page.”</p>
</blockquote>
<p>We don’t like change and we can’t relinquish control. We take our long, deep-rooted belief and experience in a previous medium, and mindlesssly apply to the new one, despite the problems it causes.</p>
<p>When the web came along, we believed we should have the same visual control as we did in print design. Today, that belief is still prevalent. We don’t just think it should behave like print, but also more app-like, whatever that means.</p>
<p>But what does this have to do with dishonest design? When we bend the web, we are designing dishonestly. When we design dishonestly we tend to design unfriendly, unintuitive experiences, which can actually break the inherent features of the web. The very same features which make the web so simple, so powerful, so amazing.</p>
<p>Since the web has been around for a good while, this comes to down to ignorance.</p>
<p>The web and the web browser gives us an amazing set of tools, not to be messed up. Elements such as links, buttons, pages, forms, back buttons, bookmarking, images, videos, headings, paragraphs, focus outlines and more.</p>
<p>It’s worth understanding what these elements mean, how they work, and how we can present them to users to signify their behaviour and utility.</p>
<p>These elements have meaning beyond just how they look.</p>
<p>Do you look at other websites on your Macbook Pro and iPhone 134 and think “if it’s good enough for them, it’s good enough for me”? That’s lazy.</p>
<p>Sometimes a solution works well for a mobile app, but works badly on the web. <a href="https://adamsilver.io/blog/7-reasons-why-infinite-scrolling-is-a-bad-idea/">Infinite scroll</a> is an example of this.</p>
<p>Have you designed a <a href="https://adamsilver.io/blog/select-boxes-shouldnt-submit-on-change/">drop down menu to work without a submit button</a>? This is also bending the web. A select box is for input, not for navigiation.</p>
<p>You should note that browsers and devices get better all the time. When we design honestly, the experience gets better all by itself, with no effort on our part—just use a form on your phone and notice how it helps you fill it out.</p>
<p>Designing dishonestly costs the user, costs the developer time and the business money, often because the results inadvertently exclude users unnecessary. You might get away with the odd bit of dishonest design, but why would you want to?</p>
Designing a responsive menu without a hamburger2015-09-14T09:00:01+00:00https://adamsilver.io/blog/designing-a-responsive-menu-without-a-hamburger/<p>James Archer has explained why the <a href="https://jamesarcher.me/hamburger-menu.html">hamburger menu can cause usability problems</a>. I thought I’d jot down a few alternative designs here.</p>
<h2>1. Medium</h2>
<p>Medium’s success is down to it’s simplicity which can be seen in its navigation which simply drops underneath the header.</p>
<div class="image" style="max-width: 400px">
<figure><img src="https://adamsilver.io/assets/images/hamburger/medium.png" alt=""><figcaption>Medium’s navigation stacks on small screens</figcaption></figure>
</div>
<h2>2. Product Hunt</h2>
<p>Product Hunt follows the same approach as Medium, but does regardless of screen size. But, as Product Hunt has more links, they wrap onto two lines.</p>
<p>This menu could be designed a little better, it’s hard to argue with how simple this is to operate across all screen sizes.</p>
<div class="image" style="max-width: 400px">
<figure><img src="https://adamsilver.io/assets/images/hamburger/producthunt.png" alt=""><figcaption>Product Hunt’s navigation stacks underneath the header regardless of screen size</figcaption></figure>
</div>
<h2>3. Node</h2>
<p>Node’s site has eight links, and they lay them out plainly in two columns on small screens. On large screens they are displayed on one line.</p>
<div class="image" style="max-width: 400px">
<figure><img src="https://adamsilver.io/assets/images/hamburger/node.png" alt=""><figcaption>Node’s navigation is in 2 columns on small screens</figcaption></figure>
</div>
<h2>4. Adamsilver.io</h2>
<p>My site follows suit and I’ve had no complaints.</p>
<div class="image" style="max-width: 400px">
<figure><img src="https://adamsilver.io/assets/images/hamburger/adamsilver.png" alt=""><figcaption>My site stacks navigation below header</figcaption></figure>
</div>
<h2>5. Google Design</h2>
<p>Google Design lets users horizontally scroll which I’ve noticed a number of news sites are employing.</p>
<div class="image" style="max-width: 400px">
<figure><img src="https://adamsilver.io/assets/images/hamburger/googledesign.png" alt=""><figcaption>Google Design uses horizontally scrolling</figcaption></figure>
</div>
<p>It’s good to avoid horizontal scroll, but on small screens, this approach works well and scales too.</p>
<h2>6. The Minimalists</h2>
<p>The Minimalist’s site keeps their navigation bar simple just like their overall message. Links simply wrap.</p>
<div class="image" style="max-width: 400px">
<figure><img src="https://adamsilver.io/assets/images/hamburger/minimalists.png" alt=""><figcaption>Minimalists stack their navigation</figcaption></figure>
</div>
<h2>Summary</h2>
<p>These designs are boringly simple and user-friendly. <a href="http://uxmyths.com/post/654047943/myth-people-dont-scroll">User’s don’t mind scrolling</a> and it’s wise not to exert too much energy trying to fit everything above an imaginary fold.</p>
Progressively enhanced Javascript2015-08-16T09:00:01+00:00https://adamsilver.io/blog/progressively-enhanced-javascript/<p>Using Javascript to design progressively enhanced interfaces is probably the most important yet, misunderstood subject in web development.</p>
<p>In this article we’ll discuss these misunderstandings. Then, we’ll explore long-forgotten techniques that have stood the test of time.</p>
<blockquote>
<p>“The problems we have with websites are ones we create ourselves”</p>
<p><cite>motherfuckingwebsite.com</cite></p>
</blockquote>
<p>By default, the web is accessible to everyone. That’s the web’s super power. It’s us lot that take this natural super power and lace it with kryptonite, hurting users in the process.</p>
<p>Most of us care about users, but we also fail in the execution of that intent. Before we get to why, let’s first define progressive enhancement.</p>
<p>Progressive enhancement first gives everyone a useful experience; Then, where necessary, it lets us create a better, enhanced experience for users using a more capable browser.</p>
<p>We don’t seem to know how to write Javascript in a progressively enhanced way.</p>
<h2>Progressive enhancement myths</h2>
<p>While there are many <a href="http://www.sitepoint.com/javascript-dependency-backlash-myth-busting-progressive-enhancement/">myths about progressive enhancement</a> I want to point out two in particular.</p>
<p>First, unobstrusive Javascript (placing Javascript in external files), does not, in anyway, mean it’s progressively enhanced.</p>
<p>Second, this is not just about people who turn off Javascript. <a href="https://adamsilver.io/blog/javascript-isnt-always-available-and-its-not-the-users-fault/">Most users experience your site without JavaScript through no fault of their own</a>.</p>
<p>The last of those points—<em>using Javascript that the browser doesn’t recognise</em>—is what we need to discuss. Javascript—unlike HTML and CSS—doesn’t degrade gracefully without intervention.</p>
<p>For example, <code><input type="email"></code> degrades gracefully into a text box. And <code>border-radius</code> degrades gracefully by not showing rounded corners. No problem.</p>
<p>Javascript, however, will error when the browser tries to execute code it doesn’t recognise. Internet Explorer 8, for example, breaks on the last line here:</p>
<pre><code>var form = document.forms[0];
form.attachEvent('submit', function() {
window.event.returnValue = false;
var foos = document.getElementsByClassName('foo');
});
</code></pre>
<p>This is because it doesn’t recognise <code>getElementsByClassName()</code>. The page didn’t degrade nor did it fully enhance. The script intercepts the form’s submit event, but gives users a broken interface.</p>
<p>So, when the user submits the form, nothing happens. Handling submit on the client (the enhanced experience) to save a round trip is fine. Handling submit on the server (the core experience) is fine too. But the implementation above doesn’t allow for either experience.</p>
<p>Neither the browser nor the features in this example are relevant. It could be any browser and any feature. It makes no difference how new a browser is or what (cutting edge) feature it supports.</p>
<h2>What shouldn’t we do?</h2>
<p>It’s often easier to deduce what it is we should do, once we find out what we shouldn’t. Let’s do that now.</p>
<h3>1. Don’t ignore the problem exists</h3>
<p>I struggled a lot with this. I always thought about the current set of browsers that a particular project adheres to. But just because I ignored users who use ‘other’ browsers, doesn’t mean they don’t exist.</p>
<h3>2. Don’t abdicate responsibility</h3>
<p>When we add a third-party script to the project, it becomes our responsibility. We should check under the hood for quality and watch out for the typical <a href="https://gist.github.com/david-mark/06b9879f963ebb0eed62">multi-browser approach</a> that opposes the principles of progressive enhancement.</p>
<p>Moreover, when a library releases a new version, they often drop support for various browsers. This is a never ending cycle. This is what Jeremy Keith calls the <a href="https://adactio.com/journal/6692">continuum</a>.</p>
<h3>3.Don’t rely on Cutting The Mustard</h3>
<p><a href="http://responsivenews.co.uk/post/18948466399/cutting-the-mustard">Cutting The Mustard</a> (CTM) is a relatively new approach which promises reliability by giving users a core or an enhanced experience. It’s intent is great but the implementation falls a little short.</p>
<pre><code>if(document.querySelector && window.addEventListener && window.localStorage) {
// start application
}
</code></pre>
<p>The script detects a few choice methods, to then infer that the browser is ‘modern’. This is impossible because of the vast amount of new (versions of) browsers being released every day. And it’s irrelevant because the release date doesn’t determine capability.</p>
<p>If the check passes, the application starts and attempts to give users the enhanced experience. Inferences are almost as frail as user agent sniffing, something that Richard Cornford explains in <a href="http://jibbering.com/faq/notes/detect-browser/">Browser Detection and What To Do Instead</a>.</p>
<p>CTM has the following problems:</p>
<ul>
<li>Detecting <a href="https://gist.github.com/david-mark/bc0c303a52957dba427239b02e5c99c9">host objects this way is dangerous</a>.</li>
<li>Merely detecting the existence of a method is not enough. Nicholas Zakas’ <a href="http://chimera.labs.oreilly.com/books/1234000001655/index.html">The Problem with Native JavaScript APIs</a> demonstrates this. Peter Michaux’s article <a href="http://peter.michaux.ca/articles/feature-detection-state-of-the-art-browser-scripting">Feature Detection: State of the Art Browser Scripting</a> explains this further.</li>
<li>It unnecessarily gives users the degraded experience. For example, due to the detection of a few choice ‘modern’ methods, it excludes Internet Explorer 8 (or 6 for that matter) from giving users client-side form validation even though these browsers are perfectly capable of providing this functionality.</li>
<li>CTM often relies on polyfills. <a href="https://adamsilver.io/blog/the-disadvantages-of-javascript-polyfills/">Polyfills are problematic</a> in their own right. But if CTM needs polyfills, it shows that on its own the technique isn’t robust.</li>
<li>The condition needs constant maintenance as vendors release new browsers. We shouldn’t have to update scripts when new browsers come out. We should revolve our scripts around features, not browsers.</li>
<li>It’s unreliable because if the application uses a method that is not within the condition, then there’s a high risk of exposing a broken interface.</li>
</ul>
<h2>What is the solution?</h2>
<p>Jeremy Keith says “I’ve always maintained that, given the choice between making something my problem, and making something the user’s problem, I’ll choose to make it my problem every time.”</p>
<p>To give users a core experience, we must ensure the interface works without Javascript. This is because that’s the experience users will get when the browser doesn’t recognise some method.</p>
<p>Then we must detect, and where necessary, test <em>all</em> of the features the application references before the application uses them. This ensures the page doesn’t end up half enhanced and therefore irrevocably broken.</p>
<p>To do this reliably we need to use wrappers (facades). The library should expose a dynamic API that adapts to the browser, something like this:</p>
<pre><code>if(hasFeatures('find', 'addListener', 'storeValue')) {
var el = find('.whatever');
addListener(el, "click", function() {
storeValue('key', 'value');
});
}
</code></pre>
<h3>Notes</h3>
<ul>
<li>It looks remarkably similar to CTM. The difference is that it doesn’t reference browser methods directly. Facades are leaner and context specific, allowing the library to fix bugs enabling us to reliably enhance an interface.</li>
<li>There’s a one-to-one mapping between what’s in the condition and what the application uses. If the condition doesn’t pass, the user gets the core experience.</li>
<li>There’s no need for polyfills. The library provides the method or it doesn’t, depending on the browser. No caveats.</li>
<li>The application logic is decoupled from the browser.</li>
</ul>
<h2>A dynamic API</h2>
<p>Peter Michaux’s <a href="http://peter.michaux.ca/articles/cross-browser-widgets">Cross-Browser Widgets</a> has a detailed walk-through, but let’s create a little something now.</p>
<p>Let’s say our application needs to add a class to an element. First we’ll create that function and expose a dynamic API:</p>
<pre><code>// use isHostMethod
if(document.documentElement.classList.add) {
var addClass = function(el, className) {
return el.classList.add(className);
};
}
</code></pre>
<p>Then the calling application checks <code>addClass()</code> is defined before referencing it:</p>
<pre><code>if(addClass) {
addClass(el, 'thing');
}
</code></pre>
<p>The application is blissfully unaware that it only runs in browsers supporting <code>classList()</code>. Users using Internet Explorer 9 and below get the degraded experience and that’s okay. If you want to support Internet Explorer 9, add a fork like this:</p>
<pre><code>var addClass;
// Use isHostMethod
if(document.documentElement.classList.add) {
addClass = function(el, className) {
return el.classList.add(className);
};
} else if(typeof html.className === "string") {
addClass = function(el, className) {
var re;
if (!el.className) {
el.className = className;
} else {
re = new RegExp('(^|\\s)' + className + '(\\s|$)');
if (!re.test(el.className)) {
el.className += ' ' + className;
}
}
}
}
</code></pre>
<p>This implementation supports almost every browser and the application didn’t need to change. In future you can remove this fork once the number of visitors diminishes to a suitable level—something only you can determine.</p>
<p>Either way, users get a working experience, proving that a library never needs to drop browser support, at least not in the traditional sense.</p>
<h2>Summary</h2>
<p>Progressive enhancement puts users first. Misunderstanding the application of progressive enhancement puts users last.</p>
<p>Progressive enhancement is not more work, it’s less work. We don’t have to endlessly play catch up with browsers. We don’t have to give users a broken experience.</p>
<p>Instead we can write backwards-compatible and future-proof code that creates robust and <a href="https://adamsilver.io/blog/11-things-to-consider-when-designing-for-everyone/">accessible experiences</a> for everyone.</p>
<!--
Cornford:
The combination of the facts that it is impossible to determine which browser is executing the script, and that it is impossible to be familiar with all browser DOMs can be rendered insignificant by using feature detection to match code execution with any browser's ability to support it. But there is still going to be a diversity of outcomes, ranging from total failure to execute any scripts (on browsers that do not support javascript, or have it disabled) to full successful execution on the most capable javascript enabled browsers.
Veal:
I would add - and with a mobile connection you have no choice but to use the proxy because that is the way the network is configured. They are not as open as your home broadband and companies often employ a proxy to save bandwidth, and again you cannot avoid this
if(document.querySelector && window.addEventListener && window.localStorage) {
// application that uses other APIs
window.addEventListener("load", function(e) {
// FAIL = ANOTHER FUCK YOU
var matches = window.matchMedia(...);
// ...other stuff...
}, false);
}
The idea of abstractions are good, the idea of several abstractions i.e. a library, is also good. But if that library is monolithic in nature, context-less, lacks feature detection and feature testing, leans on polyfills (or browser sniffing or object inferences etc) and does **not** expose a dynamic API, then ultimately you are unable to Progressively Enhance your application and your users and the business you work for, will suffer for it.
At the very least, it is beneficial to be able to spot code that does not conform to the principles of Progressive Enhancement. Particularly, the kind that doesn't even attempt to degrade gracefully in the face of danger.
This example will also demonstrate that Progressive Enhancement is not a drag in the way of "having to support old irrelevant browsers". Quite the opposite in-fact. The words "drops support for" changes to "degrades gracefully in". You also get to determine an appropriate degradation point suitable for your project.
-->
Addendum to the boring front-end developer2015-07-15T09:00:01+00:00https://adamsilver.io/blog/addendum-to-the-boring-front-end-developer/<p>Thanks to everyone who read <a href="https://adamsilver.io/blog/the-boring-front-end-developer/">The Boring Front-end<br>
Developer</a>. There were some outrageous and funny comments which I found entertaining and there were also some points worth addressing.</p>
<h2>1. CSS preprocessors</h2>
<p>I know I’m in the minority here. I know a lot of developers who like them, and a lot who don’t. I can see their many advantages too.</p>
<p>It’s just that I’ve worked on enough projects to know some of the problems they induce. Such as performance, maintainability and <a href="https://adamsilver.io/blog/the-disadvantages-of-css-preprocessors/">more</a>.</p>
<p>It’s relatively easy (cheap) to add a CSS preprocessor to a tech stack,<br>
but it’s relatively hard (costly) to remove it down the line. I’m just saying we should be more conscious of the issues before making that choice.</p>
<h2>2. New doesn’t mean good or bad</h2>
<p>I use a lot of new and old technology. I use them because they work. I don’t use them so much due to popularity, newness or how many stars they have on Github. At most these are secondary reasons.</p>
<p>This doesn’t seeem to be the case for a lot of people. It’s often about popularity, authority and newness.</p>
<h2>3. BFEDs don’t get paid well</h2>
<p>I know several developers that would be classed as boring. All are paid very well.</p>
<h2>4. Change isn’t necessarily progress</h2>
<blockquote>
<p>”I also find people touting ‘progress’ don’t realise that a lot of the time they just mean ‘change’. I mean, sure, if a new way of doing things is demonstrably better, by all means let’s use it. But a lot of the time you’re just swapping one (well-understood) set of tradeoffs and considerations for a new, less understood set, because ‘That’s what we’re doing now’.”<br><br>
—qu4z-2</p>
</blockquote>
<p>There’s a lot of change happening but does that change add value to the user or business?</p>
<h2>5. People first, developers second</h2>
<p>It’s common to hear teammates berating old browsers and dropping support<br>
in the name of cost and security but your users don’t care and are unaware anyway. Often they’re not in control of what browser they use.</p>
<p>Some users don’t know what a browser is and yet, they<br>
manage to surf and buy things using one. Amazing.</p>
<p>These users arrive at our sites because they can, and they leave because we unnecessarily and irresponsibly exclude them.</p>
<p>Has browser usage dropped because the browser is “old” or because the website doesn’t work in that browser anymore?</p>
<p>It’s true that you probably shouldn’t be testing your site in IE1 but there are some techniques that ensure any browser can be used to access a website (for the most part anyway). These techniques are just as much for new browsers as they are fold old.</p>
<blockquote>
<p>“If I had to choose between making something my problem and making something the users problem, I would make it mine every time.”<br>—Jeremy Keith</p>
</blockquote>
The disadvantages of Javascript polyfills2015-06-22T09:00:01+00:00https://adamsilver.io/blog/the-disadvantages-of-javascript-polyfills/<p>A polyfill, also known as a shim, is a user-defined implementation of an API that some browsers provide natively, normalising browser differences.</p>
<p>As a proponent of <a href="https://adamsilver.io/blog/making-view-templates-as-dumb-as-possible">outside-in development</a>, I see the lure of trying to develop as if all browsers are the same. The problem is that <a href="https://adamsilver.io/blog/browsers-are-different-but-so-what/">browsers are not the same</a>. Polyfills are problematic because:</p>
<h2>1. They augment host objects</h2>
<p>Polyfills augment host and native objects. Experts such as Richard Cornford, David Mark, Thomas Lahn and Kangax have told us this is a bad idea. The latter of which published two articles on the subject:</p>
<ul>
<li><a href="http://perfectionkills.com/whats-wrong-with-extending-the-dom/">What’s wrong with extending the DOM?</a></li>
<li><a href="http://perfectionkills.com/extending-native-builtins/">Extending native built-ins</a></li>
</ul>
<p>Here’s a choice snippet:</p>
<blockquote>
<p>“DOM extension seemed so temptingly useful […]. But what hides behind this seemingly innocuous practice is a huge load of trouble. […] the downsides of this approach far outweigh any benefits.”</p>
</blockquote>
<!--
## 2. Feature detection is not enough
As Peter Michaux shows us in [Feature Detection: State of the art browser scripting](http://peter.michaux.ca/articles/feature-detection-state-of-the-art-browser-scripting), the mere presence of an API is not always enough to determine its reliablity. This is where feature *testing* comes in.
Polyfills tend to just detect the presence of an API. They don't iron out the bugs or inconsistencies found in different browsers. Even if they did, they would have to override the original, whereby the override may contain a reference to it. This is dangerous and unnecessary. Instead, use facades, which we'll discuss shortly.
## 2. They intertwine browser and application logic
As Nicholas Zakas says in [Scalable JavaScript Application Architecture](https://www.youtube.com/watch?v=vXjVFPosQHw), it is important to decouple application and browser logic. He says:
> “Application logic should be written one way for all browsers in order to keep the code maintainable. If you’re using native APIs in your application logic, you can’t help but know what browser is being used because you need to account for browser differences. That means your application logic will always need to be updated as new browsers and new browser versions are released. **That’s a recipe for disaster**”.
-->
<h2>2. The full API is rarely needed</h2>
<p>We may not need the full API to solve the problem. We may not even be <em>able</em> to implement a polyfill because there’s just no way to do so. This is why context is important.</p>
<p>We should first look to understand the problem precisely. And then solve <em>that</em> problem only. We rarely need <em>all</em> of an API, which I’ll demonstrate in a moment. With polyfills it’s all or nothing.</p>
<h2>3. They come with caveats</h2>
<p>It takes little effort to find problematic polyfills. Take the <a href="https://github.com/es-shims/es5-shim">ES5 Shim</a> documentation. In describing the <code>Object.create</code> polyfill it states:</p>
<blockquote>
<p>“For the case of simply “begetting” an object that inherits prototypically from another, this <strong>should</strong> work fine across legacy engines.”</p>
</blockquote>
<p>The word <em>should</em> doesn’t instill confidence. We should, of course, build atop of reliable foundations—we are only as good as our lowest level functions. It continues:</p>
<blockquote>
<p>“The second argument is passed to Object.defineProperties which will <strong>probably fail either silently or with extreme prejudice</strong>.”</p>
</blockquote>
<p>We shouldn’t expect our team to rely on code like this, much less our users. Any code we write around this is just ‘polishing a turd’.</p>
<h2>What should we do instead?</h2>
<p>A facade or wrapper, is a design pattern that simplifies an interface around something more complex. This lets us abstract away the differing browser implementations and bugs. And with the added bonus of being able to simplify the method signature.</p>
<p>Inside the wrapper there’s nothing to stop us using bits of an API, and feature testing various implementations and acting accordingly, like Peter Michaux shows us in <a href="http://peter.michaux.ca/articles/cross-browser-widgets">Cross browser Widgets</a>.</p>
<p>Cloning an object is pertinent to this article because <code>Object.create</code> solves this problem. If we want to support <em>modern</em> browsers only—that is those that provide <code>Object.create</code>—then an implementation might look like this:</p>
<pre><code>var lib = {};
if(Object.create) {
lib.cloneObject = function(obj) {
return Object.create(obj);
};
}
</code></pre>
<p>As this implementation only uses a small part of the entire API, the exposed method signature has just one argument, solving the precise problem and no more. But what about browsers lacking <code>Object.create</code>?</p>
<p>If we want to degrade gracefully, we don’t have to do anything (hello Progressive enhancement!). If we want to support other browsers add a second fork:</p>
<pre><code>// Code credited to David Mark. Thanks.
var lib = {};
if(Object.create) {
lib.cloneObject = function(obj) {
return Object.create(obj);
};
} else {
lib.cloneObject = (function() {
var Fn = function() {};
return function(obj) {
Fn.prototype = obj;
return new Fn();
};
})();
}
</code></pre>
<p>The problem got a bit more challenging but the implementation is still lean and the method signature holds up. But, we didn’t need to worry about recreating <code>Object.create</code> in its entirety.</p>
<p>But if we did need the full API, we could make two changes. First, change the name of the function to something more appropriate. Second, expand the method signature to allow for property descriptors like this:</p>
<pre><code>var lib = {};
if(Object.create) {
lib.createObject = function(obj, props) {
return Object.create(obj, props);
};
}
</code></pre>
<p>What about browsers lacking <code>Object.create</code>? Same as before. Either degrade gracefully or add another fork. This is progressive enhancement.</p>
<h2>Summary</h2>
<p>At best, polyfills are hard to implement and complicate matters by intertwining browser and application logic. This complexity is costly.</p>
<p>At worst, polyfills have caveats and gaps that cause pain for the developer and broken experiences for users.</p>
<p>Instead, use wrappers, which enable us to build reliable, progressively enhanced and therefore accessible experiences.</p>
<!--
* ADDED IMPLEMENTATION Just because an API is implemented in a browser doesn't mean it's trustworthy. Sometimes, the spec is simply misunderstood and implemented differently across browser vendors. Adding a polyfill to the mix just adds complexity in the form of another user-defined implementation.
* CONSISTENCY Then there is the question of consistency. Do you want to use some polyfills and some facades. Probably not. Just use a consistent abstraction, a facade.
-->
The disadvantages of CSS preprocessors2015-05-05T09:00:01+00:00https://adamsilver.io/blog/the-disadvantages-of-css-preprocessors/<p>CSS preprocessors have many advantages. But like most tools, they also have a number of drawbacks which I’ll describe here.</p>
<h2>1. Debugging is harder</h2>
<p>Preprocessors have a compilation step, meaning that CSS line numbers are irrelevant when trying to debug our code. But debugging is twice as hard as programming, so this alone is a <em>huge</em> drawback.</p>
<blockquote>
<p>Debugging is twice as hard as programming</p>
<p><cite>Brian Kernighan</cite></p>
</blockquote>
<p><a href="http://thesassway.com/intermediate/using-source-maps-with-sass">Source maps</a> provide a solution, but they need to be setup and they don’t work in all browsers, particularly those where bugs often come up.</p>
<p>Without source maps, we’re left to search for rules in the hope that we find what we’re looking for.</p>
<h2>2. Compilation slows down development</h2>
<p>Compilation times can be really slow, even when using the best tools on the fastest computer. You know that feeling you get when you refresh and don’t see any changes—that.</p>
<h2>3. They can produce very large CSS files</h2>
<p>Source files may be small, but the <a href="http://jaketrent.com/post/cons-css-preprocessors/">generated CSS could be huge</a> which is what counts.</p>
<p>We need to be aware that in using a CSS preprocessor, we’re losing some control.</p>
<h2>4. Maintainence and overengineering</h2>
<p>It’s common to see coder authors using a <code>red</code> variable, for example. But this is of little value in terms of maintainability.</p>
<p>If the colour changes, then we need to update the name and the value, making the abstraction pointless.</p>
<p>Not only are there alternatives to variables and mixins, which I’ll cover later, but a search and replace maybe all we need.</p>
<h2>5. Tooling and developer convenience</h2>
<p>CSS preprocessors require extra tooling. Code authors shouldn’t be forced to use a particular editor just to be able to use the tool. That’s the tail wagging the dog.</p>
<p>Also, extra stuff adds complexity. This needs to be understood, upgraded and maintained—all of which increases cost and a higher risk of problems.</p>
<h2>6. Saving generated files (or not)</h2>
<p>Whether we should <a href="http://stackoverflow.com/questions/13185170/using-less-and-version-control-should-generated-css-be-included-in-a-repo">save the generated CSS</a> or not is something we don’t agree on as a community. In which case, it’s time for some <a href="http://www.nczonline.net/blog/2015/04/14/consensus-driven-development/">Concensus Driven Development</a>.</p>
<h2>7. Capability and understanding</h2>
<p>Whilst CSS preprocessors and the workflows around them have become widespread, there is still a knowledge gap. Particularly, when it comes to understanding the trade-offs.</p>
<p>There’s a big difference between understanding a tool, and using it effectively without introducing other problems.</p>
<h2>What about variables, mixins, and nesting?</h2>
<p>A solid approach to writing <a href="http://maintainablecss.com/">maintainable CSS</a> solves most problems. In anycase, we can mimick <em>variables</em> and <em>mixins</em> by using comma-delimited CSS selectors:</p>
<pre><code>selector,
anotherSelector {
/* common rules */
}
</code></pre>
<p>And, whilst we can repetitively qualify our selectors to mimick <em>nesting</em>, it’s not something that makes for performant CSS. Instead, we should <a href="http://maintainablecss.com/chapters/conventions/">use a convention</a>.</p>
<h2>Summary</h2>
<p>It’s <em>easy</em> to add a CSS preprocessor to the tech stack. But, it’s not easy to remove it down the line, should we so choose.</p>
<p>It’s our responsibility to consider the impact they have on our work flow before making the <em>easy</em> decision to install one.</p>
The role of the Front-end Developer2015-03-11T09:00:01+00:00https://adamsilver.io/blog/the-role-of-the-front-end-developer/<p>The role of the front-end developer extends far beyond translating designs into code. They should be involved in many other aspects of the design and development process too.</p>
<h2>User experience and interaction design</h2>
<p><a href="http://www.disambiguity.com/there-is-no-ux/">Everyone is responsible for UX</a> and <a href="http://www.smashingmagazine.com/2014/11/21/why-you-should-include-your-developer-in-the-design-process/">front-end developers play an essential role</a> due to their intimate relationship with a huge range browsers, across devices and operating systems. How can you design for the web if you don’t understand the platforms’ constraints and powers?</p>
<h2>Front-end architecture</h2>
<p>An <em>experienced</em> front-end developer should be able to design a suitable front-end architecture which includes the consideration of the following:</p>
<ul>
<li>Design patterns</li>
<li>Architectural patterns</li>
<li>Bootstrapping strategies</li>
<li>Bundling and compression</li>
<li>Modularity and semantics</li>
<li>Technical contracts between backend and front-end. Namely view models and XmlHttpRequest end-points</li>
<li>Code style and convention</li>
<li>Testing and automation</li>
</ul>
<h2>Accessibility</h2>
<p>The beauty of the web is one of reach; deploy once and access everywhere; there are just two requirements: a browser and an Internet connection. Oh and a competent front-end developer who won’t <a href="http://www.motherfuckingwebsite.com/">fuck up your website</a>.</p>
<p>Front-end developers are responsible and should take pride in the fact that, the UIs they build, are accessible to everyone, no matter their age, ability, user interaction preferences and, choice of device, operating system and browser.</p>
<p>Front-end developers are <em>normally</em> speaking, the only advocates of accessibility and as accessibility is intertwined with usability, it’s vital to be knowledgeable and to champion it readily.</p>
<h2>Front-end feature writing</h2>
<p>Given a well defined and suitable front-end architecture, adding new features and updating existing features will include the writing of HTML, CSS and Javscript. This should include writing unit tests and (at least helping to write) automated functional tests.</p>
<h2>Search engine optimisation</h2>
<p>Much like accessibility, it is imperative front-end developers understand how to build web pages that are search-engine friendly, so that appropriate indexing can take place in order to surface the content of the web page to their users.</p>
<h2>Front-end performance</h2>
<p>It is important front-end developers understand various facets of performance ensuring that web pages are served and <a href="https://adamsilver.io/blog/dont-use-ajax-for-personalised-content">run as fast as possible without degrading the UX</a>. This includes a good knowledge of browser caching, compression, bundling and runtime performance.</p>
<h2>Browser compatibility</h2>
<p>Front-end developers should endeavour to test in as many browsers as is reasonable when developing, but will understand there is a balance to be had, as testing all browsers, in all compatibilities, on all devices is a sisyphean task.</p>
<p>The balance can only be struck through experience of knowing which spread of browsers should be tested and at which frequency. Leaning on <a href="https://adamsilver.io/blog/progressively-enhanced-javascript/">cross-browser scripting</a> minimises the worry behind a lack of manual browser testing coverage.</p>
<h2>Development process and methodologies</h2>
<p>It is very important to be able to work as part of a team in a given process. This means an understanding of various Agile methodologies. Furthermore, it’s highly beneficial to you and your team to be able to spot friction and implement improvements to that process.</p>
Technical wanking2015-02-09T09:00:01+00:00https://adamsilver.io/blog/technical-wanking/<p>Technical wanking is the practice of using cool and new technology because — well — it’s <em>cool</em> and <em>new</em>. But it’s better to choose technology on merit.</p>
<p>I first heard the term in 2010 when I was building my first Single Page Application (SPA). We were using “cutting-edge” libraries for client-side templating and other bits; we also wrote our own client-side router.</p>
<p>The administration system we were building didn’t need to consider SEO, and only needed to work in Chrome. The application contained various CRUD interfaces with a few rich interactions around it sich as drag and drop and sorting interfaces.</p>
<p>I couldn’t wait to start, solve a bunch of new, modern problems and propel my career accordingly. How could anyone resist the new buzzwords littering my CV?</p>
<p>Six months into the project, James Norton, a friend and colleague joined my team. We got talking about the codebase and James was quite scathing about the SPA architecture we were using. He said that I was technically wanking (which was amusing and hurtful, ha).</p>
<p>James actually went on to constructively explain why all the not-so-goodaspects of the user experience born out of the architecture were self-induced and unnecessary. For example, we wrote:</p>
<ul>
<li>a client-side JavaScript router, when we already had a perfectly robust server-side router written in Rails. We should have just let the browser handle the browsing.</li>
<li>a client-side JavaScript view renderer which only re-rendered the parts of the Document tree that changed. Again Rails (in our case) had a good view templates. We should have just let the browser parse and render the HTML which is it what it does best.</li>
<li>a lot of code that adapted generic REST API responses into something that was <a href="https://adamsilver.io/blog/making-view-templates-as-dumb-as-possible">appropropriate for the view</a>. Once again, Rails, made this easy with a well designed ORM and plenty of utility functions to help server-side view templates get what they need.</li>
</ul>
<p>While I was chuffed with all the clever solutions I had created, if we had used a traditional (often seen as archaic) the application would have worked a lot better without all the <a href="https://adamsilver.io/blog/the-problem-with-single-page-applications/">problems with SPAs</a>. I was solving self-induced problems to help my team get their work done, as opposed to deliverijng robust and useful experiences for users.</p>
<p>If we avoided the lure of SPAs, the result would have been just as slick. Just as beautiful. Just as rich. And it would have taken half the time to build, with a far nicer split of responsibilities between the server and client, meaning we could iterate faster. Not to mention it would have had better performance and accessibility. All of which contributes to the overall experience.</p>
<p>“Everyone’s building them,” they say. But when everyone’s doing something, that <em>something</em> is usually a bad idea. For example, most people eat McDonalds, but it doesn’t make it good for you.</p>
<p>We’re paid to do this. We’re meant to be professionals. It’s our duty to do the right thing for users and the client. Not to make decisions solely to improve our CV. That’s developer driven design.</p>
<p>Sometimes it’s hard to push back, but we can only learn and do our best.</p>
Don't use AJAX for personalised content2014-12-29T09:00:01+00:00https://adamsilver.io/blog/dont-use-ajax-for-personalised-content/<p><a href="https://developer.akamai.com/stuff/Caching/Content_Caching.html">Content caching</a> can decrease the time it takes to load a web page.</p>
<p>But it doesn’t work if the page contains personal content because one user may receive another user’s personal content which is a breach of privacy and just doesn’t work.</p>
<p>This can lead to the use of AJAX to load in the personalised content as a separate request which has a number of drawbacks.</p>
<p>Before explaining them, I‘ll first define what I mean by personalised content.</p>
<h2>Personalised content</h2>
<p>Personalised content is content that is specific to a user.</p>
<p>At the most basic level, a “sign out” link is personalised because it means the system knows the user is signed in.</p>
<p>This type of personalised content is cacheable because you can segment the cached content into 2 huge groups of users: signed in and signed out.</p>
<p>With a <a href="https://blogs.akamai.com/2014/05/and-you-thought-your-page-could-not-be-cached.html">cookie check</a>, the user can be given the page they need.</p>
<p>But other information like the user’s name or contents of their shopping basket cannot be cached because that’s completely unique to the user.</p>
<h2>The problems with using AJAX to provide personalised content</h2>
<h3>1. It excludes people who don’t have JavaScript</h3>
<p><a href="https://adamsilver.io/blog/javascript-isnt-always-available-and-its-not-the-users-fault/">User without Javascript</a>, will get an incomplete or broken page. Not being able to sign out or see the contents of their shopping basket would be unacceptable.</p>
<h3>2. It makes the page slower to load</h3>
<p>Instead of a single HTTP request for the page there will be multiple.</p>
<p>The first contains the generic, cached non-personalised content which will be fast.</p>
<p>But the subsequent AJAX requests will hit the server which will be subject to the same slower latency anyway. Plus AJAX requests cannot be chunked making them slower than a normal HTTP response.</p>
<p>On top of that you‘d need additional code for the logic to fill in parts of the page and handle errors and things. And the cost of reflows and repaints isn’t trivial.</p>
<h3>3. It degrades the experience</h3>
<p>Using AJAX to load content means that users need to be shown a custom loading indicator which is not as familiar and usually not accurate. It just spins rather than showing progress.</p>
<p>When there’s an error, that needs to be displayed too which is inconsistent with the default browser experience that works across all websites.</p>
<p>When the page first loads it will only be half rendered. And sometime later, the personalised content is injected into the page. This is jarring as the page fills in the gaps and jumps around which could cause mistakes and confusion.</p>
<p>Sometimes the user has started to scroll when the AJAX request finally finishes so users may not notice the newly loaded content.</p>
<h3>4. It complicates the codebase</h3>
<p>You need more complex code to handle AJX calls, and send JSON and parse it on the client. And you have to think about how you‘ll organise the partials which contain HTML and decide when personalised content isn‘t essential to the user experience.</p>
<p>You‘ll also need to decide how many personalised requests the client needs to make. More sounds nice from an atomic perspective but it‘ll exacerbate the problems I mentioned earlier.</p>
<h2>Summary</h2>
<p>Content-caching is a useful technique when used responsibly and for pages that don’t contain personalised content.</p>
<p>But if you need to give users personalised content, then that‘s not a reason to use AJAX. It means you need to work on your server side infrastructure to make sure personalised content can be delivered at speed.</p>
<!--
## Todo:
* https://remysharp.com/2012/04/25/mobile-battery-performance
* http://itamarst.org/writings/dynamiccaching.html
* cache invalidated means it goes to server anyway
## Comment from blog covers it off:
> I think this would be a useful technique in only special situations. It does accomplish what you want but will require multiple downloads and will make a portion of your page unaccessible to those who have disabled JS (from what I have heard that is 10% of the intenet population).
> Plus I am dubious of the savings. The reason for the caching to not have a web brower contact the website. It can just retrieve the content from cache. But if it is having to retrieve a portion of the content anyway you still have to make a HTTP request. Might as well make that response a bit bigger and get rid of the multiple requests and more complex code.
> Sounds to me like this is going a little overboard on caching. Some pages are just not designed for caching. If that is the case then implement your application to use the “If-Modified-Since” header. That way the user can make their request but get back a small response in most cases.
> I think this is premature optimization.
-->
The boring front-end developer2014-10-01T09:00:01+00:00https://adamsilver.io/blog/the-boring-front-end-developer/<p><em>Cool</em> front-end developers are always <em>pushing the envelope</em>, jumping out of their seat to use the latest and greatest and shiniest of UI frameworks and libraries.</p>
<p>They’re often found bridging the gap between native apps and web and so will strive to make the UI look and behave like an app. <em>Which app?</em> you may ask. <em>iPhone? Android? What version?</em> All good questions, alas another topic altogether.</p>
<p>However, there’s another kind of front-end developer, the <em>boring</em> front-end developer. Here’s an ode to the <em>boring</em> front-end developer, <em>BFED</em> if you will.</p>
<h2>Browser support</h2>
<p>The BFED realises that while not all experiences will be identical, all browsers <em>can</em> be used to consume a website, even <em>gasp</em>, IE6 and below. He/she will promote Progressive Enhancement and Cross-browser (not Multi-browser) scripting at any given opportunity.</p>
<p>The BFED also realises it is not a feat to drop support for a particular (set of) browser(s) and understands that forgetting about the existence of those users hurts them and their perception of the company/product.</p>
<h2>Accessibility</h2>
<p>The BFED realises that users have different abilities and preferred ways of using a computer. Whether it’s a mouse, finger, thumb, screen reader, keyboard or a combination of all, make websites consumable no matter the audience, screen size or capability of the browser.</p>
<h2>Preprocessors</h2>
<p>When given the choice to add a preprocessor (e.g. LESS, SASS, CoffeeScript etc) to the tech stack, the BFED knows there’s a much deeper impact beyond just “writing less code”.</p>
<p><em>“Will debugging code be more difficult?”</em>, <em>“Might performance degrade?”</em> and <em>“Will I be slowed down due to compile times?”</em> are just some of the <a href="https://adamsilver.io/blog/the-disadvantages-of-css-preprocessors/">questions</a> the BFED will consider to avoid problems in the future.</p>
<h2>UI design</h2>
<p>The BFED embraces the constraints and limitations of the browser so that he/she doesn’t find him/herself in a world of Adaptive Design and UA sniffing because that world is horrible, ill-advised and costly.</p>
<p>It is best to include the BFED early on in the UX design process to save wasting time designing a UI that should ultimately be avoided (see <em><a href="http://bradfrostweb.com/blog/mobile/fixed-position/">Fixed Position</a></em> and <em><a href="https://adamsilver.io/blog/select-boxes-shouldnt-submit-on-change/">Misusing The Select Control</a></em> for more on that) and that can likely be designed more simply.</p>
<p>The BFED will also suggest the use of native form controls realising that browsers will enhance the experience where possible, particularly on mobile, and doesn’t try to control the look and feel too much as he/she knows that the brand will <em>not</em> suffer because of that decision.</p>
<p>The BFED will also suggest that links are styled as such, and with underlines, so that users can identify them within copy.</p>
<h2>Third party CSS and Javascript libraries and frameworks</h2>
<p>The BFED will carefully select third party code based on the quality of the code itself by reviewing source code, <em>not</em> based on the popularity of said code. He/she favours reliability over popularity every time.</p>
<h2>UI architecture</h2>
<p>The BFED will adhere to the following quote:</p>
<blockquote>
<p>As a Lead JavaScript Engineer, I try to get my team to write as little JavaScript as possible.</p>
<p><cite>James Norton</cite></p>
</blockquote>
<p>Furthermore, the BFED realises that <a href="https://adamsilver.io/blog/the-problem-with-single-page-applications/">Single Page Applications cause severe problems</a> and that avoiding them and leaning on the server appropriately, provides a better experience and reach.</p>
<h2>CV</h2>
<p>The BFED will develop a site based on the context of the problem and provide a solution accordingly. He/she will not just use [insert buzz word here] to improve his/her chances of finding another job based on the current technology fad in order to increase their day rate.</p>
<h2>Conclusion</h2>
<p>Be a great front-end developer. Be boring.</p>
<h2>Addendum</h2>
<p><a href="https://medium.com/simple-human/addendum-to-the-boring-front-end-developer-468dfc75d896#.1umggvug5">My response</a> to Hacker News comments.</p>
<p>Inspired by <a href="https://capwatkins.com/blog/the-boring-designer">The Boring Designer</a> by Cap Watkins’ — thank you.</p>
Select boxes shouldn’t submit on change2014-09-17T00:00:00+00:00https://adamsilver.io/blog/select-boxes-shouldnt-submit-on-change/<p>Some forms that let users sort a list sometimes consist of single select box without a submit button.</p>
<p>Instead the form is submitted when the user selects an option (<code>onchange</code>) using JavaScript.</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/select-box-submit.png" alt="" width="100%">
<figcaption>Top: a select box without a button (bad). Bottom: a select box with a button (good).</figcaption>
</figure>
</div>
<p>The reason for this is usually to declutter the interface and save users a click.</p>
<p>But not only are these poor reasons to omit the submit button but doing this can cause issues for keyboard users and screen reader users.</p>
<h2>How it affects keyboard users</h2>
<p>A form without a button uses JavaScript to submit the form when the <code>onchange</code> is triggered by selecting a new option.</p>
<p>But some browsers wrongly fire the <code>onchange</code> event when the user presses the <kbd>Down</kbd> key.</p>
<p>So as a user moves from the first option to the second, the <a href="http://html.cita.illinois.edu/script/onchange/onchange-example.php">form will be submitted before the user has a chance to move to the third option and beyond</a>.</p>
<p>This happens in a number of Windows browsers like Chrome, Opera and Internet Explorer 9 and under.</p>
<h2>How it affects screen reader users</h2>
<p>Screen reader users can struggle too because the act of reading an option selects the option too.</p>
<p>This again causes the form to be submitted before users intend it to.</p>
<h2>Conclusion</h2>
<p>Submitting a form automatically can be confusing and unfamiliar.</p>
<p>Users may not expect it to happen and it takes control away from the user and fails <a href="https://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-unpredictable-change.html">Web Content Accessibility Guidelines Success Criteria 3.2.2</a>.</p>
<p><a href="http://uxmyths.com/post/115783813605/myth-34-simple-minimal">Minimal interfaces aren’t necessarily simple interfaces</a>. And it’s not a great idea to design interfaces by <a href="http://idyeah.com/blog/2012/06/stop-counting-clicks/">counting clicks</a>.</p>
<p>Accessibility is about making things work for everyone no matter what.</p>
<p>Reducing clicks and decluttering an interface may be the result of a well-designed experience, but they’re not objectives in and of themselves.</p>
<p>Start by giving users a button. It puts users in control no matter what.</p>
JavaScript inheritance2014-09-09T09:00:59+00:00https://adamsilver.io/blog/javascript-inheritance/<p>ECMAScript doesn’t have an <em>inherit</em> function. But you can mimic the functionality yourself if you need to.</p>
<p>Here’s a ready made inherit function you can use in your project:</p>
<pre><code>// namespace
var lib = {};
// cloneObject function
// For browsers that have Object.create
if(Object.create) {
lib.cloneObject = function(o) {
return Object.create(o);
};
} else {
lib.cloneObject = (function() {
var Fn = function() {};
return function(o) {
Fn.prototype = o;
return new Fn();
};
})();
}
// innherit function
lib.inherit = function(Sub, Super) {
// Clone parent's prototype to child's prototype
Sub.prototype = lib.cloneObject(Super.prototype);
// Assign super constructor to child constructor
Sub.superConstructor = Super;
// Assign child as the child constructor
Sub.prototype.constructor = Sub;
};
</code></pre>
<p>As an example you might want a superhero to inherit the features of a regular person. A person constructor might look like this:</p>
<pre><code>function Person(name) {
this.name = name;
}
Person.prototype.sayName = function() {
return "My name is:" + this.name;
};
var bob = new Person('Bob');
bob.sayName(); // "My name is Bob"
</code></pre>
<p>A superhero has some differences. They won’t tell you their identity. Instead they will tell you their alias. The code for this is as follows:</p>
<pre><code>function Superhero(name, alias) {
// call parent constructor so Superheros have name
Superhero.superConstructor.call(this, name);
this.alias = alias;
}
// Inherit the features of a Person
lib.inherit(Superhero, Person);
// Override method so that Superheros only tell you their alias
Superhero.prototype.sayName = function() {
return "Can't tell you that but my alias is: " + this.alias;
}
// Call parent method if you need to
Superhero.prototype.revealIdentity = function() {
return Superhero.superConstructor.prototype.sayName();
};
var batman = new Superhero("Bruce Wayne", "Batman");
batman.sayName(); // "Can't tell you that but my alias is Batman"
batman.revealIdentity(); // "My name is Bruce Wayne"
</code></pre>
The problem with single page applications2014-08-11T09:00:01+00:00https://adamsilver.io/blog/the-problem-with-single-page-applications/<p>Many people in the web community believe that SPAs (single page applications) give users a superior user experience.</p>
<p>But most of the time, SPAs give users an unfamiliar, slow and fragile experience. Furthermore SPAs are much harder make.</p>
<p>In this article, I’ll explain why that is. But before I do let’s make sure we’re on the same page about what SPAs actually are.</p>
<h2>What’s an SPA?</h2>
<p>You might think about MVC, data flow and client-side templating when you think of SPAs. But they‘re not the defining characteristics of SPAs.</p>
<p>In actual fact, you can use all those things to create rich, but more traditional <a href="http://roca-style.org/">ROCA-style</a> sites.</p>
<p>SPAs can be defined as applications that handle routing or navigation using client-side JavaScript.</p>
<p>In other words, instead of letting browsers handle the browsing, the application code hijacks it in order to change the URL, make requests and render responses itself using JavaScript.</p>
<p>Using JavaScript to do the very thing that browsers are made for and already do for free is the cause of all the problems.</p>
<h2>1. Going back and forward quickly and reliably</h2>
<p>Browsers store history so that pages load quickly when the user clicks back. Daniel Puplus explains in <a href="https://medium.com/joys-of-javascript/4353246f4480">Building Single Page Applications</a> that:</p>
<blockquote>
<p>“When a user presses the browser’s back button they expect the change to happen quickly and for the page to be in a similar state to how it was last time they saw it.<br><br>
“In the traditional web model the browser will typically be able [to] use a cached version of the page and linked resources.<br><br>
“In a naive implementation of a SPA hitting back will do the same thing as clicking a link, resulting in a server request, additional latency, and possibly visual data changes.”</p>
</blockquote>
<p>To give users the expected, fast experience, we need to emulate the same native browser behaviour using JavaScript. This means:</p>
<ol>
<li>storing pages in memory, local storage, client-side databases or cookies.</li>
<li>working out when to retrieve the cached pages and when to invalidate them.</li>
</ol>
<p>For (2) there needs to be logic to work out whether the user is changing the URL manually — by clicking a link or typing a URL directly in the location bar.</p>
<p>Or by pressing the browser back or forward buttons which is <a href="http://stackoverflow.com/questions/2008806/how-to-detect-if-the-user-clicked-the-back-button">not achievable as far as I know</a>.</p>
<h2>2. Scroll position</h2>
<p>Browsers remember the scroll position of pages you’ve visited. Daniel Puplus again explains how SPAs cause trouble here:</p>
<blockquote>
<p>“Lots of sites get this wrong and it’s really annoying. When the user navigates using the browser’s forward or back button the scroll position should be the same as it was last time they were on the page. This sometimes works correctly on Facebook but sometimes doesn’t. Google+ always seems to lose your scroll position.”</p>
</blockquote>
<p>To fix this, our code needs to store, retrieve and apply the correct scroll position when the user navigates back and forth.</p>
<h2>3. Cancelling navigation</h2>
<p>When a user clicks cancel or a link, the browser will stop any in-flight requests.</p>
<p>SPAs retreive entire (data for) pages using AJAX. So there could be several requests in-flight. The first request could finish last. Or a user could click (and request) the same link twice.</p>
<p>This is problematic because its inefficient, will use up people’s data unnecessarily and cause visual glitches as subsequent requests finish that should have been cancelled.</p>
<p>The code needs to handle all of these cases.</p>
<p>To let users cancel requests, we need to put a custom cancel button in the UI – which isn’t desirable.</p>
<h2>4. Handling unsaved changes</h2>
<p>In a traditional web application, we can warn users of unsaved changes using the <code>beforeunload</code> event. But SPAs don’t navigate, which means this event won’t fire. So this needs reimplimenting from scratch.</p>
<h2>5. Search engine ranking</h2>
<p>Search engine optimisation is usually an afterthough when building SPAs. But retrofitting this is difficult and costly.</p>
<p>Creating a separate dedicated server-rendered site for search engines is wasteful and means having to maintain a lot of extra code.</p>
<p>With a traditional ROCA style site we get this for free.</p>
<h2>6. Loading CSS and JS</h2>
<p>As SPAs grow in size, loading all of the assets will get really slow. This typically leads to conditionally loading CSS and JavaScript.</p>
<p>But <a href="http://blog.getify.com/labjs-script-loading-the-way-it-should-be/">script loaders contain hacks, slow down development and reduce reliability</a>.</p>
<h2>7. Analytics</h2>
<p>Analytics tools track page views by default — you just add the analytics code to the page.</p>
<p>But SPA pages aren’t real pages which means additional logic needs to be written to make analytics can track pseudo pages when they get rendered.</p>
<h2>8. Automated functional testing</h2>
<p>Like the previous point, automation tools like Selenium know when a page has loaded.</p>
<p>But automation tools don’t automatically know a page has been loaded with AJAX.</p>
<p>THis makes tests more challenging to write to handle timeouts and they’ll be slower to execute.</p>
<h2>9. Memory leaks</h2>
<p>As SPAs don’t load pages, the page may stay open for a long time.</p>
<p>This increases the chance of memory leaks which can cause the browser to crash, and battery powered devices to drain quickly.</p>
<h2>10. Loading indicators</h2>
<p>The browser’s loading indicator provides an accurate, predictable and familiar experience to users across all sites the user visits in their browser.</p>
<p>As SPAs use AJAX to render pages, we need to create a custom loading indicator from scratch. Besides the extra work, custom loading indicators tend to be inaccurate and unfamiliar.</p>
<p>This can cause users to click the link again which slows users down further.</p>
<h2>11. JavaScript will fail</h2>
<p><a href="https://adamsilver.io/blog/javascript-isnt-always-available-and-its-not-the-users-fault/">JavaScript can fail for many reasons</a>. And most SPAs aren’t written using <a href="https://adamsilver.io/blog/progressively-enhanced-javascript/">progressive enhancement</a>.</p>
<p>The result of which is a blank screen and leaving users to refresh the page or give up.</p>
<h2>12. They’re probably slower</h2>
<p>SPAs are very likely to be slower than server-side rendering because:</p>
<ul>
<li><a href="https://jakearchibald.com/2016/fun-hacks-faster-content/">loading and rendering a page with AJAX is usually slower</a></li>
<li><a href="https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4">JavaScript takes additional time to load and run</a></li>
<li>extra coded is needed to fix the issues above</li>
</ul>
<blockquote>
<p>“Fun fact: it takes a Moto G4 about 15.66 times longer to evaluate 2.1MB of (decompressed) JS than it does to decode a 10MP image.”—<a href="https://twitter.com/csswizardry/status/971077284034678784?s=19">Harry Roberts</a></p>
</blockquote>
<h2>13. They’re not accessible by default</h2>
<p>Read <a href="http://www.craigabbott.co.uk/one-page-applications-are-not-accessible">One-page-applications are not accessible</a> by Craig Abbott.</p>
<h2>14. They just don’t feel right</h2>
<p>Read <a href="https://www.freecodecamp.org/news/why-i-hate-your-single-page-app-f08bb4ff9134/">Why I hate your Single Page App</a> by Stefan Tilkov.</p>
<h2>Summary</h2>
<p>Many people think SPAs provide faster and better experiences but in reality they create a slower, unfamiliar and inaccessible experience.</p>
<p>Worse is that they’re harder to make in the first place.</p>
<p>And it‘s not just me – Twitter, Lifehacker and Delicious went back to more traditional architectures for these reasons.</p>
<p>You can read more below:</p>
<ul>
<li><a href="https://blog.twitter.com/2012/improving-performance-on-twittercom">Improving performance on Twitter</a></li>
<li><a href="http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs">Breaking The Web With Hash Bangs</a></li>
<li><a href="http://blog.del.icio.us/?p=1174">Delicious changes</a></li>
</ul>
<p>JavaScript is not better at browsing than browsers.</p>
<p>Instead let the browser handle that and focus on creating rich, robust and accessible experiences by following the <a href="https://en.wikipedia.org/wiki/Rule_of_least_power">rule of least power</a> and following the principles of <a href="https://roca-style.org/">ROCA</a>.</p>
Javascript namespacing2014-07-11T09:00:01+00:00https://adamsilver.io/blog/javascript-namespacing/<p>Namespaces help you organise code so that it’s easy for others to find their way around it. In Javascript, they also minimise the number of <a href="http://www.yuiblog.com/blog/2006/06/01/global-domination/">global variables</a>.</p>
<p>Javascript doesn’t (at the time of writing) have a dedicated way to namespace components. But we can do it using object literals.</p>
<p>I’ll show you how to namespace your components with an example application. The application represents a zoo. The zoo has a couple of animals plus some additional information.</p>
<p>This is the directory structure for the zoo:</p>
<pre><code> zoo/
zoo.js
zoo.information.js
animals/
zoo.animals.js
zoo.animals.Penguin.js
zoo.animals.Tiger.js
</code></pre>
<p>The root namespace resides inside <code>zoo.js</code>.</p>
<pre><code>var zoo = {};
</code></pre>
<p>The animals need a sub level namespace too which resides inside <code>zoo.animals.js</code>.</p>
<pre><code>// zoo.animals.js
zoo.animals = {};
</code></pre>
<p>You will notice that the namespace matches the name of the file. This consistency helps you find the relevant component later.</p>
<p>The zoo has a penguin and a tiger definition which reside inside <code>zoo.animals.Penguin.js</code> and <code>zoo.animals.Tiger.js</code> respectively. The penguin definition is shown below:</p>
<pre><code>zoo.animals.Penguin = function() {
// constructor
};
</code></pre>
<p>If you need to store some information in the zoo you can do so as follows:</p>
<pre><code>// zoo.information.js
zoo.information = {
name: "My Awesome Zoo",
address: "52 Zoo Lane, ZA1 2AP"
};
</code></pre>
<p>Avoid deeply nested hierarchies wherever possible. But don’t worry about having a lot of files. You can concatenate them for production.</p>
Forms with multiple submit buttons are problematic2014-03-20T09:00:01+00:00https://adamsilver.io/blog/forms-with-multiple-submit-buttons-are-problematic/<p>Multiple submit buttons are problematic for keyboard users because forms can be submitted by pressing <kbd>Enter</kbd> when a field is focused.</p>
<p>When this happens the form will be submitted as if the user pressed the <em>first</em> button within the <code><form></code> element which isn’t always desirable.</p>
<h2>An example</h2>
<p>Take the following address form with a postcode lookup.</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/multiplesubmit.png" alt="Delivery address form" width="100%">
<figcaption>Delivery address form with multiple submit buttons</figcaption>
</figure>
</div>
<p>Pressing <kbd>Enter</kbd> from with any of the form fields will submit the form as if the ‘Find address’ button was clicked.</p>
<p>This at little odd as the ‘Save address’ button is the primary action here.</p>
<h2>How to solve this</h2>
<h3>Separate into 2 forms</h3>
<p>Split each action into 2 completely separate forms.</p>
<p>In this case, let users first search for their address via the postcode but give users an option to enter their address manually.</p>
<p>Having one action perform makes things simple and clear.</p>
<div class="image">
<figure>
<img src="https://adamsilver.io/assets/images/multiplesubmitsplit.png" alt="Delivery address form split" width="100%">
<figcaption>Delivery address postcode lookup with just one call to action</figcaption>
</figure>
</div>
<h2>2. Put the main submit button first</h2>
<p>If you can’t separate the forms, then you need to identify the form’s main action.</p>
<p>If it doesn’t naturally come first in the <code><form></code> then you can duplicate it and place it at the top of the form.</p>
<p>To remove it visually you can use this:</p>
<pre><code>.visually-hidden {
border: 0!important;
clip: rect(0 0 0 0)!important;
height: 1px!important;
margin: -1px!important;
overflow: hidden!important;
padding: 0!important;
position: absolute!important;
width: 1px!important;
}
</code></pre>
<p>This introduces the problem that when a user tabs to the hidden button, the interface will appear unresponsive.</p>
<p>To fix this, give the button a <code>tabindex="-1"</code> attribute to stop the button being navigable via keyboard.</p>
<h2>Checklist</h2>
<ol>
<li>Avoid multiple submit buttons whenever possible</li>
<li>If you must have multiple submit buttons put the primary action first</li>
<li>If putting it first visually doesn’t work, then hide it visually with CSS and the tabindex attribute</li>
</ol>