Web Typography: Numerals

Oct. 17th, 2017 12:48 pm
[syndicated profile] alistapart_feed

A note from the editors: We’re pleased to share an excerpt from Chapter 2 of Richard Rutter’s new book, Web Typography.

When it comes to numbers we have just ten digits. Throw in a comma and a period and we’ve got grand total of twelve characters. You might not think that would present much of a challenge to a typographer, but to a professional typesetter (that’s you if you’re a designer) numerals require far more nuance and variation than you might think at first glance. Numbers deserve the same care and attention as text - this excerpt reveals the numerical situations you should be looking out for, and how to tackle them to benefit your reader.

Use old-style numerals in running text

In ‘Ligatures and abbreviations’ we established that writing systems based on the Latin alphabet, in addition to Greek and Cyrillic, use a bicameral script, with each letter represented by two different forms – uppercase and lower (or majuscule and minuscule, to use more formal terms). The same is true of numerals. We have at our disposal ‘uppercase’ numbers 0123456789 called lining or titling numerals, and ‘lowercase’ numerals 0123456789 called old-style or text numerals.

Unlike capital and lowercase letters, different forms of numbers do not convey different meanings; they are, however, an essential component of the typographer’s palette. Just as a string of capital letters in the middle of a sentence SHOUTS at your reader, so numbers set in lining numerals call undue attention to themselves. Are pounds, dollars, dates and quotas really more important than the words and ideas which give them context and meaning?

Treat numbers as you would letters, making sure they don’t stand out unnecessarily. Do this by using old-style numerals in all your running text. Most modern, professional fonts will include both old-style and lining numerals as OpenType features. One or other of these styles will be used for the default numbers. More often it will be the old-style numerals, but there is no strict rule or consistency, and the choice of default is down to the type designer.

It’s also the case that the vast majority of fonts are neither modern nor professional, if modern means OpenType-enabled and professional means designed with both sets of numerals. Take Georgia, for example. Designed by Matthew Carter in 1993 as a screen font for Microsoft, it is extremely well put together, elegant and appealing, and one of the most popular and widely distributed fonts in the world. But it is not packaged as an OpenType font and so only contains one set of numbers, in this case old-style numerals. Times New Roman, which is similarly widespread but, again, not as an OpenType font, is packaged only with lining numerals. Georgia and Times New Roman are so widely distributed because they are bundled free of charge with Windows and Mac operating systems. However, both these fonts – like many others – are available to buy in professional versions, which do come as OpenType fonts complete with both sets of numerals, small caps and many other features.

Graphic showing numerals in Times New Roman and Georgia
Top: Numerals in Times New Roman Pro.
Bottom: Numerals in Georgia Pro.

To specify old-style numerals, set the font-variant-numeric property with a value of oldstyle-nums. If most of what you’re designing on a page is running text, then your best approach is to set old-style numerals so that they are inherited from the <body>.

body {
    font-variant-numeric: oldstyle-nums;
}

For legacy browsers requiring font-feature-settings, use the onum OpenType feature tag. As explained in ‘Ligatures and abbreviations’, you can add an @supports rule to cater for legacy browsers that only support font-feature-settings:

body {
    font-feature-settings: "onum" 1;
}
@supports (font-variant-numeric: oldstyle-nums) {
    body {
        font-feature-settings: normal;
        font-variant-numeric: oldstyle-nums;
    }
}

Many sans serif fonts of the early to mid-twentieth century, including Helvetica, were never designed with anything other than lining numerals. This is one of the reasons why Helvetica is rarely your best choice for body text. That said, the lining numerals are less of a problem in Helvetica than they are in some other typefaces. As we saw in ‘Designing paragraphs: line spacing’, Helvetica has a large x-height. A consequence of this is that its lowercase letters are closer in stature to its lining numerals when compared to other sans serif fonts such as Futura and Avenir, which have far smaller x-heights.

Graphic showing two styles of numerals in Avenir

Compared with old-style numerals, lining numerals shout loudly in Avenir.

Clearly Paul Renner and Adrian Frutiger, the designers of Futura and Avenir respectively, recognised the need for old-style numerals in their fonts as both these typefaces were designed with them from the start. Sadly, the versions of Futura and Avenir widely distributed with Apple devices have lining numerals as the default, and do not include old-style numerals as OpenType features (the macOS version of Avenir Next, however, does include them).

Use lining numerals in headings

Old-style numerals are your go-to glyphs for making numbers sit well in running text. For the same reason they are at ease with lowercase letters, so old-style numerals feel uncomfortable in close proximity to capital letters. If you set headings in anything other than sentence case, in particular ALL CAPS, or Title Case, then don’t use old-style numerals. Lining numerals will sit far more naturally in the company of uppercase letterforms.

Graphic showing Lining and Old-Style Numerals

Lining numerals sit more naturally in headings than old-style numerals.

On those occasions when numbers are the star attraction, lining numerals are the way to give them the attention they crave. Old-style numerals have a wavy rhythm to them, with some numbers reaching upwards towards the capitals, some squatting at the x-height, and others ducking down below the baseline: 1234567890. This is why they work so well in continuous reading – they replicate the patterns of words in running text. However, if your reader is scanning a sequence of numbers, looking for patterns, making comparisons, or hunting for data in a list, table or other setting, they will find it far easier to do so with the familiarity and evenness of lining numerals. To specify lining numerals, set the font-variant-numeric property with a value of lining-nums:

h1 {
    font-variant-numeric: lining-nums;
}

For legacy browsers requiring font-feature-settings, use the lnum OpenType feature tag.

Use proper subscripts and superscripts

Subscripts and superscripts are tiny numerals which are lowered or raised. They are used in chemical and mathematical formulas, as footnote indicators, and other specialist situations. For example: ‘Caffeine1 is C8H10N4O2.’ Mark this up meaningfully in HTML using the <sup> and <sub> elements:

Caffeine<sup>1</sup> is C<sub>8</sub>H<sub>10</sub>
N<sub>4</sub>O<sub>2</sub>.

Browsers’ default styling for <sup> and <sub> is to take a regular numeral, make it a bit smaller, and raise or lower it accordingly:

Graphic showing default styling for sub and sup tags

This works fine up to a point, but the numerals are still a little too big aesthetically and they affect the line spacing, causing unevenness in the rhythm:

Graphic showing the default styling for sub and sup tags in the context of a paragraph

Most professional fonts contain properly designed subscripts and superscripts built in as OpenType features. These numerals are smaller and squatter than regular numbers, and because their position relative to other characters is part of their design, the line spacing is unaffected:

Graphic showing proper sub and sup tags

To use proper subscripts and superscripts, use the font-variant-position property, like this:

sub { font-variant-position: sub; }
sup { font-variant-position: super; }

Unfortunately, this still leaves us with a problem: the browser’s default styling is still applied. Our special subscript character is being made smaller and it’s getting moved downwards, affecting the line spacing:

Graphic showing various sub styles

Top: Default <sub> styling. Middle: Proper subscripts with browser default styling. Bottom: Proper subscripts only.

The styles the browser applies to our subscript characters are these:

vertical-align: sub;
font-size: smaller;

We need to remove those styles to get the desired effect, so our rule now becomes:

sub { vertical-align: baseline;
      font-size: inherit;
      font-variant-position: sub; }

That will work fine for browsers that support OpenType. But browsers that don’t will get C8H10N4O2, a degraded rendering compared with the browser defaults. To address this we can use an @supports rule to check if the browser supports font-variant-position and only override the browser’s default <sub> styling if that’s the case:

sub { font-variant-position: sub; }

@supports ( font-variant-position: sub ) {
  sub { vertical-align: baseline;
        font-size: inherit; }
}

For legacy browsers requiring font-feature-settings, use the sups OpenType feature tag for superscripts, and subs for subscripts. If we factor these in, we get comprehensive, backwards-compatible style rules, but where two simple properties should have done the job, we now have a far more verbose proposition:

Subscripts

sub { font-feature-settings: "subs" 1; }

@supports (font-variant-position: sub) {
    sub { font-feature-settings: normal;
          font-variant-position: sub; }
}
@supports ((font-variant-position: sub) or (font-feature-settings: "subs" 1)) {
    sub { vertical-align: baseline;
          font-size: inherit; }
}

Superscripts

sup { font-feature-settings: "sups" 1; }

@supports (font-variant-position: super) {
    sup { font-feature-settings: normal;
          font-variant-position: super; }
}
@supports ((font-variant-position: super) or (font-feature-settings: "sups" 1)) {
    sup { vertical-align: baseline;
          font-size: inherit; }
}

Reference notes with superscripts

One particular use of superscripts is for footnotes. When you reference notes using numbers, use true superscripts in the text but full-size numbers in the notes themselves.

Show footnotes in context

While we’re on the subject of footnotes, it’s worth making a brief diversion into how the web improves their usability compared with the limitations of paper.

Many forms of writing, including academic papers, historical novels, detailed journalism and non-fiction books such as this one, contain additional citations, explanations and thoughts referred to within the text itself. A symbol is used to connect the note to the relevant location in the text. The symbols employed as references to annotations are either superscripted numbers or an esoteric series of devices starting with asterisks* and processing through daggers† to double daggers‡ and beyond.

Since the advent of mass printing in the Victorian era, the notes themselves have typically been positioned either at the bottom of the referring printed page (footnotes), or at the end of a chapter or the entire work (endnotes). However, this approach means the notes are located away from their position within the body of text. This can disturb the reader who wishes to refer to the annotation as they proceed through the text. The connected point in the text may well be halfway through a sentence in the middle of a paragraph at some point higher up the page, or on a different preceding page altogether, and attempting to return to it disrupts the reader’s rhythm.

An earlier approach by medieval scribes and Renaissance printers placed notes in the margins (side notes) rather than at the bottom of the page. By including notes as marginalia, the annotations are present where needed and can be read with little more than a glance away from the main text.

A crop of a hand-written document
A side note in a 9th-century manuscript. Source: Einsiedeln, Stiftsbibliothek, Codex 172(1128)

Although side notes are an improvement on footnotes, both solutions are designed within the confines of the two-dimensional printed page. The web is an interactive medium and provides us with at least three dimensions in which to work, implying you can use the z-axis to place the note on top of the main text.

Enable your reader to reveal the note on demand in the very place they are reading. Put simply, link to the footnote using a conventional symbol, but have it pop up in the vicinity of the link, thus providing a thoroughly modern solution impossible within the limitations of a printed page.

Partial screenshot
Clicking a superscript could pop up a footnote in situ.

Want to read more?

This excerpt from Web Typography will help you get started. Order the full copy today.

Cover of Web Typography

PostSecret in Nebraska Last Week

Oct. 14th, 2017 11:33 pm
[syndicated profile] post_secret_feed

Posted by Frank

—Email—

Hi Frank,

We met at your Nebraska PostSecret Live! event last night.  I’m the woman who drove down from Minnesota and who told my secret to everyone about why that was so significant to me.


Firstly, I want to thank you so much for everything. Your acknowledgement 
and validation of my struggle means more to me than you can ever know. I have never felt anything like that in my life. My heart is overflowing with love for everyone I met there.

 


Like you talked about, we often keep secrets from ourselves, and I think in the end the real secret was I couldn’t forgive myself. There is still a ways to go, but realizing this I can let go a bit and start to heal. I know I will never gain back what was lost completely. But like I said in my secret, I am gaining back a piece of what was lost. Right now that’s honestly more than I thought I’d ever 
have.

-C


PS. Oh, and you managed to pull off my hat quite nicely.

[syndicated profile] alistapart_feed

A note from the editors: We’re pleased to share an excerpt from Chapter 4 of Tony Byrne and Jarrod Gingras’s new book, The Right Way to Select Technology, available now from Rosenfeld Media.

After establishing a solid business case, enterprises will typically turn to assembling the oft-dreaded “requirements document”—or more accurately, a set of documents, spreadsheets, and diagrams that compose a multiheaded requirements package.

Large requirements packages actually provide a false sense of security. Modern digital technology entails real people interacting with screens. Technology selection leaders need to capture those interactive requirements, but also remain realistic at this phase about their inability to fully know what their enterprise really needs and will adopt eventually.

This section will show how long spreadsheets full of “what” requirements really don’t work, and instead will focus on “how” a solution might work. The best way to reveal key differences among suppliers is to craft narrative “user stories” with “personas” (rough equivalent to use-cases with actors).

In other words, tell testable stories. Business users have stories; so do customers, partners, developers, sysadmins, designers, auditors, and others.

This section will lead you through an approach to telling those stories in a way that’s more conducive to differentiating among technology suppliers.

Capture requirements that don’t suck

A solid understanding of your organization’s requirements is essential to project success. Getting that understanding will involve information gathering from various stakeholder groups, potentially utilizing a variety of techniques.

Note that at this stage, your requirements should be business- and user-focused, rather than detailed technical specifications. (We’ll get to those in Chapter 6, “Ask Questions That Really Matter”). The final key step here is to analyze and prioritize your requirements, in order to determine which ones to emphasize in the RFP and subsequent demos and bake-offs.

How not to articulate requirements

Whatever you do, avoid “check box” requirements sheets where you ask the vendor: “Can you do this, can you do that?”

As a practical matter, vendors have seen all these questions and have figured out how to check all the boxes. But what’s worse is that such spreadsheets convert the understanding of what should be a human-centered, interactive activity into a bloodless series of row-by-row activities better suited for robots repeatedly performing rote tasks.

The typical pitfall here starts like this: a business analyst (BA) goes around interviewing users and other stakeholders, and she ends up with a long wish list of features. Excel allows her to categorize those features, which is handy, but because of the limitless rows, her spreadsheet will tend to emphasize comprehensiveness over business impact.



To address the challenge of priorities, the typical enterprise process asks stakeholders to rank their needs, perhaps on a scale of 1 to 5, or using MoSCoW (Must Have/Could Have/Should Have/Won’t Have) or some other methodology. Not surprisingly, this generates a scrum where users compete to identify as many rows of “Must Haves” as possible.

Ultimately, someone will ask the BA to tie back each requirement row to the business case (remember that?), so she then spends several days building new tables and cross-references in Excel. Ultimately, reviewers find exceptions and variants for each feature, so new columns get added. Now the spreadsheet is too big to fit on a standard screen, let alone print out. It’s impressive … and impressively unhelpful.

The government agency with the massive checklist

We once advised a major U.S. federal government agency to select a new portal platform as a hub for small business advice. We came late to the process after an initial round of vendor demos had failed to differentiate clearly among the bidders.

The problem was Excel. Or more specifically, the entire RFP as a 10-tab worksheet, with some sheets going hundreds of rows deeps. Most of the tabs held feature requests—notably categorized by agency department rather than customer persona—with a long series of columns annotating those features. (Our favorite: the ever-beloved “Must be easy to use” requirement.) Nearly all the features were listed as “must have.” They were rigorously cross-tabbed to a long-but vague set of business objectives, but otherwise there was no prioritization.

The vendors didn’t know what to demo, although several gamely tried. Mostly, they just talked about their (voluminous) proposal responses, most of which consisted of declaring, for each row, “We can do that!”

Ultimately, we were able to recraft a more user-centered approach, with a narrower scope, that vendors could reasonably demo against.

Lesson: Stay away from long, feature-based checklists.

Applying UCD principles

There’s a different way to do this than torturing your BA— and everyone else—with long spreadsheets, and it revolves around pursuing a user-centered design (UCD) approach that emphasizes narratives, which we’ll call stories here. People will disagree about the tactics of UCD, but we can generalize overall that a user-centered approach is:

  • Holistic to encompass the entire digital experience (and therefore not feature based)
  • Iterative, where you initially sketch light (and therefore imperfect) requirements and refine them over time via iteration
  • Story-based, with an emphasis on user narratives, often called “journeys” or “top tasks”

There’s much more to UCD, but for our purposes, two key constructs stand out:

  • Personas: User archetypes that guide decisions about technology effectiveness. Personas are useful in the sense that they create a common shared understanding of the user group, but with a human existence to help keep it real.
  • User Stories: A to-be story about the “daily life of” or a journey undertaken by key personas. User stories are exceptionally valuable here because they offer test cases against which you can compare and contrast vendor bidders.

Information gathering

You can chose from among numerous well-known methods for eliciting information needed to create personas and user stories.

  • Document reviews: Including existing and prospective systems diagrams, planning documents, and analytics, but also the information that flows through the anticipated technology, like catalog entries for an ecommerce site, or forms in a document management system
  • Questionnaires: Including customer and employee surveys, as well as specialized questions you might want to pose in advance of any in-person meetings
  • Workshops: A useful way to debrief groups of people, as well as experiment with more forward-looking brainstorming; customer focus groups fall into this category as well
  • Interviewing: Debriefing individual stakeholders one-on-one, where they may become more candid
  • Shadowing: Following stakeholders around for a typical duration of time; this sort of contextual inquiry is often the most useful, but also labor intensive
  • Potentially others …

Different practitioners will take different approaches, and clearly the level of effort here should be commensurate with the anticipated benefits and risks with the new technology.

At Real Story Group when we’re creating personas and scenarios, we like to take a modified contextual inquiry approach. We gather individuals with similar roles in a conference room and debrief the team as a group. Using a projector, we may ask some members to log in to show specific examples of an incumbent system to the group. When we are gathering requirements for an interactive system, we make the environment as interactive as possible to get the maximum information exchange.

We’ll send five questions in advance as the agenda for the workshop:

  1. Show us briefly, on the screen, what you do.
  2. What works well in the existing environment (top three only)?
  3. What doesn’t work well or is missing in the existing environment (top three only)?
  4. How is your work/market/environment/customer changing?
  5. What else is important that we haven’t discussed?

The questions are deliberately open ended, to create as much of an open dialogue as possible. Note the emphasis on “top three”—we don’t want a laundry list of features, but rather the most important problems and opportunities.

Sometimes, it’s hard for line employees to identify potential future opportunities, so it can be useful to introduce the whole process with an educational workshop describing industry best practices or examples of what other enterprises have done with the technology. This is particularly important when selecting a type of technology that the enterprise has never used before.

The question still remains of staying aligned with the initial business plan. We like to book half-hour sessions with interested executives to understand the broader business currents and objectives underneath the technology selection effort.

At this point, a lot of raw material has been accumulated. The next step is to convert it into the two core components of the future RFP: user stories and advanced Q&A.

Tips

  • You will need to invest in both information and process analysis, and this will require document analysis as well as contextual inquiry.
  • Avoid long, undifferentiated, spreadsheet-based feature lists in favor of uncovering material necessary to create key personas and scenarios.
  • Start with the user experience and work your way back into enterprise systems.
  • Avoid the temptation to broaden your scope beyond the original charter.
  • You don’t need to be perfect at this (or any other) phase, so focus inquiry into your stakeholders’ most burning problems or intense needs.

Planning for Accessibility

Oct. 5th, 2017 02:01 am
[syndicated profile] alistapart_feed

A note from the editors: We’re pleased to share an excerpt from Chapter 3 (“Planning for Accessibility") of Laura Kalbag's new book, Accessibility for Everyone, available now from A Book Apart.

Incorporating accessibility from the beginning is almost always easier, more effective, and less expensive than making accessibility improvements as a separate project. In fact, building accessibility into your project and processes has a wealth of business benefits. If you’re looking to make the case for accessibility—to yourself, to coworkers, or to bosses and clients—you might start here:

  • Findability and ease of use: In the broadest terms, accessibility can make it easier for anyone to find, access, and use a website successfully. By ensuring better usability for all, accessibility boosts a site’s effectiveness and increases its potential audience.
  • Competitive edge: The wider your audience, the greater your reach and commercial appeal. When a site is more accessible than other sites in the same market, it can lead to preferential treatment from people who struggled to use competitors’ sites. If a site is translated, or has more simply written content that improves automated translation, increased accessibility can lead to a larger audience by reaching people who speak other languages.
  • Lower costs: Accessible websites can cut costs in other areas of a business. On a more accessible site, more customers can complete more tasks and transactions online, rather than needing to talk to a representative one-to-one.
  • Legal protection: In a few countries, an accessible site is required by law for organizations in certain sectors—and organizations with inaccessible sites can be sued for discrimination against people with disabilities.

Once you’ve made the case for incorporating accessibility into your work, the next step is to integrate an accessibility mindset into your processes. Include accessibility by default by giving accessibility proper consideration at every step in a product’s lifecycle.

Building Your Team

Web accessibility is the responsibility of everyone who has a hand in the design of a site. Design includes all of the decisions we make when we create a product—not just the pretty bits, but the decisions about how it works and who it’s for. This means everybody involved in the project is a designer of some sort.

Each specialist is responsible for a basic understanding of their work’s impact on accessibility, and on their colleagues’ work. For example, independent consultant Anne Gibson says that information architects should keep an eye on the markup:

“We may or may not be responsible for writing the HTML, but if the developers we’re working with don’t produce semantic structure, then they’re not actually representing the structures that we’re building in our designs.”

Leadership and support

While we should all be attentive to how accessibility impacts our specialism, it’s important to have leadership to help determine priorities and key areas where the product’s overall accessibility needs improvement. Project manager Henny Swan (user experience and design lead at the Paciello Group, and previously of the BBC) recommends that accessibility be owned by product managers. The product managers must consider how web accessibility affects what the organization does, understand the organization’s legal duties, and consider the potential business benefits.

Sometimes people find themselves stuck within a company or team that doesn’t value accessibility. But armed with knowledge and expertise about accessibility, we can still do good work as individuals, and have a positive effect on the accessibility of a site. For example, a designer can ensure all the background and foreground text colors on their site are in good contrast, making text easier to distinguish and read.

Unfortunately, without the support and understanding of our colleagues, the accessibility of a site can easily be let down in other areas. While the colors could be accessible, if another designer has decided that the body text should be set at 12 pixels, the content will still be hard to read.

When accessibility is instituted as a company-wide practice, rather than merely observed by a few people within a team, it will inevitably be more successful. When everybody understands the importance of accessibility and their role in the project, we can make great websites.

Professional development

When you’re just starting to learn about accessibility, people in your organization will need to learn new skills and undertake training to do accessibility well.

Outside experts can often provide thorough training, with course material tailor-made to your organization. Teams can also develop their accessibility skills by learning the basics through web- and book-based research, and by attending relevant conferences and other events.

Both formal training and independent practice will cost time away from other work, but in return you’ll get rapid improvements in a team’s accessibility skills. New skills might mean initially slower site development and testing while people are still getting their heads around unfamiliar tools, techniques, and ways of thinking. Don’t be disheartened! It doesn’t take long for the regular practice of new skills to become second nature.

You might also need to hire in outside expertise to assist you in particular areas of accessibility—it’s worth considering the capabilities of your team during budgeting and decide whether additional training and help are needed. Especially when just starting out, many organizations hire consultants or new employees with accessibility expertise to help with research and testing.

When you’re trying to find the right expert for your organization’s needs, avoid just bashing “accessibility expert” into a search engine and hoping for good luck. Accessibility blogs and informational websites (see the Resources section) are probably the best place to start, as you can often find individuals and organizations who are great at teaching and communicating accessibility. The people who run accessibility websites often provide consultancy services, or will have recommendations for the best people they know.

Scoping the Project

At the beginning of a project, you’ll need to make many decisions that will have an impact on accessibility efforts and approaches, including:

  • What is the purpose of your product?
  • Who are the target audiences for your product? What are their needs, restrictions, and technology preferences?
  • What are the goals and tasks that your product enables the user to complete?
  • What is the experience your product should provide for each combination of user group and user goal?
  • How can accessibility be integrated during production?
  • Which target platforms, browsers, operating systems and assistive technologies should you test the product on?

If you have answers to these questions—possibly recorded more formally in an accessibility policy (which we’ll look at later in this chapter)—you’ll have something to refer to when making design decisions throughout the creation and maintenance of the product.

Keep in mind that rigid initial specifications and proposals can cause problems when a project involves research and iterative design. Being flexible during the creation of a product will allow you to make decisions based on new information, respond to any issues that arise during testing, and ensure that the launched product genuinely meets people’s needs.

If you’re hiring someone outside your organization to produce your site, you need to convey the importance of accessibility to the project. Whether you’re a project manager writing requirements, a creative agency writing a brief, or a freelance consultant scoping your intent, making accessibility a requirement will ensure there’s no ambiguity. Documenting your success criteria and sharing it with other people can help everyone understand your aims, both inside and outside your organization.

Budgeting

Accessibility isn’t a line item in an estimate or a budget—it’s an underlying practice that affects every aspect of a project.

Building an accessible site doesn’t necessarily cost more money or time than an inaccessible site, but some of the costs are different: it costs money to train your team or build alternative materials like transcripts or translations. It’s wise to consider all potential costs from the beginning and factor them into the product budget so they’re not a surprise or considered an “extra cost” when they could benefit a wide audience. You wouldn’t add a line item to make a site performant, so don’t do it for accessibility either.

If you’ve got a very small budget, rather than picking and choosing particular elements that leave some users out in favor of others, consider the least expensive options that enable the widest possible audience to access your site. For example, making a carousel that can be manipulated using only the keyboard will only benefit people using keyboard navigation. On the other hand, designing a simpler interface without a carousel will benefit everyone using the site.

Ultimately, the cost of accessibility depends on the size of the project, team, and whether you’re retrofitting an existing product or creating a new product. The more projects you work on, the better you’ll be able to estimate the impact and costs of accessibility.

Want to read more?

This excerpt from Accessibility for Everyone will help you get started. Order the full copy today, as well as other excellent titles from A Book Apart.

Cover from Accessibility for Everyone

UX for Lizard Brains

Oct. 10th, 2017 01:35 pm
[syndicated profile] alistapart_feed

Technology can make magic happen. In seconds, you can find all the blue sandals in a warehouse of millions of shoes. A million people can read the same article without killing one tree. You can undo, unsend, and even unfriend! But here’s the buzzkill: if unanticipated or unwelcome, the magic of technology is confusing, disorienting, and unintuitive—a UX designer’s worst nightmare.

So how can we ensure that the magic we create is intuitive? Designers will often say, “If a design is intuitive, it behaves how a user expects it to.” Well, then … what do users expect?

We want to know the following whenever we find ourselves in a new environment (physical or digital):

  • What are the objects?
  • Where are the objects?
  • How do these objects relate to me?
  • How do these objects relate to each other?
  • What is my role as an object within this environment?

In physical spaces, these don’t require explicit thought to answer. However, in digital spaces, they often do. That is because our “lizard brains”—the part of the brain involved in motivation, emotion, learning, and memory—evolved alongside the physics of solid objects. Consequently, users may feel unsure when designers flout the perceptual expectations forged in the physical world. Without knowing what and where the objects are, we feel blind. Navigating feels uncomfortable. Taking action might even feel impossible.

The remainder of this article introduces three ways to design digital objects that “play nice” with our evolved expectations of the physical world. By doing our best to concretize the dematerialized things of our screen-based world, we give our lizard brains better affordances for understanding.

Lesson one: avoid shapeshifting objects

The properties of user interfaces need to be consistent for us to learn them well. We hunger for stable landmarks in the often ambiguous maze of digital interfaces.
Andrew Hinton, Understanding Context

Objects in the real world don’t usually change form as they change context. When I bring a new toaster home from the store, it doesn’t change into a different toaster. When I remove a vase from the cabinet, it doesn’t turn into a coffee mug. Humans expect object permanence; we are taken aback when objects unexpectedly change shape.

Why do babies love peekaboo so much? It’s a great way to practice the fundamentals of object permanence, an important lesson in survival (e.g., just because the tiger went behind the rock does not mean it has disappeared). Because babies are still coming to terms with this concept, peekaboo makes for a rollicking good time. So we might assume that if we up the ante on the surprise-factor, the game would be even more fun, right? Nope. Researchers measuring the level of toddlers’ delight during a series of hacked games of peekaboo discovered that the game loses its appeal when a different face pops up after hiding. The older the child, the more this hack kills the game. Evolution seems to be telling us: it’s not cool when objects suddenly change. But all that peekaboo practice is for naught when trying to navigate a digital world of shapeshifting objects.

For instance, when this article was in the form of a Google Doc, it lived in both the Google Docs and the Google Drive environments. Depending on the environment, the article’s module changed form and function.

Screenshot showing the same document with different menus in Google Docs (shorter) and Google Drive (longer)
Different menu options in Google Docs and Google Drive.

Moving from Docs to Drive, the shape of the document module shifts from about a 3:5 rectangular ratio to a 1:1 square ratio. If I want to see when I last opened a document, I will find that information directly on the module while in Docs; but within Drive, I must look to a disembodied side panel (not shown). Both modules have a menu of actions, but accessing it requires different interactions. (In Docs, I click the “more” icon; in Drive, I right-click the module.) Worst of all, the menu contains almost completely different options in each module! Only “Remove” and “Rename” are found in both menus. Adding insult to injury, even the icons for “Rename” are different.

Chart and screenshot of the differences in the menus between Google Docs and Google Drive
The form and behavior of the document module are significantly different on Google Docs than on Google Drive.

We could chalk up the inconsistencies of Google Drive and Google Docs to siloed teams, but shapeshifting objects are common within products, too. On Meetup.com, the digital representation of my next meetup morphs multiple times across the site. Looking at the homepage, it displays as a big red banner at the top of the screen.

Screenshot of Meetup.com showing the alert for next meetup.
Meetup’s next-up module is highlighted in bold red at the top of the homepage when you’re logged in.

Scrolling down the homepage to the calendar section, the same meetup is displayed as a white box sporting some green accents that signal my relationship with this particular object.

Screenshot of Meetup's calendar showing the same event
Meetup’s calendar module makes the same meetup look like a totally different type of thing.

And finally, within the context of its parent group—in this case Ladies that UX ATL—the meetup object is represented differently yet again. (Let’s not even get started on the ontological ambiguity between Meetup the Group and Meetup the Event.)

Screenshot of the same event in a different context on Meetup.com
The meetup module on the Ladies that UX ATL parent page.

Not only is my lizard brain trying to reconcile all these changes for potential threats, but these inconsistencies are making me work harder in a practical sense. I have to learn three displays for RSVP status, three positions for date and time, and three ways to find the number of people going. Every time the object changes, I have to make adjustments both to recognize it and to interact with it. These adjustments are small, but they add up across the experience. Designers can eliminate this cognitive load simply by creating a canonical object structure and sticking to it.

Many users don’t log the deltas between modules explicitly. Users furrow their brows and simply do their best to relearn objects and keep track of what’s what. They might harbor a vague feeling that the website or app is “hard to use.” Or worse, they blame themselves for “stupidly” attempting to interact with an object in a way that worked in one context but does not work in their current context.

Sure, there are complex platforms where it might make sense to re-prioritize object elements depending both on who is viewing it and under what conditions. But if we design screen-by-screen instead of object-by-object, we run the risk of doing this unintentionally and arbitrarily, introducing more shapeshifting than is absolutely necessary.

Key takeaway

Image showing a way to consolidate three conflicting styles of a module into one cohesive style.
In this example, a veterinary portal might have multiple modules that represent “pet.” Instead of designing a different module for each context, design one module that works well for ALL contexts.

When we move elements around within an object, we need to remember that we are making a sacrifice—we are sacrificing consistency. Sometimes it will be worth it, like perhaps in professional tools used by power users. But often, our users will be happier with a single, rock-solid representation of that object.

Lesson two: avoid masked objects

On the flip side of shapeshifters (i.e., various packages for the same object), designers also have a tendency to shove different objects into the same package. With the good intention of designing a system of reusable parts, we’ll often create one-size-fits-all modules. This might seem like a smart simplification strategy, but it actually hinders users from distinguishing various object types. Distinguishing them is critical for the user to understand the system.

Screenshot showing five slightly different product modules on Amazon
Modules on Amazon homepage

Check out this bank of candy-colored modules on my Amazon homepage. Sure they house different colors and content, but they follow the same basic structure. If the text were in Latin (or if the user were skimming rapidly, which we should always assume is true), these modules would translate as the same type of thing. In looking at the first two, PRIME and FRESH, I might get the impression that these modules represent “services.” And indeed, when I click these modules, I enter sort of informational, sale-sy pages describing these services (although they follow completely different templates).

Screenshot showing how similar modules on Amazon set an expectation of usage
PRIME and FRESH module link to services

But when I get to VIDEO, I have to pause. VIDEO…the service? Or does this module represent a TV series? The next module (MUSIC) brings up the same question. And the ALEXA module—will this take me to a service landing page or, perhaps, a product detail page?

Screenshot showing the final destination of all five similar modules on Amazon
VIDEO, MUSIC, and ALEXA modules linking to different types of content

In fact, each module takes me to a different type of place. PRIME and FRESH take me to two separate templates for a “service.” VIDEO takes me to a detail page for The Americans. And MUSIC opens up Amazon Music in a new tab (with no sign of the ill-recommended Eminem album). The ALEXA module takes me to another “snowflake” landing page.

Like opening identical doors in a game show (but not as fun), I never know what to expect when clicking on one of these tiles. (View a video of my full rant on these Amazon modules.)

Let’s look at one more example. The Apple App Store leverages a small rectangular thumbnail module that can house apps, curated collections, broad categories, developer-based app suites, and even operating system updates.

The same module represents various objects in the Apple App Store.

In both the Amazon and Apple App Store examples, instances of the modules have distinct graphics and labels, but they are the same shape and size and they are grouped together, like apples at the market. As a general rule of thumb in Gestalt psychology, when objects are grouped together, we assume they are the same type of thing, especially if their overall shape is identical. When the same packaging (i.e., the module) turns out to contain various types of things, as in the App Store, users may feel confused or even tricked. This is like taking a sip from your Starbucks coffee cup and getting a mouthful of orange juice: objectively tasty, but if unexpected, you might spew it onto your barista.

Key takeaway

Graphic showing how to take similar modules with different purposes and make them distinct
Continuing with the veterinary portal from lesson one, we have pet, appointment, and medication modules all leveraging the same basic module design. Instead, create distinct modules for distinct objects. Different things deserve different packaging!

Designing one-size-fits-all modules might seem like a good idea for an efficient modular system, but this practice doesn’t allow users to predict what’s “behind the door.” Instead, design packaging (i.e., modules) that reflects the unique things inside. This way users can learn to recognize and understand the objects in your system, making for a more intuitive environment.

Lesson three: avoid broken objects

In the real world, our environments are made of surfaces and clear edges. We rarely have the problem of understanding where one object stops and another begins. If we happen across a tangle of snuggling kittens, our brain might freeze up—not only from cuteness overload, but also because we are compelled to figure out which paws belong to which head. We want objects to be whole; if they are not, our brain does its best to connect the dots. In digital environments, an object might not only shapeshift across screens or mimic other objects, it might also be broken. The information and interaction triggers of broken objects are scattered across their digital environments.

Winc Wines, a lovely service that delivers algorithmically-recommended wine to your doorstep, prompts customers to rate their wines. Often, I’ll do this 3–4 months after receiving wines. Recently, I decided it would be a great form of procrastination to log into Winc to rate my past wines.

Screenshot of the ratings tab of Winc.com
The Ratings tab of Winc.com. These wine modules include the ability to star a wine and add a note, but don’t show the user when the wine was received.

At a dinner party I hosted in May, we drank a delicious sparkling wine. I think it was Finke’s Widow, but I’m not positive. Hesitating to give it five stars until I am sure, I need to find out when the bottle of Finke’s was delivered. On the “Ratings” tab, I see all my past wines. But delivery dates are not displayed.

Screenshot of Winc.com's product detail page
The Winc’s wine detail page displays descriptive information about the wine, but nothing about the user’s past interactions with the wine.

Clicking into the detail view, I am presented with a generic detail page, the same view of Finke’s Widow that everyone sees. Here I can find information about the wine, but no information about my relationship with the wine—mainly, when it was delivered and how (or if) I rated it.

As a wild guess, I click the “Hello, Sophia” menu, where I see a link to Order History. Seems promising.

Screenshot of Winc.com's order history page
Winc’s Order History is not much more than a table of dates.

The Order History page gives me a list of orders with no preview of the wines that were included in each order.

Screenshot of Winc.com's order history detail page
Winc’s Order History detail view is where I finally find the delivery date of the wine in question.

After clicking into the April and May orders, I finally find Finke’s Widow. Mystery solved. So, can I rate the wine from here? Nope! I have to navigate back to the Ratings tab and then scroll down to find Finke’s Widow again. In the Winc world, relevant pieces of a bottle (like a customer’s order date, rating, and tasting notes) are scattered about, forcing a user to hop around to piece together the broken object. (Watch a video of this screen-hopping.)

Key takeaway

Graphic showing how to consolidate related information in one view
Avoid scattering an object’s data and actions across settings, buried menu commands, and hierarchical navigation.

In the Winc world, I have to be in Order History to see a wine’s delivery date and I have to be in Ratings to tell the system how much I liked a bottle of wine. But what if I am browsing wine and one of my past wines shows up in a curated collection? I’ll want to be reminded that this wine was delivered to me six months ago and I gave it 4 stars. Or, if I haven’t rated it yet, but I remember loving it, I’ll want to add my stars then and there. I definitely do not want to navigate over to Ratings, only to have to scroll down to re-find that bottle.

We need to do our best as designers to encapsulate our digital objects, making them feel whole and directly manipulable, just like in the real world. I might be more likely to use the blender in the kitchen, but it still works just as well in the garage.

Building a better mind palace

Humans love to concretize things. Greek orators memorized their long speeches by visualizing the speech as rooms in a palace. Sherlock Holmes himself, a genius at making connections between the most subtle clues, did so by entering his mind palace, a visualized place where bits of information were concretized and manipulable.

If the internet is the chaotic product of the human genius, this article is a call to action for designers to build a stronger mind palace for it. When we avoid shapeshifting, masking, and breaking digital objects, understanding will emerge more naturally. It’s a simple matter of making our digital environments feel a little more like the real world in which our ancestors evolved.

Sunday Secrets

Oct. 7th, 2017 10:48 pm
[syndicated profile] post_secret_feed

Posted by Frank

—email—
Thank you so much for agreeing to ask your Facebook fans to help me decode these postcards from my Great-Grandfather in the 1800’s. He owned a farm and a mill and apparently was involved in a war that was going on at that time… We don’t know who he was corresponding with or why. None of us have been able to crack the code.

—email—
Amazing!
I just read all three decoded messages on Facebook I called my mother again and she was so excited. My Great Grandfather’s name is Harry (whom the cards are written to). She doesn’t know who the M is – and she found the one card that says “I am your true love” very interesting  – – – because his wife’s name was Helen (eek!). Thank you SO very much and feel free to share this email with the P.S. community! You’re bringing so many smiles to my family right now!

Classic Secrets

Oct. 7th, 2017 10:36 pm
[syndicated profile] post_secret_feed

Posted by Frank

   

—email—
This Sunday you posted the classic secret of Purell and a note to Katie from her mother. I saw that secret when it was originally posted as a Sunday Secret. It is the only secret I ever printed. I carried it in my purse folded up for YEARS to remind me that MY having OCD and Anxiety was okay. Nobody needed to tell me that because the literal secret in my purse told me. I was no longer ashamed and was able to be open and a self-advocate for my needs. Now as a teacher I often tell my students, who are struggling, about that secret. I am going to print the secret again and keep extras in my office for future people who need it ❤️ What I’m trying to say is thank you and thanks to Katie. You’ve changed my life for the better.

 

 

PostSecret Live!

Oct. 7th, 2017 09:56 pm
[syndicated profile] post_secret_feed

Posted by Frank

Thank you Rutgers and CMU for two memorable and emotional PostSecret Live! events.

I appreciate your courage to share your stories and secrets and was not surprised by the audience’s compassion, understanding and support.

Telling our story can be transformative. Next stop Nebraska.

Free and open to all. RSVP and details.