In my work as an accessibility consultant, there are some frequent problems I find on people’s websites. One that’s come up a lot recently is that people are making custom select inputs for their forms. I can tell that people are trying to make them accessible, because they’ve added ARIA attributes or visually-hidden instructions for screen reader users. Sometimes they use a plugin which claims to be accessible. And this is great, I love that folks want to do the right thing! But so far I’ve never come across a custom select input which actually meets all of the WCAG AA criteria.

Often I recommend to people that they use the native HTML select element instead. Yes, they’re super ugly, but as Scott Jehl shows us in his article Styling a Select Like It’s 2019 they are a lot easier to style than they used to be. They come with a lot of accessibility for free – they’re recognised and announced clearly by all screen reader software, they work reliably and predictably with keyboards and touch, and they look good in high contrast themes.

But sometimes, I can’t recommend the select input as a replacement. We want a way for someone to choose an item from a list of options, but it’s more complicated than just that. We want autocomplete options. We want to put images in there, not just text. The optgroup element is ugly, hard to style, and not announced by screen readers. The focus styles are low contrast. I had high hopes for the datalist element, but although it works well with screen readers, it’s no good for people with low vision who zoom or use high contrast themes.

Select inputs are limited in a lot of ways. They’re frustrating to work with when you have something which looks almost like what you want, but is too restricted to be useful. We know we can do better, so we make our own.

Let’s work out how to do that while keeping all the accessibility features of the original.

Semantic HTML

We’ll start with a solid, semantic HTML base. A select input is essentially a text input which restricts the possible answers, so let’s make a standard input.

User Type

Then we need to show everyone who can see that there are options available, so let’s add an image with an arrow, like the native element.

User Type

For this input, we’re going to use ARIA attributes to represent the information in the icon, so we’ll give it an empty alt attribute so screen readers don’t announce its filename.

Finally, we want a list of options. An unordered list element is a sensible choice here. It also lets screen reader software understand that these bits of text are related to each other as part of a group.

  
User
  
Author
  
Editor
  
Manager
  
Administrator

You can dynamically add or remove options from this list whenever you need to. And, unlike our element inside a , we can add whatever we like inside the list item. So if you need images to distinguish between lots of very similar-named objects, or to add supplementary details, you can go right ahead. I’m going to add some extra text to mine, to help explain the differences between the choices.

This is a good base to begin with. But it looks nothing like a select input! We want to make sure our sighted users get something they’re familiar with and know how to use already.

Styling with CSS

I’ll add some basic styles similar to what’s in Scott Jehl’s article above.

We also need to make sure that people who customise their colours in high contrast modes can still tell what they’re looking at. After checking it in the default Windows high contrast theme, I’ve decided to add a left-hand border to the focus and hover styles, to make sure it’s clear which item is about to be chosen.

This would be a good time to add any dark-mode styles if that’s your jam. People who get migraines from bright screens will thank you!

JavaScript for behaviour

Of course, our custom select doesn’t actually do anything yet. We have a few tasks for it: to toggle the options list open and closed when we click the input, to filter the options when people type in the input, and for selecting an option to add it to the input and close the list. I’m going to tackle toggling first because it’s the easiest.

Toggling

Sometimes folks use opacity or height to hide content on screen, but that’s like using Harry Potter’s invisibility cloak. No-one can see what’s under there, but Harry doesn’t cease to exist and you can still poke him with a wand. In our case, screen reader and keyboard users can still reach an invisible list.

Instead of making the content see-through or smaller, I’m going to use display: none to hide the list. display: none removes the content from the accessibility tree, so it can’t be accessed by any user, not just people who can see. I always have a pair of utility classes for hiding things, as follows:

.hidden-all {
  display: none;
}

.hidden-visually {
    position: absolute;
    width: 1px;
    height: 1px;
    padding: 0;
    overflow: hidden;
    clip: rect(0,0,0,0);
    white-space: nowrap;
    -webkit-clip-path: inset(50%);
    clip-path: inset(50%);
    border: 0;
} 

So now I can just toggle the CSS class .hidden-all on my list whenever I like.

Browsing the options

Opening up our list works well for our mouse and touch-screen users. Our styles give a nice big tap target for touch, and mouse users can click wherever they like.

We need to make sure our keyboard users are taken care of though. Some of our sighted users will be relying on the keyboard if they have mobility or dexterity issues. Usually our screen reader users are in Browse mode, which lets them click the arrow keys to navigate through content. However, custom selects are usually inside form elements. which pushes screen reader software to Forms Mode. In Forms mode, the screen reader software can only reach focusable items when the user clicks the Tab key, unless we provide an alternative. Our list items are not focusable by default, so let’s work on that alternative.

To do this, I’m adding a tabindex of -1 to each list item. This way I can send focus to them with JavaScript, but they won’t be part of the normal keyboard focus path of the page.

csOptions.forEach(function(option) {
    option.setAttribute('tabindex, '-1')
}) 

Now I can move the focus using the Up and Down arrow keys, as well as with a mouse or tapping the screen. The activeElement property of the document is a way of finding where the keyboard focus is at the moment. I can use that to loop through the elements in the list and move the focus point forward or back, depending on which key is pressed.

function doKeyAction(whichKey) {
  const focusPoint = document.activeElement
  switch(whichKey) {
    case: 'ArrowDown':
      toggleList('Open')
      moveFocus(focusPoint, 'forward')
      break
    case: 'ArrowUp':
      toggleList('Open')
      moveFocus(focusPoint, 'back')
      break
  }
}

Selecting

The Enter key is traditional for activating an element, and we want to match the original select input.

We add another case to the keypress detector…

case 'Enter':
  makeChoice(focusPoint)
  toggleList('Shut')
  setState('closed')
  break 

… then make a function which grabs the currently focused item and puts it in our text input. Then we can close the list and move focus up to the input as well.

function makeChoice(whichOption) {
    const optionText = whichOption.documentQuerySelector('strong')
    csInput.value = optionText
}

Filtering

Standard select inputs have keyboard shortcuts – typing a letter will send focus to the first item in the option which begins with that letter. If you type the letter again, focus will move to the next option beginning with that letter.

This is useful, but there’s no clue to tell users how many options might be in this category, so they have to experiment to find out. We can make an improvement for our users by filtering to just the set of options which matches that letter or sequence of letters. Then sighted users can see exactly how many options they’ve got, and continue filtering by typing more if they like. (Our screen reader users can’t see the remaining options while they’re typing, but don’t worry – we’ll have a solution for them in the next section).

I’m going to use the .filter method to make a new array which only has the items which match the text value of the input. There are different ways you could do this part – my goal was to avoid having to use regex, but you should choose whatever method works best for your content.

function doFilter() {
  const terms = csInput.value
  const aFilteredOptions = aOptions.filter(option => {
    if (option.innerText.toUpperCase().startsWith(terms.toUpperCase())) {
    return true
    }
  })
  // hide all options
  csOptions.forEach(option => option.style.display = "none")
  // re-show the options which match our terms
  aFilteredOptions.forEach(function(option) {
    option.style.display = ""
  })
} 

Nice! This is now looking and behaving really well. We’ve got one more problem though – for a screen reader user, this is a jumble of information. What’s being reported to the browser’s accessibility API is that there’s an input followed by some clickable text. Are they related? Who knows! What happens if we start typing, or click one of the clicky text things? It’s a mystery when you can’t see what’s happening. But we can fix that.

ARIA

ARIA attributes don’t provide much in the way of additional features. Adding an aria-expanded='true' attribute doesn’t actually make anything expand. What ARIA does is provide information about what’s happening to the accessibility API, which can then pass it on to any assistive technology which asks for it.

The WCAG requirements tell us that when we’re making custom elements, we need to make sure that as a whole, the widget tells us its name, its role, and its current value. Both Chrome and Firefox reveal the accessibility tree in their dev tools, so you can check how any of your widgets will be reported.

We already have a name for our input – it comes from the label we associated to the text input right at the start. We don’t need to name every other part of the field, as that makes it seem like more than one input is present. We also don’t need to add a value, because when we select an item from the list, it’s added to the text input and therefore is exposed to the API.

But our screen readers are going to announce this custom select widget as a text entry field, with some images and a list nearby.

The ARIA Authoring Practices site has a pattern for comboboxes with listboxes attached. It tells you all the ARIA you need to make screen reader software give a useful description of our custom widget.

I’m going to add all this ARIA via JavaScript, instead of putting it in the HTML. If my JavaScript doesn’t work for any reason, the input can still be a plain text field, and we don’t want screen readers to announce it as anything fancier than that.

csSelector.setAttribute('role', 'combobox') 
csSelector.setAttribute('aria-haspopup', 'listbox')
csSelector.setAttribute('aria-owns', '#list') 
csInput.setAttribute('aria-autocomplete', 'both')
csInput.setAttribute('aria-controls', 'list')

The next thing to do is let blind users know if the list is opened or closed. For that task I’m going to add an aria-expanded attribute to the group, and update it from false to true whenever the list changes state in our toggling function.

The final touch is to add a secret status message to the widget. We can use it to update the number of options available after we’ve filtered them by typing into the input. When there are a lot of options to choose from, this helps people who can’t see the list reducing know if they’re on the right track or not.

To do that we first have to give the status message a home in our HTML.

I’m using our visually-hidden style so that only screen readers will find it. I’m using aria-live so that it will be announced as often as it updates, not just when a screen reader user navigates past it. Live regions need to be present at page load, but we won’t have anything to say about the custom select then so we can leave it empty for now.

Next we add one line to our filtering function, to find the length of our current list.

updateStatus(aFilteredOptions.length)

Then we send that to a function which will update our live region.

function updateStatus(howMany) {
    console.log('updating status')
    csStatus.textContent = howMany   " options available."
}

Conclusion

Let’s review what we’ve done to make an awesome custom select input:

• Used semantic HTML so that it’s easily interpreted by assistive technology while expanding the types of content we can include in it
• Added CSS styles which are robust enough to survive different visual environments while also fitting into our branding needs
• Used JavaScript to provide the basic functionality that the native element has
• Added more JavaScript to get useful functionality that the native element lacks
• Carefully added ARIA attributes to make sure that the purpose and results of using the element are available to assistive technology and are updated as the user interacts with it.

You can check out my custom select pattern on GitHub – I’ll be making additions as I test it on more assistive technology, and I welcome suggestions for improvements.

The ARIA pattern linked above has a variety of examples and customisations. I hope stepping through this example shows you why each of the requirements exists, and how you can make them fit your own needs.

I think the volume of custom select inputs out there shows the ways in which the native select input is insufficient for modern websites. You’ll be pleased to know that Greg Whitworth and Simon Pieters are working on improving several input types! You can let them know what features you’d like selects to have. But until that work pays off, let’s make our custom selects as accessible and robust as they can possibly be.

Be a Better UX Designer with Heuristics

November 23, 2019 • Better, Designer

I like usability heuristics. Instead of us all solving the same problems over and over again, we can refer to tested and proven heuristics to inform user interface designs.

Heuristics can improve the efficiency of your design team in two important ways;

Settle Disagreements

In design reviews or day to day collaboration, designers will disagree about a specific design choice or direction. For example: what formats a date entry field should allow? What if I tell you the answer is already known.

Jakob Nielsen’s famous UI design heuristic includes a heuristic about error prevention. It states that you should strive to prevent errors rather than trying to design good error messages. The implication is that instead of asking the user to enter a date, let them select a date form a calendar.

This example is a bit a contrived, but the idea applies in many scenarios. If you find that your team gets stuck in arguments about designs, try and define a set of agreed-upon heuristics that you and your team will follow. Then whenever you get stuck in a disagreement, try and use the heuristics to settle the differences.

More efficient usability tests

I often hear UX designers complain about the lack of user testing as part of their design process. And I agree, there is no substitute for getting your product in front of a user and seeing first hand the stumbling blocks and pain points of your designs. But if we struggle to find resources and time to perform usability testing, then we should aim to use the time with users most effectively.

In a usability test with a user, we want the user to identify the problems that we are unaware of and that we are incapable of identifying on our own. However, sometimes, a user interface has a usability issue that is obvious and has an obvious solution. Then instead of the user identifying invisible problems, they get stuck on the obvious ones.

Therefore, before we go into a usability study, we should make sure that the design is without obvious usability flaws. And the best way to identify such issues is with an expert review using usability heuristics.

An expert review is a purposeful evaluation of a user interface using a set of heuristics as the evaluation criteria. The idea is to identify areas where the design is in breach of the heuristics, which indicates possible usability issues.

To understand when and how to use expert reviews, consider the following differences between the two:

• Expert reviews require less planning and preparation
• Expert reviews cannot identify all usability issues
• Usability tests can identify more issues than expert reviews can
• Usability tests results are more convincing than expert reviews

There is no substitute for usability testing with real users. We are not our users and we will never be able to design a perfect user interface the first time. But usability testing is hard and usually happens less frequently than we would like. Therefore, we should include purposeful expert reviews in our design process to identify obvious usability issues. Then our usability reviews can identify problems that we were unaware of an unable to find ourselves.

Would The Web Be Better With One Good Browser?

November 15, 2019 • Better, Would

When Tim Berners-Lee gave us the WorldWideWeb in 1990, it was the first and only web browser. But it didn’t remain alone for long.

Even in those early days of the web, there was plenty of competition for web browser market share: Mosaic, MidasWWW, SlipKnot, Arena, Netscape, and Internet Explorer emerged around that time, too, and duked it out for the top spot for the better part of a decade.

So, if there’s always been a battle of the browsers, why do we care so much about how many browsers are available today? You’d think it wouldn’t matter much. After all, browsers are nothing more than a shell through which we access the web, right? Superficially, that’s true. As consumers, browsers provide us with key navigational elements that help us move around the web: the home button, address bar, back and forward buttons, bookmarks, and more.

As designers and developers, though, you understand that browsers play a bigger role in the user experience than just what users can see at the top of their screen. With various rendering engines used to interpret and display code, we see varying results in how browsers show our websites to their users. As such, it’s a worthwhile question to ask: Would we be better off if there were only one browser?

The State of Web Browsers Today

There was a time when Internet Explorer was the reigning champ of browsers. However, it failed to prioritize the user experience and to adhere to web standards put in place for that very purpose. It was this failure that ultimately opened the door for other browsers to usurp IE from the lofty position it sat upon for years.

Here is what the global browser market share looked like in 2010, according to StatCounter:

As you can see, IE was quickly losing popularity to Firefox, which provided a much better (i.e. less intrusive) browsing experience for its users.

What’s interesting to note, though, is that Firefox didn’t remain the frontrunner for long. Just a year later, Chrome surpassed Firefox in terms of market share.

Eight years later, this is what the browser market share looks like:

It’s a totally different picture. Chrome owns the majority market share and there are no major waves detected in the market. Everyone’s browser preferences seem to be holding steady.

Even when we throw mobile browsers into the mix, the same holds true.

Notice how Chrome’s percentage share shrinks slightly, from 69.08% to 63.72%. That’s thanks to Safari, which cuts a bit deeper into Google’s share on mobile:

Even so, it’s clear that Chrome is an untouchable force when it comes to browsers. So, why don’t the others give up and just let Chrome run it all? Wouldn’t it be a better experience for users and, by consequence, make it easier for designers and developers to build for the web?

Is One Browser the Solution?

This is a tricky question to answer. Because if we’re being honest with ourselves, there’s really only one browser that we realistically could default to without the entirety of the web going bonkers: Chrome.

That said, there are some (albeit legit) concerns that will probably keep that from happening.

Concern #1: Privacy Is at Stake

Google is the entity behind Chrome and Chromium, the open source project that helps others create better browsing experiences. Browsers like Opera, Brave, and Vivaldi have been built with Chromium. Even Microsoft’s own browser, Edge, is getting a makeover with Chromium.

While it’s great that Google’s doing its part to bring order and stability to the web, that doesn’t negate the fact that there are serious privacy concerns when it comes to the Chrome browsing experience.

There’s the issue with cookies, for starters. Some web browsers have gone so far as to block websites from using cookies, by default. Google, on the other hand, leaves this to its users to configure on their own. Granted, the passing of GDPR has brought more awareness to the issue of privacy and cookie tracking on the web. But in terms of getting support from the leading browser, consumers aren’t going to get much there.

Then, there’s the matter of how much tracking Google is doing on its own. After all, if someone is using Chrome, that means they’re using other Google products as well. So, how much data is Google collecting as it watches its users go from its email platform to Google Drive to its search engine and so on? Probably a lot. Which will only strengthen the monopoly it has over the web.

Concern #2: Google Doesn’t Play Fair

Google has demonstrated that it doesn’t always have others’ interests in mind when it passes down big decisions. And that’s something that consumers and companies alike should be concerned with.

For instance, there’s the recent news about what Google wants to do to the Web Request API; specifically, how it relates to ad-blocking extensions.

Its reason for this? It says it’s moving its Chrome extensions to the Declarative Net Request API in order to improve user privacy. Some suspect, however, that Google wants to introduce its own API in order to cripple ad-blockers (which obviously impact its own ability to generate revenue through ads).

There are also assertions that Google edges out products it doesn’t like (including competing browsers) using less-than-reputable means. For example, the former CTO at Mozilla, Andreas Gal, told Bloomberg:

“There were dozens and dozens of ‘oopsies,’ where Google ships something and, ‘oops,’ it doesn’t work in Firefox. They say oh we’re going to fix it right away, in two months, and in the meantime every time the user goes to these sites, they think, ‘oh, Firefox is broken.’’

It’s not just the big competitors that Google has edged out either. The same article reports that developer Samuel Maddock had a similar experience. After building a browser using Chromium, Google refused to give him permission to use one of their products to complete it. When he sought out a reason for the rejection, there was none given.

Concern #3: Innovation Will Slow

When you look at the history of web browsers, you’ll see that it’s not just the leading options that have improved the browsing experience.

Take Opera, for instance, which was responsible for giving us browser tabs, thumbnail speed dial, and mouse gestures. Even if it’s never held a large share of the browser market, it’s still been a major innovative force, and one that the big players have had no problem copying.

Which leads me to wonder: Without multiple browsers competing and collaborating, is it possible that innovation will stagnate?

You could argue that we wouldn’t need to upgrade the browsing experience if we were given one really high-quality option to work with. But as we’ve already seen, Google doesn’t always look out for its users. So, who’s to say that it wouldn’t just kick back and wait to make improvements to its browser only when it served its own interests?

That’s not how technology works. As our needs change as consumers and the world around us becomes more complicated, technology always needs to be on the cutting edge. It would be rather reckless to give up on less popular browsers whose mere presence leads to greater innovation in how we move around the web.

Wrap-Up

As it stands now, we’re better off with multiple browsers. We could definitely stand to trim down the list of browsers that are available — for the sake of development and testing — but it would require the leading browsers to collaborate and work on building a more standardized web.

You can’t design for the majority of your visitors; you have to design for all of them.

As for what you can do with this information, here are my final thoughts:

You can’t design for the majority of your visitors; you have to design for all of them.

So, first things first: familiarize yourself with the differences between the leading web browsers. If you don’t have this set up already, install Chrome, Firefox, and Safari on your desktop and mobile devices. And put them into rotation as you spend time on the web, for work or personal use. You’ll quickly learn where these browsers fall short and where they shine.

Next, take a look at Google Analytics. Which browsers do your visitors use? What about in years past? If you don’t have any data to go on, then you need to assume that visitors could be coming in from any and all browsers.

And, finally, build websites that adhere to basic web standards. You’ll find information on this at the World Wide Web Consortium. Until our web browsers come together to align their rendering engines and browsing experiences, we have to do what we can to bring consistency and stability to the web.

Better Design With Deep Thinking

November 14, 2019 • Better, Design

About The Author

Eric is the founder of UI UX Training where he leads workshops focused on UX research, design facilitation, and UX copywriting. He has spent the past 18 years …
More about
Eric
…

Task switching is a design killer. Find out why switching and interruptions are even more serious than you think and how biology makes it difficult to resist the temptation to just check your email every few minutes. Learn how to slay the distraction dragon with five practical tips for increasing focus as you tackle challenging design problems.

Interruptions, administrative tasks, and too many meetings are among the common complaints voiced by today’s professionals. When was the last time someone complained about a canceled meeting? In other words, everyone understands what hinders productivity, right?

Not so fast, says computer scientist Cal Newport. While we all realize that interruptions and fragmented time are troublesome, we fail to recognize:

• The frequency of interruptions: We convince ourselves that we are focusing on one task at a time, such as a complex interaction design problem. Yet, every ten minutes or so, we check email or answer a text. Yes, we’re performing one task at a time, but the duration of that task is brief.
• The cost of these interruptions: As Newport explains on a recent episode of Hidden Brain: “Even those very brief checks that switch your context even briefly can have this massive negative impact on your cognitive performance. It’s the switch itself that hurts, not how long you actually switch.” (Emphasis mine)

This task switching was the focus of a study by business professor Sophie Leroy. She gave participants a cognitively demanding activity, such as solving a puzzle, and then briefly interrupted them before they completed it. When they returned to the original task, their performance dropped. As Leroy explains, these “results indicate it is difficult for people to transition their attention away from an unfinished task and their subsequent task performance suffers.”

Leroy calls this carryover from one activity to another “attention residue,” meaning that people are still thinking about the previous task even as they turn to the new one.

The most effective way to avoid attention residue is to structure your work in a way that reduces interruptions. Such structure requires understanding the difference between deep and shallow work.

Deep Work, Shallow Work, And Why They Matter

“Deep work is the ability to focus without distraction on a cognitively demanding task,” writes Newport in his book Deep Work. This work allows us to absorb, understand, and act on complicated information. Examples including coding, complex project plans, user research, and sophisticated design work.

Shallow work refers to tasks that do not require extensive thought and focus such as filling out expense reports and answering emails, texts, and Slack messages.

Shallow tasks are necessary. The question is how much time to devote to shallow and deep work and how to structure work in a way that facilitates reflection and concentration.

The Solution: Five Practical Tips For Pursuing Deep Work

Tip 1: Jump Into Design Work

Avoid the temptation to text or check email first thing. Put your phone on do not disturb. Get out your sketch pad or open your design tool and challenge yourself to solve one gnarly design problem by 10:00 am.

While this tip sounds like common sense, it’s not quite so straightforward because we are conditioned to respond to signals around us: “External triggers are cues from our environment that tell us what to do next. These are the dings and pings that prompt us to check our email, answer a text, or look at a news alert,” explains habit expert Nir Eyal in a post about distraction.

Eyal continues: “Competition for our attention can come from a person as well, such as an interruption from a coworker when we are in the middle of doing focused work.”

Computer scientist Cal Newport expands on this point by explaining the biology behind the itch to respond. When we don’t reply promptly to a text or email, we feel like we are ignoring someone from our tribe. Emotionally, it’s the modern-day equivalent of ignoring someone who is tapping on our shoulder as we sit around the fire. In short, it’s difficult to ignore messages and requests from co-workers.

Difficult but not impossible. Extend jumping into design work by blocking out untouchable time on your calendar. What about emergencies? “The short answer is that there really never are any,” writes podcaster and New York Times bestselling author, Neil Pasricha in Why You Need an Untouchable Day Every Week. These untouchable days involve deep, creative work.

While most professionals cannot set aside an entire day each week, they can mark two-hour blocks on their calendar a few times each week. Colleagues simply see “busy” when viewing your calendar. While not foolproof, this quiet signal shows that you know how to manage your time in order to engage in the deep work that your job requires.

Tip 2: Kickstart Your Brain With Useful Questions

By definition, deep work takes time and considerable brain resources. Sometimes we need a cognitive boost before tackling the problem head-on. When this is the case, ease into deep work by composing a list of questions to stimulate reflection. For example:

• What is the organization trying to accomplish?
• How does this site, product, or app align with that goal?
• If revising an existing design: What would I do differently if I could recreate the design from scratch?
• What would I do now if there were no legacy system constraints?

Note that these questions involve design but also encourage reflection beyond the immediate design challenge. The latter is important because the longer you work on a product or project, the easier it is to develop design blinders.

Easing into deep work or jumping in with both feet are often useful as long as it’s possible to avoid those nettlesome distractions. Even so, everyone gets stuck and needs time to regroup and let the mind wander.

Tip 3: Schedule Unstructured Thinking Time

Just as designers and other professionals need time to think through complex problems, they also need time to let the mind wander. The reason is the science behind “shower moments,” when ideas seem to arrive out of the blue.

In fact, the brain needs time for incubation, the psychological term for the unconscious recombination of thought processes after they are stimulated by conscious mental effort such as working on a specific design problem. In other words, when you set aside a strenuous mental task and do something less demanding, the brain is able to process and organize your thoughts to form new ideas.

Effective leaders value unstructured thinking time as outlined in How to Regain the Art of Lost Reflection. Jeff Weiner, CEO at LinkedIn, blocks at least 90 minutes for reflection and describes these buffers as “the single most important productivity tool” he uses. Susan Hakkarainen, Chairman and co-CEO of Lutron Electronics, uses 40-minute walks to reflect explaining that “Thinking is the one thing you can’t outsource as a leader. Holding this time sacred in my schedule despite the deluge of calls, meetings, and emails is essential.”

In short, designers should take their cues from these business leaders. Give your brain a break.

Tip 4: Vote It Off The Island

This tip comes from the Harvard Business Review article Stop Doing Low-Value Work by Priscilla Claman. She cites the example of a controller who was producing monthly reports that nobody read. He sent a list to his colleagues asking them to identify the three or four most important reports. He simply stopped writing the reports that no one was reading.

Another approach is to request permission to not do something such as asking customers if they really want their receipts. The point, writes Claman, is to stop doing something that is not important but to ask first to avoid getting in trouble. It’s vital that we stop ourselves from doing unimportant work.

Designers can identify possibly unimportant work by asking if:

• Every wireframe must include detailed annotations;
• Every design deliverable must include a detailed design document;
• It’s really necessary to produce many variations of a design when studies about choice and decision making show that too many options make it harder to reach a decision.

No one wants to feel as if their work is sitting on a virtual shelf. By asking clients and stakeholders what matters to them, you’ll cater to their needs and save time by discarding unnecessary tasks.

The next step is to assess the remaining important work to determine how much time you can, and should, devote to deep thinking.

Tip 5: Distinguish Deep And Shallow Work

Follow the steps below to make this assessment concrete, something you can point to and share with your boss.

1. Identify the activities that you consider deep work such as planning a usability test, drawing wireframes, or mocking up a prototype.
2. Identify shallow work activities like answering emails, attending administrative meetings or meetings tangentially related to your core responsibilities.
3. Estimate the amount of time you spend on deep and shallow work each week.
4. Meet with your boss for thirty minutes and ask her what she thinks the ratio of deep to shallow work should be. Ask for a specific number. If you disagree, politely ask if you may experiment with a different ratio for one month.
5. Then, stick to the agreed-upon number for one month. Document any changes to your productivity, anything that contributes to a better product or service. After one month, report these findings to your boss.

This approach offers two advantages:

• It’s usually wise to solicit the boss’s support.
• A single proposal about deep work will not change an entire organization. Involving management, however, can serve as a catalyst for broader change just as the Google Ventures Design Sprint influenced the design process at Google and beyond.

Why Deep Work Makes Everything Better

Deep work allows designers and developers to thrive by leveraging their skills to solve complex problems and create better products and designs. Better products are likely to boost the bottom line while thriving and highly satisfied employees are more likely to stay (reducing turnover) and put their best selves forward.

Perhaps the best news for employers is that deep work does not require adding staff. The solution, explains computer scientist Cal Newport, is to re-configure work and communication. In other words, it’s not more people; it’s the same people managing work differently.

For example, agencies often answer to clients and need to be available at a moment’s notice. Rather than require every employee to be tethered to a phone or laptop, Newport suggests assigning a different employee each day to a dedicated email or a special “bat phone.” This shows the client their importance to the agency while also allowing designers to concentrate on designing, building, and solving problems.

Conclusion

Deep work is the ability to focus on challenging tasks like design and coding. Frequent interruptions make deep work nearly impossible and impose a high financial cost. In this piece, we’ve described five tips for maximizing the time you devote to deep work.

1. Jump into design work.
   
   Draw fresh wireframes or work on a new design problem before checking emails and Slack messages. Block two-hour chunks on your calendar to allow time for deep thinking.
2. Kickstart your brain with useful questions.
   
   Take a few minutes to ask what you are trying to accomplish and how it aligns with the company’s keep performance indicators (KPIs). Alignment with KPIs is especially important for user experience designers who are frequently asked to justify their budget
3. Schedule unstructured thinking time.
   
   Take a walk, stare out the window, or whatever allows your mind to wander. This “downtime” allows the brain to form new connections.
4. Vote it off the island.
   
   Are you writing reports that no one reads? Are you scheduling meetings that your co-workers find less than useful? Ask your colleagues if it’s okay to stop. They might respond with a gleeful “yes!”
5. Distinguish deep and shallow work.
   
   Then, meet with your boss to arrive at the right balance between these two types of work.

Further Reading on SmashingMag:

• How People Make Decisions
• Maximizing The Design Sprint
• Creating Online Environments That Work Well For Older Users
• SmashingConf Videos: User Experience Psychology And Performance

(ah, il)

Better Markdown in VS Code

October 26, 2019 • Better, Markdown

This entire post was written using Markdown in Visual Studio Code. That may seem a bit ridiculous. However, with a few tweaks VS Code can become an excellent tool for writing.

Writing in VS Code doesn’t have the features of Ulysses, the Syncing of Bear App or the polish of IA Writer. It doesn’t have a mobile app. However, it is free and the experience is quite good. If you’re considering a new Markdown editor, it is worth a try—especially if you’re an engineer.

The trigger for me was a new work computer. My old 2015 Macbook Pro couldn’t hold a charge. Previously, I had Typed, a now discontinued product from RealMac Software. It was fine until it began playing zen music on startup—an odd feature for a text editor. Despite my effort to disable it, I could not fix this issue. I needed a new Markdown editor.

Unfortunately, dealing with the Mac App store is a giant pain on work computers. That ruled out a lot of options. I tried many free tools, but none of them felt like a decent writing option. There were tons of bad fonts, contrast or typesetting.

Then I decided to see if I could wrangle VS Code into a decent writing experience. It’s pretty customizable, right? I was pleasantly surprised.

About Visual Studio Code

If you’re not an engineer, Visual Studio Code is a text editor. It’s what many engineers at my company, SalesLoft, use to create software. Don’t let that scare you though. It’s an excellent tool for writing.

First you’ll need to Download VS Code from Microsoft. It’s free for Mac and Windows. Once you do that, we’ll install extensions and tweak a few settings.

Extensions

Extensions in VS Code are similar to browser extensions. They are little pieces of software that enhance another app.

I’ve listed the extensions we need below. To begin installing them you can click the blocks icon in the bottom of the navigation bar or you can hit CMD Shift X. This should open an extension search bar. Simply search for the ones below and hit the green install button when you find it.

Alternatively, clicking install from the links should prompt you to open and install the extension in VS Code.

Markdown All in One is a requirement for anyone that wants to write in Markdown. The extension adds keyboard shortcuts, sane formatting for tables of contents and lists, Markdown tables and a few other enhancements.

Code Spell Checker catches common spelling mistakes. It’s useful since VS Code does not have spellcheck installed by default.

The implementation is a little strange—a light bulb appears above the paragraph with an issue. However, it didn’t take long to get used to, and even the best writers need spellcheck.

An interesting side effect of this type of spell check is that I try and guess the correct spelling of the word instead of right clicking and selecting the first option. Maybe this is a good interaction in the long run?

Word Count adds a small word counter when working in a Markdown file. Helpful, but not required.

Wanted: A Hemingway-like extension. Hemingway is a decent editor with one killer feature. It highlights complex sentences, passive voice and suggests phrases with simpler alternatives. I would love something like this for VS Code. Ideally, the feature can be toggled with a shortcut.

Settings

Once you’ve installed VS code and the related extensions, we’ll tweak the settings to improve the writing experience.

To get to the settings tab hit CMD , or click the cog icon in the bottom left of VS Code.

Then we’ll want to open the JSON view by clicking the icon with the page and arrow in the top right of the application. This is the JSON view of all your settings. Unless you’ve made a few changes, this file should be blank.

Paste the following code into that file and hit CMD S to save. We’ll discuss what this does below.

{
 // Global VS Code Settings appear here 
     "[markdown]": {
     "editor.fontFamily": ""IA Writer Duo S", monospace",
     "editor.fontLigatures": true,
     "editor.fontSize": 16,
     "editor.lineHeight": 26,          
     "editor.wordWrap": "wordWrapColumn",
     "editor.wordWrapColumn": 72,        
     "zenMode.centerLayout": true,
     "editor.lineNumbers": "off",
     "editor.quickSuggestions": false,
     },
 }

Markdown-specific settings

You might have noticed [markdown] in brackets. What this does is help us separate settings from Markdown files from other file types. If you’ll use VS Code for writing software, you’ll want to do this. Otherwise, it’s probably fine to have these settings at the global-level.

Typography

The first setting here changes the font to Duo, an excellent open source font from IA Writer. The font is based on IBM Plex Mono, which is also an excellent font. Here’s what IA says about it.

What is Duospace?

Duospace is a notion familiar from Asian fonts where there are single and double width characters. Our candidate is a bit different. It offers single and four 1.5 width characters.

Duospace gives 50% more space to the letters m, M, w and W. It takes two of those to get back in step with the monospace rhythm. The advantage over proportional fonts is that you keep all benefits of the monospace: the draft like look, the discernibility of words and letters, and the right pace for writing. Meanwhile, you eliminate the downside stemming from mechanical restrictions that do not apply to screen fonts.

You can use Menlo or whatever default fonts you’d like here, but I’d strongly encourage you to download Duo. Especially, since it’s free. If the monospace style isn’t for you, consider Quattro.

Here I’ve changed the font size to 16 and the line height to 26. This size and leading change makes the text much easier to read. If you’d prefer a larger font than 16, multiply the font size by 1.6. This is a foolproof way to get legible text. For example you could use font size 18 and line height 29 or font size 20 and line height 32. Play around with it and see what works best for you.

The last type setting here enables font ligatures. The main reason you’ll want this is so the italic version of a font to be used when you’re writing italicized text.

Text wrapping

The second set of settings control text wrapping. Most text editors are meant for code, not articles, and disabled wrapping help makes that easier to read.

However, if you’re trying to read a paragraph like this you want lines to be between 60 and 80 characters. Anything longer than that and it becomes uncomfortable to read. Personally, 72 characters is about right for me.

VS Code features

The final settings here alter a few VS Code features to make writing a better experience. Line numbers just add noise when writing, so it’s best to remove them. Quick suggestions are helpful for inserting variables you’ve previously used but will become a nuisance when writing your blog post.

Then there’s the Zen Mode setting, which forces a center column when in Zen Mode. You can enable Zen Mode at any time by pressing CMD K and then Z.

Themes

This section was going to be about the best writing VS Code themes I found. After experimenting with a few options, I’ve decided the basic Dark theme works better than anything I found though.

Other tips

There are a few ways to center the text in VS Code. The first thing I tried was by going to View > Appearance > Centered Layout. However, it seems a little noisy. I prefer dragging the menu bar out a little further is an easy way to center the text.

There are some code editor features that are pretty useful when writing. For example, I always have the outline tab open to the left. When writing in Markdown, it populates headers and subheaders. It’s useful when working on long-form posts.

There’s a little icon with a split-screen and a magnifying glass. This opens a preview of the file the Markdown stripped away. It also makes it easy to copy the text to WordPress. That’s how this post came to be!

If you only plan to use VS Code for writing, consider setting Markdown as your default file type. You can do that by adding the following to your global settings.

"files.defaultLanguage": "markdown",

At this point, you’re all done configuring Visual Studio Code for writing Markdown. Your next blog post awaits!

References

Chris Chinchilla, Customizing Visual Studio Code for Writing, Hacker Noon, Published 6/14/2019

Writing Mode in VS Code, Diéssica Gurskas, Published 2/28/2018

J/A, VS Code: markdown and word wrap, Smokeless and Unleaded, Published 4/28/2018

Oliver Reichenstein, Duospaced! In Search of the Perfect Writing Font, IA.net, Published 11/23/2017

Typed.com is Closing Down, RealMac Software, Published 8/3/2017

Better data vs. big data: The importance of taking a lean data approach

October 1, 2019 • Better, importance

Every year companies invest billions of dollars collecting customer data to apply to marketing analytics. According to a recent CMO survey, reliance on marketing analytics to make decisions has increased from 30% to 42% in the past five years, with B2C companies using analytics the majority of the time.

At the same time, identifying the right data continues to be a challenge for brands. As my business partner and Wharton School Professor Eric Bradlow has highlighted many times before, CMOs and their teams need to focus on “better data, not big data.” And yet, we continue to see companies cast a wide net, collecting any and all available data, rather than taking a more targeted approach.

This is a discussion that’s happening with increasing regularity at the CMO and board level. To be successful, marketers must not only identify, but hyper-focus on applying the right first-party and third-party data to anticipate and meet the needs of their target customers.

To discuss this topic in greater detail, I recently chatted with Gartner Senior Director Charles Golvin. Our conversation, coupled with my own experience, solidified three areas companies need to focus on to identify, collect and apply better data… while maintaining transparency with customers.

1. Find the right balance

Over the years, I’ve worked at many organizations which take a data-driven approach to marketing. These include T-Mobile and Microsoft, and while they each have their own particular strengths, there are some common missteps that even very large, well-funded enterprises make when identifying what first and third–party data to focus on, to guide their brand and marketing strategy.

One common challenge is that companies tend to rely too heavily on data alone when crafting their marketing and product strategies. In some cases, companies seek out more and more data – in effect creating an ever-expanding “data lake” for the organization to draw from. The collection of data sometimes becomes a goal itself, losing site of the rationale and practical use for these data. 

As Golvin notes, “We continue to see a ‘more is better’ attitude  inside many organizations, collecting data for data’s sake, without fully considering the risks and do we really need it.”

In addition to the downside risks, collecting terabtyes or petabytes of data to consolidate and apply to business or marketing strategy is both expensive and sometimes impractical.

Companies can get stuck in analysis paralysis, or become overly focused on backward–facing data, or vanity metrics, rather than getting into the actual signal of what’s happening with customers. In other cases, I’ve seen companies disregard customer data because they think it’s incomplete.

In both instances, it comes down to balancing the first–party data you have available with direct customer feedback, as well as feedback from employees and business partners. At the end of the day, data needs a human filter and you need to strike the right balance to stay abreast of your target customers’ – and competitors’ – evolving behaviors.

2. Only collect data you can deliver value with

To adopt a leaner data strategy, brands need to hyper-focus on the needs of your target customers, and that starts with asking the right questions:

• What data is essential to improving CX and Customer Lifetime Value (CLV) over time? 
• When customers provide you with their personal data, what value are you offering in exchange?
• What sources should we use for th data?
• How can we minimize the amount of data our company collects (“minimum viable data”)? 

By asking these questions and sourcing the right data, firms are to better understand their target customers, their purchasing behavior, habits and preferences, and in turn deliver better products, experiences and marketing offers.

By creating focus, CMOs can also vastly improve ROI for their marketing analytics investment (another topic Eric and I recently explored with Charles).

3. Build trust and transparency with customers

Another key area that is paramount for brands today is being 100% transparent with customers in how they collect and use their data. The past two years have been absolutely littered with examples of brands that have not been transparent about how they collected or used customer data.

“Companies need to be more transparent about what data they use, while also understanding the pros, cons and risks,” shares Golvin. “More data doesn’t necessarily lead to greater business intelligence, and can expose your brand in ways that impact customer trust.”

Most consumers today are willing to share at least some of their personal data in exchange for a product, service or better experience from a brand they trust. At the same time, consumers have become far more leery of brands having access to their personal information, even when shared in aggregate or anonymously.

One Fortune 100 CIO, for example, told me that he has seven different email addresses he uses to try to manage unwanted email communications from vendors, a perfect example of the scattergun approach taken by some marketers, with seemingly no clue.

Collecting data, without making consumers leery of your brand, requires marketers to take the right approach. Brands should take a “minimum viable data” approach to collecting data, and then need to be clear about their intention and tell customers what data they are collecting and why.

When the right data are collected in the right way, brands can not only build trust but also improve CLV, brand equity and loyalty over time by delivering more personalized and relevant experiences.

---

Opinions expressed in this article are those of the guest author and not necessarily Marketing Land. Staff authors are listed here.

---

About The Author

« Older posts