Everything You Need To Know About Green UX

January 11, 2020 • About, Everything

Climate change is taking its toll on the environment. The temperature is rising, the Glaciers are melting, sea levels are rising, and the fauna and flora ranges are shifting.

According to the Intergovernmental Panel on Climate Change,

“Taken as a whole, the range of published evidence indicates that the net damage costs of climate change are likely to be significant and to increase over time.”

From the very start, all of these effects and many others account for the change have accounted for critical damage induced mainly by human activity in the form of CO₂ emissions.

In the midst of it all, the internet is a prominent cause to blame. Sure, the virtual world is affecting the real world on a massive scale; how can a UX designer or developer be involved in the overall impact? Take an ecommerce site for example. As soon as the visitor approaches the website to buy their desired products, their actions initiate a chain of events that contribute to higher emissions.

It’s even reported that if the internet were a country, it would rank among the ones having a high carbon footprint, such as the USA, China, and India. Where the internet connects so many people, it’s also inviting other drastic measures for the evolving carbon footprint.

For most of the global climate change impacts, sustainable practices and resources have been brought in to combat and reduce the apparent damage shortly. Is there a way designers or web design companies worldwide can contribute?

Instead of digging in the solutions first, let’s start by identifying how UX is indirectly contributing to the environmental damage and what you should know about creating green UX projects.

How UX Contributes To Growing CO2 Emissions

Data Centers And E-Waste

Every activity you carry out on a website or any other online platform, you need storage for your projects, files, texts, documents, and other media. You may even contact a company that provides data storage of XYZ GBs. While you may be at ease for having saved your information, the data in cloud storage is negatively impacting the environment. According to Amanda Sopkins from Sustainable UX,

“Notifications replace daily newspaper deliveries, emails replace receipts, and virtual clouds replace boxes of photographs. At first, this seems like a natural way to build a more sustainable world. However, rather than leveraging our power to create minimal solutions for hard problems, we gorge ourselves on this seemingly limitless space.” She later adds, “The buildup of all this material has an impact beyond the carbon that is produced by the servers that stores it. It has an impact on us: we lose track of what matters and what we should save.”

With millions of people interacting on the internet daily, it won’t be wrong to say that the data is massively hurling towards hyper-emission. It’s something we don’t see every day!

Mobiles And Energy Consumption

Each day, a new smartphone is released. The growing number of these devices is serving the energy-hungry populations, becoming somewhat blind to the environment. The process of smartphone production and delivery to the end-consumer greatly impacts the CO₂ emissions. For instance, an iPhone requires several hours to be created and assembled and takes up to hundreds of thousands of miles, fuel, and energy to reach the user.

The case gets worse with mobile screens becoming larger. The bigger it gets, the more materials it needs, and the more energy it consumes. How does this account for environmental damage? Every activity done on the phone requires energy and storage. As much data is stored in the data centers, more resources are exploited and greater damage is done.

Ways To Implement Green, Sustainable UX

While we mentioned just two examples of how UX is hurting the environment, we shouldn’t leave behind the measures to scale down the emission pressure. Here are a few ways we can think of.

1. Measure Your Carbon Foot Print

There’s no point in creating something if you can’t measure it. And when you can’t measure it, it will become impossible for you to manage it. When creating a sustainable user experience, one needs to review the existing research on the on-going web emissions and energy consumption. The sole purpose must base on understanding how this information can be used to estimate and cut website pollution.

For this purpose, websitecarbon.com launched a free tool to measure the amount of CO₂ a website is emitting. Upon entering the website URL, the tool rolls out the information about how much CO₂your website is emitting, and if it is following a sustainable approach.

2. Make The Experience Accessible For All

Among the practices for a sustainable UX, usability comes as the first and foremost priority, which can be enhanced with factors like readability and navigation. If the content on the website is light, guides the user expertly, and helps them recognize value, the overall experience expands into an accessible dimension.

The website’s cleanliness also matters. Less clutter and speedy loading mean lower carbon emission. If the content is presented with great clarity and directions, it builds a connection between sustainability and user experience.

3. Optimize Performance

Sometimes, websites designed with a user-focused approach have performance issues that have adverse impacts on the user experience. By optimizing the site, you not only reduce data consumption and emissions but also engage the users with satisfaction.

So, what type of content needs optimization? Text, images, and videos make up your website’s content, and optimization of these means improving your website’s performance and data usage. By using clear, concise text, high-quality images and videos, your website cuts down on the page loading time without losing the overall quality.

4. Teach Sustainability Through Practice

Designing for a better environment receives returns when the users interact with the design. Users are generally unaware of how a clean and eco-friendly website looks like, while they might be concerned about the environment in the other way.

At this point, it’s your responsibility to drop hints about a sustainable design along with motivating them to achieve green goals in a better way. However, you need to address what you’re making it, how people will use it, and how it reflects your strategy to create a safer environment. Your intent should be evident in your message throughout your website.

Why Aren?t We Curious About the Things We Want to Be Curious About?

October 25, 2019 • About, Curious

Sunday Review|Why Aren’t We Curious About the Things We Want to Be Curious About?

You can learn anything on the internet, so why do I so often learn things I don’t want to know? When I’m surfing the web I want to be drawn in by articles on Europe’s political history or the nature of quasars, but I end up reading trivia like a menu from Alcatraz prison. Why am I not curious about the things I want to be curious about?

Curiosity feels like it’s outside your control, and trying to direct it sounds as ill conceived as forcing yourself to find a joke funny. But if you understand what prompts curiosity, you may be able to channel it a little better.

Across evolutionary time, curious animals were more likely to survive because they learned about their environments; a forager that occasionally skipped a reliable feeding ground to explore might find an even better place to eat.

Humans, too, will forgo a known payoff to investigate the unknown. In one experiment, subjects were asked to choose one of four photos, each carrying some chance of paying a cash prize. Photos repeated, so subjects learned to pick the best-paying, but when a novel photo popped up, they chose it more often than the odds dictated they should. This preference for novelty is, of course, the reason manufacturers periodically tweak product packaging and advertising.

But it’s good to know about your environment even if it doesn’t promise a reward right now; knowledge may be useless today, but vital next week. Therefore, evolution has left us with a brain that can reward itself; satisfying curiosity feels pleasurable, so you explore the environment even when you don’t expect any concrete payoff. Infants prefer to look at novel pictures compared with familiar ones. Preschoolers play longer with a mechanical toy if it’s difficult to deduce how it works.

What’s more, curiosity doesn’t just ensure new opportunities for learning, it enhances learning itself. In a recent experiment, subjects read trivia questions and rated how curious each made them feel. Later, they saw the questions again, each followed by a photograph of a face, and judged whether that person looked like he or she would know the answer. In a surprise final memory test for the faces, subjects better remembered those appearing after trivia questions that made them curious. Curiosity causes a brain state that amplifies learning.

This function of curiosity — to heighten memory — is the key to understanding why we’re curious about some things and not others. We feel most curious when exploration will yield the most learning.

Suppose I ask you, “What’s the most common type of star in the Milky Way?” You’ll obviously feel no curiosity if you already know the answer. But you’ll also feel little interest if you know nothing about stars; if you learned the answer, you couldn’t connect it to other knowledge, so it would seem nearly meaningless, an isolated factoid. We’re maximally curious when we sense that the environment offers new information in the right proportion to complement what we already know.

Note that your brain calculates what you might learn in the short term — your long-term interests aren’t a factor. That’s why a cardiac surgeon who is passionate about her job will nevertheless find a conference presentation on the subject boring if her brain decides that the talk won’t add to her knowledge. Conversely, when a friend persuades her to watch a documentary on type fonts, her brain may calculate that this will be a rich source of information — and she finds herself fascinated.

It’s that disconnect between long- and short-term interests that makes frothy articles so frustrating. The feeling of curiosity promised you’d learn something and, admittedly, you did — now you know French citizens’ favorite macaron flavor — but you’re disappointed because your new knowledge doesn’t contribute to your long-term interests. You’ve been clickbaited by your own brain.

If following curiosity results in disappointment, maybe it shouldn’t be allowed to take the lead. Why not just search for topics you truly want to learn about? That sounds logical, but a search for “quasars” will yield thousands of hits and no way of knowing which offers the just-right match to your current knowledge that will maintain your curiosity. You’ll probably end up like the surgeon at the boring conference talk.

If you wish for more serious reading when you surf the web, the opportunistic approach is actually fine. You just need to frequent better foraging grounds.

Many websites that snare your time feature scores of stories on the front page, banking that one will strike each reader’s sweet spot of knowledge. So visit websites that use the same strategy but offer richer content, for example, JSTOR Daily, Arts & Letters Daily or ScienceDaily.

And pay more attention to bylines. Curiosity arises from the right balance of the familiar and the novel. Naturally, writers vary in what they assume their audience already knows and wants to know; when you find an author who tends to have your number, stick with her.

Einstein famously advised a young student to “never lose a holy curiosity.” Given our evolutionary history, there’s little danger any of us will. The challenge is changing its focus from the momentary to something more enduring.

Daniel T. Willingham (@DTWillingham) is a professor of psychology at the University of Virginia and the author, most recently, of “The Reading Mind: A Cognitive Approach to Understanding How the Mind Reads.”

The Times is committed to publishing a diversity of letters to the editor. We’d like to hear what you think about this or any of our articles. Here are some tips. And here’s our email: letters@nytimes.com.

Follow The New York Times Opinion section on Facebook, Twitter (@NYTopinion) and Instagram.

Let?s Not Forget About Container Queries

October 11, 2019 • About, Forget

Container queries are always on the top of the list of requested improvements to CSS. The general sentiment is that if we had container queries, we wouldn’t write as many global media queries based on page size. That’s because we’re actually trying to control a more scoped container, and the only reason we use media queries for that now is because it’s the best tool we have in CSS. I absolutely believe that.

There is another sentiment that goes around once in a while that goes something like: “you developers think you need container queries but you really don’t.” I am not a fan of that. It seems terribly obvious that we would do good things with them if they were available, not the least of which is writing cleaner, portable, understandable code. Everyone seems to agree that building UIs from components is the way to go these days which makes the need for container queries all the more obvious.

It’s wonderful that there are modern JavaScript ideas that help us do use them today — but that doesn’t mean the technology needs to stay there. It makes way more sense in CSS.

Here’s my late 2019 thought dump on the subject:

Philip Walton’s “Responsive Components: a Solution to the Container Queries Problem” is a great look at using JavaScript’s ResizeObserver as one way to solve the issue today. It performs great and works anywhere. The demo site is the best one out there because it highlights the need for responsive components (although there are other documented use cases as well). Philip even says a pure CSS solution would be more ideal.
CSS nesting got a little round of enthusiasm about a year ago. The conversation makes it seem like nesting is plausible. I’m in favor of this as a long-time fan of sensible Sass nesting. It makes me wonder if the syntax for container queries could leverage the same sort of thing. Maybe nested queries are scoped to the parent selector? Or you prefix the media statement with an ampersand as the current spec does with descendant selectors?
Other proposed syntaxes generally involve some use of the colon, like .container:media(max-width: 400px) { }. I like that, too. Single-colon selectors (pseduo selectors) are philosophically “select the element under these conditions” — like :hover, :nth-child, etc. — so a media scope makes sense.
I don’t think syntax is the biggest enemy of this feature; it’s the performance of how it is implemented. Last I understood, it’s not even performance as much as it mucks with the entire rendering flow of how browsers work. That seems like a massive hurdle. I still don’t wanna forget about it. There is lots of innovation happening on the web and, just because it’s not clear how to implement it today, that doesn’t mean someone won’t figure out a practical path forward tomorrow.

Everything About Style Guides, Design Systems, and Component Libraries

August 18, 2019 • About, Everything

August 7, 2019

For the better part of the last year, I’ve been investing heavily in front-end development and design.
When I started my new role at Hy-Vee, I identified a need for a component library and created it.
Since then, I’ve learned a lot about style guides, design systems, component libraries, and their best practices. This post will be a deep-dive on everything I’ve learned in the past year.

Why Should You Care?

Every website starts simple. There’s maybe one page with a few distinct pieces. It has modest intentions.

Then, slowly, it begins to scale.

More pages are added and new features are built. There might even be multiple teams devoted to specific sections of the site. You could be developing for mobile, too.

You start to notice the buttons in one part of the site are slightly different than everywhere else. One team decides to build a feature that another team has (unknowingly) already completed. Communication breakdowns happen. Consistency is lost.

Is this a preventable problem? Absolutely. Yet, why does it happen over and over again? Unless you think about your design and development process upfront, you will run into issues later as you scale.

To prevent this issue from happening, or to fix the existing lack of consistency in your products, you need three things:

Style Guide
Component Library
Design System

Don’t worry if you have no idea what I’m talking about yet. By the end of this article, you’ll have consumed almost a year’s worth of trial & error, research, and development.

What Is a Style Guide?

A style guide is a set of rules for how your brand should be displayed. This is both visual (design & imagery) as well as written content (voice & tone).

The purpose of a style guide is to allow multiple contributors to create content clearly that cohesively represents the brand. Almost every major brand has a style guide, though not all are public.

What Is a Component Library?

A component library is living, breathing implementation of your style guide. It’s a shared set of UI components that developers can consume to build applications reflecting your brand. Some notable benefits:

Having a component library means less custom code for consumers.
Since there’s a central location, you can ensure all components meet accessibility requirements.
Components become more robust with multiple contributors submitting bug fixes and improvements in a single place.
Less duplication of code allows you to ship new products and rewrite legacy code faster.

What Is a Design System?

A design system is a complete set of standards, documentation, and principles along with the components to achieve those standards. It is the marriage between your style guide and component library. One of the most popular design systems is Google’s Material Design.

A design system should contain:

Content — The language to design a more thoughtful product experience.
Design — The visual elements of the design system.
Components — The building blocks for developing new products and features.
Patterns — The individual pieces for creating meaningful product experiences.

Where Should You Begin?

Depending on the state of your company/product, you might have a different starting point. This is the outline before we dive into specifics.

Create an inventory of existing design patterns.
Establish design principles and begin a style guide.
Define your design tokens.
Create or identify an icon set.
Choose languages/frameworks supported.
Evaluate Monorepo vs. single package.
Evaluate CSS/Sass vs. CSS-in-JS.
Create a component library.
Choose a documentation platform.
Write design system documentation.

Building the Design System

Create an Inventory of Existing Design Patterns.

Unless you are starting from scratch, you will need to identify all the design patterns currently in use in your interface and document any inconsistencies.
The goal should be the same user experience regardless of which part of the product the user is in.

Start documenting and reviewing these amongst your team and identifying your preferred interaction patterns.
This should start to paint a picture of which pieces your style guide will need.

Establish Design Principles and Begin a Style Guide.

It’s time to translate these findings into the beginnings of a style guide. You can use tools like:

My recommendation would be Sketch, but it’s ultimately up to your team and company. Make sure you understand best practices around Sketch symbols and when to use nesting.

Define Your Design Tokens.

Design tokens are the visual design atoms of the design system — specifically, they are named entities that store visual design attributes. We use them in place of hard-coded values (such as hex values for color or pixel values for spacing) in order to maintain a scalable and consistent visual system for UI development.

This includes things like:

Colors (text, backgrounds, borders)
Fonts
Typography sizes
Spacing values
Shadows

For example, let’s take a look at Geist – Zeit’s Design System.

--geist-foreground: #000;
--geist-background: #fff;
--accents-1: #fafafa;
--accents-2: #eaeaea;
--accents-3: #999999;
--accents-4: #888888;
--accents-5: #666666;
--accents-6: #444444;
--accents-7: #333333;
--accents-8: #111111;
--geist-success: #0070f3;
--geist-error: #ee0000;
--geist-warning: #f5a623;
--dropdown-box-shadow: 0 4px 4px 0 rgba(0, 0, 0, 0.02);
--dropdown-triangle-stroke: #fff;
--scroller-start: var(--geist-background);
--scroller-end: rgba(255, 255, 255, 0);
--shadow-small: 0 5px 10px rgba(0, 0, 0, 0.12);
--shadow-medium: 0 8px 30px rgba(0, 0, 0, 0.12);
--shadow-large: 0 30px 60px rgba(0, 0, 0, 0.12);
--portal-opacity: 0.25;

There is now a shared language between designers and developers.

Create or Identify an Icon Set.

If you already have existing icons, you’ll need to determine which to keep. It might not make sense to create your own icons depending on the size and priorities of your company. You might be better off utilizing an open-source icon library. Here are some examples:

Regardless if you build your own or use open source, you should standardize on usage and identify consumption patterns. It’s also worth considering who are the end-users of your icons set – designers, developers, and marketing?

Using SVGs, you can make the icon library your single source of truth. Your process might look like this:

Designers create/provide raw SVGs.
Optimize and compress the SVGs using SVGO.
Automatically create React components using SVGR for developers.
Output PNGs and JPEGs at different sizes/resolutions for marketing.
Compile SVGs into a bundled font for mobile applications to use.

Choose Languages/Frameworks Supported.

What languages or frameworks are you currently supporting? Which should the component library support?
It’s important to think about this ahead of time so you can properly architecture your library.

If you have an application which uses script tags instead of ES Modules, then you’ll need to
configure your component library to bundle into a single distributable file. For example,
a vanilla JavaScript application would need something like this in an HTML file.

<script src="/js/component-library.min.js">script>

To achieve this, you can use either Webpack or Rollup.
I would recommend Webpack, as it’s the industry standard.

Evaluate Monorepo Vs. Single Package.

A Monorepo allows you to build and publish multiple libraries from a single repo. While it does solve some very real problems, it also creates others. It’s important to understand the pros and cons.

Pros

✅ Small bundle sizes by decreasing the scope of components included in one package.
✅ Shared built, lint, test, and release process for multiple packages versus separate repositories with duplicated code.
✅ More granular control of semver on a package-by-package basis.

Cons

⛔️ Additional tooling and infrastructure needed.
⛔️ Consumers are required to import from a variety of packages instead of one single component library.
⛔️ Cutting edge technology. There is industry adoption, but you can run into issues very few have experienced without a clear path for a solution.

Some questions that will help you identify which solution is right for your company.

Do you currently have multiple repositories all publishing to NPM?
Is your build, test, lint infrastructure complex? Is it duplicated in many places?
How many repositories do you have (or plan to have in the next year?)
How large is your team? How many people will be consuming the component library?
Will it be open-source? Can you lean on others in the industry to help solve problems?
Do you see the need for multiple packages in the future? (e.g. icons, codemods, etc)

For most smaller companies, I would argue that a Monorepo is unnecessary. It has its time and place. We use it at Hy-Vee (~150 developers) to distribute 10 different packages at once, spanning both internal and external apps.

Note: Want to use a Monorepo? Check out Creating a Monorepo with Lerna & Yarn Workspaces.

Evaluate CSS/Sass Vs. CSS-In-JS.

I’ve come to prefer CSS-in-JS, especially styled-components. There’s a variety of different CSS-in-JS options outlined here. The major selling points for styled-components for our component library were:

Feels like writing traditional CSS vs. JavaScript objects
React & React Native support
Auto-prefixing vendor styles
Scoped styles which eliminate global CSS conflicts

If your component library needs to support outputting raw HTML/CSS as an option, I would recommend sticking with Sass. A great example of this is IBM’s Carbon Design System.

<button class="bx--btn bx--btn--primary" type="button">
    Button
button>

Regardless of the technology you choose, I would recommend using CSS variables to contain your design tokens.

Create a Component Library.

With your technical requirements defined and your style guide started, you should now be able
to begin constructing a component library. My recommendation would be to use React alongside Storybook.

Creating a component library is much more than just translating the style guide into code.

You’ll need to think about how consumers will interact with your components.
What sort of API would they expect? What provides the most clarity and is self-documenting?
For example, consider buttons. You have different variations of buttons – primary, secondary, etc.

Should you have separate components for each?

<PrimaryButton>Hello World!PrimaryButton>
<SecondaryButton>Hello World!SecondaryButton>

or should you use a prop?

<Button>Hello World!Button>
<Button variant="secondary">Hello World!Button>

Secondarily, what should the prop be called? variant? type? Did you consider that type is a reserved attribute for the HTML