A very interesting article by Akar Sumset that explains how gamification can work by showing the relationship between gamification, UX design, and BJ Fogg’s modern persuasion phenomenon, “mass interpersonal persuasion.”
The world around us is full of little things and experiences that shape us, our way of thinking, but also how we tackle our work. Influenced by these encounters, every designer develops their unique style and workflow, and studying their artwork — the compositions, geometry of lines and shapes, light and shadows, the colors and patterns1 — can all inspire us to look beyond our own horizon and try something new.
It really doesn’t take much to let your mind wander. Always remember to take a closer look at things around you; you’ll be sure to find inspiration in the little things2. But for now, let’s dig into another collection of brilliant illustrations and photographs.
Do you often find yourself having mental blocks? Why not get out a bit and attend an event? We’ve prepared a list of upcoming events that will help you make a shift in your mindset. Read more →3
DKNG got to create a poster for their favorite band Radiohead playing at the iconic Greek Theater in Berkeley, CA. Beautiful geometrical design with superb dark shadows and light effects.
It’s a wonderful thing to get to see the imagination of an illustrator who thinks “imagining what it would be like to paddle a kayak on those serene sunset waters”… The colors and gradients used here to reflect the sunset are just so well done.
Those soft subdued tones and light really compliment the wild and remote feeling of this scene. Composed perfectly as well with just one inclusion of the person.
If you’re like me, then being persuaded requires a scientific approach and concrete examples. And that’s exactly what this article does. It explains how gamification can work by showing the relationship between gamification, UX design, and BJ Fogg’s modern persuasion phenomenon, “mass interpersonal persuasion.” And it has a lot of practical gamification examples that you can apply to your own products for more engaging experiences.
Today, virtually all companies (except for special ones like Basecamp1) have to grow non-stop. Why? Well, that’s simply how the capitalist engine works. Investors pour money into startups, banks loan money to entrepreneurs, employees accept stock options instead of cash, all in the hope of the company growing much bigger. That’s why there is so much emphasis on growth. Otherwise, the whole system would collapse. It’s kind of crazy when you think a bit more deeply about it, but I’ll leave that part to you for now.
What we call “growth” in the tech world is called “persuasion” in academia. With this article, I want to show why gamification is a great tool for growth and how persuasion science (more precisely, the “mass interpersonal persuasion” phenomenon) proves that. I’ll do that with examples and facts. Let’s get going.
Not only can gamification help sell your products better, but it can also be used to improve the user experience of your websites and apps. Read more →2
Two Misnomers: “User Experience Design” And “Gamification” Link
I think a lot about words, their meanings and how they shape our perception. This is of special importance to us UX and product people because we’re flooded with jargon. Let’s look at the following example to better understand the importance of words.
“UX is not UI” is a common reproach, and it is correct. Thanks to this famous photograph above, we now better understand that UX is not UI. But UX — or, more precisely, user experience design — is not usability either, as implied in the photograph. It requires an understanding of business goals as well as user needs and satisfaction of both, in a coherent fashion. But because the term “user experience design” does not imply anything about business, nobody talks about business. Daniel Kahneman, Nobel Prize winner in Economics, has a term for this phenomenon: What you see is all there is4. We do not see “business” in user experience design, so it becomes all about users.
5Motivation and gamification, from Michael Wu of Lithium.
Gamification is another victim of misnaming. Contrary to popular belief, it does not entail users playing or giving them points. Yes, those are useful components, but not the whole thing. The purpose of gamification is not to make people have fun, either. The purpose is to use fun to motivate people towards certain behaviors. Motivation is the key here. As shown6 above by Michael Wu, motivation and game components are in parallel. That’s why we use gamification to motivate users. If that parallel were provided by something else — say, biology — then we’d use biologification to motivate users.
So, what is gamification? One of my favorite definitions comes from Juho Hamari7 of Tampere University of Technology:
Gamification is a process of enhancing a service with affordances for gameful experiences in order to support user’s overall value creation.
Gamification is the process of making activities more game-like. In other words, it covers coordinated practices that objectively manifest the intent to produce more of the kinds of experiences that typify games.
As much as I like the definitions above, I still miss the emphasis on motivation and behaviors. So, here goes my definition of gamification:
Gamification is about using game-like setups to increase user motivation for behaviors that businesses target.
Naturally, my definition resembles user experience design. It does that by mixing the first two definitions. I’ve tried to convey how gamification satisfies users and businesses at the same time. I am not sure which definition is the most accurate, but I know this for sure: We have been playing games since we lived in caves, and we enjoy them for some reason. It’s only sensible to get inspiration from games, be it for business, education or something else.
If we want to understand persuasion9, then we should understand, before anything else, that people are predictably irrational10. Predictably irrational means that, even though people do not behave rationally most of the time, there are still patterns in this irrationality that help us predict future behaviors. This is why logic alone is not enough to persuade people. If people were consistently rational beings, then we would be living in a completely different world. For example, TV ads would merely consist of logical statements instead of gorgeous video productions. Coca-Cola ads would be like, “Coca Cola > Pepsi,” and Sony’s famous “Like no other” slogan would turn into “Sony !≈ anything else.”
Persuasion requires understanding neurology, psychology, biology, technology… a lot of “-ologies”. But arguably, the most important of all these ologies is technology, thanks to the unprecedented advancements in Internet and mobile in the last decade.
This phenomenon (Mass Interpersonal Persuasion) brings together the power of interpersonal persuasion with the reach of mass media. I believe this new way to change attitudes and behavior is the most significant advance in persuasion since radio was invented in the 1890s.
Bear in mind that, from a scientific point of view, persuasion is an umbrella term13 for affecting people’s attitudes, behaviors, intentions or beliefs. It does not necessarily require changing people’s beliefs or ideas.
Let me give you an example.
My father, 62 years old, has always been critical of iPhones because he finds the prices unreasonable — not because he cannot afford one, but because an iPhone 7 Plus (256 GB) costs almost four times the minimum wage in Turkey, where we live. But he bought an iPhone 7 for himself last month. How come? Well, for a year or so, he has been telling me how his friends have these big-screen phones and show him pictures of their grandchildren. Eventually, he got fed up with not being able to do the same and bought an iPhone 7. (All he needs now is a grandchild… sigh!) He still finds it expensive, but he bought it anyway. His idea did not change, but his behavior did. That’s what we call persuading without changing beliefs.
Mass Interpersonal Persuasion And Gamification Link
In 2007 a new form of persuasion emerged: mass interpersonal persuasion (MIP). The advances in online social networks now allow individuals to change attitudes and behaviors on a mass scale.
This is how BJ Fogg defines MIP14. The advances he mentions in the definition start with the launch of Facebook Platform in 2007. Facebook Platform is an aggregation of services and products available to third-party developers so that they can create games, applications and other services using Facebook data. Facebook’s success triggered other platforms to provide similar services. Fast-forward to today: We are living in an era when we type passwords no more, thanks to sign-in with Facebook, Google and Twitter. Or, if we want something more advanced, we can get a personality analysis15 just by providing our Twitter handle. For an example that’s even more advanced — and scary — we can look at the debates on Facebook’s alleged influence on the latest US elections16. This is how powerful social platforms are today.
MIP consist of six components. To better understand MIP and its connection to gamification, let’s look at what they are, one by one, with examples.
The following quote (and the remaining ones in this article) is taken from BJ Fogg17:
An experience that is created to change attitudes, behaviors, or both.
The key here is the intentionality to change behaviors or attitudes by providing experiences, as opposed to just stating facts and expecting people to be reasonable enough to change their behaviors or attitudes accordingly.
Now, let’s remember our definition of gamification:
Gamification is using game-like setups to increase user motivation for behaviors that businesses target.
Similar to MIP, gamification is quite intentional about changing behaviors. It does that by focusing on the entirety of the users’ experience to find the relevant spots where it can blend in the experience and do its magic. A great example of this is Sweden’s Speed Camera Lottery. The Speed Camera Lottery is a simple solution. If you do not drive over the speed limit, then you instantly get a chance to participate in a lottery. Even funnier is that the winnings comes from the fines paid by speeders.
To better understand the intentionality behind behavior change, let’s compare the Speed Camera Lottery with the campaign of New York City’s Department of Transportation (NYC DOT).
NYC DOT’s campaign is quite impressive, with its powerful visual and message. “Hit at 40 mph: There’s a 70% chance I’ll die. Hit at 30 mph: There’s an 80% chance I’ll live.” It’s hard to compare these two campaigns because the cultures in these two countries differ quite a lot, and NYC DOT’s campaign encompasses a lot of different initiatives, such as new traffic signals, speed bumps, and pedestrian walkways. However, when viewed from a purely behavioral science point of view, the Speed Camera Lottery is more likely to influence the behavior of obeying the speed limit. Why?
The NYC campaign favors an indirect way of influencing behavior. It’s very influential when we see it, but it is not there when we actually need to slow down. Unlike the NYC DOT ad, the lottery solution is implemented right when and where speeding happens.
NYC DOT’s campaign does not create an experience. It’s an example of a classic one-way communication. You see it and it’s gone. With the Speed Camera Lottery, we get a chance to participate and, thus, have an experience.
The Speed Camera Lottery is more fun than the NYC DOT’s campaign because the former is a well-gamified campaign and the latter is basically an informative ad.
That being said, though highly successful (reducing the average speed by 22%20), the Speed Camera Lottery had one downside. Some geniuses started circling around to increase their likelihood of winning the lottery. Well, that did not quite work out for them, but we should always be wary of cheaters.
Digital technology structures the persuasive experience.
We saw how the core of gamification is to create persuasive experiences with the first component of MIP. Now let’s look at the link between gamification and automated structures.
By design, gamification produces well-structured processes. Regardless of what product we are building, we need a tool to quantify behaviors to even start with gamification. Think of something similar to Google Analytics or MixPanel. For behavior tracking to be useful, we do not just count how many people perform a certain behavior, but rather define rules like, “If a user clicks five help links in a session, then open the chat window.” Gamification, by nature, is built on top of these kinds of rules:
Automated feedback: “If a user logs in for five consecutive days, then show them a message to congratulate them on their consistency.”
Points: “If a user invites a friend, then reward them with 5 points.”
Levels: “If a user collects 1000 points and receives 5 likes, then bump them up to level 3.”
We could easily add more examples to the list. Obviously, these are very simple examples, but the point is that gamification is inherently based on rules. That’s why it is very easy to build an automated structure to create a persuasive experience using gamification.
I did gamification design for FitWell23, an app that tailors meal plans and workout regimens according to the app’s assessment. Our research showed that the most important problem people encounter during their fitness journey is that they lack feedback after a while. At the beginning, we feel energized, see changes in our posture and, thus, feel motivated. After a while, though, progress slows, and we start worrying that our efforts are accomplishing nothing. That’s where gamification comes into play. With a lot of automated feedback loops, users get various encouraging feedback when their body fails to provide any.
Duolingo takes the automated experience a step further with “Shop.” Thanks to the shop, not only do I get feedback on my progress, but I also get to reward myself with Lingots (the in-app currency) all by myself.
Yes, we do not have to gamify our products to provide these kinds of experiences, but it is much easier if we do. Gamification forces us to think of actions and feedbacks that, by nature, produce an automated structure.
The persuasive experience is shared from one friend to another.
We just saw how gamification helps us with automating persuasive experiences. Now let’s see how gamification fuels social distribution.
Just four words: “Invite friends, earn money!” Money here is a variable. It could be anything from free disk space to an invitation to that new cool app. The key here is that it always involves friends and some kind of reward.
Do you remember the days when Inbox came out? Did you too harass your friends for an invitation, like my friends did to me?
Gmail had more than 500 million users when Inbox was released as an invitation-only product. So, obviously, Inbox was not after acquisition. But what was it after?
Adoption. This is why it turned the social distribution scheme upside down. Instead of rewarding people with money or free disk space, it rewarded people with the privilege of having invitations. Those privileged people (the innovators and early adopters33) were already going to try Inbox. By giving innovators and early adopters a higher status, Google turned them into a distribution tool. Limited access made the early majority crave for Inbox, which in turn both accelerated adoption and increased the satisfaction of those lucky enough to use Inbox.
Has it worked for Google? I don’t know the exact numbers, but the screenshot above, along with insights from an ex-Google product manager34, are key signals that it worked out very well for Google.
Speaking of the “Invite people and earn X” tactic, I have this friend who subscribed to a healthy-eating service that gives free meals in exchange for invitations. Following this tactic, he eventually had to cancel his subscription because he brought on too many people and ended up gaining more weight!
What this means is that the time between invitation, acceptance, and a subsequent invitation needs to be small.
On a more abstract level, rapid cycle can be restated as follows:
What this means is that the time between action, feedback, and a subsequent action needs to be small.
When viewed like this, Nir Eyal’s hook model35, the most important tool in my gamification toolbox, perfectly matches rapid cycle. ‘Hook’ is Nir’s explanation for why some products are so habit forming. Simply put, we get motivated if we get positive and instant feedback for our behaviors. Even better, if we get a chance to take a further step, we get even more motivated.
I won’t explain the whole hook model here, but here is the gist:
Hook has its roots — surprise, surprise — in BJ Fogg’s behavior model37, which explains how behavior occurs. BJ Fogg shows that we need a trigger, motivation, and ability to perform a behavior.
On top of Fogg’s behavior model, Nir Eyal adds a variable reward, so that people keep coming for more.
And Eyal asks for an investment behavior, which increases the user’s expectation of even more rewards in the future.
The persuasive experience can potentially reach millions of people connected through social ties or structured interactions.
Having millions of users is not enough for MIP to happen. What you need is millions of connected people, and the nice part is that they do not have to be your users either. You need the potential to reach millions. How? Well, for one, there are social networks. Use social log-in and leverage your users’ networks on those platforms. But that is not the only way. Suppose you have a SaaS analytics product. How can you reach millions? Provide Google Analytics integration and voilà! Now you’re relevant to millions of people.
Let’s look at how gamification helps connect people.
Quora suggests people with related expertise when we ask a question. This is an amazing solution. Why?
It helps us get answers much faster and from reliable sources.
It honors people who get asked to answer, which gets them motivated and engaged. (A common phrase on Quora is, “Thank you for A2A.”)
The combination of points 1 and 2 increases high-quality content, engagement and connectedness on Quora.
And this is all possible thanks to a very simple game mechanic: mastery. None of this would work if Quora did not have those domain experts.
Example: Yemeksepeti
42Yemeksepeti is Turkey’s Delivery Hero, acquired by the actual Delivery Hero for $589 million. (View large version43)
This example is from my hometown — hence, the language in the photo. Yemeksepeti is the Turkish version of Delivery Hero. They recently introduced a “muhtar” feature. Muhtar means “headman” in Turkish. A muhtar knows everyone and every detail about a neighborhood. So, the one with the most points in a neighborhood becomes the muhtar. As you can see, Alper G. is the muhtar in my neighborhood (the list on the right is the leaderboard).
I’ve been using Yemeksepeti for more than five years, and this is the first time I’ve been more curious about the people using it than about the restaurants on Yemeksepeti. The reason is the muhtars. Not only does it show who a neighbourhood’s muhtar is, but it also shows their recent orders and what other participants are doing on Yemeksepeti. The muhtar feature provides the basic social-proof mechanism that Yemeksepeti needed. It helps greatly with making faster decisions and increases the credibility of the restaurants’ scores. (People score a restaurant after a delivery, similar to scoring an Uber driver.)
The Muhtar feature also paves the way for Yemeksepeti to introduce its own version of A2A. I don’t know if they plan to do this (although it’s one of the ideas we presented to them four years ago), but they could surface experts who help others answer the toughest of all questions: “What should I eat?”
That’s the power of gamification. By introducing competition (or collaboration, as we saw with Quora), it makes socialization possible on a very large scale without people actually having to know each other.
The effect of the persuasive experience is observable by users and creators.
One of the core components of gamification is quantification of what users do and of the things happening around them. This way, gamification makes everything measurable by nature. Even the tiniest of behaviors are quantified and presented in various ways, sometimes as raw data, other times as points, levels or progress bars. Let’s look at some examples.
Medium and Quora are very different in how people create content, but in the end, it is content they create. That’s why it is not surprising to see that almost identical statistics are provided.
Similar to MIP’s persuasive experience component, good gamification always directly targets behaviors and blends in the experience.
MIP relies on automated structures, and gamification relies on behavior-based rules, which makes it extremely easy to build automated structures.
MIP requires social distribution, and gamification responds to this with a killer feature: Invite friends and earn money, disk space, beta participation etc. This is an old gamification practice and a powerful social-distribution tool. And you do not always have to give away “stuff.” Giving away status works, too.
Rapid cycles are at the heart of MIP. They are at the core of gamification, too, as shown by Nir Eyal’s hook model. People get motivated when the feedback for their behavior is instant. To take it a step further, try to make the feedback variable and the next step obvious.
Another important component of MIP is a huge social graph. Collaboration and competition mechanics make it easy to connect people to each other, even on the least likely of platforms.
Lastly, MIP requires people to be able to measure the impact of their behaviors. Gamification inherently requires measuring almost everything, which makes it extremely easy to make visible at all times.
Gamification aims to use fun in order to motivate users towards behaviors that businesses target. This approach satisfies both the user and the behavior, which is essential to good user experience design.
One by one, we saw how the six components of mass interpersonal persuasion relate to gamification, with examples. I chose well-known examples so that they would be easier to understand and relate to. However, I realize that this makes gamification design intimidating. You might be thinking, “Of course, Quora would do that — they have all of these great designers,” or, “Obviously, Nike would succeed — they have all of those technologies and tools”. Perhaps also, “What does MIP have to do with growth?”. Take a look at this:
Let’s go back to the fall of 2007 — a time when there was no WhatsApp, Instagram or Snapchat, when Twitter was a one-year-old baby, when Facebook announced its Platform. When BJ Fogg heard about Platform, he decided to start a new course to apply MIP principles to Facebook and measure the impact of the application of those principles. Grading was based on metrics on the Platform. There was no homework or quizzes. Students were graded based on the number of users they’ve reached and engaged through the apps they’ve built.
The numbers shown in the image above are the results of that course. The students, some of whom had no experience in coding, design or digital marketing, reached 16 million users in 10 weeks. And this happened in 2007. 2007 is the year when the first iPhone was unveiled. Think about it: Some of those apps generated so much revenue (more than $1 million in three months) that even the teaching assistant, Dan Ackerman, dropped out of school. Five of those apps made it to the top-100 apps on Facebook and reached more than 1 million users each.
So, if those students were able to design such successful experiences, why couldn’t you?
FullStory helps you build incredible online experiences by capturing every click, swipe, and scroll, then replaying sessions with pixel-perfect clarity.
In its move to patch a security hole as part of the iOS 10.3 release, Apple has introduced (yet) another redirection mechanism that developers must handle when attempting to implement mobile deep-link routing (i.e. the mechanism to route users to a specific page inside a mobile app, rather than the App Store or app home page).
This redirection instance has introduced additional friction to the app download and reopening process, and data shows that it has decreased conversion rates on iOS 10.3. This post examines the issue in detail and discusses solutions to help developers fix it.
You’ve launched your app and it’s doing well. So, how do you maintain that momentum and ensure that your app keeps gaining in popularity? Read more →1
With iOS 10.3, Apple has gifted the world powerful new features2, as well as fixes for critical security holes. For your typical iPhone user, it’s a really nice upgrade. For a software developer who is responsible for either a mobile website or a native app, it can be a huge pain.
Why? At some point in early 2017, a few enterprising scammers figured out how to hijack iOS Safari3 by abusing the custom URI scheme confirmation alert. This alert prevented user interaction until it was dismissed; so, the result of triggering it in an endless loop was essentially low-tech ransomware. Unfortunately, it was realistic enough to trick many users into paying up. In iOS 10.3, Apple fixed this security hole by changing the confirmation alert into a new non-blocking dialog. It looks like this:
From a user’s perspective, no big deal. For developers, there is a hidden change that has more important implications: the App Store had always received a special exemption from the old version of this alert, but that exemption has now been removed.
A basic deep-linking system for an app has two goals:
If the app is installed, open it and take the user to the content requested.
If the app is not installed, take the user somewhere else so they can download it.
Apple’s official deep-linking standard, “universal links,” is designed for the first case. It’s not perfect: Configuration is complicated, and there are many places (Facebook, Twitter and any app using SFSafariViewController, to name a few) where things don’t “just work.” But the user experience of deep-linking into an app is generally quite good once that app is installed. None of this has changed in iOS 10.3.
It’s the second case where iOS 10.3 makes things complicated. If a user doesn’t have your app installed, they have always ended up in Safari, looking at the web version of that link. You are then responsible for redirecting that user to download the app. Because Apple has not implemented universal links for the App Store, developers have had to rely on a custom URI scheme redirection. And a custom URI scheme redirect on iOS 10.3 now means an alert. Apple even does it this way itself: Just try visiting https://itunes.apple.com/us/app/airbnb/id4016262635 on an iOS 10.3 device, and you’ll run straight into the new confirmation dialog.
Here’s the situation. When a user clicks any link that leads to the App Store, iOS 10.3 will display a modal asking the user whether they’d like to go there. We’ve tested Apple’s appsto.re short links, full App Store long links, links from attribution providers and deep-linking platforms, and our own Branch-hosted deep links. There is no way around this new alert.
Why is this bad? There are actually two problems:
It’s an extra step.
Users don’t like extra steps, especially because downloading a new app is already relatively high-friction. Adding another tap certainly doesn’t help.
Users can press “Cancel.”
This is the much bigger problem. Pressing “Cancel” can leave users trapped on an empty page in Safari. Even worse, if they’ve come from another app and then go back to click the same link again, it’ll show this error message and do nothing:
You can’t avoid the alert. And the reality is that some users will click “Cancel,” either on purpose or by mistake. What you can do is give more context, to help visitors complete their journey if they fall off in the middle. I’m calling this a “second chance” screen, and it looks like this:
Yes, the new iOS 10.3 confirmation dialog is still there. But now we also have a friendly URL in Safari’s address bar, the app logo and name in the background, and a button that users can click to try again:
At Branch9, we pushed the first version of this second-chance screen live for all apps on the Branch platform within hours of discovering this new edge case in iOS 10.3. It has since become a widely adopted solution; here are just a few examples we have seen pop up in the last few weeks from various services:
All of these screens are solving the same basic problem: give visitors an escape hatch if they accidentally hit that “Cancel” button. It is still less than ideal, but the result works:
When the page loads, attempt to forward to the App Store. (JavaScript redirections like this are fully supported by Google14 and have no adverse effect on SEO.)
The redirection presents the confirmation dialog to the user.
If the user taps “Open,” all is good.
If the user taps “Cancel,” the rest of the template will have rendered in the background.
The user has unlimited opportunities to tap your download button. This displays the confirmation dialog again, but hopefully the user is now ready to continue.
However, I wouldn’t personally recommend building this solution yourself; you have better things to do than to constantly fix new edge cases like these from Apple, Google, Facebook, etc. If you’re using a hosted deep-link provider such as Branch or Firebase (with its Dynamic Links), then this edge case is already being handled for you. Attribution tools such as Adjust and AppsFlyer have also built similar workarounds for their paid tracking links.
We wanted to know how much this new confirmation alert actually affects download conversion rates. The Branch platform has millions of link clicks per day, across almost 25,000 apps, so we took a sample of this data from 2 May 2017. Here is what we found:
Safari does not allow clicks on this new “Cancel” button to be tracked directly. However, Branch can infer the number based on changes to other metrics that we measure, further down the funnel. In our sample, almost 19% of users were clicking it.
Installations Recaptured By Second-Chance Screen Link
The good news is that visitors still want your app — they are just getting confused by this new warning. When we give them another opportunity to click by showing a content preview with a download button, over 5% of our sample continued to install successfully.
Here is the bottom line: This new confirmation dialog is enough of a roadblock that almost a fifth of iOS users press the “Cancel” button. Even with a workaround enabled, the iOS 10.3 installation rate in our sample was about 2.25% lower than on iOS 10.2. Data shows that a second-chance screen helps, but some users still fail to make it all the way through to download.
From a more technical perspective, serving up a screen like this requires returning an HTTP 200 response, serving a page of content and waiting for the client to execute Javascript. The costs of adding just 100 milliseconds in latency are well known16, and sophisticated deep-linking implementations have long since moved to the far more efficient 307 redirection to reduce this redirection delay. Apple’s new iOS 10.3 behavior has broken this option, forcing the ecosystem to fall back on a slower, outdated solution.
Patching the original ransomware-esque custom URI exploit was the right thing for Apple to do, but the App Store is unlike any other platform. It is a core part of the iOS infrastructure. Applying such a flawed UX to a critical platform component is a costly decision.
With the early iOS 11 betas showing no change to this behavior, it seems possible we are stuck with a confirmation alert for the long haul. This makes it even more critical for you to offer your app’s users a fallback option. In the competitive mobile app world, having such an easy way to increase your installations is unheard of and is absolutely worth the small amount of effort it takes.
Component-based libraries or frameworks such as Vue have given us the wonderful ability to create reusable components1 to be spread throughout their respective application, ensuring that they are consistent, and (hopefully) simplifying how they are used.
In particular, form inputs tend to have plenty of complexity that you’d want to hide in a component, such as custom designs2, labels, validation, help messages, and making sure each of these pieces are in the correct order so that they render correctly.
Writing Reusable Modules in ES6
Are you excited to take advantage of new JavaScript language features but not sure where to start, or how? Read more →3
On top of that though, Vue has a built-in directive called v-model that simulates 2-way binding by binding a value and capturing input events. If you’re going to build a custom input component, then you’ll definitely want to support the v-model directive.
Sadly, when I looked around for examples of custom inputs in Vue for radio buttons or checkboxes, they either didn’t take v-model into consideration at all, or they failed to implement it correctly. There is some decent documentation for custom text inputs4, but since it doesn’t explain customizing radios or checkboxes, we’ll discuss that here.
This tutorial aims to help you…
Understand how v-model works on native inputs, focusing primarily on radios and checkboxes
Understand how v-model works on custom components by default
Learn how to create custom checkboxes and radios that emulate how v-model works on them natively
Quick note before we get started: ES2015+ code will be used throughout the code examples. I’ll also be favoring the Single File Component5 syntax over using Vue.component or new Vue.
The official Vue documentation6 is actually pretty good on this topic, but there are a few minor blind spots. In any case, we’ll be trying to cover it pretty thoroughly here.
In essence, v-model is just a shorthand directive that gives us 2-way data binding, and the code it is shorthand for depends on what type of input it is being used on.
When using a text input (including types such as email, number, etc.) or textarea, v-model="varName" is equivalent to :value="varName" @input="e => varName = e.target.value". This means that the value of the input is set to varName after each update to the input varName is updated to the value of the input. A normal select element will act like this too, though a multiple select will be different.
Note how v-model isn’t even touching value anymore. It’s still doing the same thing in the change event handler (though it was changed to change instead of input), but now it’s determining whether checked should be true or false depending on whether picked is the same as the value of that radio button.
Checkboxes are a bit more difficult to talk about because they have two different behaviors depending on whether there is only a single checkbox with a given v-model or multiple.
If you are using a single checkbox, v-model will treat it like a boolean and ignore the value.
If you want it to be something other than true and false, you can use the true-value and false-value attribute, which control what values your model will be set to when the checkbox is checked or not.
That’s pretty much it for single-checkbox examples. If you have multiple checkboxes that share a model, then those checkboxes will fill an array with values of all the checkboxes that are checked, but make sure the model that you pass in is already an array or you’ll get some odd behavior. Also, the true-value and false-value attributes no longer affect anything.
That’s a lot more complicated than what we’ve seen before, but if you break it down, it’s not too bad. shouldBeChecked is true when that checkbox’s value is included in the array and false if it isn’t. updateVals adds the checkbox’s value to the array when it gets checked and removes it when it gets unchecked.
Since Vue doesn’t know how your component is supposed to work, or if it’s trying to act as a replacement for a certain type of input, it treats all components the same with regards to v-model. It actually works the exact same way as it does for text inputs, except that in the event handler, it doesn’t expect an event object to be passed to it, rather it expects the value to be passed straight to it. So…
v-model will look at these properties and instead of using the value attribute, it’ll use the attribute you specify in prop and instead of listening for the input event, it’ll use the event you specified in event. So the above my-custom-component example would actually expand out to the following:
This is nice, but if we’re making a custom radio or checkbox, this doesn’t work very well. With some work, though, we can move the logic that v-model uses on radios and checkboxes inside our custom components.
Compared to a checkbox, custom radios are quite simple. Here’s a very basic custom radio that I build that just wraps the input in a label and accepts a label property to add the label text.
Note: I only included props that are helpful for explaining how these should work with v-model, but input tags can take advantage of several other attributes (such as name or disabled), so make sure you create all of the props you’ll need and pass them on to input. You’ll also want to consider accessibility by adding WAI-ARIA attributes7, as well as using slots8 for adding content rather than props like I did here with label.
You may think that since I didn’t include name in this example, a group of radios wouldn’t actually sync up with one another. Actually the updating of the model will in turn update the other radio buttons that share that model, so they don’t need to share a name like they do in plain HTML forms as long as they share the same model.
Making custom checkboxes is noticeably more complex than the radio buttons, primarily because we have to support two different use cases: a single true/false checkbox (that may or may not use true-value and/or false-value) and multiple checkboxes that combine all the checked values into an array.
So how do we determine which use case it is? You might think that we need to determine if there are other checkboxes with the same name attribute, but that’s not actually what Vue’s built-in system uses. Just like the radios, Vue doesn’t take the name attribute into consideration at all. That’s only used when natively submitting a form. So then you might think it determines it based on whether there are other checkboxes that share the same model, but that’s not it either. It’s determined by whether or not the model is an array. That’s it.
So the code will be structured similarly to the custom radio button’s code, but inside shouldBeChecked and updateInput the logic will split depending on whether or not modelValue is an array.
<template> <label> <input type="checkbox" :checked="shouldBeChecked" :value="value" @change="updateInput"> {{ label }} </label> </template> <script> export default { model: { prop: 'modelValue', event: 'change' }, props: { value: { type: String, }, modelValue: { default: false }, label: { type: String, required: true }, // We set `true-value` and `false-value` to the default true and false so // we can always use them instead of checking whether or not they are set. // Also can use camelCase here, but hyphen-separating the attribute name // when using the component will still work trueValue: { default: true }, falseValue: { default: false } }, computed: { shouldBeChecked() { if (this.modelValue instanceof Array) { return this.modelValue.includes(this.value) } // Note that `true-value` and `false-value` are camelCase in the JS return this.modelValue === this.trueValue } }, methods: { updateInput(event) { let isChecked = event.target.checked if (this.modelValue instanceof Array) { let newValue = [...this.modelValue] if (isChecked) { newValue.push(this.value) } else { newValue.splice(newValue.indexOf(this.value), 1) } this.$emit('change', newValue) } else { this.$emit('change', isChecked ? this.trueValue : this.falseValue) } } } } </script>
And there you have it. It may be better, though, to split this into two different components: one for handling the single true/false toggle and one for use in lists of options. That would allow it to more closely follow the Single-Responsibility Principle, but if you’re looking for a drop-in replacement to checkboxes, this is what you’re looking for (plus the addition of all the other useful attributes and custom features you might want).
There’s plenty more to learn about Custom Inputs, Vue Components, and Vue in general. I recommend giving some of these resources a look-through.
Awesome-Vue’s Component Sets9 – Awesome-Vue is a huge list of Vue-related projects and resources, so feel free to peruse anything and everything on that list, but in particular I want to point out the UI Libraries and Component Sets because they pretty much all have examples of Checkboxes and Radios you can look at if you feel like diving into their source code.
Vue Curated10 – This is a list similar to Awesome-Vue, but is more strictly curated so you know that everything on the list is worth taking a look at.
Vue Component Guide11 – The official Vue guide is a great place to learn the basics about anything related to Vue.
Vue API Documentation12 – This documentation is where you get into the really deep details of Vue.
Could there be a better way to welcome the new month as with a tidy desktop and a fresh wallpaper? Well, we’ve got you covered. To help you start into August freshly inspired, artists and designers from across the globe once again1 challenged their artistic skills to create unique desktop wallpapers for you to indulge in — wallpapers that are a bit more distinctive as the usual crowd.
All wallpapers in this collection can be downloaded for free and come in versions with and without a calendar — to keep your deadlines always in sight or to stick to your favorite wallpaper even after the month has ended. A big thank-you to everyone who shared their artworks with us! Now it’s up to you to decide which one will become your August companion.
Please note that:
All images can be clicked on and lead to the preview of the wallpaper,
You can feature your work in our magazine2 by taking part in our Desktop Wallpaper Calendars series. We are regularly looking for creative designers and artists to be featured on Smashing Magazine. Are you one of them?
“Many people find August one of the happiest months of the year because of holidays. You can spend days sunbathing, swimming, birdwatching, listening to their joyful chirping, and indulging in sheer summer bliss. August 8th is also known as the Happiness Happens Day, so make it worthwhile.” — Designed by PopArt Studio7 from Serbia.
“During bright summer days, while wandering around unfamiliar places, it is finally forgotten that one of the biggest human inventions is time itself, future becomes the past, past becomes the present and there are no earthly boundaries, just air.” — Designed by Ana Masnikosa97 from Belgrade, Serbia.
“Melon Day (second Sunday in August) is an annual national holiday in Turkmenistan devoted to festivities to celebrate the country’s muskmelon. Another reason for me to create this wallpaper is that melons are just awesome!” — Designed by Melissa Bogemans226 from Belgium.
“The best rides of our lives come along only once in a while. Don’t wait for it. Sometimes you just have to ride the wave you’re given!” — Designed by PlusCharts269 from India.
“La Tomatina is a food fight festival held on the last Wednesday of August each year in the town of Bunol near Valencia in Spain. Thousands and thousands of people come from all corners of the world to participate in La Tomatina, which is known as the ‘biggest food fight’, where more than one hundred metric tons of over-ripe tomatoes are thrown on each other in the streets.” — Designed by Suman Sil314 from India.
“When I think of August I think of vacation. August is the last month of summer break in Belgium so that’s why I like travelling then to enjoy that last month. I like visiting countries where the weather is pretty hot and that’s why I decided to draw a wallpaper where you are basically on the road to the sun.” — Designed by Senne Mommens345 from Belgium.
“In Melbourne it is the last month of quite a cool winter so we are looking forward to some warmer days to come.” — Designed by Tazi360 from Australia.
“Let us take a pledge to save these endangered species and create a world that is safe for them to live and perish just like all creatures.” — Designed by Acodez IT Solutions385 from India.
“The warm, clear summer nights make me notice the stars more — that’s what inspired this space-themed design!” — Designed by James Mitchell430 from the United Kingdom.
“Moments in life comes with hiccups and hitches, and so it remains unpredictable all along. There are always things you must meet in your day to day life, being afraid or running backward won’t take those away from you. In a nutshell, it’s a box full of new challenges, new thrills, new problems and new solutions, and so what we are left with is our perspective to deal with it! Face each moment until it concludes to be your last, with valor, attitude and a sturdy charm. Meeting the situations are mandatory, the thing that counts is how you face it, be yourself!” — Designed by Sweans451 from London.
“Photography is a way of feeling, of touching, of loving. What you have caught on film is captured forever. It remembers little things, long after you have forgotten everything. Applauding all the photographers who are capable of capturing what your eye cannot see on this World Photography Day.” — Designed by Areva Digital496 from India.
“Liqiu signifies the beginning of autumn in East Asian cultures. After entering the Liqiu, the mountains in Eastern Taiwan’s East Rift Valley are covered in a sea of golden flowers, very beautiful. The production season for high-mountain daylilies is in August. Chihke Mountain, in Yuli Township, and Sixty-Stone Mountain, in Fuli Township, which are both located in Hualien County, are two of the country’s three high-mountain daylily production areas.” — Designed by Hong, Zi-Qing537 from Taiwan.
“Janmashtami – day The Lord Krishna was born —, an important Hindu Festival which is celebrated worldwide. The idea was to create the Lord Krishna’s playing flute persona, in the minimalist design form.” — Designed by Damn Perfect556 from Jaipur, India.
“Buon giorno! (That’s ‘hello’ in Italian.) My name is Anopheles and yes, I’m a member of the much-feared Malaria Mafia. I’m sure you would have heard of us. I’ve something to tell you, lean closer… You know, every 30 seconds, a person dies from malaria and yes, we alone are responsible for that! No matter how long your clothing, no matter how secure your mosquito net, and no matter how high you climb, we will find you, suck your blood and cover your body in enormous, itchy welts! Wait a minute; you are going to celebrate the World Mosquito Day on August 20th? No worries, we will be there with you, as your beating heart!” — Designed by IPIX Technologies601 from India.
“Visitors to DC’s iconic Washington Monument in the sweltering August heat might wish it were a giant popsicle. For now, we’ll just imagine it that way. Here’s hoping everyone beats the heat!” — Designed by The Hannon Group642 from Washington, DC.
“In a world that get’s more divided each day, it is really important to understand that even if we are different we could all play together and have fun.” — Designed by Maria Keller741 from Mexico.
“Some colors are energetic, while others are much more calming and relaxing by nature. This summer, add some color to your life!” — Designed by StarAdmin Free Bootstrap Admin Template794 from India.
“One of my favourite books, ‘The Railway Children’, inspired me to create this wallpaper. August the 15th marks the birthday of E. Nesbit who wrote this brilliant classic! I even included an inspirational quote from the book.” — Designed by Safia Begum821 from the United Kingdom.
“This will be my final semester of grad school, and the last time August will mean back to school for me.” — Designed by Caitey Kennedy840 from the United States.
Please note that we respect and carefully consider the ideas and motivation behind each and every artist’s work. This is why we give all artists the full freedom to explore their creativity and express emotions and experience throughout their works. This is also why the themes of the wallpapers weren’t anyhow influenced by us, but rather designed from scratch by the artists themselves.
Do you ever wish you had a time machine? I certainly do, but not for the usual reasons. I want a time machine so I can go back and have a frank conversation with my younger self. I’ll let you in on a bit of a secret: My younger self was an idiot!
I have been working on the web for over 22 years now, and I feel like I wasted so many of those years. If only I could go back and share a few hard truths with myself at the start of my career. Unfortunately, I cannot, but I can share that advice with you.
Admittedly, you are almost certainly not as idiotic as I was. But hopefully, there will be something in this advice that inspires you.
Speaking of inspiration, that leads me nicely into my first piece of wisdom!
I used to be a dedicated follower of fashion who wasted so much time looking at other “cool” websites and browsing galleries of inspirational websites. My design style would morph to embrace the latest trends, from Web 2.0 to hero banners.
The result of this was bland “me too” design. But worst of all, it never put the user first. It was all about making something look good in my portfolio.
1 Look for inspiration beyond the web. Look to art, architecture and print design. (View large version2)
It was such a waste because so much inspiration is all around us: great books on classic print design, architectural trends, even airport signage (a personal obsession of mine).
Don’t make my mistakes. You don’t even have the luxury of my excuses. With CSS grid3, the possibilities are endless, and we should all embrace them.
On the subject of latest trends, that brings me to my next transgression: obsessing over tools.
We’ve wasted hours arguing over what tool is best. Should we code in PHP or classic ASP? (Yes, I am that old.) Can I be a “proper” web designer and code in Dreamweaver? Which content management systems should we use? The list went on.
Some tool or other would become trendy for whatever reason, and we would all jump on the bandwagon, until the next one emerged, and we jumped to that after an even more furious debate.
I see the same today: arguments over frameworks4 and whether we should embrace Angular or React. I don’t follow these discussions anymore because somewhere along the line I realized something: There is no single answer.
5 Do not become overly attached to a single tool. Tools come and go, and no one will be appropriate for every project. (View large version6)
A lot of these choices come down to personal preference or the requirements of the individual client. Remain flexible and open to change. If you don’t, you’ll go the way of Flash developers.
All of that time I wasted arguing about tools would have been so much better spent elsewhere, like on improving my soft skills.
I was an insufferable know-it-all when I was young. I always had the answers and always knew a better way to do something. I am sure you are not like that, although, let’s be honest, how would you know if you were? I certainly had no idea how irritating I was, despite the warning signs.
For a start, I found myself constantly arguing with everybody. Everything seemed like a battle because nobody around me “got it.” In hindsight, that was because I was too busy irritating everybody to take the time to explain things properly. But at the time, it just felt like everybody else was stupid.
I wish I had realized how weak I was in this area. Perhaps then I would have invested time and energy in improving how I worked alongside other people. Maybe I would have listened more and put the same effort into understanding my colleagues as I did my users.
I am not suggesting I should have done this necessarily to be a good man (trust me, I am not now). Instead, I should have done this because it would have made my life so much easier. I wasted endless time arguing and alienating people, people I needed on my side to do my job. It was incredibly frustrating.
7 We spend a lot of time debating whether designers should learn to code, when perhaps we should be worrying about other skills. (View large version8)
If I had developed that skill of working with people earlier, it would have also allowed me to push beyond the confines of my role.
I confess that, for many years, I was a bit of a job’s worth. I was a designer, and I spent much of my working life complaining because other people weren’t doing their jobs properly. Clients failed to deliver copy, developers didn’t implement my designs correctly, and project managers were always putting unrealistic constraints on me.
To be fair to my younger self, these were all real problems. But I did nothing but moan about them. I made no effort to help my colleagues fix these issues. I never questioned why the client was failing to deliver content or why the project manager seemed so unreasonable? I didn’t bother to understand the constraints they faced.
When I did eventually wake up and start paying attention, I discovered a bigger world. I found out just how interconnected digital and the user experience are, and how many things beyond the screen influence the experience.
I learned so much over that time, and you can, too. Take the time to understand the roles of those around you. Understand their challenges and constraints. Understand their perspectives and motivations. This will not only improve your working relationship, but make you better at your job, too.
9 Seek to understand colleagues just as you would a user. You could even consider creating empathy maps for them! (View large version10)
If you are a designer, this will enhance your designs, making them more useful in the “real world.” If you are a developer, you will understand the challenges users face and the impact you have on the user experience11. And so it goes on.
Ultimately, this will make you better at your job and hopefully progress your career. But a successful career is about more than being good at your job.
You could be the best designer or developer in the world, but if nobody has heard of you, you will have little success. That probably isn’t right or fair, but that is the reality.
I’ll be honest with you: Many people are far better at their jobs than me. But I speak all around the world, write books and have built a significant following, not because I am good at what I do, but because I put myself out there.
But it took me so long to realize that. I wasted years moaning about how it was unfair that other people got to write and speak and how my ideas were just as good as theirs.
Eventually, it twigged that I didn’t need anybody’s permission to start sharing my thoughts. I could write on a blog without a publisher and speak on a podcast without a conference.
You can, too. Not only that, you should! If you are not sharing what you have learned, you are invisible, and that will hamper your career.
12 You don’t need to be invited to speak at a conference to start sharing your ideas.
You might feel you have nothing new to say. Don’t worry, just share what you have learned. There will always be people who haven’t learned those lessons yet.
You might feel nobody is listening. Again, don’t worry. If you persevere, eventually people will start paying attention. I’ll let you in on a secret: Quality is not the number one reason for success. Consistency is. Even second-rate content will draw attention if you release it regularly enough.
Put yourself out there, in whatever way you choose. It will enable you to build contacts in the industry. That will help you avoid the last mistake my younger self-made: wasting too many years working for appalling bosses.
I worked for some truly nasty people, ranging from the incompetent to the criminal. Two ended up in prison, and the only good guy I ever worked for died of a heart attack due to stress!
I wasted years working for these people, years of them undervaluing my work and failing to invest in enabling me to do it better. Admittedly, I could be a bit of an idiot, as we have already established. But even with hindsight, these people were terrible. Unfortunately, apathy and fear prevented me from moving on.
Don’t make my mistake. There is no need. We are much in demand. Getting good digital staff is incredibly challenging, and you owe no loyalty to a boss who doesn’t value your expertise.
Instead, find a company that is going to nurture you and help you grow in your career. I’ll be honest: I never achieved that. I never had a mentor or somebody to teach me. I stumbled my way through my career, and I think I am the poorer for it. So, don’t settle. You deserve better, and loads of great jobs are out there.
In these politically uncertain times, developers can help to defend their users’ personal privacy by adopting the Privacy by Design (PbD) framework. These common-sense steps will become a requirement under the EU’s imminent data protection overhaul, but the benefits of the framework go far beyond legal compliance.
Note: This article is not legal advice and should not be construed as such.
Let’s give credit where credit is due. The global political upheaval of the past 12 months has done more to get developers thinking about privacy, surveillance and defensive user protection than ever before. The risks and threats to ourselves, and to our users, are no longer theoretical; they are real, they are everyday, and they are frightening. One need only look at the ongoing revelations regarding Cambridge Analytica, a British company with odd links to Canada, which ran a complex data-mining operation on behalf of Donald Trump’s presidential campaign to aggregate up to 5,000 pieces of data on every American adult1, to fathom what is at stake for all of us.
As developers and decision-makers, we need to do something to respond to that challenge. The political uncertainty we are living through obliges us to change the ways we approach our work. As the creators of applications and the data flows they create, we can play a critical and positive role in protecting our users from attacks on their privacy, their dignity, and even their safety.
One way we can do this is by adopting a privacy-first best-practice framework. This framework, known as Privacy by Design (PbD), is about anticipating, managing and preventing privacy issues before a single line of code is written. The best way to mitigate privacy risks, according to the PbD philosophy, is not to create them in the first place.
PbD has existed as a best-practice framework since the 1990s, but few developers are aware of it, let alone use it. That’s about to change. The EU’s data protection overhaul, GDPR, which becomes legally enforceable in May 2018, requires privacy by design as well as data protection by default across all uses and applications.
As with the previous EU data protection regime, any developer serving European customers must adhere to these data protection standards even if they themselves are not located in Europe. So, if you do business in or sell to Europe, privacy by design is now your responsibility.
This presents a monumental opportunity for developers everywhere to rethink their approach to privacy. Let’s learn what PbD is and how it works.
The PbD framework was first drawn up in Canada5 in the 1990s. Its originator, Dr. Ann Cavoukian, then Privacy Commissioner of Ontario, devised the framework to address the common issue of developers applying privacy fixes after a project is completed:
The Privacy by Design framework prevents privacy-invasive events before they happen. Privacy by Design does not wait for privacy risks to materialize, nor does it offer remedies for resolving privacy infractions once they have occurred; it aims to prevent them from occurring. In short, Privacy by Design comes before-the-fact, not after.
The PbD framework has seven foundational principles:
Privacy must be proactive, not reactive, and must anticipate privacy issues before they reach the user. Privacy must also be preventative, not remedial.
Privacy must be the default setting. The user should not have to take actions to secure their privacy, and consent for data sharing should not be assumed.
Privacy must be embedded into design. It must be a core function of the product or service, not an add-on.
Privacy must be positive sum and should avoid dichotomies. For example, PbD sees an achievable balance between privacy and security, not a zero-sum game of privacy or security.
Privacy must offer end-to-end lifecycle protection of user data. This means engaging in proper data minimization, retention and deletion processes.
Privacy standards must be visible, transparent, open, documented and independently verifiable. Your processes, in other words, must stand up to external scrutiny.
Privacy must be user-centric. This means giving users granular privacy options, maximized privacy defaults, detailed privacy information notices, user-friendly options and clear notification of changes.
PbD has always been available for any developer to use as a voluntary best-practice framework. Its popularity has tended to be greater in cultures that have a traditionally positive view of privacy, such as Canada and many European countries. Privacy, however, is not traditionally seen as a positive value in the US, whose companies dominate the tech world. For this reason, and for too long, web development has been approached with what at times has felt like the complete opposite of a PbD viewpoint. It has almost become normal for developers to ship apps that require social media registration, that request unnecessary permissions such as microphone access and location data, and that demand access to all of a user’s contacts.
The notion of privacy by design as a voluntary concept is about to change.
In Europe, the regulation that governs all collection and processing of personal data, regardless of use, sector or situation, has had a complete overhaul. This new set of rules, known as the General Data Protection Regulation6 (GDPR), is already on the books but becomes legally enforceable on 25 May 2018. Your business should already be working towards your wider GDPR compliance obligations ahead of this deadline, which will come up fast.
Crucially, GDPR makes PbD and privacy by default legal requirements within the EU. Not only will you have to develop to PbD, but you will have to document your PbD development processes. That documentation must be made available to a European regulatory authority in the event of a data breach or a consumer complaint.
Remember that European data protection and privacy laws are extraterritorial: They apply to the people within Europe whom data is collected about, regardless of where the service is provided from. In other words, if you develop for European customers, you must comply with EU data protection and privacy standards for those individuals, even if you yourself are not located within Europe.
Also remember that the EU, through its data protection system, has some of the strictest and most clearly defined privacy frameworks in the world; the US, by contrast, has no overarching data protection and privacy framework at all. Culture is important to remember as well. In Europe, privacy is considered a fundamental human right. Living and developing in a country where privacy is not a fundamental human right does not negate your moral or legal obligations to those who do enjoy that right.
Developers outside the EU, therefore, should consider adopting the PbD principles within the GDPR guidelines as a development framework, despite being located outside Europe. The guidelines will give you a clear, common-sense and accountable framework to use in your development process — and that framework is a lot better than having no guidelines at all.
The European data protection law defines personal data as any information about a living individual who could be identified from that data, either on its own or when combined with other information.
There is also a classification called “sensitive personal data”, which means any information concerning an individual’s
The data users generate within your app is personal data. Their account information with your company is personal data. The UID identifying their device is personal data. So is their IP address, their location data, their browser fingerprint and any identifiable telemetry.
For app developers, PbD compliance means factoring in data privacy by default
at your app’s initial design stage,
throughout its lifecycle,
throughout the user’s engagement with your app,
after the user’s engagement has ended,
and after the app is mothballed.
There is no checklist of ready-made questions that will get you there; General Data Protection Regulation requires developers to come up with the questions as well as the answers. But in a proactive development environment, the answers would likely take the practical forms required under GDPR, such as the following.
Good PbD practice, and its absence, is easy to spot if you know what you are looking for.
Let’s give this popular UK pub chain’s app a quick PbD audit.
The app has no settings page, which suggests no user control over privacy. This implies that downloading the app entails granting consent for data-sharing, which does not meet the second PbD principle.
This suggestion is confirmed in the “Edit Account” option, which only allows users to edit their name and email address. This does not meet the third PbD principle “Privacy must be embedded into design.”
The link to the privacy policy provides a blurry scan of a five-page PDF that is written for the outdated 1995 data protection directive. There are no user controls or granular options. If I wanted to exercise control over my data, I would have to write an email to a generic customer-service address or, alternatively — in the time-honored tradition of privacy policies that are really trying to fob users off — send them a letter in the post. This does not meet the seventh PbD principle of giving users granular privacy options with maximized privacy defaults.
The privacy policy informs me that my data will be shared with third parties but gives me no indication as to who those third parties are, nor does it give me the option to withhold that data sharing. There is no distinction between third parties whose services are necessary for the transaction (for example, PayPal) and unnecessary services, such as ad networks. This does not meet the sixth PbD principle.
But let’s say I write about this stuff for a living, and so I just really need a beer. I go to the pub and fire up the Wi-Fi to use its app. When I connect to the Wi-Fi, I notice its “Settings” page. That page merely provides links to three legal documents. As with the pub’s own app, there are no settings to change, no options and no choices. There is no PbD whatsoever.
It’s clear that the only way I can ensure my privacy with this pub chain is to not use the app or its Wi-Fi at all. This creates the zero-sum dichotomy, which the fourth PbD principle seeks to avoid.
This pub chain does not meet good PbD practice, or GDPR compliance, by any definition.
By contrast, Twitter’s recent privacy overhaul demonstrates very good PbD practice and early GDPR compliance. Here’s the catch: Its new privacy choices could have a detrimental and negative effect on users’ privacy12. The difference, however, is that it has been open and transparent and has given users educated choices and options.
The privacy overhaul offers a range of granular privacy options, which are clearly communicated, including a clear notice that it may share your data with third parties. Users can disable some or all options.
A prominent splash screen drew users’ attention to the changes, increasing the likelihood that they would take the time to educate themselves on their privacy options.
15 Twitter is clearly using a PbD framework well in advance of GDPR.
A privacy impact assessment (PIA) is simply a process of documenting the issues, questions and actions required to implement a healthy PbD process in a project, service or product. PIAs are a core requirement of GDPR, and in the event of a data protection issue, your PIA will determine the shape of your engagement with a regulatory authority. You should use a PIA when starting a new project, and run a PIA evaluation of any existing ones.
The steps in a PIA are as follows:
Identify the need for a PIA.
Describe the information flows within a project or service (user to service provider, user to user, service provider to user, user to third parties, service provider to third parties).
Identify the privacy- and data-protection risks.
Identify and evaluate the privacy solutions.
Sign off and record the PIA outcomes.
Integrate the outcomes into the project plan.
Consult with internal and external stakeholders as needed throughout the process.
Take some time to come up with a PIA template unique to your business or project that you can use as needed. The guidance from ICO16, the UK data-protection regulator, will help you to do that.
Good PbD practice gives users clear information and informed choices. Privacy information notices are central to that. The days of privacy policies being pages upon pages of dense legal babble, focused on the needs of the service provider and not the user, are over.
Your app, product or service should have a privacy information notice, including the following details:
What data are you collecting?
Why are you collecting it, and is that reasoning legally justifiable?
Which third parties are you sharing it with?
What third-party data are you aggregating it with?
Where are you getting that information from?
How long are you keeping it?
How can the user invoke their rights?
Include any information regarding the use of personal data to fulfil a contract.
Many European data protection regulators are devising standardized templates for privacy information notices, and you should check with yours to follow the progress on any required format ahead of the May 2018 deadline.
Under GDPR, the old privacy policy trick of stating “we may share your data with third parties” will no longer be considered compliant. GDPR and PbD require you to list exactly who those parties are and what they do with user data.
As one dramatic example, PayPal’s recent updated notice lists over 600 third-party service providers18. The fact that PayPal shares data with up to 600 third parties is not news. That information is simply being brought into the open.
Good PbD compliance is not just about UX. Healthy compliance also involves implementing adequate technical and security measures to protect user data. These measures, as with other aspects of full GDPR compliance, must be documented and made accountable to a regulator on request.
PbD compliance on a technical and security level could include:
password hashing and salting;
data sandboxing;
pseudonymization and anonymization;
automated background updates;
encryption at rest and in transit;
responsible disclosure;
staff training and accountability on data protection;
physical security of servers, systems and storage.
Under GDPR, companies processing certain kinds of data must appoint a Data Protection Officer (DPO), a named individual with legally accountable responsibility for an organization’s privacy compliance, including PbD. This requirement is regardless of a company’s size, which means that even the tiniest business engaged in certain kinds of data processing must appoint a DPO.
A DPO does not have to be in-house or full-time, nor are legal qualifications required. Very small businesses can appoint a DPO on an ad-hoc or outsourced basis. Check with your EU member state’s data-protection regulator for information on your national requirements for a DPO.
We would encourage all organizations to voluntarily appoint a DPO regardless of the nature of their work. Think of a DPO as the health and safety officer for privacy. Having someone act as the “good cop” to keep your development processes legally compliant — and acting as the “bad cop” if your practices are slipping — can save you from a world of troubles down the road.
The PbD framework poses challenges that only you can answer. No one else can do it for you: it is your responsibility to commence the process. If you are within Europe, have a look at your national data-protection regulator’s GDPR and PbD resources. If you are outside Europe, we have provided some links and resources below.
Don’t view PbD as a checklist of boxes to be ticked because “the law says so,” nor think of it as something you have to do “or else.” Instead, use PbD to think really creatively. Think of all the ways that your users’ data can be misused, accessed, stolen, shared or combined. Think of where data might be located, even if you might not be aware of it. Think of what liabilities you might be creating for yourself by collecting, retaining and aggregating data that you don’t really need. Think of how the third parties you share data with, even if they are your business partners, could create liabilities for you. And in our current political climate, think about the ways that the data you collect and process could be used to do harm to your users. There are no wrong questions to ask, but there are questions that it would be wrong not to ask.
Adopting PbD into your development workflow will create new steps to follow and new obligations to meet. These steps, as onerous as they might feel, are necessary in our rapidly changing world. So, view PbD as a culture shift. Use it as an opportunity to improve your policies, practices and products by incorporating privacy into your development culture. Your users will be better protected, your business’s reputation will improve, and you will be well on the road to healthy legal compliance. In an often bewildering world, if these steps are all we can take to make a difference one app at a time, they are worth a lot.
DeepScan is a cutting-edge static analysis tool for your JavaScript code including React, so you can develop JavaScript better, at lower cost, and more reliably.
Some people hate writing documentation, and others just hate writing. I happen to love writing; otherwise, you wouldn’t be reading this. It helps that I love writing because, as a design consultant offering professional guidance, writing is a big part of what I do. But I hate, hate, hate word processors.
My typical workflow using a desktop word processor goes something like this:
Select some text I want to copy to another part of the document.
Note that the application has selected slightly more or less than I told it to.
Try again.
Give up and resolve to add the missing part (or remove the extra part) of my intended selection later.
Copy and paste the selection.
Note that the formatting of the pasted text is somehow different from the original.
Try to find the styling preset that matches the original text.
Try to apply the preset.
Give up and apply the font family and size manually.
Note that there is too much white space above the pasted text, and press “Backspace” to close the gap.
Note that the text in question has elevated itself several lines at once, joined the heading text above it and adopted its styling.
Ponder my mortality.
When writing technical web documentation (read: pattern libraries1), word processors are not just disobedient, but inappropriate. Ideally, I want a mode of writing that allows me to include the components I’m documenting inline, and this isn’t possible unless the documentation itself is made of HTML, CSS, and JavaScript. In this article, I’ll be sharing a method for easily including code demos in Markdown, with the help of shortcodes and shadow DOM encapsulation.
Say what you will about CSS, but it’s certainly a more consistent and reliable typesetting tool than any WYSIWYG editor or word processor on the market. Why? Because there’s no high-level black-box algorithm that tries to second-guess what styles you really intended to go where. Instead, it’s very explicit: You define which elements take which styles in which circumstances2, and it honors those rules.
The only trouble with CSS is that it requires you to write its counterpart, HTML. Even great lovers of HTML would likely concede that writing it manually is on the arduous side when you just want to produce prose content. This is where Markdown comes in. With its terse syntax and reduced feature set, it offers a mode of writing that is easy to learn but can still — once converted into HTML programmatically — harness CSS’ powerful and predictable typesetting features. There’s a reason why it has become the de facto format for static website generators and modern blogging platforms such as Ghost.
Where more complex, bespoke markup is required, most Markdown parsers will accept raw HTML in the input. However, the more one relies on complex markup, the less accessible one’s authoring system is to those who are less technical, or those short on time and patience. This is where shortcodes come in.
Hugo3 is a static site generator written in Go — a multi-purpose, compiled language developed at Google. Due to concurrency (and, no doubt, other low-level language features I don’t fully understand), Go makes Hugo a lightening-fast generator of static web content. This is one of the many reasons why Hugo has been chosen for the new version of Smashing Magazine.
Performance aside, it works in a similar fashion to the Ruby and Node.js4-based generators with which you may already be familiar: Markdown plus meta data (YAML or TOML) processed via templates. Sara Soueidan has written an excellent primer5 on Hugo’s core functionality.
For me, Hugo’s killer feature is its implementation of shortcodes6. Those coming from WordPress may already be familiar with the concept: a shortened syntax primarily used for including the complex embed codes of third-party services. For instance, WordPress includes a Vimeo shortcode that takes just the ID of the Vimeo video in question.
The brackets signify that their content should be processed as a shortcode and expanded into the full HTML embed markup when the content is parsed.
Making use of Go template functions, Hugo provides an extremely simple API for creating custom shortcodes. For example, I have created a simple Codepen shortcode to include among my Markdown content:
Some Markdown content before the shortcode. Aliquam sodales rhoncus dui, sed congue velit semper ut. Class aptent taciti sociosqu ad litora torquent. {{<codePen VpVNKW>}} Some Markdown content after the shortcode. Nulla vel magna sit amet dui lobortis commodo vitae vel nulla sit amet ante hendrerit tempus.
Hugo automatically looks for a template named codePen.html in the shortcodes subfolder to parse the shortcode during compilation. My implementation looks like this:
{{ if .Site.Params.codePenUser }} <iframe height='300' scrolling='no' title="code demonstration with codePen" src='//codepen.io/{{ .Site.Params.codepenUser | lower }}/embed/{{ .Get 0 }}/?height=265&theme-id=dark&default-tab=result,result&embed-version=2' frameborder='no' allowtransparency='true' allowfullscreen='true' style='width: 100%;'> <div> <a href="http://www.smashingmagazine.com//codepen.io/{{ .Site.Params.codePenUser | lower }}/pen/{{ .Get 0 }}">See the demo on codePen</a> </div> </iframe> {{ else }} <p><strong>Site error:</strong> The <code>codePenUser</code> param has not been set in <code>config.toml</code></p> {{ end }}
To get a better idea of how the Go template package works, you’ll want to consult Hugo’s “Go Template Primer7.” In the meantime, just note the following:
It’s pretty fugly but powerful nonetheless.
The {{ .Get 0 }} part is for retrieving the first (and, in this case, only) argument supplied — the Codepen ID. Hugo also supports named arguments, which are supplied like HTML attributes.
The . syntax refers to the current context. So, .Get 0 means “Get the first argument supplied for the current shortcode.”
In any case, I think shortcodes are the best thing since shortbread, and Hugo’s implementation for writing custom shortcodes is impressive. I should note from my research that it’s possible to use Jekyll includes8 to similar effect, but I find them less flexible and powerful.
I have a lot of time for Codepen (and the other code playgrounds that are available), but there are inherent issues with including such content in a pattern library:
It uses an API so cannot be easily or efficiently made to work offline.
It doesn’t just represent the pattern or component; it is its own complex interface wrapped in its own branding. This creates unnecessary noise and distraction when the focus should be on the component.
For some time, I tried to embed component demos using my own iframes. I would point the iframe to a local file containing the demo as its own web page. By using iframes, I was able to encapsulate style and behavior without relying on a third party.
Unfortunately, iframes are rather unwieldy and difficult to resize dynamically. In terms of authoring complexity, it also entails maintaining separate files and having to link to them. I’d prefer to write my components in place, including just the code needed to make them work. I want to be able to write demos as I write their documentation.
Fortunately, Hugo allows you to create shortcodes that include content between opening and closing shortcode tags. The content is available in the shortcode file using {{ .Inner }}. So, suppose I were to use a demo shortcode like this:
{{<demo>}} This is the content! {{</demo>}}
“This is the content!” would be available as {{ .Inner }} in the demo.html template that parses it. This is a good starting point for supporting inline code demos, but I need to address encapsulation.
When it comes to encapsulating styles, there are three things to worry about:
styles being inherited by the component from the parent page,
the parent page inheriting styles from the component,
styles being shared unintentionally between components.
One solution is to carefully manage CSS selectors so that there’s no overlap between components and between components and the page. This would mean using esoteric selectors per component, and it is not something I would be interested in having to consider when I could be writing terse, readable code. One of the advantages of iframes is that styles are encapsulated by default, so I could write button { background: blue } and be confident it would only apply inside the iframe.
A less intensive way to prevent components from inheriting styles from the page is to use the all property with the initial value on an elected parent element. I can set this element in the demo.html file:
<div> {{ .Inner }} </div>
Then, I need to apply all: initial to instances of this element, which propagates to children of each instance.
.demo { all: initial }
The behavior of initial is quite… idiosyncratic. In practice, all of the affected elements go back to adopting just their user agent styles (like display: block for <h2> elements). However, the element to which it is applied — class="demo" — needs to have certain user agent styles explicitly reinstated. In our case, this is just display: block, since class="demo" is a <div>.
.demo { all: initial; display: block; }
Note:all is so far not supported in Microsoft Edge but is under consideration. Support is, otherwise, reassuringly broad9. For our purposes, the revert value would be more robust and reliable but it is not yet supported anywhere.
Using all: initial does not make our inline components completely immune to outside influence (specificity still applies), but we can be confident that styles are unset because we are dealing with the reserved demo class name. Mostly just inherited styles from low-specificity selectors such as html and body will be eliminated.
Nonetheless, this only deals with styles coming from the parent into components. To prevent styles written for components from affecting other parts of the page, we’ll need to use shadow DOM10 to create an encapsulated subtree.
Imagine I want to document a styled <button> element. I’d like to be able to simply write something like the following, without fear that the button element selector will apply to <button> elements in the pattern library itself or in other components in the same library page.
The trick is to take the {{ .Inner }} part of the shortcode template and include it as the innerHTML of a new ShadowRoot. I might implement this like so:
$uniq is set as a variable to identify the component container. It pipes in some Go template functions to create a unique string… hopefully(!) — this isn’t a bulletproof method; it’s just for illustration.
root.attachShadow makes the component container a shadow DOM host.
I populate the innerHTML of the ShadowRoot using {{ .Inner }}, which includes the now-encapsulated CSS.
I’d also like to include JavaScript behavior in my components. At first, I thought this would be easy; unfortunately, JavaScript inserted via innerHTML is not parsed or executed. This can be solved by importing from the content of a <template> element. I amended my implementation accordingly.
JavaScript is, to my surprise, not encapsulated automatically12 like CSS is in shadow DOM. That is, if there was another [aria-pressed] button in the parent page before this component’s example, then document.querySelector would target that instead.
What I need is an equivalent to document for just the demo’s subtree. This is definable, albeit quite verbosely:
I didn’t want to have to write this expression whenever I had to target elements inside demo containers. So, I came up with a hack whereby I assigned the expression to a local demo variable and prefixed scripts supplied via the shortcode with this assignment:
if (script) { script.textContent = `(function() { var demo = document.getElementById('demo-{{ $uniq }}').shadowRoot; ${script.textContent} })()` } root.shadowRoot.appendChild(document.importNode(template.content, true));
With this in place, demo becomes the equivalent of document for any component subtrees, and I can use demo.querySelector to easily target my toggle button.
var toggle = demo.querySelector('[aria-pressed]');
Note that I have enclosed the demo’s script contents in an immediately invoked function expression (IIFE), so that the demo variable — and all proceeding variables used for the component — are not in the global scope. This way, demo can be used in any shortcode’s script but will only refer to the shortcode in hand.
Where ECMAScript6 is available, it’s possible to achieve localization using “block scoping,” with just braces enclosing let or const statements. However, all other definitions within the block would have to use let or const (eschewing var) as well.
{ let demo = document.getElementById('demo-{{ $uniq }}').shadowRoot; // Author script injected here }
Of course, all of the above is only possible where shadow DOM version 1 is supported. Chrome, Safari, Opera and Android all look pretty good, but Firefox and Microsoft browsers are problematic. It is possible to feature-detect support and provide an error message where attachShadow is not available:
if (document.head.attachShadow) { // Do shadow DOM stuff here } else { root.innerHTML = 'Shadow DOM is needed to display encapsulated demos. The browser does not have an issue with the demo code itself'; }
Or you can include Shady DOM and the Shady CSS extension, which means a somewhat large dependency (60 KB+) and a different API. Rob Dodson was kind enough to provide me with a basic demo13, which I’m happy to share to help you get started.
With the basic inline demo functionality in place, quickly writing working demos inline with their documentation is mercifully straightforward. This affords us the luxury of being able to ask questions like, “What if I want to provide a caption to label the demo?” This is perfectly possible already since — as previously noted — Markdown supports raw HTML.
However, the only new part of this amended structure is the wording of the caption itself. Better to provide a simple interface for supplying it to the output, saving my future self — and anyone else using the shortcode — time and effort and reducing the risk of coding typos. This is possible by supplying a named parameter to the shortcode — in this case, simply named caption:
{{<demo caption="A standard button"}} ... demo contents here... {{</demo>}}
Named parameters are accessible in the template like {{ .Get "caption" }}, which is simple enough. I want the caption and, therefore, the surrounding <figure> and <figcaption> to be optional. Using if clauses, I can supply the relevant content only where the shortcode provides a caption argument:
{{ if .Get "caption" }} <figcaption>{{ .Get "caption" }}</figcaption> {{ end }}
Here’s how the full demo.html template now looks (admittedly, it’s a bit of a mess, but it does the trick):
{{ $uniq := .Inner | htmlEscape | base64Encode | truncate 15 "" }} {{ if .Get "caption" }} <figure role="group" aria-labelledby="caption-{{ $uniq }}"> {{ end }} <div></div> {{ if .Get "caption" }} <figcaption>{{ .Get "caption" }}</figcaption> {{ end }} {{ if .Get "caption" }} </figure> {{ end }} <template> {{ .Inner }} </template> <script> (function() { var root = document.getElementById('demo-{{ $uniq }}'); root.attachShadow({mode: 'open'}); var template = document.getElementById('template-{{ $uniq }}'); var script = template.content.querySelector('script'); if (script) { script.textContent = `(function() { var demo = document.getElementById('demo-{{ $uniq }}').shadowRoot; ${script.textContent} })()` } root.shadowRoot.appendChild(document.importNode(template.content, true)); })(); </script>
One last note: Should I want to support markdown syntax in the caption value, I can pipe it through Hugo’s markdownify function. This way, the author is able to supply markdown (and HTML) but is not forced to do either.
For its performance and its many excellent features, Hugo is currently a comfortable fit for me when it comes to static site generation. But the inclusion of shortcodes is what I find most compelling. In this case, I was able to create a simple interface for a documentation issue that I’ve been trying to solve for some time.
As in web components, a lot of markup complexity (sometimes exacerbated by adjusting for accessibility) can be hidden behind shortcodes. In this case, I’m referring to my inclusion of role="group" and the aria-labelledby relationship, which provides a better supported “group label” to the <figure> — not things that anyone relishes coding more than once, especially where unique attribute values need to be considered in each instance.
I believe shortcodes are to Markdown and content what web components are to HTML and functionality: a way to make authorship easier, more reliable and more consistent. I look forward to further evolution in this curious little field of the web.
For many people, a map of a transportation network is a given, an expected part of the system, something that just is — like a fire-escape plan in a building. So, when I say that I design transportation maps, they don’t understand. What is there to design even?
Well, let’s take the London underground map as an example. Designed by Harry Beck, it was the world’s first transportation map to use the principles of electrical circuit drawings. All line segments were put to the angles of 45 or 90 degrees. The distances between stations were equalized. I wrote about it in part three of my “Maps and Reality” series, “Diagrams1.”
This schematic approach was later adopted for many transportation maps of the world. But not every time was this a good idea. This is one useless map (from Samara, Russia):
It adds almost nothing beyond just listing the stations: Алабинская · Российская · Московская · Гагаринская · Спортивная · Советская…
Beck’s design dealt with growing complexity and the spread of London’s underground rail network. When there is just one line, it’s better to put this line in context. See the Ekaterinburg metro map5, for example:
Let’s look at New York. The subway is large and complicated but quite different from London’s: Trains can have different routes, which are denoted by both numbers and letters. In 1972, Massimo Vignelli designed this map:
Vignelli couldn’t have used them in New York. In London, lines rarely run together through the same stations. And when they do, all trains in a “wisp” stop at all of them — see Great Portland Street and Euston Square above.
In New York, such wisps are everywhere, and some trains don’t stop at some stations. So, when there is a stop on a particular route, Vignelli puts a black bullet on the route’s line:
You can see that, at some stations, not every line has a bullet.
Vignelli’s map was beautiful but, unfortunately, unsuccessful. People considered it too abstract. Having no geographical reference, the eye had nothing to catch on. Also, the stations named with street numbers looked identical — the font was just too small for that.
This design was the closest to London’s that New York has ever seen.
The successful design was the one by Michel Hertz (1979) — still in use. It includes parks, ponds, main streets and area names:
But there’s a list of stopping routes at each station. Look at the red line, for example. Only route 1 stops at 18th, 23rd and 28th Streets, but all routes stop at 14th and 34th Streets.
Hertz wanted his map to look geographical. But he knew that a “true” map would use the format very inefficiently. So, his map is actually distorted significantly for everything to fit. Compare Google Maps on the left to Hertz’s map on the right:
The terminals are, thus, important for wayfinding, so they have to be emphasized on a map. In Barcelona, they put the terminal’s name on a background, whose color matches the line’s:
This is unnecessary in London, where, instead of toponymics, they use geographic directions (for example, “Northbound”).
In Oslo, a thick wisp of lines passes through the city center. One of the lines forms a loop and passes several stations twice: first as line 4, then as line 6. The transformation from 4 to 6 is shown with a gradient — not a typical element indeed:
There is another detail in Oslo: Trains pass Gulleråsen station in only one direction. This requires a designation, an element that is not used in any of the maps we’ve discussed above:
Moscow has its own peculiarity: For historical reasons, the stations have different names on different lines (sick, but what can you do). In addition, the Moscow metro map has to use both Cyrillic and Latin scripts for its station names. Depiction of transfers turns into a problem. Here, eight names must be positioned around the “Biblioteka Imeni Lenina — Aleksandrovsky Sad — Arbatskaya — Borovitskaya” junction, where four lines intersect:
34 Fragment of the official map. This place looks cleaner in my design35.
A whopping six lines intersect at London’s “King’s Cross St. Pancras” station; just one name suffices:
There is not a single place on London’s giant map where a station name intersects a line — there is always space around the lines. To achieve this in Moscow, one would need to dramatically reduce the font size and complicate the line geometry. That’s why Moscow’s metro map includes a device that the London one does not: a semi-transparent background for the station names that cross lines (see above).
But London has its own complication, one absent in Moscow. The gray “clouds” delineate the payment zones — something Moscow does not need because the price of a ride is fixed:
Every city and transportation network has a lot of details, which makes it impossible to use exactly the same graphical principles everywhere. But there is another reason for maps to be so different: aesthetics.
A transportation map is not only a tool, but also a notable object of graphic design in a big city. So, if you opt for Beck’s design language, you would get a London-like map, no matter what you depict. The transportation system must have a face, and aesthetics are as important as logic.
The main feature of the Moscow metro map is the circle line. It doesn’t fit Beck’s language, but it’s very important to Moscow. This is not of Moscow:
These circle lines are major elements and form the overall impression of the map.
But little details also influence the perception of a map.
In London, the black rings of the transfer stations are noticeably thinner than the lines. The “corridors” are of the same width. The stations’ ticks are square, sticking out at two thirds of a line’s width. The names are typeset with blue New Johnston:
In Moscow, the fat rings of the transfers are colored with their lines’ colors. The corridors are much thinner and have a gradient. Some transfers are circular. The station ticks stick out at a full line’s width. The names are typeset with black Moscow Sans:
It’s obvious that it’s a tram map for London, not for some other city. It follows London’s transportation graphic design standards — the rings, the ticks, the captions.
When we see the beige background, the particular palette of the lines, the filled station disks and the distinct designation of the transfers, we immediately recognize the Paris map:
Why are they like this? The only reason is that we wanted this map to look special.
It is not enough for a good transportation map to just answer the question, “How do I get there?” Because it is used everywhere, it is a part of the city’s image. And if its design is powerful, it will influence the city in other ways.
Moscow’s circle line has inspired designers to create this beautiful wayfinding signage:
The round designations of New York’s subway train routes are used in all of the signage and have even made it to the dots of the i‘s in the pedestrian city maps (in the classic Helvetica these dots are rectangles):
This graphical language is so iconic that you can even buy all sorts of souvenirs with its elements: t-shirts, umbrellas, shower curtains. This design has spread not only beyond the Tube, but beyond London. All sorts of maps are now done in this style:
Strong graphic design makes transportation systems more attractive. This helps cities get rid of privately owned cars. People spend more time outside, interacting with each other. This gives small businesses a boost and makes cities more pleasant to live in.
CSS is an amazing tool which we constantly use but we don’t seem to honor it appropriately. Whenever I see the growing browser support of the :focus-within selector, the much wanted justify-content: space-evenly for Flexbox or how great CSS Grids already work, I feel really grateful to have such awesome tools available to work with.
And with advanced new media queries such as prefers-reduced-motion, screen and (color), or pointer, we get amazing tools to improve accessibility and usability of our websites. Just let the user be in control how to view your amazing design and it’ll be a success for everyone.
The :focus-within CSS pseudo-selector11 is a nice way to enhance your form sections further. Browser support12 is still a bit limited so far but it’s already worth thinking about adding it to your code to improve design and usability for those whose browser support the selector already.
The CSS Flexbox Module specification now has a new value justify-content: space-evenly13. This new setting places even space between and to the outer of the elements — a feature we all wanted to have very much in Flexbox. It already works in Firefox, and Safari Tech Preview and Chrome Canary have the support as well.
16 When designing a date/time picker, keep in mind that every date picker may fit every interface, but not every interface actually needs a date picker. (Credits: Topvet.net17)
Hampus Sethfors18 and Hugo Giraudel19 collected a bunch of real-world experiences regarding accessibility on websites. These two articles give a lot of insight on how to understand accessibility and usability of websites better.
20 Zooming problems: Some users with low vision point to layout and navigation problems when zooming or increasing font-size. (Image source21)
Whether you’re into good ol’ drawing and painting, or quick editing in Photoshop or Illustrator, one thing’s for sure: they’re all creativity’s best friends. Some draw pictures all day1, while others find their inspiration in uncommon sources2 in order to break out of the box. Whatever it is that you decide to do, it’s good to challenge yourself more often and get out of your comfort zone. If you don’t, you may never discover something that you love doing, or perhaps even worse, never learn a whole lot about yourself.
If your excuse are pesky blackouts or simply having no clue what to create nor where to get started, don’t fret! Even the most talented artists out there practice so much more than you’d ever imagine, and hone their skills by trying out copywork3. The most important thing is to be confident and simply give it a try. For more encouragement, I’ve collected a good number of inspirational artwork that is bound to give you that spark you need to get started already!
An editorial illustration for DB Magazine in the US on the subject of the dangers of hackers within the hospital system. Beautiful style, colors and patterns.
Playing with color, shapes and shadow. That’s what you’ll see in this series called Colorful Boxes. Absolutely love the very bright colors in this one.