Free One-Page Portfolio Website Builders

Original Source: http://feedproxy.google.com/~r/1stwebdesigner/~3/oKBT6B9eBao/

In the growing world of designers, developers and other online service providers, having a great portfolio is essential to getting hired. You won’t get work if you don’t put yourself out there, and what better way than with a portfolio? These one-page website builders are free, easy to use, and simple to set up, so you can get your portfolio online fast.

Carrd

Carrd

Carrd is a one-page site maker that uses a super straightforward interface to help you set up your portfolio. If you’re looking to create something elegant and minimalistic, you’ll love this. Many builders can be overwhelming before you get used to them, but Carrd is easy to use right from the get-go. Just pick a theme and click one button to add elements.

There’s a really cheap Pro version, which offers various forms, custom domain compatibility, and custom code + third party widgets. At $9 a year, this is about as affordable as it gets. However, all the core features are free, so feel free to test it out and even publish your website.

Mobirise

Mobirise

An offline web builder solution for Mac and Windows, Mobirise allows you to easily create mobile-friendly websites. It was specifically designed to be as easy to use as possible for non-programmers and visual thinkers. If you’re new to this, try it out.

Once you’ve finished putting together your website in this block-based builder, publish it for free wherever you want. No domain? Mobirise can publish to Github Pages at no cost to you.

About.me

About.me

Simple and professional, creating an about.me website is a great way to introduce yourself. Just type in some info about yourself, pick from one of three clean themes, and you have a mini portfolio! From there you can customize the website further, changing text and adding links. There’s also a nifty email signature feature, which adds your about.me as an email signature.

The Pro version has various other features, testimonials, image and video embeds, messages, appointment scheduling and newsletter building. With the free version, you can still build a professional biography.

WordPress

WordPress

If you’d rather do it yourself than use a simple website builder, but don’t have the technical know-how to create a website from scratch, WordPress is probably the solution. Choosing a one-page WordPress template still gives you something to work off of, but you’ll be more in control of your website’s appearance. And there’s hundreds of thousands of themes – no website builder can boast that.

Customizing and making it your own may require HTML and CSS knowledge, and you’ll also need to handle hosting, domain and WordPress installation. WordPress itself is free and open source, but these aspects will probably cost money.

Diving blindly into WordPress is not for the faint of heart, but if you’re up for a challenge, this might be the solution for you.

Wix

Wix

Wix is considered by many to be similar to WordPress, but much easier to use. Its interface is intuitive enough, and setting up and publishing a website is super easy. There’s a ton of functionality in this builder if you’re willing to learn it.

The free version of Wix allows you to create and publish your site under a Wix domain. Premium plans let you get a custom domain, remove Wix ads from the site, or add apps, but it isn’t necessary to make your portfolio public.

Persona

Persona

Persona does absolutely no beating around the bush. Just click to get started, pick a theme, and start editing. The WYSIWYG editor is super powerful. It takes some adjusting to, but once you have the hang of it, you can create basically whatever you want.

However, note that you can only create a private Persona without upgrading. If you want to publish your portfolio, it will cost a relatively cheap $24/year or $4/month. Trying before you buy will at least let you know if this is the right tool for you.

Building a Simple One-Page Portfolio

Never underestimate the power of a one-page portfolio. A site that’s too complex can drive away potential clients, especially if you can’t hold their interest long enough to direct them to the contact page. But a well-crafted one-page website is concise and gets the point across quickly, while still showing off your skills to visitors.


Free Programming Courses from Harvard, MIT, Microsoft and More

Original Source: http://feedproxy.google.com/~r/1stwebdesigner/~3/O4jAGc1SW2A/

Did you know that you can learn computer science and programming online from institutions like Harvard, MIT, Berkeley and Microsoft on edX.org? The nonprofit site offers 2,000 online courses from 140 institutions worldwide. Courses are free to try.

edX Online Courses

Popular Courses

Here are some of the most popular courses and programs offered on edX:

CS50 from Harvard

The most popular course on edX gives you an introduction to computer science and programming. Learn how to think algorithmically and solve programming problems efficiently. Gain familiarity in a number of programming languages including C, Python, SQL, JavaScript, CSS and HTML.

Front End Web Developer from W3C

W3C (World Wide Web Consortium) is the organization that develops web standards. It was founded by the inventor of the web, Tim Berners-Lee. In this 5 course program, learn how to code with modern HTML5 tags, draw and animate fun web graphics, and play audio and video elements. Learn CSS best practices for web page design and the fundamentals of JavaScript to help you develop interactive web apps.

Introduction to Computing in Python from Georgia Tech

In this 4 course program, learn the fundamentals of computer science in one of the field’s most popular programming languages, Python 3, including writing code, executing it, interpreting the results, and revising the code based on the outcomes. Rated as one of the most in-demand and beginner-friendly programming languages, a background in Python will give you a solid foundation to build your career. Short videos (2-3 minutes each) are rapidly interwoven with live programming problems and multiple-choice questions to give you constant feedback on your progress and understanding.

C Programming with Linux from Dartmouth

Did you know that smartphones, your car’s navigation system, robots, drones, trains, and almost all electronic devices have some C-code running under the hood? Along with the C programming language comes Linux, an essential operating system that powers almost all supercomputers and most of the servers worldwide, as well as all Android devices and most “Internet of Things” devices.

In this 7-course program, develop and debug code in the C programming language. Discover the foundations of computer programming and Linux, manipulate the command line, manage processes, files and memory, and compile C code with Linux.

Data Science from Harvard

Data science is one of the hottest fields in programming. Learn key data science essentials in this 9-course program, including R and machine learning, through real-world case studies to jumpstart your career as a data scientist. Also learn statistical concepts such as probability, inference, and modeling and how to apply them in practice. Gain experience with data visualization with ggplot2 and data wrangling with dplyr. Become familiar with essential tools for practicing data scientists such as Unix/Linux, git and GitHub, and RStudio. This is one of the most popular programs on edX.

Blockchain for Business from the Linux Foundation

Everyone has heard of blockchain, but most don’t understand how it can apply to their business. Learn exactly what a blockchain is, its impact and potential for change around the world, and analyze use cases in technology, business, and enterprise products and institutions in this fundamental course from the experts at the Linux Foundation.

Microsoft Courses

Some of the popular Microsoft courses include:

Introduction to Typescript

Want to write organized code for your website that you can easily manage and maintain? TypeScript is the answer to building scalable web applications. TypeScript lets you write JavaScript the way you want to. TypeScript is a typed superset of JavaScript that compiles to plain JavaScript. It works on any browser. Any host. Any OS.

Introduction to Bootstrap

Bootstrap is an open source project originally created by Twitter to enable creation of responsive, mobile first web pages. Bootstrap has a standard set of classes that allow developers to quickly create applications that scale to devices of all sizes, and incorporate common components such as dialog boxes and validation. Bootstrap has become a de facto standard for web design.

Introduction to jQuery

jQuery is the most popular library for JavaScript. In this course, you will learn how to use jQuery to add additional power and interactivity to your web pages. You’ll see how to take advantage of jQuery in your web pages, how to work with the HTML document, and even make server-side calls.

Introduction to Angular

In this course, you will learn about the basics of how Angular works, and why Angular has emerged as a popular framework for JavaScript/TypeScript application development. You will also learn how to properly set up your development environment for creating an Angular app, including installing VS Code, Node.JS, TypeScript, and the Angular CLI.

Introduction to ReactJS

ReactJS is the latest JavaScript framework to capture the hearts and attention of the frontend developer community. Developers love ReactJS because it’s highly performant and renders changes almost instantly. The best part about ReactJS is that it is a relatively small framework and does not take too much time to learn!

Start Learning Today

If you are looking for something else, edX offers beginner to advanced programming courses in C++, C#, Java, Power BI, Artificial Intelligence, Machine Learning, Deep Learning, Cybersecurity, IoT, Cloud Computing, AWS, Azure, DevOps, and more. View more courses here.


5 Signs That Web Design Is Reaching Its Own Industrial Age

Original Source: https://www.webdesignerdepot.com/2019/04/5-signs-that-web-design-is-reaching-its-own-industrial-age/

The Internet as a concept, and as a community, is much like a teenager: it’s struggling to establish its identity, everyone is trying to tell it what to do, and it tends to lash out at both people who deserve it as well as those who don’t. It does so at random, and you’re not its real dad, anyway.

The practice of designing websites, however, has gone right past the teenage years and blown past the whole human-life-span metaphor entirely. Web design is, in my opinion, reaching an industrial age, of sorts. You know, the era of smokestacks and Charles Dickens’ really depressing novels.

Let’s see how:

Increased DIY Capability

The sewing machine was invented in 1755, about five years before the “official beginning” of the industrial age. This machine, and others like it, heralded the beginning of that age and the massive machines that would come after, but they also drastically expanded the production capabilities of individuals working at home, or in their place of business.

It started with software like FrontPage and Dreamweaver, and now we’ve got Squarespace, Wix, Weebly, Duda, Webflow, and a host of other options. They’re all designed to enhance the output of the individual, the hobbyist, the business owner, and the freelancing professional. Work that once might have taken a very long time for one person, or a reasonable amount of time for ten people, is all being done by one person, in a lot less time.

And if you’re a purist, you can always sew the buttons onto your web page by hand.

Increased Automation At The Professional-Level

Think of the massive looms in old factories. Now it’s not particularly easy to automate creative visual work, as such. Most of the automation in web design is done at the coding stage, in both front and back end. But even with such simple tools as Symbols in Sketch or Affinity Designer can drastically reduce the work required to produce a large number of designs.

Or at least something like a large number of buttons. It’s not a perfect analogy to the factories of old, but the tools we have are making it consistently easier to produce designs of consistent quality, even if they also have pretty uh… “consistent” layouts and aesthetic styles. This sort of drastically increased output is the very definition of industry.

Expansion Of The Digital Middle Class

Increased DIY capability and automation in the industrial age led to a dramatic expansion in what people could afford. The increased amount of work in general meant that more people could afford that stuff, and thus, the middle class was born.

The same thing is happening in web design. For the hobbyist or professional building sites on the cheap, shared hosting can cost as little as a few dollars a month, and code editors are free. For less code-focused hobbyists and business owners alike, code-free website builders are attractive and largely affordable options, too. Plenty of platforms offer a straight-up free plan.

Getting a web presence of some kind has literally never been easier, and it’s going to keep getting easier.

Outsourcing And Subcontracting

Then, of course, there’s outsourcing and sub-contracting. These come in two major forms: software as a service, and labor. SaaS in particular has become exceedingly popular as a way to build a product that constantly pays for itself, leaving you to focus on maintenance, and improvements. The train engineers of old wish they could have worked on their trains while they were still running.

While few websites are, I think, built by orphans trapped in smoke-filled factories, we should not ignore the fact that there is a lot of cheap labor out there. And you know what? A lot of them are actually really good, and are only cheap because of the economic disparity between nations. This actually leads me to my next point…

Poor Enforcement Of Industry Standards

One of the downsides of industrial ages as they happen all over the world is this: the constant push for progress sometimes leaves much to be desired in the way we treat our fellow humans. Of course, this isn’t happening to web designers in a bubble. The “gig economy” is often used as an excuse not to provide benefits for employees. Cheap labor is often taken advantage of in the worst ways. Overworking people to near-death is accomplished not with whips, but with Instagram and Twitter feeds praising the eighty-hour work week.

And the actual standards meant to ensure the quality of the product are often ignored. The W3C does a lot of good work, but they don’t actually have the power to enforce HTML validation. Well… that’s probably for the best, all things considered, but as we’ve seen, governments are also poorly equipped to provide QA for the Internet as a whole.

However, I should note that I greatly appreciate some of the government-led work done in the field of accessibility, particularly in countries that require WCAG compliance.

Fear Of Obsolescence

The proliferation of industry created a lot of jobs, and killed a lot of others. Design, however, is still a creative discipline, and thus there will always be room for good designers. Even so, automation and code-free design tools have people worried, and I can understand why. That said, lots of people will actually hire you to use Wix for them, so… shrug.

People outsourcing relatively easy tasks might save us, yet.

It’s Not All Doom And Gloom…

We call hand-crafted websites… well… that. Sometimes “bespoke”. Perhaps a better word would be “artisanal”, and we should just get used to being hipsters. I’m only mostly kidding.

In every industrial age we’ve witnessed, things got bad, and then they got better. We haven’t gotten rid of all the smoke stacks yet, but the world is in most ways a much better place than it was, and the Internet is developing faster than the rest of the world. It may be an industrial age now, but imagine what it will be like when they invent computers.

Wait…

 

Featured image via Unsplash.

Add Realistic Chalk and Sketch Lettering Effects with Sketch’it – only $5!

Source

p img {display:inline-block; margin-right:10px;}
.alignleft {float:left;}
p.showcase {clear:both;}
body#browserfriendly p, body#podcast p, div#emailbody p{margin:0;}

Guide to Linting JavaScript with JSHint

Original Source: https://www.hongkiat.com/blog/code-optimisation-linting-jshint/

Editor’s note: This article is part of our Code Optimization series, where we take a look at how to optimize coding for better efficiency in a bid to be better coders. Linting in computer…

Visit hongkiat.com for full content.

3 Essential Design Trends, May 2019

Original Source: https://www.webdesignerdepot.com/2019/04/3-essential-design-trends-may-2019/

Sometimes designs are of an acquired taste. That’s our theme for this month.

Each of the projects and trends featured here are things that you’ll probably either love…or hate. But wait to judge these projects until you navigate through them; most of them seem to grow on you the more you dive into the content. Here’s what’s trending in design this month:

Chaos by Design

Have you ever looked at a design and wondered “what were they thinking?”

But then … “that is actually pretty nice.”

It seems like there are plenty of designs out there right now that feature a structure of chaos. These projects are identifiable by an aesthetic that seems to be all over the place, but the more you dig into it, the more it seems to come together.

Common themes include:

Lack of an obvious grid
Lots of motion or animation across multiple elements
Website elements with the same visual weight
“Too many” fonts or colors
Oversized elements that make you think about content
“Trendy” word breaks without hyphenation
Peeking elements from the edges of the canvas

If these things sound like they could make a mess out of the design, you are totally right. But what’s happening with these projects – and the super talented design teams behind them – is that they break all the rules and work.

You will want to keep scrolling through these designs to see what comes next. Each of the examples below incorporates some of these themes and they are stunning.

Oversized Lettering

Big, bold typography has been a trend in website design for some time (we’ve explored that here on multiple occasions.) But there’s been a common theme until now: Most oversized type has been of the sans serif variety.

Now the trend is shifting to an even bolder display above the scroll: Oversized lettering and script fonts.

Each of the examples below uses this trend in a different way:

Kota uses a subtle gradient-color animation in a minimal style design. The letters KOTA are the brand of the website and have a memorable design. While the main logo of the site uses a simple square mark with a sans serif, the funky lettering style is carried through the design in the form of call to action links/buttons.

Feral also features its name in the center of the screen with a handwriting style font, but the bright yellow letters are on top of a dark image and behind a simple tagline for the company. The rest of the design is brighter and more minimal, but hints of the funky font carry through in surprising details.

Alt is a little less big than the other featured trending designs, but it is just as bold. What’s nice about the handwriting-style font here is that it is sleek and has a retro feel. As a center-screen element, it draws the eye in among multiple smaller photos and helps create a sense of cohesion among elements. The font and bright blue color combination do a great job of setting the mood for this website design. (Pay attention to the animation as well. The words don’t move while the image pop around it, some behind and some in front.)

The common theme among all three projects is that this style of typography works best with a single word or short phrase. This style of type can be a challenge in terms of readability, so sticking to a simple use is the best option.

Poster-Style Hero Images

Creating a poster-style hero image or homepage screen might be the least controversial trend in the roundup this month, but it can be equally challenging when it comes to design. With multiple layered elements and bold elements, getting the visuals to collapse (or expand) to different responsive viewports can take some work.

There are so many different ways to create a design that follows this trend. The commonality is that the first screen is an immersive visual experience. It’s not a about how much to read or three places to click; it’s about setting the scene for interactions to come.

What often makes this design style work is a combination of amazing imagery – each of the examples below start with stunning images – impactful text and enough of a curiosity tease to get users to explore the design more. (It’s also interesting that all three examples are from design studios; that’s where many envelope-pushing trends show up first.)

Deep Blue does this with an amazing visual. You might not know exactly what the website is about at first glance, but it’s so pretty that you’ll probably scroll to learn more. If you do, the design has done its job.

Chaptr Studio uses a striking image in a different way. It grabs your attention with a tiny, animated cursor that expands on clickable elements. Users hardly have to try to understand that there’s much more to this design.

Alber Graphics tugs at your curiosity with a stunning image and visual theme that is reminiscent of “Through the Looking Glass.” The visual presentation is so strong that users want to know what’s next; can you feel yourself wanting to engage with the CTA just to see how they respond?

Conclusion

How many of this month’s trends could you see as part of future design projects?

Working with super trendy elements, especially ones that break common design rules or contrast with principles of design theory, can be a challenge. But if you get it right, there’s a huge upside. That’s what you get with each of the projects above; these risky design concepts are well worth the time and are a lot of fun to explore.

Add Realistic Chalk and Sketch Lettering Effects with Sketch’it – only $5!

Source

p img {display:inline-block; margin-right:10px;}
.alignleft {float:left;}
p.showcase {clear:both;}
body#browserfriendly p, body#podcast p, div#emailbody p{margin:0;}

A Designer’s Guide To Better Decisions

Original Source: https://www.smashingmagazine.com/2019/04/designers-guide-better-decisions/

A Designer’s Guide To Better Decisions

A Designer’s Guide To Better Decisions

Eric Olive

2019-04-29T12:30:16+02:00
2019-04-29T12:35:13+00:00

Nearly everyone has experienced frustration while using a website, mobile app, or web application. In these moments, we might wonder “What were they thinking?” followed by “They sure were not thinking about making this easy for me.” One reason we encounter such frustrating moments is that the process of making sound and user-friendly decisions is difficult.

In this article, we’ll identify four decision-related traps that impede good design and offer techniques for avoiding these traps. These decision traps are based on research conducted by psychologists, neuroscientists, molecular biologists, and behavioral economists including several cited in this article.

Too many design decisions occur in isolation, are based on gut feel, or are not carefully examined. The web offers many examples of poor design decisions. For instance, let’s take a look at the example below.

A field in a form asking users to enter the place of birth. And Hover text that says: 'Please enter the place of birth of your parent.'

On the left: Are they asking for city, state, or country? On the right: This tooltip does not answer the user’s question. (Large preview)

At first glance, it seems quite straightforward: type the place of birth in the text field. A moment’s reflection, however, raises a question. Should we type the country, state, or city? It’s not clear. Clicking the question mark icon displays the help text shown below, to the right. The problem? The text does not answer the question; it simply restates the original request about entering the place of birth.

The design shown above violates a basic tenet of user experience (UX) immortalized by the title of Steven Krug’s famous book Don’t Make Me Think. Sure, it’s an amusing title, but he’s serious. The entire field of user experience is based on the idea of reducing the user’s cognitive load:

“Just like computers, human brains have a limited amount of processing power. When the amount of information coming in exceeds our ability to handle it, our performance suffers.”

— Kathryn Whitenton

In other words, when a design requires users to guess or think too hard about something as simple as one text entry, users will often make mistakes (costing your organization time and money) or abandon the task altogether.

Lightening the user’s cognitive load means increasing our own cognitive load as designers. We do have to think, hard and carefully. Essential to this effort is learning how to make good design decisions.

There are four common decision traps that we often fall into. I’ll explain how you can avoid them.

Availability Heuristic
Focalism Bias
Optimism Bias
Overconfidence Bias

1. Availability Heuristic

A heuristic is a mental shortcut that helps us make decisions quickly. These mental shortcuts are essential in certain situations. For example, if a car veers into your lane, you must act quickly; you don’t have time to review several options.

Unfortunately, heuristics become a flaw when making decisions in situations where many factors and participants must be considered. One such flaw is the availability heuristic, which involves an incomplete examination of current and past information.

A particularly distressing example of the availability heuristic in the design space is the software on the Boeing 737 Max. As of this writing, it appears that this software contributed to the tragedy of the downed airplanes. People around the world have asked how to prevent such tragedies in the future.

Part of the answer lies in avoiding quick fixes. Airbus, Boeing’s chief competitor, had refitted their A320 planes with larger engines. Boeing felt pressured to do the same leading to a variety of changes:

“The bigger engines altered the aerodynamics of the plane, making it more likely to pitch up in some circumstances.”

To compensate, Boeing added new software to the 737 Max:

This software “would automatically push the nose down if it sensed the plane pointing up at a dangerous angle. The goal was to avoid a stall. Because the system was supposed to work in the background, Boeing believed it didn’t need to brief pilots on it, and regulators agreed. Pilots weren’t required to train in simulators.”

The obvious and horrifying conclusion is that Boeing engineers and designers were placed under immense pressure to re-design the 737 Max at record speed resulting in a series of misjudgments. Less obvious, but equally troubling, is the likely role of the availability heuristic in these tragedies.

In short, the information used to make critical design decisions was not sufficient and resulted in tragedy.

Small red circle within a much larger blue circle

The availability heuristic limits our perspective (Large preview)

Solution

One solution is for designers to identify their area of competence. Within this sphere their intuitions are likely to serve them well, explains author Rolf Dobelli in The Art of Thinking Clearly. For example, UX designers should feel comfortable making decisions about layout and interaction design issues like flow, navigation, and how much information to present at one time.

When designers face a decision outside their circle of competence, it’s worth taking time to apply hard, slow, rational thinking. For example, when designing cockpit software for jets, designers would be well advised to work closely with engineers and pilots to ensure that everything in the proposed user interface (UI) is precise, accurate, and provides the information pilots need when they need it.

We are all subject to the availability heuristic. Designers must strive to mitigate this heuristic by consulting a variety of subject matter experts (SMEs), not simply the programmers and engineers on their immediate teams. The downside risk is simply too high.

2. Focalism Bias

The availability heuristic hinders our ability to assess current and past information. The focalism bias concerns our ability to look forward. It refers to the inclination to concentrate on a single point when considering the future. As Harvard psychologist Daniel Gilbert explains in his book Stumbling on Happiness:

“It is difficult to escape the focus of our own attention — difficult to consider what it is we may not be considering.”

Camera lens showing a nature scene in focus

The focalism bias restricts our view of the future. (Large preview)

For example, while my colleagues and I were conducting UX research for a U.S. government agency, we discovered that caseworkers could not access information essential to processing applications for medical assistance.

As shown in the diagram below, these caseworkers literally had to stop in the middle of the application process in order to request critical information from another division. Typically, caseworkers had to wait 24 to 48 hours to receive this information.

Diagram listing many steps before re-design and fewer steps after re-design

The focalism bias led to a delay, the opposite of the desired results. Our re-design resolved the issue. (Large preview)

Caseworkers found this delay stressful because it made it more difficult to meet a federal law requiring all applications to be processed within 10 days of receipt.

How did this happen? One reason, surprisingly, was the emphasis on deadlines. Through our observation and interviews, we learned that the system had been rushed into production to meet a project deadline (all too common) and to give caseworkers a way to process applications more efficiently.

The intentions were good, the goals made sense. Unfortunately, the focus on rushing a system into production to supposedly expedite the process had the opposite effect. Designers created a system that delayed the application process.

Solution: Become An Active Problem Seeker

This idea may sound counterintuitive. Why would we look for problems? Don’t we already have enough to deal with? In truth, however, organizations that seek problems, such as Toyota, often demonstrate impressive performance. They’re called high-reliability organizations (HROs). Other examples include the U.S. Navy’s aircraft carriers and air traffic control centers in the U.S., both of which have incredibly low error and failure rates.

As decision expert Michael Roberto of Bryant University explains, leaders of HROs do not wall themselves off from the possibility of failure. On the contrary, they preoccupy themselves with failure. For example, they:

Do not simplify explanations.
Remain sensitive and attentive to their front-line operations as we did while observing caseworkers.
Defer to those who have the local, specialized knowledge as opposed to those who simply have authority in the hierarchy. Again, we relied on the expertise of caseworkers on the ground.

Commit to resilience, to the notion that you cannot prevent all small problems. Rather, the goal is to focus on fixing these small problems before they mushroom into large problems.

Man standing on a mountain looking out with binoculars

Actively seeking problems leads to better decisions. (Large preview)

Problems are not the enemy; hidden problems are because these hidden problems become serious threats down the road as we saw in the government agency examples outlined above. In both cases, earlier and additional contextual inquiry (observing users in their natural home or work environments) would likely have identified current problems and possible UI solutions to these problems.

For example, while conducting contextual inquiry for a large Mexican bank, I observed customers trying (and failing) to transfer money to family members who held accounts at different banks. Customers expressed frustration at this limitation because they wanted an easy way to send money to family members, especially those who lived far away.

While living in Mexico, I learned that loaning and giving money to family members is more common in Mexico than in the U.S., Canada, or parts of Western Europe.

Given the deeply rooted Mexican tradition of supporting family members in financial need, I was initially surprised by this banking limitation. Upon reflection, however, I realized that this limitation was simply a hidden problem. When coding the banking web site, the developers were likely focused on security, paramount in all matters financial. They had not considered including a cross-bank transfer feature.

I identified this missing feature by conducting UX Research with banking customers in Mexico. This real-world example shows how critical it is to become an active problem seeker.

3. Optimism Bias

Focusing on a single point or problem impedes our ability to plan and design for the future. An equally troubling challenge is the optimism bias. We tend to imagine the best-case scenario.

“For example, we underrate our chances of getting divorced, being in a car accident, or suffering from cancer. We also expect to live longer than objective measures would warrant, overestimate our success in the job market, and believe that our children will be especially talented.”

— Tali Sharot

In design culture, this bias sounds like this:

“Sure, this part of the UI is a bit clunky, but customers will get used to it, and then it won’t be an issue.”

In other words:

“We need to ship the product; we don’t want to deal with the cumbersome interaction.”

As anyone who has conducted a survey or usability test knows, this optimism is misplaced. Users and customers are easily frustrated and often show little patience when products and UIs are hard to use.

I witnessed this bias when designing a web application for financial advisers — 70% of whom were male. The client insisted on using a red font to emphasize certain numbers. Even after I explained that approximately 9% of males are color blind, she refused to change the font color. She reasoned that financial advisers would see the numbers in context. In other words, no problem. When I conducted multiple rounds of usability testing, however, two male advisers struggled to distinguish the numbers in red. They could read those numbers, but the figures did not stand out.

The reason for this type of wishful thinking is our tendency to see the future as a variant of the present. We tend to assume that things will go on more or less as they have. In the case of the financial application, because advisers had not complained before so my client assumed that they would not complain in the future. What she failed to grasp was the significance of changing the font to red.

As author David DiSalvo explains:

“We tend to simulate the future by re-constructing the past, and the re-construction is rarely accurate.”

Solution: The Pre-Mortem Technique

That’s why it’s essential to resist this innate tendency by leveraging techniques like psychologist Gary Klein’s pre-mortem. The idea is to describe a scenario in which the project failed to meet a specific goal such as a revenue target, an increase in the percentage of new purchases, requests for more information, etc.

Here’s how it works. Before committing to a major initiative, the key stakeholder (often an executive) gathers everyone who is slated to participate. She outlines the key objective and explains “what went wrong.” The statement will sound something like this:

“Imagine that we have rolled out a new e-commerce mobile app at a cost of $3 million with a projected revenue of $10 million for the first year. At the end of one year, revenue is $1 million, a huge failure. Please take 20 minutes to write a history of this failure.”

This pre-mortem exercise:

Legitimizes doubt by providing a safe space for asking questions and expressing concerns about the decision.
Encourages even supporters of the decision to search for threats not previously considered.

An e-commerce mobile app is simply an example. The pre-mortem technique can be applied to nearly any project in any industry because it’s about expanding our perspective in order to identify what could realistically go wrong.

4. Overconfidence Bias

We unconsciously exaggerate our ability to accurately assess the present and predict the future. A study of patients who died in a hospital ICU compared the doctor’s diagnosis to the actual autopsy results. The doctors who were completely confident in their diagnosis were wrong 40% of the time.

When designers fall prey to the optimism bias, they exaggerate their ability to understand how users think. The most common results are information overload and confusing terminology and controls (buttons, checkboxes, sliders, and so on).

For example, while evaluating a client’s tablet-based investment application targeted at lay people, my team and I immediately noticed that:

The screen where users would create a risk profile included extraneous information.
The phrase “time zone” would likely confuse users. The client intended the term to refer to the customer’s investment time horizon. Yet, “time zone” usually means the time in a country or region, such as the U.K. or South Africa.
Plus and minus controls exhibited low affordance meaning that it was hard to tell whether they could be tapped or were simply part of the display.

These observations were supported during a subsequent usability test when participants expressed confusion over these specific points. In short, the designers for this project had overestimated their ability to create an interface that users would understand.

Solution

One solution is to conduct user research as we did with the tablet-based financial application outlined above. If such research is not possible, a second solution is to actively seek case studies beyond your immediate context. For example:

If you are designing an investment application, it might make sense to **refer to banking applications** to identify potential design challenges and what is already working well for customers.
If you are designing a tablet application to help nurse practitioners make a preliminary diagnosis, **look to other projects that are related** but outside your immediate context. Has your company developed a medical device UI for surgeons or ER doctors? What worked well for users? What did not?

Referring to other projects may sound like a no-brainer. Ask yourself, however, how often a systematic review of previous, related (but not identical) projects occurs within your organization. Remember, we are all subject to overconfidence.

Conclusion

In this piece, we’ve identified four common decision traps and corresponding solutions:

The availability heuristic causes us to ignore potentially important current or past information when making decisions. The solution is to expand our perspective by reaching beyond our circle of competence. For designers, this often means consulting highly technical experts.
Closely related is the focalism bias, our tendency to concentrate on a single point when designing thus overlooking other, equally important factors. The solution is to actively seek problems in order to identify and address hidden problems now before they become even larger difficulties.
The optimism bias refers to our tendency to imagine the best-case scenario. The solution is the pre-mortem technique. In this exercise, we imagine that a design project has gone terribly wrong and discuss why and how this happened. As with active problem seeking, the idea is to identify issues before they occur or get worse.
In the design space, the overconfidence bias refers to exaggerating our ability to understand how users think and design accordingly. The solution is to conduct user research and seek case studies similar to the current design initiative.

The cognitive biases discussed here are not intended to criticize designers (I am one). Rather, they are scientific observations about human nature. While we can’t change our biology, we can remain mindful of this biology and apply the four solutions outlined in this article. In so doing, we will increase the chances of creating better, safer, and more engaging designs.

Resources

“Minimize Cognitive Load To Maximize Usability,” Kathryn Whitenton, Nielsen Norman Group
“The Optimism Bias,” Tali Sharot, ScienceDirect
“Don’t Make Me Think,” Steve Krug
“Stumbling On Happiness,” Daniel Gilbert
“The Art of Thinking Clearly,” Rolf Dobelli
“Thinking Fast And Slow,” Daniel Kahneman
“What Makes Your Brain Happy and Why You Should Do the Opposite,” David DiSalvo
“Why Great Leaders Don’t Take Yes For An Answer,” Michael Roberto

Smashing Editorial
(ah, yk, il)

Monochrome Album Design for WARP – Steve Aoki and cie

Original Source: http://feedproxy.google.com/~r/abduzeedo/~3/v8nTQVknm4E/monochrome-album-design-warp-steve-aoki-and-cie

Monochrome Album Design for WARP – Steve Aoki and cie
Monochrome Album Design for WARP - Steve Aoki and cie

AoiroStudioApr 29, 2019

Let’s kick it off with a monochrome album design for WARP for The Bloody Beetroots featuring Steve Aoki. Designed by Carosello Lab, a creative agency based in Milan, Italy. They have a working collaboration DIM MAK, Steve Aoki’s label from California. They designed a special package to celebrate the 10th year anniversary of WARP. The song by The Bloody Beetroots feat. Steve Aoki became a global hit in 2009 by mixing electronic sound with rock and punk elements. This kind of graphic design has been quite inspirational and influential from times and still keep being accomplished.

Links
Full Project on Behance
Studio Site
Monochrome Album Design for WARP - Steve Aoki and cieMonochrome Album Design for WARP - Steve Aoki and cieMonochrome Album Design for WARP - Steve Aoki and cieMonochrome Album Design for WARP - Steve Aoki and cieMonochrome Album Design for WARP - Steve Aoki and cieMonochrome Album Design for WARP - Steve Aoki and cieMonochrome Album Design for WARP - Steve Aoki and cieMonochrome Album Design for WARP - Steve Aoki and cieMonochrome Album Design for WARP - Steve Aoki and cie


SitePoint Premium New Releases: Docker, Redux, & Interviews

Original Source: https://www.sitepoint.com/sitepoint-premium-new-releases-docker-redux-interviews/

We’re working hard to keep you on the cutting edge of your field with SitePoint Premium. We’ve got plenty of new books to check out in the library — let us introduce you to them.

Learning Docker – Second Edition

Docker lets you create, deploy, and manage scalable app containers across multiple platforms. Learn how to package apps and build, ship, and scale containers. Delve into microservice architecture. Explore real-world examples of securing and managing Docker containers.

Read Learning Docker – Second Edition.

Programming Interviews Exposed

With up-to-date advice on how to succeed in programming job interviews, this book discusses what interviewers need to hear, approaching phone screens with non-technical recruiters, examining common interview problems and tests, demonstrating your skills verbally, in contests, on GitHub, and more.

Read Programming Interviews Exposed.

Learning Redux

With Redux, build consistent web apps that run in different environments (client, server and native), and are easy to test, by centralizing the state of your app. Take your web apps to the next level by combining the power of Redux with other frameworks such as React and Angular.

Read Learning Redux.

And More to Come…

We’re releasing new content on SitePoint Premium almost every day, so we’ll be back next week with the latest updates. If you’re not a member yet, check out our library for $14.99/month.

The post SitePoint Premium New Releases: Docker, Redux, & Interviews appeared first on SitePoint.

Privacy UX: Privacy-Aware Design Framework

Original Source: https://www.smashingmagazine.com/2019/04/privacy-ux-aware-design-framework/

Privacy UX: Privacy-Aware Design Framework

Privacy UX: Privacy-Aware Design Framework

Vitaly Friedman

2019-04-25T13:30:16+02:00
2019-04-26T17:34:54+00:00

Part 1: Privacy Concerns And Privacy In Web Forms
Part 2: Better Cookie Consent Experiences
Part 3: Better Notifications UX And Permission Requests
Part 4: Privacy-Aware Design Framework

We’ve already explored approaches for better cookie consent prompts, permission requests, and notifications UX, but how do they fit into an overall design strategy as we make design decisions in our design tools?

In her article “What does GDPR mean for UX?”, Claire Barrett, a UX and UI designer at Mubaloo in Bristol, UK, has shared a very practical, actionable set of UX guidelines that the design agency has been following in respect to GDPR. While these guidelines specifically target GDPR, they are applicable to a much wider scope of user-friendly and privacy-aware interactions, and could therefore be applicable to any kind of project:

Users must actively opt in to having their data collected and used.
Users must give consent to every type of data-processing activity.
Users should have the right to easily withdraw their consent at any time.
Users should be able to check every organization and all third parties that will handle the data.
Consent isn’t the same as agreeing to the terms and conditions, so they shouldn’t be bundled together; they are separate, and should have separate forms.
While asking for consent at the right times is good, it’s even better to clearly explain why consent will benefit their experience.

One of the interesting things that Claire recommends in her article is to focus on “just-in-time” data collection (mentioned in part 3 of this series); that is, explain why data is required, and how it will and will not be used — but only when the app or website actually needs it. Obviously, this could be done by including an “info” icon next to the more personal bits of information collected, and showing the tooltip with the benefits and rationale behind data collection on request.

'Just-in-time' explanations

‘Just-in-time’ explanations with the info tooltip in forms. (Image source: Claire Barrett) (Large preview)

Many mobile applications require access to location, photos, and even the camera during installation, which isn’t something most customers would be happy to consent to. A more effective way of getting permission is to explain the need for data at the point of collection by using “just-in-time” prompts, so users can give consent only when they understand the purpose of it, very much like we’ve seen with permissions earlier in this series.

'Just-in-time' prompts

‘Just-in-time’ prompts, asking for access to location only when it’s actually required. (Image source: Claire Barrett) (Large preview)

The explanations should also inform customers how to withdraw consent where applicable, and provide a link to the privacy policy. These have been a matter of ongoing complaints for years, as lengthy privacy policies written in perfectly obscure legalese are almost impossible to comprehend without a dedicated review session. (In fact, a 2008 study showed it would take the average person roughly 244 hours per year to read all of the privacy policies for the sites they use, which translates to about 40 minutes per day.)

Rather than presenting the privacy policy as a wall of convoluted text, it could be chunked and grouped into clearly labelled sections and expandable text, optimized for scanning, locating, and understanding.

Separated policy actions

Separated policy actions, presented as accordions. Optimized for easy scanning and comprehension. (Image source: Claire Barrett) (Large preview)

Once consent is granted, customers should have full control over their data; that is, the ability to browse, change, and delete any of the data our applications hold. That means data settings in our mobile applications need to provide granular options to revoke consent, and opt out from marketing preferences, as well as the option to download and delete any data without wandering around the convoluted maze of help sections and ambiguous setting panels.

'data settings' menu

Customers should have full control over their data, so our ‘data settings’ menu should provide granular options to revoke consent, opt out from preferences, and download/or delete all data. (Image source: Claire Barrett) (Large preview)

The main issue with privacy-aware design decisions is that it’s difficult to assess the impact of data collection and all the interface challenges it poses on design and development. Being humble and subtle isn’t just a matter of respect, but also about reducing technical debt and avoiding legal battles down the road. For that, the following general guidelines could help as well.

Save As Little Data As Possible

If you choose to store credit card data, you have to be upfront about the security measures you take to store them confidentially. The less data you require and store, the less of an impact a potential breach would have.

Treat Personal Data Well

Not all data is created equal. When users provide personal information, distinguish between different strata of data, as private information is probably more sensitive than public information. Treat personal data well, and never publish it by default. For example, as a user completes their profile, provide an option to review all the input before publishing it. Be humble, and always ask for permission first; proactively protect users and don’t store sensitive data. That might help prevent uncomfortable situations down the line.

This goes not only for the procedure of storing and publishing user data on your servers, but also when it comes to password recovery or using customer data for any kind of affiliate partnerships. In fact, handing over a customer’s email to somebody else without explicit consent is a breach of trust and privacy, and often results in emails marked as spam because customers are suddenly confronted with an unfamiliar brand they don’t trust. In fact, the latter is almost like a defence mechanism against rapacious websites that continuously harvest emails in exchange for a free goodie, access to videos, and freemium offerings.

Explain Early What Kind Of User Data Third Parties Will Receive

When providing an option for social sign-in, be specific about what will happen to the user’s data and what permissions third parties will have. Usually a subtle note appears when social sign-in is prompted, but it’s a good idea to be explicit straightaway about how data will be treated, and specifically what will not happen to a user’s data.

It’s common to see user interactions coming to a halt once customers are forced into connecting their brand new accounts with already existing ones, or when they are encouraged to use their social profiles to make progress with the app. That’s never a straightforward step to take, and requires some explanation and assurance that revoking access is easy.

Prepare Customer Data For Export

It’s not trivial to get a complete picture of the collected data, especially if third parties are involved. Make sure that whenever personal data is collected, it’s structured in a way that’s optimized for export and deletion later on. Bonus points if it’s also digestible for the end user, so they can find the bits and pieces they need once they are interested in something very specific. That also means tracking what types of data are collected and where data flows, as we can use this structure later to provide granular control over data settings and privacy preferences in our UI.

You might have heard of a few friendly companies that make importing personal data remarkably seamless, yet exporting user data is painfully difficult, or close to impossible. Unsurprisingly, this practice isn’t perceived well by customers; and especially at times when they are thinking about deleting their account, such a pervasive lock-in will lead to customer support complaints, call centre calls, and angry outbursts in social channels. That’s not a delightful feature that will keep them loyal long-term.

While some companies can take public blaming because of their sheer size, for many small and mid-sized companies, reputation is the most precious asset they have, and so it’s wise not to gamble with it. You could even think of partnering with similar services and make user data seamlessly portable and transferrable to each of them, while expecting the same feature to be supported by partners as well.

Making It Difficult To Close Or Delete An Account Fails In The Long Term

Corporate behemoths have excelled in making it remarkably difficult for customers to close or delete their accounts. And this technique works when when moving away is painfully difficult — that’s the case for Amazon and Facebook.

However, if you are working on a relatively small website which strives for its loyal customers, you might not be able to pull it off successfully, at least not long-term. The overall impact is even more harmful if you make it difficult to cancel a recurring payment, as is often the case with subscriptions. (In fact, that’s why subscriptions are also difficult to sell — it’s not just the commitment to monthly payments, but rather the difficulty of cancelling the subscription at a later time without extra charge due to early cancellation.)

In fact, just as designers are getting better at hiding notorious profile settings for deleting an account, so too are customers at finding ways to navigate through the maze, often supported by the infinite wisdom of easily discoverable tutorials in blogs. If it’s not the case, customers resort to the tools they know work best: turning their back on the service that shows no respect towards their intentions — usually by marking emails as spam, blocking notifications, and using the service less. It doesn’t happen overnight; but slowly and gradually, and as interviews showed, these customers are guaranteed to not recommend the service to their friends or colleagues.

Surprisingly, it’s the other way around when it’s remarkably easy to close the account. Just like with notifications, there might be good reasons why the user has chosen to move on, and very often it has nothing to do with the quality of service at all. Trying to convince the customer to stay, with a detailed overview of all the wonderful benefits that you provide, might be hitting the wrong targets: in corporate settings especially, the decision will have been made already, so the person closing the account literally can’t do much about changing the direction.

examples of cancellation of account and terminated subscription in smashing magazine

With Smashing Membership, we try to explain what happens to the data in a clear way, and give an option to leaving Members to export their data without any hidden tricks. (Large preview)

For Smashing Membership, we’ve tried to keep the voice respectful and humble, while also showing a bit of our personality during offboarding. We explain what happens to the data and when it will be irrevocably deleted (seven days), provide an option to restore the plan, allow customers to export their orders and guarantee no sharing of data with third parties. It was surprising to see that a good number of people who canceled their Membership subscription, ended up recommending it to their friends and colleagues, because they felt there was some value in it for them even though they didn’t use it for themselves.

Postpone Importing Contacts Until The User Feels Comfortable With The Service

Of course, many of our applications aren’t particularly useful without integrating the user’s social circle, so it seems plausible to ask customers to invite their friends to not feel lonely or abandoned early on. However, before doing so, think of ways of encouraging customers to use the service for a while and postpone importing contacts until the point when users are more inclined to do so. By default, many customers would block an early request as they haven’t yet developed trust for the app.

Save User Data For A Limited Amount Of Time After Account Closure

Mistakes happen, and it holds true for accidental mis-taps as much as deleting all personal data after a remarkably bad day. So while we need to provide an option to download and delete data, also provide an option to restore an account within a short amount of time. That means that data will be saved after the account is deleted, but will be irrevocably removed after that grace period has passed. Usually, 7–14 days is more than enough.

However, you could also provide an option for users to request the immediate deletion of data via email request, or even with a click on a button. Should users be informed about the ultimate deletion of their files? Maybe. The final decision will probably depend on how sensitive the data is: the more sensitive it is, the more likely users will want to know the data is gone for good. The exception is anonymized data: most of the time, customers won’t care about it at all.

Provide User-Friendly Summaries Of Privacy Policy Changes

Nothing is set in stone, and so your privacy policy and default privacy settings might need to adjust because of new personalization features or a change of the tracking script. Whenever this happens, rather than highlighting the importance of privacy in lengthy passages of text, provide clear, user-friendly summaries of changes. You could structure the summary by highlighting how things used to be and how they are different now. Don’t forget to translate legalese into something more human-readable, explaining what the change actually means for the user.

Frankly, most users didn’t seem to care much about privacy policy changes. After the never-ending stream of policy update notifications in 2018, the default reaction is usually immediate consent. Once they’ve noticed anything related to privacy policy in the subject line or the email body, they immediately accept changes before even scrolling to the bottom of the email. However, the more personal the data stored is, the more time was spent reviewing the changes, which often were remarkably confusing and unclear.

medium.com privacy policy

Microcopy has always been at the very heart of Medium.com. A well-designed and well-structured privacy policy with clear summaries of privacy policy changes. (Image source: Email Design BeeFree) (Large preview)

mailchimp privacy policy

MailChimp, with a concise summary of changes of its privacy policy. (Large preview)

Note: The folks at Really Good Emails have collected some great examples of email design related to GDPR if you’re looking for more inspiration on how to share privacy policy changes with your users and subscribers.

Set Up A Communication Strategy In Case Of A Breach

Nobody wants havoc after user data is compromised. In such situations, it’s critical to have a clear and strong communication strategy. Have an explanation prepared in case some user data is compromised. Mandy Brown published a fantastic article, “Fire Drills: Communications Strategy in a Crisis”, on A List Apart, explaining how to set one up, and a few things to consider when doing it.

Privacy By Design

It might sound like visiting websites is a quite ordinary activity, and users should feel comfortable and familiar with features such as social sign-in, importing contacts, and cookie prompts. As we’ve seen in this series, there are many non-trivial privacy considerations, and more often than not, customers have concerns, doubts, and worries about sharing their personal data.

Of course, the scope of this series could stretch out much further, and we haven’t even looked into password recovery, in-app privacy settings design, floating chat windows and pop-ups, performance and accessibility considerations, or designing privacy experiences for the most vulnerable users — children, older people, and those with disadvantages. The critical point when making design decisions around privacy is always the same, though: we need to find a balance between strict business requirements and respectful design that helps users control their data and keep track of it, instead of harvesting all the information we can and locking customers into our service.

A good roadmap for finding that balance is adopting a privacy-first best-practice framework, known as Privacy by Design (PbD). Emerging in Canada back in the 1990s, it’s about anticipating, managing, and preventing privacy issues before a single line of code is written. With the EU’s data protection policy in place, privacy by design and data protection have become a default across all uses and applications. And that means many of its principles can be applied to ensure both GDPR-compliance and better privacy UX of your website or application.

In essence, the framework expects privacy to be a default setting, and a proactive (not reactive) measure that would be embedded into a design in its initial stage and throughout the life cycle of the product. It encourages offering users granular privacy options, respectful privacy defaults, detailed privacy information notices, user-friendly options, and clear notification of changes. As such, it works well with the guidelines we’ve outlined in this series.

I highly recommend reading one of Heather Burns’ articles, “How To Protect Your Users With The Privacy By Design Framework,” in which she provides a detailed guide to implementing the Privacy by Design framework in digital services.

Where to start, then? Big changes start with small steps. Include privacy in the initial research and ideation during the design stage, and decide on defaults, privacy settings, and sensitive touchpoints, from filling in a web form to onboarding and offboarding. Minimize the amount of collected data if possible, and track what data third parties might be collecting. If you can anonymize personal data, that’s a bonus, too.

Every time a user submits their personal information, keep track of how the questions are framed and how data is collected. Display notifications and permission requests just in time, when you are almost certain that the customer would accept. And in the end, inform users in digestible summaries about privacy policy changes, and make it easy to export and delete data, or close an account.

And most importantly: next time you are thinking of adding just a checkbox, or providing binary options, think about the beautifully fuzzy and non-binary world we live in. There are often more than two available options, so always provide a way out, no matter how obvious a choice might appear. Your customers will appreciate it.

Smashing Editorial
(yk, il)

Getting To Know The MutationObserver API

Original Source: https://www.smashingmagazine.com/2019/04/mutationobserver-api-guide/

Getting To Know The MutationObserver API

Getting To Know The MutationObserver API

Louis Lazaris

2019-04-26T13:30:16+02:00
2019-04-26T11:43:00+00:00

In complex web apps, DOM changes can be frequent. As a result, there are instances where your app might need to respond to a specific change to the DOM.

For some time, the accepted way to look for changes to the DOM was by means of a feature called Mutation Events, which is now deprecated. The W3C-approved replacement for Mutation Events is the MutationObserver API, which is what I’ll be discussing in detail in this article.

A number of older articles and references discuss why the old feature was replaced, so I won’t go into detail on that here (besides the fact that I wouldn’t be able to do it justice). The MutationObserver API has near complete browser support, so we can use it safely in most — if not all — projects, should the need arise.

Basic Syntax For A MutationObserver

A MutationObserver can be used in a number of different ways, which I’ll cover in detail in the rest of this article, but the basic syntax for a MutationObserver looks like this:

let observer = new MutationObserver(callback);

function callback (mutations) {
// do something here
}

observer.observe(targetNode, observerOptions);

The first line creates a new MutationObserver using the MutationObserver() constructor. The argument passed into the constructor is a callback function that will be called on each DOM change that qualifies.

The way to determine what qualifies for a particular observer is by means of the final line in the above code. On that line, I’m using the observe() method of the MutationObserver to begin observing. You can compare this to something like addEventListener(). As soon as you attach a listener, the page will ‘listen’ for the specified event. Similarly, when you start observing, the page will begin ‘observing’ for the specified MutationObserver.

The observe() method takes two arguments: The target, which should be the node or node tree on which to observe for changes; and an options object, which is a MutationObserverInit object that allows you to define the configuration for the observer.

The final key basic feature of a MutationObserver is the disconnect() method. This allows you to stop observing for the specified changes, and it looks like this:

observer.disconnect();

Options To Configure A MutationObserver

As mentioned, the observe() method of a MutationObserver requires a second argument that specifies the options to describe the MutationObserver. Here’s how the options object would look with all possible property/value pairs included:

let options = {
childList: true,
attributes: true,
characterData: false,
subtree: false,
attributeFilter: [‘one’, ‘two’],
attributeOldValue: false,
characterDataOldValue: false
};

When setting up the MutationObserver options, it’s not necessary to include all these lines. I’m including these simply for reference purposes, so you can see what options are available and what types of values they can take. As you can see, all except one are Boolean.

In order for a MutationObserver to work, at least one of childList, attributes, or characterData needs to be set to true, otherwise an error will be thrown. The other four properties work in conjunction with one of those three (more on this later).

So far I’ve merely glossed over the syntax to give you an overview. The best way to consider how each of these features works is by providing code examples and live demos that incorporate the different options. So that’s what I’ll do for the rest of this article.

Observing Changes To Child Elements Using childList

The first and simplest MutationObserver you can initiate is one that looks for child nodes of a specified node (usually an element) to be added or removed. For my example, I’m going to create an unordered list in my HTML, and I want to know whenever a child node is added or removed from this list element.

The HTML for the list looks like this:

<ul id=”myList” class=”list”>
<li>Apples</li>
<li>Oranges</li>
<li>Bananas</li>
<li class=”child”>Peaches</li>
</ul>

The JavaScript for my MutationObserver includes the following:

let mList = document.getElementById(‘myList’),
options = {
childList: true
},
observer = new MutationObserver(mCallback);

function mCallback(mutations) {
for (let mutation of mutations) {
if (mutation.type === ‘childList’) {
console.log(‘Mutation Detected: A child node has been added or removed.’);
}
}
}

observer.observe(mList, options);

This is only part of the code. For brevity, I’m showing the most important sections that deal with the MutationObserver API itself.

Notice how I’m looping through the mutations argument, which is a MutationRecord object that has a number of different properties. In this case, I’m reading the type property and logging a message indicating that the browser has detected a mutation that qualifies. Also, notice how I’m passing the mList element (a reference to my HTML list) as the targeted element (i.e. the element on which I want to observe for changes).

See full interactive demo  →

Use the buttons to start and stop the MutationObserver. The log messages help clarify what’s happening. Comments in the code also provide some explanation.

Note a few important points here:

The callback function (which I’ve named mCallback, to illustrate that you can name it whatever you want) will fire each time a successful mutation is detected and after the observe() method is executed.
In my example, the only ‘type’ of mutation that qualifies is childList, so it makes sense to look for this one when looping through the MutationRecord. Looking for any other type in this instance would do nothing (the other types will be used in subsequent demos).
Using childList, I can add or remove a text node from the targeted element and this too would qualify. So it doesn’t have to be an element that’s added or removed.
In this example, only immediate child nodes will qualify. Later in the article, I’ll show you how this can apply to all child nodes, grandchildren, and so on.

Observing For Changes To An Element’s Attributes

Another common type of mutation that you might want to track is when an attribute on a specified element changes. In the next interactive demo, I’m going to observe for changes to attributes on a paragraph element.

let mPar = document.getElementById(‘myParagraph’),
options = {
attributes: true
},
observer = new MutationObserver(mCallback);

function mCallback (mutations) {
for (let mutation of mutations) {
if (mutation.type === ‘attributes’) {
// Do something here…
}
}
}

observer.observe(mPar, options);

Try out the demo  →

Again, I’ve abbreviated the code for clarity, but the important parts are:

The options object is using the attributes property, set to true to tell the MutationObserver that I want to look for changes to the targeted element’s attributes.
The mutation type I’m testing for in my loop is attributes, the only one that qualifies in this case.
I’m also using the attributeName property of the mutation object, which allows me to find out which attribute was changed.
When I trigger the observer, I’m passing in the paragraph element by reference, along with the options.

In this example, a button is used to toggle a class name on the targeted HTML element. The callback function in the mutation observer is triggered every time the class is added or removed.

Observing For Character Data Changes

Another change you might want to look for in your app is mutations to character data; that is, changes to a specific text node. This is done by setting the characterData property to true in the options object. Here’s the code:

let options = {
characterData: true
},
observer = new MutationObserver(mCallback);

function mCallback(mutations) {
for (let mutation of mutations) {
if (mutation.type === ‘characterData’) {
// Do something here…
}
}
}

Notice again the type being looked for in the callback function is characterData.

See live demo  →

In this example, I’m looking for changes to a specific text node, which I target via element.childNodes[0]. This is a little hacky but it will do for this example. The text is user-editable via the contenteditable attribute on a paragraph element.

Challenges When Observing For Character Data Changes

If you’ve fiddled around with contenteditable, then you might be aware that there are keyboard shortcuts that allow for rich text editing. For example, CTRL-B makes text bold, CTRL-I makes text italic, and so forth. This will break up the text node into multiple text nodes, so you’ll notice the MutationObserver will stop responding unless you edit the text that’s still considered part of the original node.

I should also point out that if you delete all the text, the MutationObserver will no longer trigger the callback. I’m assuming this happens because once the text node disappears, the target element is no longer in existence. To combat this, my demo stops observing when the text is removed, although things do get a little sticky when you use rich text shortcuts.

But don’t worry, later in this article, I’ll discuss a better way to use the characterData option without having to deal with as many of these quirks.

Observing For Changes To Specified Attributes

Earlier I showed you how to observe for changes to attributes on a specified element. In that case, although the demo triggers a class name change, I could have changed any attribute on the specified element. But what if I want to observe changes to one or more specific attributes while ignoring the others?

I can do that using the optional attributeFilter property in the option object. Here’s an example:

let options = {
attributes: true,
attributeFilter: [‘hidden’, ‘contenteditable’, ‘data-par’]
},
observer = new MutationObserver(mCallback);

function mCallback (mutations) {
for (let mutation of mutations) {
if (mutation.type === ‘attributes’) {
// Do something here…
}
}
}

As shown above, the attributeFilter property accepts an array of specific attributes that I want to monitor. In this example, the MutationObserver will trigger the callback each time one or more of the hidden, contenteditable, or data-par attributes is modified.

See live demo  →

Again I’m targeting a specific paragraph element. Notice the select drop down that chooses which attribute will be changed. The draggable attribute is the only one that won’t qualify since I didn’t specify that one in my options.

Notice in the code that I’m again using the attributeName property of the MutationRecord object to log which attribute was changed. And of course, as with the other demos, the MutationObserver won’t start monitoring for changes until the “start” button is clicked.

One other thing I should point out here is that I don’t need to set the attributes value to true in this case; it’s implied due to attributesFilter being set to true. That’s why my options object could look as follows, and it would work the same:

let options = {
attributeFilter: [‘hidden’, ‘contenteditable’, ‘data-par’]
}

On the other hand, if I explicitly set attributes to false along with an attributeFilter array, it wouldn’t work because the false value would take precedence and the filter option would be ignored.

Observing For Changes To Nodes And Their Sub-Tree

So far when setting up each MutationObserver, I’ve only been dealing with the targeted element itself and, in the case of childList, the element’s immediate children. But there certainly could be a case where I might want to observe for changes to one of the following:

An element and all its child elements;
One or more attributes on an element and on its child elements;
All text nodes inside an element.

All of the above can be achieved using the subtree property of the options object.

childList With subtree

First, let’s look for changes to an element’s child nodes, even if they’re not immediate children. I can alter my options object to look like this:

options = {
childList: true,
subtree: true
}

Everything else in the code is more or less the same as the previous childList example, along with some extra markup and buttons.

See live demo  →

Here there are two lists, one nested inside the other. When the MutationObserver is started, the callback will trigger for changes to either list. But if I were to change the subtree property back to false (the default when it’s not present), the callback would not execute when the nested list is modified.

Attributes With subtree

Here’s another example, this time using subtree with attributes and attributeFilter. This allows me to observe for changes to attributes not only on the target element but also on the attributes of any child elements of the target element:

options = {
attributes: true,
attributeFilter: [‘hidden’, ‘contenteditable’, ‘data-par’],
subtree: true
}

See live demo  →

This is similar to the previous attributes demo, but this time I’ve set up two different select elements. The first one modifies attributes on the targeted paragraph element while the other one modifies attributes on a child element inside the paragraph.

Again, if you were to set the subtree option back to false (or remove it), the second toggle button would not trigger the MutationObserver callback. And, of course, I could omit attributeFilter altogether, and the MutationObserver would look for changes to any attributes in the subtree rather than the specified ones.

characterData With subtree

Remember in the earlier characterData demo, there were some problems with the targeted node disappearing and then the MutationObserver no longer working. While there are ways to get around that, it’s easier to target an element directly rather than a text node, then use the subtree property to specify that I want all the character data inside that element, no matter how deeply nested it is, to trigger the MutationObserver callback.

My options in this case would look like this:

options = {
characterData: true,
subtree: true
}

See live demo  →

After you start the observer, try using CTRL-B and CTRL-I to format the editable text. You’ll notice this works much more effectively than the previous characterData example. In this case, the broken up child nodes don’t affect the observer because we’re observing all nodes inside the targeted node, instead of a single text node.

Recording Old Values

Often when observing for changes to the DOM, you’ll want to take note of the old values and possibly store them or use them elsewhere. This can be done using a few different properties in the options object.

attributeOldValue

First, let’s try logging out the old attribute value after it’s changed. Here’s how my options will look along with my callback:

options = {
attributes: true,
attributeOldValue: true
}

function mCallback (mutations) {
for (let mutation of mutations) {
if (mutation.type === ‘attributes’) {
// Do something here…
}
}
}

See live demo  →

Notice the use of the attributeName and oldValue properties of the MutationRecord object. Try the demo by entering different values in the text field. Notice how the log updates to reflect the previous value that was stored.

characterDataOldValue

Similarly, here’s how my options would look if I want to log old character data:

options = {
characterData: true,
subtree: true,
characterDataOldValue: true
}

See live demo  →

Notice the log messages indicate the previous value. Things do get a little wonky when you add HTML via rich text commands to the mix. I’m not sure what the correct behavior is supposed to be in that case but it is more straightforward if the only thing inside the element is a single text node.

Intercepting Mutations Using takeRecords()

Another method of the MutationObserver object that I haven’t mentioned yet is takeRecords(). This method allows you to more or less intercept the mutations that are detected before they are processed by the callback function.

I can use this feature using a line like this:

let myRecords = observer.takeRecords();

This stores a list of the DOM changes in the specified variable. In my demo, I’m executing this command as soon as the button that modifies the DOM is clicked. Notice that the start and add/remove buttons don’t log anything. This is because, as mentioned, I’m intercepting the DOM changes before they are processed by the callback.

Notice, however, what I’m doing in the event listener that stops the observer:

btnStop.addEventListener(‘click’, function () {
observer.disconnect();
if (myRecords) {
console.log(`${myRecords[0].target} was changed using the ${myRecords[0].type} option.`);
}
}, false);

As you can see, after stopping the observer using observer.disconnect(), I’m accessing the mutation record that was intercepted and I’m logging the target element as well as the type of mutation that was recorded. If I had been observing for multiple types of changes then the stored record would have more than one item in it, each with its own type.

When a mutation record is intercepted in this way by calling takeRecords(), the queue of mutations that would normally be sent to the callback function is emptied. So if for some reason you need to intercept these records before they’re processed, takeRecords() would come in handy.

Observing For Multiple Changes Using A Single Observer

Note that if I’m looking for mutations on two different nodes on the page, I can do so using the same observer. This means after I call the constructor, I can execute the observe() method for as many elements as I want.

Thus, after this line:

observer = new MutationObserver(mCallback);

I can then have multiple observe() calls with different elements as the first argument:

observer.observe(mList, options);
observer.observe(mList2, options);

See live demo  →

Start the observer, then try the add/remove buttons for both lists. The only catch here is that if you hit one of the “stop” buttons, the observer will stop observing for both lists, not just the one it’s targeting.

Moving A Node Tree That’s Being Observed

One last thing I’ll point out is that a MutationObserver will continue to observe for changes to a specified node even after that node has been removed from its parent element.

For example, try out the following demo:

See live demo  →

This is another example that uses childList to monitor for changes to the child elements of a target element. Notice the button that disconnects the sub-list, which is the one being observed. Click the “Start…” button, then click the “Move…” button to move the nested list. Even after the list is removed from its parent, the MutationObserver continues to observe for the specified changes. Not a major surprise that this happens, but it’s something to keep in mind.

Conclusion

That covers just about all the primary features of the MutationObserver API. I hope this deep dive has been useful for you to get familiar with this standard. As mentioned, browser support is strong and you can read more about this API on MDN’s pages.

I’ve put all the demos for this article into
a CodePen collection, should you want to have an easy place to mess around with the demos.

Smashing Editorial
(dm, il)