Jump to Navigation

Around The Web

Monthly Web Development Update 3/2018: Service Workers, Building A CDN, And Cheating At Design

Smashing Magazine - Fri, 03/16/2018 - 9:29am

Service Worker is probably one of the most misrepresented technologies we currently have. When I hear people talking about it, the topic almost always revolves around serving an app when a user is offline. However, Service Worker can do so much more than that, and every week I come across new articles that show how powerful the technology really is.

This month, for example, we can learn how to use Service Worker for cross-tab messaging and to load off requests into the background with the Background Sync API. I think the toolset we now have in our browsers already allows us to build great experiences regardless of the network state. Now it’s up to us to make the experiences so great that users truly love them. And that’s probably the hardest part.

News Sketch 49 has arrived, and with it comes the new Prototyping in Sketch feature which lets you see the entire flow in action. (Image credit)

Getting the process just right ain't an easy task. That's why we've set up 'this-is-how-I-work'-sessions — with smart cookies sharing what works really well for them. A part of the Smashing Membership, of course.

Explore features → General
  • Ed Ellson examined Chrome’s Background Sync API and the retry strategy it uses to perform a request. By allowing synchronization in the background after a first attempt has failed, the API helps us improve the browsing experience for users who go offline or are on unstable connections.
UI/UX Use color and weight to create visual hierarchy instead of size is only one of the seven practical tips for cheating at design that Adam Wathan and Steve Schoger share. (Image credit) Security
  • With GraphQL you can query exactly what you want whenever you want. This is amazing for working with an API but also has complex security implications. Instead of asking for legitimate, useful data, a malicious actor could submit an expensive, nested query to overload your server, database, network, or all of these. To prevent this from happening, Max Stoiber shows us how we can secure the GraphQL API in our projects.
  • WebKit is introducing the Storage Access API. The new API targets one of the major issues with Safari’s Intelligent Tracking Protection (ITP): Identifying users who are logged in to a first-party service but view content of it embedded on a third party (YouTube videos on a blog, for example). The Storage Access API allows third-party embeds to request access to their first-party cookies when the user interacts with them. A good solution to protect user privacy by default and allow exceptions on request.
Web Performance
  • Janos Pasztor built his own Content Delivery Network because he thinks it can be a better solution than using existing third parties. The code for the CDN of his personal website is now available on Github. A nice web performance article that looks at common solutions from a different angle.
  • A year after Facebook’s announcement to broadly use Cache-Control: Immutable, Paul Calvano examined how widespread its usage is on the web — apart from the few big players. Interesting research and it’s still sad to see that this useful performance tool is used so little. At Colloq, we use it quite a lot, which saves us a lot of traffic and load on our servers and enables us to serve a lot of pages nearly instantly to recurring users.
Global stats for the custom CDN that Janos Pasztor built. (Image credit) HTML & SVG JavaScript CSS Accessibility The Accessibility Checklist helps build accessibility into your process no matter your role or stage in a project. (Image credit) Work & Life
  • This week I read an article by Alex Duloz, and his words still stick with me: “When we develop a new application, when we post content on the Internet, whatever we do that people will have access to, we should consider just for a minute if our contribution adds up to the level of dumbness kids/teenagers are exposed to. If it does, we should refrain from going live.” The truth is, most of us, including me, don’t consider this before posting on the Internet. We create funny things, share funny pictures and try to get fame with silly posts. But in reality, we shape society with this. Let’s try to provide more useful resources and make the consumption of this more enjoyable so young people can profit from our knowledge and not only view things we think are funny. “We should always consider how teenagers will use what we release.”
  • The MIT OpenCourseWare released a lot of free audio and video lectures. This is amazing news and makes great content available to broader masses.
  • Jake Knapp says great work requires idealism and cynicism and has strong arguments to back up this theory. An article worth reading.
  • There’s an important article on how unhappiness has grown in America’s population since around the year 2000. It reveals that while income inequality might play a role, the more important aspect is that young people who use a lot of digital media are unhappier than those who use it only up to an hour a day. Interestingly, people who don’t use digital media at all, are unhappy, too, so the outcome of this could be that we should try to use digital media only moderately — at least in our private lives. I bet it’ll make a big difference.
  • Following the theory of Michael Bradley, projects don’t necessarily need a roadmap for success. Instead, he suggests to create a moral compass that points out why the project exists and what its purpose is.
Going Beyond…

We hope you enjoyed this Web Development Update. The next one is scheduled for April 13th. Stay tuned.

Categories: Around The Web

Ethical Design: The Practical Getting-Started Guide

Smashing Magazine - Fri, 03/16/2018 - 6:00am

By now, most people working in tech know and feel the deep concerns related to surveillance capitalism fostered and upheld by the tech giants. We understand that the root of the problem lies within the business model of capitalising and monetising user data. Stories of how people are being exploited surface on a daily basis, like the recent story about how Instagram withholds like notifications to certain users, with the purpose of increasing the rate of which they open the app. In the same story, The Globe and Mail describe how former high level employees of Facebook are growing a conscience and tell horrifying stories about how features are meticulously being built to exploit human behavior and make us addicts of social media.

As designers and developers we have an obligation to build experiences that are better than that. This article explains how unethical design happens, and how to do ethical design through a set of best practices. It also helps you understand how you can plant the seed to change the meaning within the company you work for and in the design community, even if you are not part of the management layer. Change starts with a movement!

Ethical Design

Let’s start with the core terminology: According to Merriam Webster, ethics is “the discipline dealing with what is good and bad and with moral duty and obligation.” For the purpose of this article, ethics will be defined as a system of moral principles that defines what is perceived as good and evil. Ethical design is, therefore, design made with the intent to do good, and unethical design is its black hat counterpart.

Is your pattern library up to date today? Alla Kholmatova has just finished a fully fledged book on Design Systems and how to get them right. With common traps, gotchas and the lessons she learned. Hardcover, eBook. Just sayin'.

Table of Contents →

Ind.ie is a social enterprise striving for justice in the digital age. It is founded by Aral Balkan and Laura Kalbag who defined an “Ethical Hierarchy of Needs” that describe the core of ethical design very well.

The 'Ethical Hierarchy of Needs' (licensed under CC BY 4.0) (Source: ind.ie)

As with any pyramid-shaped structure, the layers in the Ethical Hierarchy of Needs rest on the layer below it. If any layer is broken, the layers resting on top of it will collapse. If a design does not support human rights, it is unethical. If it supports human rights but does not respect human effort by being functional, convenient and reliable (and usable!), then it is unethical. If it respects human effort but does not respect human experience by making a better life for the people using it, then it is still unethical.

From a practical viewpoint, this means that products and services which exploit user data, use dark patterns and generally are only out to make money, disregarding its human purpose, are unethical. Let’s look at how unethical design manifests itself in business models and design decisions.

Unethical Design: The Black Hat Of The Business 
 Surveillance Capitalism

Data-driven design can be used to do good. But more often than not it is used with monetary intent also known as surveillance capitalism.

As Aral Balkan, ethical designer and founder of ind.ie puts it:

“When a company like Facebook improves the experience of its products, it’s like the massages we give to Kobe beef: they’re not for the benefit of the cow but to make the cow a better product. In this analogy, you are the cow.”

Surveillance capitalism is unethical by nature because at its core, it takes advantage of rich data to profile people and understand their behavior with the sole purpose of making money. The most chilling thought of all is how data is being used not just to predict and manipulate current behavior, but how it is used to profile our future selves through machine learning, ultimately giving companies the power to impact our future decisions and behavioral patterns.

As Cracked Labs, independent research institute and creative laboratory, states in their report about Data Against People:

“Systems that make decisions about people based on their data produce substantial adverse effects that can massively limit their choices, opportunities, and life-chances”.

This happens on a daily basis to everyone who use Facebook, where the individualized feed is carefully filtered to show the posts most likely to trigger engagement and activity. Pricing is also becoming increasingly individualized because companies are able to use rich data to assess the long-term value of customers, also known as data-driven persuasion.

Data trade and data tracking is big business. According to the report “Corporate Surveillance in Everyday Life”, Oracle provides access to 5 billion (yes, billion!) unique user ID’s (this is confirmed on Oracle’s website). The word “scared” does not cover the emotional state which we should all be in over that fact.

An overview of the amount of profiles held by online platforms, credit reporting agencies and consumer data brokers as of June 2017. (Source: Corporate Surveillance in Everyday Life, CC BY-SA 4.0, Cracked Labs)

One can only imagine how companies will be able to utilize data to profile which of us are more likely to develop mental health or physical issues, thus putting us in the “no thanks” pile of applications for our future jobs. With this in mind, I fear for the future of my children.

To some the above sounds like something out of a science fiction movie, but it is not far-fetched at all. Unethical companies are exposed daily, from the VPN app who claimed to protect the data of their 24 million users, but sold it to Facebook to the software called Alphonso which, according to an article in The New York Times, is used in more than 250 game apps (some of which are designed for children) to monitor what tv ads people watch, even if the app is not in active use. The list of companies who harvest and use data with deeply unethical purposes goes on and on and on.

Black Hat Design

Nevertheless, data tracking is not the only way that unethical design plays out. Dark patterns fall under unethical design too, as they are black hat design patterns specifically designed to trick us into doing something we don’t necessarily want to do. It may not be considered unethical when a company makes use of the dark pattern called Roach Motel to make it nearly impossible to delete your account (looking at you, Skype). But looking at the motivation of the business side, it is not hard to see the unethical nature of the design, naming the Chinese shoe company who tricked people to swipe by adding a fake strand of hair on their Instagram ad as just one example.

Harry Brignull, one of the originators and driving forces behind Dark Patterns, states that dark patterns work because they take advantage of the human brain’s weaknesses and the way we are hard-wired. That counts as unethical in my book, and we have a moral obligation to the people who design these products to do better.

Businesses who nurture consumerism and manipulate people into buying more stuff are unethical by design. It is common practice in e-commerce, and it takes advantage of a phenomenon called “loss aversion”. Hotels.com is particularly aggressive, sending several notifications within seconds about how many people have booked and are looking at the same room as you.

Hotels.com loves letting us know just how many others are looking at a room to 'motivate' us into booking fast. The General Data Protection Regulation

The effectuation of the General Data Protection Regulation (GDPR) in late May 2018 will be an efficient tool in the fight against companies that are unethical by design.

GDPR is an extensive regulation that amongst the highlights include:

  • The requirement of any organization that collects data to do so in a secure manner by design;
  • Heavy fines for data breaches;
  • Data must only be collected after explicit consent, and the language used to explain why the data is collected must be plain and simple. In addition, consent must be withdrawable at any time and must be as easy to do as it was giving it (which, by the way, includes Sign up → Delete profile);
  • “The right to be forgotten,” meaning that people have the right to have their data deleted;
  • The right for people to get access to their personal data in any organization, alongside information about how this data is processed;
  • Data portability, meaning that people have the right to get hold of their data in one company and transfer it to another company;
  • Heavy fines for non-compliance of GDPR.

All in all, May 25, 2018, is a pretty good day for the people, and a sign of a much different future for all the unethically designed organizations out there.

But let’s not kid ourselves and think that change will happen overnight or across all organizations in a heartbeat. A deeper change is needed in order to make that happen over time.

Change Happens Through Change Of Meaning

GDPR is not likely to solve all of our problems. Believing that would be naive. That’s why it will continue to be up to the people within company walls to make a difference. The good news is that making a change is possible even if you’re not part of the management team who decides on the business model.

This type of change towards a more ethical design approach is not claimed to happen overnight. Rather, it is possible to make changes incrementally and foster long-term, organizational change through what Don Norman and Roberto Verganti call Meaning-driven Innovation (read more in their article about “Incremental and Radical Innovation”).

Meaning-driven innovation is a result of people starting to articulate new thoughts that create new dynamics, which ultimately lead to radically new meanings.

Don Norman and Roberto Verganti say that radical innovation only happens when one of the following things occur:

  1. A new enabling technology is available in a reliable, economical form (it took 20 years for touch interfaces to exit the labs and enter the phone and tablet market);
  2. When the meaning of something changes in society — also referred to as meaning-driven innovation.

I think that the increasing awareness, focus, and concern about our privacy in respect to data-driven businesses will in a not so distinct future spark radical innovation and change in society. Ironically, the companies who founded surveillance capitalism have also sparked a change in how we perceive our right to privacy, and we are already starting to see companies and organizations innovate and foster privacy driven solutions.

The meaning of companies who track and surveil us is already changing. We used to not think very hard about, and maybe even find it convenient when ads served on Facebook were based on our browsing history. But with the escalation of surveillance capitalism, I will argue that we are going through a meaning change as an increasing mass of people are finding it not only uncomfortable but directly unacceptable to be spied on in the name of a business.

DuckDuckGo, a search engine that doesn’t track, had an average of 16 million search queries per day in 2017, a sign that privacy is an increasing concern among people when using the web. Also, we are seeing apps devoted to privacy reaching markets, such as Signal, a secure phone and messenger app designed to protect privacy. Furthermore, it is highly likely that GDPR will spark further meaning change related to privacy.

Transition To A Human-Centered Design Approach

Human-Centered Design (HCD) is a philosophy developed by Don Norman (among others). According to the User Experience Professionals Association (UXPA), HCD is defined by “the active involvement of users and a clear understanding of user and task requirements”.

Don Norman and Roberto Verganti conclude in their substantial study that HCD is only suitable for incremental innovation — step by step improvements — because new ideas are not discovered while constantly looking at the existing state of things as it is done through user research.

While this sounds reasonable, I believe that HCD can prove to be the offset to meaning-driven innovation, ultimately leading to a broad meaning change about what people will accept and won’t accept from unethical organizations. The reason why I believe this, is that HCD fosters a deeper sense of empathy than any other experience design method.

Human-Centered Design is a framework as well as a mindset. At its core, working “human-centered” means involving the people you serve early and continuously in the process, i.e. using research to establish the needs of these people, understanding what problems they have, and how your product can help solve these problems.

It falls within the natural sphere of experience designers to work human-centered, but what do you do if your job is in design and development, and you are constantly occupied by sprint reviews and daily tasks?

While working with a remote development team, I learned that the developers didn’t have any contact with the people who used the product. This often led to heated discussions where statements like “I think…”, “From a technical perspective…”, and “I feel…” were the main arguments.

The biggest problem with basing decisions on what you think and feel, or what is easiest from a technical perspective, is that it doesn’t involve the people you are serving. The people who your product or service is put in the world to solve problems for. That’s where HCD comes in.

UX designers and researchers typically conduct research, document the insights and bring them forward in a refined state to the design- and product team in the shape of personas, user needs descriptions, user flows, journeys, and so on. And that’s all well and good. The problem is, however, that the distance between the organisation and people you serve remains large, because no one except the UX designers talked to them or have seen them use the product. So they keep going back to “I feel…”, “I think…” and “From a technical perspective…”

To help establish empathy towards the people you serve, there are a couple of very impactful things designers and developers — and the rest of the organization — can do (and can ask for from the UX team).

  1. Involve all team members in watching videos from user testing sessions.
    Actually going through the pains and delights of the people who use your products (or prototypes, depending on what you’re testing) is worth every second. It cannot be stressed enough how important it is to watch other people interact with and comment on the stuff you’re building (and no, your team doesn't count as “people” here!).

    If this is not part of the routine in your company, ask for it to be included. Certainly, the vast majority of UX designers who would not be thrilled to organize and facilitate such sessions. You are guaranteed to go through pain, agony, frustration, happiness and get multiple eye openers, and it will all serve as the stepping stone towards growing a human-centered mindset.
  2. Ask for actual, living portraits of the people you serve.
    This includes photos and video from contextual studies (link), stories from their daily life and stories about them. Getting a deeper sense of the people on the other side of the product you develop creates instant empathy and makes it a lot harder to design things that knowingly are bad for them.
  3. Insist on continuous testing.
    It cannot be emphasized enough how crucial testing is in HCD. This includes early proof of concept tests, prototype tests, and usability tests. A side bonus of early and continuous involvement from the people who are meant to use the product is that it saves money in the long run. The earlier you realize a bad call or error, the cheaper it is to fix.

    A lot has been said about the nuclear alarm that was triggered by mistake in Hawaii on January 13. However, it’s pretty safe to say that early and continuous testing would have helped prevent it.
    A poorly designed screen has been named the cause of a false ballistic missile alert in Hawaii. (Source: Honolulu Civil Beat)
  4. Always ask “why?”
    To start a change of meaning in an organization or community, the first important step is to start asking “why.” Ask why something is being done unethically; ask why you are told to make a black hat feature; question the current state of things.

    Ask on what grounds design decisions are being made. If it’s because of what the CEO or someone else thinks, and it has no root in insights from the people you are serving, ask for that validation. Meaning change grows through small steps.
Ethical Design Best Practices

Alongside establishing a human-centered design tradition in the organization, it is also important to make use of the best practices of ethical design. People who do so are part of taking the lead and showing the rest of the organization how things can be done in a more ethical way, all of which will add to the incremental meaning change. Just as dark patterns fall under unethical design, we have White Hat design patterns that can be utilized to ensure ethical design, some of which you can learn about in the following.

Use Data To Improve The Human Experience

Despite numerous companies using data for unethical purposes, such as increasing consumption and traffic, data can, in fact, be used to actually improve the human experience.

This is the case on the ind.ie forum where setting up an account is suggested as a way to customize your experience by remembering what you’ve read.

ind.ie's forum highlights the benefits of setting up an account — one that won’t harvest your data and use it unethically.

In a current project in which I am involved in making an app for students to more easily access their Learning Management System, we are sorting the student’s individual courses by “last visited”; we know through research that the students most often revisit a small number of pages that relate to the courses they are currently enrolled in. This customization is not designed to change behavior or nudge them into using parts of the app they didn’t intend to. Instead, it is designed to make their experience faster and more efficient.

In this early wireframe from a current project, it it shown how we used knowledge about current usage of the product to increase efficiency in the app by sorting the student’s courses by 'last visited'.

Another positive example is the American pharmacy Walgreens, who sends out reminders when it’s time to refill on things like vitamins. This is an extremely helpful feature that solves a problem a lot of us have.

Data can help inform research initiatives to understand how you’re not tackling the problems people have when interacting with your product.

Skyscanner, a travel search engine, noticed through their data that their newly launched design didn’t go down well for the people who used their service to fly out of Amsterdam. That data helped inform a research initiative that ultimately lead to a customized solution for people flying to and from Amsterdam that broke down the barriers the new design had initially built (here’s the background story).

Advertising Without Tracking

Advertising is not necessarily unethical. Advertising based on granular data is. It is careless (if not stupid) to rely on a single platform for the majority of a brand’s marketing efforts, especially considering that said platform owns and controls the data the brand uses as the foundation for its ad targeting.

Facebook, Instagram, and Google care just about as little about their advertisers as they do about the people who they see as “users,” i.e. they can make any change they want to, disregarding any consequences it might have for people or businesses using their platform. For example, there was a time when they started blocking fake accounts en masse, which hurt numerous companies whose social media admins had set up fake accounts to administer business pages because they (understandably) didn’t want to use their private accounts for this purpose. This is standard procedure from Facebook who only allows one profile per person (likely because allowing several would contaminate their data tracking).

The platform is always the weakest link in a marketing strategy because it is a third party beyond the control of companies. Thinking back to the 90’s when I worked in marketing at a regional newspaper, granular data tracking was not an option. When a store had placed an ad in the paper about an event, they would simply monitor how many people showed up, and compare that to their expectations to determine the success rate.

While “the good old days” were certainly not good in all aspects, the thought of not basing advertising on granular user data tracking is an appealing thought. John Gruber’s blog, Daring Fireball is an example of a site that doesn’t allow ad tracking. Instead, John Gruber encourages advertisers to add a custom link to their ads enabling them to monitor the click rate on their end.

As John Gruber rightfully states:

“If you pay (say) Facebook for an ad, why in the world would you, the advertiser, trust Facebook’s numbers for how the ad performed?”


Another great example worth highlighting is Goodwings, a hotel booking site that donates half of their commission to charity. They can do so because of a close collaboration with a large number of NGO’s which means they spend very little on traditional marketing.

Goodwings is a hotel search engine that donates half of their commission to charity.

And if you think Google Analytics is your only option for collecting meaningful data, think again: Matamo is an open source tool that is installed directly on your own server. It guarantees that data is not shared with advertising agencies such as Google.

Always, Always Prioritize Usability

Surveillance capitalism and data tracking are heavily talked about problems related to ethical design these days. But we must not forget the importance of complying with the best practices of usability. Without it, design is unethical, as a lack of usability almost always entails the use of dark patterns. A good place to go to read more about core usability is Nielsen Norman Group.

Back in the early days, Jakob Nielsen defined 5 core components of usability:

  • Learnability,
  • Efficiency,
  • Memorability
  • Errors, and
  • Satisfaction.

To ensure a usable product, it’s crucial that these five components are front and center in the design and development process. 
 While it may not be the most interesting 404 page around, Apple’s version focuses on error prevention by offering us a forward path when we hit a lost page.

Don’t Ask For More Than You Need

As with many other aspects in life, asking for more than you need results in exploitation. It’s common for e-commerce sites to ask for tons of information when people sign up for an account or buy a product. But if someone is buying a digital product (such as a book), there really is no need to ask for anything other than their email address.

Signal is a great example. Private at its core, it doesn’t ask for anything more than the information that is absolutely necessary for people to start using the app right away.

Signal only asks for the phone number of the device during signup. Be Transparent

Norwegian.com has perhaps one of the best airfare booking systems in the world. Not only is it convenient to use but they also offer full transparency in relation to their optional service fees, something that is often hidden away. Anyone who lives outside of an Amazon storage country knows how hard it is to find the actual delivery price of their location.

Norwegian.com offers full transparency on all additional charges. Conclusion

The movement towards a more ethical future has begun. Change doesn’t happen radically short term unless it’s built into the core of the business model. But that doesn’t mean we cannot change the current state for the better. We can do so through incremental change; one step at a time. By working human-centered, by asking why, and by using best practices for ethical design. That’s our obligation as the ones who build products so deeply ingrained in people’s lives. What we do changes and shapes lives for better or for worse. I choose better.

Learn More

There are a lot of valuable resources available for anyone interested in ethical design. Here are a few to get you started:

  • IDEO’s Human-Centered Design Kit is extremely helpful to understand HCD and offers a wide range of methods on how to work human-centered.
  • Simply Secure is an organization that supports and educates practitioners in ethical design processes. They offer a thorough knowledge base for people interested in building trustworthy technology
  • White Hat UX — The Next Generation in User Experience is a book that offers lots of practical advice on how to design experiences that are transparent, honest and ethical. Written by Trine Falbe, Martin Frederiksen, and Kim Andersen.
  • Cracked Labs is an independent research institute and a creative laboratory based in Vienna, Austria. It investigates the socio-cultural impacts of information technology and develops social innovations in the field of digital culture. They offer in-depth reports about most things related to privacy.
(ah, ra, il)
Categories: Around The Web

Conversational Design

Design Blog - Thu, 03/15/2018 - 10:30am

A note from the editors: We’re pleased to share an excerpt from Chapter 1 of Erika Hall’s new book, Conversational Design, available now from A Book Apart.

Texting is how we talk now. We talk by tapping tiny messages on touchscreens—we message using SMS via mobile data networks, or through apps like Facebook Messenger or WhatsApp.

.article-layout .main-content > figure.quote:first-child figcaption { margin-top: 1rem; }

In 2015, the Pew Research Center found that 64% of American adults owned a smartphone of some kind, up from 35% in 2011. We still refer to these personal, pocket-sized computers as phones, but “Phone” is now just one of many communication apps we neglect in favor of texting. Texting is the most widely used mobile data service in America. And in the wider world, four billion people have mobile phones, so 4 billion people have access to SMS or other messaging apps. For some, dictating messages into a wristwatch offers an appealing alternative to placing a call.

The popularity of texting can be partially explained by the medium’s ability to offer the easy give-and-take of conversation without requiring continuous attention. Texting feels like direct human connection, made even more captivating by unpredictable lag and irregular breaks. Any typing is incidental because the experience of texting barely resembles “writing,” a term that carries associations of considered composition. In his TED talk, Columbia University linguist John McWhorter called texting “fingered conversation”—terminology I find awkward, but accurate. The physical act—typing—isn’t what defines the form or its conventions. Technology is breaking down our traditional categories of communication.

By the numbers, texting is the most compelling computer-human interaction going. When we text, we become immersed and forget our exchanges are computer-mediated at all. We can learn a lot about digital design from the inescapable draw of these bite-sized interactions, specifically the use of language.

What Texting Teaches Us

This is an interesting example of what makes computer-mediated interaction interesting. The reasons people are compelled to attend to their text messages—even at risk to their own health and safety—aren’t high-production values, so-called rich media, or the complexity of the feature set.

Texting, and other forms of social media, tap into something very primitive in the human brain. These systems offer always-available social connection. The brevity and unpredictability of the messages themselves triggers the release of dopamine that motivates seeking behavior and keeps people coming back for more. What makes interactions interesting may start on a screen, but the really interesting stuff happens in the mind. And language is a critical part of that. Our conscious minds are made of language, so it’s easy to perceive the messages you read not just as words but as the thoughts of another mingled with your own. Loneliness seems impossible with so many voices in your head.

With minimal visual embellishment, texts can deliver personality, pathos, humor, and narrative. This is apparent in “Texts from Dog,” which, as the title indicates, is a series of imagined text exchanges between a man and his dog. (Fig 1.1). With just a few words, and some considered capitalization, Joe Butcher (writing as October Jones) creates a vivid picture of the relationship between a neurotic canine and his weary owner.

Fig 1.1: “Texts from Dog” shows how lively a simple text exchange can be.

Using words is key to connecting with other humans online, just as it is in the so-called “real world.” Imbuing interfaces with the attributes of conversation can be powerful. I’m far from the first person to suggest this. However, as computers mediate more and more relationships, including customer relationships, anyone thinking about digital products and services is in a challenging place. We’re caught between tried-and-true past practices and the urge to adopt the “next big thing,” sometimes at the exclusion of all else.

Being intentionally conversational isn’t easy. This is especially true in business and at scale, such as in digital systems. Professional writers use different types of writing for different purposes, and each has rules that can be learned. The love of language is often fueled by a passion for rules — rules we received in the classroom and revisit in manuals of style, and rules that offer writers the comfort of being correct outside of any specific context. Also, there is the comfort of being finished with a piece of writing and moving on. Conversation, on the other hand, is a context-dependent social activity that implies a potentially terrifying immediacy.

Moving from the idea of publishing content to engaging in conversation can be uncomfortable for businesses and professional writers alike. There are no rules. There is no done. It all feels more personal. Using colloquial language, even in “simplifying” interactive experiences, can conflict with a desire to appear authoritative. Or the pendulum swings to the other extreme and a breezy style gets applied to a laborious process like a thin coat of paint.

As a material for design and an ingredient in interactions, words need to emerge from the content shed and be considered from the start.  The way humans use language—easily, joyfully, sometimes painfully—should anchor the foundation of all interactions with digital systems.

The way we use language and the way we socialize are what make us human; our past contains the key to what commands our attention in the present, and what will command it in the future. To understand how we came to be so perplexed by our most human quality, it’s worth taking a quick look at, oh!, the entire known history of communication technology.

The Mother Tongue

Accustomed to eyeballing type, we can forget language began in our mouths as a series of sounds, like the calls and growls of other animals. We’ll never know for sure how long we’ve been talking—speech itself leaves no trace—but we do know it’s been a mighty long time.

Archaeologist Natalie Thais Uomini and psychologist Georg Friedrich Meyer concluded that our ancestors began to develop language as early as 1.75 million years ago. Per the fossil record, modern humans emerged at least 190,000 years ago in the African savannah. Evidence of cave painting goes back 30,000 years (Fig 1.2).

Then, a mere 6,000 years ago, ancient Sumerian commodity traders grew tired of getting ripped off. Around 3200 BCE, one of them had the idea to track accounts by scratching wedges in wet clay tablets. Cuneiform was born.

So, don’t feel bad about procrastinating when you need to write—humanity put the whole thing off for a couple hundred thousand years! By a conservative estimate, we’ve had writing for about 4% of the time we’ve been human. Chatting is easy; writing is an arduous chore.

Prior to mechanical reproduction, literacy was limited to the elite by the time and cost of hand-copying manuscripts. It was the rise of printing that led to widespread literacy; mass distribution of text allowed information and revolutionary ideas to circulate across borders and class divisions. The sharp increase in literacy bolstered an emerging middle class. And the ability to record and share knowledge accelerated all other advances in technology: photography, radio, TV, computers, internet, and now the mobile web. And our talking speakers.

Fig 1.2: In hindsight, “literate culture” now seems like an annoying phase we had to go through so we could get to texting.

Every time our communication technology advances and changes, so does the surrounding culture—then it disrupts the power structure and upsets the people in charge. Catholic archbishops railed against mechanical movable type in the fifteenth century. Today, English teachers deplore texting emoji. Resistance is, as always, futile. OMG is now listed in the Oxford English Dictionary.

But while these developments have changed the world and how we relate to one another, they haven’t altered our deep oral core.

Orality, Say It with Me Orality knits persons into community. Walter Ong

Today, when we record everything in all media without much thought, it’s almost impossible to conceive of a world in which the sum of our culture existed only as thoughts.

Before literacy, words were ephemeral and all knowledge was social and communal. There was no “save” option and no intellectual property. The only way to sustain an idea was to share it, speaking aloud to another person in a way that made it easy for them to remember. This was orality—the first interface.

We can never know for certain what purely oral cultures were like. People without writing are terrible at keeping records. But we can examine oral traditions that persist for clues.

The oral formula

Reading and writing remained elite activities for centuries after their invention. In cultures without a writing system, oral characteristics persisted to help transmit poetry, history, law and other knowledge across generations.

The epic poems of Homer rely on meter, formulas, and repetition to aid memory:

Far as a man with his eyes sees into the mist of the distance Sitting aloft on a crag to gaze over the wine-dark seaway, Just so far were the loud-neighing steeds of the gods overleaping. Iliad, 5.770

Concrete images like rosy-fingered dawn, loud-neighing steeds, wine-dark seaway, and swift-footed Achilles served to aid the teller and to sear the story into the listener’s memory.

Biblical proverbs also encode wisdom in a memorable format:

As a dog returns to its vomit, so fools repeat their folly. Proverbs 26:11

That is vivid.

And a saying that originated in China hundreds of years ago can prove sufficiently durable to adorn a few hundred Etsy items:

A journey of a thousand miles begins with a single step. Tao Te Ching, Chapter 64, ascribed to Lao Tzu The labor of literature

Literacy created distance in time and space and decoupled shared knowledge from social interaction. Human thought escaped the existential present. The reader doesn’t need to be alive at the same time as the writer, let alone hanging out around the same fire pit or agora. 

Freed from the constraints of orality, thinkers explored new forms to preserve their thoughts. And what verbose and convoluted forms these could take:

The Reader will I doubt too soon discover that so large an interval of time was not spent in writing this discourse; the very length of it will convince him, that the writer had not time enough to make a shorter. George Tullie, An Answer to a Discourse Concerning the Celibacy of the Clergy, 1688

There’s no such thing as an oral semicolon. And George Tullie has no way of knowing anything about his future audience. He addresses himself to a generic reader he will never see, nor receive feedback from. Writing in this manner is terrific for precision, but not good at all for interaction.

Writing allowed literate people to become hermits and hoarders, able to record and consume knowledge in total solitude, invest authority in them, and defend ownership of them. Though much writing preserved the dullest of records, the small minority of language communities that made the leap to literacy also gained the ability to compose, revise, and perfect works of magnificent complexity, utility, and beauty.

The qualities of oral culture

In Orality and Literacy: The Technologizing of the Word, Walter Ong explored the “psychodynamics of orality,” which is, coincidentally, quite a mouthful.  Through his research, he found that the ability to preserve ideas in writing not only increased knowledge, it altered values and behavior. People who grow up and live in a community that has never known writing are different from literate people—they depend upon one another to preserve and share knowledge. This makes for a completely different, and much more intimate, relationship between ideas and communities.

Oral culture is immediate and social

In a society without writing, communication can happen only in the moment and face-to-face. It sounds like the introvert’s nightmare! Oral culture has several other hallmarks as well:

  • Spoken words are events that exist in time. It’s impossible to step back and examine a spoken word or phrase. While the speaker can try to repeat, there’s no way to capture or replay an utterance.
  • All knowledge is social, and lives in memory. Formulas and patterns are essential to transmitting and retaining knowledge. When the knowledge stops being interesting to the audience, it stops existing.
  • Individuals need to be present to exchange knowledge or communicate. All communication is participatory and immediate. The speaker can adjust the message to the context. Conversation, contention, and struggle help to retain this new knowledge.
  • The community owns knowledge, not individuals. Everyone draws on the same themes, so not only is originality not helpful, it’s nonsensical to claim an idea as your own.
  • There are no dictionaries or authoritative sources. The right use of a word is determined by how it’s being used right now.
Literate culture promotes authority and ownership

Printed books enabled mass-distribution and dispensed with handicraft of manuscripts, alienating readers from the source of the ideas, and from each other. (Ong pg. 100):

  • The printed text is an independent physical object. Ideas can be preserved as a thing, completely apart from the thinker.
  • Portable printed works enable individual consumption. The need and desire for private space accompanied the emergence of silent, solo reading.
  • Print creates a sense of private ownership of words. Plagiarism is possible.
  • Individual attribution is possible. The ability to identify a sole author increases the value of originality and creativity.
  • Print fosters a sense of closure. Once a work is printed, it is final and closed.

Print-based literacy ascended to a position of authority and cultural dominance, but it didn’t eliminate oral culture completely.

Technology brought us together again

All that studying allowed people to accumulate and share knowledge, speeding up the pace of technological change. And technology transformed communication in turn. It took less than 150 years to get from the telegraph to the World Wide Web. And with the web—a technology that requires literacy—Ong identified a return to the values of the earlier oral culture. He called this secondary orality. Then he died in 2003, before the rise of the mobile internet, when things really got interesting.

Secondary orality is:

  • Immediate. There is no necessary delay between the expression of an idea and its reception. Physical distance is meaningless.
  • Socially aware and group-minded. The number of people who can hear and see the same thing simultaneously is in the billions.
  • Conversational. This is in the sense of being both more interactive and less formal.
  • Collaborative. Communication invites and enables a response, which may then become part of the message.
  • Intertextual. The products of our culture reflect and influence one another.

Social, ephemeral, participatory, anti-authoritarian, and opposed to individual ownership of ideas—these qualities sound a lot like internet culture.

Wikipedia: Knowledge Talks

When someone mentions a genre of music you’re unfamiliar with—electroclash, say, or plainsong—what do you do to find out more? It’s quite possible you type the term into Google and end up on Wikipedia, the improbably successful, collaborative encyclopedia that would be absent without the internet.

According to Wikipedia, encyclopedias have existed for around two-thousand years. Wikipedia has existed since 2001, and it’s the fifth most-popular site on the web. Wikipedia is not a publication so much as a society that provides access to knowledge. A volunteer community of “Wikipedians” continuously adds to and improves millions of articles in over 200 languages. It’s a phenomenon manifesting all the values of secondary orality:

  • Anyone can contribute anonymously and anyone can modify the contributions of another.
  • The output is free.
  • The encyclopedia articles are not attributed to any sole creator. A single article might have 2 editors or 1,000.
  • Each article has an accompanying “talk” page where editors discuss potential improvements, and a “history” page that tracks all revisions. Heated arguments are not documented. They take place as revisions within documents.

Wikipedia is disruptive in the true Clayton Christensen sense. It’s created immense value and wrecked an existing business model. Traditional encyclopedias are publications governed by authority, and created by experts and fact checkers. A volunteer project collaboratively run by unpaid amateurs shows that conversation is more powerful than authority, and that human knowledge is immense and dynamic.

In an interview with The Guardian, a British librarian expressed some disdain about Wikipedia.

The main problem is the lack of authority. With printed publications, the publishers must ensure that their data are reliable, as their livelihood depends on it. But with something like this, all that goes out the window. Philip Bradley, “Who knows?”, The Guardian, October 26, 2004

Wikipedia is immediate, group-minded, conversational, collaborative, and intertextual— secondary orality in action—but it relies on traditionally published sources for its authority. After all, anything new that changes the world does so by fitting into the world. As we design for new methods of communication, we should remember that nothing is more valuable simply because it’s new; rather, technology is valuable when it brings us more of what’s already meaningful.

From Documents to Events

Pages and documents organize information in space. Space used to be more of a constraint back when we printed conversation out. Now that the internet has given us virtually infinite space, we need to mind how conversation moves through time. Thinking about serving the needs of people in an internet-based culture requires a shift from thinking about how information occupies space—documents—to how it occupies time—events.

Texting means that we’ve never been more lively (yet silent) in our communications. While we still have plenty of in-person interactions, it’s gotten easy to go without. We text grocery requests to our spouses. We click through a menu in a mobile app to summon dinner (the order may still arrive at the restaurant by fax, proving William Gibson’s maxim that the future is unevenly distributed). We exchange messages on Twitter and Facebook instead of visiting friends in person, or even while visiting friends in person. We work at home and Slack our colleagues.

We’re rapidly approaching a future where humans text other humans and only speak aloud to computers. A text-based interaction with a machine that’s standing in for a human should feel like a text-based interaction with a human. Words are a fundamental part of the experience, and they are part of the design. Words should be the basis for defining and creating the design.

We’re participating in a radical cultural transformation. The possibilities manifest in systems like Wikipedia that succeed in changing the world by using technology to connect people in a single collaborative effort. And even those of us creating the change suffer from some lag. The dominant educational and professional culture remains based in literary values. We’ve been rewarded for individual achievement rather than collaboration. We seek to “make our mark,” even when designing changeable systems too complex for any one person to claim authorship. We look for approval from an authority figure. Working in a social, interactive way should feel like the most natural thing in the world, but it will probably take some doing.

Literary writing—any writing that emerges from the culture and standards of literacy—is inherently not interactive. We need to approach the verbal design not as a literary work, but as a conversation. Designing human-centered interactive systems requires us to reflect on our deep-seated orientation around artifacts and ownership. We must alienate ourselves from a set of standards that no longer apply.

Most advice on “writing for the web” or “creating content” starts from the presumption that we are “writing,” just for a different medium. But when we approach communication as an assembly of pieces of content rather than an interaction, customers who might have been expecting a conversation end up feeling like they’ve been handed a manual instead.

Software is on a path to participating in our culture as a peer.  So, it should behave like a person—alive and present. It doesn’t matter how much so-called machine intelligence is under the hood—a perceptive set of programmatic responses, rather than a series of documents, can be enough if they have the qualities of conversation.

Interactive systems should evoke the best qualities of living human communities—active, social, simple, and present—not passive, isolated, complex, or closed off.

Life Beyond Literacy Indeed, language changes lives. It builds society, expresses our highest aspirations, our basest thoughts, our emotions and our philosophies of life. But all language is ultimately at the service of human interaction. Other components of language—things like grammar and stories—are secondary to conversation. Daniel L. Everett, How Language Began

Literacy has gotten us far. It’s gotten you this far in this book. So, it’s not surprising we’re attached to the idea. Writing has allowed us to create technologies that give us the ability to interact with one another across time and space, and have instantaneous access to knowledge in a way our ancestors would equate with magic. However, creating and exchanging documents, while powerful, is not a good model for lively interaction. Misplaced literate values can lead to misery—working alone and worrying too much about posterity.

So, it’s time to let go and live a little! We’re at an exciting moment. The computer screen that once stood for a page can offer a window into a continuous present that still remembers everything. Or, the screen might disappear completely.

Now we can start imagining, in an open-ended way, what constellation of connected devices any given person will have around them, and how we can deliver a meaningful, memorable experience on any one of them. We can step away from the screen and consider what set of inputs, outputs, events, and information add up to the best experience.

This is daunting for designers, sure, yet phenomenal for people. Thinking about human-computer interactions from a screen-based perspective was never truly human-centered from the start. The ideal interface is an interface that’s not noticeable at all—a world in which the distance from thought to action has collapsed and merely uttering a phrase can make it so.

We’re fast moving past “computer literacy.” It’s on us to ensure all systems speak human fluently.

Categories: Around The Web

How BBC Interactive Content Works Across AMP, Apps, And The Web

Smashing Magazine - Thu, 03/15/2018 - 8:20am

In the Visual Journalism team at the BBC, we produce exciting visual, engaging and interactive content, ranging from calculators to visualizations new storytelling formats.

Each application is a unique challenge to produce in its own right, but even more so when you consider that we have to deploy most projects in many different languages. Our content has to work not only on the BBC News and Sports websites but on their equivalent apps on iOS and Android, as well as on third-party sites which consume BBC content.

Now consider that there is an increasing array of new platforms such as AMP, Facebook Instant Articles, and Apple News. Each platform has its own limitations and proprietary publishing mechanism. Creating interactive content that works across all of these environments is a real challenge. I’m going to describe how we’ve approached the problem at the BBC.

Example: Canonical vs. AMP

This is all a bit theoretical until you see it in action, so let’s delve straight into an example.

Here is a BBC article containing Visual Journalism content:

Our Visual Journalism content begins with the Donald Trump illustration, and is inside an iframe

This is the canonical version of the article, i.e., the default version, which you’ll get if you navigate to the article from the homepage.

Nope, we can't do any magic tricks, but we have articles, books and webinars featuring techniques we all can use to improve our work. Smashing Members get a seasoned selection of magic front-end tricks — e.g. live designing sessions and perf audits, too. Just sayin'! ;-)

Explore Smashing Wizardry →

Now let’s look at the AMP version of the article:

This looks like the same content as the normal article, but is pulling in a different iframe designed specifically for AMP

While the canonical and AMP versions look the same, they are actually two different endpoints with different behavior:

  • The canonical version scrolls you to your chosen country when you submit the form.
  • The AMP version doesn’t scroll you, as you cannot scroll the parent page from within an AMP iframe.
  • The AMP version shows a cropped iframe with a ‘Show More’ button, depending on viewport size and scroll position. This is a feature of AMP.

As well as the canonical and AMP versions of this article, this project was also shipped to the News App, which is yet another platform with its own intricacies and limitations. So how do we do support all of these platforms?

Tooling Is Key

We don’t build our content from scratch. We have a Yeoman-based scaffold which uses Node to generate a boilerplate project with a single command.

New projects come with Webpack, SASS, deployment and a componentization structure out of the box. Internationalization is also baked into our projects, using a Handlebars templating system. Tom Maslen writes about this in detail in his post, 13 tips for making responsive web design multi-lingual.

Out of the box, this works pretty well for compiling for one platform but we need to support multiple platforms. Let’s delve into some code.

Embed vs. Standalone

In Visual Journalism, we sometimes output our content inside an iframe so that it can be a self-contained “embed” in an article, unaffected by the global scripting and styling. An example of this is the Donald Trump interactive embedded in the canonical example earlier in this article.

On the other hand, sometimes we output our content as raw HTML. We only do this when we have control over the whole page or if we require really responsive scroll interaction. Let’s call these our “embed” and “standalone” outputs respectively.

Let’s imagine how we might build the “Will a robot take your job?” interactive in both the “embed” and “standalone” formats.

Contrived example showing an 'embed' on the left, versus the content as a 'standalone' page on the right

Both versions of the content would share the vast majority of their code, but there would be some crucial differences in the implementation of the JavaScript between the two versions.

For example, look at the ‘Find out my automation risk’ button. When the user hits the submit button, they should be automatically scrolled to their results.

The “standalone” version of the code might look like this:

button.on('click', (e) => { window.scrollTo(0, resultsContainer.offsetTop); });

But if you were building this as “embed” output, you know that your content is inside an iframe, so would need to code it differently:

// inside the iframe button.on('click', () => { window.parent.postMessage({ name: 'scroll', offset: resultsContainer.offsetTop }, '*'); }); // inside the host page window.addEventListener('message', (event) => { if (event.data.name === 'scroll') { window.scrollTo(0, iframe.offsetTop + event.data.offset); } });

Also, what if our application needs to go full screen? This is easy enough if you’re in a “standalone” page:

document.body.className += ' fullscreen'; .fullscreen { position: fixed; top: 0; left: 0; right: 0; bottom: 0; } We successfully use full-screen functionality to make the most of our map module on mobile

If we tried to do this from inside an “embed,” this same code would have the content scaling to the width and height of the iframe, rather than the viewport:

It can be difficult going full screen from within an iframe

…so in addition to applying the full-screen styling inside the iframe, we have to send a message to the host page to apply styling to the iframe itself:

// iframe window.parent.postMessage({ name: 'window:toggleFullScreen' }, '*'); // host page window.addEventListener('message', function () { if (event.data.name === 'window:toggleFullScreen') { document.getElementById(iframeUid).className += ' fullscreen'; } });

This can translate into a lot of spaghetti code when you start supporting multiple platforms:

button.on('click', (e) => { if (inStandalonePage()) { window.scrollTo(0, resultsContainer.offsetTop); } else { window.parent.postMessage({ name: 'scroll', offset: resultsContainer.offsetTop }, '*'); } });

Imagine doing an equivalent of this for every meaningful DOM interaction in your project. Once you’ve finished shuddering, make yourself a relaxing cup of tea, and read on.

Abstraction Is Key

Rather than forcing our developers to handle these conditionals inside their code, we built an abstraction layer between their content and the environment. We call this layer the ‘wrapper.’

Instead of querying the DOM or native browser events directly, we can now proxy our request through the wrapper module.

import wrapper from 'wrapper'; button.on('click', () => { wrapper.scrollTo(resultsContainer.offsetTop); });

Each platform has its own wrapper implementation conforming to a common interface of wrapper methods. The wrapper wraps itself around our content and handles the complexity for us.

Simple 'scrollTo' implementation by the standalone wrapper

The standalone wrapper’s implementation of the scrollTo function is very simple, passing our argument directly to window.scrollTo under the hood.

Now let’s look at a separate wrapper implementing the same functionality for the iframe:

Advanced 'scrollTo' implementation by the embed wrapper

The “embed” wrapper takes the same argument as in the “standalone” example but manipulates the value so that the iframe offset is taken into account. Without this addition, we would have scrolled our user somewhere completely unintended.

The Wrapper Pattern

Using wrappers results in code that is cleaner, more readable and consistent between projects. It also allows for micro-optimisations over time, as we make incremental improvements to the wrappers to make their methods more performant and accessible. Your project can, therefore, benefit from the experience of many developers.

So, what does a wrapper look like?

Wrapper Structure

Each wrapper essentially comprises three things: a Handlebars template, wrapper JS file, and a SASS file denoting wrapper-specific styling. Additionally, there are build tasks which hook into events exposed by the underlying scaffolding so that each wrapper is responsible for its own pre-compilation and cleanup.

This is a simplified view of the embed wrapper:

embed-wrapper/ templates/ wrapper.hbs js/ wrapper.js scss/ wrapper.scss

Our underlying scaffolding exposes your main project template as a Handlebars partial, which is consumed by the wrapper. For example, templates/wrapper.hbs might contain:

<div class="bbc-news-vj-wrapper--embed"> {{>your-application}} </div>

scss/wrapper.scss contains wrapper-specific styling that your application code shouldn’t need to define itself. The embed wrapper, for example, replicates a lot of BBC News styling inside the iframe.

Finally, js/wrapper.js contains the iframed implementation of the wrapper API, detailed below. It is shipped separately to the project, rather than compiled in with the application code — we flag wrapper as a global in our Webpack build process. This means that though we deliver our application to multiple platforms, we only compile the code once.

Wrapper API

The wrapper API abstracts a number of key browser interactions. Here are the most important ones:


Scrolls to the given position in the active window. The wrapper will normalise the provided integer before triggering the scroll so that the host page is scrolled to the correct position.

getScrollPosition: int

Returns the user’s current (normalized) scroll position. In the case of the iframe, this means that the scroll position passed to your application is actually negative until the iframe is at the top of the viewport. This is super useful and lets us do things such as animate a component only when it comes into view.


Provides a hook into the scroll event. In the standalone wrapper, this is essentially hooking into the native scroll event. In the embed wrapper, there will be a slight delay in receiving the scroll event since it is passed via postMessage.

viewport: {height: int, width: int}

A method to retrieve the viewport height and width (since this is implemented very differently when queried from within an iframe).


In standalone mode, we hide the BBC menu and footer from view and set a position: fixed on our content. In the News App, we do nothing at all — the content is already full screen. The complicated one is the iframe, which relies on applying styles both inside and outside the iframe, coordinated via postMessage.


Tell the wrapper your content has loaded. This is crucial for our content to work in the News App, which will not attempt to display our content to the user until we explicitly tell the app our content is ready. It also removes the loading spinner on the web versions of our content.

List Of Wrappers

In the future, we envisage creating additional wrappers for large platforms such as Facebook Instant Articles and Apple News. We have created six wrappers to date:

Standalone Wrapper

The version of our content that should go in standalone pages. Comes bundled with BBC branding.

Embed Wrapper

The iframed version of our content, which is safe to sit inside articles or to syndicate to non-BBC sites, since we retain control over the content.

AMP Wrapper

This is the endpoint which is pulled in as an amp-iframe into AMP pages.

News App Wrapper

Our content must make calls to a proprietary bbcvisualjournalism:// protocol.

Core Wrapper

Contains only the HTML — none of our project’s CSS or JavaScript.

JSON Wrapper

A JSON representation of our content, for sharing across BBC products.

Wiring Wrappers Up To The Platforms

For our content to appear on the BBC site, we provide journalists with a namespaced path:

/include/[department]/[unique ID], e.g. /include/visual-journalism/123-quiz

The journalist puts this “include path” into the CMS, which saves the article structure into the database. All products and services sit downstream of this publishing mechanism. Each platform is responsible for choosing the flavor of content it wants and requesting that content from a proxy server.

Let’s take that Donald Trump interactive from earlier. Here, the include path in the CMS is:


The canonical article page knows it wants the “embed” version of the content, so it appends /embed to the include path:


…before requesting it from the proxy server:


The AMP page, on the other hand, sees the include path and appends /amp:


The AMP renderer does a little magic to render some AMP HTML which references our content, pulling in the /amp version as an iframe:

<amp-iframe src="https://news.files.bbci.co.uk/include/newsspec/15996-trump-tracker/english/index/amp" width="640" height="360"> <!-- some other AMP elements here --> </amp-iframe>

Every supported platform has its own version of the content:

/include/newsspec/15996-trump-tracker/english/index/amp /include/newsspec/15996-trump-tracker/english/index/core /include/newsspec/15996-trump-tracker/english/index/envelope ...and so on

This solution can scale to incorporate more platform types as they arise.

Abstraction Is Hard

Building a “write once, deploy anywhere” architecture sounds quite idealistic, and it is. For the wrapper architecture to work, we have to be very strict on working within the abstraction. This means we have to fight the temptation to “do this hacky thing to make it work in [insert platform name here].” We want our content to be completely unaware of the environment it is shipped in — but this is easier said than done.

Features Of The Platform Are Hard To Configure Abstractly

Before our abstraction approach, we had complete control over every aspect of our output, including, for example, the markup of our iframe. If we needed to tweak anything on a per-project basis, such as add a title attribute to the iframe for accessibility reasons, we could just edit the markup.

Now that the wrapper markup exists in isolation from the project, the only way of configuring it would be to expose a hook in the scaffold itself. We can do this relatively easily for cross-platform features, but exposing hooks for specific platforms breaks the abstraction. We don’t really want to expose an ‘iframe title’ configuration option that’s only used by the one wrapper.

We could name the property more generically, e.g. title, and then use this value as the iframe title attribute. However, it starts to become difficult to keep track of what is used where, and we risk abstracting our configuration to the point of no longer understanding it. By and large, we try to keep our config as lean as possible, only setting properties that have global use.

Component Behaviour Can Be Complex

On the web, our sharetools module spits out social network share buttons that are individually clickable and open a pre-populated share message in a new window.

BBC Visual Journalism sharetools present a list of social share options

In the News App, we don’t want to share through the mobile web. If the user has the relevant application installed (e.g. Twitter), we want to share in the app itself. Ideally, we want to present the user with the native iOS/Android share menu, then let them choose their share option before we open the app for them with a pre-populated share message. We can trigger the native share menu from the app by making a call to the proprietary bbcvisualjournalism:// protocol.

Native share menu on Android

However, this screen will be triggered whether you tap ‘Twitter’ or ‘Facebook’ in the ‘Share your results’ section, so the user ends up having to make their choice twice; the first time inside our content, and a second time on the native popup.

This is a strange user journey, so we want to remove the individual share icons from the News app and show a generic share button instead. We are able to do this by explicitly checking which wrapper is in use before we render the component.

Generic share button used in the News App

Building the wrapper abstraction layer works well for projects as a whole, but when your choice of wrapper affects changes at the component level, it’s very difficult to retain a clean abstraction. In this case, we’ve lost a little abstraction, and we have some messy forking logic in our code. Thankfully, these cases are few and far between.

How Do We Handle Missing Features?

Keeping abstraction is all well and good. Our code tells the wrapper what it wants the platform to do, e.g. “go full screen.” But what if the platform we’re shipping to can’t actually go full-screen?

The wrapper will try its best not to break altogether, but ultimately you need a design which gracefully falls back to a working solution whether or not the method succeeds. We have to design defensively.

Let’s say we have a results section containing some bar charts. We often like to keep the bar chart values at zero until the charts are scrolled into view, at which point we trigger the bars animating to their correct width.

Bar chart showing values relevant to my area

But if we have no mechanism to hook into the scroll position — as is the case in our AMP wrapper — then the bars would forever remain at zero, which is a thoroughly misleading experience.

How the bar chart could look if scrolling events aren't forwarded

We are increasingly trying to adopt more of a progressive enhancement approach in our designs. For example, we could provide a button which will be visible for all platforms by default, but which gets hidden if the wrapper supports scrolling. That way, if the scroll fails to trigger the animation, the user can still trigger the animation manually.

We could display a fallback button instead, which triggers the animation on click. Plans For The Future

We hope to develop new wrappers for platforms such as Apple News and Facebook Instant Articles, as well as to offer all new platforms a ‘core’ version of our content out of the box.

We also hope to get better at progressive enhancement; succeeding in this field means developing defensively. You can never assume all platforms now and in the future will support a given interaction, but a well-designed project should be able to get its core message across without falling at the first technical hurdle.

Working within the confines of the wrapper is a bit of a paradigm shift, and feels like a bit of a halfway house in terms of the long-term solution. But until the industry matures onto a cross-platform standard, publishers will be forced to roll out their own solutions, or use tooling such as Distro for platform-to-platform conversion, or else ignore entire sections of their audience altogether.

It’s early days for us, but so far we’ve had great success in using the wrapper pattern to build our content once and deliver it to the myriad of platforms our audiences are now using.

(rb, ra, il)
Categories: Around The Web

How To Make A WordPress Plugin Extensible

Smashing Magazine - Wed, 03/14/2018 - 8:40am

Have you ever used a plugin and wished it did something a bit differently? Perhaps you needed something unique that was beyond the scope of the settings page of the plugin.

I have personally encountered this, and I'm betting you have, too. If you're a WordPress plugin developer, most likely some of your users have also encountered this while using your plugin.

Here's a typical scenario: You've finally found that plugin that does everything you need — except for one tiny important thing. There is no setting or option to enable that tiny thing, so you browse the documentation and find that you can't do anything about it. You request the feature in the WordPress plugin's support forum — but no dice. In the end, you uninstall it and continue your search.

Imagine if you were the developer of this plugin. What would you do if a user asked for some particular functionality?

The ideal thing would be to implement it. But if the feature was for a very special use case, then adding it would be impractical. It wouldn't be good to have a plugin setting that only 0.1% of your users would have a use for.

You'd only want to implement features that affect the majority of your users. In reality, 80% of users use 20% of the features (the 80/20 rule). So, make sure that any new feature is highly requested, and that 80% of your users would benefit from it, before implementing it. If you created a setting for every feature that is requested, then your plugin would become complicated and bloated — and nobody wants that.

Your best bet is to make the plugin extensible, code-wise, so that other people can enhance or modify it for their own needs.

In this article, you'll learn about why making your plugin extensible is a good idea. I'll also share a few tips of how I've learned to do this.

Getting the process just right ain't an easy task. That's why we've set up 'this-is-how-I-work'-sessions — with smart cookies sharing what works really well for them. A part of the Smashing Membership, of course.

Explore features → What Makes A Plugin Extensible?

In a nutshell, an extensible plugin means that it adheres to the "O" part of the SOLID principles of object-oriented programming — namely, the open/closed principle.

If you're unfamiliar with the open/closed principle, it basically means that other people shouldn't have to edit your code in order to modify something.

Applying this principle to a WordPress plugin, it would mean that a plugin is extensible if it has provisions in it that enable other people to modify its behavior. It's just like how WordPress allows people to "hook" into different areas of WordPress, but at the level of the plugin.

A Typical Example Of A Plugin

Let's see how we can create an extensible plugin, starting with a sample plugin that isn't.

Suppose we have a plugin that generates a sidebar widget that displays the titles of the three latest posts. At the heart of the plugin is a function that simply wraps the titles of those three posts in list tags:

function get_some_post_titles() { $args = array( 'posts_per_page' => 3, ); $posts = get_posts( $args ); $output = '
    '; foreach ( $posts as $post ) { $output .= '
  • ' . $post->post_title . '
  • '; } $output .= '
'; return $output; }

While this code works and gets the job done, it isn't quite extensible.

Why? Because the function is set in its own ways, there's no way to change its behavior without modifying the code directly.

What if a user wanted to display more than three posts, or perhaps include links with the posts' titles? There's no way to do that with the code above. The user is stuck with how the plugin works and can nothing to change it.

Including A Hundred Settings Isn't The Answer

There are a number of ways to enhance the plugin above to allow users to customize it.

One such way would be to add a lot of options in the settings, but even that might not satisfy all of the possibilities users would want from the plugin.

What if the user wanted to do any of the following (scenarios we'll revisit later):

  • display WooCommerce products or posts from a particular category;
  • display the items in a carousel provided by another plugin, instead of as a simple list;
  • perform a custom database query, and then use those query's posts in the list.

If we added a hundred settings to our widget, then we would be able to cover the use cases above. But what if one of these scenarios changes, and now the user wants to display only WooCommerce products that are currently in stock? The widget would need even more settings to accommodate this. Pretty soon, we'd have a gazillion settings.

Also, a plugin with a huge list of settings isn't exactly user-friendly. Steer away from this route if possible.

So, how would we go about solving this problem? We'd make the plugin extensible.

Adding Our Own Hooks To Make It Extensible

By studying the plugin's code above, we see a few operations that the main function performs:

  • It gets posts using get_posts.
  • It generates a list of post titles.
  • It returns the generated list.

If other people were to modify this plugin's behavior, their work would mostly likely involve these three operations. To make our plugin extensible, we would have to add hooks around these to open them up for other developers.

In general, these are good areas to add hooks to a plugin:

  • around and within the major processes,
  • when building output HTML,
  • for altering post or database queries,
  • before returning values from a function.
A Typical Example Of An Extensible Plugin

Taking these rules of thumb, we can add the following filters to make our plugin extensible:

  • add myplugin_get_posts_args for modifying the arguments of get_posts,
  • add myplugin_get_posts for overriding the results of get_posts,
  • add myplugin_list_item for customizing the generation of a list entry,
  • add myplugin_get_some_post_titles for overriding the returned generated list.

Here's the code again with all of the hooks added in:

function get_some_post_titles() { $args = array( 'posts_per_page' => 3, ); // Let other people modify the arguments. $posts = get_posts( apply_filters( 'myplugin_get_posts_args', $args ) ); // Let other people modify the post array, which will be used for display. $posts = apply_filters( 'myplugin_get_posts', $posts, $args ); $output = '
    '; foreach ( $posts as $post ) { // Let other people modify the list entry. $output .= '
  • ' . apply_filters( 'myplugin_list_item', $post->post_title, $post ) . '
  • '; } $output .= '
'; // Let other people modify our output list. return apply_filters( 'myplugin_get_some_post_titles', $output, $args ); }

You can also get the code above in the GitHub archive.

I'm adding a lot of hooks here, which might seem impractical because the sample code is quite simple and small, but it illustrates my point: By adding just four hooks, other developers can now customize the plugin's behavior in all sorts of ways.

Namespacing And Context For Hooks

Before proceeding, note two important things about the hooks we've implemented:

  • We're namespacing the hooks with myplugin_.
    This ensures that the hook's name doesn't conflict with some other plugin's hook. This is just good practice, because if another hook with the same name is called, it could lead to unwanted effects.
  • We're also passing a reference to $args in all of the hooks for context.
    I do this so that if others use this filter to change something in the flow of the code, they can use that $args parameter as a reference to get an idea of why the hook was called, so that they can perform their adjustments accordingly.
The Effects Of Our Hooks

Remember the unique scenarios I talked about earlier? Let's revisit those and see how our hooks have made them possible:

  • If the user wants to display WooCommerce products or posts from a particular category, then either they can use the filter myplugin_get_posts_args to add their own arguments for when the plugin queries posts, or they can use myplugin_get_posts to completely override the posts with their own list.
  • If the user wants to display the items in a carousel provided by another plugin, instead of as a simple list, then they can override the entire output of the function with myplugin_get_some_post_titles, and instead output a carousel from there.
  • If the user wants to perform a custom database query and then use that query's posts in the list, then, similar to the first scenario, they can use myplugin_get_posts to use their own database query and change the post array.

Much better!

A Quick Example Of How To Use Our Filters

Developers can use add_filter to hook into our filters above (or use add_action for actions).

Taking our first scenario above, a developer can just do the following to display WooCommerce products using the myplugin_get_posts_args filter that we created:

add_filter( 'myplugin_get_posts_args', 'show_only_woocommerce_products' ); function show_only_woocommerce_products( $args ) { $args['post_type'] = 'product'; return $args; } We Can Also Use Action Hooks

Aside from using apply_filters, we can also use do_action to make our code extensible. The difference between the two is that the first allows others to change a variable, while the latter allows others to execute additional functionality in various parts of our code.

When using actions, we're essentially exposing the plugin's flow to other developers and letting them perform other things in tandem.

It might not be useful in our example (because we are only displaying a shortcode), but it would be helpful in others. For example, given an extensible backup plugin, we could create a plugin that also uploads the backup file to a third-party service such as Dropbox.

"Great! But Why Should I Care About Making My Plugin Extensible?"

Well, if you're still not sold on the idea, here are a few thoughts on why allowing other people to modify your plugin's behavior is a good idea.

It Opens Up the Plugin to More Customization Possibilities

Everyone has different needs. And there's a big chance your plugin won't satisfy all of them, nor can you anticipate them. Opening up your plugin to allow for modifications to key areas of your plugin's behavior can do wonders.

It Allows People to Introduce Modifications Without Touching the Plugin's Code

Other developers won't be forced to change your plugin's files directly. This is a huge benefit because directly modifying a plugin's file is generally bad practice. If the plugin gets updated, then all of your modifications will be wiped.

If we add our own hooks for other people to use, then the plugin's modifications can be put in an external location — say, in another plugin. Done this way, the original plugin won't be touched at all, and it can be freely updated without breaking anything, and all of the modifications in the other plugin would remain intact.


Extensible plugins are really awesome and give us room for a lot of customization possibilities. If you make your plugin extensible, your users and other developers will love you for it.

Take a look at plugins such as WooCommerce, Easy Digital Downloads and ACF. These plugins are extensible, and you can easily tell because numerous other plugins in WordPress' plugins directory add functionality to them. They also provide a wide array of action and filter hooks that modify various aspects of the plugins. The rules of thumb I've enumerated above have come up in my study of them.

Here are a few takeaways to make your plugin extensible:

  • Follow the open/closed principle. Other people shouldn't have to edit your code in order to modify something.
  • To make your plugin extensible, add hooks in these places:
    • around and within major processes,
    • when building the output HTML,
    • for altering post or database queries,
    • before returning values from a function.
  • Namespace your hooks' names with the name of your plugin to prevent naming conflicts.
  • Try passing other variables that are related to the hook, so that other people get some context of what's happening in the hook.
  • Don't forget to document your plugin's hooks, so that other people can learn of them.
Further Reading

Here are some resources if you want to learn more about extending plugins:

(mc, ra, al, yk, il)
Categories: Around The Web

A DIY Web Accessibility Blueprint

Design Blog - Tue, 03/13/2018 - 9:18am

The summer of 2017 marked a monumental victory for the millions of Americans living with a disability. On June 13th, a Southern District of Florida Judge ruled that Winn-Dixie’s inaccessible website violated Title III of the Americans with Disabilities Act. This case marks the first trial under the ADA, which was passed into law in 1990.

Despite spending more than $7 million to revamp its website in 2016, Winn-Dixie neglected to include design considerations for users with disabilities. Some of the features that were added include online prescription refills, digital coupons, rewards card integration, and a store locator function. However, it appears that inclusivity didn’t make the cut.

Because Winn-Dixie’s new website wasn’t developed to WCAG 2.0 standards, the new features it boasted were in effect only available to sighted, able-bodied users. When Florida resident Juan Carlos Gil, who is legally blind, visited the Winn-Dixie website to refill his prescriptions, he found it to be almost completely inaccessible using the same screen reader software he uses to access hundreds of other sites.

Juan stated in his original complaint that he “felt as if another door had been slammed in his face.” But Juan wasn’t alone. Intentionally or not, Winn-Dixie was denying an entire group of people access to their new website and, in turn, each of the time-saving features it had to offer.

What makes this case unique is that it marks the first time in history in which a public accommodations case went to trial, meaning the judge ruled the website to be a “place of public accommodation” under the ADA and therefore subject to ADA regulations. Since there are no specific ADA regulations regarding the internet, Judge Scola decided the adoption of the Web Content Accessibility Guidelines (WCAG) 2.0 Level AA to be appropriate. (Thanks to the hard work of the Web Accessibility Initiative (WAI) at the W3C, WCAG 2.0 has found widespread adoption throughout the globe, either as law or policy.)

Learning to have empathy

Anyone with a product subscription service (think diapers, razors, or pet food) knows the feeling of gratitude that accompanies the delivery of a much needed product that arrives just in the nick of time. Imagine how much more grateful you’d be for this service if you, for whatever reason, were unable to drive and lived hours from the nearest store. It’s a service that would greatly improve your life. But now imagine that the service gets overhauled and redesigned in such a way that it is only usable by people who own cars. You’d probably be pretty upset.

This subscription service example is hypothetical, yet in the United States, despite federal web accessibility requirements instituted to protect the rights of disabled Americans, this sort of discrimination happens frequently. In fact, anyone assuming the Winn-Dixie case was an isolated incident would be wrong. Web accessibility lawsuits are rising in number. The increase from 2015 to 2016 was 37%. While some of these may be what’s known as “drive-by lawsuits,” many of them represent plaintiffs like Juan Gil who simply want equal rights. Scott Dinin, Juan’s attorney, explained, “We’re not suing for damages. We’re only suing them to follow the laws that have been in this nation for twenty-seven years.”

For this reason and many others, now is the best time to take a proactive approach to web accessibility. In this article I’ll help you create a blueprint for getting your website up to snuff.

The accessibility blueprint

If you’ll be dealing with remediation, I won’t sugarcoat it: successfully meeting web accessibility standards is a big undertaking, one that is achieved only when every page of a site adheres to all the guidelines you are attempting to comply with. As I mentioned earlier, those guidelines are usually WCAG 2.0 Level AA, which means meeting every Level A and AA requirement. Tight deadlines, small budgets, and competing priorities may increase the stress that accompanies a web accessibility remediation project, but with a little planning and research, making a website accessible is both reasonable and achievable.

My intention is that you may use this article as a blueprint to guide you as you undertake a DIY accessibility remediation project. Before you begin, you’ll need to increase your accessibility know-how, familiarize yourself with the principles of universal design, and learn about the benefits of an accessible website. Then you may begin to evangelize the benefits of web accessibility to those you work with.

Have the conversation with leadership

Securing support from company leadership is imperative to the long-term success of your efforts. There are numerous ways to broach the subject of accessibility, but, sadly, in the world of business, substantiated claims top ethics and moral obligation. Therefore I’ve found one of the most effective ways to build a business case for web accessibility is to highlight the benefits.

Here are just a few to speak of:

  • Accessible websites are inherently more usable, and consequently they get more traffic. Additionally, better user experiences result in lower bounce rates, higher conversions, and less negative feedback, which in turn typically make accessible websites rank higher in search engines.
  • Like assistive technology, web crawlers (such as Googlebot) leverage HTML to get their information from websites, so a well marked-up, accessible website is easier to index, which makes it easier to find in search results.
  • There are a number of potential risks for not having an accessible website, one of which is accessibility lawsuits.
  • Small businesses in the US that improve the accessibility of their website may be eligible for a tax credit from the IRS.
Start the movement

If you can’t secure leadership backing right away, you can still form a grassroots accessibility movement within the company. Begin slowly and build momentum as you work to improve usability for all users. Though you may not have the authority to make company-wide changes, you can strategically and systematically lead the charge for web accessibility improvements.

My advice is to start small. For example, begin by pushing for site-wide improvements to color contrast ratios (which would help color-blind, low-vision, and aging users) or work on making the site keyboard accessible (which would help users with mobility impairments or broken touchpads, and people such as myself who prefer not using a mouse whenever possible). Incorporate user research and A/B testing into these updates, and document the results. Use the results to champion for more accessibility improvements.

Read and re-read the guidelines

Build your knowledge base as you go. Learning which laws, rules, or guidelines apply to you, and understanding them, is a prerequisite to writing an accessibility plan. Web accessibility guidelines vary throughout the world. There may be other guidelines that apply to you, and in some cases, additional rules, regulations, or mandates specific to your industry.

Not understanding which rules apply to you, not reading them in full, or not understanding what they mean can create huge problems down the road, including excessive rework once you learn you need to make changes.

Build a team

Before you can start remediating your website, you’ll need to assemble a team. The number of people will vary depending on the size of your organization and website. I previously worked for a very large company with a very large website, yet the accessibility team they assembled was small in comparison to the thousands of pages we were tasked to remediate. This team included a project manager, visual designers, user experience designers, front-end developers, content editors, a couple requirements folks, and a few QA testers. Most of these people had been pulled from their full-time roles and instructed to quickly become familiar with WCAG 2.0. To help you create your own accessibility team, I will explain in detail some of the top responsibilities of the key players:

  • Project manager is responsible for coordinating the entire remediation process. They will help run planning sessions, keep everyone on schedule, and report the progress being made. Working closely with the requirements people, their goal is to keep every part of this new machine running smoothly.
  • Visual designers will mainly address issues of color usage and text alternatives. In its present form, WCAG 2.0 contrast minimums only apply to text, however the much anticipated WCAG 2.1 update (due to be released in mid-2018) contains a new success criterion for Non-text Contrast, which covers contrast minimums of all interactive elements and “graphics required to understand the content.” Visual designers should also steer clear of design trends that ruin usability.
  • UX designers should be checking for consistent, logical navigation and reading order. They’ll need to test that pages are using heading tags appropriately (headings are for semantic structure, not for visual styling). They’ll be checking to see that page designs are structured to appear and operate in predictable ways.
  • Developers have the potential to make or break an accessible website because even the best designs will fail if implemented incorrectly. If your developers are unfamiliar with WAI-ARIA, accessible coding practices, or accessible JavaScript, then they have a few things to learn. Developers should think of themselves as designers because they play a very important role in designing an inclusive user experience. Luckily, Google offers a short, free Introduction to Web Accessibility course and, via Udacity, a free, advanced two-week accessibility course. Additionally, The A11Y Project is a one-stop shop loaded with free pattern libraries, checklists, and accessibility resources for front-end developers.
  • Editorial review the copy for verbosity. Avoid using phrases that will confuse people who aren’t native language speakers. Don’t “beat around the bush” (see what I did there?). Keep content simple, concise, and easy to understand. No writing degree? No worries. There are apps that can help you improve the clarity of your writing and that correct your grammar like a middle school English teacher. Score bonus points by making sure link text is understandable out of context. While this is a WCAG 2.0 Level AAA guideline, it’s also easily fixed and it greatly improves the user experience for individuals with varying learning and cognitive abilities.
  • Analysts work in tandem with editorial, design, UX, and QA. They coordinate the work being done by these groups and document the changes needed. As they work with these teams, they manage the action items and follow up on any outstanding tasks, questions, or requests. The analysts also deliver the requirements specifications to the developers. If the changes are numerous and complex, the developers may need the analysts to provide further clarification and to help them properly implement the changes as described in the specs.
  • QA will need to be trained to the same degree as the other accessibility specialists since they will be responsible for testing the changes that are being made and catching any issues that arise. They will need to learn how to navigate a website using only a keyboard and also by properly using a screen reader (ideally a variety of screen readers). I emphasized “properly” because while anyone can download NVDA or turn on VoiceOver, it takes another level of skill to understand the difference between “getting through a page” and “getting through a page with standard keyboard controls.” Having individuals with visual, auditory, or mobility impairments on the QA team can be a real advantage, as they are more familiar with assistive technology and can test in tandem with others. Additionally, there are a variety of automated accessibility testing tools you can use alongside manual testing. These tools typically catch only around 30% of common accessibility issues, so they do not replace ongoing human testing. But they can be extremely useful in helping QA learn when an update has negatively affected the accessibility of your website.
Start your engines!

Divide your task into pieces that make sense. You may wish to tackle all the global elements first, then work your way through the rest of the site, section by section. Keep in mind that every page must adhere to the accessibility standards you’re following for it to be deemed “accessible.” (This includes PDFs.)

Use what you’ve learned so far by way of accessibility videos, articles, and guidelines to perform an audit of your current site. While some manual testing may seem difficult at first, you’ll be happy to learn that some manual testing is very simple. Regardless of the testing being performed, keep in mind that it should always be done thoroughly and by considering a variety of users, including:

  • keyboard users;
  • blind users;
  • color-blind users;
  • low-vision users;
  • deaf and hard-of-hearing users;
  • users with learning disabilities and cognitive limitations;
  • mobility-impaired users;
  • users with speech disabilities;
  • and users with seizure disorders.
When you are in the weeds, document the patterns

As you get deep in the weeds of remediation, keep track of the patterns being used. Start a knowledge repository for elements and situations. Lock down the designs and colors, code each element to be accessible, and test these patterns across various platforms, browsers, screen readers, and devices. When you know the elements are bulletproof, save them in a pattern library that you can pull from later. Having a pattern library at your fingertips will improve consistency and compliance, and help you meet tight deadlines later on, especially when working in an agile environment. You’ll need to keep this online knowledge repository and pattern library up-to-date. It should be a living, breathing document.

Cross the finish line … and keep going!

Some people mistakenly believe accessibility is a set-it-and-forget-it solution. It isn’t. Accessibility is an ongoing challenge to continually improve the user experience the way any good UX practitioner does. This is why it’s crucial to get leadership on board. Once your site is fully accessible, you must begin working on the backlogs of continuous improvements. If you aren’t vigilant about accessibility, people making even small site updates can unknowingly strip the site of the accessibility features you worked so hard to put in place. You’d be surprised how quickly it can happen, so educate everyone you work with about the importance of accessibility. When everyone working on your site understands and evangelizes accessibility, your chances of protecting the accessibility of the site are much higher.

It’s about the experience, not the law

In December of 2017, Winn-Dixie appealed the case with blind patron Juan Carlo Gil. Their argument is that a website does not constitute a place of accommodation, and therefore, their case should have been dismissed. This case, and others, illustrate that the legality of web accessibility is still very much in flux. However, as web developers and designers, our motivation to build accessible websites should have nothing to do with the law and everything to do with the user experience.

Good accessibility is good UX. We should seek to create the best user experience for all. And we shouldn’t settle for simply meeting accessibility standards but rather strive to create an experience that delights users of all abilities.

Additional resources and articles

If you are ready to learn more about web accessibility standards and become the accessibility evangelist on your team, here are some additional resources that can help.

Resources Articles
Categories: Around The Web

Moving From Flash To HTML, CSS, And JavaScript

Smashing Magazine - Tue, 03/13/2018 - 8:10am

Back in the 2000s, it was commonplace to see websites that were built using Flash. By viewing the source of a website, you’d often see very little HTML and an embedded SWF file. This meant a few things. First, the browser didn’t natively support Flash, so you had to download the Flash plugin. Browsers found it difficult to go into the SWF to read content. Amongst other things, this had a detrimental affect on SEO and accessibility.

In 2007, the iPhone was released. It didn’t support Flash. In 2015, Google moved all its YouTube videos to HTML5. In July 2017, Adobe officially announced it would stop working on Flash by 2020. People used Flash because it could do things that HTML, CSS, and JavaScript couldn’t do at the time. It’s incredible to see how far web standards have come (and what’s coming).

We can do a lot today that was previously only possible with Flash. Not only that, but we can do it in a way that’s far more accessible and performant. I’ll go over some of the groundbreaking things Flash could do and how we can go about doing them today.

Disclaimer: I love Flash, and it will always have a place in my heart, but for me at least, its time has passed. Just in case you’re wondering: there are still so many interfaces and engines running in Flash, especially for games, and this article addresses some of the issues that are very relevant there.

Nope, we can't do any magic tricks, but we have articles, books and webinars featuring techniques we all can use to improve our work. Smashing Members get a seasoned selection of magic front-end tricks — e.g. live designing sessions and perf audits, too. Just sayin'! ;-)

Explore Smashing Wizardry → Video

One of the great things Flash heralded was video, offering basic support as early as 2002. It wasn’t until 2009 that the <video> tag was introduced in Chrome, Safari, and Firefox. Furthermore, Internet Explorer (IE) 8 didn’t support the <video> tag, and it wasn’t until 2011, when IE 9 was released, that it got support.

Flash would use the <object> tag, like so:

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,16,0" width="320" height="400"> <param name="movie" value="filename.swf"> <param name="quality" value="high"> <param name="play" value="true"> <param name="LOOP" value="false"> <embed src="video-filename.swf" width="320" height="400" play="true" loop="false" quality="high" pluginspage="http://www.macromedia.com/go/getflashplayer" type="application/x-shockwave-flash"></embed> </object>

Not the nicest of code, but it did work.

Now, we can simply write <video src="filename.mp4" />, although it is important to be aware of different video formats across browsers, the most popular being MP4, Ogg and WebM. Taking things a step further, it’s possible not only to support the <video> tag, but also offer fallbacks and helpful alternatives:

<video width="320" height="400"> <source src="filename.mp4" type="video/mp4" /> <source src="filename.webm" type="video/webm" /> <source src="filename.ogv" type="video/ogg" /> <!-- Flash fallback --> <object type="application/x-shockwave-flash" data="flash-player.swf?videoUrl=filename.mp4" width="320" height="400"> <param name="movie" value="flash-player.swf?videoUrl=filename.mp4" /> <param name="allowfullscreen" value="true" /> <param name="wmode" value="transparent" /> <param name="flashvars" value="controlbar=over&image=placeholder.jpg&file=flash-player.swf?videoUrl=filename.mp4" /> </object> <!-- Text Fallback --> <p>No video support found. Please download the video below, or upgrade your browser: https://browsehappy.com/</p> </video> <ul> <li><a href="linktomovie.mp4">MP4 format</a></li> <li><a href="linktomovie.ogv">Ogg format</a></li> <li><a href="linktomovie.webm">WebM format</a></li> </ul> Video Background

Because YouTube makes use of the <video> tag and has an API, it’s possible to create a full-screen background video. Take the following YouTube video link code, for example:


Using the different parameters it’s possible to change the way the video behaves.

controls=0 Hides the controls. showinfo=0 Hides extra information. rel=0 Hides related content. autoplay=1 Auto plays the video when the site is loaded. loop=1 Loops the video. mute=1 Mutes the sound.

For a full list, check the IFrame Player API.

Using CSS, we can set the video to be fixed in position and to fill the screen.

.video { background: #000; position: fixed; width: 100%; height: 100%; top: 0; right: 0; bottom: 0; left: 0; z-index: -1; pointer-events: none; }

And with the use of media queries, we can set the video to be centered and can help keep the correct aspect ratio.

@media (min-aspect-ratio: 16/9) { .video { height: 300%; top: -100%; } } @media (max-aspect-ratio: 16/9) { .video { width: 300%; left: -100%; } }

Here’s the example put together, with Mr. Smashing Magazine himself presenting a talk:

See the Pen Video Background Demo Using YouTube by Simon Owen (@s10wen) on CodePen.

Interaction And Gaming

Another thing Flash excelled at was interaction and gaming. The popular website Miniclip was founded in 2001 and hosted a wide range of Flash games. In 2008, it was valued at over £900 million and is still going today.


JUST A REFLEKTOR is an interactive music video that rivals and even surpasses the capabilities of Flash. With the use of various web technologies, it’s now possible to interact with the video using a mobile device, as well as at one point using your webcam so that you actually appeared in the music video yourself!

The website Just A Reflektor makes great use of modern web technologies to create an interactive music video. Cube Slam

There’s some fantastic web-based Chrome experiments online today, such as Cube Slam. Cube Slam is a game that makes use of WebRTC (an open web technology), letting you video chat and play a game within the browser. Although Flash was heavily used for video chat, it came with a number of drawbacks compared to WebRTC: It relied on the Flash plugin, it required a media server, and it had various security implications and poor performance.

Cube Slam is a web based Chrome Experiment that allows video chat whilst playing a game. HTML5 Game Engines

There are a number of HTML5 and JavaScript game engines. This next example makes use of canvas and WebGL. WebGL (Web Graphics Library) is an API built in JavaScript that allows interactive 2D and 3D graphics within the <canvas> tag.

As mentioned in Good Boy Digital’s own post regarding the project (the creators of the example):

"Star Wars Arcade really pushes the boundaries of what’s possible with HTML5 and WebGL technologies. This allows for the creation of a single build that works seamlessly on both desktop and mobile browsers without having to download an app; the advantage of this being able to offer an ‘app like’ experience on all devices so anyone can enjoy it, instantly. No passwords, no App Stores, just hit the URL and play!"

goodboy digital, Star Wars Arcade Case Study

I especially love this bit: “Just hit the URL and play!” One of my earliest “Wow” memories of the web was having my own website in 1999 and being able to type that URL into any computer connected to the web and view it. It seemed absolutely incredible to me that this was actually possible (and continues to amaze me to this day!).

Browser Support

One of the advantages of building something—especially a game, due to the extra complexity—in Flash that is still relevant today is browser support. Browser support is generally pretty good these days, and Can I Use can help us to quickly find out about the state of browser support for a particular specification. However, there are still discrepancies that could cause issues. So, if you’re OK with only supporting browsers that are installed with the Flash plugin you’re working with, then you’re likely not to encounter any cross-browser issues.


Flash was originally designed as an animation tool. As such, it had various limitations with typography.

Flash had a pixel-grid system. If typography was laid on the grid at X:100.3 :100.7 and, thus, out of alignment to the pixel grid, it would look blurred.

As a result, I found that pixel fonts were useful because they sat on the grid and remained crisp. Another limitation here would be if you used an 8-pixel font but set it to 10 pixels, it would go out of alignment with the grid and, again, be blurred.

Thankfully, today in HTML and CSS, we have a host of tools to help us. We can set fonts as an absolute unit in px (pixels) or, more common these days, use ems and rems to aid with responsive web design (I’ll be covering more on this later).

Another issue with Flash and typography was fonts. If a font wasn’t available on the device, a fallback font would be provided. To circumvent this in Flash, you could embed the font in the .swf file. By doing this, though, you added to the file size and, thus, the time that the SWF would take to download and appear.

That being said, what was possible with Flash was Scalable Inman Flash Replacement (sIFR). sIFR allowed HTML text to be replaced with Flash. Before this, in order to use custom fonts, we used images. However, using images didn’t allow for selectable text, and it meant you had to create images manually. Moving on from sIFR, developers came up with Cufón. Cufón avoided the use of Flash by using an SVG and VML version of a font. It was faster than sIFR and didn’t require the Flash plugin; but, again, with this technique, it wasn’t possible to select text.

Today, we have the CSS @font-face rule and a host of standard web fonts available:

In Chrome and Firefox (and, hopefully soon, Safari), we have font-display in CSS. If you’re using a custom font, by default the browser will wait to get the custom font. If it can’t get the custom font, it will use a backup font (the speed varies among browsers, but it is usually 3 seconds). This is known as a flash of invisible text (or FOIT). To improve this scenario, we can use the following:

@font-face { font-display: swap; }

By using swap, we’ll see the text immediately using the backup font. When the custom font is loaded, the browser will swap the backup for it. This way, the user gets to read the content as soon as it’s available.


One of the things that Flash did very well was tweening. Tweening is used to animate elements. In Flash, you could create an element in a keyframe, duplicate that keyframe along the timeline, and then add a tween.

With HTML and CSS, we can apply the same animation using @keyframes, transform and animation.

<div class="box"></div> .box { width: 100px; height: 100px; background-color: #333; } @keyframes move { from { transform: translateX(0); } to { transform: translateX(200px); } } div { animation-duration: 3s; animation-name: move; animation-iteration-count: infinite; animation-direction: alternate; }

See the Pen CSS Animation Example by Simon Owen (@s10wen) on CodePen.

With Chrome Developer Tools, we can inspect and adjust the animation by going to Chrome Dev Tools → Cmd + Shift + P → Animation.

An example showing Chrome Developer Tool’s 'Performance' tab.

It’s also possible to debug potential performance issues that may arise when dealing with animation. In Chrome Developer Tools, there’s a “Performance” tab. By clicking this, then the “Record” circle icon, we can see a range of useful information. This technique greatly helped me when I built Mind’s Annual Report 2012-13, particularly the section of the website that has a map with animated circles showing the locations of Mind shops. Initially, the map section was loaded at the start, which caused repaint issues. Using the “Performance” tab, I was able to identify and update this, so the map only started animating when it was in view.

Vector Graphics

The web has benefitted and still does benefit enormously from careful consideration of file size. Back in the early 2000s, the web was mostly viewed on desktop computers, with slow dial-up modems. A simple image could take seconds or even minutes to load. To help with this, Flash made heavy use of vector graphics. Using vector graphics, where appropriate, instead of JPEG or GIF images, significantly reduced file size and thus load more quickly over the web.

Over the past few years, and particularly thanks to Sara Soueidan, scalable vector graphics (SVGs) have become more and more widespread on the web. SVG is an XML-based markup that enables us to create vector graphics for the web. It works extremely well with animation and I’ve had the pleasure of building some websites that make use of this: the Mind report website (previously mentioned) and How Clean Is England? which Sara mentioned on Twitter! Thanks Sara!

Mind’s Annual Report website made use of SVGs and animation to create a fun way to display their statistics for the year. The How Clean Is England? website was heavily based on illustration. SVGs and CSS animations helped to make the illustrations look crisp and keep file sizes to a minimum. Responsive Web Design

One of the main pitfalls of building a website in Flash today is the lack of media queries. Today, mobile and tablet usage has surpassed that of desktop. In order to create the best experience, we must create a website that is accessible on all of these devices. On many devices, Flash will simply not load at all, and even if it did, it would most likely breach the viewport’s width or would scale and be unusable.

Using media queries, we can create a layout that responds to the content. Here’s an example:

<div class="someContent"> <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit. Est excepturi enim id ratione blanditiis voluptate dolore necessitatibus culpa maxime eius assumenda eveniet dolores odit sunt repellat, rerum amet delectus vel.</p> </div> .someContent { color: green; } @media screen and (min-width: 400px) { .someContent { color: yellow; } } @media screen and (min-width: 600px) { .someContent { color: red; } }

See the Pen Simple Media Query Example by Simon Owen (@s10wen) on CodePen.

ActionScript vs. JavaScript

ActionScript is used in Flash and, thus, has the same pitfall of SWF files mentioned earlier, in that it requires the Flash plugin. JavaScript, on the other hand, is readily available in all modern browsers.

Let’s look at an example of setting a variable in both and their differences:

var x:Number = 42; var x = 42;

With ActionScript, we declare that the variable is a number. If the variable is assigned anything else, it will get an error. JavaScript is loosely typed, which means we could assign the variable as something else, such as a string:

var x = '42';

In JavaScript, if we wanted to check that it is a number, we could use typeof(x);, and this would output “number”. Another option would be to create a function and use isNaN to detect whether it is “not a number”:

function isNumber(value) { if (isNaN(value)) { return value + ' is not a number.'; } return value + ' is a number.'; } console.log(isNumber(42)); // "42 is a number." console.log(isNumber('forty two')); // "forty two is not a number." Collaboration

With HTML, CSS, and JavaScript (and many other coding languages), Git and GitHub make collaboration extremely easy. For example, if I wanted to edit the HTML of Smashing Magazine’s “Author Template,” via GitHub, I could click the “Fork” button. This would create a version of the files (also known as the repository) under my own name. I could then make any amendments I like and submit a pull request. This would give the owner at Smashing Magazine the ability to review my pull request and accept or reject it. Once accepted, the code would go in the main repository.

There are a number of great reasons for working in this way: You always have a backup of your work; you can revert to previous versions of your work, and collaboration becomes very easy. Someone could be working on one section of the website, or on the CSS or JavaScript, and when each team member has finished, you could review the changes and pull them in as required.

If we tried the same with Flash, it would be a lot more difficult having to save and send an .fla file each time. If multiple people were to work on the same .fla, things could get very confusing. With HTML, CSS and JavaScript, it’s’ possible to do a “diff” on the code, which allows us to compare and review the code. We can even select certain code chunks, bring them in, or comment on them for further review and work.


Flash was one of the reasons I started building websites. It pioneered in a lot of areas, and this led to people creating amazing things with it. Over the years, it’s pushed the web forward a great deal. Adobe’s official announcement of dropping support of Flash, though, does raise concerns. It would be a massive shame if millions of websites using Flash were lost. There’s a petition to open source Flash and Shockwave. I do hope we don’t lose it forever. We’ve had some great — and weird — times. I’ll leave you with this classic example of the “weird” to which I refer:

Here are the lyrics, if you’d like to sing along.

(ra, hj, al, il)
Categories: Around The Web

Building A Static Site With Components Using Nunjucks

Smashing Magazine - Tue, 03/13/2018 - 6:00am

It’s quite popular these days, and dare I say a damn fine idea, to build sites with components. Rather than building out entire pages one by one, we build a system of components (think: a search form, an article card, a menu, a footer) and then piece together the site with those components.

JavaScript frameworks like React and Vue emphasize this idea heavily. But even if you don’t use any client-side JavaScript at all to build a site, it doesn’t mean you have to give up on the idea of building with components! By using an HTML preprocessor, we can build a static site and still get all the benefits of abstracting our site and its content into re-usable components.

Static sites are all the rage these days, and rightfully so, as they are fast, secure, and inexpensive to host. Even Smashing Magazine is a static site, believe it or not!

Let’s take a walk through a site I built recently using this technique. I used CodePen Projects to build it, which offers Nunjucks as a preprocessor, which was perfectly up for the job.

A Four-Page Site With A Consistent Header, Navigation, And Footer

This is a microsite. It doesn’t need a full-blown CMS to handle hundreds of pages. It doesn’t need JavaScript to handle interactivity. But it does need a handful of pages that all share the same layout.

Consistent header and footer across all pages

HTML alone doesn’t have a good solution for this. What we need are imports. Languages like PHP make this simple with things like <?php include "header.php"; ?>, but static file hosts don’t run PHP (on purpose) and HTML alone is no help. Fortunately, we can preprocess includes with Nunjucks.

Importing components is possible in languages like PHP

It makes perfect sense here to create a layout, including chunks of HTML representing the header, navigation, and footer. Nunjucks templating has the concept of blocks, which allow us to slot in content into that spot when we use the layout.

<head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>The Power of Serverless</title> <link rel="stylesheet" href="/styles/style.processed.css"> </head> <body> {% include "./template-parts/_header.njk" %} {% include "./template-parts/_nav.njk" %} {% block content %} {% endblock %} {% include "./template-parts/_footer.njk" %} </body>

Notice the files that are included are named like _file.njk. That’s not entirely necessary. It could be header.html or icons.svg, but they are named like this because 1) files that start with underscores are a bit of-of a standard way of saying they are a partial. In CodePen Projects, it means they won’t try to be compiled alone. 2) By naming it .njk, we could use more Nunjucks stuff in there if we want to.

None of these bits have anything special in them at all. They are just little bits of HTML intended to be used on each of our four pages.

<footer> <p>Just a no-surprises footer, people. Nothing to see here.<p> </footer>

Done this way, we can make one change and have the change reflected on all four pages.

Using The Layout For The Four Pages

Now each of our four pages can be a file. Let’s just start with index.njk though, which in CodePen Projects, will automatically be processed and create an index.html file every time you save.

Starting off with an index.njk file

Here’s what we could put in index.njk to use the layout and drop some content in that block:

{% extends "_layout.njk" %} {% block content %} <h1>Hello, World!</h1> {% endblock %}

That will buy us a fully functional home page! Nice! Each of the four pages can do the same exact thing, but putting different content in the block, and we have ourselves a little four-page site that is easy to manage.

The index.njk file gets compiled into index.html

For the record, I’m not sure I’d call these little chunks we re-using components. We’re just being efficient and breaking up a layout into chunks. I think of a component more like a re-usable chunk that accepts data and outputs a unique version of itself with that data. We’ll get to that.

Making Active Navigation

Now that we’ve repeated an identical chunk of HTML on four pages, is it possible to apply unique CSS to individual navigation items to identify the current page? We could with JavaScript and looking at window.location and such, but we can do this without JavaScript. The trick is putting a class on the <body> unique to each page and using that in the CSS.

In our _layout.njk we have the body output a class name as a variable:

<body class="{{ body_class }}">

Then before we call that layout on an indivdiual page, we set that variable:

{% set body_class = "home" %} {% extends "_layout.njk" %}

Let’s say our navigation was structured like

<nav class="site-nav"> <ul> <li class="nav-home"> <a href="/"> Home </a> ...

Now we can target that link and apply special styling as needed by doing:

body.home .nav-home a, body.services .nav-services a { /* continue matching classes for all pages... */ /* unique active state styling */ } Styling navigation links with an active class.

Oh and those icons? Those are just individual .svg files I put in a folder and included like

{% include "../icons/cloud.svg" %}

And that allows me to style them like:

svg { fill: white; }

Assuming the SVG elements inside have no fill attributes already on them.

Authoring Content In Markdown

The homepage of my microsite has a big chunk of content on it. I could certainly write and maintain that in HTML itself, but sometimes it’s nice to leave that type of thing to Markdown. Markdown feels cleaner to write and perhaps a bit easier to look at when it’s lots of copy.

This is very easy in CodePen Projects. I made a file that ends in .md, which will automatically be processed into HTML, then included that in the index.njk file.

Files in markdown get compiled into HTML on CodePen Projects. {% block content %} <main class="centered-text-column"> {% include "content/about.html" %} </main> {% endblock %} Building Actual Components

Let’s consider components to be repeatable modules that as passed in data to create themselves. In frameworks like Vue, you’d be working with single file components that are isolated bits of templated HTML, scoped CSS, and component-specific JavaScript. That’s super cool, but our microsite doesn’t need anything that fancy.

We need to create some “cards” based on a simple template, so we can build things like this:

Creating repeatable components with templates

Building a repeatable component like that in Nunjucks involves using what they call Macros. Macros are deliciously simple. They are like as if HTML had functions!

{% macro card(title, content) %} <div class="card"> <h2>{{ title }}</h2> <p>{{ content }}</p> </div> {% endmacro %}

Then you call it as needed:

{{ card('My Module', 'Lorem ipsum whatever.') }}

The whole idea here is to separate data and markup. This gives us some pretty clear, and tangible benefits:

  1. If we need to make a change to the HTML, we can change it in the macro and it gets changed everywhere that uses that macro.
  2. The data isn’t tangled up in markup
  3. The data could come from anywhere! We code the data right into calls to the macros as we’ve done above. Or we could reference some JSON data and loop over it. I’m sure you could even imagine a setup in which that JSON data comes from a sort of headless CMS, build process, serverless function, cron job, or whatever.

Now we have these repeatable cards that combine data and markup, just what we need:

HTML is controlled in the macro, while data can come from anywhere Make As Many Components As You Like

You can take this idea and run with it. For example, imagine how Bootstrap is essentially a bunch of CSS that you follow HTML patterns in which to use. You could make each of those patterns a macro and call them as needed, essentially componentizing the framework.

You can nest components if you like, embracing a sort of atomic design philosophy. Nunjucks offers logic as well, meaning you can create conditional components and variations just by passing in different data.

In the simple site I made, I made a different macro for the ideas section of the site because it involved slightly different data and a slightly different card design.

It's possible to create as many components as you want A Quick Case Against Static Sites

I might argue that most sites benefit from a component-based architecture, but only some sites are appropriate for being static. I work on plenty of sites in which having back-end languages is appropriate and useful.

One of my sites, CSS-Tricks, has things like a user login with a somewhat complex permissions system: forums, comments, eCommerce. While none of those things totally halt the idea of working staticly, I’m often glad I have a database and back-end languages to work with. It helps me build what I need and keeps things under one roof.

Go Forth And Embrace The Static Life!

Remember that one of the benefits of building in the way we did in this article is that the end result is just a bunch of static files. Easy to host, fast, and secure. Yet, we didn’t have to give up working in a developer-friendly way. This site will be easy to update and add to in the future.

  • The final project is a microsite called The Power of Serverless for Front-End Developers (https://thepowerofserverless.info/).
  • Static file hosting, if you ask me, is a part of the serverless movement.
  • You can see all the code (and even fork a copy for yourself) right on CodePen. It is built, maintained, and hosted entirely on CodePen using CodePen Projects.
  • CodePen Projects handles all the Nunjucks stuff we talked about here, and also things like Sass processing and image hosting, which I took advantage of for the site. You could replicate the same with, say, a Gulp or Grunt-based build process locally. Here’s a boilerplate project like that you could spin up.
(ms, ra, hj, il)
Categories: Around The Web

Tips For Conducting Usability Studies With Participants With Disabilities

Smashing Magazine - Mon, 03/12/2018 - 8:20am

Over the last few years, I ran several usability studies with participants with various disabilities. I thought it would help others if I shared some of my experiences.

In this article, I provide lessons learned or tips to consider in planning and executing usability testing with participants with disabilities. The lessons learned are divided into general that can apply to all types of disabilities; and lessons learned for three specific disability categories: visual, motor, and cognitive. These tips will help you regardless where you work: If you work with an established user research team where usability testing is part of your design process or if you work on your own with limited resources but want to improve the quality of the user research by expanding the diversity of participants.

Windows 10 high contrast mode of Google.com. (Large preview) Background

Several of our clients from a state government agency to several fortune 500 companies came to us at the User Experience Center (UXC) for help with their websites. They wanted to make sure users with disabilities could access their site and accomplish their goals.

There are many different kinds of disabilities, however, there is a general agreement to categorize people with disability into four general categories: visual, auditory, motor (also referred to as "physical"), and cognitive. There are different conditions and much variability within each category, e.g., within visual disabilities, color blindness, low vision, and blindness. There is also a distinction as to when a disability is contracted, e.g., a person who was born blind as opposed to one who lost vision later on in life.

Getting the process just right ain't an easy task. That's why we've set up 'this-is-how-I-work'-sessions — with smart cookies sharing what works really well for them. A part of the Smashing Membership, of course.

Explore features →

Furthermore, as we age or encounter unique situations (such as multi-tasking), we may have a similar experience to people we think of as disabled. Therefore, disabilities should be thought of as a spectrum of abilities that should be accounted for during the design of all user interfaces and experiences.

Typically, in order to ensure that disabled people can use their digital products and services, companies aim for compliance with accessibility guidelines such as the Web Content Accessibility Guidelines (WCAG 2.0). While this is critical, it is also important to have users with disabilities try to accomplish real tasks on the site in usability testing. There may be gaps in the overall user experience...

Think about the typical doors found in buildings. How many times have you tried to open a door one way and realized they actually open the other, for example, push instead of pull. Technically the door is accessible, but it is usable?

Example of doors that are technically accessible, but not usable (handles give impression you should push but must pull to open). (Large preview)

Even if a site follows the accessibility guidelines and is technically accessible, users may not be able to accomplish their goals on the site.

Lesson Learned

In most ways, usability testing with this segment of the population is no different than testing with anyone else. However, there are several areas you need to pay just a bit more attention to so your sessions run smoothly. The lessons or tips are broken down into general ones that can apply to all participants and specific tips for various disability types such as visual, motor, and cognitive.

General Lessons Learned 1. Ensure a baseline level of accessibility before usability testing

Ensure a baseline level of accessibility before usability testing: Planning usability testing, especially recruiting participants can take time both for the project team and the recruited participants.

Two good examples of basic accessibility issues that should be addressed prior to usability testing are:

  • Missing alternative (alt) text.
    Usability testing can be used to see if the alt text used is appropriate and makes sense to participants, but if all the participants are doing is confirming that the alt text is missing then this is not a good use of their time.
  • Appropriate color contrast.
    All page designs should be reviewed beforehand to make sure all foreground and background colors meet WCAG 2.0 AA color contrast ratios.
2. Focus the recruiting strategy

If you work with an external recruiter ask them if they have experience recruiting people with disabilities; some do. If you are recruiting internally (without an external recruiter), you may need to reach out to organizations that have access to people with disabilities. For example, if you need to recruit participants with visually disabilities in the United States, you should contact a local chapter of the National Federation of the Blind (https://nfb.org/state-and-local-organizations) or a local training center such as the Carroll Center for the Blind in Massachusetts (http://carroll.org/). If you use social media to advertise your study, a good approach is to use the hashtag #a11y (stands for accessibility — there are 11 letters between the "a" and "y") in your post.

3. Bring their own equipment/assistive technology

Allow and encourage participants to bring their own equipment such as their own laptop, especially if they use assistive technology. This way, you can truly see how people customize and use assistive technology.

4. Have a backup plan for assistive technology

As stated above in #3. It is best if participants can bring their own equipment. However, it is always wise to plan for the worst, for example, if a participant does not bring their equipment or if there is a technical problem such as you can't connect their equipment to your Wi-Fi network. In the case of visually impaired participants, install assistive technology (AT) such as screen reader software they will be bringing in on a backup PC. For many of the AT software packages, you can get a free trial that should cover you for the usability testing period. This has saved us several times. Even though the configuration was different than what the participants had, we were able to run the session. Participants were quickly able to go into the settings and make some adjustments (e.g., increase the speech rate) and get started with the session.

5. Allow additional time

Provide additional time in-between sessions. Typically we like to reserve 30 minutes between participants. However, when participants plan to bring in their own equipment additional time may be required for setting up and resolving any issues that may arise. When testing with individuals with disabilities, we schedule an hour between sessions, so we have extra time for setting up assistive technology and testing it.

6. Confirm participant needs

Either with the recruiting screener or via email or telephone, confirm what equipment participants will bring in and need to be supplied beforehand. In our lab, we can connect external laptops (that in this case, were outfitted with special accessibility software and settings) to our 1Beyond system via an HDMI cable. In a recent study, all of our participants' laptops had HDMI ports. However, we forgot to check this beforehand. This is an example of a small but important thing to check to prevent show-stopping issues at the time of the test.

7. Consider additional cost

Depending on the disability type transportation to the usability testing location may add additional burden or cost. Consider the cost of transportation in the incentive amount. If feasible, consider providing an extra $25-$40 in your incentive amount so participants can take a taxi/Uber/Lyft, etc. to and from your location. Depending on access to public transportation and taxi/ride-sharing rates in your area the amount may vary. Our participants came to the UXC in different ways — some more reliable and timely than others.

8. Revise directions

Check the directions you provide for accessibility. Make sure they include an accessible path into your building. Test them out beforehand. Do you need to provide additional signage? If so, ensure all signs are clear, concise, and use plain-language directions.

9. Review the emergency evacuation plan

Review the plan in the event of a fire or other emergency. Map out the emergency evacuation plan in advance.

10. Consider logistics

Consider remote usability testing as an option. One of the benefits of bringing individuals with disabilities into the lab for usability testing is observing first-hand participants' use of the product or website in question. However, the logistics of getting to your location may be just too much for participants. If it's possible to test remotely (we typically do this through Zoom or GoToMeeting), it should be considered. This poses the additional challenge of making sure your process for capturing the remote session is compatible with all of the participant's assistive technology, as well as accessible itself. Troubleshooting remotely is never fun and could be more difficult with this segment of the population.

11. Hearing impaired participants

Some participants may have a hearing impairment where the position of the moderator and participant is critical for adequate communication. In the case of hearing-impaired participants, it is important to get their attention before talking to them and also to take turns when engaging in conversation.

To get the most of this research, it is best if the participants are not discovering basic accessibility issues that should have been discovered during an accessibility review and/or testing.

Lessons Learned For Participants With Visual Disabilities

Participants with visual disabilities range from people who are blind and use screen readers such as JAWS, to people that need to the text or the screen to be enlarged using software such as ZoomText or relying on the native screen enlargement in the browser. People that are color-blind also fall into this category.

  • For any documents needed prior to the study such as the consent form, send via email beforehand and ask them review and send back in lieu of a physical signature. If you don't, be prepared to read aloud the consent form and assist in signing the documents for some participants.
  • Make sure directions provide step-wise directions; do not rely only on graphical maps as these may not be accessible.
  • For all documents, make sure color is not used as the sole cue to convey information. Print out all documents on a black and white printer to make sure color is not required to make sense of the information.
  • Get participants mobile phone numbers in advance and meet them at their drop-off point. Be prepared to guide them to the testing location. Review best practice for guiding blind individuals:
  • While Braille documents can be helpful for participants that read Braille, the time and cost involved may not be feasible. Furthermore, all blind people do not read Braille, especially people that have lost sight later in life. It is best to make sure all documents can be read via a screen reader. Unless you are sure if there are no accessibility issues avoid PDF documents and send out simple Word documents or text-based emails.
  • If participants bring guide dogs do not treat them as pets, they are working. Provide space for the dog and do not pet it unless the participant gives you permission.
  • Make sure to explain beforehand any sounds or noise that are or may be present in the room such as unique audio from recording software. This may avoid the participant from becoming startled or confused during the session.
  • Initially when I started to work with blind participants I was worried my choice in language might offend. However, over the years I have learned that most blind participants are fairly relaxed when it comes to speech. Therefore, during moderation do not be afraid to use phrases such as "see" or "look" and similar words when talking to blind participants; for example, "please take a look at the bottom of the page" or "what do you see in the navigation menu?" In my experience, blind participants will not be offended and will understand the figurative meaning rather than the literal meaning.
  • Test out all recording equipment/processes beforehand. Ensure all audio including both human speech in the room and audio/speech from AT such as screen readers will be recorded correctly. During testing of the equipment adjust the locations of the microphones for optimal recording.
Lessons Learned For Participants With Motor Disabilities

Motor disabilities refer to disabilities that affect the use of arms or legs and mobility. These individuals may need to use a wheelchair. Some people may not have full use of their hands or arms and cannot use a standard mouse and keyboard. These people may need to voice recognition software which allows to use voice input or use a special pointing device, for example, one that is controlled by their mouth.

  • In the directions, make sure the route is accessible and routes them via elevators rather than stairs. Also, if participants are driving note the location of accessible parking.
  • Note if doors have accessible door controls. If not you may need to meet the participant and guide them to the testing location.
  • Make a note of the nearest accessible restrooms to the testing location.
  • As with all participants with disabilities, it is best if they can bring in their own laptop with their assistive technology software installed and any other required assistive technology. However, in the case of participants (such as Adriana in Figure 3) that use voice recognition software such as Dragon Naturally Speaking this is critical because they have trained the software to recognize their voice.
  • Make sure the desk or table where the participant will be working can accommodate a wheelchair and the height is adjustable. According to the American with Disabilities Act (ADA), conference tables must be 27 inches high in order to accommodate knee clearance for individuals in wheelchairs..
Adriana Mallozzi conducting a usability test at the User Experience Center. Adriana has a motor disability (cerebral palsy) which affects her entire body. She uses a wheelchair, a sip-and-puff joystick that acts as a mouse, along with Dragon Naturally Speaking. (Large preview) Lessons Learned For Participants With Cognitive Disabilities

Individuals with these disabilities cover a wide range of relatively mild learning disabilities such as Dyslexia to individuals with a more profound cognitive disability such as Down syndrome. In general, people with cognitive disabilities have challenges with one or more mental tasks. Rather than looking at specific clinical definitions it best to consider functional limitations in key areas such as memory, problem-solving, attention, reading or verbal compensation. Consider how best to accommodate participants during usability testing. Many of the tips below should also apply to all participants, however for this group you need to be extra aware.

  • Sometimes participants will be accompanied by a caretaker or an aide. This person may assist with transportation or may need to be present with the participant during the usability test. If the caretaker is present during the usability test, make sure they understand the structure of the usability test and what will be required of the participant. If you know the participant will be accompanied before the study, you review the goals and protocol prior to arrival via email or phone. That is as much as possible the participant should be one conducting the usability testing, and the caretaker should not be involved unless it is completely necessary.
  • In some cases, the caretaker or aide may act like an interpreter. You may need to communicate with this interpreter in order to communicate with the participant. If this is the case, make sure you record the audio coming from both the participant and the interpreter.
  • Provide instructions in multiple modalities, for example, both written and verbal. Be patient and be prepared to repeat the task or ask the same question multiple times.
  • Be prepared to break tasks into smaller sub-tasks to support memory/attention challenges or fatigue that may set in.
  • Ideally, it is best to be consistent with tasks for all participants however for some participants with cognitive disabilities you should be prepared to go off-script or modify tasks on the fly if the current approach is not working.
  • Have the participant's comfort and well-being the number one priority at all times. Don't be afraid to take multiple breaks or end the session early if things are just not working out or the participant is not comfortable.
Amazon.com home page zoomed in at 250%. (Large preview) Additional Insights

The tips above should serve as guidelines. Each participant is unique and may require various accommodations depending on their situation. Furthermore, while some of the tips are categorized for specific disability types, specific individuals may have multiple disabilities and/or benefit from a tip from a different category than their primary disability.

If you or your company have conducted user or customer research, you know the value of gathering feedback about the issues and benefits of products and systems. Testing with individuals with disabilities is no different, as you learn many insights that you would not gain otherwise. However, an additional takeaway for us was the realization that people use assistive technologies in different ways. The following example is specific to people with visual disabilities, but there are similar examples across all groups.

An assumption might be someone that is blind only uses a screen reader such as JAWS and is an expert at it. We found that people with visual impairments actually differ greatly in the level of support needed from assistive technology.

  • Some users need a screen reader for accessing all content.
  • Some users (with more sight/with low vision) only need to enlarge content or invert page colors to increase contrast.
  • Others may need a combination of approaches. One visually impaired participant used both a screen reader along with the zoom function embedded in the web browser. She only used a screen reader for large paragraphs of text, but otherwise simply zoomed in with the web browser and got very close to the screen when navigating around the website.

Furthermore, just like anyone, all users are not experts on the software they use. While some users would consider themselves experts, some only learn enough about the software to accomplish what they need and no more.

Moving Forward

Hopefully you have learned some useful information that will help you include more diversity into your usability testing. However, since there is variability with different disabilities, this may seem overwhelming. I recommend starting small; for example by including one or two participants with disabilities as part of a larger group of 5 to 10 participants. In addition, initially bring in someone that has both experience with usability testing and a lot of experience with their assistive technology so you can focus on getting their feedback rather than how the usability testing process works or their use of their assistive technology.


I would like to thank Jocelyn Bellas, UX Researcher at Bank of America and Rachel Graham, UX Researcher at Amazon. When Rachel and Jocelyn worked at the User Experience Center as Research Associates in 2016, they worked with me on some of the projects referenced in this article and also contributed to a related blog post on this topic.

References (cc, ra, yk, il)
Categories: Around The Web

The Future Of Mobile Web Design: Video Game Design And Storytelling

Smashing Magazine - Fri, 03/09/2018 - 8:00am

As technologies change and design techniques evolve, it’s inevitable that we’d experience massive growth in terms of design quality. There are similar parallels we can see within video game design as well. For instance:

This was CERN, the very first website back in 1991. Just some basic HTML and ample white space:

The very first website to appear online back in 1991. (Large preview)

This example from Smashing Magazine is how we design websites and share information online in 2018:

A much more complicated and yet beautiful web design… 27 years after the advent of websites. (Large preview)

Nope, we can't do any magic tricks, but we have articles, books and webinars featuring techniques we all can use to improve our work. Smashing Members get a seasoned selection of magic front-end tricks — e.g. live designing sessions and perf audits, too. Just sayin'! ;-)

Explore Smashing Wizardry →

Now, if you look at the history of video game design, you’ll note a similar track; one in which early games like Pong were incredibly simplistic and devoid of any real story:

But now there are games like Grand Theft Auto that put players in the actual driver’s seat, allowing them to control the pace, direction, and outcomes of their experience:

As technologies improve and design techniques evolve, improvements in digital design are inevitable. What is truly impressive, however, is how we are now able to use design to tell a story. In other words, we no longer need to use long scrolls to set up plots or describe what a company does. This is especially great when designing for the mobile experience, which already sets pretty strict limits on how much we can “tell” versus “show.”

In this article, I want to look at three ways in which video game designers get the storytelling aspect of design right, and how web designers can use these techniques to provide users with an immersive experience and drive them more quickly and effectively to conversion.

Three Video Game Storytelling Techniques We Need More Of In Web Design

Video games have come a long way since they were introduced in the late ‘70s in terms of graphics, user controls and, of course, story development. With video game design evolving around the same time as web design, there are similar features and trends that can be found between the two. The only thing is, I don’t know if many web designers think to look to video games for design tips.

Granted, the overwhelming use of shocking colors and cheesy dialogue won’t work that well when you’re developing a professional website. However, it’s the way in which video game designers tell a story with design elements — and effectively guide players to the end by using those elements — that we need to pay attention to.

As your visitors’ attention spans shorten and demand grows for more engaging experiences, web designers can greatly benefit from using these storytelling techniques on the web and, more importantly, for mobile.

1. Make Your Visitor the Hero

Ever since the early days of video games, the goal was to put the player in the front seat and to let them be the hero of the story.

Take PAC-MAN, for instance:

The player was always the hero (i.e., PAC-MAN), and his or her mission was to work through the situation (i.e., to fight the ghosts) and get to the end.

The same holds true for modern gaming as well, though many games go the route of giving players the impression they have control over their heroic journey. A good example of this are the Telltale games.

Basically, each of their games is crafted around a well-known story. In the example above, the game is based on the events that unfold in the T.V. show Game of Thrones. Throughout the game, players are called upon to step into the world and make active choices about what happens next. Sometimes this is through dialogue (at 6:00), and sometimes it happens through action (at 11:55).

In the end, every player of the game ends up at the same place regardless of which way they turn or what line they utter. This doesn’t make the experience any less enthralling for the player as they are actively engaged throughout, and there is a reward in the end — even if it’s one they share with every other person who has played this game.

That’s exactly what websites should do for their visitors, right? They allow visitors to take full control over the experience so that they want to get to the end. For the web, this translates to conversion. And the best way to do this, as evidenced by video games, is to give visitors the ability to pick and choose how they traverse through the story.

Here are some ways in which you can do this with web design:

Create User Personas

Develop user personas before you do anything else when strategizing and planning for a website. Your personas should have a key “problem” they face. It’s then your job to establish the user’s journey in a way that helps them discover solutions to that problem.

Enable Avatar Setup

For those of you with websites that allow for users to create profiles, this is a great opportunity to enable them to define their own unique identity. Allow them to upload a photo of themselves and to personalize their profile. You can also give them different access settings which directs what kinds of content they see, what types of offers they receive, and so on.

WordPress membership websites like WPMU DEV are a good example of websites that do this. Users can create their own profiles and earn points and special statuses based on how much work they put into the community.

A fun community where web design and development professionals can set up individual profiles. (Large preview) Use Relatable Content

In video game design, there is something known as “ludonarrative dissonance.” Basically, it “is the unpleasant situation where we’re asking players to do something they don’t want to do… or prevent them from doing what they want.”

You’ve likely encountered this sort of resistance as you’ve designed websites in the past.

You review the analytics and discover high bounce rates on certain pages or even right from within the home page. You discover that there’s a visual element or a line of copy that just doesn’t sit right with your audience. That’s because it’s a disruption in what should be an otherwise immersive experience. By using content that resonates with the visitor, that makes them feel like you’re telling their story, they won’t feel disconnected and want to stray from the goal.

Spin a Fantasy

Here’s an interesting fact: people are 22 times more likely to remember data when it’s presented in a narrative form.

Let’s face it; if you’re building a website on behalf of a business or other professional entity, you don’t have some dramatic tale to spin like a video game does. And that’s fine.

Consumers aren’t visiting websites in order to get caught up in hours of epic storytelling. That said, they do still expect to be engaged by what you’re sharing with them.

So, why not depict a fantastic scenario through visual storytelling? The brain digests visual content 60% more quickly than written content, so your web designs and other visuals (like video, animation, and so on) are the keys to doing this.

The Airbnb blog always does a great job of this type of visual storytelling.

The Airbnb blog is a master of visual storytelling. (Large preview)

While every story is probably told through 800 to 1,000 words, it’s also accompanied by highly attractive visuals that tell you something about what you’d experience at this specific destination.

2. Minimize Distractions by Using Symbols

Let’s talk specifically about websites viewed from mobile devices for a second, shall we? As of August 2017, 52.64% of all visits to websites were done via a smartphone. And, starting in 2017, the most popular size for a smartphone was between five and six inches and will only continue to grow in popularity as the years go on.

That’s not a lot of space to fill with content for the majority of site visitors, is it? So, how do you effectively tell a story if you have limited real estate? If we’re to take a page out of the video game design handbook, then we should turn to symbols.

Kontra makes a good point about this:

"[O]ne, often overlooked, strong point of game UX is the preference towards symbolism. The ability to transform meaning into symbols was a huge step towards visual decluttering."

Functional minimalism is already something you’re doing in your own web design efforts, but have you thought about how it can tie into the storytelling aspect as well? When it comes to video games, symbols help clear the way so that players can focus on the story before them. You’ll see this most often in two-dimensional, side-scroller games:

Street Fighter and other fighting games place the health bar at the top:

Sonic the Hedgehog places the life counter at the bottom:

There are even ones like Virtua Racing and other geographic-dependent games that put their navigation off to the side for players to reference:

As you can see, the use of symbols keeps the gamespace clear and easy to follow along with.

Whether you’re designing mostly for desktop or mobile users, your aim is to design a space that encourages users to follow along and not get caught up in distractions. So, while you might think that full-screen, overlay navigation is a creative choice for your website or the ever-present live chat pop-up will get more engagements, you may be doing yourself a great disservice.

By employing the use of easily recognized symbols throughout your site, you can keep the design clean and clear and distraction-free. The story you’re weaving throughout is the most important thing, and you don’t want to stand in the way of visitors being able to get to it.

MSR is a beautiful example of this done well:

A good example of how to minimize navigation and directional cues so visitors can focus on the main content and story. (Large preview)

The website is for their architecture design firm. Rather than write volumes of text about what they’ve done and how they do it, they allow the images to speak for themselves. They’ve then employed a number of symbols to help visitors continue on to other points of interest in their journey.

Here are some ways in which you might use symbols to declutter your site:

  • Hamburger icon (for the navigation)
  • Profile photo icon (for account details)
  • Pencil icon (for an editing interface)
  • Gear icon (for settings)
  • Shopping cart icon (to checkout)
  • Magnifying glass (to expand the search bar)
  • Connector icon (to open social sharing and RSS feed options)
  • Question mark (to expand live chat, search, or help options)
  • And so on.

One thing to note here is that you don’t want to overdo it with icons. As you can see from the video game examples above, the entire interface isn’t strewn with icons. They’re simply there to hold the place of elements players are already familiar with and will refer to often. That’s the way you should handle icons for your own site. Think about how easy your icons will be to decipher as well as which ones are absolutely necessary. Decluttering doesn’t mean hiding every element under an icon; you simply want to tidy up a bit.

If you’re concerned with the potential for confusion over what your icons mean to users, then use labels, alt text, or tooltips to provide further elaboration to those who need it.

3. Be Smart About How You Use Space

One of the nice things about video games is how they use actual walls and roadblocks to prevent players from navigating into territory where they shouldn’t be. One of my favorite games that does this right now is called LittleBigPlanet. While it is similar to side-scrolling adventures like Super Mario, its design expands beyond the basic two dimensions usually experienced in these kinds of games.

As you can see, the player encounters a number of hard surfaces which then prompt him or her to move back and forth between layers, to climb up various elements, and to find a more ideal route towards the end of the game.

First-person shooter games like Halo also use physical elements to keep players confined to the main gamespace and on track to completing the mission and story.

As a web designer, you don’t have the luxury of crafting walls around the user’s journey on your site. That said, you don’t have to design a website and leave it all to chance. There are ways to steer visitors through a direct path to conversion.

Kill Screen did an interesting write-up about the art of spatial storytelling in video games. In it, writer Sharang Biswas explained the idea that “Spaces can be designed. They can be made to promote certain pathways, encourage specific behaviors, even elicit emotional reactions.”

There are a number of ways in which you can do this with design:

Use a Spotlight

In video games, you can use light and darkness to draw attention to important pathways. On websites, it’s not always easy to employ the use of lightness or darkness as too-dark of a design or too-light of text could lead to a bad user experience. What you want to do instead is create a “spotlight” of sorts. You can do this by infusing a key area of your design with a dramatic color or a boldly stylized font.

In a site that’s otherwise pretty light in color usage, Kappow does a nice job using it to highlight two key areas of the site where it’s clear visitors should visit: its case studies.

It’s more than obvious where Kappow wants visitors to focus their attention as they scroll through the home page. (Large preview) Add Clues

If you’ve ever played a horror video game before, you know how critical the element of sound can be for it. Here’s an example of how Until Dawn uses sound (as well as visual footprints) to try to steer the player in the right direction:

In all honesty, I’m not a big fan of music on websites, even if they’re from auto-play videos that I visited the website for in the first place. I’m sure I’m not the only one who feels this way as there aren’t many websites that employ the use of background music or auto-play audio anymore.

That said, while you might not be able to direct visitors down the page with the sound of something playing down below, you can use other elements to lead them. For one, you can use interactive elements like animation to draw their attention to where it needs to go. Let’s take a game like Angry Birds, for example.

See how the little red birds are hopping up and down while they wait their turn? It’s a subtle gesture, but one that is sure to draw first-time players’ attention to the area of the screen in which they should directly interact if they want to move on to the next level. Animation on a website would work just as effectively if you’re trying to lure visitors’ eyes down to a key element like a contact form or a clickable button.

But it doesn’t just have to be animation. Other video game designers simply plant clues around the landscape to steer players through the journey. I’m not suggesting that your site start hiding Easter eggs all over the place. Instead, you may want to think about using subtle arrows or lines that define the space in which visitors should “play” and then move down through.

Employ a Mascot

For some brands, it might make sense to employ the use of an actual mascot to guide visitors through the story. If it’s an already established mascot and it won’t intrude too heavily on the experience, then why not bring it on the journey to ensure that visitors are checking in at all the right spots?

Or you can do like BarkBox and use a series of related mascots to guide visitors through different parts of the site (especially the signup and subscription process).

BarkBox uses a series of illustrated black-and-white mascots to guide visitors through the conversion processes. (Large preview) Summary

As attention spans shorten and visitors just want to get to the good stuff on a website, designers have to get more creative in how they communicate their website’s “story.” Ideally, your web design will do more showing of that story instead of telling, which is how video game design tends to succeed in this matter.

Remember: Storytelling isn’t just relegated to big brands that can weave bright and shiny tales about how consumers’ lives were changed with their products. Nor is it just for video game designers that have hours of gameplay to develop for their audiences. A story simply needs to convey to the end-user how their problem can be fixed by your site’s solution. Through subtle design strategies inspired by video game storytelling techniques, you can effectively share and shape your own story.

(da, ra, yk, il)
Categories: Around The Web

An Introductory Guide To Business Insurance For Designers And Developers

Smashing Magazine - Thu, 03/08/2018 - 7:50am

At some point in your career, most web designers and developers can relate to issues with scope creep, unexpected project delays, client relationships breaking down, and unpaid invoices. The good news is that there’s an insurance policy to help with these scenarios. In the UK, we call it “professional indemnity insurance.” Elsewhere, it can be called “professional liability” or “errors and omissions insurance.”

Let’s explore what this insurance is and how it’s designed to keep web professionals in business. I’ll also be sharing real stories of businesses who were glad they had insurance.

What Is Professional Indemnity Insurance?

Professional indemnity insurance protects your business from screw-ups and problem clients.

Let’s say a client threatens legal action, claims loss of income or damages due to a service you provided. Even if you’re in the wrong, professional indemnity steps in to ensure the consequences to your business aren’t crippling.

A creative agency working on a project together. (Large preview)

It’s also important to distinguish what professional indemnity insurance isn’t. After all, business insurance is an umbrella term for different types of cover. One of those covers is public liability insurance — or general liability insurance as it’s known in the US.

Public liability insures your business against claims of:

  • physical injury to clients and members of the public
  • accidents on your work premises
  • damage to third-party property.

This is a popular cover for those who have clients visit their office or those who work from client premises. However, in this article, we’re focusing exclusively on professional indemnity.

Getting the process just right ain't an easy task. That's why we've set up 'this-is-how-I-work'-sessions — with smart cookies sharing what works really well for them. A part of the Smashing Membership, of course.

Explore features → How Can Insurance Help Me If I’m A Designer Or Developer?

Business insurance isn’t often talked about in web circles. I think it’s because insurers have focused their products and user experience on traditional industries. A lot of the information out there isn’t relevant to those of us working in digital.

To add to that, people don’t equate working with a computer as being a danger or massive liability. Especially when you have all of your clients sign a contract. This can lull designers and developers into a false sense of security. A common objection I hear from web professionals when talking about insurance is:

I can't cause any damage as a web designer. For anything that does go wrong, I have a clause in my contract that says I'm not liable.

Firstly, I have to debunk the myth of not needing to have insurance because you work with a contract. Contracts don’t alleviate you from liability. They’re useful for laying the foundation of what duties are expected of both parties, but insurance steps into action when those duties come into question.

With every scenario I’m sharing today, they all had the following in common:

  • A contract was signed by both parties.
  • They had years of experience in their profession.
  • They were professionally insured, but never expected to have to use their insurance.

Below are real stories of how professional indemnity insurance helped these designers and developers.

Scope Creep

A developer built a web platform to spec, but the client complained of missing functionality.

The developer agreed to build the perceived missing functionality for a further fee, but the client believed it should have been included in the initial build. Not only did the client refuse to pay the remaining invoice, but they threatened legal action if the developer didn’t cooperate.

Having professional indemnity insurance meant that the developer had a team of legal experts behind him. They helped the developer communicate with his client to avoid the problem escalating.

The developer’s professional indemnity policy also had a mitigation costs clause. This meant the insurer paid the amount owed to him by his client, which was thousands of pounds.

Project Delays

Designers and developers often work to tight deadlines. Missing deadlines can cause problems if the project has an important launch date.

A creative agency was hired to design a website, but the project started to unravel. Key members of the team left part way through the project and the pace of the work being completed slowed down.

While the website was delivered in time for launch, it was missing a lot of major features. The client said it wasn’t fit for purpose.

After wasting money on a marketing campaign for the launch, the client refused to pay the final invoice. They also incurred extra expenses from hiring new contractors to complete the website’s missing features.

The client threatened to involve solicitors if the agency pursued payment.

The unpaid invoice was settled by the insurer under the mitigation costs clause of their professional indemnity policy. The insurer also provided the agency with legal advisors to confirm with the client that the project is considered at an end.

Client Relationships Breaking Down

This is a common catalyst for professional indemnity claims. Even if we spot a few amber flags, we like to believe we can make our client relationships work and projects run smoothly. However scary it is, sometimes you have to burn bridges with a client.

A designer did this when working with a client they felt didn’t respect them. An ever-changing scope, long hours, and poor pay lead to a breakdown in the relationship. What had started off as a promising project was now a strained working relationship and source of stress. The designer decided to walk away from the project.

Unfortunately, that wasn’t the end of things. The client wanted to be reimbursed for the money they had already paid to the designer. They also wanted damages for the loss of income due to a delayed launch and compensation for hiring other contractors to complete the project.

A team of legal experts was arranged by the insurer to deal with the designer’s client. A settlement was agreed out of court, which was also covered by the insurer.

What Does A Professional Indemnity Policy Insure Against?

Professional indemnity insurance is a meaty policy, so it isn’t feasible to cover every scenario here. At its core, it’s designed to put your business back in the same financial position after a loss as it was in before a loss. As you can see from the stories above, a loss can be legal fees, client damages, compensation or even unpaid invoices. However, this has to stem from a client expressing dissatisfaction with your work.

While all professional indemnity policies differ, let’s look at some of the key features you can expect to see.

Defence Costs

If a client makes a claim against you, your professional indemnity policy will pay the defence costs. This isn’t just for situations that have escalated to court. Insurers want to solve problems before they get to that stage, so they’ll provide a team of legal experts to help negotiate terms with your client.

Intellectual Property Infringement

Web and graphic designers are vulnerable to arguments over copyright infringement, whereas developers could get into disputes over who owns the code. This clause covers claims against copyright infringement, trademarks, slogans, and even domain names.

Mitigation Costs

If you read the stories above, you’ll have seen mitigation costs mentioned where unpaid invoices were paid by the insurer. If a client is dissatisfied with your work, refuses to pay any or all your fees and threatens to bring a claim against you, professional indemnity may pay the amount owed to you by your client. This is only if the insurer believes it will avoid a claim for a greater amount.


Negligence covers a broad spectrum, but think of this as a warranty for any mistakes you make that lead to an unhappy client.

Unintentional Breach Of Contract

Breach of contract can take many forms. It could be something as simple as failing to deliver a project on time or not meeting the client’s expectations. Any breach of contract may entitle the client to make a claim against you.

A web developer working on his laptop. (Large preview) Some Practical Tips For Buying Insurance

The first question people ask when it comes to buying insurance is, “How much should I insure my business for?”. The level of cover will typically start at £100,000 and can go well into the millions. It can be a difficult question to answer, but there are factors that can help you arrive at a reasonable figure.

Client Contracts

If your client contract has an insurance clause, it’s usually for £1,000,000 of professional indemnity. This is the base level of cover a client would expect. It’s the most common level of cover I see businesses buy.

Types of Clients

What type of clients are you working with? Is it large corporations with in-house legal teams, or local small businesses? It’s not unwise to assume the larger companies pose a bigger threat, therefore should have a higher level of cover. You may also find that larger companies will have an insurance clause in their contract.

Type Of Work You Do

A developer building a payment platform will potentially face a bigger risk than somebody designing a website to showcase a restaurant’s menu. Does your work involve dealing with sensitive information or higher-cost products? Are businesses depending on your service to generate income for them?

If it feels like I’ve skirted around answering this, it’s because there isn’t a straightforward figure. A lot of insurers will simply tell you to buy what you’ve budgeted for. If in doubt, consider a base level of £1,000,000 and periodically evaluate your clients and type of work you do. Most insurers allow you to make a mid-term adjustment part way through your policy to increase your level of cover.

Other than the cost of insurance, there are a few other factors to be aware of when buying insurance.

Insuring More Than One Activity

The web is a multi-disciplinary industry. You should be looking for a policy that can cover your various activities. A web developer may also provide web hosting. A designer may also offer consulting services. If you fall outside of the typical box, you might find it useful talking to a broker or using a service like With Jack where your policy can be customized instead of using an online comparison site.

Insuring Your Work Worldwide

By default, professional indemnity policies in the UK exclude US jurisdiction. If you’re working with US clients under US contract law, look for an insurer that can lift the jurisdictional limit from your policy, so you’re insured worldwide. Just beware that it will increase your premium.

Your Policy Can Adapt To Your Needs

Insurance can be flexible. Don’t delay buying insurance because you’re thinking of switching from sole trader to Limited company down the line, or because you’re waiting to add a new service to your business. A good insurance company will allow you to adjust your policy, adapting it as your business changes and grows.

How Insurance Can Help You Build A Bulletproof Business

Whenever I see newcomers ask for advice on starting their business in the web industry, I see a lot of suggestions that look like this:

  • “Get an accountant immediately.”
  • “Build a network!”
  • “Have your clients sign a contract.”
  • “Monitor your cashflow!”

This is all great advice, of course, but rarely do I see anybody mentioning getting insured. Insurance should be a crucial part of any professional designer or developer’s toolbox.

Offering your professional services to clients comes with a degree of risk. It’s your responsibility to mitigate that risk. You have to be confident that — if something does go wrong — you can get back to work quickly. There can be issues with mistakes in your work, a relationship going sour or a client claiming they’re unhappy with your service. It doesn’t matter how good you are, these things happen!

This is why I’m sharing these stories — to highlight the importance of being insured. I want to get web professionals not just thinking about insurance, but understanding it. Insurance is something we don’t necessarily want to budget for or consider, yet as professionals, we have to. The stories above show how critical it can be.

So yes, work with a contract. Monitor your cash flow. Have an accountant manage your bookkeeping, but also get insured. There’s little point in building your business only for one problem client or mistake to take it away from you.

(ra, yk, il)
Categories: Around The Web

How To Build A Skin For Your Web App With React And WordPress

Smashing Magazine - Wed, 03/07/2018 - 8:00am

So you’ve trained yourself as a web engineer, and now want to build a blazing fast online shop for your customers. The product list should appear in an instant, and searching should waste no more than a split second either. Is that the stuff of daydreams?

Not anymore. Well, at least it’s nothing that can’t be achieved with the combination of WordPress’ REST API and React, a modern JavaScript library.

Wait, What? WordPress REST API?

Yes, the WordPress REST API will help you build the back-end foundation for your web application. This is a good choice for your web application’s back-end technology if you are building a content-driven solution. WordPress will interoperate smoothly with other technologies as well; you could use Node.js as the focus of your application to connect to other RESTful services.

The WordPress REST API is a game-changer for WordPress, which can now safely be called a web application framework — not just a CMS. Now that the front- and back-end are completely decoupled, WordPress can be used as a mobile app back-end or as a back-end for any system focusing on content.

But why WordPress? The reason: You will be amazed at the functionalities that emerge out of the box with WordPress. You will get extensive user management, media management, and an incredibly developer-friendly set of APIs to extend your work.

In this article, I will walk you through building an SPA (Single Page Application) WordPress theme using the JavaScript library called React, connecting to the WP REST API.

“You must unlearn what you have learned!” Meet the brand new episode of SmashingConf San Francisco with smart front-end tricks and UX techniques. Featuring Yiying Lu, Aarron Draplin, Smashing Yoda, and many others. Tickets now on sale. April 17-18.

Check the speakers → Let’s Jump Into Building The Theme

This article assumes you are already familiar with the various existing WordPress APIs, particularly the ones that drive the development of themes for your site’s aesthetics, and functionalities for your site’s plugins. I also assume you have set up your development platform for WordPress, such as the LAMP stack in a Linux or MacOS environment.

For simplicity, though, I will refer only to absolute paths as visible with the XAMPP platform that is used with Windows.

Now, let’s create an instance of WordPress in our localhost, naming it ‘Celestial.’ That is the name of the WordPress theme we are going to use to help us set the direction for building future themes ready for use with web applications powered by the WordPress REST API. You may already be familiar with WordPress’ much-loved template hierarchy, but with the REST API, you have an opportunity to discover something different!

We then need to create a folder for the theme within the wp-content\themes folder. Navigate to C:\xampp\htdocs\celestial\wp-content\themes\ (or equivalent) and create a folder celestial. Add these files inside the celestial theme folder:

  1. index.php
    The catch-all file for the theme.
  2. style.css
    This contains information about the theme (and not actual CSS).
  3. functions.php
    To write the functionality and the importing of CSS and JS files.

Add an image file named screenshot.jpg if you want a picture for your theme showing inside the dashboard.

Note: The code for each file is a few lines long and can be found on GitHub.

Next, log in to your WordPress Dashboard, head over to AppearanceThemes and select ‘Celestial’ as the theme. Now that the foundation is in place, let’s get onto creating the theme.

You can select the 'Celestial' theme you created from the Themes panel in the dashboard. Getting Started With React And Webpack For The Theme

React is a very popular UI library supported and maintained by Facebook. According to Stack Overflow’s Developer Survey 2017 results, “React is the most loved among developers.”

React: A JavaScript library for building user interfaces.

For starting the project, you need to initialize the project as an NPM (Node Package Manager) project. This is done with the command npm init in the terminal (after having installed Node.js and NPM on your computer). Initializing the project will prompt you for certain configuration information. After successful initialization, NPM will create a package.json file in the theme’s root directory. This file will include the project details and all dependencies of the project.

React is now under MIT license, so we will be using version 16 of React as the JavaScript library for this project. React has some cool features under the hood, such as the Virtual DOM (a representation of the document within memory) and has a host of tools surrounding it such as the React Router. React is also used in the WordPress’ Project Calypso — the dashboard for WordPress.com.

We will now install the required NPM packages to the project:

  1. Type npm install --save react react-dom in the terminal and press enter to install the packages. Using npm to install react and react-dom. Since we are building the theme as a Single Page Application (SPA), we need the help of a tool such as Webpack. We will be writing code as different components, and Webpack will help us package them all together and output them as a single .js or .css file. In short, it’s a module bundler.

    Webpack has first to be installed globally on your computer. To do that, we again can utilize NPM.
  2. Type in the command npm install -g webpack to get the latest stable version of Webpack installed globally in your system.

    Next, we will install NPM packages supporting Webpack in our app.
  3. Go to the package.json file in my git repo and copy the rest of the dependencies from there into your package.json’s dependencies section. Then run npm install again to install all the packages within package.json. { "name": "celestial", "version": "1.0.0", "description": "A basic theme using the WordPress REST API and React", "main": "index.js", "dependencies": { "babel-core": "^6.26.0", "babel-loader": "^7.1.2", "babel-preset-es2015": "^6.24.1", "babel-preset-react": "^6.24.1", "css-loader": "^0.28.7", "extract-text-webpack-plugin": "^3.0.1", "file-loader": "^1.1.5", "image-webpack-loader": "^3.4.2", "node-sass": "^4.5.3", "path": "^0.12.7", "react": "^16.0.0", "react-dom": "^16.0.0", "react-router-dom": "^4.2.2", "sass-loader": "^6.0.6", "style-loader": "^0.19.0", "url-loader": "^0.6.2", "webpack": "^3.6.0" }, "devDependencies": {}, "scripts": { "build": "webpack", "watch": "webpack --watch" }, "keywords": [ "blog", "decoupled", "react", "rest-api" ], "author": "Muhammad Muhsin", "license": "GPL-3.0" }
    The above is a list of all required packages in the package.json file for this project.
  4. Copy the configurations from GitHub and paste it into your theme folder’s webpack.config.js file. var ExtractTextPlugin = require("extract-text-webpack-plugin"); var path = require('path'); module.exports = { entry: { app: './src/index.jsx' }, output: { path: path.resolve(__dirname, 'dist'), filename: '[name].js' }, module: { rules: [ { test: /\.scss$/, use: ExtractTextPlugin.extract({ fallback: 'style-loader', use: ['css-loader','sass-loader'], publicPath: 'dist' }) }, { test: /\.jsx?$/, exclude: /node_modules/, use: 'babel-loader' }, { test: /\.(jpe?g|png|gif|svg)$/i, use: [ 'file-loader?name=[name].[ext]&outputPath=images/&publicPath=http://localhost/celestial/wp-content/themes/celestial/dist/images', 'image-webpack-loader' ] }, { test: /\.(woff2?|svg)$/, loader: 'url-loader?limit=10000&name=fonts/[name].[ext]' }, { test: /\.(ttf|eot)$/, loader: 'file-loader?name=fonts/[name].[ext]' } ] }, resolve: { extensions: ['.js', '.jsx'] }, plugins: [ new ExtractTextPlugin({ filename: "style.css", allChunks: true }) ] }
    Important: Please note that module.exports → module → rules[3] → use → publicPath can change according to where your project’s dist images are situated in localhost. If this is wrong, images may not display correctly in the web app.
  5. Afterwards, these commands can be used to compile the project:
    • webpack or npm run build to compile the project, or
    • webpack --watch or npm run watch to compile the project and watch for changes.

Note: To get a better understanding of Webpack, read this article by Joseph Zimmerman on Smashing Magazine.

Extending The WordPress REST API

The WordPress REST API comes with many different endpoints for fetching posts, pages, media and so on. However, they may not always have all the details in their response. For instance, the posts method does not give the URL of the featured image or the author’s name. Therefore, we have to make separate calls to each of these elements.

Access your WordPress site's data through an easy-to-use HTTP REST API.

But what if you wanted to have your own data appear within the posts response? That’s where the magic of extending the REST API comes in. The following code will add two additional variables in the response to the posts request, namely author_name and featured_image_src. The code is within the functions.php file:

// Add various fields to the JSON output function celestial_register_fields() { // Add Author Name register_rest_field( 'post', 'author_name', array( 'get_callback' => 'celestial_get_author_name', 'update_callback' => null, 'schema' => null ) ); // Add Featured Image register_rest_field( 'post', 'featured_image_src', array( 'get_callback' => 'celestial_get_image_src', 'update_callback' => null, 'schema' => null ) ); // Add Published Date register_rest_field( 'post', 'published_date', array( 'get_callback' => 'celestial_published_date', 'update_callback' => null, 'schema' => null ) ); } add_action( 'rest_api_init', 'celestial_register_fields' ); function celestial_get_author_name( $object, $field_name, $request ) { return get_the_author_meta( 'display_name' ); } function celestial_get_image_src( $object, $field_name, $request ) { if($object[ 'featured_media' ] == 0) { return $object[ 'featured_media' ]; } $feat_img_array = wp_get_attachment_image_src( $object[ 'featured_media' ], 'thumbnail', true ); return $feat_img_array[0]; } function celestial_published_date( $object, $field_name, $request ) { return get_the_time('F j, Y'); }
Extending the REST API with additional variables in the functions.php file.

A Global JavaScript Variable

There are certain WordPress constants (or known as ‘variables’) that we will be using throughout the React app. This will be information about the various routes of the application (and later on be WooCommerce specific ones).

This variable is defined within the functions.php file. It will be called ‘CelestialSettings’ and be appended to celestial-scripts, the handle for the enqueued app.js file:

wp_enqueue_script( 'celestial-script', get_stylesheet_directory_uri() . '/dist/app.js' , array(), '1.0', true ); $url = trailingslashit( home_url() ); $path = trailingslashit( parse_url( $url, PHP_URL_PATH ) ); wp_scripts()->add_data( 'celestial-script', 'data', sprintf( 'var CelestialSettings = %s;', wp_json_encode( array( 'title' => get_bloginfo( 'name', 'display' ), 'path' => $path, 'URL' => array( 'api' => esc_url_raw( get_rest_url( null, '/wp/v2' ) ), 'root' => esc_url_raw( $url ), ), 'woo' => array( 'url' => esc_url_raw( 'https://localhost/celestial/wp-json/wc/v2/' ), 'consumer_key' => 'ck_803bcdcaa73d3a406a0f107041b07ef6217e05b9', 'consumer_secret' => 'cs_c50ba3a77cc88c3bf46ebac49bbc96de3a543f03' ), ) ) ) );
Passing WordPress (PHP) variables to the front-end.

The above code shows an example of getting WordPress (PHP) variables to the front-end, an important and very useful technique when building a decoupled theme. This object variable holds the site title, path, the URL for the API and root and three variables relating to WooCommerce (explained later).

React And JSX

React is different from the rest of the major JavaScript libraries. What I mean by that is, we generally write JavaScript within our HTML. However, when it comes to React, we write HTML inside our JavaScript code. To be more accurate, we write JSX inside JS. JSX is very similar to HTML but has a few differences. The class attribute is written as className for instance. This is then converted to plain JavaScript through Webpack and Babel and saved within app.js.

There are, however, a few restrictions with writing JSX. For instance, we can have only one child within our render() method, which will serve as the root element for a Component. However, the advantage is that it is easier to debug. We can know exactly where we have made a mistake, whereas in normal HTML our error will generally not be shown explicitly. We will be writing JSX for this project, and therefore, the JavaScript files will have an extension of .jsx. However, it could also be .js if you prefer so.

Create the following files within the src folder:

  1. index.jsx (the main file and the one which contains the React Router configurations)
  2. header.jsx (the header component)
  3. footer.jsx (the footer component)
  4. posts.jsx (for the archive of posts)
  5. post-list.jsx (component for an individual post within posts.jsx)
  6. post.jsx (for a single post)
  7. products.jsx (contains all the products from WooCommerce)
  8. product.jsx (displays a single product from WooCommerce)
  9. style.scss (to contain all CSS code in SASS format)
Folder structure of the src folder in the Celestial project. ReactDOM.render()

The index.jsx file is the root of the project. What I mean by that is, the index.jsx contains the component App which is rendered to the DOM.

import { render } from 'react-dom'; // importing render from ReactDOM const App = () => ( // defining the routes <div id="page-inner"> <Header /> <div id="content"> <Switch> <Route exact path={CelestialSettings.path} component={Posts} /> // the root path </Switch> </div> <Footer /> </div> ); // React Router const routes = ( <Router> <Route path="/" component={App} /> </Router> ); render( // rendering to the DOM by replacing #page with the root React component (routes), document.getElementById('page') // rendering the route );

The other components are specified within React Router and will be loaded upon visiting the different routes.

This is how we write modular components where all the different components ultimately end at index.jsx.

Stateful vs. Stateless Components

You would have noticed components being written in either of the following two ways:

  1. const App = () => (
  2. class Post extends React.Component {

The first way is how we write Stateless Components and the second is an example of Stateful Components. Stateless means that component does not have ‘state’ in it. ‘state’ is essentially a variable that has information within the component, and every time the variable changes, the component is re-rendered. Stateful Components are also known as ‘Smart Components.’ The state variables are thus used for inner communication within that component.

The second type, Stateless Components do not have the state variable in them and sometimes called ‘Dumb Components.’ However, like Stateful Components, they have ‘props,’ which are properties passed down to them from their parent components.

Stateful components have the React lifecycle methods whereas the Stateless one has only the render() method which is the default method for it.

React Lifecycle Methods

These are methods called at different stages in the component’s lifecycle, which we can override to run our own code at those instances. We are utilizing the following methods in our application:

  • constructor()
    Called before a component is mounted.
  • componentDidMount()
    Invoked immediately after a component is mounted.
  • render()
    The method which is called to render the JSX (HTML) content.
  • componentDidUpdate()
    Called when the component is updated.
  • componentWillUnmount()
    Invoked when a component is to be removed.

Note: To learn more about Components and their lifecycle, read the documentation here.

Is your pattern library up to date today? Alla Kholmatova has just finished a fully fledged book on Design Systems and how to get them right. With common traps, gotchas and the lessons she learned. Hardcover, eBook. Just sayin'.

Table of Contents → JavaScript Promises

We are going to use JavaScript Promises to get data from our WordPress REST API. First, we have the URL to the REST API in our functions.php, where we have appended it as a JavaScript variable which we can access from the front-end.

We will use JavaScript’s fetch API method to get data from the different endpoints. We are adding a loader to show the user while the content is being fetched:

getMorePosts() { var that = this; var totalPages; // adding a loader jQuery("#loader").addClass("active"); this.setState({ page: this.state.page + 1 }); fetch(CelestialSettings.URL.api + "/posts/?page=" + this.state.page) .then(function (response) { for (var pair of response.headers.entries()) { // getting the total number of pages if (pair[0] == 'x-wp-totalpages') { totalPages = pair[1]; } if (that.state.page >= totalPages) { that.setState({ getPosts: false }) } } if (!response.ok) { throw Error(response.statusText); } return response.json(); }) .then(function (results) { var allPosts = that.state.posts.slice(); results.forEach(function (single) { allPosts.push(single); }) that.setState({ posts: allPosts }); // removing the loader jQuery("#loader").removeClass("active"); }).catch(function (error) { console.log('There has been a problem with your fetch operation: ' + error.message); jQuery("#loader").remove(); }); }
Fetching data from various endpoints, with loader to indicate process is running.

Using The React Router

React Router is the library that will handle client-side routing for our application. Server-side routing is possible with WordPress, but to achieve a truly SPA experience we need the help of React Router.

Since version 4, React Router has been broken into three packages: react-router, react-router-dom, and react-router-native. We will be using react-router-dom for this project since that is the one used in web applications.

Since react-router-dom is installed already, we can write the router configuration inside the index.jsx file. The code will be as follows:

const App = () => ( <div id="page-inner"> <Header /> <div id="content"> <Switch> <Route exact path={CelestialSettings.path} component={Posts} /> <Route exact path={CelestialSettings.path + 'posts/:slug'} component={Post} /> <Route exact path={CelestialSettings.path + 'products'} component={Products} /> <Route exact path={CelestialSettings.path + 'products/:product'} component={Product} /> <Route path="*" component={NotFound} /> </Switch> </div> <Footer /> </div> ); // Routes const routes = ( <Router> <Route path="/" component={App} /> </Router> ); render( (routes), document.getElementById('page') );
Router configuration in the index.jsx file.

The above code will take care of all routing, handled in the client side. The * in the last line says that any other route not mentioned above will take the user to the ‘404 Not Found’ page.

The <Link to=""> tag is used instead of the <a href=””> tag for linking between different pages using React Router:

<div className="navbar-nav"> <Link className="nav-item nav-link active" to={CelestialSettings.path} >Home <span className="sr-only">(current)</span></Link> <Link className="nav-item nav-link" to={CelestialSettings.path + "products/"} >Products</Link> </div>
Using the <Link to=""> tag for linking between different pages.

Getting Test Data

Now that you have created the theme, it is time to add some data. One way of adding data is to create our own content. However, there is an easier (and better) way to add data to our WordPress site. This method imports placeholder data from an external source:

  • Head to https://codex.wordpress.org/Theme_Unit_Test and download the theme unit test data
  • Head over to Tools > Import > WordPress to install the WordPress importer.
  • After the WordPress importer is installed, click on Run Importer.
  • Click ‘Choose file’ in the importer
  • Select the downloaded file and import the WordPress Theme Unit Test Data

Now you have to select the theme-unit-test-data.xml file and all the placeholder content is now on your site.

When all the data is imported correctly. WooCommerce Integration

Now, we are ready to power our store using React. We will use the products.jsx and product.jsx files for this purpose, whose code is similar to posts.jsx and post.jsx respectively.

We will add three more variables to CelestialSettings under ‘woo’ (see A Global JavaScript Variable):

  1. URL
  2. consumer_key
  3. consumer_secret

The Consumer key and Consumer secret have to be generated from DashboardWooCommerceSettingsAPIKeys/Apps.

For the woo URL, you have to manually add it (since WooCommerce allows transfer only over SSL, add the URL with https, i.e. https://localhost/celestial/wp-json/wc/v2/).

Copy the Consumer key and Consumer secret and paste them in the appropriate places within functions.php. This will serve as the authentication for accessing WooCommerce via an API call.

Visit the WooCommerce REST API documentation for more information about its API. The products.jsx file has the code for populating the store with products. The products can be added by an admin from the dashboard. Just go to DashboardProductsAdd New and enter product details.

Add new product via the dashboard.

When you click on a certain product, you will be taken to the product.jsx page:

Individual product page rendered based on the product.jsx file

The code for the above page is similar to post.jsx:

renderProduct() { return ( <div className="card"> <div className="card-body"> <div className="col-sm-4"><img className="product-image" src={this.state.product.images ? this.state.product.images[0].src : null} alt={this.state.product.images ? this.state.product.images[0].alt : null } /></div> <div className="col-sm-8"> <h4 className="card-title">{this.state.product.name}</h4> <p className="card-text"><strike>${this.state.product.regular_price}</strike> <u>${this.state.product.sale_price}</u></p> <p className="card-text"><small className="text-muted">{this.state.product.stock_quantity} in stock</small></p> <p className="card-text">{jQuery(this.state.product.description).text()}</p> </div> </div> </div> ); }
Code for product.jsx file" alt="Code for product.jsx file


For the theme to work correctly, we have to set the following permalinks within DashboardSettingsPermalinks:

  1. Under Common SettingsCustom Structure: http://localhost/celestial/posts/%postname%/

  2. Under Product permalinksCustom base: /products/

If you don’t set the permalinks as above, the theme may not function as desired.

A WooCommerce Fix

When you navigate to localhost/celestial/products, chances are you will get a blank space where the products are supposed to be loaded. This happens because WooCommerce needs authenticated requests whereas our localhost is not https. To fix the issue:

  1. Visit https://localhost/celestial/wp-json/wc/v2/products. This will give us a warning:
WooCommerce requires authenticated requests and will show a warning if localhost is not https
  1. Click on ADVANCED > Proceed to localhost (unsafe).
  2. Now, if you go back to the products page, the items will be displayed correctly.

Note: If you are on Valet on a Mac, you have to run Valet Secure on your site to secure the local site with a TLS certificate. This is another way of fixing the problem.

What Is ScrollMagic?

ScrollMagic is a library that allows us to perform certain actions when scrolling through the page. To use ScrollMagic we will enqueue the ScrollMagic JavaScript library in functions.php. We are using ScrollMagic for two instances in this project:

  1. To lazy-load posts within the posts.jsx component: componentDidMount() { var that = this; window.onbeforeunload = function () { window.scrollTo(0, 0); } // init ScrollMagic Controller that.state.controller = new ScrollMagic.Controller(); // build scene var scene = new ScrollMagic.Scene({ triggerElement: "#colophon", triggerHook: "onEnter" }) .addTo(that.state.controller) .on("enter", function (e) { if (that.state.getPosts && that.getMorePosts !== null) { that.getMorePosts(); } }); }
    Lazy-loading posts within the posts.jsx component
  2. To show a fade-in animation for posts appearing by scrolling through posts and products in the posts.jsx and products.jsx components respectively: componentDidUpdate() { var FadeInController = new ScrollMagic.Controller(); jQuery('.posts-container .col-md-4.card-outer').each(function () { // build a scene var FadeInScene = new ScrollMagic.Scene({ triggerElement: this.children[0], reverse: false, triggerHook: 1 }) .setClassToggle(this, 'fade-in') .addTo(FadeInController); }); }
    Applying a fade-in animation for posts which appear as scrolling occurs

We are now ready to view our theme from the front-end. Navigate to localhost/celestial on your web browser and see your theme in action.

And pat yourself on the back, because you have now successfully created the theme!

Other WordPress Themes With JavaScript Libraries

If you found this helpful, you can take a look at other awesome decoupled WordPress themes built using modern JavaScript libraries/frameworks:

  • Foxhound: The first decoupled theme to make it to the WordPress themes repository. Written by Kelly Dwan, this theme uses React, Redux and React Router.
  • Anadama React: Another theme by the same author, but using Flux instead of Redux, and Page instead of React Router.
  • Wallace: Written by Kirby, this theme uses Angular with the WordPress REST API.
  • Picard: Written by Automattic themselves to showcase the capability of the WordPress REST API.
  • React Verse: A React and Redux theme I wrote based on Foxhound.
Next Steps

The main sections I wanted to show you are now done. You can continue with building the project for further knowledge. These are some recommendations that you could pursue:

  1. A full-fledged store with the WooCommerce plugin, including checkout and shopping cart;
  2. A page each for archive, tag, taxonomy, and so on;
  3. State management with Redux or Flux.

Good luck, and happy coding!

(mc, ra, al, il)
Categories: Around The Web

A Comprehensive Guide To User Testing

Smashing Magazine - Wed, 03/07/2018 - 6:30am

(This is a sponsored article.) With a prototype of your design built, it’s important to start testing it to see if the assumptions you have made are correct. In this article, the seventh in my ongoing series exploring the user experience design process, I’ll explore the importance of user testing.

As I explored in my earlier article on research, where I explored the research landscape, there are many different types of research methods you can use, and there are a variety of different user tests you can run, including:

  • Usability Testing
  • Eye Tracking
  • Interviews and Focus Groups

In this article, I’ll be focusing on usability testing, where we evaluate the design decisions we have made against a representative set of users to test if our assumptions are correct.

With your prototype in hand, you might be all set to go with the final build of your website or application, but it’s important to pause and undertake some testing at this stage in the process. Getting some typical users in front of your design is critical so you can get a feel for what works and — equally — what doesn’t.

Similarly, when you’ve undertaken your final build, you might be forgiven for thinking that everything is finished. In fact, once you’ve launched, you’re only at the start of the journey. Ideally, you’ll undertake some further testing and, with your findings from that testing in hand, revisit your design and address any issues you might have discovered.

Remember: Design is an iterative process. There are always improvements to be made, informed by your testing.

In short: User testing should be happening at every point in the process as an integral part of an iterative design process. With that thought in mind, it’s important to establish a structured framework for user testing throughout the design process:

  • Before you undertake your initial design, perhaps using paper prototypes;
  • During the digital prototyping phase, using lo-fi and hi-fi clickable prototypes; and
  • At the end of the process, helping you to refine what you’ve built.

You might not have the budget to run fully-fledged usability tests, and for many projects that’s understandable, but that doesn’t mean you shouldn’t at the very least test your designs informally. Guerilla testing — ad-hoc testing with passers-by, run in an informal manner — is better than no testing.

The bottom line? Any testing you can do — no matter how informal — will serve you well. With the importance of usability testing underlined, let’s explore the why and when of testing, stress the importance of good preparation, and dive into running usability tests effectively.

Usability Testing: Why And When?

First things first, to run an effective usability test you don’t need formal ‘laboratory conditions.’ It’s far better to run some usability testing using what you have to hand than to run no usability testing at all.

You might be wondering, why bother? Usability testing takes time and — when you’re under pressure and with deadlines looming — you might be tempted to forego it. Don’t make this mistake: it will cost you more in the long run. Usability testing will, of course, require a degree of investment in time and money, but it will more than pay off.

Your goal is to gather as much feedback as you possibly can as early as you possibly can. This helps you to identify any design issues before you get to the expensive part of the process when you reach the final build. It’s too late — and too expensive — to leave user testing until after you’ve built your product. At that point in the process, changes are incredibly costly.

As I noted in my previous article on wireframing and prototyping, the earlier you identify problems, the less expensive they are to fix. Running a usability test will, amongst other things, help you to:

  • Identify if users are able to complete specific tasks successfully;
  • Establish how efficiently users can undertake predetermined tasks; and
  • Pinpoint changes to the design that might need to be made to address any shortcomings to improve performance.

In addition to these objective findings:

  • Does the product work effectively?
  • Running a usability test helps you to make subjective findings: Do users enjoy using the product?

These objective and subjective findings provide valuable feedback that help you to shape and improve your design.

With the benefits of running usability tests clearly established, let’s explore when in the design process you should run your tests. There are a number of points in the design process that you might run usability testing. You might be testing an existing product or a competitors’; this will depend on your project and its circumstances. You might, for example, be:

  • Testing an existing product you’ve created that you plan to redesign;
  • Testing competitors’ products so that you can learn from them if you’re moving into a space where there is already an existing, competing product; or
  • Testing a product you’re currently in the process of working on.

It’s important to allow for more than one series of usability tests. Ideally, you’ll be testing at multiple points in the process: at a midway point with some clickable prototypes; and once your final build is done and you have a fully built product.

Ideally, usability testing should happen throughout the design process. At the prototyping stage, it can help identify issues that would be expensive to fix later in the process. At the final build stage it can equally identify issues that might have been hard to replicate at the prototyping stage.

Each of these points in the process offers you something different to learn and helps you address shortcomings in your assumptions before your final build. The rule of thumb is: The earlier you run a usability test, the better.

Like anything, the better prepared you are, the more effectively your usability testing is likely to be, so let’s explore the importance of preparation.

Preparation Is Key

To run a usability test effectively will take between 30–60 minutes per participant. Of course, depending upon the complexity of what you’re building, this length of time will vary, but in my experience, an hour is about the maximum time I’d recommend.

The longer a usability test runs, the more tiring it is for the participant, leading to diminishing returns. As such, preparation is key. It’s important to establish upfront exactly what you hope to learn from the test and, equally importantly establish who you’ll be testing. To do this, it helps to:

  • Develop a solid test plan that outlines your usability test, ensuring that when you test across different individuals, you’re doing so in a consistent manner; and
  • Establish clear criteria for recruiting participants, so that you’re testing users who are appropriate to what you’re designing.

The preparation you put in place before the test will pay off in terms of efficiency and improved findings. Bear in mind that running a test will require a number of individuals:

  • The test participants;
  • A facilitator, guiding the test and ensuring everything runs smoothly; and
  • Some observers and note takers.

Time is money, and with so many people involved in the process, it’s important to ensure that the time you’re investing pays off. To remain focused it’s important to establish a plan for your usability test and prepare a script that ensures everything is consistent.

Establishing A Plan

Your plan serves to establish the following: what you plan to test; how you plan to run the test; how you will measure what you’ll capture and what metrics you’ll use; the number of users you’ll test; and what scenarios you’ll use as the backbone for the test.

Think about the scenarios that you are trying to test. What is your website or application’s purpose? What’s its primary goal? It’s important to establish a plan around this, including the following elements.

Where and when?

Where and when will you be running the test? Unless you’re working for a large organization, it’s unlikely you’ll have a dedicated space for usability testing. That’s fine; the important thing is you’re running some usability tests!

Try to find a quiet space that you can welcome your test participants and make them feel at ease. Also allow for space for a facilitator, who will run the test, and some observers, who will take notes. It helps to group your usability tests so that you can cross-reference your findings across users while everything’s fresh in your mind.


Establishing the scope of your usability test ensures your goals are realistic. You might be designing a website or a product that is large in scope, but when defining the scope for your usability testing, be realistic. You only have so much time, so focus on the important aspects that you need to address.

Specify what you’ll be testing, for example, your website or application’s navigation system, or its e-commerce flow. This will keep you focused and ensure you don’t drift off-topic.

If you’re dealing with a complex piece of design with multiple moving parts, you might want to run a series of different usability tests; each focused on a particular aspect.


Different usability tests will require different timings, but as a rule of thumb, it helps to allocate around 30–60 minutes per participant. Moving beyond an hour can result in participants getting tired, which — in my experience — leads to a drop-off in the quality of feedback.

When scheduling your usability tests ensure you allow for sufficient time between tests. It’s important to allow for discussion amongst the team immediately following a test, while the test is fresh in everyone’s mind. Equally, a buffer between tests is helpful in case a test runs over or a participant arrives late.


Again, the equipment you use doesn’t have to be overly complicated. It’s important to be able to capture the session in some form, ideally using video. Above all, it helps to be able to capture what users’ say and their expressions. As I’ll explore in a moment, you can tell a lot about a design by looking at a test participant’s reactions. Their facial expressions and body language will often tell you as much, if not more, than what they actually say.

We’re fortunate now to have low-cost screen recording software at our disposal. Screen recording tools like Screenflow are very cost effective and, using your computer’s built-in webcam, enabling you to capture not only what the user is doing on screen, but also the look on their face.

With your plan clearly established, it’s time to develop a script.

Creating A Script

Building on your plan, your script will help you to facilitate the usability test clearly and consistently. Creating a script helps you to:

  • Focus your mind on what exactly you’re testing, so that your usability test doesn’t drift and remains focused;
  • Ensure consistency across multiple test participants;
  • Talk about different user scenarios;
  • Clearly, articulate the different goals you’re testing; and
  • Help you put your users’ minds at ease.

It helps to break the script down into a couple of sections: a section that acts as a preamble, and a section that covers the main body of the test itself.

Your preamble is designed to settle the user before the test starts. In it, you cover what you’re testing and why you’re testing it. Above all, it’s important to ensure that you put the users’ mind at rest, assuring them that you are not testing them, you are testing the product.

Participants are human beings, and it’s only natural that they will apologize if and when things go wrong. You need to put their minds at ease and assure them that nothing they do or say is wrong.

Your script is designed to focus your test on the scenarios you have established in your plan. When establishing your scenarios, bear in mind that — depending upon the complexity of the website or product you’re building — you will only have a limited amount of time to test everything, so be realistic.

It helps to establish a story around which you build your series of tasks. For example, if you’re testing a travel-related website or application, consider:

  • How many people are making the journey?
  • When are they traveling and do they have flexibility with their dates?
  • What kind of budget do they have?

Of course, every scenario will be different. The bottom line is to spend some time defining what exactly you plan to test so that your testing is focused on testing the right thing and returns valuable results. If you’ve spent some time building user personas for your project, you might like to build scenarios around these.

In short, try and create as realistic a scenario as possible. As websites and applications become increasingly complex, it helps to test user journeys through your interface. This also helps to tie your testing back to the user stories you identified earlier in the design process, which I explored in my previous article on high-level UX design.

Recruiting Participants

With your plan ready and your script written you need to identify some participants to undertake your usability test. As with your plan and your script, preparation is key; it’s important to put some thought into identifying the right participants.

There’s no point setting aside a considerable amount of time to undertake usability testing and then testing random strangers. Spend some time to identify and find the right kind of people for your test.

First things first, it’s important to test more than one person. Everyone is different, and everyone draws from different experience, so ensure that you’re testing a variety of different people, so your results aren’t skewed by too small a sample size. What you’re designing will affect who you choose, different websites and products attract different audiences, so plan accordingly.

Usability.gov has an excellent Usability Test Screener that is a great starting point for building your own screener.

It helps to establish a profile and create a screener to help you identify candidates so that you recruit participants who accurately represent your potential users. It’s important that your participants share the characteristics of your typical customers; again, user personas will be helpful in identifying these characteristics.

Imagine you’re building a mobile application for a new digital challenger bank aimed at a younger demographic, your screener might include the following:

  • What gender do you identify as?
  • What age are you?
  • Which bracket does your income fall into?
  • Are you a saver or a spender?
  • Does your current bank have an app and do you use it?

It’s important to ensure that your questions are inclusive. Equally, exercise some discretion when asking sensitive personal questions. For example, when asking for income — if it is relevant to your test — provide brackets for income so that you respect your applicants’ confidentiality.

If you’re looking for a good starting point, Usability.gov have an excellent example of a Usability Test Screener for website testing. This is a useful starting point and will give you some ideas.

With a plan created, your script in hand and some participants lined up it’s time to run your test, so let’s explore that now.

Running The Test

Before you begin your usability testing it’s important to get everything organized and in place. It helps to have a record of each usability test you run, so that you can look back through it later and undertake some analysis. This might be through screen-recording software alone, or it might include recording a video of the test.

If you’re recording the test, it’s important to ask your participants for permission. Equally, this gives you an opportunity to explain why you’re recording the session and what you’ll be using the recordings for.

Remember, your goal is to put your participants’ minds at ease, and explaining what’s what helps to do this before you start the test.

Before The Test

Rather than diving straight into your testing scenarios, it helps to run through a short preamble, explaining what it exactly as you’re trying to achieve through your testing. This ensures you give your participant a clear idea of what you’re expecting of them, helps to take the pressure off them, and eases them into the test.

It’s helpful to outline who’s in the room and why, explaining that while you’re running the test, the others present will be recording their observations. It also helps to give the participant an idea of how long the test will last and, broadly, what you’ll be covering.

Before you begin, it’s important to inform the participant that you’re not testing them, you’re testing the software and that there are no wrong answers. The participant needs to know that your intention is to watch them using what you’ve built and, to ensure the conditions are as real as possible, you won’t be offering them advice.

This last point is critical, especially of you’re running a usability test on something you’ve designed. It’s important not to interrupt the test participant’s flow by offering them guidance and advice. You won’t be there to do this in the ‘real world,’ so resist the urge to offer advice from the sidelines.

Even if what you’re testing was designed by you, it’s important that you don’t tell your test participant. (A little white lie won’t hurt!) You’re dealing with humans, and if your test participants know that they’re giving you feedback on something you designed, they are likely — only naturally — to hold back on their criticisms. No one likes to hurt someone’s feelings, and it’s important you get an honest opinion, so don’t skew the participants’ answers by telling them they are judging something you designed.

Ask your test participants to try, if possible, to verbalize what they think will happen as they work their way through the scenarios. This helps you to get a feel for what they’re thinking. It also helps your observers and notetakers if you ask your participant to run through the tasks you’ve set them a little more slowly than they might if this wasn’t a test.

As a facilitator — from time to time and being careful not to interrupt the flow — you might like to ask the participant what they think might happen next before they undertake a particular action. This helps you measure your user’s mental model of what’s happening to see if it aligns with the mental model of the design.

Lastly, stress that if something goes wrong during the test, it’s the software’s fault, not the user’s. It’s important that your test participants don’t think something is ‘their fault’ when it’s an issue with your design.

During The Test

With your preamble done, it’s time to get the test underway. As you walk your participants through your script setting them various tasks, it’s important to resist the urge to lead them. Your goal is to see how they react to the tasks, helping them out with advice defeats that purpose.

This can be incredibly difficult, especially if you’re testing something you’ve designed, but you need to do your absolute best not to try and help out. It can be frustrating watching someone struggle to understand how to use something you’ve built — that you think makes absolute sense — but remember, what you’re discovering is helping you.

Equally, if you’re responsible for the design try not to let your facial expressions give the game away. This takes practice (especially for me!), but it’s important that you try and remain as neutral as possible.

When running your usability test, you’re learning on two levels, by:

  1. Listening to what people say; and
  2. Observing what people do.

Listening and observing are both important and will provide you with different insights. Listening will give you subjective feedback on your design: “I like this because…,” “I like this kind of feature…,” “I prefer it when….” While subjective, and dependent upon your test participants’ opinions, this kind of feedback is useful, because it can surface ways of doing things that you may not have considered.

Observing how your test participants use your website or application is a great way of seeing what works and what doesn’t. Again, you’re testing your assumptions: you think you’ve designed something that’s perfect, but sometimes your test tells you otherwise.

It’s important to be aware of the distinction between listening to what people say and observing what they do. You are dealing with human beings when you’re running a test and humans like to consider others’ opinions.

You might run into situations where someone you’re testing is complimentary about a particular design or feature (“I like this.”), yet their actions tell a different story (you watch them desperately trying to complete a task you’ve set them!).

Don’t underestimate the power of observation. As Yogi Berra famously put it:

"You can observe a lot just by watching."

This is why, when you run a test it’s important to have more than one person involved. You’ll need a facilitator to take the participant through the usability test, using the script as a guide; and one or more observers to capture the participants’ reactions.

In Closing

Testing — and particularly usability testing — is a critical part of the design process. Run them well; an effective usability test will save you money in the long run. Running usability tests, ideally at multiple points in the design process, helps to keep your users positioned front and center, which — as user experience designers — is our goal.

Your tests don’t need to be run in fully fledged laboratory conditions; the important thing is you’re undertaking testing. If you’re on a shoestring budget, some guerilla testing is better than no testing; just ensure that you’re testing on the right kind of person.

Remember: Who you test is important. There’s no point putting in the hard work to build a detailed usability testing plan if you’re testing the wrong people.

Lastly, as I noted in my article on user research it’s important to spend some time analyzing your research findings. When you’ve completed a number of usability tests with different participants, sit down with your team, cross-reference everything, and look for patterns of behavior.

Identifying pain points — points in the process where your participants ran into difficulty — means you can fix those pain points. Equally, identifying moments of delight can help you identify what you might want to do more of. Taken together, this feedback — once you’ve applied it — will lead to a better experience all-round.

Suggested Reading

There are many great publications, offline and online, that will help you on your adventure. I’ve included a few below to start you on your journey.

This article is part of the UX design series sponsored by Adobe. Adobe XD is made for a fast and fluid UX design process, as it lets you go from idea to prototype faster. Design, prototype, and share — all in one app. You can check out more inspiring projects created with Adobe XD on Behance, and also sign up for the Adobe experience design newsletter to stay updated and informed on the latest trends and insights for UX/UI design.

(ra, il)
Categories: Around The Web

We Write CSS Like We Did in the 90s, and Yes, It’s Silly

Design Blog - Tue, 03/06/2018 - 9:47am

As web developers, we marvel at technology. We enjoy the many tools that help with our work: multipurpose editors, frameworks, libraries, polyfills and shims, content management systems, preprocessors, build and deployment tools, development consoles, production monitors—the list goes on.

Our delight in these tools is so strong that no one questions whether a small website actually requires any of them. Tool obesity is the new WYSIWYG—the web developers who can’t do without their frameworks and preprocessors are no better than our peers from the 1990s who couldn’t do without FrontPage or Dreamweaver. It is true that these tools have improved our lives as developers in many ways. At the same time, they have perhaps also prevented us from improving our basic skills.

I want to talk about one of those skills: the craft of writing CSS. Not of using CSS preprocessors or postprocessors, but of writing CSS itself. Why? Because CSS is second in importance only to HTML in web development, and because no one needs processors to build a site or app.

Most of all, I want to talk about this because when it comes to writing CSS, it often seems that we have learned nothing since the 1990s. We still write CSS the natural way, with no advances in sorting declarations or selectors and no improvements in writing DRY CSS.

Instead, many developers argue fiercely about each of these topics. Others simply dig in their heels and refuse to change. And a third cohort protests even the discussion of these topics.

I don’t care that developers do this. But I do care about our craft. And I care that we, as a profession, are ignoring simple ways to improve our work.

Let’s talk about this more after the code break.

Here’s unsorted, unoptimized CSS from Amazon in 2003.

.serif { font-family: times, serif; font-size: small; } .sans { font-family: verdana, arial, helvetica, sans-serif; font-size: small; } .small { font-family: verdana, arial, helvetica, sans-serif; font-size: x-small; } .h1 { font-family: verdana, arial, helvetica, sans-serif; color: #CC6600; font-size: small; } .h3color { font-family: verdana, arial, helvetica, sans-serif; color: #CC6600; font-size: x-small; } .tiny { font-family: verdana, arial, helvetica, sans-serif; font-size: xx-small; } .listprice { font-family: arial, verdana, sans-serif; text-decoration: line-through; font-size: x-small; } .price { font-family: verdana, arial, helvetica, sans-serif; color: #990000; font-size: x-small; } .attention { background-color: #FFFFD5; }

And here’s CSS from contemporary Amazon:

.a-box { display: block; border-radius: 4px; border: 1px #ddd solid; background-color: #fff; } .a-box .a-box-inner { border-radius: 4px; position: relative; padding: 14px 18px; } .a-box-thumbnail { display: inline-block; } .a-box-thumbnail .a-box-inner { padding: 0 !important; } .a-box-thumbnail .a-box-inner img { border-radius: 4px; } .a-box-title { overflow: hidden; } .a-box-title .a-box-inner { overflow: hidden; padding: 12px 18px 11px; background: #f0f0f0; }

Just as in 2003, the CSS is unsorted and unoptimized. Did we learn anything over the past 15 years? Is this really the best CSS we can write?

Let’s look at three areas where I believe we can easily improve the way we do our work: declaration sorting, selector sorting, and declaration repetition.

Declaration sorting

The 90s web developer, if he or she wrote CSS, wrote CSS as it occurred to them. Without sense or order—with no direction whatsoever. The same was true of last decade’s developer. The same is true of today’s developer, whether novice or expert.

.foo { font: arial, sans-serif; background: #abc; margin: 1em; text-align: center; letter-spacing: 1px; -x-yaddayadda: yes; }

The only difference between now and then: today’s expert developer uses eight variables, because “that’s how you do it” (even with one-pagers) and because at some point in their life they may need them. In twenty-something years of web development we have somehow not managed to make our CSS consistent and easier to work on by establishing the (or even a) common sense standard to sort declarations.

(If this sounds harsh, it’s because it’s true. Developers condemn selectors, shorthands, !important, and other useful aspects of CSS rather than concede that they don’t even know how to sort their declarations.)

In reality, the issue is dead simple: Declarations should be sorted alphabetically. Period.


For one, sorting makes collaborating easier.

Untrained developers can do it. Non-English speakers (such as this author) can do it. I wouldn’t be surprised to learn that even houseplants can do it.

For another reason, alphabetical sorting can be automated. What’s that? Yes, one can use or write little scripts (such as CSS Declaration Sorter) to sort declarations.

Given the ease of sorting, and its benefits, the current state of affairs borders on the ridiculous, making it tempting to ignore our peers who don’t sort declarations, and to ban from our lives those who argue that it’s easier—or even logical—not to sort alphabetically but instead to sort based on 1) box dimensions, 2) colors, 3) grid- or flexbox-iness, 4) mood, 5) what they ate for breakfast, or some equally random basis.

With this issue settled (if somewhat provocatively), on to our second problem from the 90s.

Selector sorting

The situation concerning selectors is quite similar. Almost since 1994, developers have written selectors and rules as they occurred to them. Perhaps they’ve moved them around (“Oh, that belongs with the nav”). Perhaps they’ve refactored their style sheets (“Oh, strange that site styles appear amidst notification styles”). But standardizing the order—no.

Let’s take a step back and assume that order does matter, not just for aesthetics as one might think, but for collaboration. As an example, think of the letters below as selectors. Which list would be easiest to work with?

c, b · a · a, b · c, d · d, c, a · e · a c · b · a, b · a · c, d · a, c, d · a · e a, b · a, c, d · a · b, c · c, d · e

The fact that one selector (a) was a duplicate that only got discovered and merged in the last row perhaps gives away my preference. But then, if you wanted to add d, e to the list, wouldn’t the order of the third row make placing the new selector easier than placing it in either of the first two rows?

This example gets at the two issues caused by not sorting selectors:

  • No one knows where to add new selectors, creating a black hole in the workflow.
  • There’s a higher chance of both selector repetition and duplication of rules with the same selectors.

Both problems get compounded in larger projects and larger teams. Both problems have haunted us since the 90s. Both problems get fixed by standardizing—through coding guidelines—how selectors should be ordered.

The answer in this case is not as trivial as sorting alphabetically (although we could play with the idea—the cognitive ease of alphabetical selector sorting may make it worth trying). But we can take a path similar to how the HTML spec roughly groups elements, so that we first define sections, and then grouping elements, text elements, etc. (That’s also the approach of at least one draft, the author’s.)

The point is that ideal selector sorting doesn’t just occur naturally and automatically. We can benefit from putting more thought into this problem.

Declaration repetition

Our third hangover from the 90s is that there is and has always been an insane amount of repetition in our style sheets. According to one analysis of more than 200 websites, a median of 66% of all declarations are redundant, and the repetition rate goes as high as 92%—meaning that, in this study at least, the typical website uses each declaration at least three times and some up to ten times.

As shown by a list of some sample sites I compiled, declaration repetition has indeed been bad from the start and has even increased slightly over the years.

Yes, there are reasons for repetition: notably for different target media (we may repeat ourselves for screen, print, or different viewport sizes) and, occasionally, for the cascade. That is why a repetition rate of 10–20% seems to be acceptable. But the degree of repetition we observe right now is not acceptable—it’s an unoptimized mess that goes mostly unnoticed.

What’s the solution here? One possibility is to use declarations just once. We’ve seen with a sample optimization of Yandex’s large-scale site that this can lead to slightly more unwieldy style sheets, but we also know that in many other cases it does make them smaller and more compact.

This approach of using declarations just once has at least three benefits:

  • It reduces repetition to a more acceptable amount.
  • It reduces the pseudo need for variables.
  • Excluding outliers like Yandex, it reduces file size and payload (10–20% according to my own experience—we looked at the effects years ago at Google).

No matter what practice we as a field come up with—whether to use declarations just once or follow a different path—the current level of “natural repetition” we face on sample websites is too high. We shouldn’t need to remind ourselves not to repeat ourselves if we repeat code up to nine times, and it’s getting outright pathetic—again excuse the strong language—if then we’re also the ones to scream for constants and variables and other features only because we’ve never stopped to question this 90s-style coding.

The unnatural, more modern way of writing CSS

Targeting these three areas would help us move to a more modern way of writing style sheets, one that has a straightforward but powerful way to sort declarations, includes a plan for ordering selectors, and minimizes declaration repetition.

In this article, we’ve outlined some options for us to adhere to this more modern way:

  • Sort declarations alphabetically.
  • Use an existing order system or standardize and follow a new selector order system.
  • Try to use declarations just once.
  • Get assistance through tools.

And yet there’s still great potential to improve in all of these areas. The potential, then, is what we should close with. While I’ve emphasized our “no changes since the 90s” way of writing CSS, and stressed the need for robust practices, we need more proposals, studies, and conversations around what practices are most beneficial. Beneficial in terms of writing better, more consistent CSS, but also in terms of balancing our sense of craft (our mastery of our profession) with a high degree of efficiency (automating when it’s appropriate). Striving to achieve this balance will help ensure that developers twenty years from now won’t have to write rants about hangovers from the 2010s.

Categories: Around The Web

A Comprehensive Website Planning Guide (Part 3)

Smashing Magazine - Tue, 03/06/2018 - 7:40am

In Part 2, I covered the details of evaluating a plan, choosing web professionals, and determining your website structure. The question of why planning for the web is just as important as planning for anything else associated with your business was covered in Part 1, so head on back to read that part first in case you missed it. In today's final part of this guide, I'll start with a few of the most common approaches in any initial design.

Initial Design: Three Common Approaches

There are, of course, others, including hybrids which combine elements of each, and every design team and every project is different, but there are core approaches to creating a web design.

1. Classic Photoshop mockup approach

Commonly created in Adobe Photoshop (the industry standard) or other design software such as Sketch, the initial design will consist of a visually accurate image ("mockup") of the home page and at least one internal page.

Your business' visual branding elements should be applied here. If you have well-defined graphics in addition to your logo, they will dictate the design of the site. However, if your brand lacks detail, the designer will do their best to create work that accurately reflects the business, working with your existing graphics as a jumping off point.

Following is a short list of key points for successful mockups. We'll assume the designer is working in Photoshop, however, these guidelines also apply to other design programs.

  • Start with a pre-made grid with pre-drawn, pixel-accurate guides. Some designers create their own, while others may adhere to a pre-set grid system. Whatever the case, it's important to have a clean template to start. Make your canvas wider than the width you're designing to, so you can add notes on one side and get a feel for what the site feels like when floating in a wide browser window.
  • Add the color palette and basic branding elements (i.e., fonts) in the margins of the canvas so you'll have it for reference when viewing on screen or in print.
  • Draw everything to exact pixels, and draw clear guides and/or slices around design elements. This becomes critical when the front end developer later creates the HTML from the mockup, however, your design will only be pixel-accurate when displayed on a ‘big screen' device.
  • Organize all design elements with a logical folder/subfolder structure, and label each item clearly.
  • If the designer will be handing off their files to an HTML developer, this is especially important. Name your folders and layers for their content so there's no confusion later. For example: "Sidebar — events header" is clear, "Layer14 Copy Copy Copy" is not.

Getting the process just right ain't an easy task. That's why we've set up 'this-is-how-I-work'-sessions — with smart cookies sharing what works really well for them. A part of the Smashing Membership, of course.

Explore features →
  • Make clear notes dictating fonts, alignment, repeating background elements, gradients and anything that will need to be implemented with CSS techniques. In Photoshop, the sticky note feature is good for this. If unclear, ask the person who will be converting your design into a working page.
  • If using a common style for headers, navigation, or other design elements that appear throughout the site, consider making separate Photoshop documents for them. Some designers find it easier to "chunk it down", especially in big projects.
  • Use realistic content. Designers often use greeking ("lorem ipsum") to fill space, which is ok for body copy. However, for headlines, titles, events, etc., try to use realistic copy. Consider the two following headlines. Layout considerations are different for each:
    • "Widgets, Inc. Wins Green Manufacturing Award"
    • "Widgets, Inc. Employees Win Landmark Court Case Affirming Employee Right To Petition For College Tuition Reimbursement When Training Is Relevant To Work Role"
Large preview The problem with this method

When you design pixel-perfect mockups, you can be assured that the website's appearance will be very close on the desktop web — but that's it. The minute you switch to a different device, it will change. So at the very least, you'll want to either convey to the business how the design will change as it is viewed on smaller screens (tablet, smartphone) by showing a site with similar layout, or design additional mockups at common screen sizes. As you can imagine, this is a lot of additional design work, and if you change an element on the desktop-focused mockup, you'll have to change it on the others too. Here's the smartphone view.

Large preview 2. Design in the browser

With the rise of responsive web design, some designers are moving away from the Photoshop mockup approach, instead using responsive frameworks like Bootstrap or Foundation, or tools like Froont or Typecast. These tools allow very rapid, iterative design that allows you to see how the site will look on different devices.

You may still use Photoshop or other graphic design tools to create stylized elements to place within the design, but the bulk of the design will happen outside these tools. There is no good way to show the business "exactly what it will look like" so for designers used to making pixel-perfect mockups for the desktop web, in-browser design may not be the best approach. For many, this method also represents a major change to their process and can take a while to get the hang of. Most see this as a necessary evolution, since a Photoshop mockup can only represent one of the many "frames" in which your site's content is displayed, and the world of web is moving rapidly toward designing for multiple platforms from the get go.

When it's time to write the HTML, CSS and Javascript that will make up the site, you can either stick with the framework you used initially to create your design iterations, adapt its code, or write your own from scratch, using your framework designs as a guide.

3.Element collage (also know as style tile, style collage)

With this approach, the designer will assemble a range of elements that make up a website including header, navigation, icons, sample photography, illustrations, forms, interactive elements, and anything else deemed necessary to get a good sense of the site's look and feel. Additionally, depending on the design tool, these elements may be laid out in such a way as to show how their appearance will change in unison with the screen size. This is typically combined with some kind of graphic mockup of at least the home page and few internal pages. (It can be hard for businesses to visualize how pages in a site will look based solely on an element collage.)

Note: These sample images are not to scale — our Photoshop version of the element collage is one long page, 1500X4500 pixels, so we can't fit it here in one piece.

Large preview

For designers (and businesses) long used to the Photoshop mockup method, this is also a new frontier, and requires a change in perspective. With a style prototype, you're not trying to layout a page exactly, but rather, to show the key parts of the site and get feedback on the general look and feel. Because a responsive site must change in appearance radically as the screen size changes, this method is much more about about the parts of a site and getting a feel for the direction the design is heading. You're not showing the site as a whole, let alone making a pixel-perfect representation of exactly how each and every page will look.

This can save a lot of time, but again, if the business isn't comfortable (or trusting) enough to let the designer make structural decisions later on down the line, this method may be a tough sell. That said, it really can create a flexible environment in which to rapidly create web designs for myriad platforms.

While the principles of graphic design are timeless, the approaches used for website design will change and evolve over time. I highly recommend you watch Design Deliverables for a Post-Comp era to discover the value of this approach.

When using this the element collage method, the business must accept there is no exact, precise, final draft of a given page, only layout guidelines to agree upon. The very nature of responsive sites is to adapt their content to the capabilities of each device, so the businessmust not expect to approve set-in-stone layouts prior to the development phase. With an approved style prototype, a designer may want to return to wireframes or working prototype to work out all the layouts your project requires. Then when it comes to build the site, you will assemble the elements of your collage into the visual structure of each unique layout.

There is much discussion and debate in the design community about the best tools, methods, and process for creating web designs. Designers tend to feel very strongly about which is the "best" method, and while that's understandable, it's important to use the most suitable process for the project and the business. It's smart for designers to get comfortable working with an array of methods and systems, and broaden their horizons when a project allows.

Author's note
I was very hesitant to include some of the following content, because it highlights serious tensions in the business-designer relationship. While it may seem overly critical of business owners, I believe it is of great value to businesses because so much time and money is at risk in a website project.
In the interest of diplomacy and preserving client relationships, designers probably won't voice these frustrations to business owners, but the following issues can and do derail projects. Design approval and revisions

Regardless of which design method was chosen for the project, when the design is complete, the results are are shared with the business for approval, and there is often a (hopefully short) revision process. The revision process involves the the designer and key stakeholders going back and forth a few times, trying different edits to the design until the design is approved.

Design by committee: don't do it.

A common (and completely avoidable) problem at this stage is the consideration of too many opinions, simply having too many cooks in the digital kitchen.

To help ensure a smooth process, the business must assign one person as the point of contact for the design team. That person is responsible both for communicating with the designer and for making final decisions about design direction.

Certainly, it is important to solicit feedback on design, and project stakeholders have valuable critique to offer, helping guide the design process so that the end result accurately represents their business.

Additionally, in some instances, review by legal and/or technical staff is needed. However, having the entire company offer input, and lending equal weight to all feedback leads quickly to nobody being satisfied. The best possible way to ensure a muddy, unfocused design is to give everybody input and then to run around making all the changes proposed.

Generally speaking, in small businesses or organizations, having any more than five people provide design feedback is a recipe for gridlock. The fewer the better, five is the maximum. These five (or fewer) people will solicit feedback from their subordinates or department colleagues, but that input should be compiled by each stakeholder and presented as a unified, single opinion. In other words, don't invite fifteen people to a design review meeting. Weed out all the back and forth before you go to the designer with input. It's also very important to distinguish between objective design concerns ("does this color scheme really suit our bakery?") versus personal design preferences ("I love the color blue — let's use a lot more blue").

Design is not an arbitrary pursuit. There is good design and bad. There are rules to be followed, best practices to be adhered to, and as long as planning has been done properly, design decisions are almost never really a matter of taste. That is, there's a good reason the designer used that exact blue, in that exact spot, or that font at that size. All of those little choices communicate things to the user. They may feel insignificant, but in reality, all these choices the designer makes are important. They can drastically affect the way the site functions and how it is received. Unfortunately, many businesses fail to understand that just because they like it doesn't mean everybody else will, and doing what's best for conveying the soul of the business is what the designer is hired to do. Opinion shouldn't enter into it unless absolutely necessary.

When egos rule

Any experienced designer has dealt with decision makers who have the dreadful combination of strong ego and poor design sensibility. In the worst case, designers will be asked to use a logo the CEO developed in Microsoft PowerPoint, or colors and fonts totally unsuited to the business' image. This, unfortunately, comes with the territory of being a designer. Sometimes it's possible to diffuse this by placing the offending artwork in a grid alongside professionally designed material from competitors or similar companies in the industry — Pinterest is a good tool for this.

If a competitive review was part of your needs assessment, you may want to refer to their brands for reference. The hope is that the business can see how awful their version looks next to the competition and rethink their commitment to the bad idea. Ultimately, however, decision makers can and do ruin projects by insisting, contrary to all available evidence, that their design sense should take priority over established design principles.

Help! They won't budge!

Readers of an earlier version of this book asked for ways to deal with the ego problem. I wish I had a clever or useful answer for you. Suffice to say this is a problem with people, not technology. Make your best case for the value of good design, fight your best fight, then be prepared to let it rest.

Design tension: designer vs. the business

Designers often deal with tension between their informed concepts of design and business' uninformed design critiques. This is best illustrated by the "bad idea" conundrum. The business will request a design feature that's either ugly, unworkable, or just a bad idea. (This is so common that there are many websites which chronicle clueless businesses and the headaches that result in this dynamic1.) The designer will respond somewhere on the continuum between "that's horrible, we won't do it" and "well, if that's what you prefer...". This response is dependent on a variety of ever-shifting factors, including:

1http://clientsfromhell.net, http://theoatmeal.com/comics/design_hell

  • When designer hopes to get paid.
  • How emotionally invested designer is in the project.
  • How much time the designer has invested in the design phase, and how much delay will result from implementing the bad idea.
  • How high the stakes are — how much damage the bad idea will do to the site as a whole.
  • Personality, businesses' willingness to take constructive counsel about their ideas.

Every project is different. When designers deal with businesses who continually request features that are ill- advised, at some point they may write off the project altogether. At a certain point, it's just too exhausting to continually explain why centered, bold paragraphs in red, WRITING IN ALL UPPERCASE, crazy Flash animations or poor quality photography make an ineffective website2. The designer's attitude rapidly shifts from "let's make something really great that we're proud of" to "let's just get it done so we never have to look at this again."

2Other mood killers include autoplay videos and fonts most often used in children's books.

While considering the above, also realize that there's another side to this coin. People problems can also crop up on the designer end of the spectrum. Some designers' skills may not be up to par, they may refuse to listen to valid criticism of their work, or may not value the informed input of the business. A good way to avoid this is by getting good references from designers' past clients.

Consider the content

Think about expansion. For example, you may have a news section. To start, you have six news items. That's fine. You'll make a main news page with summaries and link the summaries to a detail page. But what happens when you have ten, twenty, or fifty news pieces? Now there are other considerations. Do you want to archive old news? Create pagination? Only show the most recent ten items? This should be considered in the design process. Plan around content as much as possible in the design process, and think ahead wherever you can — plan for the content you will have, not the content you have right now.

Web style guide

A style guide is where proper planning shines. A style guide will consist of all the design, layout, interactive (i.e. JavaScript) and type elements used throughout the site in one location. This is usually done in HTML, so if you're a designer who doesn't code, you'll need to create a mockup for your style guide and deliver it to your front end developer along with the rest of your designs. If you've used the element collage method covered earlier, you may not need to repeat yourself in a separate web style guide. If you're using the classic Photoshop mockup method, you will need one. Elements of a style guide include, but are not limited to:

  • Navigation styles
  • <h1> through <h5>, also known as header tags
  • Paragraphs
  • Lists
  • Block quotes
  • Italics, bold face, underlines
  • Links, including active, hover and visited states, that is, the appearance of links, including when hovered over with the mouse
  • Icons
  • Use of images and image style
  • Use of background images or "watermarks"
  • Forms.

This article from Canva explores 10 web style guides for well known companies. You can also use an online tool like Frontify.

Using A Pattern Library

For websites of larger scope, you might expand the web style concept to the more robust pattern library, which explains how various elements appear and how they are handled. Sample code for these elements is usually part of the library. It's not just a picture of it, but the thing itself. For example, what does a form look like, what happens visually when it has errors, what is the process for comment submission, etc.

Approved mockups, element collage and wireframes, along with the style guide, are used as the building blocks for the next steps of development.

HTML/CSS Creation

Using the designs and style guide, an HTML/CSS expert (the front end Coder) will create HTML templates which accurately represent the design as approved. In some cases, templates will appear identical to mockups, however, where Photoshop was used for mockups, subtle differences are to be expected.

Your front end coder might also need additional guidelines and assets related to designs, like color palettes, specific images, icons, and — if not explicitly noted already — design rules like margins and padding. Make sure you know what all the deliverables will be before you start sending files. If designs and style guide were created with plenty of attention to detail, there should be few questions or guesswork at this stage; work should be humming along.

Interactive Element Creation

Interactive elements may be as simple as a drop-down menu, or as elaborate as a pie chart creator. These elements are typically developed with JavaScript, often using a script library like jQuery. At the most general level, this consists of assembling (and writing) a set of instructions that interact with pages on your website. There may be interactivity between site and server to consider too. You might be connecting APIs3, making something like a booking or calendar system etc., or using widgets from third party services.

3 Essentially, a bridge between one or more systems. For example, Facebook offers an API that allows you to pull in posts from your wall to an unrelated website.

 CMS Integration

At long last your brilliant design has been converted to code and is ready to be integrated in a Content Management System (CMS). It's well on its way to becoming a website!

The individual or team tasked with doing the "stitching" of the code to the CMS will provide you with a login for the control panel of the CMS, which allows you to enter the content, including text, photos, videos, and documents. Most writers prefer to cut and paste from Microsoft Word.

Depending on the specifics of the CMS selected, you may be able to do this without issue, retaining simple formatting like bold, italics, and lists. However, the CMS may strip out this formatting when you cut and paste, requiring you to add it back. While sometimes tedious, this insures your content remains neat and orderly, which makes it more easily indexed by search engines, more easily printed, cited and converted to other formats.

Although in reality this process is quite involved, I've left out the details because the exact process will be unique to each CMS, and doing this well relies on the expertise of the Web/CMS Developer.

Training And Documentation

While modern CMS can be very user friendly, it's important to coordinate training for the people responsible for entering content. When possible, on-site training is best, with web conference a second choice. Training works best in very small groups — 5 people or less. Additionally, having people actually follow the steps needed to complete a task on their own, (rather than just having them watch the trainer and try to remember how to do it when they're on their own) is much more effective.

Training should be supported by documentation, which can take many forms:

  • Step-by-step video ("screencast")
  • PDFs with screenshots
  • Printed guidelines
  • Contextual help (built in to the CMS).

Sometimes documentation combines some or all of the above. Whatever you choose, keep in mind the skill level of the people entering content. Many people who work in offices are competent at Microsoft Word and email, but can be challenged by basic but necessary "design" tasks like sizing and cropping images. Also remember that the business probably isn't working with the same set of professional design tools that the designer is, so make allowances for the business' technological concerns as well.

It's a good idea to save the writing of documentation until as close to the end of the project as possible. Remember that if you change something in the CMS mid-project, you may have to update documentation to match. This can be very time-consuming (and confusing too), so try to coordinate the parts of your project so the documentation is written once the content entry process has been finalized.

Puttin' it all together...

At this point, having followed the preceding steps, you should now be sitting on a pretty solid website. Regardless the size of your project, now is a good time to:

Review your content once again, checking it against the points listed under writing for the web above.

Ask a third party to proofread all your content. This is not the task of the designer or the original writer. It's best to bring in someone with a fresh perspective. Don't proofread your own work.


When you feel your website is almost ready for the public to see, it's time for beta testing — a process of going through all aspects of the site, making sure everything appears and functions as intended. Consider this checklist, at minimum:

  • Does the site look as intended in all targeted web browsers? Web browsers include the usual Internet Explorer, Firefox, Safari and Chrome, as well as those that come with common mobile devices. If you've been viewing the site on a desktop browser up until now, you may find unexpected glitches when you switch to a tablet or smartphone. This is the time to thoroughly review your site on a variety of devices before it can be considered ready for public consumption. Remember — your site's audience will use a wide range of devices to view your site, and it needs to work acceptably well on all of them. You don't have to physically test your site on every possible phone or tablet, but you should try it on a handful of common devices. Don't go out and buy a five-year-old Blackberry for testing purposes.
    "Emulation" websites and services like Spoon.net will generate previews of your site on just about every browser or device known to humankind, giving you a good idea of how it will look in most scenarios.
  • Interactive features work smoothly.
  • Contact or other forms work predictably and generate the correct response to the user and recipient of the information submitted.
  • Error messages are helpful and human-friendly.
  • Internal and external links function.
  • Images are sized properly.
  • All placeholder content has been replaced by the final copy/images, etc.
  • Internal and external links, including email links, work properly.
  • Integrations with third party software, such as email service providers, are working.

At this point its very wise to enlist someone who has had no involvement in the process to date, and ask them to methodically go through each page and feature in the site, noting any errors or glitches they find. Don't use someone who's been staring at the site for months. Problems to look out for could include typos, bad links, image sizing, failures on specific mobile devices, or content that's missing or incomplete. (Make sure to tell your tester that the design of the site is set in stone at this point, so they're not wasting time looking at non-content considerations.)

Pre-launch coordination

When you approach launch time, you'll need to coordinate with your company's other marketing efforts. If you're active on social media, write and proofread the announcement of your new/redesigned site, and set a schedule to post the announcement. Prepare to update your outgoing voicemail message and coordinate print advertising — everything needed to support the launch of the site.

Redirecting traffic from the "old" site

If your new website is replacing a previous version, it will probably have a different URL structure, and you need to map the old structure to the new. There are two reasons to do this. First, search engines have indexed the URLs of your old site. This indexing has a lot of value to people searching for what your company offers. When you launch a new site with different URLs, the old ones will break and users will get a "page not found" message (404 Error). You want to retain your hard-earned place in search engines. Second, site visitors may have bookmarked pages within your old site and want to return to them. If those pages' URLs change, you need to insure visitors still receive content that is relevant to their needs, instead of a page that no longer exists.

For example, your old site may have:

  • http://oursite.com/company/history.html
  • http://oursite.com/staff/california.html

while the new site has:

  • http://oursite.com/company-history
  • http://oursite.com/staff/california

The differences are subtle, but computers are very literal things — to the browser, the difference between "history.html" and "company-history.html" might as well be the distance between Mars and Earth. You need to go through the structure of the old site and make note of every page that has equivalent information in the new site and their URLs. If your old site has a lot of pages, you can use a tool like Powermapper to help automate the process. Sometimes old and new URLs will line up pretty well, like those above. Other times an old URL may not have an equivalent in the new site. This often happens if you've closed a division of your company, discontinued a project, or reorganized a department. Regardless of the reason, you'll still need exact URLs to work with for the next step. There are three ways to handle old URLs:

  • If they have an equivalent like the examples above, you can point the old URL to the new. To diverge in to the technical for a moment, this is done with a 301 Redirect, which tells search engines and users' web browsers that a URL has permanently changed. It looks like this: Redirect 301 /company/history.html http://oursite.com/company-history
  • If the links have no equivalent, you can send site visitors to a page which says "Sorry we can't find what you you're looking for. We've redesigned and reorganized our site, and some content has changed or moved." and provide a site map and search option.
  • You can also point all non-existent URLs right to the home page.

The larger the scale of your old site, the more work will be required to re-point old URLs. If you have analytics running on your old site, you may choose to re-point only the top 10 or 20 old URLs to new ones, and set a catch-all for all the rest, pointing them either to the "Sorry, we can't find what you're looking for…" page or the home page. Creating catch-all redirects, or those that match a specific URL pattern is a technical endeavor that we won't address here, but you can easily find information on .htaccess files (for Linux server) or web.config files (for NT server) at Stack Exchange or other resources.

Never launch on a Friday

It's never a good idea to launch a website, especially one on which many people depend, on a Friday or right before holidays. If something goes wrong, you may not have the resources to fix it when most of the office staff, vendors and other third parties who might be able to help have gone home for the weekend. Mondays are best for launching a new site, as that gives you the whole week to fix any unexpected problems that may arise, and plenty of support to help you do so.


Once you've thoroughly beta tested the site, it's time to launch. Specific steps vary by project, but generally this means either moving the site (files, database, configuration) from a development environment to a public one making it visible to the world, or simply updating server settings to allow visitors to yourcompany.com to see the new site.

Post-Launch Web statistics

Reviewing your website visitor statistics can give you vital insight in to how people are using your site. You'll need at least a month or two worth of data to make any determinations. Don't get too hung up on the pure numbers — all of them are approximate to one degree or another. Trends should be your main focus. Here are a few key points to consider:

  • Where are visitors coming from? Search engines, direct traffic (i.e., someone just typed your site's.
  • URL in to the browser), ads, links from other sites, etc.
  • Where do visitors live? Are they mostly local, regional, national, international?
  • What pages are the most popular?
  • How long are visitors staying on the site?
  • What is the bounce rate, that is how many users visit only one page on the site before leaving it entirely?

Google Analytics is among the most commonly used web statistics software and you will easily find answers to these questions in the high-level data it presents. Other web statistics software like KISSMetrics or Clicky should readily provide these answers as well.

Technical documentation

You'll also need detailed notes on how various parts of the site are implemented on the CMS. This is different from the documentation provided to the business. Much of your technical documentation will simply consist of the annotated elements discussed earlier in this document, including wireframes, style guide and Photoshop documents. Think about what information would be needed if you brought new people in to maintain the site, people who were not at all familiar with it. What do they require to pick up the project? They'll need:

  • Credentials for the CMS, web server, and other services connected to the site.
  • Written or video instructions on how to perform tasks in the CMS: adding news items, blog posts, swapping out photos — everything that someone can do to the site.
  • Recommended technical maintenance — how often do the CMS and other services require updating?
  • Notes on backups — what is being backed up, how often, and where is it backed up to?

Note: writing documentation of all kinds is one of a web professional's least favorite tasks, but it's very important. Don't slack on it. Think how terrible it would be to inherit a project without any technical documentation. Then use that dread as your inspiration! You don't want to leave anybody in a lurch down the line and doing this right will save time and frustration later on.


This is often overlooked by businesses and designers alike. Schedule regular backups of the site's files and database. Daily is ideal. Your hosting company may provide an automated way to do this, but if they don't, there are plenty of effective services and tools available to facilitate this process. That way, if your files or database get hacked, erased, corrupted or otherwise damaged, you can restore them with copies from the previous day.

Depending on the size of your site, frequency of updates and some technical matters that vary with each site, you may want to schedule more frequent backups. Ideally, your site will be backed up off-site, that is, in a different place than where it is hosted. Services like Amazon S3 or Rackspace Cloud are ideal for this purpose. The idea is that if your website gets irrevocably damaged, a recent copy is stored in a different physical location, allowing restoration of the site to the last undamaged version.

Maintenance plan

Your maintenance plan, which should have been budgeted for before you started, should clarify roles and responsibilities for every aspect of the site. For example, if two articles per week are to be posted, who is responsible for this, and who is that person's backup? If your site requires photos or graphics to be created regularly, make sure this work is assigned and understood by all involved. Determine who will check links, re-size images, write blog posts, etc. Write a simple maintenance plan and share it with everyone involved in the site's care and feeding. Remember, a good website isn't a one-time event, but rather an extensible communication tool that requires regular updates to remain valuable, relevant and compelling to site visitors.

Solicit visitor feedback

After it's been online for a while, a great way to improve the impact of your site is to solicit visitor feedback. There are a variety of ways to do this, from simple online surveys to on-site focus groups. Site visitors often have trouble articulating what they like and don't like about their experience. With this in mind, it's important to craft very clear and specific questions when soliciting feedback. And remember, if you're going to take a significant amount of visitors' time, offer something in return — a product discount, prize, or simply a handwritten note thanking them.


OK, one more time for posterity: A good website isn't a one-time event, but rather an extensible communications tool. Once you've built a great website, keep the momentum going. Devote resources to regular maintenance, and check in with your site visitors regularly to identify areas for improvement.

Recommended Reading
  • "Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability" by Steve Krug
    Helps readers understand the principles of intuitive navigation and information design.
  • "Content Strategy for Mobile" by Karen McGrane
    Making the case for a mobile strategy, publishing flexibly to multiple channels, and adapting your workflow to a world of emerging devices, platforms, screen sizes, and resolutions.
  • "Design Is A Job" by Mike Monteiro
    From contracts to selling design, from working with clients to working with each other, learn why navigating the business of design is just as important as the craft of it.
  • "Grow your SEO" by Candy Phelps
    A beginner's guide to SEO.
DEFINITIONS Term Definitions Adobe Flash A proprietary system for creating rich, interactive website features such as charts, graphs, animations and streaming video. The Flash player, that is, the browser add-on that allows users to via Flash content, is free. Flash authoring software is sold by Adobe. Beta testing The process of reviewing a website to ensure everything works as intended prior to launch. Content Management System (CMS) Software that provides website authoring, collaboration and administration tools designed to allow users with little knowledge of web programming languages or markup languages to create and manage the site's content with relative ease. Offers users the ability to manage documents and output for multiple author editing and participation. Popular CMS include WordPress, ExpressionEngine, Drupal, Joomla, Perch, Statamic, Craft, and hundreds more. Grid system A grid takes the available screen area and divides it up in to equal parts, for example, 10 columns of 96 pixels = 960 pixels. This makes layout and design easier. Many grid systems are available — use a search engine to see what's current. HTML Short for 'Hypertext Markup Language.' HTML is a tag-based language which defines the elements of content on a web page. For example, surrounding content in <p>...</p> tags creates a paragraph, while <strong>...</strong> creates bold text (adapted from Wikipedia). Javascript (JS) A programming language that runs inside a user's web browser, enhancing websites with a wide range of features such as mouseovers, slide shows, moving and fading elements, and more. Commonly implemented through a library like jQuery. CSS Short for 'Cascading Style Sheets.'' CSS is a set of instructions which define the layout and appearance of HTML elements. For example, CSS may specify that all paragraphs be 12 point Verdana, dark gray. Layout Deals with the arrangement of visual elements on a page. It generally involves organizational principles of composition to achieve specific communication objectives. Lorem Ipsum ("Greeking") Placeholder text used by web and graphic designers to fill space in mockups and incomplete web pages until real content is provided. May be as old as the sixteenth century. Meta tags Information about a web page (for example, title, description, author) that helps search engines and other resources understand the contents of that page. Responsive Web Design (RWD) A set of web design techniques that insure a site adjusts its presentation appropriately for different devices. Term originally coined by Ethan Marcotte. Search Engine Optimization (SEO) The process of affecting the visibility of a website in a search engine's results. URL Stands for Uniform Resource Locator, that is, a unique address on the web that contains specific content. For example, tastyfruit.com/citrus/oranges Wireframe A visual representation of the layout elements of a web page, intended to show page structure, element placement and sizing. (vf, ra, yk, il)
Categories: Around The Web

How To Prevent Common WordPress Theme Mistakes

Smashing Magazine - Mon, 03/05/2018 - 9:00am

If you’ve been thinking of creating free or premium WordPress themes, well, I hope I can help you avoid some of the mistakes I’ve made over the years. Even though I always strive for good clean code, there are pursuits that still somehow lead me into making mistakes. I hope that I can help you avoid them with the help of this article.

1. Don’t Gradually Reinvent The Wheel

Be careful when making things look nice — especially if you create a function that does almost exactly the same thing as another function just to wrap things nicely. The more prettifying code you add, the harder it gets to maintain. Keystrokes per minute isn’t the bottleneck of your performance as a developer when you spend most of your time thinking about code, not actually writing it.

I’ve made this mistake a lot thinking I was DRY-ing up the code.

For example, I made a function called get_portfolio_part($name, $slug). Can you guess what it did? Yes. It’s a wrapper to save me the ”hassle” of writing the extremely repetitive get_template_part(“portfolio/$name”, $slug);. This is what I call “gradual wheel reinvention”. It does almost exactly the same thing as the original while complicating the code base at the same time.

Don’t do it! You don’t need to save those few keystrokes. It’s going to be difficult figuring out the actual path after a year has passed, or when someone else looks at your code. Even if you could argue that it’s simple and obvious — it’s going to either involve parsing yet another function in one's head or pure guesswork to guess where that function is fetching files from.

On top of saving a few characters, I remember the perfectly valid argument for making a get_portfolio_part() function in my head — what if I decide to move the portfolio directory in the future? I’ll have to perform an “ugly search and replace.”

Can you guess how many times I have changed that directory name over the years? Zero. This brings us to mistake #2.

Getting the process just right ain't an easy task. That's why we've set up 'this-is-how-I-work'-sessions — with smart cookies sharing what works really well for them. A part of the Smashing Membership, of course.

Explore features → 2. Stop Predicting The Future

Humans are terrible at predicting the future. Yet, as developers, we try to do it all the time.

For example, imagine you’ve made an option to display social icons somewhere in your post. Let's set aside the discussion whether that’s plugin territory or not. Just imagine that this is what you’ve decided to do. So our hypothetical function would look something like this:

function has_social_icon($icon) { $icons = get_post_meta(get_the_ID(), 'post_social_icons', true); // do what has to be done with $icons return true; }

A very typical idea crosses my mind now: "*But what if I want to use this function outside the loop sometime in the future*?" Well, this led me to a refactor that looks like something like this:

function has_social_icon($icon, $post_id = 0) { if( ! $post_id ) { $post_id = get_the_ID(); } $icons = get_post_meta($post_id, 'post_social_icons', true); // do what has to be done with $icons return true; }

And *voilà*! You’ve now created absolutely unnecessary bloat in the name of a non-existent future. This is such a simple example how these things happen, but the more complicated a thing becomes, the easier it is for you to lure yourself down a futuristic rabbit hole.

Don’t do it! Refactor out of real needs, not hypothetical scenarios that may or may not occur.

3. Premature Optimization Is The Root Of All Evil

Have you ever heard that quote? I didn’t give it much thought until rather recently. It’s very difficult to reform old habits, so this is something that trips me up to this day. I still catch myself optimizing code that I should not be optimizing.

Have you ever done something this?

<?php $post_id = get_the_ID(); // look 'ma - I'm reusing ID, saving 1 function call! $thumb = get_the_post_thumbnail( $post_id, 'large'); // look 'ma - I'm saving another function call! Yay! ?> <div id="post-<?php echo $post_id ?>" <?php if( $thumb ): ?> <div class="thumbnail"> <?php echo $thumb ?> </div> <?php endif; ?> </div>

Assigning a value to a variable, because you’re using that value twice is going to save you exactly .000002ms (a completely made up and useless figure), and 0ms when that request is cached, which it will be most of the time when performance is of concern anyway.

Here is much simpler way to write the same thing the WordPress way:

<div id="post-<?php the_ID() ?>" <?php if( has_post_thumbnail() ): ?> <div class="thumbnail"> <?php the_post_thumbnail('large') ?> </div> <?php endif; ?> </div>

Yes, it involves two extra function calls, but the code performance benefit is negligible. That doesn't meant that you shouldn't optimize your code at all. Be intelligent about it. If you're saving database queries, or you're running expensive functions in a loop - of course you should keep your code optimized. But do it intelligently. Don't throw everything in a variable just to save a function call. Speaking of variables...

4. Avoid Variables In Template Files

When you stop trying to over-optimize, you should notice considerably fewer variables in your template files. I recommend that you take that idea a step further and try to avoid variables in template files in general. Not because you should avoid variables themselves, but because of what they’re a symptom of in template files — logic.

While some logic will always be necessary, you can improve the readability of your template files significantly by removing as much as you can.

Here is a simple example.

<?php $logo_url = false; $thumbnail_url = wp_get_attachment_image_src( get_theme_mod( 'hypthetical_theme_logo' ), 'full' ); if( $thumbnail_url ) { $logo_url = $thumbnail_url[0]; } ?> <?php if( $logo_url ): ?> <a href="<?php echo esc_url( home_url() ); ?>" title="<?php bloginfo( 'name' ); ?>" class="custom-logo"> <img src="<?php echo $logo_url; ?>" /> </a> <?php endif; ?>

All by itself, this may not look terrible, but when it’s somewhere inside your `header.php` file, it’s going to look quite messy, especially when wrapped in multiple divs with indentation.

On top of it not looking great, why should the template (or the person reading the code) be concerned of how the logo is retrieved? Template files just want to show content, not fetch and parse the content.

Instead of defining two variables, why not extract them away into functions? Then the code above can easily turn into this:

<?php if( hypotheme_has_logo() ): ?> <a href="<?php echo esc_url( home_url() ); ?>" title="<?php bloginfo( 'name' ); ?>" class="custom-logo"> <img src="<?php hypotheme_the_logo_url() ?>" /> </a> <?php endif; ?>

This is much, much easier to read and avoids any unnecessary clutter and in case someone wants to know where the logo comes from — they can inspect the function instead. Now the logic is separate from the presentation.

Here is another example:

<?php /** * page.php */ ?> <?php get_header(); ?> <?php $hypotheme_sidebar = hypotheme_get_option( 'hypotheme_sidebar' ); $hypotheme_sidebar_size = hypotheme_get_option( 'hypotheme_sidebar_size' ); ?> <?php while ( have_posts() ) : the_post(); ?> <div class="row two-columns"> <?php if ( $hypotheme_sidebar == 1 ): ?> <div class="main-column <?php if ( $hypotheme_sidebar_size == 0 ) { ?> col-md-6 <?php } else { ?> col-md-7 <?php } ?>"> <?php else: ?> <div class="main-column col-md-12"> <?php endif; ?> <div id="page-<?php the_ID(); ?>" <?php post_class( 'entry-page' ); ?>> <h1 class="entry-title"><?php the_title(); ?></h1> <div class="entry-content"><?php the_content(); ?></div> </div> <?php if ( comments_open() ) : ?> <?php comments_template(); ?> <?php endif; ?> </div> <?php if ( $hypotheme_sidebar == 1 ) { get_sidebar(); } ?> </div> <?php endwhile; ?> <?php get_footer(); ?>

Look at those variables. On their own they’re not really out of place — they’re doing what they should be doing.

However, this template probably isn’t the only template in this theme with a sidebar. That means that those variables are probably present in all template files where there is a sidebar.

Not only the logic is mixed with the presentation, but it is also repeated all over the template files ( page.php, single.php, index.php, etc. ). That’s a lot of repetition, a lot of code that can be removed easily:

<?php /** * page.php */ ?> <?php get_header(); ?> <?php while ( have_posts() ) : the_post(); ?> <div class="row two-columns"> <div class="main-column <?php echo hypotheme_container_width_class() ?>"> <div id="page-<?php the_ID(); ?>" <?php post_class( 'entry-page' ); ?>> <h1 class="entry-title"><?php the_title(); ?></h1> <div class="entry-content"><?php the_content(); ?></div> </div> <?php if ( comments_open() ) : ?> <?php comments_template(); ?> <?php endif; ?> </div> <?php get_sidebar(); ?> </div> <?php endwhile; ?> <?php get_footer(); ?>

This is way easier to read and understand. The reader doesn’t have to care about how you decide how wide is the container, yet if they’re interested — in most code editors you can quickly jump to that function and read all about it. Functions help make your code more readable and extendable if used in conjunction with either WordPress Hooks or the Pluggable Functions pattern.

Don’t be afraid to create multiple files where you can store all your necessary template functions, i.e. don’t dump everything inside functions.php. By default, _s theme includes /inc/template-tags.php file for that purpose. And if you find that the file becomes too large with all of the new template tags you’ve created, you can create more files as needed. It’s your theme after all!

5. Make Sure You’re Up To Date

WordPress is constantly evolving, just as everything else on the internet. Stay up to date with best practices, and question yourself every now and then, and also make sure you’re still using best practices.

For example, I’ve seen themes released on WordPress.org this year, that are still using wp_print_styles instead of wp_enqueue_scripts, even though wp_print_styles has been deprecated since WordPress version 3.3.

If you’re building WordPress themes for others to use, keep up to date with best practices, and check the codex every now and then to see whether the way you’re doing something is still the best way to do it.

6. Use Native WordPress Functions When You Can

It’s important to use native WordPress functions when possible so that others can tap into your theme, either from a plugin or a child theme.

When you’re up to date with the latest and greatest that WordPress has to offer, you might discover that the example “Mistake # 4” can be completely replaced with native WordPress functions since WordPress version 4.5 because WordPress now supports Custom Logo functionality natively.

<?php if( has_custom_logo() ): ?> <a href="<?php echo esc_url( home_url() ); ?>" title="<?php bloginfo( 'name' ); ?>" class="custom-logo"> <img src="<?php the_custom_logo() ?>" /> </a> <?php endif; ?>

Here is another example.

When designing a nice post-to-post navigation without really giving it too much thought I resorted to using get_next_post function and copy-pasted something like this in my theme:

<?php $next_post = get_next_post(); if (!get_next_post()): ?> <a href="<?php echo esc_url( get_permalink( $next_post->ID ) ); ?>"><?php echo esc_attr( $next_post->post_title ); ?></a> <?php endif; ?>

Sweet! The internet just wrote some code for me! This is exactly what I needed.

What’s wrong with this? Well, several things.

First of all, don’t access object properties directly when possible, unless you’re sure you have to. In this case, you can use get_the_title() function instead. This way you will properly retrieve the title, prepend “Private/Protected" and apply the_title filter.

// do this echo get_the_title( $next_post ) // instead of this: echo $next_post->post_title

And secondly, there is a WordPress function called next post link and you can replace everything above with just a simple function call:

<?php next_post_link() ?>

Again, some research and staying up to date can help clean up themes significantly.

7. Don’t Build Your Own Framework

When I write code, I want it to be DRY, with a clean interface, reusable, and performant. I think ultimately we all want that.

When all those ambitions are combined with a sprinkle over premature optimization, a dash of future prediction, ignoring a native WordPress function or two, and the desire to save on a few keystrokes, that's when "a framework for me by me" is born.

As the saying goes, "The road to hell is paved with good intentions." In my almost five years of theme development, I’ve built a “solid framework” for myself at least twice and refactored them countless times. Now, I wish I could strip it all away in one fell swoop. Don’t do it! Spare your future self!

I’m against building "a framework for my by me," not frameworks in general. There are well supported and maintained frameworks out there, like the Genesis theme or Sage by Roots. But they are not in the "a framework by me for me" format.

Here are a few problems and side effects of building a framework for yourself:

Maintainability Issues

The first problem is that building a “framework” is just adding an additional codebase to maintain. Especially if the framework lives in your /inc/me-framework directory, you will have to update all your themes using that framework when you release an update to it.

If you decide not to update your framework in each theme every time you update it, there is still trouble lurking around the corner.

As you grow as a developer, your framework will grow and change, too. Eventually leading to incompatibility with your old themes. What if you discover a critical bug in older framework versions? You’ll have to either rewrite parts of all themes you’ve made or make a very special bug-fixed fork. And again: more code to maintain.

Plugin Territory

If you find yourself adding “custom functionality” in the theme, you might want to create a WordPress plugin instead. Themes should make pretty layouts and style them. Theme files should be filled with configuration, attaching to hooks and using template tags that either plugins or WordPress core provide. If you feel the need for using PHP Classes, you’re probably venturing into the plugin territory.

Make a plugin instead; make it easily customizable and style it in your theme. Not only you will avoid making a framework, but you’ll also contribute to back to the open-source community!

Increased Complexity

When you build a framework for yourself you’re making your theme more complex and difficult to work with. When someone reads your theme code, they’ll have to learn your framework that’s most likely either poorly documented or undocumented at all.


I have come to realize that most of the mistakes I’ve made have been caused by either the desire to save time in the future (xkcd has a wonderful comic about that) or to improve the code itself in some way, either by following a best practice that I’ve read somewhere or making the code look nicer.

WordPress has its own coding and theming standards. While you can write PHP the way you want to in your template files, it’s best to actually stick to “the WordPress way,” even if it’s not necessarily “the best way.” Remember that “best” is relative to the audience. When in Rome, do as the Romans do.

So please, don’t repeat my mistakes. I truly hope that this article will help you create great WordPress themes!

(mc, ra, yk, il)
Categories: Around The Web

Beyond Tools: How Building A Design System Can Improve How You Work

Smashing Magazine - Fri, 03/02/2018 - 10:00am

When high potential projects fall apart, it’s often a failure of collaboration and alignment. The tools, the assumptions, the opportunity, and the intentions may line up, but if people don’t communicate or don’t have a clear map to help them move in the same direction, even the best projects falter.

Communication failures are human problems, so they’re messy and hard to solve. They involve feelings and a willingness to have uncomfortable conversations. Human problems are abstract — sometimes it’s hard to even define the issue — and progress may be hard to see and measure. Because of this ambiguity, people often look to tools to fix things. Tools for better collaboration, task management, and to enable people to talk to each other.

Design systems are one kind of tool that people look to in order to solve problems that are fundamentally about failures in collaboration and alignment. Often, when people talk about design systems, they’re really talking about style guides because that’s the most tangible part of the work. The style guide is like the tip of an iceberg. It rises majestically up out of the surface, and it’s easy to forget the larger stabilizing force beneath the surface of the water that keeps the whole thing afloat.

Image credit: Kyle Mortara

Among the most important and overlooked forces behind your style guide are the internal workings and culture on your team or with your client. In fact, a style guide is just a map of how a group of people approaches their work. It documents and operationalizes the internal process and culture that already exist. If you’re not careful, it can even reinforce bad habits and dysfunctional, siloed ways of working.

Is your pattern library up to date today? Alla Kholmatova has just finished a fully fledged book on Design Systems and how to get them right. With common traps, gotchas and the lessons she learned. Hardcover, eBook. Just sayin'.

Table of Contents →

Since Shopify launched the style guide for the Polaris design system last year, many of the questions I’ve been asked have been about how we were able to produce something that feels so integrated - where design, content strategy, and front-end development come together to form a holistic picture of how we build our product. These questions usually assume that we were battling to fill a gap between developers and designers, or that some kind of peace treaty must have been brokered between different disciplines to achieve the kind of unity reflected in Polaris.

This article will outline some of the ways Shopify structures its UX team and how we used the process of building our style guide to rethink and reinforce the integrated way we approach product development. Whether you work in-house on a team or as a freelancer with different clients, it includes practical advice to help you think about creating a system to enable harmonious, integrated, and fundamentally successful product development.

Design System vs. Style Guide

A style guide is the map of your design system. It’s the place where you can bring together and make explicit many of the elements related to how you approach UX.

It can help to think of design systems as made up of tangible and intangible assets. Most industries have some version of this concept. For example, in the investment world, tangible assets are things like “land, vehicles, equipment, machinery, furniture, inventory, stock, bonds and cash.” Intangible assets are defined as “nonphysical, such as patents, trademarks, franchises, goodwill, and copyrights.”

At Shopify, we think of our design system as being made up of tangible and intangible elements. For example:

Tangible elements Intangible elements Team members Opinions and assumptions about quality Defined roles and responsibilities Communication between individuals and teams Components in our product Aspirations about the future of our product UI Kit Skills graph Content and visual rules Alignment between teams Research and data UX culture

A large part of the early work of creating the Polaris style guide was to determine which of these elements we could and should make explicit in our map.

Define The Problem You’re Trying To Solve

The first step towards being intentional about your design system is being honest about where you are today. Whether you have a style guide or not, if you build products and have a UX team, you have a design system. It may be a dysfunctional system, but the fact that you have people working together to build something means that it exists. People you’re working with likely have all kinds of assumptions about how a product is designed and built — this is the scaffolding of your system.

Prior to building Polaris, Shopify had internal documents that defined some of our most common interface components and some of our content and design rules. We also had ways of working together, including rituals like regular critiques to help build alignment.

As the team, product, and even our user base grew, the informal system we were using became disjointed and, because no one team was responsible for it, hard to manage. We were also undertaking a redesign of our core product, and we knew that without a more intentional approach to our system, it would be very hard to coordinate all the different teams and changes that would need to click together. These were some of the problems that led us to revisiting and documenting our design system.

Building an intentional design system and the documentation to formalize it are a big investment. Before you start, ask yourself and stakeholders:

  • How does the system function today?
  • What would be gained or lost from more formal ownership and documentation of the system?
  • What are the key problems that a more intentional design system would solve?
Inventory Tangible And Intangible Elements

Creating an inventory of the tangible and intangible elements of your existing system will help you identify the biggest gaps in how your team is working. It will also point to existing processes and documentation to be clarified, streamlined, and refined.

Creating an inventory can be a great kick-off activity that will get you thinking through how people currently approach their work.

  • How does everyone know what to do?
  • What are the common assumptions people hold about how products are designed and built?
  • What resources and documentation already exists?
  • How do people know they’re aligned?
  • How are different disciplines currently collaborating?

We found that different teams had different ways of working and had created their own parallel documentation to define processes and opinions. For example, the product content strategy team and the team that writes and maintains the Help Center had both created artifacts related to content standards. In some cases, those documents were aligned, in other cases, they were in conflict. This pointed to a good opportunity to talk about the gaps and work together to define holistic content documentation. We might not have identified this gap without the important step of doing an inventory.

The design system that you build, and the documentation you create for it, will reflect and reinforce any assumptions and biases in how you work.

Take A Multidisciplinary Approach

A design system is inherently about being intentional about how you approaches creating, building, and maintaining the user experience of your product. Having clear documentation (like a style guide) to map out the different pieces of your system is a pretty critical way to operationalize this work. For most companies, the effort required to do this is larger than a side project. It’s not something that can be slapped together at a hackathon and then magically stays in sync. It requires some number of people to steward and maintain it. Depending on the size of your company and the complexity of your systems, this could mean one (if you’re a freelancer) or dozens of people. The important thing is that someone, or some group of people, is responsible and accountable for establishing and documenting the design system.

If you want to build holistic products that are easy to understand and use, the people thinking about your design system need to be equipped with a breadth of UX skills. For example, if you don’t include a content strategist on your team, or at least someone with deep experience and interest in how content works in the interface, it’s likely that the interfaces built on the scaffolding of your system won’t leverage the full power of language. If you don’t have a multidisciplinary UX team to lean on, it’s important for you to consider the different dimensions that make up a good user experience and represent them accordingly.

Our UX practice is comprised of four disciplines: design, front-end development, research, and content strategy. Since we’ve defined these are the UX perspectives we value most on our product teams, we’ve made sure they’re well represented on our systems team. When we defined the team that would work on Polaris back in January 2017, it was important to have representatives from each of these disciplines as contributors and as stakeholders.

If you approach UX from a holistic point of view, that multidisciplinarity will be reflected in your design system. If you work in silos or you de-prioritize or devalue certain parts of the user experience, that bias will also be reflected in the design systems you build and document.

Shopify’s multidisciplinary approach to product development comes across most clearly in how we document components in Polaris. We wanted people to have the functional building blocks to recreate components in code or to design with them in Sketch, but we also wanted everyone to understand the fundamental utility of each component — the purpose it solves — for Shopify merchants. It was also critical that people had access to the usability rules and content standard for each component, all in one place.

As I wrote in an article published shortly after the launch of the Polaris style guide,

“When people understand the logic behind design decisions, they’re positioned to build better experiences for merchants. Including this information was fundamental if we wanted our style guide to be a map of our design system and reflect the way we believe a product should be built at Shopify.” Image credit: Shopify

Our ability to build a design system and style guide that reinforces the multidisciplinary way we work (which is one of the core ways we build great user experiences) depended on assembling a core systems team that reflected our different UX disciplines. We also agreed on some ways of working to encourage deep, integrated collaboration between disciplines. This was important because we were a large team. If you’re working with a smaller team, some of this may happen organically out of necessity:

  • Encourage people to move between swim lanes. Designers and front-end developers are encouraged to write, content strategists are encouraged to design, but everyone is encouraged to code. Embrace the fact that UX roles overlap and intersect.
  • Hold cross-disciplinary sprints, critiques, and project planning sessions. Make it clear that everyone is accountable for the breadth of the user experience.
  • Appoint team leaders from different disciplines and give them shared authority.
  • Make everyone, including team leads, responsible for the “dirty work.” For the launch of Polaris, this meant that everyone on the team submitted diffs, reviewed pull requests for code changes, and edited content in markdown. No job was too small or inconsequential for anyone, regardless of discipline or job title.
Build Your Map

Creating the documentation for your design system can be labor intensive, but it’s easier once you’ve defined your purpose, created and analyzed the inventory of your system, and assembled a strong, multidisciplinary team. One of the most valuable outcomes of creating documentation is that writing is a great way to clarify what you think.

For Polaris, the bulk of our new documentation was about our components. Content strategists created a template that outlined the different content chunks the team believed were critical to creating useful documentation about each component. Then it was a shared responsibility across the team to write that documentation. The goal in sharing writing responsibilities wasn’t for everyone to generate perfect prose, but to have everyone on the team use language as a way to think through the utility, functionality, and UX best practices for each component.

One of the ways we encouraged collaboration was to use tools that were accessible to people from different disciplines and teams. We used a gigantic Google Document as a scrappy content management system as we were writing and editing our map. At its longest, this document was 180 pages of mainly text. Internally, Shopify defaults to open, so we gave everyone in the company access to our draft and encouraged people to add comments, make edits, and to contribute. Doing this was noisy at times, but the challenge of managing lots of input was far outweighed by the goodwill and buy-in it resulted in. Design systems are relevant to people outside of UX and giving a wide range of people the opportunity to give feedback was an important way of making sure our assumptions were challenged and rigorously tested.

In addition to using Google Docs to manage our content creation and editing process, we used markdown in GitHub for our style guide because it lowered the bar for contributions. This decision continues to be an important way the Polaris team is able to encourage people from across Shopify to edit and add to the style guide.

Your style guide helps make the system explicit and gets people moving in the same direction. The way that you go about creating this documentation and the decisions around what you choose to include or exclude will inform how people use it and whether they recognize it as relevant to them.

Last Thoughts

Building a design system and the documentation that defines it can be an opportunity to rethink how you approach UX, or it can be a vanity project that reinforces existing problems. This is true whether you’re working in-house at a large company, or trying to bring order to a product you’re designing for a client.

Launching the Polaris style guide was just the most visible outcome of a lot of deep thinking and work across multiple disciplines and many different teams. The long, hard work is what came before the launch, and what has continued behind the scenes since then — lots of people working together to iterate on how we build products and how we document what we’ve learned. This quiet, deep work is where the real value lives.

A style guide is simply a map. It can orient you and show you the way. But whether you get there, and who you bring along, are up to you.

(da, ra, hj, il)
Categories: Around The Web

A Comprehensive Guide To Wireframing And Prototyping

Smashing Magazine - Thu, 03/01/2018 - 12:45pm

(This is a sponsored article.) With the big picture established and your user interface considered, it’s time to start building some prototypes. My sixth article in this series of ten articles dives into the prototyping process.

As I’ve stressed before in the earlier articles in this series, the best design follows an iterative process:

  1. You undertake research, working with users to identify the underlying user requirements that need to be addressed.
  2. With this research in hand, you define the problem you’re trying to solve and establish a hypothesis.
  3. With the problem defined you build a prototype.
  4. Using this prototype you test your assumptions, measuring against your hypothesis.
  5. Finally, you return to stage one, refining your thinking and iterate through the process again, working your way closer to a finished solution.

At each loop throughout the process, the fidelity of your prototypes increases. The earlier in the process you can identify and fix problems, the easier and the less expensive it is. The further into a process you get, as the fidelity of what you’re building increases, the more expensive it becomes to make changes. This is where prototyping comes in.

As designers working today, we’re fortunate to have a wealth of prototyping tools at our disposal. Tools like Adobe XD, in particular, enable us to build immersive clickable prototypes at relatively low cost.

These tools allow us to undertake a great deal of our testing before we get to the expensive part of the process, building fully working products in the medium they will be delivered in.

With the big picture of user flows established and some thought given to building a design system that ensures consistency, it’s time to put together some interactive prototypes.

This article, the third in this series within a series, explores the benefits of wireframing and prototyping, before covering the process from paper prototyping to lo-fi wireframing to hi-fi prototyping with mockups.

The Benefits Of Prototyping

We are fortunate as designers to have a wealth of prototyping tools at our disposal at a wide range of fidelities. At one end of the spectrum, we have lo-fi paper prototypes, while at the other end of the spectrum we have hi-fi digital prototypes.

Digital prototypes allow us to build realistic, clickable proof of concepts that allow users and stakeholders to get a feel for what we’re building. These prototypes enable us to test our assumptions and move progressively towards finished solutions.

Building a clickable prototype using a tool like Adobe XD is considerably quicker than diving deep into HTML, CSS, and JS to build a website or diving into the complex build of a mobile application.

Clickable prototypes also allow us to test our designs with users and other stakeholders, bringing them into the design process in a meaningful way and allowing us to test: information architecture, layout and visual hierarchy, and interactive elements.

There are numerous other benefits of prototyping, including:

  • Saving time and money;
  • Getting everyone involved and bought into the design process;
  • Acting as a bridge between designers and developers.

Let’s dive a little deeper into these and make a case for prototyping — as a bridge between your original idea and your final build — as a core part of the design process.

Prototypes Save You Time and Money

The golden rule of prototyping — and developing any new idea — is to fail early and fail inexpensively. Prototyping enables misunderstandings to be identified and addressed as early in the design process as possible. The earlier in the process issues are addressed, the better, saving you time and money.

The deeper into a project you are, the more expensive it is to fix mistakes. Prototypes — whether lo-fi paper prototypes or digital hi-fi prototypes — are a cost-effective way of identifying changes that might need to be made before you embark upon a finished build, at which point changes become increasingly more expensive to implement.

Prototypes Help Get Everyone Involved In The Design Process

Even a modest project will typically encompass a number of different stakeholders. It’s important to engage with everyone involved in a project, bringing them on the journey from idea to finished product.

Prototypes are helpful for including the wide range of participants in a project: designers, developers, project managers, business analysts and everyday users. (This list — depending on the size and scope of the project — is potentially just the tip of the iceberg.)

Prototypes are a great way of getting everyone involved in the design process. They also keep the conversation going, so that designers don’t disappear for weeks on end building complicated solutions to problems that perhaps don’t exist.

Prototypes Act As A Bridge Between Designers And Developers

As our industry has become more and more complex, the idea of ‘unicorn designers’ — who have deep skills as both designers and developers — is one that’s thankfully being left behind. It is simply too complex now to be ‘a master of all trades.’ We are increasingly working in multi-disciplinary teams, drawing on the strengths of different specialists and in this context, prototypes act as the glue that holds everyone together.

When the design of a product or feature is finished, and it is being passed on to a more skilled developer to undertake the final build, a high fidelity, clickable prototype ensures that the developer has a clear understanding of what’s what.

This is particularly true when it comes to designing interactions. Rich, interactive prototypes are considerably more powerful — not to mention immersive — than a series of flat, visuals that lack interaction. They provide a very clear picture of not only how something looks, but also how it works.

So, with this in mind, let’s explore the process of building prototypes.

Paper Prototypes, Wireframes And Clickable Prototypes

With the benefits of prototyping defined, it’s time to dive deeper into the prototyping process. We can, of course, create product prototypes at a wide range of fidelities and using a wide range of tools. These include:

  • rapid, sketched paper prototypes;
  • lo-fi, monochromatic wireframes; and
  • high-fidelity, clickable mockups.

As we move through the spectrum of prototypes, we can provide a more comprehensive view of our design, including color palettes, typographic choices, and other aspects including interactions and animations. In short, prototyping takes place across a spectrum of fidelity, from low detail to high detail.

As we work our way up the levels of fidelity, we’ll eventually build prototypes in the medium they’ll be delivered in. For example, the final prototypes for a website will ideally be built using HTML, CSS, and JavaScript so that we can tailor them to the medium.

The prototyping process is a journey, transitioning through levels of fidelity. There are many different types of prototypes — low- medium- and high-fidelity — and these are suited to different points on the design journey.

Prototypes are involved at every stage of the design process: from the earliest iterations where you are often ‘thinking aloud’; via clickable prototypes where you start to test assumptions; to detailed prototypes where you begin to implement your design. (Large preview)

At the start of the journey it’s important to focus on low-fidelity approaches that are low cost and fast to implement. Paper is the perfect prototyping tool at this stage in the process. Once you’ve undertaken some initial testing with your paper prototypes, it’s time to move onto something at a higher level of fidelity.

With some feedback gathered, it helps to move to the next level of fidelity, using tools like Adobe XD to create clickable lo-fi prototypes with wireframes. These help your users and stakeholders get a much better picture of how everything works.

Again, with testing done it’s time to move on to high-fidelity prototypes. At this point in the process, we’re increasing fidelity, moving from wireframes to mockups. Creating clickable hi-fi prototypes with mockups provides users and stakeholders with a very clear picture of the end result.

Finally, we move towards the end medium for prototyping, for example using HTML, CSS, and JavaScript for a website. Building a native prototype ensures that what you are creating is as close as possible to the finished product.

Of course, every project is different and — at times — you might need to approach your prototyping in a different order. When building a complex web-based SaaS application, for example, you might need to start prototyping in HTML earlier in the process in order to implement and test web technologies. As always, the approach you choose will depend on the project in hand.

For this article, I’m exploring paper prototyping, lo-fi prototyping with wireframes, and hi-fi prototyping with mockups. If you’re looking for an in-depth and exhaustive — in a good way! — book that covers prototyping in detail, I’d recommend Ben Coleman and Dan Goodwin’s book, "Designing UX: Prototyping"." It has an excellent in-depth chapter covering HTML prototyping.

The Power Of Paper

Paper is an incredibly powerful tool for prototyping. As a very low-cost prototyping medium, it frees you up, reducing the ‘weight of expectation.’ The beauty of paper is that it’s also collaborative, allowing you to design as a team, collectively. As Khoi Vinh’s Design Tools Survey shows, paper is embraced by designers the world over with 64% of designers using paper as an integral part of their process.

Like anything, paper prototyping is a skill that gets better with practice and some time spent sketching interfaces will pay off. I recently attended a full day workshop on sketching interfaces with Eva-Lotta Lamm, and I left with lots of ideas to enhance my paper prototyping approach.

One simple technique that improved my sketches dramatically was being set the task to draw an interface (Twitter, YouTube, Kickstarter, and so on) in as short a time as possible, just a minute or two. Running through this process repeatedly forced you to focus and speeded up your sketching considerably.

The more you draw, the more you improve your thinking and communication skills. You don’t need to be in a workshop to do this, however. Simply set aside some time and practice, and your paper prototyping skills will improve immeasurably. Just as an athlete warms up before a race, so too, we can warm up our mental muscles — before embarking on a paper prototyping session — in a similar manner.

Khoi Vinh’s Design Tools Survey underlines the importance of paper as a design tool, with 64% of respondents reporting that they use paper as their primary tool for brainstorming and ideation. Paper’s usefulness also extends to sketching interfaces, acting as a bridge between the ideas phase and the layout phase. (Large preview)

In workshops I run — whether it’s for students or professionals — I’ll always kick off with paper. It’s the perfect tool for generating and realizing ideas. We can think through paper and understanding that is incredibly liberating.

Paper is considerably faster than working on a computer. By working at an inherently lower level of fidelity, it forces you to think through the process, defining flows and mapping out interfaces. Lastly, a paper prototyping kit is incredibly inexpensive to build and is within reach of anyone regardless of budget. You could start with the following:

When paper prototyping, I find it helps to have pens available in a range of thicknesses. Sharpies force you to think in low fidelity, because of their thick nibs. Muji Gel Pens, on the other hand, allow you to think in a higher fidelity because they’re thinner. The Tombow ABT N75 Dual Brush Pen in Cool Grey 3 is fantastic for creating shadows and giving your drawings a ‘lift.’ (If you buy one pen, buy the Tombow, it’s fantastic.)

With your paper prototypes developed, it’s time to move to the computer and create some lo-fi wireframes, which can be stitched together to create more immersive prototypes for the screen.

Lo-fi, Low Stress Wireframes

With the broad brushstrokes established at a low fidelity using paper prototypes, it’s time to start transitioning towards a slightly higher level of fidelity using wireframes. At this stage in the prototyping process, we’re moving from paper to screen and incrementally increasing the fidelity.

A wireframe is essentially a ‘skeleton’ for your design. As a lower fidelity design deliverable — which is focused on structure, as opposed to look and feel — wireframes help you to focus on functionality and not get lost in detail. Wireframes distill the interface down to simple, monochromatic shapes and are helpful for communicating high-level structure.

Wireframes offer a number of benefits:

  • With the ‘visual grammar’ or ‘look and feel’ stripped out, they are faster to create, enabling you to focus on functionality.
  • As lo-fi deliverables they can be rapidly updated during user testing.
  • With their stripped-down design they put less pressure on users and stakeholders, allowing them to speak freely about design decisions without fear that they are criticising a ‘finished’ design.
  • They are less ‘precious,’ allowing designers to take on board feedback without feeling too attached to them.
  • Their unfinished look takes the pressure off; no one expects a wireframe will be in a fit state to ship the next day.

As I noted in my previous article, Adobe XD provides a number of pre-built UI Kits that save you from re-drawing commonly used user interface elements. These UI Kits provide you with a wealth of different elements you’re likely to need when building out a design, including those covering:

  • Sign Up
  • Activity Feeds
  • Checkout Screens
  • News Feeds
  • Articles and Posts.

UI Kits can be used to transform a paper prototype into a lo-fi, clickable prototype relatively quickly and they’re a huge time saver. Even better, if you’re using Adobe XD, they’re free.

Adobe XD’s UI Kits are the perfect starting point for putting together wireframes. With a wide range of different interface elements to draw from, they can act as a bridge between paper and digital prototypes. (Large preview)

With their focus on information architecture, wireframes enable you to quickly map the journey through content. Wireframes are also useful for helping to establish the scope of a project, enabling you to identify all the different screens you might need to design.

You don’t need to wait until you have high-fidelity mockups to start to build interactive, clickable prototypes. Tools like Adobe XD enable you to create lo-fi clickable prototypes, and these can be incredibly useful to help move your thinking on and test your assumptions.

By providing users and other stakeholders with a ‘functioning’ prototype that enables them to click through a series of screens, lo-fi prototypes are extremely useful for driving design conversations, enabling you to edge your design forward through discussion.

With a lo-fi, clickable prototype developed and tested it’s time to create a more fully realized clickable mockup, helping you to paint a picture of what the finished product will look like in your stakeholders’ minds.

Hi-fi, Clickable Prototypes

Once you’ve used your lo-fi clickable prototypes to iron out any issues, it’s time to build a higher fidelity prototype to provide a more realistic experience.

At this point in the journey you’re fusing your functional wireframes with the elements you created when you designed your element collages. This results in a high-fidelity, clickable prototype that is more powerful and engaging for everyone involved.

This is the final stage of the prototyping process before you start to build prototypes using the medium you’re designing for, for example, HTML, CSS and JavaScript, if you’re building a website or a language like Swift, if you’re building an app for a mobile context.

Tools like Adobe XD — which has been created by designers for designers – reimagine how user experience designers take their ideas from paper prototype to wireframe to interactive prototype. By allowing you to take separate screens and link them together using ‘hotlinks’ they enable you to build standalone clickable mockups.

These rich visual mockups provide a number of benefits:

  • By allowing you to publish prototypes on the web and providing a link for stakeholders to view or comment on your prototypes, they allow you to gather feedback from everyone involved in the project.
  • They can be viewed remotely, so you can talk a client through a prototype without having to be in the same room as them.
  • They can be used to share specifications with developers, enabling them to inspect your designs for colors, typographic styles, and various measurements.

Tools like Adobe XD also allow you to gather feedback directly within your prototype, enabling everyone involved in the process to leave comments. This is useful not just for the feedback it allows, but for the documentation it provides of the design process.

It’s easy to build comprehensive clickable prototypes with tools like Adobe XD. By drawing ‘hotspots’ (clickable areas of the interface) and then linking these hotspots to other pages, it’s easy to build immersive clickable prototypes. (Large preview)

High-fidelity prototypes are useful for bringing a design to life, helping everyone to get a feel for both the visual design and the interaction design. By including real content in your prototype, your users can experience how a website or an application functions and flows and provide helpful feedback.

Prototypes at this level of fidelity — rather than in the finished medium — are also considerably quicker to build, helping you to:

  • Validate your assumptions, testing your ideas;
  • Communicate your thinking, enabling others to provide feedback; and
  • Pitch ideas, when you’re proposing a new feature, for example.

As our industry has evolved, so too has its tools. As designers, we’re fortunate to have easy to use prototyping tools like Adobe XD at our disposal now. Access to these tools enables us to create, update and maintain prototypes in a way that just a few years ago would have been impossible to imagine.

Collaboration And Feedback

As I’ve noted in this article, and in the previous articles in this series, design is an iterative process that includes multiple stakeholders. The more you can keep the lines of communication open throughout that process the better.

By embracing an iterative approach towards your prototyping you can draw on the wisdom of everyone involved in the process. To create truly memorable user experiences, it’s critical to ensure that users are involved in the design process at every step of the journey.

In the past — before the advent of tools like Adobe XD and other tools that allow you to publish prototypes to the web — there was an inherent delay at every step of the process, as you brought various stakeholders in to the studio, or visited them on site.

The web has changed that, allowing you to maintain the flow of information throughout a project, streamlining the process considerably. With shareable prototypes that allow for users to leave comments you cannot only gather feedback, but you can also pinpoint clear, trackable design documentation.

Thanks to the use of commenting tools, it’s easy to see who said what about a design and when, allowing you to collaborate with others and respond to feedback easily. Design is at heart about people and communication, and commenting tools ease this communication.

The ability to have everything available in one package — from design through to commenting — has considerably eased the design process. The result is a workflow that is not only faster, but one that encompasses everyone involved in a project.

In Closing

Tools like Adobe XD now occupy a central place in the user experience designers’ toolbox. By acting as a bridge between the ideas captured at the paper prototyping stage and the finished build, they have transformed how we work as user experience designers.

As we work our way through the design process, it’s important to embrace the right tool for the job at hand. Different tools have different strengths and lend themselves to different tasks.

When you’re mapping out ideas at an early phase in the design process, paper is the perfect tool. It is both cheap and efficient and — because of this — it takes the pressure off you. Paper is also perfect for collaboration, allowing multiple designers to prototype collectively.

Wireframes are perfect when you’re focused on testing functionality and getting your high-level structure in place. Stitching wireframes together to create lo-fi prototypes enables you to map out user flows without getting lost in the details.

Finally, high-fidelity prototypes created using more detailed mockups allow your stakeholders to get a feel for how a design looks and feels. At this point in the prototyping process, the details matter: color palettes, typographic choices, and other aspects including interactions and animations.

Regardless of the end outcome — be it desktop or mobile, web or native — a considered prototyping process, one that is iterative in nature, will deliver the required outcomes, ensuring that what’s designed meets our users’ needs. Pick the right tool for the job, and you’ll be all set to go.

Suggested Reading

There are many great publications, both offline and online, that will help you on your adventure. I’ve included a few below to start you on your journey.

If you’re looking for a comprehensive overview of the prototyping process, Ben Coleman and Dan Goodwin’s book, "Designing UX: Prototyping is excellent. As they put it, “A prototype is worth a thousand words,” and their book takes you through every step of the prototyping process, from low- to high-fidelity. I’d strongly recommend it.

If your budget will stretch to some training, I’d highly recommend Eva-Lotta Lamm’s "Sketching Interfaces" workshop, it’s worth every penny. Lamm is also working on a book that explores sketching interfaces in depth, which I will certainly be buying when it’s published. You might like to keep an eye Lamm’s Twitter and Instagram accounts to be notified the moment it’s published.

If you’re interested in a complementary perspective on wireframing and prototyping, Nick Babich’s lengthy article for the Adobe Blog, "Everything You Need To Know About Wireframes And Prototypes" is comprehensive reading, providing lots of useful insight.

Lastly, there are a wealth of templates that you can use to speed up your paper prototyping process. 3flab inc.’s Printable PDFs cover every platform imaginable and are excellent. I use them in my workshops and encourage participants to download them.

This article is part of the UX design series sponsored by Adobe. Adobe XD is made for a fast and fluid UX design process, as it lets you go from idea to prototype faster. Design, prototype, and share — all in one app. You can check out more inspiring projects created with Adobe XD on Behance, and also sign up for the Adobe experience design newsletter to stay updated and informed on the latest trends and insights for UX/UI design.

(ra, yk, il)
Categories: Around The Web

Contributing To WordPress: A Beginner’s Guide For Non-Coders

Smashing Magazine - Thu, 03/01/2018 - 8:50am

If you’ve been using WordPress for any amount of time, there’s a good chance you’ve come across the following statement: “Free as in speech, not free as in beer.’ If you haven’t, pull up a chair and let’s talk.

WordPress is a free and open-source software (also known as FOSS) project. The explanation of that could easily fill up a separate article, but the TL;DR version is that the software is free to download, use, inspect and modify by anyone who has a copy of it. These modifications can also be contributed back to the original project and thereby shared with all the users of WordPress, making everyone’s lives better after every release.

Whenever your WordPress dashboard indicates that there is an update to WordPress, it means that hundreds of people from around the world have volunteered their time to contribute updates, bug fixes, and improvements to the project. These contributions are what make open-source projects so popular and appealing. Instead of a small team building only the features they deem important, hundreds of thousands of people can volunteer to improve WordPress on a daily basis.

Now, most people who learn about the fact that you can contribute back to WordPress (this now includes you, mostly because you just read the above three paragraphs) automatically assume that only contributions of code are useful to the project. WordPress is a software project, after all, so surely only software developers could contribute anything meaningful back to WordPress, right?

If you’re reading (or have ever heard) that line in your own voice, fear not. We’ve all been there. I myself was under the impression that the only way I could contribute back to WordPress was through code. However, you would be surprised to find that there are many ways that people can (and do) contribute back to the project without even writing or understanding a line of PHP.

Interested? Then let’s get cracking, shall we?

With our third SmashingConf San Francisco on April 17 & 18, we want to explore strategies for breaking out. We want to find out the why, and the how of outstanding and fast experiences, and what we all need to know today, to be more productive and make smarter decisions tomorrow. Hope to meet you there!

Check the speakers → Getting Started

If you visit the WordPress.org homepage, you’ll see a little “Get Involved” link in the top menu. This takes you to the Make WordPress blog where you can view all the areas in which you could get involved in. At last count, there are 17 active teams working hard on improving various aspects of WordPress. The teams are Core, Design, Mobile, Accessibility, Polyglots, Support, Themes, Documentation, Community, Plugins, Meta, Training, Test, TV, Marketing, CLI, and Hosting. I could write about them all, but would rather highlight some of the easiest to get involved in. I know this because I myself have contributed in one way or another via these teams.

The first thing you will need to do in order to be able to contribute to WordPress is to register a WordPress.org account. If you don’t already have one, you’ll receive an email to confirm your address and generate your password. Once you’ve done that, it would be a good idea to sign up for the WordPress Slack team. The WordPress project uses Slack as its main real-time communication platform, replacing all previous communication platforms such as IRC and Skype. If you don’t already use Slack, I also recommend downloading the app for your operating system; it makes communicating on Slack so much easier. Once you have signed up for Slack, look out for the Slack channel for your chosen team and join them. Most (if not all the teams) have regular weekly meetings for updates and such.

As a small way of showing your contribution chops, you will also now have a WordPress.org profile. When you join a team and make a contribution, you’ll get the relevant team badge added to your profile. As you can see on my profile, I’ve contributed as a Plugin Developer, WordCamp Organizer, Translation Contributor, and on the Community Team. Not that it’s about the collecting the badges (“gotta catch em all”), but it’s nice to be able to see how you’ve contributed to the project.


One of the first and easiest ways to contribute to the WordPress project is to help beta test the new WordPress releases. WordPress usually releases 2 to 3 major versions a year, with a few minor and security releases in between. By downloading the WordPress Beta Tester plugin to a WordPress install, you can test out the newest version of WordPress before their release and provide useful user feedback to the development team. Side note, I recommend doing this on a local install of WordPress, or a noncritical site, as using the beta of any software on a critical site is not recommended.

You can read more about the beta testing process in the Core handbook.

Support Forums

Have you ever visited the WordPress support forums? Did you know that every single reply on those forums is from a volunteer? Now take a look at the forum posts that don’t yet have replies. See any you think you can help with?

WordPress users from around the world post questions to the support forums daily. Even if your knowledge of WordPress is only limited to one aspect of the software, I’m pretty sure you could find one support ticket a day you could answer to help out another user.


The WordPress documentation team is always active. Recent updates include a big overhaul to the Developer documentation, including updating documentation for Theme and Plugin developer, Code Reference and the Rest API and WP CLI documentation. There are still a bunch of projects being worked on, including HelpHub, the new user documentation portal as well as all the various other team handbooks. If you have a passion for good written documentation, there is no better place for you to get involved.


The Polyglots team help to translate WordPress and its free themes and plugins to all the languages around the world. Contributing to this team is as simple as logging into the translation platform with your WordPress.org account, and suggesting translations. Each language has a Global Translation Editor (or GTE) who reviews the translations with a view to include them into the core software.

Over the past few years, the PolyGlots team has held Global Translations Days, where WordPress users meet and spend the day (or part of it) working on translating WordPress. Think of it as a ‘language’ hackathon. It’s pretty cool because all the thinking you really have to do is taking American English and translating it into your own language.


Another outstanding part of the WordPress community is WordPress.tv. This video archive of all things WordPress is led by a great group of volunteers. There are nearly a thousand videos of WordCamp sessions, interviews with community influencers and simple how-to instructional videos. Folks like John Parkinson do an incredible job editing, interviewing, and curating every piece of the WordPress that’s available and present it in video form. They are always looking for additional volunteers to help out with editing or moderating and reviewing videos, so get involved with the folks at WordPress.TV.


Are you always the one in the room who is talking about how great WordPress is to your co-workers, friends, and anyone online who will listen? Perhaps joining the WordPress Marketing team is an ideal choice for your participation. This special group meets every Wednesday morning via Slack to devise and develop different campaigns that try to attract new users, both individual and commercial. There are four different sub-groups within the Marketing team: marketing WordPress to developers (Group 1), marketing to agencies and clients (Group 2), marketing to end-users (Group 3), and marketing the WordPress community itself (Group 4). There is always something new happening within the marketing operations, and you could be a part of it all! Just let the team know you are interested and attend your first meeting.


The last team I want to mention is also my favorite, mostly because it does a lot of direct work with the people who use WordPress and I enjoy working with people. Also, it’s one that I’ve more recently started dedicating more of my contribution time to, and I’ve found the team to be a great bunch of people.

The Community Team oversees official events, mentorship programs, diversity initiatives, contributor outreach, and other ways of growing the WordPress community. Every time you attend a WordCamp or a WordPress meetup, you can be sure a member of this team has been involved. If you like dealing with people in a more direct manner than just email and you have a passion for community events the Community Team might just be the place for you.

So there you have it, seven different places you can contribute some of your time back to the WordPress project without having to look at a line of code. Pick your favorite, and you’re off!

(mc, ra, hj, il)
Categories: Around The Web

Exploring New Worlds: March Desktop Wallpapers, Challenge and The Winner

Smashing Magazine - Wed, 02/28/2018 - 10:30am

Everybody’s an artist. That was the idea behind the Smashing Creativity Challenge which we announced at the beginning of the month. We asked the community to get their creative ideas flowing, and design a desktop wallpaper for March 2018. The only requirement: The wallpaper had to somehow relate to the theme “Exploring New Worlds”. How? Well, only your imagination was the limit.

Today, we are happy to present the result of this creative experiment, and the lucky winner, too, of course. So let’s get ready to explore new worlds — be it the great unknown, the little adventures that inspire us every day, and even our own minds.

By the way, if you’re up for a creative challenge, too, we’ve got a new one coming up (plus a smashing prize to win) for April. More on that, at the end of this post.

Sneak a peek behind the scenes

Igor Izhik shows how he approaches all stages of designing a desktop wallpaper. Valuable tips for creating vector illustrations guaranteed. Curious? →

And The Winner Is … Let’s Get Outside!

Lívia Lénárt from Hungary designed a wallpaper that reminds us to get outside and seize the beginning of Spring. Who knows what adventures might await us there?

Download Lívia’s wallpaper:

Congratulations, Lívia! You won a Wacom Intuos Pro tablet (medium size). Enjoy! We’d love to see what it will inspire you to bring to life — perhaps we’ll see it in a future wallpapers post?

“You must unlearn what you have learned!” Meet the brand new episode of SmashingConf San Francisco with smart front-end tricks and UX techniques. Featuring Yiying Lu, Aarron Draplin, Smashing Yoda, and many others. Tickets now on sale. April 17-18.

Check the speakers → More Submissions

A big Thank You to everyone who participated. It was great to see the theme come to life in so many unique ways. Keep up the brilliant work!

Exploring New Worlds Through Books

“For me, every book has a new world in it. Whether it is a fairytale or thriller storybook, they always take us into a new world where we can explore new things, meet new peoples and witness a new story every time.” — Designed by Suman Sil from India.

Greetings from Mars

“I was inspired to create this artwork by space and planet Mars, and by the fact that the name of the month March comes from the Latin word ‘Martius’. It was named after Mars, the Roman god. The main character is a cat that lands on planet Mars and conquers it, the colors are predominant reds and browns with a contrast of light green. I played with texture and composition and of course I enjoyed designing the main character, an Astro-cat ready to explore the new world.” — Designed by Inna Alexandra Marculescu from Romania.

Peaceful Wave

“‘Exploring New Worlds’ made me think that if we could reinvent ourselves with a goal of peace and sharing - that would be an exciting place to live.” — Designed by Lora Eggleston from NC, USA.


“Exploring new worlds is much like exploring your own mind, creativity and knowledge. The only way to learn what’s really inside you is by trying something new. The illustration is my very own vision of the knowledge. It’s placed in some mysterious habitat. It’s a space where people learn from each other, find new talents and study their own limits.” — Designed by Julia Wójcik from Poland.

City Upon The Hill

“A defeated medieval knight arrives at a serene valley after a long onerous journey through forestlands and hills. A city upon a hill, glimmering in the dark of the night emerges in front of him. He realizes that his journey has finally come to an end.” — Designed by Dipanjan Karmakar from India.


“We wanted to pay homage to Starman who entered the Earth’s orbit in February. We truly hope to see it on Mars some day, so we made this graphic to visualize what it would be like up there.” — Designed by PopArt Studio from Serbia.

Sending FriendShips to March

Designed by João Acácio from Portugal.

Galaxy Glimpse

“For the ‘Exploring New Worlds’ theme I thought about Earth being a potential new planet to other worlds, so this is a little galaxy glimpse of an explorer from a different world.” — Designed by Kate Carlin from Australia.


“My mind went toward an imaginary world underwater when I thought of Exploring New Worlds. We often dream about exploring space or other planets, but it seems there is still much to discover here on Earth.” — Designed by Paul Cushing from Boise, Idaho.


Designed by Romana Águia Soares from Portugal.


“March brings the will to travel and with it comes the will (or need) to explore new worlds, new cultures, and even new challenges.” — Designed by Diana Lima from Portugal.

The Unknown

“As the theme you’ve proposed says ‘Exploring New Worlds’, I made here a connection, between the dark side and the unknown lighted and catchy area.” — Designed by Valentin Keleti from Romania.


“I am very fond of bicycles. This graffiti reminds me of my childhood during the 80’s and the begining of the 90’s when I loved to take a ride on my bicycle during the sunny days and sing my favorite song: ‘Wonderful Life’ from Black. Today when I ride the bicycle I always get that feeling of exploring the unknown: new day, sky, trees, streets, oh there is a new cat on the roof. Cheers!” — Designed by Marija Zaric from Belgrade, Serbia.

Search For Life On Planet Red

“Exploring New Worlds: It’s a race to find life beyond our planet Earth. Is Planet Red (Mars) our next destination? Let’s come and join hands to find our new world.” — Designed by Debobrata Debnath from India.

Sun Temple

“In March, the world awakes from its intense sleep and the first sun rays say us hello. They warm our souls with their playful joy. Let each of us rediscover the Sun Temple within ourselves, and our lives to become a joyful sunny day, regardless of the weather outside.” — Designed by Viktor Mazhlekov from Bulgaria.

Explore The Forest

“This month, I want to go to the woods and explore my new world in sunny weather.” — Designed by Zi-Cing Hong from Taiwan.

A New World

Designed by Kellie Heath from Portland, Oregon.

The Great Beyond

“My inspiration came mostly from ‘The Greay from’. It’s about a dog and an astronaut exploring a strange new world.” — Designed by Lars Pauwels from Belgium.

Explore The Far East

“March is a big month in Japan as it commemorates the start of Spring, new life, and blooming wild cherries. I have picked Japan as it’s the destination I always wanted to go to and explore their culture. Thus when reading the ‘Never Stop Exploring’ quote, I couldn’t think of anything else but this.” — Designed by Sara Galova from Portugal.

Live To The Fullest

“The purpose of life is to live it, to taste it, to experience to the utmost, to reach out eagerly and without fear for newer and richer experience. #ExploringNewWorlds” — Designed by Dekko Digital from India.

Join The Challenge!

Feeling inspired? Well, now’s your chance to get creative and feature your artwork on Smashing Magazine.

We’ve got a new challenge for you, and there’s a smashing prize waiting for one lucky winner! Design a desktop wallpaper in which you illustrate your favorite song. Once again, what you make out of it, is entirely up to you. There’s only one requirement: Please don’t simply write down the lyrics. Instead, show us what the song is about, what images arise in your head when you listen to it, what it means to you, how it makes you feel. Is it loud and bold, full of energy, or calm and relaxing? Show us!

The deadline is Monday, March 26th, 2018.

Please be sure to read the following guidelines carefully before you get started (we’ve also collected them in a PDF for you).

Submission Guidelines
  1. Please design two versions of your wallpaper. One with and one without a calendar for April 2018. This way, your wallpaper remains useful even after the month has ended. The calendar should be in English.
  2. Make sure the wallpaper contains a Smashing Magazine logo. You can download different versions of the logo at http://smashed.by/logos. Oh, and please feel free to include your own logo in it, too, if you want.
  3. Submit your design in as many different screen resolutions as you can, so that as many readers as possible can enjoy your artwork on their desktops.
  4. Name your files according to their resolutions and their formats (e.g., 1280x720.jpg or 1280x720.png), and save them in two separate folders named “cal” and “nocal”.
  5. Fill in this form. It will generate a file which you need to send us together with your artwork.
  6. You’re almost there: Pack your “cal” and “nocal” folders as well as the generated form file into an archive (preferably .zip).

Once you’ve bundled everything up, send us your package to the following address: wallpapers@smashingmagazine.com. If your ZIP is too large to send via email, please don’t hesitate to provide us with a Dropbox or Google Drive link instead.

The deadline is Monday, March 26th, 2018.

What You Can Win

After the deadline has ended, we’ll award a SmashingConf ticket of your choice to one lucky winner: It’s up to you to decide if you’d like to go to SmashingConf San Francisco (April 17th—18th) or SmashingConf Toronto (June 26th–27th). Good luck!

Design a wallpaper about your favorite song and win a ticket to one of our upcoming SmashingConfs.

Sounds good? We’d love to see what you’ll come up with. Happy designing!

If you have any questions, please feel free to get in touch with us anytime.

Categories: Around The Web
Syndicate content