Chatbot fever has infected Silicon Valley. The leaders of virtually every tech giant — including Facebook, Google, Amazon and Apple — proclaim chatbots as the new websites, and messaging platforms as the new browsers. “You should message a business just the way you would message a friend,” declared Mark Zuckerberg when he launched the Facebook Messenger Platform for bots. He and the rest of the tech world are convinced that conversation is the future of business.
But is chatting actually good for bots? Early user reviews of chatbots suggest not. Gizmodo writer Darren Orf describes1 Facebook’s chatbot user experiences as “frustrating and useless” and compares using them to “trying to talk politics with a toddler.” His criticisms are not unfair.
Here’s an example of a “conversation” I had with the 1–800-Flowers Messenger bot2 after I became stuck in a nested menu and was unable to return to the main menu. Not exactly a pleasant or productive user experience.
Designers who are new to conversational interfaces often have the misconception that chatbots must “chat.” At the same time, they underestimate the extraordinary writing skill, technical investment and continual iteration required to implement an excellent conversational user experience (UX).
This article explores when conversation benefits and when conversation hurts the chatbot user experience. We’ll walk through case studies for both sides of the argument and compare divergent opinions from Ted Livingston, CEO of Kik, who advises6 bot makers to deprioritize open-ended chat, and Steve Worswick, the creator of “the most human chatbot,” who encourages developers to invest in truly conversational experiences.
As you’ll see from the examples below, both strategies can lead to successful chatbot experiences. The key is to choose the right level of conversational ability for your bot given your business goals, team capabilities and user needs.
Steve Worswick is the developer behind Mitsuku7, one of the world’s most popular chatbots. Mitsuku has twice won the Loebner Prize8, an artificial intelligence award given to the “most human-like chatbot.” The popular chatbot has conversed with more than 5 million users and processed over 150 million total interactions. 80% of Mitsuku’s users come back for more chats.
The longest a user has chatted with Mitsuku is nine hours in a single day — a testament to the bot’s extraordinary conversational abilities. Mitsuku does not help you find makeup products, buy flowers or perform any functional utility. The chatbot’s sole purpose is to provide entertainment and companionship. You won’t be surprised to find out that Worswick thinks “chatbots should be about the chat.”
Building a conversational chatbot that isn’t awful is extremely hard. Worswick nearly gave up many times when Mitsuku repeatedly gave unsatisfactory answers and users called her “stupid.” One major breakthrough occurred when Worswick programmed in a massive database with thousands of common objects such as “chair,” “tree” and “cinema,” along with their relationships and attributes.
Suddenly, Mitsuku could give sensible answers to strange user questions, such as, “Is a snail slower than a train?” or “Can you eat a tree?” According to Worswick, “Let’s say a user asks Mitsuku if a banana is larger than X, but she doesn’t recognize what X is. She knows that a banana is a relatively small object so can deduce that X is probably larger.”
Even if a chatbot is utilitarian, providing spontaneous answers in a conversation — especially if unexpected — can delight and engage users. Poncho12 is a Messenger bot that gives you basic weather reports, but the creators gave the bot the personality of a Brooklyn cat. Poncho can conduct small talk and even recognizes other cats. “Weather is boring,” admits Poncho founder Kuan Huang. “We make it awesome.”
When You Should Add Conversation To Delight Users Link
Making a bot conversational takes tremendous effort, but if you are up to the challenge, here are the top situations in which conversation could distinguish your chatbot from competitors’ and truly delight users.
If You Need to Differentiate From Competition Link
As seen earlier, Poncho’s conversational personality distinguishes the chatty weather cat from boring, routine weather apps. Bots launch at a more rapid pace than mobile apps due to the lower technical barriers to entry. Dozens of bots already exist to service identical use cases, so winners need to stand out with a superior conversational UX.
Just like weather apps, public transit apps are soulless and boring. We use them out of necessity and not delight. Enter Bus Uncle16, a bot that can tell you anything you want to know about the Singaporean bus system in his quirky, broken English and suggest funny things to do while you wait.
Comprehensive, detailed guides and maps for the bus system exist on the Internet to help expats and locals find their way home, but Bus Uncle’s conversational interface both simplifies and adds joy to a routine task.
Beware that the bot is not all fun and games. Like any proper Asian uncle, Bus Uncle stays in character by occasionally forcing you to solve math problems.
E-commerce is a challenging space for bots due to product diversity and language variability. Many conversational shopping bots malfunction when users use unrecognized vocabulary or suddenly switch contexts. Such failures are usually technical in nature, where a bot simply doesn’t have the requisite data set or intelligence to handle the edge input.
ShopBot23 from eBay avoids common e-commerce bot UX failures by combining limited option menus with the ability to handle unexpected user input. While many shopping bots hem users into a narrow series of menus, ShopBot was able to quickly adapt when I switched from shopping for jeans to shopping for blouses.
Shopping is a difficult use case for chatbots to master. Superior conversational experiences in e-commerce bots are a function not just of great copy, but of powerful technologies that process natural language, keep track of shoppers’ contexts and preferences, and anticipate diverse needs accurately.
RJ Pittman, chief product officer at eBay, explains27, “Shoppers have complex needs, which are often not fully met by traditional search engines. The science of AI provides contextual understanding, predictive modeling, and machine learning abilities. Combining AI with eBay’s breadth of inventory and unique selection will enable us to create a radically better and more personal shopping experience.”
Chatting is an intimate act we do with close friends and family, which is why chatting with a “brand” is often an awkward and strange experience. Strong conversational skills in a chatbot can overcome this barrier and establish an authentic connection.
Maintaining a consistent and compelling brand voice in chatbots is not easy. PullString28, a conversational AI platform founded by ex-Pixar CTO Oren Jacob, employs an entire department of expert Hollywood screenwriters to bring brands like Mattel’s Barbie and Activision’s Call of Duty to life.
Its demo chatbot, Jessie Humani29, is powered by over 3,500 lines of carefully selected dialog to create the impression that she’s your messed-up millennial friend who can’t get her life together without your help.
Many bot industry experts believe the word “chatbot” sets the wrong expectation among users that bots should have human-level conversational abilities. The hard reality is that natural-language processing and artificial intelligence still have much progress to make before bots will impress you with their gift of gab.
Ted Livingston, CEO of Kik, a popular messaging platform with a thriving bot store, is squarely on the side of no chatting. “The biggest misconception is that bots need to be about ‘chat.’ What we discovered is that bots that don’t have suggested responses simply don’t work. Users don’t know what to do with an empty input field and a blinking cursor,” he shared33 at a recent bot conference.
Kik started building a conversational platform two years ago34, long before bots suddenly became cool. In the beginning, its bots allowed freeform responses the same way Facebook Messenger bots do now. What resulted was user confusion and error, as well as complaints from developers about having to deal with the unnecessary complexity of processing open-ended conversation. Kik now restricts user responses to a limited set of predefined options and intentionally makes typing freeform text difficult.
For example, when Sephora’s Kik bot asks what type of beauty products a user would like to see, the bot follows the question with a menu of suggested responses to choose from. A user has to go out of their way to tap “Tap a message” in order to type normally.
When You Should Restrict Chat For A Better UX Link
There are many cases in which designers of chatbots should restrict conversation to provide a superior experience. Below are a few common situations in which letting users type freeform conversational text complicates development and decreases your bot’s usability.
If User Error Would Lead to a Failed Transaction Link
1–800-Flower’s bot for Facebook Messenger originally gave users three options for flower delivery dates: “Today,” “Tomorrow” or “Choose another date.” The third option allowed users to type in dates freeform, which often resulted in error, confusion and an abandoned or failed transaction.
By removing the third option for users to type in a date manually, 1–800-Flowers actually increased the number of transactions and overall customer satisfaction. Restricting conversation helped it focus on its most important users, the ones who want to send flowers urgently.
Chatbots should give users the key advantage of completing tasks with fewer taps and context switches than regular mobile apps. Enabling open-ended chat can undermine this simplicity and add development complexity related to handling variable input.
An example is the simple meditation bot Peaceful Habit41 for Amazon Echo and Facebook Messenger. The bot is designed to help regular meditators build a daily practice and should be quicker to use than meditation apps.
On the Amazon Echo, a user can start a 5-, 10- or 20-minute meditation completely hands-free, with voice alone. On Facebook Messenger, the bot sends a daily reminder with limited user options, so only a single tap is required to start a meditation practice.
Many user requests appear simple on the surface but are extremely complex to handle in an open-ended conversational interface due to variability of vocabulary, grammatical structures and cultural norms. For example, a user can ask to schedule a meeting by asking any of the following questions:
When’s Bob’s next open time slot?
Let me know the next three times Bob can chat.
Is Bob available at 4 PM PST today?
Turns out the complexity of handling seemingly simple meeting requests requires powerful artificial intelligence capabilities. Several well-funded companies have emerged just to solve narrow scheduling challenges with specialized technology.
When you consider more complex requests, such as asking for restaurant recommendations, limiting conversations often means less confusion for both your bot and your user. Sure45, a bot that offers local restaurant recommendations, asks users to type in what they are craving, but it often can’t understand the responses.
These examples demonstrate that complex artificial intelligence, machine learning or natural-language processing is not required to create a great user experience using a chatbot. As Ted Livingston, CEO of Kik, warns53, “AI is not the killer app for bots. In fact, AI holds most bots back. Bots are just a better way to deliver a software experience. They should do one thing really well.”
How “chatty” your chatbot should be will depend on your users’ mental models of chatbots and the goals and needs your chatbot fulfills for them. Bots on Kik that only offer limited responses can be just as successful and engaging as Mitsuku and Jessie Humani.
Problems occur when designers do not decide up front who their audience is, how the chatbot fits into their business or brand strategy, what domains the chatbot will and will not cover, and what a successful experience should look like.
When you are deciding how much “conversation” to design into your chatbot experience and are defining the right level of engagement, answer the following questions:
How are you setting user expectations?
If you brand your chatbot as a character or a human replacement, users will expect a minimum level of conversational ability. If your bot’s functionality is utilitarian or limited, then guide conversations towards specific outcomes.
Is your chatbot utilitarian or entertainment-driven?
Mitsuku is an artificial-intelligence companion, so she’s required to master the art of conversation. On the other hand, a Slackbot that performs SQL queries or pulls CRM data has no need to support chat.
Does your chatbot reflect your brand’s voice?
Major brands such as Disney54 and Universal Studios55 use chatbots to engage audiences beyond simple ad clicks and video views. A chatbot working as a brand ambassador needs to authentically reflect the domain and voice of the company it represents.
Is your chatbot a familiar service or product?
Businesses such as 1–800-Flowers and Domino’s Pizza already have millions of buyers who use their websites, mobile apps and phone numbers to order products. Users who already know what you offer and what they like won’t require as much explanation and hand-holding.
Does your chatbot need to differentiate itself in a competitive market?
Weather apps are a dime a dozen. Poncho the Weather Cat differentiates itself by having a distinct personality and delightful reactions, making the bot stand out against other weather services.
How strong is your technical team and AI platform?
Building an adaptable and user-friendly conversational AI is incredibly challenging. Worswick invested over a decade to make Mitsuku the award-winning chatbot she is today. Each conversational AI platform has strengths and weaknesses that will affect your chatbot’s UX.
How strong is your writing team?
In the world of bots, writers are the new designers. Do your writers understand how to write engaging, emotional copy that draws users in? Bots reflect the communication skills of their makers.
As natural-language understanding, machine learning and artificial intelligence improve, chatbots will inevitably become smarter and more capable in interactions with humans.
For now, just be sure that your bot either sticks with utilitarian offerings or stays within a comfortable zone of conversational topics. Take a cue from how Mitsuku gracefully avoids confrontation by excusing herself from a potentially awkward political conversation.
When I was a developer, I often had a hundred questions when building websites from wireframes that I had received. Some of those questions were:
How will this design scale when I shrink the browser window?
What happens when this shape is filled out incorrectly?
What are the options in this sorting filter, and what do they do?
These types of questions led me to miss numerous deadlines, and I wasted time and energy in back-and-forth communication. Sadly, this situation could have been avoided if the wireframes had provided enough detail.
Now that I am a UX designer, I notice that some designers tend to forget that wireframes are equally creative and technical. We are responsible for designing great ideas, but we are also responsible for creating product specifications. I admit that there can be so many details to remember that it’s easy to lose track. To save time and energy for myself, I gathered all of my years of wireframing knowledge into a single checklist that I refer to throughout the process. And now I am sharing this knowledge with you, so that you can get back to being creative.
If you’re starting fresh on a wireframe project, I recommend going through each section’s guidelines like a checklist. If not, feel free to jump to the appropriate section.
Note: These guidelines are more appropriate for wireframes — and prototypes, to an extent — during a production life cycle (i.e. preparing your product to be built). By this point, the main idea has been established, the features have been fairly locked down, and the core layouts are not going to dramatically change. That being said, some guidelines, like in the first section, can be used for conceptual wireframes in a discovery phase. Just be wary of getting too detailed, because your designs might drastically change, and you will have wasted time.
Finally, onto the guide!
Decisions To Consider Before Wireframing
These guidelines ensure that you ask the difficult but crucial questions early on and establish a foundation for a smooth wireframing process.
Usually, the stakeholders will dictate which devices to support, but sometimes you will have a reasonable suspicion that it will be cross-platform or responsive. Other times, you might have to select the best devices to use with your product. In either case, here’s a list of reference devices:
desktop browsers
mobile website (browser)
native mobile app: Android, iOS, Windows
tablet
smartwatch: Android Wear, Watch OS(iOS), WebOS, Band (Microsoft)
smart TV: Android TV, Tizen OS (Samsung), Firefox OS (Panasonic), WebOS (LG)
console gaming: Xbox One, Playstation 4, Wii U, Steam
Confirm devices expected to be supported. More often than not, responsive mobile wireframes are requested later in the process or are suddenly included by the client. These late requests can cause massive design reworking when you have already started on the wireframes. So, ensure the following:
Align with your team’s expectations.
Make sure you have client approval in writing, or refer to a statement of work.
While they are not devices, content management systems are frequently forgotten.
Match features to context of use. While composing a review for a product would work in a desktop browser, it might be seldom done on a mobile phone. Review your features one by one and determine whether your users will get added value from each device. If a feature does not match the user’s goals, either change it to be more device-specific or cut it out completely for the device in question. Reducing the design will save you time and money.
Verify design differences on multiple devices. A common scenario is building a desktop application with a mobile and tablet component. Discuss the following with your team and stakeholders:
Will the layout be identical (responsive) or completely separate?
Are features shared across all experiences, or will there be subsets?
Which operating systems are being supported? For instance, Android and iOS apps follow different design patterns.
Maintain documentation on differences in layouts and features, so that you can easily design for them later in your wireframes.
Consider implications of screen orientation. For mobile and tablet, designs can appear different in portrait and landscape modes.
Left alone, a landscape layout will appear like the portrait version but with the width stretched out and less horizontal viewing space.
Screens can be locked to an orientation. Tread carefully around design layouts that are exclusive to portrait or landscape, because you are forcing users to work a certain way. If in doubt, conduct a usability test.
4 Maintaining a portrait layout might have worked better here so that users would not have to rotate their phone back and forth on the scheduling screen of Nest’s mobile app. (View large version5)
A layout and its UI elements can scale in a variety of ways when the window’s size changes. The most popular scaling patterns are:
fixed or static
Remains the same no matter what.
fluid or liquid
Incrementally shrinks or stretches with each pixel.
adaptive
Layout changes at certain breakpoints in the window’s width.
responsive
Follows a mix of fluid and adaptive behavior.
Liquidapsive566 is an interactive tool for visualizing how each scaling pattern affects the layout when the window’s size changes.
Get team consensus. First discuss with your team the best approach, because this will have an impact on the time for you, the developers and the visual designers. Users expect most websites to have desktop and mobile versions, although they don’t always have to share the same set of features.
Align with your developer on mechanics. Consult with your developers on how the design should scale. Also, discuss breakpoints and the scaling behavior for layouts and UI elements that you are unsure of.
Prepare for many sets of wireframes. Responsive and adaptive layouts will need many sets of screens; so, let your project managers know it will require extra time. I usually add an extra 50 to 75% of the total time for each set.
Establishing a default screen size is important for everyone on your team because they will need to know what to develop and design for. You also want to avoid accidentally starting too large and then realizing you need to shrink it down.
Start small and prepare for a large size. 1024 × 768 pixels for desktop and tablet and 320 × 480 for mobile are generally safe resolutions to work with. Anything higher can be risky to begin with. It is prudent to start with a low resolution and then scale up so that the design still looks adequate when the window is larger.
Additionally, consider that many people do not maximize their browser window, so their view of the layout will be even smaller.
Use analytics to guide your decision. Analytics for screen resolutions can reveal interesting trends, which can help you make an informed decision. You might need the data to convince your client of the resolution you are pushing for as well. Remember that it’s better to be inclusive than exclusive.
9 Although 1366 × 768 pixels has the highest number of users, 1280 × 800 is the best to start with, despite having a usage of 3.76%. (View large version10)
Going for that larger, prettier resolution might cut off a chunk of your audience. To help with your analysis, here are some scenarios I have seen before:
The most popular resolution can sometimes be safe if it shows a trend of continued growth over many years, while the lower resolutions are declining.
A group of small resolutions with a low percentage of use could add up to a sizeable population — in which case, choose the lowest resolution.
For a large variation in resolutions, go with the lowest one.
If at least 5% of users have a a low resolution, such as 1024 × 768, I would err on the side of caution and select that.
Viewing trends for the past year is sometimes better than viewing trends since the beginning, because the latter could include resolutions that are no longer relevant. Sanitize your data by removing old data and mobile and tablet resolutions — trends will be easier to identify.
Know your audience and usage environment. Although 1366 × 768 is the most common resolution for the desktop (as of May 2016, according to StatCounter5711 and W3Counter5812), think about your audience’s context of use. For instance, 1024 × 768 makes sense if you’re dealing with users who are on old computers and can’t change their equipment (usually corporate environments).
Be clear on your definitions of fidelity because it can mean different things to different people. Below is how I define wireframe fidelity:
Low fidelity has these elements:
Focuses on layout and high-level interactions and concepts.
UI elements and content can be represented as boxes or lines, with or without label descriptions.
Gray-scale.
Can be paper sketch.
13 Notice how abstract this wireframe is. It’s easy to get carried away with adding more detail, but imagine that people will only be able to see a zoomed-out wireframe.
High fidelity has these elements:
Emphasizes visual aesthetics and branding, such as tone, colors, graphics and font style.
Can include realistic images and copy.
UI elements look realistic and might include aesthetic touches such as textures and shadows.
Sometimes known as a mockup.
14 Sometimes you need to create a small set of concept wireframes with visual themes to preview the overall look and feel. (Image: Squarespace15) (View large version16)
Medium fidelity has these elements:
Varies between low and high fidelity.
More realistic UI elements, but not styled.
Filler images and copy.
Gray-scale.
Has some visual design (such as hierarchical typography).
17 This wireframe uses various grayscale values to convey visual weight, without actually using color. (View large version18)
Indulge your stakeholders. Observe your stakeholders’ behavior to figure out what makes them happy, or have a discussion with them to determine what they expect.
Are they the type to hone in on minor irrelevant details? Start with low fidelity, and iterate on that until they are satisfied. Then, move up to medium or high fidelity. Gradually building fidelity over multiple check-ins will make approvals easier, while saving precious design time.
Are they the type to react to something flashy? Go with high fidelity, but create only a couple at first, so that the stakeholders get an idea of what to expect.
If in doubt, medium fidelity is always a safe bet, although it takes a bit more time.
Confirm the expectations of fidelity. Whichever fidelity you decide on, make sure your team and stakeholders are on the same page — consider giving examples to be sure. It is scary to walk into a meeting with low-fidelity designs when “low fidelity” in people’s mind is actually “medium fidelity.”
When used in a wireframe tool, a grid system saves you time by easily aligning your UI through snap-to-grid features. This feature basically keeps your designs looking aligned and polished.
Using a grid system will also help you maintain consistency in the layout and balance the design’s hierarchy. The article “All About Grid Systems19” does a great job of briefly explaining the theory behind grid systems and the key advantages to using them.
Know your alignment and spacing features. I achieve pixel-perfection by using the alignment and space-distribution features of many wireframe tools. Learn to use the most common keyboard shortcuts, such as centering, space distribution, grouping and ungrouping. It will save you from having to manually polish your layouts.
21 Shown here is Omnigraffle’s object-alignment module, which is somewhat similar in other tools such as InDesign and Axure. (View large version22)
Perform visual checks. Your visual designer and developer will end up doing most of the actual pixel-pushing, but you’ll want to get it as close as possible; a sloppy design will lose the trust of your user. The key to saving time and cleaning up a design is to stand back a bit from the design and see if any misalignments are visible to the naked eye.
Now that you have checked off all of the pre-wireframing activities, you can start designing the actual wireframes. The next section will focus on polishing the design.
Detailing The Design Elements
Once you have completed the bulk of your main designs, it’s time to include all of the cumbersome details. Go through each of your screens and use the guidelines below as a checklist to fill in anything missing.
For any action that a user executes, there should always be feedback to let them know what happened or what the next step is.
Validate forms. Forms will usually have one of these validation responses:
Invalid syntax: For email address, phone number, area code, URLs and credit-card numbers.
Incorrect login: Include a message for the username or password being incorrect, but also include one for both being wrong.
Empty form fields.
Required check boxes: For agreeing to terms of service.
Age requirement: Dropdown to fill in birth date.
Intermediary messages and modals. Many user actions will generate some form of UI to inform the user of what is happening or to ask them to do something. These can include:
confirmation
warning or alert
success
failed action
error
long-term progress indicator: This is when the user might have to wait for a long behind-the-scenes process to complete (even days long).
progress indicator or bar: Include states for zero progress, in progress, completion and failure.
spinner: For indeterminate time estimations or short operations.
Write user-friendly messages. No one likes to read an obscure error message like “Exception 0xc000000933” or a generic one like “Login error.” And unless you have a technical writer on the team, you are actually the most qualified person to write user-friendly messaging.
For consistency, I follow these criteria when writing messages:
Include the specific problem if possible.
Mention the next step to resolve the issue.
Keep it brief and concise, about one to two sentences.
Explain in colloquial terms.
Avoid technical jargon.
Maintain a positive and apologetic tone. Pretend you’re a down-to-earth customer service rep.
Enhance with the brand’s tone, if there is one.
Implement supportive form-input techniques. Your developer will know clever tricks to show users error messages immediately or to support users with input fields. Below is a list of common techniques to think about:
“Remember me” checkbox for logging in.
Links for forgotten password or username. Don’t forget the extra screens such as for “Send a reset password to email” and confirmation that the reset was successfully sent.
Suggested results upon typing keywords in a search.
Validating each keyboard character entered.
Character limit, with a counter or some visual representation when reaching a character limit.
Dropdown lists that auto-filter items when typing. Select223 is a great plugin for combo boxes.
Letting a user know when they have entered an old password.
A checklist for password strength or password syntax that marks off syntax requirements as the user types.
24 This checklist clearly tells you what criteria has been fulfilled for your password. (View large version25)
Walk through each of your UI components, and design for best- and worst-case scenarios, as well as any other potential states.
Dropdown lists. While the closed state will already be in your design, include the expanded state in your annotations or on a separate page. Do you have any of the following types of dropdowns?
navigation menu
combo box (states, date, age)
filter
sorting
context menu
Titles, labels and names. Account for all cases in which the text is exceptionally long in a confined space and can’t break to a new line (for example, in a table). Try to shorten the text as below, and then include the full-length text in a tooltip.
Ellipsis: “Deoxyribo…”
Truncation: “Deoxy”
Abbreviations: “DNA”
Names: “G. Washington or George W.”
Numbers: “100K,” “50M,” “140+”
Dynamic content. Your developers will need to know how content population scales or behaves in different situations:
Pagination: search result listings, forums, news articles
Scrolling and loading content
Brief paragraph text or tags
Galleries: image, video and banner carousels
Trees: nested file or folder directories
Comments and posts
These states are commonly associated with dynamic content:
First, middle and last pages: Pagination controls can sometimes appear different depending on where the user is, and final pages can include a “next step” action to fill in empty space.
Standard content length: This is default.
Empty or unpopulated content: Empty space can look awkward, so consider a friendly message or a subtle background image to fill the void.
Overflowing content: Try using “More…” links or a form of truncation.
Nested posts: Stack Exchange has a forum thread26 with a variety of suggestions to nest infinite posts.
Icons with numbers. Icons sometimes include values such as how many notifications or emails the user has. You will want to include states for the following:
zero items
typical items: double or triple digits
large numbers: depending on the design, it could go up to hundreds or thousands, but indicating “100K” or “2000+” is also acceptable.
Form fields. Forms will typically have a few states:
enabled: This is the default.
disabled: For fields that appear unusable in certain conditions.
corrected: Optionally have a different style for fields whose validation error has been corrected.
validation error: Some designers place error messages adjacent to the relevant field and/or provide an error list.
Tooltips. Consider adding a tooltip (a brief one to two sentences) for any interactions that fit these criteria:
New or uncommon interaction pattern: Helpful text for interactions that users wouldn’t intuitively understand at first glance. Think of different design solutions before using this as a fallback.
Advanced areas and actions: Common with programs such as Photoshop and Word, in which advanced functionality improves the user’s productivity or work quality.
Less frequent actions: Actions that rarely occur will need help text to jog the user’s memory.
Keyboard shortcuts.
Shortened content: Abbreviated or truncated text that needs a fully written version.
Content preview: Text or images that include previews of content. This is common with listings where users would want to peek at the content before committing to an action that would take them off the page.
Reference information: Extra details that quickly support the user with a task (for example, the security number on a credit card).
File uploads. When the user uploads a file in the browser, there are a few states to design for:
File upload dialog: Usually provided by default in the OS or browser, but include your custom design if you have one.
Upload progress bar.
Upload completion bar: For having reached 100%.
Canceling in-progress upload: Cancelling an upload in progress can take time.
Success: Appears after the progress bar goes away. Include the file name that was uploaded and a way to remove the file.
Remove confirmation: Confirmation to remove the uploaded file.
There is typically one way your users will physically interact with your UI, but there can also be multiple gestures per interaction, as with a responsive design or buttons with keyboard shortcuts. For each user action, look for the other gestures below and note the differences in your annotations later.
click
double-click
right-click
swipe or flick
pinch and spread
press
hover
drag and drop
keyboard input
keyboard shortcut
link to external website
link to default application: email, phone number, map.
27 This smart TV wireframe shows how various remote-control buttons interact with a UI element. (View large version28)
Be sensitive to cross-device interaction. If you are working on a responsive website, be aware of gestures that will not translate smoothly:
Hovering: Some designers replace this with a touch gesture. But watch out for actions that already use touch for something else.
Dragging and dropping: An alternative design is best.
Uploading files: Not a common mobile task; consider removing it for mobile.
Consider how much time you have and what would be useful to your audience. You can also mix and match styles, like using real text for the home-page banner but filler for other areas. Listed below are various styles, with their key advantages.
Demonstrating how an interaction works will reduce miscommunication with the developer and ensure that it is technically feasible. Typically, the developer will feel more confident about deciding which plugin or implementation to use. But if you feel technically savvy, then it would be really helpful for you, as the architect, to take the first step. Below are some useful tips.
Search for plugins. If you are working online, you can often find the latest and trusted plugins being used by the development community on GitHub3736. Search for something like “accordion” to browse through accordion plugins. If you are working on other devices, such as Android mobile or Apple Watch, search the web for official design guideline documentation.
Select relevant plugins. Developers consider community approval, constant updates and framework compatibility to be important when selecting a plugin. On GitHub3736, you can sort for “most stars” and “recently updated.” Also, look for demo links in the documentation or website to see how it will work, and then share it with your developer to see if it is viable.
Build a demonstration. If you are building a custom interaction or flow that does not yet exist, think about using prototyping tools or coding it yourself if you are technically savvy. Some prototyping tools with motion design features include Principle6338, Flinto6439 and Axure40. Some that might require a bit of programming knowledge are Origami6641 and Framer6742.
If you can actually code, then CodePen43 is useful for building something quickly and easily.
Once you feel content with the level of polish in your design, finish up with annotations.
Annotating The Wireframes
At this point, most of your design will be complete, and you are ready to annotate your work.
Being strategic in where and how you place your annotations on the page can improve your workflow and overall quality.
Determine a location. There are different advantages to where you place annotations. See which style below would be most useful to you:
Left or right column: Allows the reader to focus on the design or on reading the annotations.
Inline: Promotes a more connected reading experience by linking explanations directly to UI elements.
Marked tooltips: Similar to inline annotations. Prototyping software such as Axure allows you to place markers directly in the design that can be clicked on to reveal the annotation.
Separate page: Gives ample, dedicated space to view the design and annotations.
44 I drew lines directly from an interaction to show the gesture used and what the resulting state would be. (View large version45)
Load in wireframe images. Designing for a large resolution can leave little space for annotations. Instead, you could wireframe your layouts with the accurate resolutions, and have another document where you drop the same wireframe images into a fixed-size container. This gives you consistent space for annotations, without having to worry about how big the design is.
I’ve created a template46 (Zip, 1.51 MB) that enables you simply to export wireframe images to the image folder and then drag and drop the same images to an annotated InDesign document. As long as you use the same file names for your export, you can continually overwrite the old wireframe images, and they will automatically update in the InDesign document.
Follow these technical writing rules when revising your annotations:
Avoid being wordy. Be direct and concise. Excise words and sentences that do not add any information or that are redundant. Your team and stakeholders want to quickly and easily get the information they need.
Avoid figures of speech and metaphors if your audience might be foreign.
Stick to simple vocabulary so that everyone can understand, but use technical terms if the audience would understand them.
Favor the active voice over the passive voice to cut down wordiness and to be clearer in your explanations. Purdue OWL has an article47 showing examples of the active and passive voice.
Write for developers. Although stakeholders will enjoy story-driven annotations, developers will prefer straightforward, technical explanations. Be extremely detailed about how an interaction works, and include values if necessary. Write your annotations so that anyone could take the design and build it without needing to talk to you.
To compare and contrast, the annotation below is written for a stakeholder who is working on conceptual wireframes (notice the second-person usage and descriptive wording):
As you scroll toward the bottom of the page, you will seamlessly receive more search results so that you can continue reading without needing to perform another action.
Here is the same example written for a developer:
When scroll bar reaches last search result (about 25% height from bottom):
Dynamically load 10 more search results below current list.
If end of search results is reached, remove “Load more…” button.
Show spinner when loading; remove when finished.
Use fade-in and fade-out animation when loading results.
List multiple gestures, states and demos. For each action, indicate the gesture(s), label each annotation by its state, and include demo links if available. If there are multiple states, define their conditions or business logic.
48 My wireframe shows a variety of styles for describing states and gestures. (View large version49)
One of the most common challenges for UX designers is convincing other people of your design decisions. There is a tendency among people to feel that your decisions are arbitrary. If you can muster the time, I have found it helpful to connect previous UX work to a finished design. It goes a long way to reminding your team or stakeholders of the evidence that supports your design.
Site map. In each wireframe, show where this particular screen lives in your site map. Don’t show the entire site map, though, just the immediate parents, siblings and children. You can also refer to page IDs if you are using them in your site map.
Personas and user goals. Include a label of the persona and the major user goals, tasks or behaviors that the screen is targeting. Alternatively, include user story statements and/or features from a feature priority matrix.
User flows. Show the reader which step in the flow they are looking at. Include a portion of the user flow (enough for context), as opposed to the entire flow.
50 The flow below shows where the user is currently, but also shows the previous and next steps. (View large version51)
User research findings. Include user research findings (as bullet points) that directly support your design decisions. These could come from user interviews, ethnographic studies, analytics, competitive analysis, surveys, focus groups or usability tests.
Open questions. If you still need more information from stakeholders, developers or subject-matter experts, provide a list of questions under the annotation to give the reader context. Putting questions in the wireframe has several advantages:
reader will see that you are thinking deeply about the design,
promotes iteration and reduces anxiety about finalizing the design.
convenient for bringing up in presentations.
Usability testing questions. Your designs are not always going to be perfect from the first iteration. Minimize design “paralysis analysis” by choosing a hypothetical direction and then conducting usability tests to guide your design changes. List your user-testing questions so that people can see your thought process and so that you can keep track of contentious topics for your usability test plan.
52 I maintained a list of hypothetical questions on the side to show that I still need user feedback to move forward. (View large version53)
Inevitably, you will iterate through many versions of your wireframes. Including wireframe meta data and keeping track of changes will be helpful not only to other people, but also to you in the long run. Forming this habit takes time, but it’s well worth it.
Include a table of contents. A table of contents is especially important in production wireframes because there will be many pages. Also, InDesign can re-update your table of contents based on any new page changes. Setting up header styles can be finicky, so feel free to use my template54 (ZIP, 1.51 MB) if you need a quick start.
Add a footer. The footer is the best place to include ancillary information about your wireframes. It also keeps your document together in case you print the wireframes and pages go missing. Consider including the following information:
Document name: Could simply include the project’s name, deliverable type and version number.
Page number
Confidential labels: Some companies require that you label documents “Private” or “Confidential.”
Track wireframe revisions. It can be difficult for readers to know what has changed when your wireframes have over 100 pages. So, ahead of your table of contents, include a table of revisions containing the following details:
date,
name of the person who made the revisions,
brief notes or bullet points about what has changed.
Maintain file versioning. Every time you work on a new batch of wireframes (i.e. sending it out to people), create a copy of the previous file before working on the new one. Then, rename it and include at least these details:
Brand or client’s company name: Optional if it doesn’t make sense or if the file name gets too long.
Project name
Type of deliverable: wireframes, in this case
Version number: lead with two 0’s for proper file sorting, because “1” can get incorrectly sorted with “10” and “100.”
Your name or initials: If you expect to collaborate with another designer
Delimiters: Use underscore or hyphen, instead of a space, which sometimes causes issues with file systems.
It could look like this: Google_Youtube_Wireframes_001.graffle.
Or, if you’re collaborating, it could look like this: Apple-iTunes-Wireframes-EL-001.sketch.
Striving for perfection is a great goal, but be practical with your time, too. Most real-world projects don’t have ample timelines, so figure out your priorities, and use the guidelines that make sense.
My goal is to help fill in the gaps of every UX designer’s wireframing process with all of the knowledge I’ve gained over the years. I hope it helps you to perfect your wireframes.
I love to help people out, so let me know in the comments below or contact me if you have questions. Also, please share and spread the love if you’ve found this helpful!
I’m big on modular design1. I’ve long been sold on dividing websites into components, not pages, and amalgamating those components dynamically into interfaces. Flexibility, efficiency and maintainability abound.
But I don’t want my design to look like it’s made out of unrelated things. I’m making an interface, not a surrealist photomontage.
As luck would have it, there is already a technology, called CSS, which is designed specifically to solve this problem. Using CSS, I can propagate styles that cross the borders of my HTML components, ensuring a consistent design with minimal effort. This is largely thanks to two key CSS features:
inheritance,
the cascade (the “C” in CSS).
Despite these features enabling a DRY2, efficient way to style web documents and despite them being the very reason CSS exists, they have fallen remarkably out of favor. From CSS methodologies such as BEM and Atomic CSS through to programmatically encapsulated CSS modules, many are doing their best to sidestep or otherwise suppress these features. This gives developers more control over their CSS, but only an autocratic sort of control based on frequent intervention.
I’m going to revisit inheritance, the cascade and scope here with respect to modular interface design. I aim to show you how to leverage these features so that your CSS code becomes more concise and self-regulating, and your interface more easily extensible.
Despite protestations by many, CSS does not only provide a global scope. If it did, everything would look exactly the same. Instead, CSS has a global scope and a local scope. Just as in JavaScript, the local scope has access to the parent and global scope. In CSS, this facilitates inheritance.
For instance, if I apply a font-family declaration to the root (read: global) html element, I can ensure that this rule applies to all ancestor elements within the document (with a few exceptions, to be addressed in the next section).
html { font-family: sans-serif; } /* This rule is not needed ↷ p { font-family: sans-serif; } */
Just like in JavaScript, if I declare something within the local scope, it is not available to the global — or, indeed, any ancestral — scope, but it is available to the child scope (elements within p). In the next example, the line-height of 1.5 is not adopted by the html element. However, the a element inside the p does respect the line-height value.
html { font-family: sans-serif; } p { line-height: 1.5; } /* This rule is not needed ↷ p a { line-height: 1.5; } */
The great thing about inheritance is that you can establish the basis for a consistent visual design with very little code. And these styles will even apply to HTML you have yet to write. Talk about future-proof!
There are other ways to apply common styles, of course. For example, I could create a .sans-serif class…
.sans-serif { font-family: sans-serif; }
… and apply it to any element that I feel should have that style:
<p>Lorem ipsum.</p>
This affords me some control: I can pick and choose exactly which elements take this style and which don’t.
Any opportunity for control is seductive, but there are clear issues. Not only do I have to manually apply the class to any element that should take it (which means knowing what the class is to begin with), but in this case I’ve effectively forgone the possibility of supporting dynamic content: Neither WYSIWYG editors nor Markdown parsers provide sans-serif classes to arbitrary p elements by default.
That class="sans-serif" is not such a distant relative of style="font-family: sans-serif" — except that the former means adding code to both the style sheet and the HTML. Using inheritance, we can do less of one and none of the other. Instead of writing out classes for each font style, we can just apply any we want to the html element in one declaration:
Some types of properties are not inherited by default, and some elements do not inherit some properties. But you can use [property name]: inherit to force inheritance in some cases.
For example, the input element doesn’t inherit any of the font properties in the previous example. Nor does textarea. In order to make sure all elements inherit these properties from the global scope, I can use the universal selector and the inherit keyword. This way, I get the most mileage from inheritance.
Note that I’ve omitted font-size. I don’t want font-size to be inherited directly because it would override user-agent styles for heading elements, the small element and others. This way, I save a line of code and can defer to user-agent styles if I should want.
Another property I would not want to inherit is font-style: I don’t want to unset the italicization of ems just to code it back in again. That would be wasted work and result in more code than I need.
Now, everything either inherits or is forced to inherit the font styles I want them to. We’ve gone a long way to propagating a consistent brand, project-wide, with just two declaration blocks. From this point onwards, no developer has to even think about font-family, line-height or color while constructing components, unless they are making exceptions. This is where the cascade comes in.
I’ll probably want my main heading to adopt the same font-family, color and possibly line-height. That’s taken care of using inheritance. But I’ll want its font-size to differ. Because the user agent already provides an enlarged font-size for h1 elements (and it will be relative to the 125% base font size I’ve set), it’s possible I don’t need to do anything here.
However, should I want to tweak the font size of any element, I can. I take advantage of the global scope and only tweak what I need to in the local scope.
If the styles of CSS elements were encapsulated by default, this would not be possible: I’d have to add all of the font styles to h1 explicitly. Alternatively, I could divide my styles up into separate classes and apply each to the h1 as a space-separated value:
<h1>Hello World</h1>
Either way, it’s more work and a styled h1 would be the only outcome. Using the cascade, I’ve styled most elements the way I want them, with h1 just as a special case, just in one regard. The cascade works as a filter, meaning styles are only ever stated where they add something new.
We’ve made a good start, but to really leverage the cascade, we should be styling as many common elements as possible. Why? Because our compound components will be made of individual HTML elements, and a screen-reader-accessible interface makes the most of semantic markup.
To put it another way, the style of “atoms” that make up your interface “molecules” (to use atomic design terminology3) should be largely addressable using element selectors. Element selectors are low in specificity4, so they won’t override any class-based styles you might incorporate later.
The first thing you should do is style all of the elements that you know you’re going to need:
The next part is crucial if you want a consistent interface without redundancy: Each time you come to creating a new component, if it introduces new elements, style those new elements with element selectors. Now is not the time to introduce restrictive, high-specificity selectors. Nor is there any need to compose a class. Semantic elements are what they are.
For example, if I’ve yet to style button elements (as in the previous example) and my new component incorporates a button element, this is my opportunity to style button elements for the entire interface.
Now, when you come to write a new component that also happens to incorporate buttons, that’s one less thing to worry about. You’re not rewriting the same CSS under a different namespace, and there’s no class name to remember or write either. CSS should always aim to be this effortless and efficient — it’s designed for it.
Using element selectors has three main advantages:
The resulting HTML is less verbose (no redundant classes).
The resulting style sheet is less verbose (styles are shared between components, not rewritten per component).
The resulting styled interface is based on semantic HTML.
The use of classes to exclusively provide styles is often defended as a “separation of concerns.” This is to misunderstand the W3C’s separation of concerns5 principle. The objective is to describe structure with HTML and style with CSS. Because classes are designated exclusively for styling purposes and they appear within the markup, you are technically breaking with separation wherever they’re used. You have to change the nature of the structure to elicit the style.
Wherever you don’t rely on presentational markup (classes, inline styles), your CSS is compatible with generic structural and semantic conventions. This makes it trivial to extend content and functionality without it also becoming a styling task. It also makes your CSS more reusable across different projects where conventional semantic structures are employed (but where CSS ‘methodologies’ may differ).
Before anyone accuses me of being simplistic, I’m aware that not all buttons in your interface are going to do the same thing. I’m also aware that buttons that do different things should probably look different in some way.
But that’s not to say we need to defer to classes, inheritance or the cascade. To make buttons found in one interface look fundamentally dissimilar is to confound your users. For the sake of accessibility and consistency, most buttons only need to differ in appearance by label.
Remember that style is not the only visual differentiator. Content also differentiates visually — and in a way that is much less ambiguous. You’re literally spelling out what different things are for.
There are fewer instances than you might imagine where using style alone to differentiate content is necessary or appropriate. Usually, style differences should be supplemental, such as a red background or a pictographic icon accompanying a textual label. The presence of textual labels are of particular utility to those using voice-activation software: Saying “red button” or “button with cross icon” is not likely to elicit recognition by the software.
I’ll cover the topic of adding nuances to otherwise similar looking elements in the “Utility Classes” section to follow.
Semantic HTML isn’t just about elements. Attributes define types, properties and states. These too are important for accessibility, so they need to be in the HTML where applicable. And because they’re in the HTML, they provide additional opportunities for styling hooks.
For example, the input element takes a type attribute, should you want to take advantage of it, and also attributes such as aria-invalid6 to describe state.
I don’t need to set color, font-family or line-height here because these are inherited from html, thanks to my use of the inherit keyword. If I want to change the main font-family used application-wide, I only need to edit the one declaration in the html block.
The border color is linked to color, so it too inherits the global color. All I need to declare is the border’s width and style.
The [aria-invalid] attribute selector is unqualified. This means it has better reach (it can be used with both my input and textarea selectors) and it has minimal specificity. Simple attribute selectors have the same specificity as classes. Using them unqualified means that any classes written further down the cascade will override them as intended.
The BEM methodology would solve this by applying a modifier class, such as input--invalid. But considering that the invalid state should only apply where it is communicated accessibly, input--invalid is necessarily redundant. In other words, the aria-invalid attribute has to be there, so what’s the point of the class?
My absolute favorite thing about making the most of element and attribute selectors high up in the cascade is this: The composition of new components becomes less a matter of knowing the company or organization’s naming conventions and more a matter of knowing HTML. Any developer versed in writing decent HTML who is assigned to the project will benefit from inheriting styling that’s already been put in place. This dramatically reduces the need to refer to documentation or write new CSS. For the most part, they can just write the (meta) language that they should know by rote. Tim Baxter also makes a case for this in Meaningful CSS: Style It Like You Mean It7.
So far, we’ve not written any component-specific CSS, but that’s not to say we haven’t styled anything. All components are compositions of HTML elements. It’s largely in the order and arrangement of these elements that more complex components form their identity.
Which brings us to layout.
Principally, we need to deal with flow layout — the spacing of successive block elements. You may have noticed that I haven’t set any margins on any of my elements so far. That’s because margin should not be considered a property of elements but a property of the context of elements. That is, they should only come into play where elements meet.
Fortunately, the adjacent sibling combinator8 can describe exactly this relationship. Harnessing the cascade, we can instate a uniform default across all block-level elements that appear in succession, with just a few exceptions.
The use of the extremely low-specificity lobotomized owl selector9 ensures that any elements (except the common exceptions) are spaced by one line. This means that there is default white space in all cases, and developers writing component flow content will have a reasonable starting point.
In most cases, margins now take care of themselves. But because of the low specificity, it’s easy to override this basic one-line spacing where needed. For example, I might want to close the gap between labels and their respective fields, to show they are paired. In the following example, any element that follows a label (input, textarea, select, etc.) closes the gap.
Once again, using the cascade means only having to write specific styles where necessary. Everything else conforms to a sensible baseline.
Note that, because margins only appear between elements, they don’t double up with any padding that may have been included for the container. That’s one more thing not to have to worry about or code defensively against.
Also, note that you get the same spacing whether or not you decide to include wrapper elements. That is, you can do the following and achieve the same layout — it’s just that the margins emerge between the divs rather than between labels following inputs.
Achieving the same result with a methodology such as atomic CSS10 would mean composing specific margin-related classes and applying them manually in each case, including for first-child exceptions handled implicitly by * + *:
Bear in mind that this would only cover top margins if one is adhering to atomic CSS. You’d have to prescribe individual classes for color, background-color and a host of other properties, because atomic CSS does not leverage inheritance or element selectors.
Atomic CSS gives developers direct control over style without deferring completely to inline styles, which are not reusable like classes. By providing classes for individual properties, it reduces the duplication of declarations in the stylesheet.
However, it necessitates direct intervention in the markup to achieve these ends. This requires learning and being commiting to its verbose API, as well as having to write a lot of additional HTML code.
Instead, by styling arbitrary HTML elements and their spacial relationships, CSS ‘methodology’ becomes largely obsolete. You have the advantage of working with a unified design system, rather than an HTML system with a superimposed styling system to consider and maintain separately.
Anyway, here’s how the structure of our CSS should look with our flow content solution in place:
global (html) styles and enforced inheritance,
flow algorithm and exceptions (using the lobotomized owl selector),
element and attribute styles.
We’ve yet to write a specific component or conceive a CSS class, but a large proportion of our styling is done — that is, if we write our classes in a sensible, reusable fashion.
The thing about classes is that they have a global scope: Anywhere they are applied in the HTML, they are affected by the associated CSS. For many, this is seen as a drawback, because two developers working independently could write a class with the same name and negatively affect each other’s work.
CSS modules11 were recently conceived to remedy this scenario by programmatically generating unique class names tied to their local or component scope.
<!-- my module's button --> <button>Press me</button> <!-- their module's button --> <button>Hit me</button>
Ignoring the superficial ugliness of the generated code, you should be able to see where disparity between independently authored components can easily creep in: Unique identifiers are used to style similar things. The resulting interface will either be inconsistent or be consistent with much greater effort and redundancy.
There’s no reason to treat common elements as unique. You should be styling the type of element, not the instance of the element. Always remember that the term “class” means “type of thing, of which there may be many.” In other words, all classes should be utility classes: reusable globally.
Of course, in this example, a .button class is redundant anyway: we have the button element selector to use instead. But what if it was a special type of button? For instance, we might write a .danger class to indicate that buttons do destructive actions, like deleting data:
.danger { background: #c00; color: #fff; }
Because class selectors are higher in specificity than element selectors and of the same specificity as attribute selectors, any rules applied in this way will override the element and attribute rules further up in the style sheet. So, my danger button will appear red with white text, but its other properties — like padding, the focus outline, and the margin applied via the flow algorithm — will remain intact.
<button>delete</button>
Name clashes may happen, occasionally, if several people are working on the same code base for a long time. But there are ways of avoiding this, like, oh, I don’t know, first doing a text search to check for the existence of the name you are about to take. You never know, someone may have solved the problem you’re addressing already.
My favorite thing to do with utility classes is to set them on containers, then use this hook to affect the layout of child elements within. For example, I can quickly code up an evenly spaced, responsive, center-aligned layout for any elements:
.centered { text-align: center; margin-bottom: -1rem; /* adjusts for leftover bottom margin of children */ } .centered > * { display: inline-block; margin: 0 0.5rem 1rem; }
With this, I can center group list items, buttons, a combination of buttons and links, whatever. That’s thanks to the use of the > * part, which means that any immediate children of .centered will adopt these styles, in this scope, but inherit global and element styles, too.
And I’ve adjusted the margins so that the elements can wrap freely without breaking the vertical rhythm set using the * + * selector above it. It’s a small amount of code that provides a generic, responsive layout solution by setting a local scope for arbitrary elements.
My tiny (93B minified) flexbox-based grid system12 is essentially just a utility class like this one. It’s highly reusable, and because it employs flex-basis, no breakpoint intervention is needed. I just defer to flexbox’s wrapping algorithm.
.fukol-grid { display: flex; flex-wrap: wrap; margin: -0.5em; /* adjusting for gutters */ } .fukol-grid > * { flex: 1 0 5em; /* The 5em part is the basis (ideal width) */ margin: 0.5em; /* Half the gutter value */ }
Fukol’s distinctive logotype
Using BEM, you’d be encouraged to place an explicit “element” class on each grid item:
<div> <!-- the outer container, needed for vertical rhythm --> <ul> <li></li> <li></li> <li></li> <li></li> </ul> </div>
But there’s no need. Only one identifier is required to instantiate the local scope. The items here are no more protected from outside influence than the ones in my version, targeted with > * — nor should they be. The only difference is the inflated markup.
So, now we’ve started incorporating classes, but only generically, as they were intended. We’re still not styling complex components independently. Instead, we’re solving system-wide problems in a reusable fashion. Naturally, you will need to document how these classes are used in your comments.
Utility classes like these take advantage of CSS’ global scope, the local scope, inheritance and the cascade simultaneously. The classes can be applied universally; they instantiate the local scope to affect just their child elements; they inherit styles not set here from the parent or global scope; and we’ve not overqualified using element or class selectors.
Here’s how our cascade looks now:
global (html) styles and enforced inheritance,
flow algorithm and exceptions (using the lobotomized owl selector),
element and attribute styles,
generic utility classes.
Of course, there may never be the need to write either of these example utilities. The point is that, if the need does emerge while working on one component, the solution should be made available to all components. Always be thinking in terms of the system.
We’ve been styling components, and ways to combine components, from the beginning, so it’s tempting to leave this section blank. But it’s worth stating that any components not created from other components (right down to individual HTML elements) are necessarily over-prescribed. They are to components what IDs are to selectors and risk becoming anachronistic to the system.
In fact, a good exercise is to identify complex components (“molecules,” “organisms”) by ID only and try not to use those IDs in your CSS. For example, you could place #login on your log-in form component. You shouldn’t have to use #login in your CSS with the element, attribute and flow algorithm styles in place, although you might find yourself making one or two generic utility classes that can be used in other form components.
If you do use #login, it can only affect that component. It’s a reminder that you’ve moved away from developing a design system and towards the interminable occupation of merely pushing pixels.
When I tell folks that I don’t use methodologies such as BEM or tools such as CSS modules, many assume I’m writing CSS like this:
header nav ul li { display: inline-block; } header nav ul li a { background: #008; }
I don’t. A clear over-specification is present here, and one we should all be careful to avoid. It’s just that BEM (plus OOCSS, SMACSS, atomic CSS, etc.) are not the only ways to avoid convoluted, unmanageable CSS.
In an effort to defeat specificity woes, many methodologies defer almost exclusively to the class selector. The trouble is that this leads to a proliferation of classes: cryptic ciphers that bloat the markup and that — without careful attention to documentation — can confound developers new to the in-house naming system they constitute.
By using classes prolifically, you also maintain a styling system that is largely separate from your HTML system. This misappropriation of ‘separate concerns’ can lead to redundancy or, worse, can encourage inaccessibility: it’s possible to affect a visual style without affecting the accessible state along with it:
<input aria-invalid="false" />
In place of the extensive writing and prescription of classes, I looked at some other methods:
leveraging inheritance to set a precedent for consistency;
making the most of element and attribute selectors to support transparent, standards-based composition;
applying a code- and labor-saving flow layout system;
incorporating a modest set of highly generic utility classes to solve common layout problems affecting multiple elements.
All of these were put in service of creating a design system that should make writing new interface components easier and less reliant on adding new CSS code as a project matures. And this is possible not thanks to strict naming and encapsulation, but thanks to a distinct lack of it.
Even if you’re not comfortable using the specific techniques I’ve recommended here, I hope this article has at least gotten you to rethink what components are. They’re not things you create in isolation. Sometimes, in the case of standard HTML elements, they’re not things you create at all. The more you compose components from components, the more accessible and visually consistent your interface will be, and with less CSS to achieve that end.
There’s not much wrong with CSS. In fact, it’s remarkably good at letting you do a lot with a little. We’re just not taking advantage of that.
Some like it loud, others need some steady beats to stay focused, others calm tunes. A while ago we asked on Twitter1 and Facebook2 what music the web community is listening to when coding and designing.
The answers were as diverse as the community itself and certainly too good to live an existence only in a Twitter discussion. That’s why we’ve compiled those hand-crafted playlists, favorite artists, and loved soundtracks in this article to see which tunes fuel the web, and, well, first and foremost, to provide you with some new ear candy to get you through lengthy coding and design sessions, of course. Get your headphones ready!
Positive psychology describes flow as the mental state when you get fully immersed in what you’re doing, feeling energized, focused, and involved. These playlists will tickle your brain to help you reach that much sought-after state.
As developers, are we paid to write code? This challenging question raises concerns about product quality, code quality, and our purpose as developers in a world of coded applications. You’ll find an interesting post that dives deeper into the matter in the “Work & Life” section of our reading list this week.
But we have other amazing resources to look at this week, too: new tools, new tutorials, and we’ll also take some time to reconsider CSS print styles. Let’s get started!
Firefox 50 was released this week1. The new version comes with support for the once option for Event Listeners, the referrerpolicy attribute and a fix for dashed and dotted borders. On the other hand, box-sizing: padding-box was removed. The upcoming version, Firefox 512, which is currently in beta, will introduce a couple of changes, too: <img> with empty src will now fire an error event and JavaScript will be blocked if it’s served with a wrong MIME type. Furthermore, the non-standard Web Payments API will be removed, Accept header for XHR will be simplified, and SHA-1 certificates issued by public CA will no longer be accepted.
Splittable5 is a next-generation module bundler for JavaScript that aims at combining efficiency with ease of use. It supports code splitting and tree shaking and uses Babel and Browserify to resolve modules and their dependencies and Google’s Closure Compiler for efficient compilation of code. Definitely one of the most advanced module bundlers available today. Unfortunately, it still needs the Java version of Closure Compiler to work, since the JavaScript variant doesn’t support the relevant feature yet.
blake2x6 is a new hashing function that is even better than blake2. It does not only allow hashes of any arbitrary size but also has a key derivation function and a deterministic random bit generator.
Do you have a plan for your hiring interviews? The people at GitLab certainly have, and they share it with the public: Read their Hiring Guide18 to get some useful advice on writing job ads, handling rejections, and conducting interviews.
Garann Means quit the web industry about two years ago. Now she shares what that really meant to her19, why she did it, and why it’s important that we think very carefully about it before we take this step for real. It’s easy to joke about leaving the industry, but the consequences are real and might differ a lot from what we expect.
Theo Nicolaou wrote about web development and pressure20. Even if we don’t read articles every day, work on side-projects all the time, or contribute to open-source projects regularly, the web will still be here tomorrow, and we can still help to move it forward and make an impact. We need to remind ourselves that sometimes it’s okay to just do something different, to relax or go out with friends.
“You Are Not Paid to Write Code21.” Tyler Treat wrote about our job as developers and why we introduce the possibility of failure into a system every time we write code or introduce third-party services. Our job is to find solutions that (if possible) don’t require a new system and to keep out everything else from a codebase unless it’s really necessary.
With Thanksgiving coming up next week, have you already thought about ways how to spend your days before the holiday? Well, you could send simple “Thank You” emails to your past clients, perhaps design something free for somebody, or take some time to improve your website. To those of you who celebrate Thanksgiving, we’ve got a nice icon set for you today — all available in PNG, PSD, AI and SVG formats.
This set of 15 free icons was created by the design team at ucraft1. Please note that this icon set is licensed under a Creative Commons Attribution 3.0 Unported2. You may modify the size, color or shape of the icons. No attribution is required, however, reselling of bundles or individual pictograms is not cool. Please provide credits to the creators and link to the article in which this freebie was released if you would like to spread the word in blog posts or anywhere else.
3 Some pixel-perfect icons to welcome and celebrate Thanksgiving. (Full preview864)5 Embrace Thanksgiving with pumpkins and pilgrim hats. (Full preview864)7 Don’t forget to be thankful. (Full preview864)
“Autumn is here and Thanksgiving is just around the corner and we can’t imagine a better time to share this set of icons with you. In the spirit of giving back we decided to create 15 icons to help you celebrate this holiday. Spruce up your commercial project and give it that homely and warm tone. You can also share them with your family and friends (that’s entirely up to you); just be sure that you are kind and grateful to people around you.”
A big thank you to the folks behind ucraft — we sincerely appreciate your time and efforts. Keep up the brilliant work!
Imagine a cloudy, rainy November evening. After a long day, you walk home along the streets, following the dimmed street lamps. Everybody seems to be busy, rushing somewhere, crossing paths with strangers and lonely stores. It’s dark and cold outside, and it’s difficult to see things through, so you decide to take a shortcut route to shorten the path.
Suddenly you see a bright light and music streaming from one of the remote corners of the street. Out of curiosity, you slowly walk towards the light, and hold your breath for a second. You discover a cozy little place with a fireplace, packed with people, jazzy tunes, and the smell of pizza, pasta and red wine. You see people smiling. Talking. Laughing. Sharing. Inviting you to join them.
1 That’s right! Somethin’ is cookin’ in the kitchen!
You probably have a whole bunch of reasons to keep on walking down that street, but what if you walked inside instead? Well, that’s what joining the Smashing Conference experience feels like: It’s an intimate, personal, friendly experience for web designers and developers — in a cozy venue with charm and personality, with people who deeply care about the quality of their work. Don’t take our word — see for yourself2.
Guess what: we have SmashingConf San Francisco 20173 coming up in April next year, featuring tasty front-end ingredients, UX recipes and neat design beats from the hidden, remote corners of the web. 1 track, 2 conference days, 8 workshops, 16 excellent speakers and just 500 available tickets, taking place on April 4–5, 2017. And it’s going to be… smashing!
We’ve put aside 50 early-bird tickets, and if you book a workshop6, too, you’ll save $100 off the conference and workshop price. That pretty smashing, isn’t it?
Also, in case you get a hard time taking a few days off, we’ve got your back: You can always use the Convince Your Boss PDF7 (0.1 Mb) to convince… well, whoever you have to convince! To the tickets.8
About The Conference
So you know what’s going on in front-end. You’ve been working with pattern libraries and atomic design and Gulp and SMCSS and BEM and HTTP/2 and Flexbox and SVG. What you might not know though is what pitfalls and traps other web designers have encountered in practice — to prevent issues creeping up on you later on.
With our conference in San Francisco9, we bring together experienced speakers to share practical front-end and UX techniques and pitfalls they ran into, lessons they’ve learned and the workflows they’ve chosen to stay efficient. Expect an intimate, hands-on conference experience, with lots of learning, sharing and networking along the way. Admittedly, we can’t solve every problem faced by the web community, but for front-end and UX, these conferences will push your boundaries significantly and give you answers you can take to the bank.
10 SmashingConf SFO 201711 is a two-day event taking place in the very heart of San Francisco. If you’ve always wanted to visit the city, or just happen to live around the corner (well, more or less), this is just the opportunity you’ve been waiting for. (Image credit12)
The conference will cover CSS/JavaScript techniques, SVG and Flexbox gotchas, architecting and “selling” design systems libraries, performance optimization and psychology insights, UX strategies and design workflows, tips on establishing and maintaining pattern libraries, and steps to produce resilient, fast responsive websites. All learned from actual, real-life projects.
We don’t care about trends, but we do care about smart solutions. We love exploring how designers and developers work and how actual problems are solved—ideas and techniques that actually worked, or failed in real-life projects, and why exactly they failed and what decisions were made instead. All those things that help us make smarter design decisions and build better products, faster.
That’s exactly what the conference will be about. No theory, no fluff, just curated quality content. 2 conference days, 1 track, hands-on workshops13 and 16 speakers14, taking place on April 4–5, 2017 in the beautiful and iconic Palace of Fine Arts. Of course, we embrace respect and tolerance with our code of conduct15.
For this year’s line-up, we invited experts who have worked in small as well as large companies. People who spend day and night working and playing with web technologies. It doesn’t get more practical than that, does it? Get ready, set, go:
16 Our first confirmed speakers, an astronomist Nadieh Bremer and design systems designer Nathan Curtis. Seriously.
Our workshops offer the opportunity to get to grips with new ideas and techniques in real depth, with a full day spent on the topic of your choice. It’s a great way to round off your conference experience, and we provide lunch, too. By registering for a workshop while buying your conference ticket, you’ll save $100 on the regular workshop ticket price.
In this full day checkout optimization workshop Christian Holst, research director at the Baymard Institute, will share their newest checkout usability test findings, uncovered during the past 7 years of large-scale testing of e-commerce sites and from working with clients like Etsy, Office Depot, Sears, Kohl’s, Nike, John Lewis, Carnival, T-mobile, Overstock.com, The North Face, etc.Read more…34
The role of design with large organizations is expanding, spreading across product teams and influencing decision-making at higher and higher levels. This scale makes it increasingly challenging to align designers and product teams to deliver cohesive, consistent experiences across a customer journey.Read more…37
In this hands-on workshop, you’ll learn front-end techniques and strategies you need to know today to make proper use of HTTP/2 tomorrow. The workshop will also look into dealing with legacy browsers that don’t support HTTP/2 as well as the security aspects of how you can keep your website or application safe, future-proof and blazingly fast.Read more…40
In this workshop, Vitaly Friedman (editor-in-chief of Smashing Magazine), will cover practical techniques, clever tricks and useful strategies you need to be aware of when working on responsive websites. From responsive modules co clever navigation patterns and web form design techniques; the workshop will provide you with everything you need to know today to start designing better responsive experiences tomorrow.Read more…43
Smashing Workshops on Thursday, April 6th, 2017Link
In this full-day workshop, Sarah will teach you the basics of the SVG Animation development and the essentials needed to start using these techniques in production environments for animations both large and small.Read more…46
This workshop is designed for designers and developers who already have a good working knowledge of HTML and CSS. We will cover a range of CSS methods for achieving layout, from those you are safe to use right now even if you need to support older version of Internet Explorer through to things that while still classed as experimental, are likely to ship in browsers in the coming months.Read more…49
With so many tools available to visualize your data, it’s easy to get stuck in thinking about chart types, always just going for that bar or line chart, without truly thinking about effectiveness. In this workshop, Nadieh will teach you how you can take a more creative and practical approach to the design of data visualization.Read more…52
In this full-day workshop, Vitaly Friedman, editor-in-chief of Smashing Magazine, will present practical techniques, clever tricks and useful strategies you need to be aware of when working on any responsive design project. Most techniques are borrowed from mid-size and large-scale real-life projects, such as large e-commerce projects, online magazines and Web applications.Read more…55
Pretty much because of the value it will provide. We’ll explore how designers and developers work, design and build and how they approach problems strategically. Think of it as a playbook with handy rules of thumb for your next projects: it can’t get more practical than this. Learn:
Strategies for building fast responsive websites,
Clever techniques for better front end,
Rules of thumb for better transitions and animations,
Strategy to break out of the generic layouts,
Approaches for better visual/brand identity design,
Guidelines for building pattern libraries,
How to build accessible and future-proof UIs,
Mistakes and lessons learned from large projects,
How to apply psychology in design decisions,
How to improve conversion rates in eCommerce projects,
How to craft responsive HTML email for Gmail, Yahoo and common mail clients,
How to tackle complexity when building a delightful, responsive user experience,
…more practical takeaways from real-life projects.
So you need to convince your manager to send you to the SmashingConf? No worries, we’ve got your back! We prepared a neat Convince Your Boss (PDF)56 (0.15 Mb) that you can use to convince your colleagues, friends, neighbors and total strangers to join you or send you to the event. We know that you will not be disappointed. Still not good enough? Well, tweet us @smashingconf and we’ll help you out — we can be quite convincing, too, you know!
57 “8 reasons why you should send your incredibly hard-working, deserving employee to the SmashingConf” (PDF58). Quite self-explanatory, really.
We do everything possible to keep ticket prices affordable for everyone, and we welcome sponsors to help us create a truly unique, unforgettable conference experience. And you can be a major part of it. We have some attractive and creative sponsorship packages for you, and we are also flexible and would love to adjust them to your needs. So if you’re interested, please email Mariona at mariona@smashingconf.com59 — we’d love for you to be involved!
We’d love you to come and join us. Walk in. Take a seat. We are looking forward to seeing you in San Francisco, and who knows, perhaps months later after the conference is over, you’ll look back at your workflow, at your projects and at this very post realizing that it wasn’t that off after all. Grab your ticket and see you there! 😉
I recently spoke with a back-end developer friend about how many hours I spend coding or learning about code outside of work. He showed me a passage from an Uncle Bob book, “Clean Code”, which compares the hours musicians spend with their instruments in preparation for a concert to developers rehearsing code to perform at work.
I like the analogy but I’m not sure I fully subscribe to it; it’s that type of thinking that can cause burnout in the first place. I think it’s great if you want to further your craft and broaden your skill set, but to be doing it every hour of the day isn’t sustainable.
Front-end fatigue is very real. I’ve seen a number of posts on JavaScript fatigue but I think the problem extends further than that specific language.
To be clear, this isn’t another rant about how it’s all bad and everything is moving too fast — I love that technology is evolving so rapidly. Equally, I can appreciate how it can be overwhelming and have certainly felt flushed out myself at times.
As far as I can tell, this is a two-pronged problem.
The first is that as a front-end developer you think you’re expected to have all of the following in your arsenal:
HTML (writing clean, semantic markup)
CSS (Modular, scalable)
CSS methodologies (BEM, SMACSS, OOCSS)
CSS preprocessors (something like LESS, SCSS, PostCSS)
A basic understanding of whatever back-end language is being used
And on top of that you’re either dabbling with or looking towards things like:
Service workers
Progressive Web Apps (PWA)
Web Components
The second is that your day-to-day work probably doesn’t cover it all or give you time to learn it all, so how are you going to make sure you have all the tools at your disposal?
1 Hearing terms such as “Progressive Web Apps” can be quite daunting to developers’ ears. New techniques and technologies lead to the feeling of fatigue — front-end fatigue. (Image credit2)
Now, as a consumer you might:
Subscribe to a bunch of different weekly development newsletters
Trawl your Twitter feed
Attend a weekly catch up your Front-end team at work
Have a Slack channel outside of work with a handful of devs that you also talk shop with
Follow online tutorials (that hopefully aren’t out of date)
Buy web development books (that hopefully aren’t out of date)
Attend meetups
Attend conferences
Attend training courses
As a contributor you might:
Write blogs/magazine articles
Dabble in speaking
Run a podcast
Contribute to open-source projects
Have your own side projects
Recently I found my attention being split three ways, I was focusing a third on writing code, with headphones on half-listening to discussions about code whilst chatting on Slack about code. I decided enough was enough — every orifice was clogged with code and I was mentally drained.
Whilst that is certainly at the extreme end, I’m sure others of you have experienced something similar. On top of all this you probably have a full-time job, family, friends, hobbies. It’s no wonder that there are so many of us feeling burnt out and wondering if we made the right career choice.
Some of my fellow front-ends have expressed interest in packing it all in and switching job to one where they can turn off at five o’clock. But part of me thinks this job attracts a certain type of person and if we were to throw it all away and become an estate agent instead, you’d still want to be the best estate agent you can be. Attending estate agency meetups and tracking house price trends in your free time. Many moons ago I worked in finance and I was still studying in my evenings and reading around it to become the most skilled I could in my chosen field.
We’re not alone in this discipline, a lot of professions require a solid amount of dedication and learning outside of work. Maybe the thing with front-end development is that the technology evolves so fast that it feels like someone keeps moving the goal posts. It seems like every other day I receive an email saying “XYZ” technology is dead. Which I’m sure can’t be true because otherwise we’d have no tech left.
The ecosystem is in a state of constant change and I think that can be a good thing. Personally I love being in a role where I can constantly learn develop and push myself but that’s not to say I don’t get overwhelmed at times.
With that in mind, here are some things I try to remember in order to stop my head exploding as well as some general advice on how to avoid the fatigue.
The developers I know, both at work and outside of it are amongst the smartest people I know. But they are all feeling overwhelmed. Most have some sort of wish list of technologies that they are trying to learn. There might be a handful of people who know it all and are on top of everything, but the majority of us are in the exact same position.
We’re all still reliant on Google and Stack Overflow to get us through the day and have far too many tabs open filled with answers to web related questions. You’re not alone!
Be happy in the knowledge that you’re not a bad developer just because you haven’t tried whatever the cool kids are using yet.
Yes, even the “web celebs” are in the same spot…
There’s no way you can know everything and the rock star developers you follow on Twitter tend to be really really good in a few areas each. You’ll notice that they’re the same areas they are famous for being knowledgeable about. Again there will be exceptions but they’re just humans like us. 🙂
I know several great front-end developers that won’t apply for roles because they’d feel like a fraud going for them without knowing all the things on the job description requirements. To quote one of them:
“90% of the JDs I see make me think “Argh, I’m so behind!” In fact, it bothers me so much, that I’m thinking about staying in my current role, and just trying to push for more money simply because I feel like I’ve “gotten away with it” here.”
The fact is, most of those job specs are a farce. My friend Bård4 put together this great image that shows the difference between what front-end job specs say and what they mean.
Just remember, it will be ok. Every job I’ve had I’ve felt out of my depth to start with, but eventually you get used to their tools and workflow, you learn and become a better developer for it.
Don’t be afraid to learn on the job, the best way to pick up new skills is to be using them every day.
If you’ve got imposter syndrome, odds are you’re actually a decent developer because otherwise you wouldn’t be self aware enough to realise it.
It’s easy to get distracted by the shiny and new but if your foundations aren’t solid then odds are what you’re building won’t stand the test of time.
As a good friend of mine said to me once:
“Focus on the fundamentals has always been my mantra. If you can build good sh!t and solve problems then that’s all that matters, how you solve them (the tools) has and will always change.”
For example, when React catapulted to fame it always seemed to be bundled up with ES6, and I put my focus on those changes or additions to the language rather than the nuances of the framework itself. Once React is dead and gone, the knowledge I’ve picked up from keeping on top of the latest vanilla Javascript will live on. A lot of the features you can play about with natively in Chrome so you don’t have to pull in Babel and get bogged down in dependency hell to play with it.
This is really key. I don’t think it’s the new frameworks, libraries and modules that are killing us, it’s our own belief that we have to learn them all.
With learning I find the best bet is to keep it focused — at the moment I’m delving into functional JavaScript programming in ES6.
There are tons of other things on my list that I’d like to learn, but I try not to get distracted. For example, I would love to brush up on my accessibility knowledge, play around with Polymer and dive into some of the latest CSS techniques like Grid but if I start reading about too many different areas at once I won’t retain all the information. These other things aren’t going anywhere, I’ll get to them when I get to them.
Avoid rushing to try and consume everything on a given topic. Take your time and make sure you thoroughly understand it.
If you’re like me, you’ll have an ever-growing list, but don’t be afraid to cull items from it. Not everything is worth investing time in and you should try to recognize what is worth learning and what is likely to be gone in a couple of years. Taking time to learn programming design patterns and architectural techniques is always going to be more beneficial in the long run rather than leaping to the current hotness in framework land. You’ll only end up scrambling to play buzzword bingo again a short while down the track.
Most Companies Aren’t Using Bleeding Edge Tech Link
There is a lot of new stuff coming out, the web is progressing at a staggering rate but typically it will take a long time before businesses actually start adopting these new technologies. The majority of companies will wait for a technology to mature for a while and see it proven in the field.
Angular8 was created six years ago and I first started working at a startup who decided it was the framework for them three years ago. Reactjs9 has been about for just over three years and my current company started using it just before Christmas. I’m sure a lot of other frameworks have come and gone in that time. If I’d jumped on them all I’d be going crazy.
In CSS land, Flexbox has been available since 2010 — six years ago! Browser support is still limited. We started using it in production earlier this year, but I don’t see it being used much in the wild elsewhere.
My point being, there is no rush to learn all the things, whilst technology might move quickly your potential employers are moving at a much slower pace. You don’t have to be ahead of the curve, just make sure you’re keeping an eye on it’s trajectory.
The More You Learn, The More You Discover You Don’t Know, And That’s Okay Link
This is totally normal. When you first start out, you don’t know what you don’t know. Then you learn some stuff and decide you’re a genius. Then little by little that fantasy unravels and you start to comprehend actually how much there is out there that you don’t know.
Essentially, the more experience you get, the deeper into the void you go. You need to make peace with this, otherwise it will consume you. If anything, this feeling should give you the confidence that you’re heading in the right direction. Odds are in our chosen profession you’ll never comfortably be able to sit on a throne constructed from all front-end knowledge.
It’s easy to feel that you’re so far behind you need to be coding and learning every minute. This is a one-way ticket to burnout-ville. Set some time aside to develop your skillset, see if you can negotiate some time with your boss so it’s scheduled in and spend the rest of the time doing what you love.
I’ve had some of my coding epiphanies at the gym. Exercising is extremely important for your mind as well as your body. Try and do at least 20–30 minutes a day to keep your mind sharp and help prevent burnout.
Make time for your family and friends — try not to talk shop with them!
Don’t be worried about finding a job right now. At the moment we’re in a very fortunate position where there are more roles than developers to fill them. I don’t know how long this will last, but capitalise on it now!
You can get a job without knowing all the things. I’ve found that in the interviews I’ve carried out 99% of people are totally blagging it.
Worst case scenario, remember that there’s gold in legacy code. If you’re a developer that loves the old ways there will always be companies stuck on legacy tech that need developers to work on their software.
I hope some of these pointers have helped mitigate some of the frustrations you might be feeling. The worst thing you can do is reach the edge and become fully burnt out because once you are, it’s very hard to regain that passion you had for what you do and why you started doing it in the first place.
If you’re a visual designer, you probably spend a majority of your time making small adjustments to multiple visual elements. Maybe your client has decided they need a few more pixels of padding between each of your elements, or perhaps they’ve decided that all of their avatars needed to have rounded corners. Any which way, you might find yourself making the same adjustment in your design over and over… and over again.
In Adobe Experience Design CC (Beta), we’ve introduced the Repeat Grid feature to address this tedious aspect of a designer’s workflow. In this article, we’ll dig deep to uncover the true power of this time-saving feature. We’ll create and adjust a Repeat Grid, add content to it, and wire it up in Adobe XD’s simple and powerful Prototype Mode. If you’d like to follow along, you can download and test Adobe XD1 for free.
At its core, a Repeat Grid is a special type of group. Just like we group objects, we’ll create our Repeat Grid by selecting an object or a group of objects and convert them to a Repeat Grid. In this exercise, we’ll make a simple phone contact list with an image and a name.
From the welcome screen, select an artboard type to start a new file.
Draw a rectangle using the Rectangle tool (R).
To the right of your rectangle, use the Text tool (T) to type in some placeholder text.
Using the Selection tool (V), select both objects, either by marquee selecting (drawing a box around both objects), or by selecting one object and Shift-selecting the other.
Note that we do not need precision at this point, as we can adjust the elements later.
Convert the selection to a Repeat Grid by clicking on the button in the Property Inspector or by using the shortcut key Cmd + R.
Our group is now a Repeat Grid. You can see that it now has two handles, one on the right and one on the bottom, and the box around your group is a green, dotted line.
You can create your Repeat Grid out of any items. (Large view2.)
Click and drag the right handle to the right, expanding the Repeat Grid. To expand the Repeat Grid down, drag the bottom handle down.
We now have repeated elements in our Repeat Grid. All of the styles we apply to any object will be to all repeated versions of it.
Step 3: Adjust Any Elements Within Your Repeat Grid Link
Like any group, we can access the Repeat Grid’s component elements by double clicking into the group. Once we’ve made our changes, we can exit the edit context by pressing the Escape key. However, there are other ways to access the component elements. For instance, we can drill down into the element in the Layers panel (Cmd + Y) or by direct selecting it (Cmd + Click).
Using the Selection tool (V), double click on any rectangle in the Repeat Grid. You should now see a light blue box around the cell you’re editing. Select and drag your text so that it’s aligned to your rectangle.
Click on the Text object and change the typeface and size in the Property Inspector on the right. All of your text objects share the same style.
Press Escape to exit the edit context and move the Repeat Grid so that it’s aligned to the artboard.
When you make adjustments to the attributes of any objects, they apply to all cells in the Repeat Grid. (Large view3.)
Step 4: Adjust The Row And Column Padding In Your Repeat Grid Link
Now that we have our Repeat Grid, we can begin to adjust the space between each row and column. By hovering over the gap between elements, we can activate the column and row indicators and change them to our liking.
Place your cursor between the right side of a text element and the left side of a rectangle, directly in the column gutter. Once the pink column indicator is displayed, drag the right side of the gutter left and right until it’s set to 30.
Place your cursor between rectangles, directly in the row gutter. Once the pink row indicator displays, drag the bottom of the gutter up and down until it’s set to 30.
Continue to adjust the spacing between cells and the size of the Repeat Grid until you have the right number of elements to fit your artboard.
You can easily adjust padding between cells by hovering over the gutters. (Large view4.)
You can convert any set of objects into a Repeat Grid. Those objects become a cell in the Repeat Grid. You can then edit the cell and adjust the gap between rows and columns.
Now that we have the overall shape of our contacts list, we can populate it with content. The simplest way to populate is to change each element separately.
Cmd + Click a text object in your Repeat Grid to select it. You’re now in the Repeat Grid’s edit context mode.
Double click the text element to edit it and change the text to a name. Note that the content isn’t applied to all of the other text objects in the Repeat Grid. However, any style applied to the text object applies to all text objects.
Drag an image into one of the rectangles to import it. Your image will be applied as the fill for the rectangle, and automatically resizes to fill the shape. We call this feature auto-masking.
Drag a second image into the second rectangle. We define order in the Repeat Grid in left-to-right reading order (left to right, then top to bottom). Note that the Repeat Grid now alternates between the first photo and the second photo. We’ve now created a 2-photo pattern.
Drag a third image into the fourth rectangle. Now that you’ve dragged an item into the fourth rectangle, we have a 4-photo pattern, with the first and third being identical images.
Drag a fourth image into the first rectangle. This replaces the first element in your 4-photo pattern, so you should now have four unique photos in your pattern.
You can create overrides with text and patterns with images in Repeat Grid. (Large view5.)
Text works on the concept of overrides; we can override the content of a text object itself, but the styles remain applied to all repetitions of the object. However, we can build out the concept of repeated patterns with auto-masked objects, where the image fill of an object is repeated in a pattern that you define. For instance, if you dragged your third image into the third rectangle, you would have created a 3-photo pattern. Similarly, if you had dragged an image into the fifth rectangle, you would have created a 5-photo pattern.
However, that can get really tedious. Instead, what we’ll do is use content that we’ve prepared ahead of time.
Step 3: Drag A Return-Separated Text File To Your Text Object Link
Create a text file with the extension .txt. You can create this using Mac’s TextEdit (select Format > Make Plain Text) or any text editor you prefer. Separate each piece of data with a return.
Once you’ve saved the file, drag it from Finder and onto your Repeat Grid’s text object in Adobe XD to import the data.
Now our object repeats based on the number of lines in our text file. If our text file has four lines, it’ll place a line per text object and repeat after placing the first four.
Step 4: Drag a selection of image files into your rectangle. Link
In Finder, select a number of images.
Drag this selection from Finder and onto your Repeat Grid’s rectangle to import the images as fills for the repeated rectangle.
Select the rectangle and change the corner radius by dragging one of the radius controls. All of your style changes are reflected on each repetition.
Similar to dragging images in one at a time, you’re creating a repeating pattern for your object’s fill. And, just like text, any change to the container is propagated to all of the repetitions of the object in the Repeat Grid.
Note that you can easily change the content of a Repeat Grid, either by changing an individual object or by dragging in data sources. Note that the data is imported and not linked, so any changes you make to the source file won’t affect the data you’ve already placed in your XD file. All of your styles and the size and shape of any container is reflected in all repetitions of an element.
Now that we have a fairly fleshed out contacts list, we can continue our design process, iterating as we receive feedback from our colleagues and stakeholders. In this case, we might need to add elements after the fact. Repeat Grid makes this easy by allowing us to add elements to a cell.
In our example, we’ll add a horizontal line to separate the cells vertically.
Draw a horizontal line over the cell below by selecting the Line tool (L) and holding down the Shift key while dragging across.
Using the Selection tool, adjust the line’s location until it’s aligned to the left of the rectangle.
Press Escape to exit edit context.
We can draw any element or add text within the Repeat Grid’s edit context, even after you’ve created it. Since Repeat Grid automatically repeats every element, this allows us the flexibility to play with design in a new way.
We’ve just added a line, but now the cells are overlapping one another, leaving us with a visual mess. We’ll need to add vertical space between cells. When something like this happens, Repeat Grid recalculates the gutter between the row or column (from the bottom of one to the top of the next, or from the right of one to the left of the next) and sets it to a negative number if they overlap.
Hover in the overlap space. Grab either the top or bottom of the rectangle and pull it down, so the overlap no longer exists, then a little further.
Adding elements that expand the cell of the Repeat Grid may cause negative padding. (Large view7.)
We’ve solved this problem, but what about adding artwork that we’ve already created? We can cut from one context and paste into another.
Step 3: Cut And Paste Into The Repeat Grid’s Edit Context Link
Download the star.svg file and drag it onto the pasteboard, outside of your current artboard. This imports the star.svg file into your project.
Convert your imported path into a Repeat Grid and drag the right handle to the right until you have a total of four stars. Adjust the padding to bring the stars closer together.
Cut the Repeat Grid with the stars (Cmd + X), then double click on any cell of your contact list in order to enter its edit context.
Paste (Cmd + V). Your Repeat Grid of stars will paste into the center of the cell. Move the stars so that it’s underneath the text.
Sometimes, though, we’ll want to break apart the Repeat Grid; sometimes you just want independent objects after you’ve lined them up. In order to do this, we’ll ungroup the Repeat Grid and make our changes.
Step 4: Ungroup The Inner Repeat Grid And Edit As Necessary Link
Since you’re already in the contact list’s edit context, click on the Repeat Grid of stars to select it.
Ungroup the Repeat Grid by selecting the Ungroup button in the Property Inspector, selecting Ungroup Grid from the context menu (Ctrl-click or right mouse button), or using the keyboard shortcut Cmd + Shift + G.
Select two of the stars and uncheck the fill.
If your image is an SVG, it’s imported as an editable path. You can use Repeat Grid to align and repeat, then adjust afterward by ungrouping it. (Large view9.)
You can even add objects to the Repeat Grid after you create it, either by drawing or pasting into the edit context. If you have negative padding, you can adjust it easily by hovering over the overlap area. You can use Repeat Grid as an easy alignment tool between elements and decouple the repeated elements by ungrouping.
Now that we have a Repeat Grid, we’re going to wire it to another artboard in Prototype Mode. Using Adobe XD, we can switch back and forth between Design and Prototype Modes quickly, which allows us to edit both the UI and interactions at the same time.
In this case, we’re just going to create a second artboard and wire from our Repeat Grid in three different scenarios.
Option 1: Wire The Entire Repeat Grid For A Single Interaction Link
Create a second artboard in your file by using the Artboard tool (A). Click to the right of your existing artboard to create another artboard next to your first.
Switch to Prototype mode by clicking on the tab at the top of the application frame or by using the keyboard shortcut Cmd + Tab.
Select the Repeat Grid in your first artboard. A connector with an arrow will appear on the right side of the object at its midpoint.
Drag this connector to the next artboard. Select your transition options in the pop-up, then press Escape or click outside to dismiss it.
Preview by either pressing the Play button in the upper right-hand corner of the application frame or by using the keyboard shortcut Cmd + Enter. Click anywhere over the Repeat Grid to play the interaction.
What we’ve done at this point is wire the entire object, including its padding, as a hit point for the interaction.
Option 2: Wire A Single Element Of A Repeat Grid For An Interaction Link
Undo your last wire by using the keyboard shortcut Cmd + Z.
Cmd-click a rectangle in your Repeat Grid to direct select it.
Drag the connector on the right of the rectangle and drag it to the second artboard. Select your transition options in the pop-up as before, then dismiss it.
If your Preview window isn’t still open, launch it again and click the target.
Wire from a single element from within a Repeat Grid. (Large view11.)
At this point, we have a single element, but what happens if we want to select the entire cell? We can create a group within the Repeat Grid in order to make this a valid hit point.
Option 3: Create a group of elements within the Repeat Grid and create an interaction from the group. Link
Undo your last wire by using the keyboard shortcut Cmd + Z.
Switch back to Design mode by clicking on the tab or using the keyboard shortcut Cmd + Tab.
Cmd + Click a rectangle in your Repeat Grid to direct select it. Shift-click the text object next to it to add it to your selection.
Group the two objects by using the context menu selection or the keyboard shortcut Cmd + G.
Switch back to Prototyping mode. Note that your selection remains the same as while in Design mode.
Drag the connector from the group to the second artboard. You’ve now wired the entire group area as a hit point for the interaction.
Create a group inside the Repeat Grid and use that as your interaction target. (Large view12.)
You can even create an interaction by setting the hit point to the entire Repeat Grid, an individual element from inside it, or a group created inside of it.
I hope that this brief tutorial has helped you explore the power of Repeat Grid. This simple and powerful feature has been quite popular in the beta version, and it’s evolving as we get more feedback from users. If you have an idea for improvements, please do share them in the comments section below.
This article is part of the UX design series sponsored by Adobe. The newly introduced Experience Design app13 is made for a fast and fluid UX design process, creating interactive navigation prototypes, as well as testing and sharing them — all in one place.
You can check out more inspiring projects created with Adobe XD on Behance14, and also visit the Adobe XD blog15 to stay updated and informed. Adobe XD is being updated with new features frequently, and since it’s in public Beta, you can download and test it for free16.
Three user interfaces (UIs) go to a pub. The first one orders a drink, then several more. A couple of hours later, it asks for the bill and leaves the pub drunk. The second UI orders a drink, pays for it up front, orders another drink, pays for it and so on, and in a couple of hours leaves the pub drunk. The third UI exits the pub already drunk immediately after going in — it knows how the pubs work and is efficient enough not to lose time. Have you heard of this third one? It is called an “optimistic UI.”
1Optimistic UI design is not about looking at the web through rose-colored glasses — at least not only about it. (View large version2)
Recently, having discussed psychological performance optimization3 at a number of conferences dedicated to both front-end development and UX, I was surprised to see how little the topic of optimistic UI design is addressed in the community. Frankly, the term itself is not even well defined. In this article, we will find out what concepts it is based on, and we will look at some examples as well as review its psychological background. After that, we will review the concerns and main points regarding how to maintain control over this UX technique.
But before we begin, truth be told, no single thing could be called an “optimistic UI.” Rather, it is the mental model behind the implementation of an interface. Optimistic UI design has its own history and rationale.
A long while ago — when the word “tweet” applied mostly to birds, Apple was on the verge of bankruptcy and people still put fax numbers on their business cards — web interfaces were quite ascetic. And the vast majority of them had not even a hint of optimism. An interaction with a button, for example, could follow a scenario similar to the following:
The user clicks a button.
The button is triggered into a disabled state.
A call is sent to a server.
A response from the server is sent back to the page.
The page is reloaded to reflect the status of the response.
4 In the old days, interfaces were nowhere nearly as optimistic. (View large version5)
This might look quite inefficient in 2016; however, surprisingly enough, the same scenario is still used in a lot of web pages and applications and is still a part of the interaction process for many products. The reason is that it is predictable and more or less error-prone: The user knows that the action has been requested from the server (the disabled state of the button hints at this), and once the server responds, the updated page clearly indicates the end of this client-server-client interaction. The problems with this kind of interaction are quite obvious:
The user has to wait. By now, we know that even the shortest delay in the server’s response time has a negative effect on the user’s perception6 of the entire brand, not only on this particular page.
Every time the user gets a response to their action, it is presented in quite a destructive way (a new page loads, instead of the existing one being updated), which breaks the context of the user’s task and might affect their train of thought377. Even though we are not necessarily talking about multitasking8 in this case, any switch of mental context is unpleasant. So, if an action is not inherently meant to switch contexts (online payment is a good example of when a switch is natural), switching would set up an unfriendly tone of dialogue between user and system.
Then, the so-called Web 2.0 arrived and provided new modes of interaction with web pages. The core of these were XMLHttpRequest and AJAX. These new modes of interaction were complemented by “spinners”: the simplest form of progress indicator, the sole purpose of which was to communicate to the user that the system is busy performing some operation. Now, we did not need to reload the page after getting a response from the server; we could just update a part of the already-rendered page instead. This made the web much more dynamic, while allowing for smoother and more engaging experiences for users. The typical interaction with a button could now look like this:
The user clicks a button.
The button is triggered into a disabled state, and a spinner of some kind is shown on the button to indicate the system is working.
A call is sent to the server.
A response from the server is sent back to the page.
The visual state of the button and the page are updated according to the response status.
This new interaction model addressed one of the aforementioned problems of the old method of interaction: The update of the page happens without a destructive action, keeping the context for the user and engaging them in the interaction much better than before.
9 XMLHttpRequest and spinners solved one of the issues of the old methods of interaction: a destructive switch of context after the server’s response. (View large version10)
This kind of interaction pattern has been widely used everywhere in digital media. But one issue remains: Users still have to wait for a response from the server. Yes, we can make our servers respond faster, but no matter how hard we try to speed up the infrastructure, users still have to wait. Again, users do not like to wait, to put it mildly. For example, research shows11 that 78% of consumers feel negative emotions as a result of slow or unreliable websites. Moreover, according to a survey12 conducted by Harris Interactive for Tealeaf, 23% of users confess to cursing at their phones, 11% have screamed at them, and a whole 4% have actually thrown their phone when experiencing a problem with an online transaction. Delays are among those problems.
13 About 78% of consumers feel negative emotions as a result of slow or unreliable websites. (View large version14)
Even if you show some kind of progress indicator while the user waits, unless you are very creative with the indicator15, nowadays that is simply not enough. For the most part, people have gotten accustomed to spinners indicating a system’s slowness. Spinners are now more associated with purely passive waiting16, when the user has no option other than either to wait for the server’s response or to close the tab or application altogether. So, let’s come up with a step to improve this kind of interaction; let’s look at this concept of an optimistic UI.
As mentioned, an optimistic UI is nothing more than a way of handling human-computer interaction. To understand the main ideas behind it, we will stick with our “user clicks a button” scenario. But the principle will be the same for pretty much any kind of interaction that you might want to make optimistic. According to the Oxford English Dictionary17:
op-ti-mis-tic, adj. hopeful and confident about the future.
Let’s begin with the “confident about the future” part.
What do you think: How often does your server return an error on some user action? For example, does your API fail often when users click a button? Or maybe it fails a lot when users click a link? Frankly, I don’t think so. Of course, this might vary based on the API, server load, level of error-handling and other factors that you, as the front-end developer or UX specialist, might not be willing to get involved in. But as long as the API is stable and predictable and the front end properly communicates legitimate actions in the UI, then the number of errors in response to actions initiated by the user will be quite low. I would go so far as to state that they should never go above 1 to 3%. This means that in 97 to 99% of cases when the user clicks a button on a website, the server’s response should be success, with no error. This deserves to be put in a better perspective:
18Optimistic UIs are based on the assumption that when the user clicks a button, the server should return a success response in 97 to 99% of cases. (View large version19)
Think about it for a moment: If we were 97 to 99% certain about a success response, we could be confident about the future of those responses — well, at least much more confident about the future than Schrödinger’s cat was. We could write a whole new story about button interaction:
The user clicks a button.
The visual state of the button is triggered into success mode instantly.
That’s it! At least from the user’s point of view, there is nothing more to it — no waiting, no staring at a disabled button, and not yet another annoying spinner. The interaction is seamless, without the system crudely stepping in to remind the user about itself.
20An optimistic UI interaction has no place for either a disabled button or a spinner. (View large version21)
From the developer’s point of view, the complete cycle looks like this:
The user clicks a button.
The visual state of the button is triggered into success mode instantly.
The call is sent to the server.
The response from the server is sent back to the page.
In 97 to 99% of cases, we know that the response will be success, and so we don’t need to bother the user.
Only in the case of a failed request will the system speak up. Don’t worry about this for now — we will get to this point later in the article.
Let’s look at some examples of optimistic interactions. You are probably familiar with “like” buttons, as found on Facebook and Twitter. Let’s take a look at the latter.
It starts, obviously enough, with the click of the button. But note the visual state of the button when the user is no longer pressing or hovering over the button. It switches to the success state instantly!
22 After the like button is clicked, Twitter instantly updates it to the success state visually.
Let’s see what’s happening in the “Network” tab of our browser’s developer tools at this very moment.
23 The visual state of the button is updated independent of the server request, which is still in progress. (View large version24)
The “Network” tab shows that the server request has been sent but is still in progress. The “likes” counter number has not been incremented yet, but with the change in color, the interface is clearly communicating success to the user, even before having gotten a response from the server.
After a successful response is received from the server, the counter is updated, but the transition is much subtler than the instant color change. This provides the user with a smooth, uninterrupted experience, without any perceived waiting.
25While the like button is visually in success mode, the counter is updated only after the server response confirms success. (View large version26)
Another example of optimistic interaction is seen on Facebook, with its own like button. The scenario is quite similar, except that Facebook updates the counter instantly, together with success color of the button, without waiting for the server’s response.
27Facebook employs the same optimistic interaction as Twitter, except that it updates the counter instantly along with the button’s visual state.
One thing to note here, though. If we look at the server’s response time, we’ll see that it is a little over 1 second. Considering that the RAIL model recommends28100 milliseconds as the optimal response time for a simple interaction, this would normally be way too long. However, the user does not perceive any wait time in this case because of the optimistic nature of this interaction. Nice! This is another instance of psychological performance optimization29.
But let’s face it: There is still that 1 to 3% chance that the server will return an error. Or perhaps the user is simply offline. Or, more likely, perhaps the server returns what is technically a success response but the response contains information that has to be further processed by the client. As a result, the user will not get a failure indicator, but we cannot consider the response a success either. To understand how to deal with such cases, we should understand why and how optimistic UIs work psychologically in the first place.
So far, I have not heard anyone complain about the aforementioned optimistic interactions on the major social networks. So, let’s say that these examples have convinced us that optimistic UIs work. But why do they work for users? They work simply because people hate waiting. That’s it, folks! You can skip to the next part of the article.
But if you’re still reading, then you are probably interested in knowing why it is so. So, let’s dig a bit deeper into the psychological ground of this approach.
30 Brain studies help us to understand the psychology behind why optimistic UIs work. (View large version31)
An optimistic UI has two basic ingredients that are worth psychological analysis:
the fast response to the user’s action;
the handling of potential failures on the server, on the network and elsewhere.
When we talk about optimistic UI design, we’re talking about an optimal response time in human-computer interaction. And recommendations for this type of communication have been around since as far back as 1968. Back then, Robert B. Miller published his seminal piece “Response Time in Man-Computer Conversational Transactions32” (PDF), in which he defines as many as 17 different types of responses a user can get from a computer. One of those types Miller calls a “response to control activation” — the delay between the depressing of a key and the visual feedback. Even back in 1968, it should have not exceeded 0.1 to 0.2 seconds. Yes, the RAIL model33 is not the first to recommend this — the advice has been around for about 50 years. Miller notes, though, that even this short delay in feedback might be far too slow for skilled users. This means that, ideally, the user should get acknowledgement of their action within 100 milliseconds. This is getting into the range of one of the fastest unconscious actions the human body can perform — an eye blink. For this reason, the 100-millisecond interval is usually perceived to be instant. “Most people blink around 15 times a minute and a blink lasts on average 100 to 150 milliseconds,” says Davina Bristow34, of University College London’s Institute of Neurology, adding that this “means that overall we spend at least 9 days per year blinking.”
Because of its instant visual response (even before the actual request has finished), an optimistic UI is one of the examples of the early-completion35 techniques used in psychological performance optimization. But the fact that people like interfaces that respond in the blink of an eye should not come as a surprise to most of us, really. And it’s not hard to achieve either. Even in the old days, we disabled buttons instantly after they were clicked, and this was usually enough to acknowledge the user’s input. But a disabled state in an interface element means passive waiting36: The user cannot do anything about it and has no control over the process. And this is very frustrating for the user. That’s why we skip the disabled state altogether in an optimistic UI — we communicate a positive outcome instead of making the user wait.
Let’s get to the second interesting psychological aspect of optimistic UI design — the handling of potential failure. In general, plenty of information and articles are available on how to handle UI errors in the best possible way. However, while we will see how to handle failure later in this article, what matters most in an optimistic UI is not how we handle errors, but when we do it.
Humans naturally organize their activity into clumps, terminated by the completion of a subjectively defined purpose or sub-purpose. Sometimes we refer to these clumps as a “train of thought377,” a “flow of thought38” (PDF) or simply a “flow39.” The flow state is characterized by peak enjoyment, energetic focus and creative concentration. During a flow, the user is completely absorbed in the activity. A tweet by Tammy Everts40 nicely illustrates this:
On the web, the durations of such clumps of activity are much shorter. Let’s revisit Robert B. Miller’s work for a moment. The response types he cites include:
a response to a simple inquiry of listed information;
a response to a complex inquiry in graphic form;
a response to “System, do you understand me?”
He ties all of these to the same 2-second interval within which the user should get the relevant type of response. Without digging deeper, we should note that this interval also depends on a person’s working memory43 (referring to the span of time within which a person can keep a certain amount of information in their head and, more importantly, be able to manipulate it). To us, as developers and UX specialists, this means that within 2 seconds of interacting with an element, the user will be in a flow and focused on the response they are expecting. If the server returns an error during this interval, the user will still be in “dialogue” with the interface, so to speak. It’s similar to a dialogue between two people, where you say something and the other person mildly disagrees with you. Imagine if the other person spent a long time nodding in agreement (the equivalent of our indication of a success state in the UI) but then finally said “no” to you. Awkward, isn’t it? So, an optimistic UI must communicate failure to the user within the 2 seconds of the flow.
44An optimistic UI must clearly yet carefully communicate failure to the user. Most importantly, it should happen within the 2 seconds of the user’s flow. (View large version45)
Armed with the psychology of how to handle failure in an optimistic UI, let’s finally get to those 1 to 3% of failed requests.
By far, the most common remark I hear is that optimistic UI design is a kind of black pattern — cheating, if you will. That is, by employing it, we are lying to our users about the result of their interaction. Legally, any court would probably support this point. Still, I consider the technique a prediction or hope. (Remember the definition of “optimistic”? Here is where we allow some room for the “hopeful” part of it.) The difference between “lying” and “predicting” is in how you treat those 1 to 3% of failed requests. Let’s look at how Twitter’s optimistic “like” button behaves offline.
First, in line with the optimistic UI pattern, the button switches to the success state right after being clicked — again, without the user pressing or hovering over the button any longer, exactly as the button behaves when the user is online.
46 When offline, Twitter’s like button is still visually updated after being clicked. (View large version47)
But because the user is offline, the request fails.
So, as soon as possible within the user’s flow, the failure should be communicated. Again, 2 seconds is usually the duration of such a flow. Twitter communicates this in the subtlest way possible, simply by reverting the button’s state.
50 After the failed request, Twitter subtly reverts the visual state of the like button, without any visual fuss. (View large version51)
The conscientious reader here might say that this failure-handling could be taken one step further, by actually notifying the user that the request could not be sent or that an error has occurred. This would make the system as transparent as possible. But there is a catch — or, rather, a series of issues:
Any sort of notification that appears suddenly on screen would switch the user’s context, prompting them to analyze the reason behind the failure, a reason that would probably be presented in the error message.
As with any error message or notification, this one should guide the user in this new context by providing actionable information.
That actionable information would set yet another context.
OK, by now we can all agree that this is getting a bit complicated. While this error-handling would be reasonable for, say, a large form on a website, for an action as simple as clicking a like button, it’s overkill — both in terms of the technical development required and the working memory of users.
So, yes, we should be open about failure in an optimistic UI, and we should communicate it as soon as possible so that our optimism does not become a lie. But it should be proportional to the context. For a failed like, subtly reverting the button to its original state should be enough — that is, unless the user is liking their significant other’s status, in which case the thing better work all the time.
One other question might arise: What happens if the user closes the browser tab right after getting a success indicator but before the response is returned from the server? The most unpleasant case would be if the user closes the tab before a request has even been sent to the server. But unless the user is extremely nimble or has the ability to slow down time, this is hardly possible.
If an optimistic UI is implemented properly, and interactions are applied only to those elements that never wait longer than 2 seconds for a server response, then the user would have to close the browser tab within that 2-second window. That’s not particularly difficult with a keystroke; however, as we’ve seen, in 97 to 99% of cases, the request will be successful, whether the tab is active or not (it’s just that a response won’t be returned to the client).
So, this problem might arise only for those 1 to 3% who get a server error. Then again, how many of those rush to close the tab within 2 seconds? Unless they’re in a tab-closing speed competition, I don’t think the number will be significant. But if you feel this is relevant to your particular project and might have negative consequences, then employ some tools to analyze user behavior; if the probability of such a scenario is high enough, then limit optimistic interaction to non-critical elements.
I intentionally haven’t mentioned cases in which a request is artificially delayed; these do not generally fall under the umbrella of optimistic UI design. Moreover, we have spent more than enough time on the pessimistic side of things, so let’s summarize some main points about implementing a good optimistic UI.
I sincerely hope this article has helped you to understand some of the main concepts behind optimistic UI design. Perhaps you’re interesting in trying out this approach in your next project. If so, here are some things to keep in mind before you begin:
A prerequisite to everything we’ve talked about so far: Make sure the API you’re relying on is stable and returns predictable results. Enough said.
The interface should catch potential errors and problems before a request is sent to the server. Better yet, totally eliminate anything that could result in an error from the API. The simpler a UI element is, the simpler it will be to make it optimistic.
Apply optimistic patterns to simple binary-like elements for which nothing more than a success or failure response is expected. For example, if a button click assumes a server response such as “yes,” “no” or “maybe” (all of which might represent success to varying degrees), such a button would be better off without an optimistic pattern.
Know your API’s response times. This is crucial. If you know that the response time for a particular request never goes below 2 seconds, then sprinkling some optimism over your API first is probably best. As mentioned, an optimistic UI works best for server response times of less than 2 seconds. Going beyond that could lead to unexpected results and a lot of frustrated users. Consider yourself warned.
An optimistic UI is not just about button clicks. The approach could be applied to different interactions and events during a page’s lifecycle, including the loading of the page. For example, skeleton screens52 follow the same idea: You predict that the server will respond with success in order to fill out placeholders to show to the user as soon as possible.
Optimistic UI design is not really a novelty on the web, nor is it a particularly advanced technique, as we have seen. It is just another approach, another mental model, to help you manage the perceived performance55 of your product. Being grounded in the psychological aspects of human-computer interaction, optimistic UI design, when used intelligently, can help you to build better, more seamless experiences on the web, while requiring very little to implement. But, in order to make the pattern truly effective and to keep our products from lying to users, we must understand the mechanics of optimistic UI design.
We all recognize emoji. They’ve become the global pop stars of digital communication. But what are they, technically speaking? And what might we learn by taking a closer look at these images, characters, pictographs… whatever they are ? (Thinking Face). We will dig deep to learn about how these thingamajigs work.
Please note: Depending on your browser, you may not be able to see all emoji featured in this article (especially the Tifinagh1 characters). Also, different platforms vary in how they display emoji as well. That’s why the article always provides textual alternatives. Don’t let it discourage you from reading though!
Now, let’s start with a seemingly simple question. What are emoji?
What we’ll find is that they are born from, and depend on, the same technical foundation, character sets and document encoding that underlie the rest of our work as web-based designers, developers and content creators. So, we’ll delve into these topics using emoji as motivation to explore this fundamental aspect of the web. We’ll learn all about emoji as we go, including how we can effectively work them into our own projects, and we’ll collect valuable resources along the way.
There is a lot of misinformation about these topics online, a fact made painfully clear to me as I was writing this article. Chances are you’ve encountered more than a little of it yourself. The recent release of Unicode 9 and the enormous popularity of emoji make now as good a time as any to take a moment to appreciate just how important this topic is, to look at it afresh and to fill in any gaps in our knowledge, large or small.
By the end of this article, you will know everything you need to know about emoji, regardless of the platform or application you’re using, including the distributed web. What’s more, you’ll know where to find the authoritative details to answer any emoji-related question you may have now or in the future.
21 June 2016 brought the official release of Unicode Version 9.02, and with it 72 new emoji. What are they? Where do new emoji come from anyway? Why aren’t your friends seeing the new ROFL, Fox Face, Crossed Fingers and Pancakes emoji you’re sending them?! ? (Pouting Face emoji) Keep reading for the answers to these and many other questions.
A question to get us started: What is the plural form of the word “emoji”?
It’s a question that came up in the process of reviewing and editing this article. The good news is that I have an answer! The bad news (depending on how bothered you are by triviality) is that the answer is that there is no definitive answer. I believe the most accurate answer that can be given is to say that, currently, there is no established correct form for the plural of emoji.
An article titled “What’s the Plural of Emoji?3” by Robinson Meyer4, published by The Atlantic5 on 6 January 2016, discusses exactly this issue. The author turns up recent conflicting uses of both forms “emoji” and “emojis,” even within the same national publications:
In written English right now, there’s little consensus on this question. National publications have not settled on a regular style. The Atlantic, for instance, used both (emoji6, emojis7) in the last quarter of 2015. And in October alone in The New York Times, you could find the technology reporter Vindu Goel covering Facebook’s “six new emoji,”8 despite, two weeks later, Austin Ramzy detailing the Australian foreign minister’s “liberal use of emojis9.” …
The Unicode Emoji Subcommittee, which, as we will see, is the group responsible for emoji in the Unicode Standard, uses “emoji” as the plural form. This plural form appears in passages of documentation quoted in this article. Consider, for example, the very first sentence of the first paragraph of the Emoji Subcommittee’s official homepage at unicode.org10:
Emoji are pictographs (pictorial symbols) that are typically presented in a colorful form and used inline in text. They represent things such as faces, weather, vehicles and buildings, food and drink, animals and plants, or icons that represent emotions, feelings, or activities.
I have chosen the plural “emoji”, for the sake of consistency if nothing else. At this point in time, you can confidently use whichever form you prefer, unless of course the organization or individual for whom you’re writing has strong opinions one way or the other. You can and should consult your style guide if necessary.
We’ll start at the beginning, with the basic building blocks not just of emoji, nor even digital communication, but of all written language: characters and character sets.
A dictionary definition for a character will do to get us started: “A character is commonly a symbol representing a letter or number.”
That’s simple enough. But like so many other concepts, for it to be meaningful, we need to consider the broader context and put it into practice. Characters, in and of themselves, are not enough. I could draw a squiggle with a pencil on a piece of paper and rightfully call it a character, but that wouldn’t be particularly valuable. Not only that, but it is difficult to convey a useful amount of information using a single character. We need more.
Character Sets
A character set is “a set of characters.”
Expanding on that a bit, we can take a step back and consider a slightly more precise but still general description of a set: a group or collection of things that belong together, resemble one another or are usually found together.
Because we’re dealing with sets in the context of computing, we can be a little more precise. In the field of computer science a set is: a collection of a finite number of values in no particular order, with the added condition that none of the values are repeated.
What’s this about a collection? Technically speaking, a collection is a grouping of a number of items, possibly zero, that have some shared significance.
So, a character set is a grouping of some finite number of characters (i.e. a collection), in no particular order, such that none of the characters are repeated.
That’s a solid, precise, if pedantic, definition.
The World Wide Web Consortium (W3C38), the international community of member organizations that work together to develop standards for the web, has its own definition, which is not far from the generic one we’ve arrived at on our own.
A character set or repertoire comprises the set of characters one might use for a particular purpose — be it those required to support Western European languages in computers, or those a Chinese child will learn at school in the third grade (nothing to do with computers).
So, any arbitrary set of characters can be considered a character set. There are, however, some well-known standardized character sets that are much more significant than any random grouping we might put together. One such standardized character set, unarguably the most important character set in use today, is Unicode. Again, quoting the W3C40:
Unicode is a universal character set, i.e. a standard that defines, in one place, all the characters needed for writing the majority of living languages in use on computers. It aims to be, and to a large extent already is, a superset of all other character sets that have been encoded.
Text in a computer or on the Web is composed of characters. Characters represent letters of the alphabet, punctuation, or other symbols.
In the past, different organizations have assembled different sets of characters and created encodings for them — one set may cover just Latin-based Western European languages (excluding EU countries such as Bulgaria or Greece), another may cover a particular Far Eastern language (such as Japanese), others may be one of many sets devised in a rather ad hoc way for representing another language somewhere in the world.
Unfortunately, you can’t guarantee that your application will support all encodings, nor that a given encoding will support all your needs for representing a given language. In addition, it is usually impossible to combine different encodings on the same Web page or in a database, so it is usually very difficult to support multilingual pages using ‘legacy’ approaches to encoding.
The Unicode Consortium provides a large, single character set that aims to include all the characters needed for any writing system in the world, including ancient scripts (such as Cuneiform, Gothic and Egyptian Hieroglyphs). It is now fundamental to the architecture of the Web and operating systems, and is supported by all major web browsers and applications. The Unicode Standard also describes properties and algorithms for working with characters.
This approach makes it much easier to deal with multilingual pages or systems, and provides much better coverage of your needs than most traditional encoding systems.
We just learned that the Unicode Consortium is the group responsible for the Unicode Standard. From their website41:
The Unicode Consortium enables people around the world to use computers in any language. Our freely-available specifications and data form the foundation for software internationalization in all major operating systems, search engines, applications, and the World Wide Web. An essential part of our mission is to educate and engage academic and scientific communities, and the general public.
Unicode provides a unique number for every character,
no matter what the platform,
no matter what the program,
no matter what the language.
Fundamentally, computers just deal with numbers. They store letters and other characters by assigning a number for each one. Before Unicode was invented, there were hundreds of different encoding systems for assigning these numbers. No single encoding could contain enough characters: for example, the European Union alone requires several different encodings to cover all its languages. Even for a single language like English no single encoding was adequate for all the letters, punctuation, and technical symbols in common use.
These encoding systems also conflict with one another. That is, two encodings can use the same number for two different characters, or use different numbers for the same character. Any given computer (especially servers) needs to support many different encodings; yet whenever data is passed between different encodings or platforms, that data always runs the risk of corruption.
Unicode provides a unique number for every character, no matter what the platform, no matter what the program, no matter what the language. … The emergence of the Unicode Standard, and the availability of tools supporting it, are among the most significant recent global software technology trends.
In short, Unicode is a single (very) large set of characters designed to encompass “all the characters needed for writing the majority of living languages in use on computers.” As such, it “provides a unique number for every character, no matter what the platform, no matter what the program, no matter what the language.”
Both the W3C and Unicode Consortium use the term “encoding” as part of their definitions. Descriptions like that, helpful as they may be, are a big part of the reason why there is often confusion around what are in fact simple concepts. Encoding is a more involved, difficult-to-grasp concept than character sets, and one we’ll discuss shortly. Don’t worry about encoding quite yet; before we get from character sets to encoding, we need one more step.
A coded character set is a set of characters for which a unique number has been assigned to each character. Units of a coded character set are known as code points. A code point value represents the position of a character in the coded character set. For example, the code point for the letter ‘à’ in the Unicode coded character set is 225 in decimal, or E1 in hexadecimal notation. (Note that hexadecimal notation is commonly used for referring to code points…)
Note: There is an unfortunate mistake in the passage above. The character displayed is “à” and the location given for that symbol in the Unicode coded character set is 225 in decimal, or E1 hexadecimal notation. But 225 (dec) / E1 (hex) is the location of “á,” not “à,” which is found at 224 (dec) / E0 (hex). Oops! ? (Unamused Face emoji)
That isn’t too difficult to understand. Being able to describe any one character with a numeric code is convenient. Rather than writing “the Latin script letter ‘a’ with a diacritic grave,” we can say xE0, the hexadecimal notation for the numeric location of that symbol (“à”) in the coded character set known as Unicode. Among other advantages of this arrangement, we can look up that character without having to know what “Latin script letter ‘a’ with a diacritic grave” means. The natural-language way of describing a character can be awkward for us, even more so for computers, which are both much better at looking up numeric references than we are and much worse at understanding natural-language descriptions.
So, a coded character set is simply a way to assign a numeric code to every character in a set such that there is a one-to-one correspondence between character and code. With that, not only is the Unicode Consortium’s description of Unicode more understandable, but we’re ready to tackle encoding.
⛅ ? ? ? ? ?? ?
Encoding
We’ve quickly reviewed characters, character sets and coded character sets. That brings us to the last concept we need to cover before turning our attention to emoji. Encoding is both the hardest concept to wrap our heads around and also the easiest. It’s the easiest because, as we’ll see, in a practical sense, we don’t need to know all that much about it.
We’ve come to an important point of transition. Character sets and coded character sets are in the human domain. These are concepts that we must have a good grasp of in order to confidently and effectively do our work. When we get to encoding, we’re transitioning into the realm of the computing devices and, more specifically, the low-level storage, retrieval and transmission of data. Encoding is interesting, and it is important that we get right what little of it we are responsible for, but we need only a high-level understanding of the technical details in order to do our part.
The first thing to know is that “character sets” and “encodings” (or, for our purpose here, “document encodings”) are not the same thing. That may seem obvious to you, especially now that we’re clearly discussing them separately, but it is a common source of confusion. The relationship is a little easier to understand, and keep straight, if we think of the latter as “character set encodings.”
It’s back to the W3C’s “Character Encodings: Essential Concepts” for a definition of encoding44 to get us started:
The character encoding reflects the way the coded character set is mapped to bytes for manipulation by a computing device.
In the table below, which reproduces the same information from a graphic appearing in the W3C document, the first 4 characters and corresponding code points are part of the Tifinagh alphabet, and the fifth is the more familiar exclamation point.
The table shows, from left to right, the symbol itself, the corresponding code point and the way the code point maps to a sequence of bytes using the UTF-8 encoding scheme. Each byte in memory is represented by a two-digit hexadecimal number. So, for example, in the first row we see that the UTF-8 encoding of the Tifinagh letter ya (ⴰ) requires 3 bytes of storage (E2 B4 BO).
There are two important points to take away from the information in this table:
First, encodings are distinct from the coded character sets. The coded character set is the information that is stored, and the encoding is the manner in which it is stored. (Don’t worry about the specifics.)
Secondly, note how under the UTF-8 encoding scheme the Tifinagh code points map to three bytes, but the exclamation point maps to a single byte.
Although the code point for the letter à in the Unicode coded character set is always 225 (in decimal), in UTF-8 it is represented in the computer by two bytes. … there isn’t a trivial, one-to-one mapping between the coded character set value and the encoded value for this character. … the letter à can be represented by two bytes in one encoding and four bytes in another.
The encoding forms that can be used with Unicode are called UTF-8, UTF-16, and UTF-32.
The W3C’s explanation is accurate, concise, informative and, for many readers, clear as mud. At this point, we’re dealing with pretty low-level stuff. Let’s keep pushing ahead; as is often the case, learning more will give us the context we need to better understand what we’ve already seen.
UTF is a set of encodings specifically created for the implementation of Unicode. It is part of the core specification of Unicode itself.
The Unicode Consortium maintains an official website for Unicode 9.050 (as well as all previous versions of the specification). A PDF of the core specification51 was just recently published to the website in August 2016. You’ll find the discussion of UTF in “Section 2.5: Encoding Forms.”
Computers handle numbers not simply as abstract mathematical objects, but as combinations of fixed-size units like bytes and 32-bit words. A character encoding model must take this fact into account when determining how to associate numbers with the characters.
Actual implementations in computer systems represent integers in specific code units of particular size—usually 8-bit (= byte), 16-bit, or 32-bit. In the Unicode character encoding model, precisely defined encoding forms specify how each integer (code point) for a Unicode character is to be expressed as a sequence of one or more code units. The Unicode Standard provides three distinct encoding forms for Unicode characters, using 8-bit, 16-bit, and 32-bit units. These are named UTF-8, UTF-16, and UTF-32, respectively. The “UTF” is a carryover from earlier terminology meaning Unicode (or UCS) Transformation Format. Each of these three encoding forms is an equally legitimate mechanism for representing Unicode characters; each has advantages in different environments.
Note: These encoding forms are consistent from one version of the specification to the next. In fact, their stability is vital to maintaining the integrity of the Unicode standard. Whatever we read about the encoding forms in the Version 9.0 specification was true of Version 8.052 as well, and will hold going forward.
The Unicode specification discusses at length the pros and cons and preferred usage of these three forms — UTF-8, UTF-16 and UTF-32 — endorsing the use of all three as appropriate. For the purposes of this brief discussion of UTF encoding, it’s enough to know the following:
UTF-8 uses 1 byte to represent characters in the ASCII set, 2 bytes for characters in several more alphabetic blocks, 3 bytes for the rest of the BMP, and 4 bytes as needed for supplementary characters.
UTF-16 uses 2 bytes for any character in the BMP, and 4 bytes for supplementary characters.
UTF-32 uses 4 bytes for all characters.
From the brief description of storage requirements for the various UTF encodings above, you might guess that UTF-8 is more complicated to implement (owing to the fact that it is not fixed-width) but more space efficient than say UTF-32, which is more regular but less space-efficient, with every character taking up exactly 4 bytes.
Ignoring the Berber characters and focusing on the exclamation point in the rightmost column, we see that the same character would take up a single byte in UTF-8, 2 bytes (two times the storage) in UTF-16, and 4 bytes (four times the storage) in UTF-32. That’s three very different amounts of storage to convey the exact same information. Multiply that difference in storage requirements by the size of the web, estimated to be at least 4.83 billion pages65 currently, and it’s easy to appreciate that the storage requirements of these encodings is not an inconsequential consideration.
Whether or not that all made sense to you, here’s the good news…
When dealing with HTML, the character set we’ll use is Unicode, and the character encoding is always UTF-8. It turns out that that’s all we’ll ever need to concern ourselves with. ? (Relieved Face emoji, U+1F60C) Regardless, it’s no less important to be aware of the general concepts, as well as the simple fact that there are other character sets and encodings.
Now, we can bring all of this to the context of the web, and start working our way toward emoji.
⛅ ? ? ? ? ?? ?
Declaring Character Sets And Document Encoding On the Web
We need to tell user agents (web browsers, screen readers, etc.) how to correctly interpret our HTML documents. In order to do that, we need to specify both the character set and the encoding. There are two (overlapping) ways to go about this:
utilizing HTTP headers,
declaring within the HTML document itself.
That gives us a very quick summary. After a period of officially working together, these two standards bodies have parted ways. However, there is still an awkward collaboration of sorts on the HTML5 standard itself. The WHATWG works on its specification, rolling in changes continually. Much like a modern evergreen operating system (OS) or application with an update feature, the latest changes are incorporated without waiting for the next official release. This is what the WHATWG means by “living standards,” which it describes as follows:
This means that they are standards that are continuously updated as they receive feedback, either from Web designers, browser vendors, tool vendors, or indeed any other interested party. It also means that new features get added to them over time, at a rate intended to keep the specifications a little ahead of the implementations but not so far ahead that the implementations give up.
Despite the continuous maintenance, or maybe we should say as part of the continuing maintenance, a significant effort is placed on getting the specifications and the implementations to converge — the parts of the specification that are mature and stable are not changed willy nilly. Maintenance means that the days where the specifications are brought down from the mountain and remain forever locked, even if it turns out that all the browsers do something else, or even if it turns out that the specification left some detail out and the browsers all disagree on how to implement it, are gone. Instead, we now make sure to update the specifications to be detailed enough that all the implementations (not just browsers, of course) can do the same thing. Instead of ignoring what the browsers do, we fix the spec to match what the browsers do. Instead of leaving the specification ambiguous, we fix the the [sic] specification to define how things work.
For its part, the W3C will from time to time package these updates (at least some of them), as well as its own changes possibly, to arrive at a new version of its HTML 5.x standard.
Assuming that the WHATWG process works as advertised — and that may be a pretty good assumption considering that many of the people directly involved with the WHATWG also work for the organizations responsible for the implementation of the standard (e.g. Apple, Google, Mozilla and Opera) — the best strategy is probably to refer to the WHATWG spec first. That is what I have done in this article. Where I quote from an HTML5 spec, I am referencing the WHATWG specification. I do, however, make use of informational documents from the W3C throughout the article because they are helpful and not inconsistent with either spec.
Honestly, for our purposes here, it hardly matters. The sections I pull from are nearly (though not strictly) identical. But I suppose that’s really part of the problem, rather than evidence of cohesiveness. To get a sense of just how messy the situation is, take a look at the “Fork Tracking” page on the WHATWG’s wiki70.
content-type HTTP Header Declaration
As long as we’re talking about the web, there’s good reason to believe that the W3C has something to say71 about the topic:
When you retrieve a document, a web server sends some additional information. This is called the HTTP header. Here is an example of the kind of information about the document that is passed as part of the header with a document as it travels from the server to the client.
HTTP/1.1 200 OK Date: Wed, 05 Nov 2003 10:46:04 GMT Server: Apache/1.3.28 (Unix) PHP/4.2.3 Content-Location: CSS2-REC.en.html Vary: negotiate,accept-language,accept-charset TCN: choice P3P: policyref=http://www.w3.org/2001/05/P3P/p3p.xml Cache-Control: max-age=21600 Expires: Wed, 05 Nov 2003 16:46:04 GMT Last-Modified: Tue, 12 May 1998 22:18:49 GMT ETag: "3558cac9;36f99e2b" Accept-Ranges: bytes Content-Length: 10734 Connection: close Content-Type: text/html; charset=UTF-8 Content-Language: en
If your document is dynamically created using scripting, you may be able to explicitly add this information to the HTTP header. If you are serving static files, the server may associate this information with the files. The method of setting up a server to pass character encoding information in this way will vary from server to server. You should check with the documentation or your server administrator.
Without getting too heavily into the details, while still coming away from the discussion with some sense of how this works, let’s clarify some of the terminology.
HTTP is the network application protocol underlying communication on the web. (The same protocol is also used in other contexts, but was originally designed for the web.) HTTP is a client-server protocol and facilitates communication between the software making a request (the client) and the software fulfilling or responding to the request (the server) by exchanging request and response messages. These messages all must follow a well-defined, standardized structure so that they can be anticipated and interpreted properly by the recipient.
Part of this structure is a header providing information about the message itself, about the capabilities or requirements of the originator or of the recipient of the message, and so on. The header consists of a number of individual header lines. Each line represents a single header field comprising a lone key-value pair. One of the approximately 45+ defined fields is Content-Type, which identifies both the encoding and character set of the content of the message.
In the example above, among the header lines, we see:
Content-Type: text/html; charset=UTF-8
The field contains two pieces of information.
The first is the media type74, text/html, which identifies the content of the message as an HTML document, which a web server can process directly. There are other media types, like application/pdf (a PDF document), which generally need to be handled differently.
The second piece of information is the document encoding and character set, charset=UTF-8. As we’ve already seen, UTF-8 is exclusively used with Unicode. So UTF-8 alone is enough to identify both the encoding and character set.
You can view these HTTP headers yourself. Options for doing so include, among others:
Browser development tools
web-based tools
Checking HTTP Headers Using A Browser’s Developer Tools
Checking HTTP Headers with Firefox (Recent Versions)
Open the “Web Console” from the “Tools” → “Web Developer” menu.
Select the “Network” tab in the pane that appears (at the bottom of the browser window, if you haven’t changed this default).
Navigate to a web page you’d like to inspect. You’ll see a list consisting of all resources that contribute to the page fill-in, including the root document, at the top (with component resources listed underneath).
Select any one of these resources from the list for which you’d like to look at the accompanying headers. (The pane should split.)
Select the “headers” tab in the new pane that appears.
You’ll see response and request headers corresponding to both ends of the exchange, and among the response headers you should find the Content-Type field.
Checking HTTP Headers with Chrome (Recent Versions)
Open the “Developer Tools” from the “View” → “Developer” menu.
Select the “Network” tab in the pane that appears (at the bottom of the browser window, if you haven’t changed this default).
Navigate to a web page you’d like to inspect. You’ll see a list of all resources that contribute to the page fill-in, including the root document, at the top (with component resources listed underneath).
Select any one of these resources from the list for which you’d like to look at the accompanying headers. (The pane should split.)
Select the “headers” tab in the new pane that appears.
You’ll see response and request headers corresponding to both ends of the exchange, and among the response headers you should find the Content-Type field.
Checking HTTP Headers Using Web-Based Tools
Many websites allow you to view the HTTP headers returned from the server for any public website, some much better than others. One reliable option is the W3C’s own Internationalization Checker75.
Simply type a URL into the provided text-entry field, and the page will return a table with information related to the internationalization and language of the document at that address. You should see a section titled “Character Encoding,” with a row for the “HTTP Content-Type” header. You’re hoping to see a value of utf-8.
Using A Meta Element With charset Attribute
We can also declare the character set and encoding in the document itself. More specifically, we can use an HTML meta element to specify the character set and encoding.
There are two different, widely used, equally valid formats (both interpreted in exactly the same way).
The latter form is shorter and, so, easier to type and harder to get wrong accidentally, and it takes up less space. For these reasons, it’s the one we should use.
It might occur to you to ask (or not), “If the browser needs to know the character set and encoding before it can read the document, how can it read the document to find the meta element and get the value of the charset attribute?”
That’s a good question. How clever of you. ? (Octopus emoji, U+1F419 — widely considered to be among the cleverest of all animal emoji76) I probably wouldn’t have thought to ask that. I had to learn to ask that question. (Sometimes it’s not just the answers we need to learn, but the questions as well.)
It would be convenient if you could put the Content-Type of the HTML file right in the HTML file itself, using some kind of special tag. Of course this drove purists crazy… how can you read the HTML file until you know what encoding it’s in?! Luckily, almost every encoding in common use does the same thing with characters between 32 and 127, so you can always get this far on the HTML page without starting to use funny letters:
But that meta tag really has to be the very first thing in the <head> section because as soon as the web browser sees this tag it’s going to stop parsing the page and start over after reinterpreting the whole page using the encoding you specified.
Notice the use of the older-style meta element. This post is from 2003 and, therefore, predates HTML5.
The element containing the character encoding declaration must be serialized completely within the first 1024 bytes of the document.
In order to satisfy this condition as safely as possible, it’s best practice to have the meta element specifying the charset as the first element in the head section of the page.
This means that every HTML5 document should begin very much like the following (the only differences being the title text, possibly the value of the lang attribute, the use of white space, single versus double quotation marks around attribute values, and capitalization).
Now you might be thinking, “Great, I can specify the character set and encoding in the HTML document. I’d much rather do that than worry about HTTP header field values.”
I don’t blame you. But that begs the question, “What happens if the character set and encoding are set in both places?”
Maybe somewhat surprisingly the information in the HTTP headers takes precedence. Yes, that’s right, the meta element and charset attribute do not override the HTTP headers. (I think I remember being surprised by this.) ? (Slightly Frowning Face emoji, U+1F641)
If you have access to the server settings, you should also consider whether it makes sense to use the HTTP header. Note however that, since the HTTP header has a higher precedence than the in-document meta declarations, content authors should always take into account whether the character encoding is already declared in the HTTP header. If it is, the meta element must be set to declare the same encoding.
There’s no getting away from it. To avoid problems, we should always make sure the value is properly set in the HTTP header as well as in the HTML document.
An Encoding By Any Other Name
Before we finish with character sets and encoding and move on to emoji, there are two other complications to consider. The first is as subtle as it is obvious.
It’s not enough to declare a document is encoded in UTF-8 — it must be encoded in UTF-8! To accomplish this, your editor needs to be set to encode the document as UTF-8. It should be a preference within the application.
Say, I have a joke for you… What time is it when you have an editor that doesn’t allow you to set the encoding to UTF-8?
Punchline: Time to get a new editor! ? (Face with rolling eyes emoji, U+1F644)
So, we’ve specified the character set and encoding both in the HTTP headers and in the document itself, and we’ve taken care that our files are encoded in UTF-8. Now, thanks to Unicode and UTF-8, we can know, without any doubt, that our documents will be interpreted and displayed properly for every visitor using any browser or other user agent on any device, running any software, anywhere in the world. But is that true? No, it’s not quite true.
There is still a missing piece of the puzzle. We’ll come back to this. Building suspense, that’s good writing! ? (Smiling Face with Mouth Open emoji, U+1F603)
⛅ ? ? ? ? ?? ?
What Were We Talking About Again? Oh Yeah, Emoji!
So What Are Emoji?
We’ve already mentioned the Unicode Consortium, the non-profit responsible for the Unicode standard.
There’s a subcommittee of the Unicode Consortium dedicated to emoji, called, unsurprisingly, the Unicode Emoji Subcommittee80. As with the rest of the Unicode standard, the Unicode Consortium and its website (unicode.org81) are the authoritative source for information about emoji. Fortunately for us, it provides a wealth of accessible information, as well as some more formal technical documents, which can be a little harder to follow. An example of the former is its “Emoji and Dingbats” FAQ82.
Q: What are emoji?
A: Emoji are “picture characters” originally associated with cellular telephone usage in Japan, but now popular worldwide. The word emoji comes from the Japanese 絵 (e ≅ picture) + 文字 (moji ≅ written character).
Note: See those Japanese characters in this primarily English-language document? Thanks Unicode!
Emoji are often pictographs — images of things such as faces, weather, vehicles and buildings, food and drink, animals and plants — or icons that represent emotions, feelings, or activities. In cellular phone usage, many emoji characters are presented in color (sometimes as a multicolor image), and some are presented in animated form, usually as a repeating sequence of two to four images — for example, a pulsing red heart.
Q: Do emoji characters have to look the same wherever they are used?
A: No, they don’t have to look the same. For example, here are just some of the possible images for U+1F36D LOLLIPOP, U+1F36E CUSTARD, U+1F36F HONEY POT, and U+1F370 SHORTCAKE:
In other words, any pictorial representation of a lollipop, custard, honey pot or shortcake respectively, whether a line drawing, gray scale, or colored image (possibly animated) is considered an acceptable rendition for the given emoji. However, a design that is too different from other vendors’ representations may cause interoperability problems: see Design Guidelines86 in UTR #5187.
Read through just that one FAQ — and this article, of course ? (Grinning face with Smiling Eyes emoji, U+1F601) — and you’ll have a better handle on emoji than most people ever will.
How Do We Use Emoji?
The short answer is, the same way we use every other character. As we’ve already discussed, emoji are symbols associated with code points. What’s special about them is just semantics — i.e. the meaning we ascribe to them, not the mechanics of them.
If you have a key on a keyboard mapped to a particular character, producing that character is as simple as pressing the key. However, considering that, as we’ve seen, more than 120,000 characters are currently in use, and the space defined by Unicode allows for more than 1.1 million of them, creating a keyboard large enough to assign a character to each key is probably not a good strategy.
When we exhaust the reach of our keyboards, we can use a software utility to insert characters.
Recent versions of macOS include an “Emojis and Symbols” panel that can be accessed from anywhere in the OS (via the menu bar or the keyboard shortcut Control + Command + Space). Other OS’ offer similar capabilities to view and click or to copy and paste emoji into text-entry fields. Applications may offer additional app-specific features for inserting emoji beyond the system-wide utilities.
Lastly, we can take advantage of character references to enter emoji (and any other character we like, for that matter) on the web.
Character References
Character references are commonly used as a way to include syntax characters as part of the content of an HTML document, and also can be used to input characters that are hard to type or not available otherwise.
Note: I’m sure many of you are familiar with character references. But if you keep reading this section, it wouldn’t surprise me if you learn something new.
HTML is a markup language, and, as such, HTML documents contain both content and the instructions describing the document together as plain text in the document itself. Typically, the vast majority of characters are part of the document’s content. However, there are other “special” characters in the mix. In HTML, these form the tags corresponding to the HTML elements that define the structure and semantics of the document. Moreover, it’s worth taking a moment to recognize that the syntax itself — i.e. its implementation — creates a need for additional markup-specific characters. The ampersand is a good example. The ampersand (&) is special because it marks the beginning of all other character references. If the ampersand itself were not treated specially, we’d need another mechanism altogether.
Syntax characters are treated as special, and should never be used as part of the content of a document, because they are always interpreted specially, regardless of the author’s intent. Mistakenly using these characters as content makes it difficult or impossible for a browser or other user agent to parse the document correctly, leading to all sorts of structural and display issues. But aside from their special status, markup-related characters are characters like any other, and very often we need to use them as content. If we can’t type the literal characters, then we need some other way to represent them. We can use character references for this, referred to as “escaping” the character, as in getting outside of (i.e. escaping) the character’s markup-specific meaning.
What characters need to be escaped? According to the W3C three characters should always be escaped88: the less-than symbol (<, <), the greater-than symbol (>, >) and the ampersand (&, &) — just those three.
Two others, the double quote (“, ") and single quote (‘, ') are often escaped based on context; in particular, when they appear as part of the value of an attribute and the same character is used as the delimiter of the attribute value.
Note: Even this is a bit of a fib, though it comes from a typically reliable source. To be safe, we can always escape those characters. But in fact, because of the way document parsing works, we can often get away without escaping one or more of them.
If you’re interested in a more detailed run-through of just how complicated and fiddly the exceptions to the syntax-character rules can get in practice, have a look at the blog post “Ambiguous Ampersands110,” in which Mathias Bynens considers precisely when these characters must be escaped and when they don’t need be in practice.
But here’s the thing: These types of liberties can, and frequently do, cascade through our markup when we inevitably make other mistakes. For that reason alone, you may want to stick to the advice from the W3C. Not only is it the safer approach, it’s a lot easier to remember, and that’s not a bad thing.
In addition to these few syntax characters, there are similar references for every other Unicode character as well, all 120,000+ of them. These references come in two types:
named character references (named entities)
numeric character references (NCRs)
Note: It is perfectly confusing that the term “numeric character reference” is abbreviated NCR, which could just as easily be used as the abbreviation for named character reference. ? (Weary Face, U+1F629)
Named character references
Named character references (also known as named entities, entity references or character entity references) are pre-defined word-like references to code points. There are quite a few of them. The WHATWG provides a handy comprehensive table of character reference names supported by HTML5113, listing 2,231 of them. That’s far, far more than you will ever likely see used in practice. After all, the idea is that these names will serve as mnemonics (memory aids). But it’s difficult to remember 2,231 of anything. If you don’t know that a named reference exists, you won’t use it.
But where does this information come from? How can we be certain that the information in the table referenced above, which I describe as “comprehensive,” is in fact comprehensive? Not only are those perfectly valid questions, it’s exactly the type of questioning we need more of, to cut through the clutter of hearsay and other misinformation that is all too common online.
The very best sources of authoritative information are the specifications themselves, and that “handy, comprehensive table” is in fact is a link to section 12.5 of the WHATWG’s HTML5 spec114.
Let’s say you wanted to include a greater-than symbol (>) in the content of your document.
As we have just seen, and as you probably already knew, we can’t just press the key bearing that symbol on your keyboard. That literal character is special and may be treated as markup, not content. There is a named character reference for the greater-than symbol. It looks like >. Typing that in your document will get you the character you’re looking for every time, >.
So, in summary, named entities are predefined mnemonics for certain Unicode characters.
Essentially, a group of people thought it would be nice if we could refer to & as &, so they arranged to make that possible, and now & corresponds to the code point for &.
Numeric Character References
There isn’t a named reference for every Unicode character. We just saw that there are 2,231 of them. That’s a lot, but certainly not all. You won’t find any emoji in that list, for one thing. But while there are not always named references, there are always numeric character references. We can use these for any Unicode character, both those that have named references and those that don’t.
An NCR is a reference that uses the code point value in decimal or hexadecimal form. Unlike the names, there is nothing easy to remember about these.
We’ve looked at the ampersand (&), for which there is a named character reference, &. We can also write this as a numeric reference in decimal or hexadecimal form:
decimal: & (&)
hexadecimal: & (&)
Note: The # indicates that what follows is a numeric reference, and #x indicates that the numeric reference is in hexadecimal notation.
You’ll find a table containing a complete list of emoji in the document “Full Emoji Data182117,” maintained by the Unicode Consortium’s Emoji Subcommittee. It includes several different representations of each emoji for comparison and, importantly, the Unicode code point in hexadecimal form, as well as the name of the character and some additional information. It’s a great resource and makes unnecessary any number of other websites that often contain incomplete, out of date or otherwise partially inaccurate information.
Note: If you look carefully, you might spot some unfamiliar emoji in this list. As I write this, the list includes new emoji from the just recently released Unicode Version 9.0. So, you can find ? Face with Cowboy Hat (U+1F920), ? Shrug (U+1F937), ? Selfie (U+1F91E), ? Potato (U+1F954) and 68 others from the newest version of Unicode118.
To look at just a few:
? (?): Pile of Poo
? (?): Doughnut (that’s one delicious-looking emoji)
? (?): Person Doing a Cartwheel (new with version 9)
Are you seeing a box or other generic symbol, rather than an image for the last emoji in the list (and the preceding paragraph as well)? That makes perfect sense, if you’re reading this around the time I wrote it. In fact, it would be more remarkable if you were seeing emoji there. That last emoji, Person Doing a Cartwheel (U+1F938), is new as of Unicode Version 9.0119, released on 21 June 2016. It isn’t surprising at all if your platform or application doesn’t yet support an emoji released within the past several days (or weeks). Of course, as this newest release of Unicode begins to roll out, Version 9.0’s 72 new emoji120 will begin to appear, including ? (Person Doing a Cartwheel, U+1F938), the symbol for which will automatically replace the blank here and in the list above.
Do we really have to type in these references? No, if the platform or application you’re using allows you to enter emoji in some other way, that will work just fine. In fact, it’s preferred. Emoji are not syntax characters and so can always be entered directly.
Here’s a basketball emoji I inserted into this document from OS X’s “Emojis and Symbols” panel: ? (Basketball, U+1F3C0).
This brings up a more general question, “If there’s a reference for every Unicode character, when should we use them?”
The W3C provides us with a perfectly reasonable, well-justified answer to this question in a Q&A document titled “Using Character Escapes in Markup and CSS121“. The short version of its answer to the question of when should we use character references is, as little as possible:
When not to use escapes
It is almost always preferable to use an encoding that allows you to represent characters in their normal form, rather than using character entity references or NCRs.
Using escapes can make it difficult to read and maintain source code, and can also significantly increase file size.
Many English-speaking developers have the expectation that other languages only make occasional use of non-ASCII characters, but this is wrong.
Take for example the following passage in Czech.
Jako efektivnější se nám jeví pořádání tzv. Road Show prostřednictvím našich autorizovaných dealerů v Čechách a na Moravě, které proběhnou v průběhu září a října.
If you were to require NCRs for all non-ASCII characters, the passage would become unreadable, difficult to maintain and much longer. It would, of course, be much worse for a language that didn’t use Latin characters at all.
Jako efektivnĕjší se nám jeví pořádání tzv. Road Show prostřednictvím našich autorizovaných dealerů v Čechách a na Moravě, které proběhnou v průběhu září a října.
As we said before, use characters rather than escapes for ordinary text.
So, we should only use character references when we absolutely must, such as when escaping markup-specific characters, but not for “ordinary text” (including emoji). Still, it is nice to know that we can always use a numeric character reference to input any Unicode character at all into our HTML documents. Literally, a world ? (Earth Globe Americas, U+1F30E) of characters are open to us.
The final point I will make before moving on has to do with case-sensitivity. This is another one of those issues about which there is much confusion and debate, despite the fact that it is not open to interpretation.
Character References and Case-Sensitivity
Named character references are case-sensitive and must match the case of the names given in the table of named character references supported by HTML122 that is part of the HTML5 spec. Having said that, if you look at the named references in that table carefully, you will see more than one name that maps to the same code point (and, so, the same character).
Take the ampersand. You’ll find the following four entries in the table for this single character:
This may be where some of the confusion originates. One could easily be fooled into assuming that this simulated, limited case-insensitivity is the real thing. But it would be a mistake to think that these kinds of variations are consistent. They definitely are not. For example, the one and only one valid named reference for the backslash character is Backslash;.
Backslash; — U+02216 (∖)
You won’t find any other references to U+02216 in that table, and so no other form is valid.
If we look closely at the four named entities for the ampersand (U+00026) again, you’ll see that half of them include a trailing semicolon (;) and the other half don’t. This, too, may have led to confusion, with some people mistakenly believing that the semicolon is optional. It isn’t. There are some explicitly defined named character references, such as AMP and amp, without it, but the vast majority of named references and all numeric references include a semicolon. Furthermore, none of the named references without the trailing semicolon can be used in HTML5. ? (Face with Mouth Open, U+1F62E) Section 12.1.4 of the HTML5 specification123 tells us (emphasis added):
Character references must start with a U+0026 AMPERSAND character (&). Following this, there are three possible kinds of character references:
Named character references
The ampersand must be followed by one of the names given in the named character references124 section, using the same case. The name must be one that is terminated by a U+003B SEMICOLON character (;).
Decimal numeric character reference
The ampersand must be followed by a U+0023 NUMBER SIGN character (#), followed by one or more ASCII digits125, representing a base-ten integer that corresponds to a Unicode code point that is allowed according to the definition below. The digits must then be followed by a U+003B SEMICOLON character (;).
Hexadecimal numeric character reference
The ampersand must be followed by a U+0023 NUMBER SIGN character (#), which must be followed by either a U+0078 LATIN SMALL LETTER X character (x) or a U+0058 LATIN CAPITAL LETTER X character (X), which must then be followed by one or more ASCII hex digits126, representing a hexadecimal integer that corresponds to a Unicode code point that is allowed according to the definition below. The digits must then be followed by a U+003B SEMICOLON character (;).
“The ampersand must be followed by one of the names given in the named character references section, using the same case. The name must be one that is terminated by a U+003B SEMICOLON character (;).”
That answers that.
By the way, the alpha characters in hexadecimal numeric character references (a to f, A to F) are always case-insensitive.
⛅ ? ? ? ? ?? ?
Glyphs
At the end of the encoding section, I asked whether Unicode and UTF-8 encoding are enough to ensure that our documents, interfaces and all of the characters in them will display properly for all visitors to our websites and all users of our applications. The answer was no. But if you remember, I left this as a cliffhanger. ? (Hushed Face, U+1F62F) There’s just one thing left to complete our picture of emoji (pun intended) ? (Grimacing Face U+1F62C).
Unicode and UTF-8 do most of the heavy lifting, but something is missing. We need a glyph associated with every character in order to be able to see a representation of the character.
In typography, a glyph /’ɡlɪf/ is an elemental symbol within an agreed set of symbols, intended to represent a readable character for the purposes of writing and thereby expressing thoughts, ideas and concepts. As such, glyphs are considered to be unique marks that collectively add up to the spelling of a word, or otherwise contribute to a specific meaning of what is written, with that meaning dependent on cultural and social usage.
For example, in most languages written in any variety of the Latin alphabet the dot on a lower-case i is not a glyph because it does not convey any distinction, and an i in which the dot has been accidentally omitted is still likely to be recognized correctly. In Turkish, however, it is a glyph because that language has two distinct versions of the letter i, with and without a dot.
The relationship between the terms glyph, font and typeface is that a glyph is a component of a font that is composed of many such glyphs with a shared style, weight, slant and other characteristics. Fonts, in turn, are components of a typeface (also known as a font family), which is a collection of fonts that share common design features but each of which is distinctly different.
Essentially, we need a font that includes a representation for the code point of the emoji we want to display. If we don’t have that symbol we’ll get a blank space, an empty box or some other generic character as an indication that the symbol we’re after isn’t available. You’ve probably seen this. Now you understand why, if you didn’t before.
What would happen if you tried to insert those characters into a web page using a numeric character reference? Let’s see:
ⴰ (ⴰ)
ⵣ (ⵣ)
ⵓ (ⵓ)
ⵍ (ⵍ)
! (!)
Chances are you can see the exclamation point, but some of the others might be missing, replaced by a box or other generic symbol.
As has already been mentioned, those symbols are Tifinagh characters. Tifinagh130 is “a series of abjad and alphabetic scripts used to write Berber languages.” According to Wikipedia131:
Berber or the Amazigh languages or dialects (Berber name: Tamaziɣt, Tamazight, ⵜⴰⵎⴰⵣⵉⵖⵜ [tæmæˈzɪɣt], [θæmæˈzɪɣθ]) are a family of similar and closely related languages and dialects indigenous to North Africa. They are spoken by large populations in Algeria and Morocco, and by smaller populations in Libya, Tunisia, northern Mali, western and northern Niger, northern Burkina Faso, Mauritania, and in the Siwa Oasis of Egypt. Large Berber-speaking migrant communities have been living in Western Europe since the 1950s. In 2001, Berber became a constitutional national language of Algeria, and in 2011 Berber became a constitutionally official language of Morocco, after years of persecution.
Not long ago, it would have been surprising if your platform displayed any of the Tifinagh characters. But wide internationalization support has improved dramatically and is getting better all the time, thanks in large part to Unicode. There is now a good chance you’ll see them.
We can still reliably stump our platforms with references to characters that have been only very recently released, as we saw earlier with ? (Person Doing a Cartwheel, U+1F938).
For those of you who really appreciate missing characters, here are some others:
? — (Drooling Face, U+1F924)
? — (Shrug, U+1F937)
? — (Face Palm, U+1F9260)
? — (Selfie, U+1F933)
? — (Owl, U+1F989)
? — (Carrot, U+1F955)
? — (Shallow Pan of Food, U+1F958)
? — (Shopping Trolley, U+1F6D2)
Note: If you are seeing the eight emoji in that list, then it’s safe to say you have support for the newest emoji introduced with Unicode Version 9.0. As we’ll see, that support could be coming from your OS or application or it could even be loaded via Javascript for a particular website (but not all of the others).
Regardless of what you or I do or do not see, Unicode is doing its part.
OK, so emoji are symbols (i.e. glyphs) that correspond to a specific code point — that’s a clean, easy-to-understand arrangement… well, it’s not quite so simple. There is one more thing we need to cover — the zero-width joiner.
Zero-Width Joiner: The Most Important Character You’ll Never See
The zero-width joiner (ZWJ) has a code point but no corresponding symbol. It is used to connect two or more other Unicode code points to create a new “compound character” with a unique glyph all its own.
The U+200D ZERO WIDTH JOINER (ZWJ) can be used between the elements of a sequence of characters to indicate that a single glyph should be presented if available. An implementation may use this mechanism to handle such an emoji zwj sequence as a single glyph, with a palette or keyboard that generates the appropriate sequences for the glyphs shown. So to the user, these would behave like single emoji characters, even though internally they are sequences.
When an emoji zwj sequence is sent to a system that does not have a corresponding single glyph, the ZWJ characters would be ignored and a fallback sequence of separate emoji would be displayed. Thus an emoji zwj sequence should only be supported where the fallback sequence would also make sense to a recipient. …
So, a ZWJ is exactly what it says it is: It does not have any appearance (i.e. it is “zero width”), and it joins other characters.
One important use of the ZWJ related to emoji are the skin tone modifiers that have already been mentioned. We’ve said that these skin tones were added to Unicode in version 8.0 to bring diversity to the appearance of emoji depicting human beings by allowing for a range of skin color. More specifically, Unicode has adopted the Fitzpatrick scale, a numeric classification scheme for skin tones specifying six broad groups or “types” of skin (Type I to Type VI) that represent in a general way at least a majority of people. From the Wikipedia entry for the Fitzpatrick scale138:
It was developed in 1975 by Thomas B. Fitzpatrick, a Harvard dermatologist, as a way to estimate the response of different types of skin to ultraviolet (UV) light. It was initially developed on the basis of skin and eye color, but when this proved misleading, it was altered to be based on the patient’s reports of how their skin responds to the sun; it was also extended to a wider range of skin types. The Fitzpatrick scale remains a recognized tool for dermatological research into human skin pigmentation.
…
Type I (scores 0–6) always burns, never tans (pale white; blond or red hair; blue eyes; freckles).
Type II (scores 7–13) usually burns, tans minimally (white; fair; blond or red hair; blue, green, or hazel eyes)
Type III (scores 14–20) sometimes mild burn, tans uniformly (cream white; fair with any hair or eye color)
Type IV (scores 21–27) burns minimally, always tans well (moderate brown)
Type V (scores 28–34) very rarely burns, tans very easily (dark brown)
Type VI (scores 35–36) Never burns, never tans (deeply pigmented dark brown to darkest brown)
Getting back to the ZWJ, let’s take a closer look at this in practice using the Boy emoji (U+1F466). To illustrate that this really works as described, I’m going to write out all of the emoji using numeric references. (You can take a look at the page source if you want to confirm this.)
So, we’ll start with our base emoji:
? — (Boy, ?)
Although the Fitzpatrick scale specifies six skin types, the depiction of the first two types using emoji are combined under Unicode. So, only five skin tone modifiers are actually available to us:
? — Emoji Modifer Fitzpatrick Type 1-2 (?)
? — Emoji Modifer Fitzpatrick Type 3 (?)
? — Emoji Modifer Fitzpatrick Type 4 (?)
? — Emoji Modifer Fitzpatrick Type 5 (?)
? — Emoji Modifer Fitzpatrick Type 6 (?)
These skin tone modifiers appear in the list “Full Emoji Data144,” along with all of the other emoji that are part of Unicode. They are represented as a square or some other shape of the appropriate color (i.e. skin tone) when used alone. That’s what you should be seeing in the list above.
We can manually build up the skin-type variants of the Boy emoji by combining the base emoji with each of the skin-type symbols:
?? — Boy Type 1 to 2 (??)
?? — Boy Type 3 (??)
?? — Boy Type 4 (??)
?? — Boy Type 5 (??)
?? — Boy Type 6 (??)
Note: The used in the list above is just an image I’ve used as a placeholder for the ZWJ character, which is not visible itself.
Family and other groups are built up in exactly same way, one character at a time, with ZWJs in between. But don’t forget we’ve already learned that we should use character references only when we absolutely must. So, although we could build up the group “Family, Man, Woman, Girl, Boy” manually…
? ? ? ? — ????
…it’s preferable (and also easier and less error-prone) to use the emoji symbol itself. So, of course that is what we should do. — ????
We could also write the Latin lowercase “a” as either simply “a” or a (a). Imagine writing an entire HTML document out using only numeric character references, and you will probably appreciate the pointlessness of the exercise.
How Do We Know If We Have These Symbols?
Like any other character, in order to display a specific emoji, a symbol must be included in some font available on the device you are using. Otherwise, the OS will find no way to graphically represent the code point.
An OS, be it a desktop operating system such as Apple’s macOS, or a mobile OS like iOS and Android, ships with quite a few preinstalled fonts. (Many more can be acquired and installed separately.) The fonts available may differ by geographic region or primary language of the intended users across localized versions.
Many of these fonts will overlap, offering the same characters but presenting them in different styles. From one font to the next, these differences may be subtle or extreme. However, not all fonts overlap. Fonts intended for use with Western languages, for example, will not contain the symbols for Chinese, Japanese or Korean characters, and the reverse is also true. Even overlapping fonts may have extended characters that differ.
It is the responsibility of the font designer to decide which characters will be included in a given font. It is the responsibility of developers of an OS to make sure that the total collection of fonts covers all of the intended languages and provides a wide range of styles and decorative, mathematic and miscellaneous symbols and so on, so that platform is as expressively powerful as possible.
The current versions of all major platforms (Windows, macOS, Linux, iOS and Android) support emoji. Precisely what that means differs from one platform to the next, version to version and, in the case of Linux, from distribution to distribution.
The Great Emoji Proliferation Of 2016
In this article we’ve covered a little about the history of emoji through the current version of the Unicode Standard, Version 9.0 (released 21 June 2016). We’ve seen that Version 9.0 introduced 72 entirely new emoji, not counting variants. (The number is 167 if we add skin tone modifers.)
Before moving on I should mention that the emoji included in Unicode 9.0 are referred to separately as “Unicode Emoji Version 3.0”. That is to say that “Unicode Version 9.0 emoji” and “Unicode Emoji Version 3.0” are the same set of characters.
As we begin to look at Emoji support with the next section, and considering everything we’ve learned about emoji so far, it would seem to be a relatively straight-forward to know what we’re looking for. Ideally we would like to see full support for all Version 3.0 emoji, including skin tone modifiers, and multi-person groupings. After all, a platform can’t possibly do better than full support for the current version of the Standard. That would be madness! Have you heard the Nietzsche quote:
There is always some madness in technology. But there is also always some reason in madness.
Nietzsche was talking about love, but isn’t it just as true of tech? ? (Winking face, U+1F609)
It turns out you can do “better” than 100% support, that is depending on your definition of better. Let’s say that you can do more than 100% support. This isn’t a unique concept in technology, or even web design and development. For example, implementators doing more than 100% support for CSS led to vendor prefixes. Somehow more than 100% always seems good at first, but tends to lead to problems. It’s a little like how spending more than 100% of the money you have starts out as a solution to a problem, but tends to eventually lead to more problems ? (Frowning face with open mouth, U+1F626).
What does more than 100% support look like in the context of emoji?
First, let’s agree that simply calling something an emoji does not make it an emoji. You may remember (or not) Pepsi’s global PepsiMoji campaign145. A PepsiMoji is not an emoji, it’s an image. We won’t concern ourselves with gimmicky marketing ploys like that. There are still a couple of ways platforms are exceeding 100% support:
Using Zero Width Joiners to create non-standard symbols by combining standard emoji.
Rolling out proposed emoji before they are officially released.
An example of the former are Microsoft’s somewhat silly (IMO) Ninja Cat emoji, which I discuss in the section on Windows’ emoji support. But cat-inspired OS mascots are not the only place we see this sort of unofficial emoji sequence. More practical uses have to do with multi-person groupings and diversity, i.e. gender and skin tones.
Emoji for multi-person groupings present some special challenges:
Gender combinations. Some multi-person groupings explicitly indicate gender: MAN AND WOMAN HOLDING HANDS, TWO MEN HOLDING HANDS, TWO WOMEN HOLDING HANDS. Others do not: KISS, COUPLE WITH HEART, FAMILY (the latter is also non-specific as to the number of adult and child members). While the default representation for the characters in the latter group should be gender-neutral, implementations may desire to provide (and users may desire to have available) multiple representations of each of these with a variety of more-specific gender combinations.
Skin tones. In real multi-person groupings, the members may have a variety of skin tones. However, this cannot be indicated using an emoji modifier with any single character for a multi-person grouping.
The basic solution for each of these cases is to represent the multi-person grouping as a sequence of characters—a separate character for each person intended to be part of the grouping, along with characters for any other symbols that are part of the grouping. Each person in the grouping could optionally be followed by an emoji modifier. For example, conveying the notion of COUPLE WITH HEART for a couple involving two women can use a sequence with WOMAN followed by an emoji-style HEAVY BLACK HEART followed by another WOMAN character; each of the WOMAN characters could have an emoji modifier if desired.
This makes use of conventions already found in current emoji usage, in which certain sequences of characters are intended to be displayed as a single unit.
We’re told, “the default … should be gender-neutral, implementations may desire to provide … multiple representations of each of these with a variety of more-specific gender combinations.”
This is in fact what implementations are doing, and pretty aggressively. As we will see, with its Windows 10 Anniversary Update, Microsoft now allows for as many as 52,000 combinations of multi-person groupings. Is this a good thing?
It is certainly laudable effort. Having said that, it’s worth keeping in mind what it means from a standards perspective. Though Microsoft has greatly increased universality of its emoji through its flexibly diverse emoji handling, it comes at the expense of compatibility with other platforms. Be aware that users of every other platform, including every version of Windows other than Windows 10 Anniversary Update, will not see many of these groupings as intended.
Microsoft is not the only implementor to do this, but they’ve taken it further than others.
That leaves the idea of rolling out proposed emoji before they are officially released. Everyone is getting in on this, and it is a new phenomenon. First, let’s take a brief moment to understand the situation.
Like most other standards bodies, the Unicode Consortium doesn’t wait for the release of one version of a standard to begin working on the next. As soon as the door closes on inclusion for one release, changes and new proposals are evaluated for the next.
Generally speaking, the Unicode Consortium invites outside parties to participate in selecting future emoji, the process for which is outlined in the document “Submitting Emoji Character Proposals147“. As that page describes, the process is somewhat drawn out, and proposals can be rejected for many reasons, but those that fair well are eventually added as “candidates”.
From the same page:
…proposals that are accepted as candidates are added to Emoji Candidates148, with placeholder code points…
So proposed Emoji are made public in some cases well before inclusion in the Unicode Emoji Standard. However the proposals carry this warning:
Candidates are tentative: they may be removed or their code point, glyph, or name changed. No code point values for candidates are final, until (and if) the candidates are included as characters in a version of Unicode. Do not deploy any of these.
That would seem pretty cut and dry. Promising proposals are added to a publicly available candidates list with the disclaimer that they should not be used until officially released. But rarely are these kinds of issues so simple for long. Seemingly more often than not, the exception is the rule, and by that measure, emoji are following the rules.
Google wants to increase the representation of women in emoji and would like to propose that Unicode implementers do the same. Our proposal is to create a new set of emoji that represents a wide range of professions for women and men with a goal of highlighting the diversity of women’s careers and empowering girls everywhere.
That proposal, well worth reading, was submitted in May 2016, a little over a month before the release of Unicode Version 9.0 with its 72 new emoji. It has led to a flurry of activity resulting in a Proposed Update to UTR #51150, and making way for Unicode Emoji Version 4.0 much more quickly than might have been expected. How quickly — right about now.
The original proposal led to another by the Unicode Subcommittee, “Gender Emoji ZWJ Sequences151“, published on 14 July 2016, that fast-tracked new officially recognized sequences providing greater gender parity among existing emoji characters as well as new profession emoji.
From the proposal:
This document describes how vendors can support a set of both female and male versions of many emoji characters, including new profession emoji. Because these emoji use sequences of existing Unicode characters composed according to UTR#51: Unicode Emoji, vendors can begin design and implementation work now and can deploy before the end of 2016, rather than waiting for Unicode v10.0 to come out in June of 2017.
Unicode itself does not normally specify the gender for emoji characters: the emoji character is RUNNER, not MAN RUNNER; POLICE OFFICER not POLICEMAN. Even where the name may appear to be exclusively one gender, such as U+2603 SNOWMAN or U+1F482 GUARDSMAN the character can be treated as neutral regarding gender.
To get a greater sense of realism for these characters, however, vendors typically have picked the appearance of a particular gender to display. This has led to gender disparities in the emoji that people can use. There is also a lack of emoji representing professions and roles, and the few that are present (like POLICE OFFICER) do not provide for both genders; a vendor has to choose one or the other, but can’t represent both.
How big a change are we talking about? There are a total of 88 new sequences combining existing emoji in new ways to provide gender alternates for current characters and also professions, for which there are male and female representations. However, adding skin tone variants to these new alternate characters and professions means that in total the number of emoji has increased from 1,788 in Version 3.0 to 2,243 in the proposed Version 4.0. That’s 455 new emoji in approximately 2 months. ? (Rocket, U+1F680)
So why am I bothering to discuss unreleased, “beta” emoji? After all, the review period for the new proposed standard doesn’t close until 24 October 2016 (coincidentally the date this article is scheduled to be published). I’m covering all of this because implementations are already rolling out these changes. It’s no longer possible to accurately describe the current level of emoji support on these platforms without mentioning the proposed Version 4.0. Now that we have covered all of the officially-official emoji through the current version of the Standard, and unofficially-official emoji included in the post-current Standard, we can make sense of emoji support for across popular platforms. ? (Dizzy face, U+1F635)
Emoji OS Support
Emoji Support: Apple Platforms (macOS and iOS)
The current version of Apple’s Mac operating system, “macOS Sierra” (10.12) released on 20 September 2016, includes well over 100 fonts, and among them one named “Apple Color Emoji”. It’s this font that contains all of the symbols for the platform’s native emoji. The same font is used by the current version of Apple’s mobile OS, iOS 10.
Users of Apple’s OS’ have typically enjoyed very good emoji support, and the newest versions continue the trend. To begin with, iOS 10 and macOS Sierra support all emoji through Unicode Version 9.0. Apple’s OS release cycle is nicely timed as far as emoji are concerned. Unicode updates are happening in the Summer, and bring with them changes to Emoji. Apple is able to roll them out across all of their platforms in the Fall.
Beyond Unicode Emoji Version 3.0, macOS Sierra and iOS 10 support the gendered ZWJ sequences that are key part of the proposed Unicode Version 4.0. However new professions and sequences that add skin tone modifiers to existing multi-person groupings didn’t make the update. As a bonus Apple threw in the Version 4.0 draft specification ?️? (Rainbow flag sequence — White flag, U+1F3F3 + Emoji variation selector, U+FE0F + ZWJ, U+200D + Rainbow, U+1F308).
In total, Apple’s newest OS updates include 632 changes and additions. Some of these changes are minor and reflect nothing more than an evolution of design sensibilities of those involved at Apple. Others are more dramatic however, most notably ? (pistol, U+1F52B), which has been changed from a realistic looking weapon to a cartoonish sci-fi water gun.
Windows 8 included a limited set of black-and-white emoji with the “Segoe UI Symbol” font. This same font was eventually added to Windows 7, providing that version of the OS with its basic emoji symbols.
Windows 8.1 was the first Windows OS to support color emoji by default, shipping with the “Segoe UI Emoji” font, which provides Windows with its unique set of color emoji symbols.
Windows 10 continues to build on increasingly good support, adding all Unicode Version 8.0 emoji, including skin tone modifiers156. However, Windows 10 did not include symbols for national flags ?? (Flag of the United States of America, U+1F1FA, U+1F1F8) ?? (Flag of Germany U+1F1E9, U+1F1EA), which are displayed as two-character country-code identifiers instead.
Note: Flag emoji are each associated with pairs of 26 individual “regional indicator symbols.” These combinations are referred to as an “emoji_flag_sequence”. It is the combination of pairs of code points together that produce a single flag emoji. For more information about flag symbols, refer to “Annex B: Flags157” in the document “Unicode Technical Report #51158.”
Windows 10 Anniversary Update159 released on 2 August 2016 (and available now via the Windows Update facility on your Windows 10 PC), brings with it a wealth of changes to emoji on Windows. The update (officially, version 1607, and the second major update to Windows 10) includes all of the new Unicode Version 9.0 emoji, but that’s just the beginning.
The Microsoft Design Language Team embarked on Project Emoji, redesigning the emoji set from scratch in under a year. From early sketches to creating a new scripting method, the team knew only emoji. Illustrators, graphic designers, program managers, font technicians, production designers, and scripting gurus all worked with an impressive singular focus.
It’s a testament to the acknowledged significance of emoji that Microsoft would make this kind of an effort.
The update includes “over 1700 new glyphs, with a possible 52,000 combinations of diverse women, men, kids, babies, and families.” As we’ve already discussed, Unicode 9.0 adds only 72 new emoji. The fact that Microsoft added 1700 new symbols clearly demonstrates that diversity was a critical focus of the update. Support for diversity begins with the same skin tone modifiers available under previous editions of Windows 10, now extended to more emoji. But the most ambitious effort is expansive support for family and other multi-person groups.
From the same “Project Emoji” blog post:
So if you’re a single mother with three kids, you’ll be able to create that image. If your husband is dark-toned and you’re light-toned and your two kids are a blend of both, you can apply all of those modifiers to create your own personal family emoji, one that’s sincerely representative. It extends to the couple emoji, where you can join a woman, a heart, and a woman — both with unique skin tones — for a more inclusive emoji. Because they’re created dynamically, there are tens of thousands of permutations. And no other platform supports that today.
Emoji in Windows 10 Anniversary Update gives us a good sense of the scale of expanding skin tone modifiers across flexible multi-person groupings. However this effort seems to be largely independent of Unicode Emoji Version 4.0. Missing are all of the gendered and profession emoji that are the hallmark of proposed version.
The first thing you might notice are the bold outlines surrounding each of the new emoji. But the changes go much further than that. On the minor end of the scale, virtually all emoji have a more geometric look, which contributes to an overall stronger, more readable appearance. Beyond this, many emoji are drastically different, going so far as to be essentially new interpretations. Generally speaking, the new emoji are less generic, willowy and neutral, which is to say that they are more iconic, bold and dynamic. They’ve gone from looking like designs you might see on the wallpaper in a nursery to what you’d expect of the signage in a modern building. Some examples will give you a better sense of what I’m trying to describe:
Figure 5: Emoji in Windows 10 before and after the Anniversary UpdateSmiling Face with Open Mouth, U+1F603Happy Person Raising One Hand, U+1F64BMan and Woman Holding Hands, U+1F46BDromedary Camel, U+1F42ASoft Ice Cream, U+1F366
For more information on all things emoji in Windows 10 Anniversary Update, I highly recommend the Windows Experience Blog162 post “Project Emoji: The Complete Redesign163161,” written by Danielle McClune (4 August 2016). It does a good job of covering the changes introduced with the Anniversary Update and also provides a bit of an insider’s perspective. For those of you not particularly interested in Windows, the article offers some useful general information, including a brief illustrated discussion of the emoji skin tone modifiers and the Fitzpatrick scale.
If you still can’t get enough of Windows 10 emoji goodness, the next place to turn to is Emojipedia’s blog post “Avalanche of New Emojis Arrive on Windows164,” which nicely displays an overview of the changes to emoji in Anniversary Update. Beyond that, the Emojipedia page dedicated to the Anniversary Update165 lists all of the emoji for this version of Windows, with an option to narrow the list to just the new symbols.
If all of this wasn’t enough, Microsoft has added a new emoji keyboard to improve the experience of working with its updated emoji.
It’s fair to say Microsoft has really upped its emoji game with the Windows 10 Anniversary Update. Are there any notable gaps or other issues related to Windows’ emoji support other than the absent Version 4.0 symbols? I’ll mention two…
First, the flag emoji are still missing. You will continue to see country-code identifiers, as in earlier versions of Windows 10.
Second is something of an oddity that’s specific to Windows 10 Anniversary Update (and incompatible with every other platform): Ninja Cat.
Ninja Cat is a character that started out as something of an unofficial mascot for Windows 10 among developers, making its first appearance in a presentation about the OS in mid-2014 (before its release). Apparently, Ninja Cat has proven to be popular and enduring enough over the past couple of years to justify some desktop wallpapers and an animated GIF166, coinciding with the Anniversary Update, and — you know what’s coming — there are ninja cat emoji as well.
I’m making a point of mentioning Ninja Cat because it is another example of the use of zero-width joiners. All Ninja Cat emoji (yes there’s more than one) are sequences of the ? (Cat face, U+1F431) emoji in combination with other standard emoji, connected with the ZWJ character, and resulting in new unofficial symbols.
Note: If skin tone modifiers and flexible multi-person groups are among the more important uses of ZWJ, then non-standardized mascots and gimmicks have to be among the worst, as fun as they may be.
The basic Ninja Cat is a combination of ? (Cat Face, U+1F431) and ? (Bust in Silhouette, U+1F464). Other combinations include:
Here is what those symbols look like in Windows 10 Anniversary Update (the only place you will see them):
Figure 6: Ninja Cat emoji in Windows 10 Anniversary UpdateNinja CatAstro CatDino CatHacker CatHipster CatStunt Cat
Emoji Support: Linux
If you’re a Linux user, you’ll know that these kinds of things tend to be distribution-dependent. The Unicode underpinnings are there. What may be missing is a font providing the symbols for displaying the emoji. Adding an emoji font is a relatively simple matter, and good options are available, including some that we’ll see shortly.
Emoji Support: Android
Android has supported emoji since Jelly Bean (4.1) and color emoji since Kit Kat (4.4). The latest version of Android, the recently released “Nougat” version 7.1 includes substantial changes. Like Microsoft, Google has made a big push toward ensuring its emoji support is second to none. The prior version of Android, “Marshmallow” (6.0.1), supported all of the official emoji through Unicode Version 8, with the notable exception of skin tone modifiers.
“Noto” and “Roboto” are the standard font families on recent versions of Android and Chrome. Unlike “Apple Color Emoji” and Window’s “Segoe UI Emoji,” Noto167 and Roboto168 are freely available for download, including “Noto Color Emoji,” the primary emoji font on Android.
For starters, Google is beginning to move away from the amorphous blobs that Android users are familiar with. However, Android is keeping the same gumdrops for generic faces:
Figure 8: Generic face emoji in Android Nougat (version 7.0)Slightly Smiling Face, U+1F642 (Look familiar? Yep, it’s unchanged from Android 6.0.1)Smiling Face With Open Mouth, U+1F603Face With Stuck-out Tongue, U+1F61BDrooling Face, U+1F924 (New with Unicode 9.0)Rolling on the Floor Laughing emoji, U+1F923 (New with Unicode 9.0)
Those last two, both introduced in Unicode 9.0, are proof that Google is not entirely abandoning its gumdrops. But emoji are changing where it matters most, with human-looking depictions for less generic faces, actions and groups, complete with skin tone modifiers (conspicuously absent from Android to date).
Here are a few examples to give you some sense of how much the situation has improved:
Figure 9: Comparison of Android emoji from 6.0.1 to 7.0 Dev Preview 2Man with TurbanAndroid 6.0.1: Man With Turban, U+1F473Android N Dev Preview 2: Man With Turban, U+1F473 (U+200D U+1F3FB, U+200D U+1F3FC, U+200D U+1F3FD, U+200D U+1F3FE, U+200D U+1F3FF)GirlAndroid 6.0.1: Girl, U+1F467Android N Dev Preview 2: Girl, U+1F467 (U+200D U+1F3FB, U+200D U+1F3FC, U+200D U+1F3FD, U+200D U+1F3FE, U+200D U+1F3FF)Happy Person Raising One HandAndroid 6.0.1: Happy Person Raising One Hand, U+1F467Android N Dev Preview 2: Happy Person Raising One Hand, U+1F64B (U+200D U+1F3FB, U+200D U+1F3FC, U+200D U+1F3FD, U+200D U+1F3FE, U+200D U+1F3FF)Man and Woman Holding HandsAndroid 6.0.1: Man and Woman Holding Hands, U+1F46BAndroid N Dev Preview 2: Man and Woman Holding Hands, U+1F46BCouple with HeartAndroid 6.0.1: Couple With Heart: Woman, Woman (U+1F469 U+200D U+2764 U+FE0F U+200D U+1F469); Man, Man (U+1F468 U+200D U+2764 U+FE0F U+200D U+1F468); Woman, Man (U+1F469 U+200D U+2764 U+FE0F U+200D U+1F468)Android N Dev Preview 2: Couple with Heart: Woman, Woman (U+1F469 U+200D U+2764 U+FE0F U+200D U+1F469); Man, Man (U+1F468 U+200D U+2764 U+FE0F U+200D U+1F468); Woman, Man (U+1F469 U+200D U+2764 U+FE0F U+200D U+1F468)
Nougat includes all of the new emoji introduced with Unicode Version 9169. However, despite it originally being Google’s proposal, and their continued close involvement with the beta standard, Version 4.0 emoji, including gendered emoji and professions, didn’t make the original Nougat (7.0) update.
However, just in the past few days, on 20 October 2016, Google released Android 7.1 with support for those Emoji Version 4.0 sequences. The 7.1 update is the first version of Android to include the new professions and genered emoji, as well as an expansion of multi-person groupings to include single parent families. For good measure Android 7.1 also includes ?️? (Rainbow flag sequence — White flag, U+1F3F3 + Emoji variation selector, U+FE0F + ZWJ, U+200D + Rainbow, U+1F308).
Once again, Emojipedia is a good resource for platform-specific emoji information. A page dedicated to Android Nougat 7.1170 shows all of the emoji for the most recent version the OS. You can find pages for earlier releases as well.
Emoji On The Web
The person viewing your website or application must have emoji support to see the intended symbols. We’ve specified the character set and encoding, and written emoji into our documents and UIs. The user agent renders the page and all of the characters on it, and that’s what emoji are, of course.
You’ll recognize that this is no more than the usual arrangement. However, emoji are newer than the other elements we’re used to working with, and what’s more, they occupy an odd space somewhere between text and images. Also, many of us begin with a shaky understanding of character sets and encodings. Altogether, it leads to confusion and consternation ? (Confused Face, U+1F615) in the way that only something similar to but not exactly the same as what we already know well can. Though this should come as no surprise, it’s critically important, and for that reason I’m mentioning it here at the end of the article.
A code point without a glyph is just a code point. U+2D53 (Tifinagh letter Yu) is clearly different than U+1F32E (Taco emoji). But, ultimately, we care only about the corresponding symbols ⵓ (U+2D53) and ? (U+1F32E). As usual, we’re at the mercy of our audience.
What about polyfills, shims and fallbacks? Is there anything like that we can use to improve the situation? I’m happy to say that the answer is yes.
Emoji One
The Emoji One171 project is aimed at creating a collection of up-to-date, high-quality and universal emoji resources. The largest component of the project by far is a comprehensive set of emoji that can be freely used by anyone for any purpose, both non-commercial or commercial (with attribution).
Figure 10: Emoji One set sampler
In the words of the people responsible for the project, Emoji One is:
The web’s first and only complete open source emoji set. It is 100% free and super easy to integrate.
In December 2015, Emoji One announced the upcoming release of an updated and redesigned set of all of their emoji, branded “The 2016 Collection” (Q1 2016 Version 2.1.0, January 29, 2016172). More importantly, they committed to quarterly design updates173, a promise they have made good on to date.
On May 30th, Emoji One officially released its 2nd quarterly update (Q2 2016 update, Version 2.2.0174), with a total of 624 “design upgrades,” encompassing changes to existing symbols and entirely new (to the set) emoji.
Shortly thereafter, on June 21st, and coinciding with the official release of Unicode 9.0, Emoji One released version 2.2.4175, updating its set to include the 72 new Unicode emoji along with associated skin tone sequences.
Version 2.2.4 is the current version, though Emoji One has recently begun promoting the next major update, version 3.0, teasing “The revolution begins this December.”
Currently, the Emoji One set comprises 1834 emoji, organized in nine categories, all of which can be browsed on the Emoji One website in the Emoji Gallery176 and searched via The Demo177.
emojicopy provides a responsive interface for searching emoji and copying selected symbols, with optional text, to paste into other apps.
emoji.codes offers a number of useful features, including a “Cheat Sheet180” for browsing and searching Emoji One short codes, a method of inputting emoji in applications and websites with built-in support for Emoji One.
emoji.codes’ “Family Tree181” is a table comparing emoji symbols across as many as 10 platforms (Symbola, Emoji One, Apple, Google, Windows, Twitter, Mozilla, LG, Samsung and Facebook). It’s essentially a prettier version of the same sort of table on the Unicode Consortium’s “Full Emoji Data182117” page previously mentioned.
The Family Tree is certainly much cleaner and provides a beneficial search interface. Just keep in mind that, when in doubt, the Unicode Consortium is the authoritative source.
Lastly, an Emoji Rolodex183 lists links to quite a few resources: information, libraries, scripts, plugins, standalone apps and more. There are valuable tools here and some purely fun links, too.
All Emoji One art files are available for personal and commercial use under a Creative Commons license (CC BY 4.0184). Emoji are available as PNG, SVG and font files (for Android, macOS and iOS) and can be downloaded as a complete set from the Emoji One developer page185 or individually from the gallery186.
In addition to the emoji art itself, the developer resources include a toolkit of conversion scripts, style sheets, sprite files and more.
The project also offers an extension for Google Chrome, called, fittingly, “EmojiOne for Chrome187” which is described as “four game-changers in one,” providing:
a panel in Chrome for inputting emoji
emoji character search
set-once toggling between skin tones
well, the last “game changer” is Emoji One itself (which is cheating, but I think we can let it slide)
Emoji One is, without a doubt, an important (assuming you think emoji are important) well-executed, well-maintained and ambitious project. If all of that wasn’t enough, Emoji One has paid up to become a voting member of the Unicode Consortium.
Let’s hope the project has a bright future.
We can include Emoji One in our websites and applications and know that not only will visitors see the emoji we intend, but also that the emoji we use will maintain a consistent, high-quality appearance across devices, OS’ and browsers. Come on, that’s pretty great!
To get started, you’ll want to read through the information in Emoji One’s GitHub repository188, or download the complete developer toolkit189. Presently, the toolkit is around 60 MB and includes all emoji symbols as PNG files in three sizes (64, 128 and 512 pixels), and SVG vector images as well.
If you just want to read through the instructions for getting started, the Emoji One readme on GitHub190 is probably a better option.
You will learn that Emoji One has partnered with JSDeliver191, a “free super-fast CDN for developers and webmasters” (their words, not mine) to make it easy to install on any Javascript-capable website. It’s a matter of adding a script and link element to the CDN-hosted Javascript and CSS files in the usual way.
There are also options for installing via npm, Bower, Composer and Meteor package managers. If any of those are relevant to you, then you should have no trouble at all.
Twemoji
I would be remiss if I didn’t mention that Emoji One is not your only option for open source emoji sets. In November 2014, Twitter announced on its blog that it was “Open Sourcing Twitter emoji for Everyone192.”
Figure 11: Twemoji set sampler
From the blog post:
The project ships with the simple twemoji.js library that can be easily embedded in your project. We strongly recommend looking at the preview.html source code193 to understand some basic usage patterns and how to take advantage of the library, which is hosted by our friends at MaxCDN194.…
For more advanced uses, the twemoji library has one main method exposed: parse. You can parse a simple string, that should be sanitized, which will replace emoji characters with their respective images.
Twemoji195 is hosted on GitHub and includes, among other resources, a set of emoji images as PNG files at 16 × 16, 36 × 36, 72 × 72 sizes, and SVG vectors as well.
After the initial release, a version 2 included emoji from Unicode Version 8 (as well as other changes). Subsequently, version 2.1 added symbols for all of the Unicode 9 emoji, for a total of over 1830 symbols. Presently, the current version of Twemoji is 2.2, which includes support for the gendered and profession emoji from the Unicode Emoji Version 4.0 draft, bringing the total number of symbols to 2,477. A complete download of the current version of the project is an over 400 MB ZIP file. You can read about the latest updates in the project’s ReadMe file196.
Conclusion
⛅ ? ? ? ? ?? ?
Are we done? Could it be? Do we know everything there is to know about emoji? ? (Tired Face, U+1F62B)
It might be a stretch to say we know absolutely everything there is to know, but we know what we need to know to find and understand everything there is to know. ? (Face with Look of Triumph U+1F624)
These days, I’ve been pondering what purpose we as developers have in our world. I’m not able to provide you with an answer here, but instead want to encourage you to think about it, too. Do you have an opinion on this? Are we just pleasing other people’s demands? Or are we in charge of advising the people who demand solutions from us if we think they’re wrong? A challenging question, and the answer will be different for everyone here. If you want to let me know your thoughts, I’d be happy to hear them.
Bear with me, this week’s list is a large one. Too many good resources popped up, explaining technical and design concepts, how to use new JavaScript methods to write smarter applications, how to use CSS Grid Layouts, and how to take care of your happiness.
The Safari Technology Preview 171 adds support for Custom Elements v1, rel=noopener, and stylesheet loading via a link element inside Shadow DOM subtrees. Furthermore, preloading behavior was changed — it now matches iOS where resources like images get less priority when loading.
Already available in Nightly Builds, the feature to emulate throttled network connections2 in Firefox’s Developer Tools will soon be added to the stable release, too.
How do you design a simple, usable registration form for a tax reform? @jelumalai explains the process from a designer’s perspective6, diving deep into the challenge of asking for a lot of information while maintaining a clear workflow for the user.
7 How can you master the balancing act between asking for a lot of information and keeping a form as simple and usable for the user? @jelumalai shares his lessons learned8. (Image credit: @jelumalai9)
Stefan Judis explains when to use and when not to use aria-selected12. Applying it to the current active navigation item, for example, isn’t correct, but applying it to the current active tab in a tablist, on the other hand, would be.
JavaScript’s requestIdleCallback method14 will soon come to Firefox 52. If you don’t want to wait, good news: It can already be tested in Nightly Builds and is also supported in Chrome where it adds great value to scheduling tasks in cooperation with the browser environment.
Oliver Williams shares what he learned about CSS Grid Layout16. Once you realize that it’s designed to be used alongside Flexbox and not as a replacement, you’ll slowly grasp how powerful the new technology really is.
JP de Vries shares the challenges of unfolding critical CSS17 and why most websites are better off without it.
Mike Monteiro gave an impactful talk at this year’s Beyond Tellerrand conference in Berlin. “Let Us Now Praise Ordinary People21” opens our eyes to how we can change the world and why we need to get over-hyped startups that only claim to change something to actually do meaningful work. If I can make you watch one thing this week, take 45 minutes, sit back and listen to Mike Monteiro.
selfcare.tech22 wants to help developers take better care of their health. It shows some great methods for solving common problems every one of us will face at some point.
These solar panels are certainly a cool invention23: They can pull drinking water straight from the air, up to 5 liters per day per panel. A very nice way to source water when you don’t have traditional water resources.
Every developer knows that just because a website looks like and does what it’s meant to on the latest iPhone, doesn’t mean it will work across every mobile device. In this article, we’ll highlight some of the many open device labs out there — fantastic and helpful initiatives by the community that deserve support and attention.
Open device labs (ODLs) are a response to the myriad of operating systems, browsers and devices that litter our technical landscape. They offer developers a (usually) free space to go to test their web systems, websites and apps on a range of software and hardware. This premise forms the core of the OpenDeviceLab.com1 initiative, which is a community movement to help people locate the right ODL for the job and to drum up further support for these testing centers.
Testing on a variety of real devices is crucial for ensuring the intended user experience, especially looking over the boundaries of each ones own cultural and/or economic area. But, by far not everybody has access to the necessary test bed. Think of people producing content/apps for the first world, not taking less developed regions or those with a completely different mobile device landscape into account — the business will fail on one side, since UX or even plain accessibility will suck on the other.
He adds:
ODLs even provide ways to get stakeholders and customers to live the urge for necessary budget decisions on quality assurance, accessibility and I18n and L10n.
There are now more than 150 ODLs in 35+ countries, but ODLs may have reached the peak of their popularity, given the growing attention on in-house device labs (IDLs).
While new ODLs are opening at a constant rate, a handful of ODLs have closed down due to a lack of demand. Penn State University, for example, recently closed its ODL and replaced it with a virtual-only offering, due to a lack of funding, despite being the only one in the region. This virtual testing environment now mainly uses BrowserStack and similar virtual machine (VM) platforms.
Greg O’Toole, a lecturer at Penn State University, says:
We have had fairly consistent interest and inquiry levels from groups and individual software developers from around the Penn State community and the PA community at large looking for ways to get involved and/or utilize the offerings of the ODL@PSU over the past 24 months. I am optimistic still. We have had several offers from these community members to donate Fitbit devices, old laptops, etc. which sort of orbit around the target set of devices we are looking for.
IDLs do seem to be a popular option. Many of the labs we spoke with originated on a company’s property, eventually opening up as ODLs to support the development work of others.
Christian Schaefer, freelance front-end developer from the ODL initiative, says:
I don’t think ODLs are important in today’s technical landscape, IDLs are. ODLs served the purpose of steering the people’s interest towards the topic of real device testing. And ODLs may also be blueprints for how to set up such a thing yourself, inhouse. But reality shows that ODLs are often only used by their owners/administrators.
ODLs not being used by external people has to do with convenience and also with access to development infrastructure, which is mostly only available within a company. That’s why companies started assembling their own device labs — sometimes opening it up to others, thereby creating a new ODL.
Andre adds:
In general, ODLs located at companies see way lower public usage as compared to ODLs in public places, like co-working spaces, libraries, or places that have been built solely for running the ODL. Privacy and competition are to be taken into account, this is where some companies posted excellent upfront statements and provided physical space separate from their regular offices — others didn’t.
ODLs are particularly popular in the UK and Germany, with other such labs popping up around the world. Whether you want to call them ODLs or IDLs, the need to test on physical devices seems unlikely to lose momentum.
Here are some of the best ODLs for the developer community:
This stylish lab is the only one in the Augsburg region of Germany, and you can get a free coffee if you work here. It supports its users with a balance of professional knowledge and consulting in fields such as design and UX (as a member of the German Berufsverband User Experience und Usability (UPA) group) and development (with Magento certification and Drupal Association membership).
The lab also works with the University of Applied Sciences to support its students in classes and projects.
Address: Alter Teichweg 25a, 22081 Hamburg, Germany
All devices in this test lab run with purchased OS versions and offer a virtual environment for each major Internet Explorer (IE) version and Windows operating system. You can use one of the lab’s computers equipped with a Ghost Lab license and test pages simultaneously on multiple devices. Plus, there’s free coffee and water, as well as a friendly team to chat about the latest trends and operating systems.
Address: LAUNCH/CO Hamburg, Neuer Kamp 3, 20359 Hamburg, Germany
This lab maintains a wide range of setups and devices, and it is open for ad-hoc testing sessions; that is, people can usually drop in the same day to test, without booking ahead.
It is run by fellow developers, and someone is always there to help if a question arises or advice is needed. Devices are also lent out on request.
This long-standing lab has worked in the mobile space for more than 15 years. Its work has spanned many technologies, including WAP and J2ME, CHTML (aka i-mode) and XHTML/MP, the W3C Mobile Web Initiative, the app store (thanks to the iPhone and Android devices), HTML5 and responsive web design, and it’s adapting to a (potential) future with progressive web apps.
This lab doesn’t just focus on mobile devices, though — it also houses some specialist devices, such as Oculus Rift and Google Glass.
Address: c/o BNT.DE, Löwengasse 27E, 60385 Frankfurt am Main, Germany
With continued five-star ratings24, this lab is a popular choice with its users and engages in regular meetups. It has 32 devices and offers paid testing sessions for larger companies. This busy lab also requests users to make an appointment before turning up.
This is one of the few labs in the world that uses a charging model to keep the facility up to date with OS and hardware releases, with all the money made going back into keeping the lab open. This ODL is also exploring other tasks it can help the community with, like adding usability testing facilities for guerilla user testing, session recording and remote observation.
The lab offers free access for open-source and community projects, ad-hoc rates from £25 per hour for small businesses, and monthly subscriptions that help it maintain recurring revenue and stay open.
The team also built a private test lab for the Scottish government’s web team and is currently working on some interesting analytics tools for identifying the right test coverage for your audience.
Address: The Old Treasury, 7a Kings Road, Southsea, PO5 4DJ, UK
This lab may have been open only a few months, but its dedicated private space is already home to several key devices. All devices are laid out and labelled on shelves, with a work area where you can use browser sync on your laptop to experiment with the layout.
The ODL space can also be booked for usability testing31. It houses dedicated Windows and Mac laptops that stream user website tests to a screen outside the room for observation and analysis. This facility allows developers and designers to ensure that every project delivers a seamless and engaging user experience.
Address: 12 Basepoint, Andersons Road, Southampton, Hampshire, SO14 5FE, UK
With more than 25 devices, ranging from an iPhone 6 Plus to an old HTC Desire rocking Android 2.2, this ODL allows the local community to test on real devices, old and new, to make sure their projects work for as many people as possible.
This ODL is a big fan of progressive enhancement and encourages people to build resilient and inclusive websites. The relaxed and collaborative environment in the office also means that team members are on hand for advice.
Adam Tomat from the lab says, “We started the ODL because the local community is important to us. We recognised how difficult it is to test responsive websites without access to real devices and also how unfeasible it is for every individual or organisation to acquire a large enough selection. It’s been a great way for us to connect with new people, start conversations and help to build on the existing digital community here in Southampton.”
Address: We Are Base, 65 Seamoor Rd, Bournemouth, BH4 9AE, UK
Believed to be the largest collection of open devices in the world, this ODL has more than 440 devices available to use for web and app testing. With everything from brand new devices to old niche devices available, you can book for 1 to 2 hours per day, and only 10 devices can be booked out at a time, for security reasons.
Aside from being the largest in the world, this lab is right in the heart of one of the UK’s fastest-growing tech clusters in Bournemouth and Poole and provides an essential resource for local agencies, product teams, freelancers and students.
Address: Harella House, 90-98 Goswell Road, London, EC1V 7DF, UK
This popular London-based device lab has four hot seats in its studio, so you get access to a lot of kit, and you can feel like part of the studio as you see the lab’s practitioners at work.
Former managers have given each of the lab’s devices a name under their own naming convention. The current manager names devices after movie characters. Its latest phone is “Johnny the iPhone 7 Plus,” which you might recognize from the Short Circuit films. If you’d like to use Johnny or any of his 52 companions, write to device.lab@foolproof.co.uk41.
43 Cover-Up has an impressive lineup of devices, all of which the lab originally used to test its own products. (View large version44)
Address: Unit 1, George Street, Bridgend, CF31 3TS, UK
Cover-Up’s core business is creating innovative accessories for a selection of phones, tablets and laptops. As a result, for each new product range that it creates, it always buys the device, so that it can test firsthand. So, the company has a huge selection of gadgets that laid around for many years gathering dust — until its ODL was born.
The ODL now houses dozens of devices and is open 9:00 to 17:00, Monday to Friday. Just drop the team an email to book a spot at this ODL serving South Wales.
This lab holds a variety of screen sizes, from televisions down to watches, and also has devices of varying quality, from old monitors to HD screens. A selection of input types are available, such as trackpads, mice, styluses and screenreaders, installed to test for issues beyond just screen layout, which is a nice touch.
This balance of old and new devices is important, as Paul Burgess from the Indylab explains: “We shouldn’t assume that everyone is using the latest technology. Many people are using devices that haven’t been updated in a long time, so we include some older operating systems and pre-smartphone devices, as well as an iPod running a vintage iOS 2.2.1.”
Studio Massis is a coworking studio created by and for creative freelancers located in Gent, near the Dampoort railway station.
The space holds a range of mobile devices, and testing can be done free of charge on the premises. You can take devices to test at your own office, but there is a fee and warranty request for this service.
This new lab is just starting out, so not everything is set up yet. This ODL not only provides mobile devices for app and web development, but also has a green key, motion-capture suits and a broad range of media devices, including VR headsets and cool stuff like Leap Motion.
The lab depends on Erasmus University College Brussels, so priority goes to students during weekdays. The lab is reserved every Wednesday, serving visitors from 13:00 to 21:00.
This ODL contains a lot of obscure devices with non-mainstream operating systems such as Firefox OS, BlackBerry Playbook and even a few webOS, Ubuntu Phone and Tizen devices. Access to the device lab is free, and coffee is even provided.
The lab recently received a great number of donated devices have not yet been unpacked, tested or listed on the website. So, more to come!
58 In this closed-off device lab, you can focus on testing and debugging your application. (View large version59)
Address: Incentro Rotterdam (building Koffie, Unit 2429, 4th Floor), Van Nelleweg 1, 3044BC Rotterdam, The Netherlands
This lab is located in Van Nellefabriek, a UNESCO World Heritage Site. It houses a broad variety of devices, from the more common iPhone devices to old BlackBerrys, Google Glass and Oculus Rift. Visitors can also work in a closed-off space to focus on debugging and testing applications.
The lab’s goal is to help people build better software. It is used for the internal projects of digital service company Incentro60, but anyone is welcome to use this space.
Users can come here to test devices, or the lab can test a solution on your behalf (for a fee). With 18 devices and more added all the time, you can see your application on all devices simultaneously.
68 MODL is situated in a “glass box” in the middle of the inUse office, with a privacy screen available. (View large version69)
Address: C/O inUse, Gustav Adolfs Torg 10B, 4th floor, Malmö, Sweden
This lab is hosted in a cozy office, populated mostly by experienced digital designers — but it is run by a couple of passionate front-end developers. There’s always free coffee, and you can also chat with others in the same industry while you take a break from testing. Despite being in an open office, you can pull the drapes on the glass box for some privacy while testing.
This ODL only allows for websites to be tested, not native apps, due to administrative difficulties with developer units.
Address: Rue de Sébeillon 9B, 1004 Lausanne, Switzerland
With free coffee, this ODL is the first one in the French-speaking part of Switzerland. The team takes the time to help users set up and use their devices. The lab is now also available in a portable format (a suitcase), which you can take with you (free of charge) to test from your place of work.
The local multimedia school (Eracom) often comes to look at its projects on old devices, and user-testing sessions are also organized in the lab twice a month.
Address: 3635 Perkins Ave, Cleveland, Ohio 44114, USA
The thunder::tech User Experience Lab provides an array of devices that cover a wide range of operating systems and screen sizes, for testing most real-world scenarios. It also houses some unusual items, including a 3D printer for rapid prototyping, wearables such as Google Glass, Samsung Gear VR, Apple Watch, Android Wear watch and interactive devices such as Leap Motion.
Over the last year, this ODL has hosted a Cleveland UXPA event, in which the lab discussed its process for testing clients’ websites. Madison Letizia, social-media team manager at thunder::tech, says, “That’s a big step from where our lab was started many years ago as it originally used only employees’ personal smartphones to fill the need of website testing for client projects. It quickly evolved into the MTL (Mobile Testing Lab) with dedicated devices and today it is officially a User Experience Lab, providing countless opportunities to experience tech, express creativity and learn something new.
Address: 505 S. Rosa Road, Suite 225, Madison, WI 53719, USA
This completely community-supported lab has been built up by various members over time. It’s free to any member in the coworking space who wants to use it.
The ODL is expanding soon, so anyone considering using the space should come and check it out.
Aside from being the only Open Device Lab in Montreal, this lab is not just a library of devices: It’s run by a friendly team of professional software testers who will happily provide advice and share their knowledge with visitors over coffee.
This ODL is located in the heart of downtown Montreal, so it’s easily accessible by public transportation. It is open on the usual business days between 8:00 am and 18:00. If you can give the team a heads up before visiting, this gives them a chance to prepare a comfortable workspace for the day.
Address: 208 SW 1st Ave, Suite 240, Portland, OR 97204, USA
This friendly community device lab provides a quiet space where people in Portland can come to test their work on a variety of devices.
Of the dozens of mobile devices, cofounder Jason Grigsby says, “We’d love for more Portlanders to come use it. We enjoy sharing our space and learning what people are working on.”
86 Here is Monkop at work, crawling this application on several devices at once and automatically in the device lab (View large version87)
Address: Jose Ellauri 1126, Montevideo, Uruguay
Abstracta is a software company focused on QE, so it knows how to help ODL users. The organization has partnered with Monkop88 to have many bots automatically run test flows in parallel, while measuring application performance on real devices.
90A few extra shelves similar to the one in this picture are to be donated to other ODLs in Bangkok. (View large version91)
Address: 20 Satri Witthaya 2 Soi 17, Lat Phrao, 10230 Bangkok, Thailand
Thailand’s first ODL was originally started by a team for its own testing needs, before they decided to share their resources with the web and development community in Bangkok.
According to the lab, traffic in Bangkok can be a nightmare, so more ODLs are required in other parts of town to combat this issue. BK Device Lab has built a few extra shelves to store the devices, which can be donated to these other labs based around Bangkok to help them get started.
The devices in this lab are chosen with its local (South African) users in mind and are updated every now and then based on research and statistics, which means the selection leans towards feature phones and lower-end smartphones.
The devices are purposefully kept relatively low in number but cover a wide range of variables (input method, form factor, quality and condition of hardware, device capabilities). The high-level categories that a device belongs to (for example, old Android, cheap smartphone) are more important than the device itself: The lab is aiming for support across a wide range of these variables. Its focus is to help people build “future-friendly things.”
A couple of devices in the lab might seem odd to include (like the Amazon Kindle Touch, the Sony Playstation Vita and the Nintendo 3DS XL) because these aren’t particularly popular devices for web browsing in South Africa, but they are a good way to testing your website on an old device and browser.
Address: Level 1, 346 William Street Perth, Western Australia
As western Australia’s first (and only) ODL, this space includes a free workspace with a library full of web-related books and a rotating collection of records.
The space is open to all digital professionals, game developers, makers, freelancers and students alike. You can also book for intimate industry and networking events.
Address: UXBERT Usability Lab, Al Nemer Center 1, Olaya Street, Riyadh 11372, Saudi Arabia
This state-of-the-art ODL is the only one in Saudi Arabia and only one of three in the Middle East. It’s located in the only commercial usability testing lab in Saudi Arabia and is equipped with the latest technology, including an Oculus Rift, eye-tracking tools and brain EEG control devices.
Large corporate, government and other businesses pay for Arabic UX and usability-testing consulting services based on a project’s requirements, but use of the ODL is completely free for unfunded startups and entrepreneurs. All the lab asks is that you book in advance to ensure that the lab and devices are available.
As well as testing for quality or bugs, visitors can also take advantage of its usability testing lab (depending on equipment availability) to test with real users and record those tests, but you need to bring your own users.
Nadeem Bakhsh, a senior UX, usability and ecommerce consultant at the UXBERT Usability Lab, sas, “Saudi’s tech startup community is young, but it’s full of ambitious people with innovative ideas. We started this device and usability lab to help support these startups to turn their ideas into reality. Using the lab, they not only get access to devices for testing, but can bounce ideas and get insights from our team of Arab UX, usability and ecommerce experts to help develop their ideas into wireframes, user journeys and prototypes.”
This lab has a great mix of new technology and some really ancient devices. The oldest in its collection is a Nokia N85, and it’s got an Oculus Rift and Leap Motion Controller as well. Run by Foolproof104, an experience design agency, it does a lot of usability testing alongside other research and also houses a testing and observation lab.
Located at Seah Street in Singapore, a short walk from City Hall MRT station, this ODL is open during usual business hours.
Have more open device labs you want to share? Please let us know in the comments. Thank you!
I have been drawing desktop wallpapers for Smashing Magazine’s monthly collections for over a year now, and every time it’s a very fun and challenging mission. In this article, I would like to share how I approach all stages of the process and provide general techniques for creating vector illustrations in Adobe Illustrator. Hopefully, you will find these techniques useful.
While referring to a particular drawing — the illustration for the “Understand Yourself” desktop wallpaper, which was featured in May’s wallpaper collection this year1 — I’ll also highlight key takeaways from my experience as an illustrator and designer.
2 The “Understand Yourself” illustration, featured in the May 2016 desktop wallpapers collection (View large version3)
The idea for “Understand Yourself” derived from my curiosity about the future relationship between robots and human beings (artificial intelligence has become a thing recently). How would a robot go about understanding human emotions? By doing the same things that people do, of course. Hence, a pensive robot staring at the sunset.
Let’s take a closer look at it and see how it was made.
Although vector artwork is scalable without compromising quality, you have to decide on the ratio. I prefer 4:3 and 16:9 because these are fairly common standards for most screens. Also, bear in mind that, despite the perfect scalability of vector graphics, working with curve anchors and colors in small areas is sometimes onerous.
Composition
Rules are made for breaking. But we should know which are supposed to get broken, right? One that I really like is the rule of thirds4. It is easy and it works well. The key idea is that main objects should be located at the intersections of the grid lines. If you are willing to learn more about composition, I can’t recommend anything better than the book Framed Ink5.
Depth
To make an illustration look more natural, create depth. You can achieve this by placing some objects closer to the viewer and some farther.
Framing
Don’t fret that some of your artwork will get trimmed; account for it while drawing. The rule of thumb is to think of your illustration as a clipping from a much bigger picture. While drawing, don’t try to squeeze all objects into the canvas; let them hang out. This is even more relevant if you are planning to turn your artwork into a wallpaper with multiple versions.
Detail
Adding detail is a great way to make your illustration more attractive. The more thorough the work is, the more one will want to explore it, and the more truthful it will look. On the other hand, adding detail might (and most of the times does) take a lot more time than creating a decent illustration that you are satisfied with.
Perfection
Don’t be afraid to make mistakes. There is always someone (future you, as well) who is better at composition and coloring. Your drawing won’t be flawless, and over time you will notice a lot of things you didn’t pay attention to or just missed. At the same time, the only way to learn something is to make mistakes. That’s how it works.
Since the dawn of the human race, storytelling has been one of the most exciting forms of communication. It teaches, it captivates, it makes us think.
An illustration might look static, but it doesn’t have to be. Creating a story within a still image is easier than you might think. All you have to do is to imagine that your artwork is a middle frame of a movie. Technically, a movie is a sequence of images played at high speed, so that the eye doesn’t notice the change of frames.
Think about what happened before the frame you are working on and what might happen after. Let’s think about what’s happening at the moment as well. What led to our frame? What are the causes and consequences?
The art of storytelling is not about what you tell the viewer, but rather how people perceive what you are telling. A good story sources its power from people’s emotions and memories; it resonates with the viewer.
In my opinion, the most important part of the idea-generation process is doodling. This fun and simple activity creates plenty of ideas fast. Of course, you have to sift through them later, but quantity is what matters at this point. All you have to do is start drawing random things. The beauty of doodling is that you don’t have to think hard — your subconscious does all the work. Almost all of my illustrations, logo concepts and comic strips have evolved from doodles.
Try not to tie your artwork to a specific topic if it’s not absolutely necessary. Strong illustration works on its own. In our case, while the concept is connected to the nice weather in May and the beginning of a new season, it could easily be deprived of that context without losing its meaning.
Observe the world around you; get inspired. Think outside the box, because every new idea is a combination of old ones. Jack Foster’s How to Get Ideas9 is a wonderful read on the topic.
A paper sketch will capture your initial idea (materialize it, if you will). A loose paper sketch will help you to evaluate proportions and composition as well. I prefer not to trace my sketches later but to draw, peeking at the sketch from time to time. If you do not stick to the sketch 100%, you will have more freedom to experiment with details and to see where the illustration takes you.
The background is extremely important because it sets the mood and affects the colors you will pick later for the hero and the surroundings.
Open Adobe Illustrator, and create a new document by hitting Cmd/Ctrl + N. Type 2560px in the “Width” field and 1440px in the “Height” field. Choose RGB color mode, because we are creating an illustration that will be used on digital screens only. (Note: Shift + O activates the artboard editing mode, so you can change the dimensions of the artboard if you want to alter them or in case you typed them in wrong.)
Hit M to select the Rectangle tool, and click anywhere on the artboard. Type in the same width and height values as your artboard’s (2560px and 1440px).
The safest way to align our rectangle is to use the “Align to Artboard” option from the dropdown menu in the top control bar. Alternatively, you can move the rectangle around and wait for the live guides to help you align it.
Let’s use a gradient as the background to represent the sky. Select the Gradient tool from the toolbar (if the Gradient tool is missing in the toolbar, go to the top menu and select Window → Gradient). By default, a gradient is white to black.
If you would like your colors to look more real, go ahead and search for some reference pictures of your subject. Get some insight into perspective, lighting, composition, depth and everything else. Pick the colors from the image, and play around with them until you are satisfied with the result.
You can adjust the colors by selecting the respective peg located right under the gradient preview in the Gradient panel. I prefer HSB color mode because it enables me to control the hue, saturation and brightness more predictably than RGB or CMYK do.
Select “Radial” as the gradient type from the “Type” dropdown list located at the top of the Gradient panel.
Gradient shape values can be modified by hitting G. Stretch, resize and move the gradient around until the desired effect is reached. In our illustration, I want the sunlight to go from the bottom-right corner all the way to the top-left in a circular manner.
I recommend hitting Cmd/Ctrl + 2 as soon as you are fine with the values, so that we lock the background graphic and don’t accidentally select it later. Plus, we can select multiple objects on the artboard much more easily by clicking and dragging the cursor over these objects.
Once the background is in place, we can move on to adding more objects to the scene. Using an iterative approach, we’ll start by “blocking” colors of our shapes. Then, we’ll gradually add more and more detail.
Tip: Save versions of your artwork. It will help you to track your progress and even to revert if you got stuck at some point.
In Adobe Illustrator, you can choose between several drawing tools. I recommend drawing with the Pencil tool (N) and modifying paths with the Pen tool (P). The Pen tool is more precise and enables you to add, delete and convert anchor points on a path.
I always start by drawing shapes and filling them with a plain color. This technique is called blocking32. Blocking colors within shapes gives you a rough idea of how the illustration will look color-wise. Also, with the primary color in place, it’s much easier to determine which colors to use for highlights and shadows.
Let’s add some mountain peaks to our scene. As we know from sourcing reference images, objects that are closer to us are darker. I am going to make them not black, though, but dark-blue instead. We’ll save black for objects that are even closer.
If you hold Shift while drawing with the Pencil tool (N), the line will be perfectly straight. Let’s draw a cloud and see how a straight line is helpful sometimes. I will use BD5886 for the cloud. Playing around with an object’s opacity is all right, but I prefer to adjust the color manually. (In most cases, lowering the opacity is not enough because real objects tend to reflect colors around them.)
I am always tempted to clone already drawn shapes, but this is a bad habit. Try to avoid copying and pasting as much as you can. Copying the same type of object (another cloud for instance) seems like a quick win. But you won’t save a lot of time, and viewers will spot the clone and smirk. We don’t need that.
In some cases, though, cloning is acceptable. Drawing each leaf independently to create foliage, for example, can be painful. Instead, create as many leaves as you can, and then resize, flip or rotate copies to make them look different.
36 Copying and pasting elements of an illustration is acceptable in some cases, but handle with care. Nothing wrong with cloning foliage, for example. (View large version37)
For the robot’s body, let’s pick cold colors. But keep in mind that the overall atmosphere is warm, so we’ll mix cold gray with a bit of red.
Hit Ctrl + G to group multiple layers belonging to the same object (like a head or foot). It will be easier to rotate, resize or change their position later if required. Send groups to the back or bring them to the front using Cmd/Ctrl + [ or Cmd/Ctrl + ], respectively.
As I mentioned, the Pencil tool is a great simulation of a real pencil (especially if you are using a graphic pen tablet). And the Pen tool comes in handy for tweaking curves.
Another helpful tool is the Smooth tool, which enables you to smoothen curves.
Another nice thing about the Pencil tool (N) is that you can easily modify an existing path simply by drawing on top of the curve. This feature is very helpful for closing an open path, smoothening corners and adding areas without having to draw an additional shape.
To make objects more realistic, let’s add shadows (darker areas), where the light barely reaches the surface. Obviously, some tree bark and some leaves on the branch will need to be darker than the rest of the foliage.
Did you notice that the drawn path automatically becomes smoother? You can adjust the smoothness by double-clicking on the Pencil tool. This will show a dialog containing “Fidelity” and some other options.
47 Quick tip: Almost every tool has dedicated options. Just try double-clicking on it. (View large version48)
Add more shadows along the branch shape, the robot’s body and the foliage, using the same drawing technique.
Highlights (i.e. areas where light reflects off the surface of an object) are just as important as shadows. Let’s add some bright patches along the curve of the tree branch.
Draw a shape along the branch. Hit Cmd/Ctrl + C to copy the branch shape and Cmd/Ctrl + Shift + V to paste the shape in the same place on top of all other objects. Now, select both shapes (the branch and the highlight), go to the Pathfinder panel, and hit “Unite.” “Unite” merges two shapes into one where they overlap. Thus, we’ll have the exact same curve where the highlight follows the branch shape. Holding Shift while using the color picker allows you to pick a single color from a gradient. If you are not holding Shift, the shape will be filled with a gradient of the source object.
We’ll use the same technique for every highlight or shadow that “touches” the border of the shape beneath it. This effect can be achieved using masks; however, masks keep both shapes intact. Selecting masked shapes later might be difficult if you have multiple shapes with the same mask (in our case, the branch is a mask, and the highlights and shadows are masked shapes).
It’s time to add details such as a backpack, a green light on the robot’s head and a reflection on his face. We can also fine-tune some shapes and lines, remove leftovers, and fix inconsistencies. As soon as you like the look of your illustration, stop.
Sometimes I’ll put some grain on top of an illustration by making a layer with monochrome noise in Adobe Photoshop. It adds a little texture to the illustration and smoothens the gradients. It’s especially useful when gradients have noticeable step wedges.
To import your vector art to Adobe Photoshop, select all of your graphics by hitting Command + A, and drag and drop them into Photoshop. Embed as a “Smart Object,” which will enable you to scale the vector artwork up and down without losing quality.
Create a new layer with Command + Shift + N, and fill it with white color. Then, go to Filters → Noise → Add Noise in the main menu. Set the noise level to 100%, and hit “OK.” In the layers panel, set the “Blending mode” to “Overlay” and the “Opacity” to your liking (I usually go with 3 to 5%).
56 Adding a noise layer gives the illustration some extra texture and smoothens the gradients. Left: Our illustration without the noise layer. Right: After adding the noise layer. (Lager version57)
Now we can correct the colors. Hit Cmd/Ctrl + M in Photoshop to open the dialog for curves. Select the “Red,” “Green” or “Blue” channel from the dropdown and play around with the curves.
While most artists, designers and illustrators are eager to develop their own distinctive style, always think of the purpose, the objective, the “why.” Style is merely a means of achieving your objective. Style sells, no doubt — clients will recognize you by your style. At the same time, it will limit the viewer’s expectations of you as an artist, designer or illustrator.
While picking colors from a real image is sometimes reasonable, it depends greatly on the style you’re going for. Black and white with acid color spots here and there? Pale and subdued? Each style demands its own approach to color. What works for a book cover (catchy and provocative) might not work for a wallpaper (imagine staring at extremely bright colors every day).
I always run into the dilemma of which is more important: the idea or the execution of the idea. Your illustration might contain an interesting idea, yet if it’s poorly drawn, it won’t be compelling enough. On the contrary, if your artwork is superb and rich in detail but lacks an idea, is it doing its job? Is it moving people?
Nothing is perfect except pizza, so don’t get stuck in pursuit of perfection. Let the dust settle, and return to your artwork a day or two after finishing it. But don’t leave it unseen for too long. Would you prefer to get it done and move on, or meticulously improve it pixel by pixel?
Illustration is a great way to boost many of your skills and to experiment with drawing techniques, colors and composition. These skills will make you a better specialist in any creative field (such as animation and web design, to name a couple). Just remember that a solid illustration requires patience and is rarely done quickly. The good news is that it pays off.
Buttons are a common element of interaction design. While they may seem like a very simple UI element, they are still one of the most important ones to create.
In today’s article, we’ll be covering the essential items you need to know in order to create effective controls that improve user experience. If you’d like to take a go at prototyping and wireframing your own designs a bit more differently, you can download and test Adobe XD1 for free.
How do users understand an element is a button? The answer is simple. Visual cues help people determine clickability. It’s important to use proper visual signifiers on clickable elements to make them look like buttons.
A safe bet is to make buttons square or square with rounded corners, depending on the style of the site or app. Rectangular shaped buttons were introduced into the digital world a long time ago, and users are very familiar with them.
2 Windows 95 at first run: notice that every button, including famous ‘Start’ button, has a rectangular shape. Image credit: Wikipedia3. (Large preview4)
You can, of course, be more creative and use other shapes, (circles, triangles, or even custom shapes), but keep in mind unique ideas can prove to be a bit riskier. You need to ensure that people can easily identify each varying shape as a button.
5 Here, the Floating Action Button (FAB), which represents the primary action in an Android application, is shaped like a circled icon.
No matter what shape you choose, be sure to maintain consistency throughout your interface controls, so the user will be able to identify and recognize all UI elements as buttons.
Why is consistency so important? Well, because users remember the details, whether consciously or not. For example, users will associate a particular element’s shape as the “button.” Therefore, being consistent won’t only contribute to a great-looking design, but it’ll also provide a more familiar experience for users.
The picture below illustrates this point perfectly. Using three different shapes in one part of your app (e.g. system toolbar) is not only confusing to the user, it’s incorrect design practice.
6 There’s nothing wrong with creativity and experimentation, but keep the design coherent. (Large preview7)
Shadows are valuable clues, telling users at which UI element they are looking. Drop-shadows make the element stand out against the background and make it easily identifiable as a tappable or clickable element, as objects that appear raised look like they could be pressed down, (tapped or clicked). Even with flat buttons (almost flat, to be exact), there are still places for these subtle cues.
8 If a button casts a subtle shadow, users tend to understand that the element is interactive.
Users avoid interface elements without a clear meaning. Thus, each button in your UI should have a proper label or icon9. It’s a good idea to base this selection on the principles of least astonishment: If a necessary button has a label or icon with a high astonishment factor, it may be necessary to change the label or icon.
The label on actionable interface elements, such as a button, should always tie back to what it will do for the user. Users will feel more comfortable when they understand what action a button does. Vague labels like ‘Submit,’ or abstract labels like in the example below, don’t provide enough information about the action.
10 Avoid designing interface elements that make people wonder what they do. Image credit: uxmatters11
The action button should affirm what that task is, so that users know exactly what happens when they click that button. It’s important to indicate what a button does using action verbs. For example, if a user is signing up for an account, a button that says, ‘Create Account,’ tells them what the outcome will be after pressing the button. It’s clear and specific to the task. Such explicit labels serve as just-in-time help, giving users confidence in selecting the correct action.
12 A button’s label should say exactly what will happen when the user presses it. Image credit: Amazon13
If you’re designing a native app, you should follow platform GUI guidelines when choosing a proper location and order for buttons. Why? Because applying consistent design that follows user expectations saves people time.
You should consider how large a button is in relation to the other elements on the page. At the same time, you need to ensure the buttons you design are large enough for people to interact with.
18 Smaller touch targets are harder for users to tap than larger ones. Image credit: Apple19. (Large preview20)
When a tap is used as a primary input method for your app or site, you can rely on the MIT Touch Lab21 study to choose a proper size for your buttons. This study found that the average size of finger pads are between 10–14mm and fingertips are 8–10mm, making 10mm x 10mm a good minimum touch target size. When a mouse and keyboard are the primary input methods, button measurements can be slightly reduced to accommodate dense UIs.
22 10mm x 10mm is a good minimum touch target size. Image credit: uxmag23
You should consider the size of button elements, as well as the padding between clickable elements, as padding helps separate the controls and gives your user interface enough breathing space.
This requirement isn’t about how the button initially looks to the user; it’s about interaction experience with the UI element. Usually, a button isn’t a one-state object. It has multi-states, and providing visual feedback to users to indicate the current state should be a top priority task. This helpful illustration from Material Design27 makes it clear how to convey different button states:
28 Make sure you consider the hover, tap, and active states of the button. Image credit: Material Design29.30 This animation shows the button’s behavior in action. Image credit: Behance31. (Large preview32)
Visually Highlight The Most Important Buttons Link
Ensure the design puts emphasis on the primary or most prominent action. Use color and contrast to keep user focus on the action, and place the button in prominent locations where users are most likely to notice it.
Important buttons, (such as CTAs,) are meant to direct users into taking the action you want them to take. To create an effective call-to-action button, one that grabs the user’s attention and entices them to click, you should use colors with a high contrast in relation to the background and place the button in the path of a user.
If we look at Gmail’s UI33, the interface is very simple and almost monochromatic, with the exception of the ‘Send’ button. As soon as users finish writing a message, they immediately notice this nice blue button.
34 Adding one color to a grayscale UI draws the eye simply and effectively.
The same rule works for websites. If you take a look at the Behance35 example below, the first thing that will catch your attention is a “Sign Up” call-to-action button. The color and the position, in this case, is more important than the text.
36 The most important call-to-action button stands out against the background. (Large preview37)
Visual Distinctions for Primary and Secondary Buttons Link
You can find another example of grabbing the user’s attention with buttons in forms and dialogues. When choosing between primary and secondary actions, visual distinctions are a useful method for helping people make solid choices:
The primary positive action associated with a button needs to carry a stronger visual weight. It should be the visually dominant button.
Secondary actions, (e.g. options like ‘Cancel’ or ‘Go Back’,) should have the weakest visual weight, because reducing the visual prominence of secondary actions minimizes the risk for potential errors, and further directs people toward a successful outcome.
38 Notice how the primary action is stronger in color and contrast. Image credit: Apple39. (Large preview40)
While every design is unique, every design also has a set of items in common. That’s where having a good design checklist comes in. To ensure your button design is right for your users, you need to ask a few questions:
Are users identifying your element as a button? Think about how the design communicates affordance. Make a button look like a button (use size, shape, drop-shadows and color for that purpose).
Does a button’s label provide a clear message as to what will happen after a click? It’s often better to name a button, explaining what it does, than to use a generic label, (like “OK”).
Can your user easily find the button? Where on the page you place the button is just as important as its shape, color and the label on it. Consider the user’s path through the page and put buttons where users can easily find them or expect them to be.
If you have two or more buttons in your view, (e.g. dialog box), does the button with the primary action have strongest visual weight? Make the distinction between two options clear, by using different visual weight for each button.
When looking at the visual distinction for ‘Submit’ button, it should be visually dominant over the other button. Image credit: Lukew
Buttons are a vital element in creating a smooth user experience, so it’s worth paying attention to the best essential practices for them. A quick recap:
Make buttons look like buttons.
Label buttons with what they do for users.
Put buttons where users can find them or expect them to be.
Make it easy for the user to interact with each button.
Make the most important button clearly identifiable.
When you design your own buttons, start with the ones that matter most, and keep in mind that button design is always about recognition and clarity.
This article is part of the UX design series sponsored by Adobe. The newly introduced Experience Design app47 is made for a fast and fluid UX design process, creating interactive navigation prototypes, as well as testing and sharing them — all in one place.
You can check out more inspiring projects created with Adobe XD on Behance48, and also visit the Adobe XD blog49 to stay updated and informed. Adobe XD is being updated with new features frequently, and since it’s in public Beta, you can download and test it for free50.
Editor’s note:Please note that this article is quite lengthy, and contains dozens of CodePen embeds for an interactive view. The page might take a little while to load, so please be patient.
Layout on the web is hard. The reason it is so hard is that the layout methods we’ve relied on ever since using CSS for layout became possible were not really designed for complex layout. While we were able to achieve quite a lot in a fixed-width world with hacks such as faux columns, these methods fell apart with responsive design. Thankfully, we have hope, in the form of flexbox — which many readers will already be using — CSS grid layout and the box alignment module.
In this article, I’m going to explain how these fit together, and you’ll discover that by understanding flexbox you are very close to understanding much of grid layout.
CSS grid layout is currently behind a flag or available in the developer and nightly builds of Firefox, Safari, Chrome and Opera. Everything you see here can be seen to be working if you use a developer or nightly browser or enable the flag in a mainstream browser that has flagged support. I am trying to keep an up-to-date list of support for grid layouts1.
Both grid and flexbox are new values for the display property. To make an element a flex container, we use display: flex; to make it a grid container, we use display: grid.
As soon as we do so, the immediate children of our flex or grid container become flex or grid items. Those immediate children take on the initial values of flex or grid items.
In the first example, we have three elements in a wrapper element set to display: flex. That’s all we need to do to start using flexbox.
Unless we add the following properties with different values, the initial values for the flex container are:
flex-direction: row
flex-wrap: no-wrap
align-items: stretch
justify-content: flex-start
The initial values for our flex items are:
flex-grow: 0
flex-shrink: 1
flex-basis: auto
We’ll look at how these properties and values work later in this article. For now, all you need to do is set display: flex on a parent, and flexbox will begin to work.
To lay out items on a grid, we use display: grid. In order that we can see the grid’s behavior, this example has five cards to lay out.
Adding display: grid won’t make a dramatic change; however, our child items are all now grid items. They have fallen into a single-column track grid, displaying one below the other, the grid creating implicit row tracks to hold each item.
We can take our grid a step further and make it more grid-like by creating some columns. We use the grid-template-rows property to do this.
In this next example, I’ve created three equal-width column tracks using a new unit that has been created for grid. The fr unit is a fraction unit signifying the fraction of available space this column should take up. You can see how our grid items have immediately laid themselves out on the grid, one in each created cell of our explicitly defined columns. The grid is still creating implicit rows; as we fill up the available cells created by our columns, new rows are created to hold more items.
Once again, we have some default behavior in evidence. We haven’t positioned any of these grid items, but they are placing themselves onto our grid, one per cell of the grid. The initial values of the grid container are:
grid-auto-flow: row
grid-auto-rows: auto
align-items: stretch
justify-items: stretch
grid-gap: 0
These initial values mean that our grid items are placed one into each cell of the grid, working across the rows. Because we have a three-column track grid, after filling the grid cell of the third column, a new row is created for the rest of the items. This row is auto-sized, so will expand to fit the content. Items stretch in both directions, horizontal and vertical, filling the grid area.
Box Alignment
In both of these simple examples, we are already seeing values defined in the box alignment module in use. “Box Alignment Module Level 3” essentially takes all of the alignment and space distribution defined in flexbox and makes it available to other modules. So, if you already use flexbox, then you are already using box alignment.
Let’s look at how box alignment works in flexbox and grid, and the problems that it helps us solve.
Equal-Height Columns
Something that was very easy to create with old-school table-based layouts, yet fiendishly difficult using positioning and floats, is equal-height columns. In the floated example below, our cards contain unequal amounts of content. We have no way of indicating to the other cards that they should visually take on the same height as the first card — they have no relationship to each other.
As soon as we set the display property to grid or flex on a parent, we give the children a relationship to each other. That relationship enables the box-alignment properties to work, making equal-height columns simple.
In the flex example below, our items have unequal amounts of content. While the background on each lines up, it doesn’t sit behind the content as it would for floated elements. Because these items are displayed in a row, the property that controls this behavior is align-items. Creating equal-height columns requires that the value be stretch — the initial value for this property.
We see the same with grid layouts. Below is the simplest of grid layouts, two columns with a sidebar and main content. I’m using those fraction units again; the sidebar has 1 fraction of the available space, and the main content 3 fractions. The background color on the sidebar runs to the bottom of the content. Once again, the default value of align-items is stretch.
We’ve seen how the default value of align-items for both grid and flexbox is stretch.
For flexbox, when we use align-items, we are aligning them inside the flex container, on the cross axis. The main axis is the one defined by the flex-direction property. In this first example, the main axis is the row; we are then stretching the items on the cross axis to the height of the flex container. The height of the flex container is, in this case, determined by the item with the most content.
We can use other values, instead of the default stretch:
flex-start
flex-end
baseline
stretch
To control the alignment on the main axis, use the justify-content property. The default value is flex-start, which is why our items are all aligned against the left margin. We could instead use any of the following values:
flex-start
flex-end
center
space-around
space-between
The space-between and space-around keywords are especially interesting. With space-between, the space left over after the flex items have been displayed is distributed evenly between the items.
We can display flex items as a column rather than a row. If we change the value of flex-direction to column, then the main axis becomes the column, and the cross axis is along the row — align-items is still stretch by default, and so stretches the items across row-wise.
We can use justify-items, too, including space-between and space-around. The container needs to have enough height for you to see each in action, though!
In a grid layout, the behavior is similar, except that we are aligning items within the defined grid area. In flexbox, we talk about the main and cross axis; with grids, we use the terms “block” or “column axis” to describe the axis defining our columns, and “inline” or “row axis” to describe the axis defining our rows, as defined in the specification43.
We can align content inside a grid area using the properties and values described in the box alignment specification.
A grid area is one or more grid cells. In the example below, we have a four-column and four-row track grid. The tracks are separated by a grid gap of 10 pixels, and I have created three grid areas using line-based positioning. We’ll look at this positioning properly later in this guide, but the value before the / is the line that the content starts on, and the value after where it ends.
The dotted border is on a background image, to help us see the defined areas. So, in the first example, each area uses the defaults of stretch for both align-items on the column axis and justify-items on the row axis. This means that the content stretches to completely fill the defined area.
In the second example, I have changed the value of align-items on the grid container to center. We can also change this value on an individual grid item using the align-self property. In this case, I have set all items to center, but item two to stretch.
In all of the examples above, I have aligned the content of the grid areas, the areas defined by the start and end grid lines.
We can also align the entire grid inside the container, if our grid tracks are sized so that they take up less space than the container that has been set to display: grid. In this case, we use the align-content and justify-content properties, as with flexbox.
In the first example, we see the default alignment of a grid where the columns and rows have been defined in absolute units and take up less space than the fixed-sized wrapper allows for. The default values for both are start.
Just as with flexbox, we can use space-around and space-between. This might cause some behavior that we don’t want as the grid gaps essentially become wider. However, as you can see from the image below and in the third example in the CodePen, we get the same space between or around the tracks as we see with flexbox.
The fixed-sized tracks will gain additional space if they span more than one track. Element two and four in our example are wider and three is taller because they are given the extra space assigned to the gap they span over.
We can completely center the grid by setting both values to center, as shown in the last example.
We have very nice alignment abilities in both flexbox and grid, and they work in a generally consistent way. We can align individual items and groups of items in a way that is responsive and prevents overlap — something the web has lacked until now!
In the last section, we looked at alignment. The box-alignment properties as used in grid and flexbox layouts are one area where we see how these specifications have emerged in a world where responsive design is just how things are done. Values such as space-between, space-around and stretch allow for responsiveness, distributing content equally among or between items.
There is more, however. Responsive design is often about maintaining proportion. When we calculate columns for a responsive design using the target ÷ context approach introduced in Ethan Marcotte’s original article on fluid grids64, we maintain the proportions of the original absolute-width design. Flexbox and grid layouts give us far simpler ways to deal with proportions in our designs.
Flexbox gives us a content-out approach to flexibility. We see this when we use a keyword value of space-between to space our items evenly. First, the amount of space taken up by our items is calculated, and then the remaining space in the container is divided up and used evenly to space out the items. We can get more control of content distribution by way of properties that we apply to the flex items themselves:
flex-grow
flex-shrink
flex-basis
These three properties are more usually described by the shorthand flex property. If we add flex: 1 1 300px to an item, we are stating that flex-grow should be 1 so that items can grow, flex-shrink should be 1 so that items can shrink, and the flex-basis should be 300 pixels. Applying this to our cards layout gives us the example below.
Our flex-basis here is 300 pixels, and we have three cards in a row. If the flex container is wider than 900 pixels, then the remaining space is divided into three and distributed between the items equally. This is because we have set flex-grow to 1 so that our items can grow from the flex-basis. We have also set flex-shrink to 1, which means that, where we don’t have space for three 300-pixel columns, space will be removed equally.
If we want these items to grow in different proportions, then we can change the flex-grow value on one or more items. If we would like the first item to get three times the available space distributed to it, we would set flex-grow to 3.
The available space is distributed after the amount needed for flex-basis has been taken into account. This is why our first item is not three times the size of our other items, but instead gets a share of three parts of the remaining space. You will see a bigger change by setting the value for flex-basis to 0, in which case we wouldn’t have a starting value to remove from the overall container. Then, the entire width of the container could be distributed in proportion to our items.
A very useful tool to help you understand these values is Flexbox Tester74. Pop the different values into the tester, and it calculates the actual sizes at which your items will end up, and explains why they end up at that size.
If you use auto as your flex-basis value, it will use any size set on the flex item as the flex-basis value. If there is no size, then it defaults to be the same as the value of content, which is the content’s width. Using auto is, therefore, very useful for reusable components that might need to have a set size on an item. You can use auto and be sure that if the item needs to be around a size defined on it, flexbox will respect it.
In the next example, I have set the flex-basis on all cards to auto. I then gave the first card a width of 350 pixels. So, the flex-basis of that first card is now 350 pixels, which is used to work out how to distribute space. The other two cards have a flex-basis based on their content’s width.
If we go back to our original flex: 1 1 300px, add more items to our example and set flex-wrap: wrap on the container, the items will wrap in order to maintain as near as possible the flex-basis value. If we have five images and three fit onto one row, then the next two will wrap onto a new row. As the items are allowed to grow, they both grow equally, and so we get two equal-sized items on the bottom row and three in the row above.
The question then asked is often, “How can I get the items on the bottom row to line up with the ones on the top, leaving a gap at the end?” The answer is that you don’t, not with flexbox. For that kind of behavior you need a grid layout.
Keeping Things in Proportion With Grid Layout
Grid layouts, as we have already seen, have a concept of creating column and row tracks into which items can be positioned. When we create a flexible grid layout, we set the proportions when defining the tracks on the grid container — rather than on the items, as with flexbox. We encountered the fr unit when we created our grids earlier. This unit works in a similar way to flex-grow when you have a flex-basis of 0. It assigns a fraction of the available space in the grid container.
In this code example, the first column track has been given 2fr, the other two 1fr. So, we divide the space into four and assign two parts to the first track and one part each to the remaining two.
Mixing absolute units and fr units is valid. In this next example, we have a 2fr track, a 1fr track and a 300-pixel track. First, the absolute width is taken away, and then the remaining space is divided into three and assigned three parts to track 1 and one part to track 2.
What you can also see from this example is that our items fit into the defined tracks — they don’t distribute across the row, as they do in the flexbox example. This is because, with grid layouts, we are creating a two-dimensional layout, then putting items into it. With flexbox, we get our content and work out how much will fit in a single dimension in a row or column, treating additional rows or columns as entirely new flex containers.
What would be nice, however, is to still have a way to create as many columns of a certain size as will fit into the container. We can do this with grid and the repeat syntax.
In the next example, I will use the repeat syntax to create as many 200-pixel columns as will fit in our container. I am using the repeat syntax for the track listing, with a keyword value of auto-fill and then the size that I want the repeated tracks to be.
(At the time of writing, this was not implemented in Chrome, but works in Firefox Developer Edition.)
We can go a step further than that and combine fraction units and an absolute width to tell the grid to create as many 200-pixel tracks as will fit in the container and to distribute the remainder equally.
In this way, we get the benefits of a two-dimensional layout but still have flexible quantities of tracks — all without using any media queries. What we also see here is the grid and flexbox specifications diverging. Where flexbox ends with distributing items in one dimension, grid is just getting started.
A Separation of Source Order and Visual Display
With flexbox, we can’t do a lot in terms of positioning our flex items. We can choose the direction in which they flow, by setting flex-direction to row, row-reverse or column, column-reverse, and we can set an order, which controls the visual order in which the items display.
With grid layouts, we get to properly position child items onto the grid we have defined. In most of the examples above, we have been relying on grid auto-placement, the rules that define how items we have not positioned are laid out. In the example below, I am using line-based positioning to position the items on the grid.
The grid-column and grid-row properties are a shorthand for grid-column-start, grid-row-start, grid-column-end and grid-row-end. The value before the / is the line that the content starts on, while the value after is the line it ends on.
You can also name your lines. This happens when you create your grid on the grid container. Name the lines in brackets, and then position the items as before but using the names instead of the line index.
You can have multiple lines with the same name, and then target them by line name and index.
You can use a span keyword, spanning a number of lines or, for example, to the third line named col. This type of positioning is useful for creating components that sit in various places in the layout. In the example below, I want some elements to span six column tracks and others to span three. I am using auto-placement to lay out the items, but when the grid encounters an item with a class of wide, the start value will be auto and the end value will be span 2; so, it will start on the line it would normally start on based on the auto-placement rules, but span two lines.
Using auto-placement with some rules in this way will likely leave some gaps in our grid as the grid encounters items that need two tracks and has space for only one. By default, the grid progresses forward; so, once it leaves a gap, it doesn’t go back to place things in it — unless we set grid-auto-flow to a value of dense, in which case, the grid will actually backfill the gaps left, taking the content out of DOM order.
There is also a whole different method of positioning items using the grid layout — by creating a visual representation of our layout right in the value of the grid-template-areas property. To do this, you first need to name each direct child of the grid container that you want to position.
We then lay the items out in this ASCII art manner as the value of grid-template-areas. If you wanted to entirely redefine the layout based on media queries, you could do so just by changing the value of this one property!
As you can see from the example, to leave a cell empty, we use a full stop or a series of full stops with no white space between them. To cause an element to span a number of tracks, we repeat the name.
Accessibility Implications of Reordering
For flexbox and even more so for grid layouts, we need to take great care when using these methods to reorder content. The specification for flexbox states111:
Authors must use order only for visual, not logical, reordering of content. Style sheets that use order to perform logical reordering are non-conforming.
Grid layout gives authors great powers of rearrangement over the document. However, these are not a substitute for correct ordering of the document source. The order property and grid placement do not affect ordering in non-visual media (such as speech). Likewise, rearranging grid items visually does not affect the default traversal order of sequential navigation modes (such as cycling through links).
In both cases, as currently defined, the reordering is only visual. It does not change the logical order of the document. In addition, we need to take great care in considering sighted keyboard users. It would be incredibly simple to cause someone tabbing through the document to tab along the navigation at the top and then suddenly be taken to the bottom of the document due to a grid item that appears early in the source being positioned there.
A New System For Layout
I’ve not covered every aspect of Grid and Flexbox in this guide – my aim being to show the similarities and differences between the specifications, and to throw Box Alignment into the mix. To demonstrate that what these specifications are bringing us is a new layout system, one that understands the kind of sites and applications we are building today.
At the present time Flexbox is all we have in production browsers, however Grid — behind a flag — is shaping up in Chrome, Opera, Safari and Firefox. Flexbox initially emerged prefixed, was used in production by developers, and then changed making us all feel as if we couldn’t rely on it. Grid is being developed behind a flag and if you take a look at the examples in this article in a browser with the flag enabled, you’ll find that the implementations are already very interoperable. With the specification now at Candidate Recommendation status, the specification is all but finished. So when Grid lands, possibly early next year, it is going to land in a very cross-browser compatible state.
Do play with the examples in the article, and there is a whole host of other stuff detailed in the resources below. I would be especially interested in use cases that you can’t achieve with these layout methods. If you find one let me know, I’m interested in finding the edges of the specifications we have so welcome a challenge.
Resources
Here are some resources to help you explore these specifications further.
I realized something the other day: I’ve been designing apps for nine years now! So much has changed since the early days and, it feels like developers and designers have been through a rollercoaster of evolutions and trends. However, while the actual look and functionality of our apps have changed, along with the tools we use to make them, there are some things that have very much stayed the same, such as the process of designing an app and how we go through the many phases that constitute the creation of an app.
Sure, collectively you could argue that we’ve become a lot better at the process. We’ve invented new terminology and even completely new job titles to better facilitate the process of designing mobile applications. But, at its core, the process remains largely unchanged.
And while this approach has become a truism in most of our industry, it’s far from obvious for anyone entering the field. A lot of articles have been written about all the different aspects of this process, but that doesn’t seem to change the fact that I encounter very basic questions from clients and new designers alike. How do you go about designing an app? So, here’s an article about just that. A top level, somewhat simplified, and very honest overview of the steps involved in designing an app. This is an account of how most of the apps I work on are born, complete with shameless links to the tools I use (several of them my own3).
It might be different from how you do it. The steps might be named differently or the tools might vary. In fact, if you’re a seasoned designer, you’ll know most of this. You might even think the content is trivial or, “something everyone knows.” In that case, you’re most likely part of the bubble we live in. But, if you’re a new designer or someone trying to understand what you’re paying other people to do, this will hopefully give you a down-to-earth overview.
Now when people think of ‘designing’ something, their thoughts often circle around the visual aspects of a product. Pixel pushing in Photoshop or laying grids in Sketch, but that’s a common misconception. Design, in the context of this article, covers the entire process. It is every deliberate action meant to produce something. The truth is that from the moment you get an idea, you are designing.
Everything starts with an idea. This might be your idea or an idea that a client has approached you with. Ideas are great, but they’re also a dime a dozen. The sooner you realize that ideas are nothing but passing phantoms of something that might one day turn into a product, the better you’ll be able to handle this phase.
We tend to put way too much stock in ideas, as getting the idea ‘right’ is far less important than people think. Ideas are sealed up and protected by NDA’s, paraded around in pitch decks, and tend to take on a very defined state much too early.
Keeping your idea malleable and changing for as long as possible is, in my experience, much healthier and leads to far better end-results. Ideas should be subjected to a healthy dose of Darwinism before being pursued – survival of the fittest. You want your idea to evolve the best version of itself, and to that end, it can make sense to talk about a circular process within this phase.
Depending on the type of idea, there are different questions to ask. In the case of apps, these are some of the most often asked questions:
Is this idea financially viable?
Making anything takes time, effort and money. Can you recoup your investment? Does the idea have a solid plan for revenue? A realistic one?
Is this idea technically feasible?
Can this be made? Who should make it? How would we go about making it? What sort of tools do we use? What sort of data/API/touch points do we need? What are the obstacles facing the implementation of the idea?
Is someone else already doing this?
Most things today are a remix. While that’s cool, what we can do better? What components of this idea differentiate it from existing ideas? How are we adding something new to the market?
Could this be made simpler/differently?
Are there other ways to accomplish the same goals? Or, are there other methods that could be more effective and take less time to execute?
Those are just a handful of the tough questions you need to ask while you or your clients’ idea is taking shape. To be honest, 90% of app ideas I’ve ever been pitched or have come up with myself, fall flat on the first question. People always underestimate how long it takes to make something and always overestimate how much they stand to gain.
Idea workshops are great ways to force the evolution of your ideas. You can use things like Trello6 to track aspects of your idea in an environment where you can move around and prioritize concepts. Collaboration helps promote the strong aspects of the concept, the ones that resonate with participants. At the same time, collaboration helps identify and eliminate what is detracting from the idea.
7 Generate, challenge, and revise ideas with others. (Large preview8)
Once you’re satisfied with an idea, it’s time to put things in writing.
A ‘Specification’ or a ‘Spec’ is the piece of paper(s) that declares what your app does and how it is accomplished. It’s the blueprint if you will. There are quite a few ways to do a spec, ranging from the lighter (also sometimes called a ‘brief’) to the enveloping complete enveloping breakdown. No matter which way you choose to go about it, always do a spec. I repeat: Always do a spec.
In client projects, specs are often contracts on which estimates can be based on – the mother document that dictates to all parties involved what needs to be made and (roughly) how. In personal or in-house projects they’re not as commonly seen as a priority, but they should be.
You’d be surprised how much of an idea is further developed, changed or refined when you’re asked to put everything in writing. Areas of uncertainty are naturally brought forward and further questions are raised. In a sense, the act of creating a spec is the first conscious and calculated ‘design’ of the solution. A lot of initial ideas and assumptions are explored and illuminated in this document, which keeps everyone involved in tune with what is being built. It can also be beneficial to periodically revisit a spec and update it retroactively while the project moves into its next phases.
A program like Pages, Word, or any other simple markup editor will be fine for this phase. The real trick is deciding what to include and what to leave out of a spec. It is best to keep things short and concise under the assumption that the more you write, the more can be misinterpreted. List both functional and non-functional requirements. Explain what your app is, and not how it needs to be done. Use plain language. In the end, the best spec is the one that is agreed upon by all parties.
Many articles could be written about the art of a good spec, however, this is not one of those articles.
Wireframes, or low fidelity mockups, can be either part of the spec or built from the spec. Information Architects (iA’s) and User Experience Designers (UX designers) usually take ownership of this phase but, the truth is it’s important that everyone on the team discuss and understand how the product is put together and how the app is structured.
If you’re a single designer working on the product, you’re likely the one holding the marker here. Draw on your experience of the platform conventions, knowledge of controls and interface paradigms, and apply that knowledge to the challenges you’re trying to solve alongside those who may have domain-specific knowledge. The fusion of knowledge on how to best achieve things on the platform, with knowledge about the target audience or the goal of the product, creates a strong foundation for the architecture of the app.
9 An example from one of our whiteboarding sessions (Large preview10)
We tend to do workshops either internally or, ideally, with the client, and go through the spec, screen by screen, and whiteboard the wireframes. The wireframes are then brought into a tool to be digitized, shared and revised. Many people prefer applications like Omnigraffle or Sketch, while some of us still use Photoshop.
There are many tools out there that will help you wireframe. On applypixels.com231911 I’ve got a wireframe UI kit12 that I use. Below is an example of how that can be done:
Here I mock up a quick low fidelity prototype of a photo sharing app.
Wireframes are the first deliberate design made in a project. Everything not caught in the production of the spec usually becomes painfully obvious during this phase. Inconsistencies in navigation, entire missing sections of the app or counterintuitive flows are brought forth, discussed and fixed. I like to think of it as the great ironing out of all the wrinkles the original idea has left behind.
13 Digital tools for wireframing can speed up the process (Large preview14)
Armed with a spec and a wireframe, you’re now ready to get serious. These are also the materials that I advise you have ready when you contract other people to work on your project. Specs and wireframes can vary greatly in quality, but showing that you’ve made those initial preparations makes all of the difference. You had an idea, you’ve committed it to a document, and you’ve thought through a proposed solution.
You’d be surprised how many people do not do this. Why? Because it’s difficult and laborious work. You need to be specific about what you want and how you propose it could be done. The single reason why most apps I’m pitched don’t get off the ground is because it is entirely more compelling to talk about the overall idea of an app instead of asking the tough questions and getting into the gritty details of how to execute it.
The next step varies greatly. In fact, the next three steps are all entwined and often run alongside each other. With the spec and the wireframe in hand, we are now ready to attempt a prototype. The word prototype in this context covers many different things, but ultimately it’s about creating a bare-bones version of the app with the goal of testing your hypotheses and get early feedback. Some people use tools like Invision15 or Marvel3216 where you can convert your low-fidelity mockups into interactive “apps” that allow you to tap through the design. Often, designers go straight for a native prototype written in Swift.
There are pros and cons to each approach. More complex and “bigger” apps with larger teams influencing the product (or with more loose specs) may benefit more from this intermediate step, where iterations are quickly and more easily shared. For smaller teams with a more solid spec, going directly to code allows for a quicker turnaround, while laying the foundation for the actual app. This also often confronts implementation issues directly as you’re actually building the real product right from the start.
There are many tools popping up that span the divide between visual design and functional prototype, while aiming to take collaborative design to new interactive heights. Both Framer3017 and Figma18 are two options worth looking at.
How you choose to prototype depends on many different factors. The most important thing in this step when deciding is getting early validation of your idea. A bad experience with a prototype might cause you to uncover issues with your wireframes, your spec, or even the very core of your idea. You can then, before you’ve invested time in the next two phases, make changes or abandon it entirely.
Now, you’ve been ‘designing’ all along, but in this phase, you get to what is more traditionally consider ‘design’. Visual design deals with the appearance of the app. It is not just making things look nice, but also making sure that there’s a consistent and identifiable visual language throughout. Here design helps, not only to tell a story and communicate your brand, to guide users through challenging parts of the app, but also to make particular aspects of the experience more enjoyable.
Proper visual design should build on top of all of the experiences you’ve made in the previous stages. It should support the overall ethos of the idea, the goals defined in the specs, the flows laid out in the wireframes, and the lessons learned from the prototype.
Visual design is not just a ‘skin’. It’s not a coat of paint applied to make things look pretty. It is the visual framework you use to create a coherent and consistent experience, tell an engaging story, and differentiate your product from others’. Great visual design elevates the mundane, clarifies the unclear and leaves a lasting impression with the user.
Rules defined in the great unwritten design manual of your product, inform every choice on every visual solution you may encounter. The work in this stage consists of the designer defining a series of rules and conventions and then applying those to every challenge he or she may encounter when putting the interface together. Luckily you don’t need to reinvent the wheel every time (even though sometimes we do just that). iOS & Android have a ton of existing rules, conventions, and expressions on which we can lean. “UI Kit with a Twist” is an expression being thrown around that covers the idea of a visual design that leans on the standard iOS UI components, but with a sassy colored navbar or other minor customizations.
There is no right way of creating a visual design for an app and this stage is probably the phase that has the most tools and approaches. If you’ve been diligent and digitized (and updated) your wireframes you could start to add embellishment to those and build it from there in Sketch or Photoshop. Another place to start is to base your design off existing iOS UI elements and then tweak from there.
I usually start my visual design based on a UI kit, like the one available from applypixels.com231911 (available for both Sketch20 & Photoshop21). This lets me lean on iOS conventions while attempting to break the mold and experiment in subtle but meaningful ways. There are many other UI kits out there, and places like ui8.net22 can be particularly great sites to find a pre-made style.
Visual design doesn’t end when you hand something off to the developer. It is a continued and constantly evolving process, evaluating your visual rulebook and the choices that dictate. You may find yourself delivering and redelivering assets or tweaking interactions, right up until you ship.
Next up, or as is sometimes the case, alongside, is the development of the app. In an ideal world, the person responsible for developing the app has been part of all previous phases, chiming in with his or her experience, deliberating on the difficulty level of implementation of various proposed designs, and discussing best practices in terms of structure, tools, libraries, and so on.
I am familiar with the desire to clearly separate development from design, both from an organizational and a cultural perspective. It is my clear conviction that the best products are built by teams made of multiple professionals from various disciplines who have a mutual understand of each other. Development shouldn’t be devoid of a design presence and design shouldn’t be without development know-how.
There’s an obvious balance to this. Designers probably shouldn’t have much to say in the choice of an API implementation, like developers probably shouldn’t get to veto a color scheme. However, during a wireframing session a developer could save a designer from making a disastrous proposal that would cause time for implementation to increase tenfold. Likewise, a designer overlooking implementation of navigation could steer the interaction towards a much more enjoyable experience that better fit the consistency and feel of the app. Use your best judgment but, don’t rob your team of their combined expertise by putting up imagined barriers.
A lot could be written about the iterative nature of development as well, but once again, I will let someone else to write that article.
The real truth that seems to catch many people off guard is that you’re never actually done designing. In most good projects, designers have product ownership from spec to ship. You don’t want design becoming a relay race where you hand off something to another department or group of people where you don’t have a say. Even just listing the individual steps like I’ve done, I run the risk of misleading you, as it can very easily be understood as a progression that runs from A to B. Designing apps, or anything for that matter, is rarely a straight line or a clear succession of stages.
While our tools, as well as our products, have changed a lot over these past years, the underlying process of making apps remains largely the same.
Get an idea
Write it down
Build a prototype
Enter into the dance between design and development until something comes out of it
As you progress down this narrowing funnel of bringing an app through development, you make assumptions. Then, you challenge and revise until some nugget of truth makes it into the next stage (or the next build).
People tend to think about building apps the way they think about building a house. First, you lay the foundation, then the walls come up and the appliances are installed. It seems straightforward. There is a blueprint, a design, and a team building it. This fallacy is the source of much grief in the world of making software. It’s why clients expect you to be able to tell them how much their idea costs to develop. It’s why estimates are almost always wrong, and frankly, why we have so many terrible products. It implies that we know the outcome of the process – that right from the start we’re working in a mostly controlled environment with a clearly defined goal.
But, if the process and the stages outlined above teach us anything, it is that we don’t and we shouldn’t have one. The process is there to help us explore the potential by challenging our assumptions and iteratively execute each step – to bring the best nuggets from the idea into the hands of people.
Rather than building a house, designing apps is probably more like composing a symphony. Each profession a separate instrument. In the beginning, it sounds odd, hollow and out of tune. Slowly, however, as we move through the acts and apply our experience and skill, iteratively it finds its direction and becomes some version of the music described in the original idea.
In this article I use several tools available to subscribing members at applypixels.com231911, including the Wireframe kit24 and the iOS 10 UI kit.25 These are my own tools that I care greatly for, but there are many other design templates out there. Worth mentioning is the free tools on Bjango’s26 site and the ones you can purchase on ui827.
For both wireframing and visual design, I recommend you take a look at Photoshop28 or Sketch29.
How can you be sure you’re moving your design problem in a straight line? That you’re moving directly to a solution? From client to payment, from product to audience?
How certain are you of what the second step in your process is? Or the third? Or how long each will take, or if any should be removed? Are they all useful? Do any need improvement? Is each done with aim and purpose? How often do you fall-forward with momentum, rather than move with reason?
These horribly uncomfortable questions are awkward for one reason:
Most of us carry the dead weight of an undefined process.
If you’re like me, your process is a mix of tools, some picked up when studying, a few from colleagues, maybe one or two from an idol, a few oddities taken too seriously, and some wrapped up in the often stale notion of history and tradition – those “because we’ve always done it that way” steps.
We’re too passive, or ignorant, or foolish, or dismissive, or proud when it comes to our workflow. And that’s where we lose.
Being ignorant of our process is to be ignorant of how long things really take, or where opportunities for improvement, in skill or outcome, are hidden. We can’t provide insightful timelines or adjust our process to suit new projects. In all this we lose control of our intellectual and creative growth, letting too many opportunities slip to become the designers (or developers or writers) we aspire to be.
“Discipline is hard–harder than trustworthiness and skill. We are by nature flawed and inconstant creatures. We are not built for discipline. We are built for novelty and excitement, not for careful attention to detail. Discipline is something we have to work at.”
– Atul Gawande, The Checklist Manifesto
A well-defined process is an ordered list of the tasks that get your work done – each given a timeframe, rating of importance, and your level of skill.
A well-defined process gives you an insight into how your projects take shape. Such footing helps you recognise how each step impacts the final outcome, your relationships with your clients and colleagues, and helps you see if the skills you want to develop are being ignored.
1 An example of what a well-defined process might look like. The details of your own process will vary greatly, depending on your interests and career goals. (Large preview2)
Let’s have a closer look at a few helpful benefits that come from defining your process:
Master Your Time and Schedule
Make Better Decisions with Clarity and Focus
Have More Control to Make More (and Better) Choices
What’s more important to a designer or developer (or pretty much anyone who works with clients, budgets, and timelines) than to use their time well? In this section, you’ll learn how to:
Take advantage of a predictable schedule
Warp time to handle the unexpected
Comfortably separate creative and non-creative work
Easily handle a client’s schedule disruptions and demands
As designers we work to schedules and deadlines. Schedules help us manage our workload, timeline, and especially if freelancing, helps us know how much to charge. But it’s easy to have schedule-creep when we don’t know what our process looks like. I’ve been guilty (far too many times) of giving an overly optimistic progress report or timeframe for projects. Hearing the deadline scream past leaves us looking unprofessional, placing both designer and client in a foul mood.
3 Part of our role is to work to deadlines, but it’s common for designers to rely on memory and gut instinct to get them through their process. (Large preview4)
Knowing how long it takes to complete each step in our a process, and what step we’re up to, allows us to set realistic deadlines. We can also, at any point, tell our clients how much is left to be done and how long it’s likely to take.
The client calls and tells you they’ve stuffed up. They noted the date of their launch wrong and the website you’re designing needs to be finished a month earlier than agreed.
That’s okay. You have a super power. You can warp time.
When you know every step in your process, how long each one takes, and how important individual steps are to the final outcome, you can speed things up.
5 Having a clear guide as to how long each step in your process (should) take, realistically allows you to give some tasks more attention, while knowing that you can race through others. (Large preview6)
Let’s say you were going to design custom icons and draw a custom map. You can adjust these minor steps and speed up the process by using a set of purchased icons, and stick with Google Maps to give people directions. These moves are worth making because it allows you to focus on the more valuable tasks of, say, optimizing the product pages for sale, or the home page for email sign ups.
Knowing each step in your process allows you to calmly adjust them, and their expected outcomes, as needed.
But warping time can do more than save your client from themselves. It can help you produce better work. If you need to spend some extra time learning a new skill or gaining a deeper knowledge about the audience, you should feel comfortable doing so, remembering that the steps you know inside out will allow you to catch up. You will have learned a new skill, addressed the audience more directly, and produced something great for the client – that’s a whole lot of winning!
Comfortably Separate Creative And Non-Creative Work Link
Who’s a fan of paperwork? Or quoting? Or bug hunting?
Creatives projects aren’t solely made of creative tasks. There is always other stuff which is never fun, but is inescapably important.
7 A designer’s process is a mix of the creative and the practical. Knowing when, why, and how long each creative and non-creative task of your process takes, you can rearrange them to better suit your day or week. (Large preview8)
Knowing each step in your process allows you to schedule your days more efficiently. You can schedule your most productive time for your most important work, and leave the autopilot stuff to the after-lunch slump. You can shuffle around your process without much worry because you can trust that every step is going to be ticked off.
Easily Handle Client’s Schedule Disruptions And Demands Link
We all have an order we prefer to work in. First, I want my sketches approved, a couple of weeks later we’ll start talking copy, and then down the road we will figure out the photography.
What if the client’s Brand Coordinator is going away and she’s the one approving the copy and the photography, but doesn’t care about sketches? What if the Coordinator is heading overseas for three months, and when you’d normally be presenting sketches, you need to be thinking about words and photos?
9 Sometimes we rely on nothing but habits to get our work done – habits that a client can easily disrupt and throw us off our game. A defined process allows for easy shuffling without losing momentum. (Large preview10)
Having a process means being able to rearrange on the fly without skipping any steps. You can line up the copywriter and photographer much earlier than you normally would. Once the copy and photos are taken, instead of putting them into a polished design, you can go back to what needs to be done (getting those sketches approved!).
Obviously, if this kind of situation comes up you’ll do what needs to be done, regardless of whether or not you know your process well. But, by having that knowledge, you can shuffle things around without stress and manage your timeline easily.
Any product we produce is the result of a thousand small decisions. Everything from how we communicate with the client to what the product will look like and do, comes down to this-or-that choices. Having a strong understanding of your process will allow you to:
Relax and enjoy the reliability,
Keep your focus and ideas on track,
Build stronger relationships with your clients and
A defined process becomes a roadmap that ensures you visit each step. You will always know how far into the project you truly are or how much is left to do, and can take a more educated stab at how many hours are still needed.
11 We can too easily forget important and necessary steps when we’re in the middle of a whirlwind project. Checking off the steps in a defined process helps us get everything done. (Large preview12)
The worth of this knowledge shines through during conversations with your client and colleagues. You’re able to show them where your time (and their money) has been spent, while also being able to judge how much more time (and, again, their money) might be needed to reach the finish line. We’re always better off approaching the deadline when we know how much work is still left to do.
As creatives, we deliberately keep our eyes open to new ideas and methods. We do so in the hope of finding a more effective way of grabbing the audience’s attention and communicating to them in way that is both clear and interesting.
When we’re planning how to finish a new project, we give ourselves a clear set of ideas. (“I’m going to use this kind of grid system with this typography” or “I’m going to use this JavaScript library to add those features.”) But, when we stumble over a new idea that we’re excited about, we sometimes apply it because it’s new, not because it’s better.
Knowing where each step in our process begins and ends gives us the opportunity to simply ask, “Have I gotten lost?”
13 Our attention can easily wander, but having defined outlines for a project and process means we can explore while ensuring we stay on track. (Large preview14)
Accidental discoveries are a marvelous aspect of creative work and can sometimes yield results we never would have planned for. But, if we want to ensure that we’re hitting the right targets and doing so before we run out of time or money, taking a moment to make sure we’re keeping our focus on the outcome rather than our own curiosity is essential.
Build Stronger Relationships With Your Clients Link
Clients who have been brought along in the design process tend to be a lot easier to work with. Regular contact helps them understand where our time is being spent and what progress has been made.
15 Completed established milestones are natural moments to get in contact with clients, helping to build relationships as well as their trust in our process and professionalism. (Large preview16)
Moments between steps give us a great opportunity to fire off an email or two. Often it will be good news (“We’ve finished the wireframing and it’s going well! That thing we were worried about was easily managed, and we’re now slightly ahead of schedule,”) and it helps the client put more trust in our professionalism.
This comes in handy when things go wrong. Imagine how a client feels when they only get the, “Here’s a proof,” or, “Give me content,” emails, then gets a, “We broke something and will miss the deadline,” email? Imagine how such an email would go over when we’ve been in regular contact and built a relationship that can genuinely handle a bump in the road.
Kill The Steps That Aren’t Carrying Their Weight Link
We can pick from a wide range of tools, methods, and ideas to get our work finished. For each project we do, we choose what will best help us achieve our goals. But sometimes there are steps in our process that exist for no other reason than tradition. This is especially true at bigger or older businesses, or in-house studios. Useful steps which have turned stale can sometimes linger in our process.
17 Tradition, routine, habit, and ‘just because’ often lead to steps that chew up our time without much of a return. (Large preview18)
More often than not, they’re probably harmless, but take up time and energy — the print designer who makes all their font outlines even though their printer’s RIP can handle fonts just fine; the developer who manually converts and compresses images into weaker formats when there are build systems and better formats available.
By keeping track of how long each step takes and its impact on the final product, we can ensure our process is deliberate and lean.
Have More Control To Make More (And Better) Choices Link
Once you know your process well, you can start to make higher-level decisions. These are powerful choices — they seem simple and small, but can have a huge impact on how you manage your time, your professionalism, and how deliberately your set of skills develop. Here we will look at how you can:
All this knowledge allows you to ask the insanely rich question: “Do I even like doing all of these things?”
19 Defined spaces around each of the steps in your process means you can more easily outsource aspects of a project you don’t enjoy doing, or haven’t got the time for. Knowing your process well means you’ll understand exactly what the person you’ve outsourced to will need, as well as what they will have to give you back for things to run smoothly. (Large preview20)
Especially for entrepreneurs and freelancers, there are always going to be boring tasks. As valuable and essential as they may be, they still manage to bore us while constantly sending off reminders of how we could better spend our time.
So why not swap tasks with a colleague? Or outsource the duds? Or even kill them off completely? I’m sure it’s possible for any of us to learn the legal skills to punch out an air-tight contract, but we’d rather hire a lawyer, wouldn’t we? Same goes for accounting work and server (hardware) maintenance.
What about development work? If that’s your weak spot, why not outsource it? Or maybe you love to art direct but hate to do the grunt work of designing a thousand different ads for a thousand different markets? Or maybe you love taking the photos but despise doing the touch ups?
Knowing what the edges around these tasks look like (where they start, where they end, what’s needed for them to work, and what the outcome should be), makes it a lot easier to start justifying outsourcing, so you can focus your effort on what matters.
You know those tasks that you never do, even though you know they’ll improve your skills or business?
Archiving, reviews (of skill, process, client interactions, outcome), follow-up emails (“How did we do?”, “How is the audience responding to the campaign?”, “Have sales improved?”, “What is and isn’t working?”, “Thank you for working with us”), planning follow-up work, uploading samples to Dribbble and Behance, plus a thousand other little I-should-but-never-do tasks can be added to your process.
These are the little things that can make our projects, our relationships, and even our opportunities significantly better. If we embed it into our process as a way of closing a job, we can be sure we will get to them and enjoy the benefits they bring.
21 Rolling those (sometimes) dull but essential tasks into your process will eventually build the habit of making sure they’re done before your project is finished. (Large preview22)
It’s good to see where the deadweight in your process is, but making targeted improvements is better. This is why weighing up the importance and skill of each step is most beneficial.
If setting type seems to take too long, and you rate the importance of it highly but your skills at it low, then it’s probably worth investing some time into deliberately practicing what’s found in The Elements of Typographic Style. Or maybe your HTML/CSS skills are tight, but your jQuery is loose? Great. Time to load up some tutorials or enroll in an online course.
23 Forcing yourself to grade how well you perform each step in your process lets you make targeted improvements to your skillset. (Large preview24)
In the middle of a project, when such reflection doesn’t come with any opportunity to take action, such realisations are useless. Reflecting on your process at the end of your project lets you see which of your skills are weak, and is a great time to plan what you’re going to do to strengthen them. Even a day or two of practice can make the outcome of your next project better.
We can only take charge of things we understand. If you want to steer the direction of your skills and professionalism, then act like the designer you want to be.
You will start to gain this understanding by reflecting on your process. Then, you can do more than simply use your knowledge – you can act with wisdom.
Leaps of skill are easily noticeable in our early careers – every few days we add another tool to our belts. Soon, it’s every few months, and before long we know enough to keep our clients happy, so we plateau.
I’m sure most of us aren’t that way inclined, at least not those of us who take the time to read a few thousand words on something as niched-within-a-niche as improving the process of our design work. If you’re reading this, then clearly you’re one of those designers, and I’m willing to bet that the idea of having a stale and just good enough set of skills eats you up inside.
So, take the smallest of small steps and think about what you do, why you do it, and how well it all really works. Then take joy in figuring out how to do it all better.
We gain peace of mind when we have a clear view of where a project is heading. Even more invigorating is knowing the capacity of our ability, and being able to make improvements where we see fit.
We can work better with clients, provide increasingly more services, deliver better results, and best of all, find genuine enjoyment in how we spend our days. We can produce work that isn’t simply done, but deliberately crafted.
It’s easier to start watching what you’re doing than it is to awkwardly fit your effort into some “ideal” imaginary process.
It can be done in as little as four easy steps:
Watch how you work. Note down each step as you move through them. This isn’t the time to worry about whether you’re doing the right or wrong thing, what can be improved, nor what is best.
Grade the importance and your skill level, so you can see what needs work and what you might be able to get rid of or replace with an automated or outsourced process.
Think of your ideal process. Once you’ve finished your project, write out another list – the way you think you should have worked, grading the importance of each step.
Compare the two lists. Look for where they don’t line up, where you have holes, what doesn’t work, how much time was spent on each task and if it correlates with how important you think each is.
That’s all there is to it.
Try scheduling your time to mimic your ideal process for your next project, focusing on the order of the steps, including those you don’t do often enough, while removing what wastes your time. Then, keep track of how it actually works out, compare your new process to your ideal process, and adjust the schedule for each new project until you hit your mark.
Simply being aware of how you want to work and the realities of how you actually work can be enough to start making changes.
Once you have a well-defined process that’s a realistic view of how you work, start making improvements and doing experiments, one step at a time.
We all have visions and dreams. Whether it’s about our personal lives, our work, or about complex concepts that target issues which are hard to grasp. The important thing is to listen to your ideas, to write them down, and, if they wake strong feelings, to pursue them.
It can be easy to achieve this, yet sometimes it’s not. A nice technique is to start small and take small steps instead of going 100% all-in or do nothing at all. We like to play with new things, we like to try out new technology, and our minds want to explore new paths — let’s do it!
FlyWeb1 is a new experimental Web API that allows web pages to host local web servers for exposing content and services to nearby browsers. It also adds the ability to discover and connect to nearby local web servers to the web browser itself. This might be a bit hard to grasp now, but imagine this in combination with a decentralized service picking the nearest edge server via FlyWeb. You wouldn’t need any complex external CDN solutions that choose the “nearest” edge server via geolocation resolution or similar unreliable technologies anymore. Another use case could be an “off-grid on-the-fly network” with devices that use FlyWeb together with Bluetooth and WiFi chips to find other devices in the vicinity and hereby introduce a whole new area of network reliability. As FlyWeb is a technology experimentally developed by Mozilla, you need to have Firefox Nightly installed to test this out.
Coding a line chart isn’t a big deal anymore thanks to libraries like D3 or Highcharts. But what seems so easy, actually isn’t: there are quite some pitfalls which can distort the results2 and lead to false assumptions about the presented data. Line-smoothing is one of them.
Monica Dinculescu just spent a week traveling Taiwan with a 2G roaming plan and now reminds us that we need to care more about proper lazy font loading8 if we use web fonts to not annoy our users.
Afshin Mehrabani illustrates the impact of Web Workers9 when sorting a 50K array with JavaScript on the main thread or in a background task. Great to see why we should consider using asynchronous worker tasks for complex and non-time-critical operations.
Tobias Tom wrote about doing what you think is right for you12 and why it matters to slowly change your habits and take small steps to reach your goals instead of seeing only black and white.
Kate Lunau from Vice Motherboard wrote an article explaining why the only good future of commuting is no more commuting14. Nice to see the topic of how we can work together without sitting in the same room and still be social and productive being picked up.
Jonathan MacDonald’s article “The Paradox of Life Balance15” targets a social problem we all face: While our connected devices offer great things, they also make us neglect real life and social communication. A great piece on why innovation is important and why it’s equally important to balance our activity and prioritize the non-digital reality.
People research what types of economy our society could transfer to after the current form of capitalism. Recently, I learned about The Venus Project20, a trial balloon for a resource-based economy. As Albert Einstein said decades ago: “We cannot solve our problems with the same thinking we used when we created them.” I’m excited to see this being tested out and curious if other proposals and tests will lead to a transformation of our current economy in the future. Not only we as developers need to play and test in search for better technology and better solutions, but we as human beings need to do this in all areas of our life.
With autumn starting to show its full glory, there is really no reason to stay inside and drink your hot cacao. No, it’s time to go outside and soak up all those warm colors nature has to offer, especially the vibrant golden-yellow leaves that can now be found almost everywhere you look. It’s the season of hazy mornings, and beautiful warm color palettes. In this month’s collection, I’ve gathered a couple of illustrations and photos that express this seasonal feeling.
These collections of cutout items in combination with real ones is so beautiful if done right. Mostly something that is done when there’s animation4 involved as well.
Poster for a conference that discusses the social, environmental, and organizational issues plaguing the fashion industry. Some beautiful gradients in an inspiring organic shape.
Bob Lundberg is an illustrator from Sweden that draws inspiration from objects he comes across in everyday life. The result is a harmonious testimony to design objects.
Concert poster that is part of the design/color system that Scott Hansen has going since the release of his latest album ‘Epoch’. Be sure to read the story23 about the meaning and origin of the artwork of Tycho.
This one is created for a fashion editorial in Marie Claire Italia. It’s part of a series that explores the lives of four sisters, their relationships with each other, and their individuality. The eyes are the attention grabbers, maybe even a little creepy. Wonderful water-color work. Be sure to check out the rest36.
Great to see how the mountain roads have been translated here with all the different structures. The fluo wheels are a nice touch, and also the way the pink is applied everywhere to add this sunset feeling.
You don’t have to be a baseball fan to appreciate everything in here. The typography is so on point. These are also hard colors to pull off just right. Be sure to admire them all.
Sad that summer is over but one comfort is that light is usually very pretty this time of the year. This photo proves it. Just look at this. Quite spectacular imho. It’s just like a painting.
So how does a cozy Sunday look like when it is raining outside. Exactly as illustrated here. Some nice shading going on. The light creating this warm feeling is so perfectly done.
Created as a tribute to mid-century modernism in California for Focus Magazine. Superb style and color usage. Beautiful shadow and highlight at play. You feel the light of the sun.
Admiring the soft colors pencil style in this illustration. Oscar’s illustrations are a reaction to designer and founder of type foundry Letters from Sweden85. Göran Söderström’s typeface called Funkis, which is influenced by the aesthetics from the early years of Scandinavian functionalism.
There are still some lingering thoughts that won’t accept fall. Queue a beautiful summer day with a magical view like you see here. Such a perfect scene with that tiny sail boat in the centre.
This illustration was submitted to Type Hike118, a collaborative design project that includes 60 designers and typographers, all celebrating the National Parks Service centennial in the USA. Love how the yellow touches are applied to create this moonlight effect.
What an inspiring color palette! The texture of the wood is also refreshing. All textures are in fact very well done. Love the disproportion of their bodies too.
Added another one to “the places I want to ride my bicycle” list. My friends are not lying when they say, “It’s not LIKE riding through a painting — it IS riding through a painting — up a very, very steep and twisting painting”.
Speaking of brush strokes, this lovely cover for the Autumn Books section of the Wall Street Journal is also very well executed. Perfect autumn feeling.
It has been a while since I last had a look at the ‘Windows of New York’ project. Time to rectify this with this beauty from 137 Second Avenue in East Village.
New work in the swimming pool series from Maria Svarbova. It’s such an inspiring thing to watch. Brilliant in its simplicity. That red accent is just brilliant.
I love illustrations that tackle the future. It’s such a great way to see imagination at work. Here you have a concept of how an airport terminal of the future could look like. Love the color palette and subtle gradient shades.
9
13
17
20
24
30
35
38
42
46
50
56
