Stockio
A new site with free photos, vectors, icons, fonts and videos for personal and commercial use.
A new site with free photos, vectors, icons, fonts and videos for personal and commercial use.
Not all products are created equal. While we repeatedly buy some products almost mindlessly, for others, we take a lot of time to make a purchasing decision. For a price tag that meets a certain threshold or if we are particularly invested in the quality of a product, we want to be absolutely certain that we are making the right choice and are getting a good product for a good price. That’s where a feature comparison table makes all the difference.
Feature comparison tables are helpful not only in their primary function, though. When designed properly, they can aid in decision-making way beyond placing product specifications side by side. They can also add meaning to an otherwise too technical product specification sheet, explaining why a certain feature is relevant to the customer or how a certain product is better than the others.
After our close examination of accordions1, time and date pickers2 and sliders3, in this article we’ll look into all of the fine details that make a perfect, accessible and helpful feature comparison table. Please note that this article isn’t necessarily about pricing plans, nor is it about data visualization methods. Rather, it’s tailored specifically for the case where a customer wants to confirm their purchasing choice or can’t choose between one of multiple preselected items.
Before diving into design decisions, we need to properly understand the user’s goals, intentions and behavioral patterns.
Many customers visit a website, browse around, add one or more products to their cart and then leave without completing their purchase. We can easily reduce abandonment rates with a couple of simple techniques. Read more →4
In observing customers in a few e-commerce projects, I found it quite revealing to notice how seemingly irrelevant a comparison feature appears to be to many customers. Quite often users will say that it clutters the interface, and that they never use the feature. The reason for it is simple: While we tend to purchase small low-priced items quite often, we tend to buy large high-priced items not so frequently. In fact, there are just not that many situations where we actually need a feature comparison.
Not many customers would even think of comparing a few books or pairs of socks. However, relatively few customers would purchase a coffee machine or refrigerator without exploring their options thoroughly. A feature comparison is indeed irrelevant for “small” purchases, but it becomes important for “large” purchases. In fact, when customers are committed to making a large purchase but can’t choose which product to buy, they are likely to end up not buying altogether, getting locked up in the choice paralysis. As a retailer, we obviously want to avoid these deadlock situations, and that’s where a feature comparison element can be very useful, simplifying the decision-making process and filtering out items that don’t meet relevant criteria.
The latter can apply to very different settings: We could be comparing locations, venues, glasses, cars, luggage, watches, TV sets or even chemicals29. However, for the scope of this article, we’ll be focusing on a very specific feature comparison among e-commerce retailers. The lessons we’ll learn here can be applied to any kind of comparison context, although the fine details might vary.
One way or another, in the end, it all boils down to what kind of purchase the customer is about to make. As Joe Leech states in his brilliant webinar on purchasing decisions30, when shopping online, users have either a “non-considered” or a “considered” purchase in mind.
Non-considered purchases are quick, low-effort purchases that we tend to make when we need a quick solution, or run errands. Whenever we need a pack of batteries, ordinary stationery, a “good-enough” dryer or a quick weekend getaway, what we’re actually doing is checking a box off our to-do list and moving on. Few people get excited about selecting batteries or pencils, and so we are unlikely to explore different websites a few times just to buy that perfect pack. Instead, we tend to purchase such items quickly, often on the go, skimming over vendor reviews and shopping by price, shipping speed and convenience.
Considered purchases, on the other hand, are slow, high-effort purchases, purchases that need time and consideration. When we buy a bicycle, a watch, a refrigerator or health insurance, we explore our options thoroughly, making sure we don’t end up with something that isn’t good enough or that doesn’t fit or that would need to be replaced soon after. In such cases, we tend to keep exploring a possible purchase for quite a long time, often browsing many different retailers, comparing prices, reading reviews and examining pictures. We might even ask the opinion of our friends, colleagues and loved ones. Eventually, a final decision is made based on the expected quality and service, rather than convenience and speed, and it’s not necessarily influenced by price point alone.
Of course, the more expensive an item, the more consideration it requires. But considered purchases aren’t necessarily expensive: Any item with a certain attribute, such as longevity, speed or quality, has to be thoroughly considered as well. This includes gifts, flowers, wine and spirits, clothing, mortgages and health insurance. The reason for it is obvious: it’s very hard to be very disappointed about a pack of batteries, but an uncomfortable gift, or wrong flowers sending a wrong message, or even an ill-fitting shirt that has to be returned, can be quite a frustrating experience.
Not many people know exactly what they want or need up front, unless they receive a trusted recommendation. So, every considered purchase requires a lot of thinking and consideration, comparing different options and filtering for that perfect one. The problem is that comparison isn’t a particularly fun activity on the web. Details are often missing, prices are not transparent (how often do you add an item to the shopping cart and go through the entire checkout up to payment, only to see the real final price?) and model numbers (such as for appliances) are not consistent.
That’s where a well-designed feature comparison can increase sales and improve user satisfaction. If we manage to pick up an indecisive customer in a moment of doubt — before they leave the website or start looking around — and guide them skillfully to a sound decision, then we are striving for a better customer experience, while also accounting for a larger profit and a more loyal customer base for the business. After all, customers don’t have to shop around on other websites when purchasing (often) expensive items. That’s something that might bear fruit for the business for years to come.
At this point, it’s probably no big revelation that feature comparison is relevant mostly for considered purchases. They are particularly useful in cases where a product is relatively complex — potentially including details that might be confusing or ambiguous. Good examples of this are digital cameras and TVs — for an informed comparison of choices, one often needs an understanding of the technical capabilities of these devices. Another example would be a vacation or business trip — anything that requires many small decisions, such as availability, pricing, convenient departure and arrival times, budget, and a thorough planning of activities up front.
What exactly makes a comparison relevant for the customer? Well, it’s relevant if it helps users make a good, informed choice. A feature comparison could be designed to drive more customers towards “high-profit” margin sales, but if they aren’t a good fit or if the customer feels they are overpaying, then the retailer will have to deal with either a high volume of returns or users abandoning them altogether in the long term.
When we observed and interviewed users to find out how a feature comparison might be relevant to them, we found that it essentially boils down to one single thing: seeing the difference between options, or filtering out unnecessary details quickly so that the differences become more obvious. Unfortunately (and surprisingly), many feature comparisons out there aren’t particularly good at that.
If we wanted to compare two or more items against each other to find the better fit, what would be the most obvious way to do that? With clothes, we would try them on and pick the one that feels right. But what if trying things on isn’t an option? When purchasing products online, we can rely on our past experiences, ratings, expert reviews, customer reviews and trustworthy recommendations to reduce the scope of options to just a few candidates.
Still, at some point, you might be left with a few too similar items — maybe one a bit too expensive, the other missing an important quality, and the third a recommendation from a friend’s friend. So, what do you do? You list all options, examine their attributes side by side, and eliminate options until you have a winner. (Well, at least most people do that.)
Translated to common interface patterns, this naturally calls for a structured layout that aids in the quick scanning of options — probably a good ol’ comparison table, with columns for products, and rows for their attributes. Once the user has selected products and prompted the comparison view, we can just extract all attributes from all selected products and list them as rows in the table. Should be easy enough, right? Yes, but that’s not necessarily the best approach for meaningful comparison.
Ideally, we’d love to display only meaningful, comparable attributes that the customer cares about. Rather than extracting and lining up all product specs, we could determine and highlight all relevant product attributes, while keeping all other attributes accessible. This requires us to (1) find out what the user is interested in and (2) have consistent, well-structured data about our products.
While the first requirement is just a matter of framing the question properly in the UI, the second requirement is a tough nut to crack. In practice, having well-structured meta data often turns out to be remarkably difficult, not because of technical or design limitations, but because of content limitations.
Unless a retailer is using a specialized, actively maintained system that gathers, organizes and cleans up meta data about all products in their inventory, getting well-structured, complete and consistent attribute details — at least about products merely in the same category — turns out to be a major undertaking. You can surely manage meta data for a relative small clothing store, but if you as retailer rely on specs coming from third-party vendors, a meaningful comparison will require quite an effort.
This raises a question: How would you display a comparison table for two digital cameras if critical attributes were missing in one of them? In that case, meaningful comparison would be impossible, making it also impossible for the customer to make an informed decision. When faced with such a situation, rather than picking one of the options blindly, most customers will abandon the purchase altogether, because the worry about purchasing a wrong product outweighs the desire for a product at all.
Conrad1263937 lists all products in a table, with every other row alternating in background color. Like in many other retail stores, meta data is often incomplete and inconsistent, leaving users in the dark. In the example above, the number of HDMI inputs, the weight, the highlights and player dimensions aren’t available for two of the three compared products.
The same happens when items are difficult to compare — for instance when noisy ill-formatted data appears next to well-structured data for many attributes. It might be possible to spot the differences between products with enough time investment, but it requires just too much work. In usability sessions, you can see this pattern manifest itself when customers prompt for a comparison view and scan the rows for a second or two, only to abandon the page a few seconds later. Moreover, once they’ve had this experience on the website, they will perceive the feature comparison on the website to be “broken” in general and ignore it altogether in future sessions.
So, what do we do if some information is missing, incomplete or inconsistent? Rather than display the comparison table as is, it would be better to inform the user that comparison isn’t possible because some data about a particular product is missing, and then guide them to relevant pages (perhaps standalone reviews of the compared products) or ask them questions about attributes that are relevant to them, and suggest the “best” option instead.
Comparing by attributes matters, but extracting and reorganizing data from a specification sheet alone might not be particularly useful for a not-so-savvy customer. In fact, it might be helpful to extend or even replace some attributes with data that the user would find more understandable — for example, replacing technical jargon with practical examples from the user’s daily routine? Or extracting advantages and disadvantages of products?
As noted by Nielsen Norman Group42, on Amazon, technical details aren’t displayed as is. Instead, the comparison table translates technical attributes into language that is understandable by the average consumer. Interface copy matters: this goes for attributes as much as for wording on buttons, labels and thumbnails.
For every two compared items, Imaging Resource46 extracts the advantages and disadvantages of the products, as well as the respective strengths and weaknesses, in a list. This might not be the fastest way to compare attributes, but it nicely separates qualities by default, prominently highlighting critical differences between options. The website also provides extracts from reviews and suggests other relevant comparisons.
Versus5352 goes one step further, highlighting how the features of the selected products compare against other products on average in a bar chart. Rather than only displaying all attributes as a table, they are also shown in a list view, with a detailed explanation of each attribute. Even better, the website puts every attribute into context by highlighting how much better the best product in that category is performing. The bonus is that members of the community can upvote every single attribute if they find it relevant. That’s way more helpful for customers than single attribute values in a table.
Cool Blue5554 has a fine feature comparison: Everything is just right. Not only does it display similar and different features prominently by default, it also highlights the pros and cons of each product and the pros and cons of each feature. The interface also granularly breaks down the rating for specific groups of features and customer reviews.
Flipkart5756 provides feature comparison on most category pages and most product pages, with advantages, disadvantages and highlights extracted from reviews. That makes the feature comparison infinitely more relevant, and it might make it slightly easier to jump to a purchasing decision.
More often than not, a detailed spec sheet alone might not be good enough for meaningful comparison. Extending the comparison with further details, such as relevant reviews, helpful rewording, as well as advantages and disadvantages in direct comparison can go a long way in helping the customer make that tough decision.
All of the options above provide a quick, scannable view of advantages and disadvantages, but depending on the complexity of a product, you might end up with 70 to 80 attributes lined up in a list. Going through all of them to find the ones that a customer cares about most would require quite some work.
One way to improve the scannability of attributes would be by grouping attributes in sections and then showing and collapsing them upon a click or tap. That’s where accordion guidelines58 come into play: In too many intefaces only icon acts as a toggle; of course, the entire bar should open or collapse the group of attributes. Additionally, an autocomplete search box or filter could allow customers to either jump to sections or to select and unselect categories for comparison.
Rather than just list all attributes, Home Depot59 groups them into “Dimensions,” “Details” and “Warranty / Certifications.” It also highlights differences between products and has a fancy print view (accessible via a tiny print icon — let’s see if you can find it!).
Sharp6362 allows customers to select a category of interest from a list, or even to use autosuggest to quickly jump to a specific category. A checkbox on the right allows users to highlight the differences, too — although the highlight isn’t always visually clear.
For its feature comparison, Otto6564, a German retail store, not only groups all attributes but also turns each group into collapsible and extendable sections. Some sections additionally contain detailed information about an attribute, provided upon a tap or click.
Garmin6766 goes even further. Rather than just displaying a dropdown at the top of the page, it floats it alongside the products as the user scrolls the page. That’s slightly better.
Rtings.com6968 extends a dropdown with filtering functionality for the entire table. If a customer is interested in a particular group of attributes, they can select the exact values that interest them. That’s a level of granularity that a feature comparison table usually doesn’t provide, and it’s especially useful for lengthy comparison views.
Ultimately, a floating dropdown with a selection of the attribute section would be just enough for any comparison. In general, a slightly better organization of the attributes would help users navigate towards points of interest, but being able to easily see differences or similarities within those points of interest would also be useful.
Because being able to easily see differences is one of the central purposes of a comparison, it makes sense to consider adding a toggle — like in Sharp’s example above — to allow users to switch between seeing only differences, seeing only similarities and seeing all available attributes.
In fact, when users access a comparison table and notice the “show differences” button, they often first scroll down past the entire table just to see how time-consuming the comparison will be, only then returning back to that shiny button, pressing it and exploring the updated view.
In fact, that feature seems to be used quite heavily, and it’s understandable why: Seeing the differences is exactly why customers actually prompt for a comparison view in the first place. That means that the option to highlight differences should be quite prominent. But then how exactly would you design it, and what options would you include, and what would the interaction look like?
On MediaMarkt70, for example, customers can choose to see all attributes or only attributes by which products differ. The button for “showing only differences” is located in the left upper corner, next to product thumbnails. Keeping it closer to the table might make it more difficult to overlook it. The German retail store uses alternate background colors for product rows, but not for headings. Many products have 10 to 15 groups of attributes, and each of them can be shown and collapsed. Also, each product has a link to the full specification sheet.
The problem with highlighting differences is that it’s enough for just one character in one table cell in the row to be slightly different, and the entire row will not disappear — even if all the other columns have the same, identical value. However, rather than just displaying the row as is, it would be infinitely more useful to actually highlight the difference — perhaps collapsing all “same” cells into one and highlighting that one cell that is different.
And then the question comes up: once “showing the differences” is selected, should identical attributes disappear altogether, or should they stay in the table with only different attributes being highlighted? It’s probably a matter of personal preference. If there are 60–80 attributes to compare, we’d probably remove similar rows for easier scanning. If the table is smaller, removing rows might not be necessary.
Electrolux1511507472, for instance, contains a button in the left upper corner, acting as a toggle. The state is indicated with a checkmark which can be on or off. Rows with identical data aren’t removed from the table — instead, differences are highlighted with a light blue background.
BestBuy7877 contains a lot of exact numerical data, such as height “69.88 inches” and “69.9 inches”. Most rows will never be omitted because of such minimal differences, making the comparison a bit more difficult.
BestBuy7877 with “Show only differences”. Grouping attributes and perhaps even repeating the button for every section would be helpful here.
Seeing only differences is useful, but would users also benefit from seeing only similarities? In fact, providing this option is not very common, but there are some good use cases for it. As it turns out, one important scenario is when selected products have too many differences to scan through easily.
Here’s an example. Let’s imagine the customer has selected four digital cameras to compare, with each product having 60–80 attributes. Before embarking on a long journey through dozens of attributes, some customers will attempt to eliminate the options based on “simple” criteria, such as price or release date, “too weak” or “too expensive” or “not up to date” qualities. Obviously, while eliminating those items, they will want to make sure they aren’t removing the wrong ones. In that particualr case, seeing similarities gives users validation that they are “still” looking at products that are “worth comparing” or “worth investing time into.”
The main use case when it happens is when a customer is comparing a few strong, similar candidates. They might vary in a dozen attributes, yet the list of all 80 attributes is too lengthy to easily compare. With an option to see only similarities or only differences, the customer can break down the complexity into two parts. What you notice in such cases is that customers tend to take care of the “easier” task first: they will look into similarities first (just to be sure all options are “solid”), and then look specifically into the differences.
You might be wondering if it’s necessary to provide the overview of all attributes? After all, the customers check both similarities and differences. The answer is “yes.” Customers don’t want to miss out on important details, and because they want to be certain about all available attributes, they will seek and examine the “all attributes” option as well, scanning it at least once during the session.
In terms of design, an obvious solution would be to use a group of mutually exclusive buttons or just one button or link that changes the contents and basically acts as a toggle.
Samsung828079 allows customers not only to see all attributes, only similarities and only differences, but also to select what attributes are relevant and compare only by them, removing everything else. All attributes are grouped into accordions, which all can be expanded or collapsed with one click.
LG8381‘s interface is similar to Samsung828079‘s, but the “compare” links are a bit too small, and because different views remain clickable all the time, it’s not always clear what you are looking at. Also, I’ve still yet to figure out what “locking” an item above the product thumbnails in the comparison view means — it probably means displaying the item first.
In practice, when encountering a feature to switch views, customers tend to alternate between all available options quite a lot. Seeing the differences and all attributes matters the most, but being able to see all similarities, while not necessary, might be reaffirming and supportive.
To highlight differences, we can remove similar or identical rows, but we could also use color-coding to indicate how different the compared items are, and which of them performs better. An obvious way to do this would be to use some kind of colors or patterns on table cells. Zipso84, for instance, colors fragments of each row for each selected attribute. While it’s helpful for a few attributes, when many of them are selected, the presentation quickly becomes too difficult to compare.
Prisjakt9189 uses color-coding of table cells to highlight differences by default. Also, customers can highlight relevant rows by tapping or clicking on them (although, on tap, the differences aren’t clear visually any longer). Every comparison also has a unique, shareable URL.
ProductChart9694 uses background bars to indicate which of the candidates performs better for a certain attribute. The length of the bar indicate how much better one of the options performs. Slightly highlighting the winner, or providing an overall score and suggesting a winner, might be helpful here.
Digital Camera Database100 displays the differences between products with filled colored rectangles, to indicate the dimensions of difference. That’s useful for highly technical and detailed comparisons, but not necessarily so for every kind of feature comparison.
If your feature comparison table is likely to contain a lot of numerical data, it might be useful to highlight both the row and the column upon a tap or click, so that the user always knows they are looking at the right data point.
Color-coding is a simple way to highlight differences, but we also need to provide an accessible alternative, perhaps elaborating on the difference between products in a summary above the table.
You’ve probably been in this situation before. If you have three obscurely labelled products to compare, with over 50 attributes being compared against, you might have a very difficult time remembering exactly which product a column represents. To double-check, you’ll need to scroll all the way back up to the headings, and then scroll back all the way down to continue exploring the attributes.
One obvious way to make mapping less strained is by having sticky column headers, following the customer as they scroll down the comparison table. We don’t necessarily need to keep all of the details in the header, but providing a product model’s name, with its rating and a small thumbnail might be good enough.
Sony106105 keeps product labels and thumbnails floating above the comparison table as the user compares products. This gives customers a very clear mapping between attributes and a product. To compare, a quick look at the header is enough — no extra scrolling necessary!
Indesit108107 solves the same problem in a slightly different way. The interface keeps thumbnails in a floating bar at the bottom of the screen, rather than at the top. As the items are added, they are displayed in the bar at the bottom. To add the items though users need to hit the comparison icon tucked in the upper-right corner of the product — it might not be easy to identify. Ah, also the entire “Compare models” bar should act as a toggle — in the implementation, only the chevron icon triggers expansion and collapsing.
So, if a floating bar is in use, should it float above or below the table — or does it even matter? Keeping headings above the content seems slightly more natural, especially when the thumb is hovering over the contents of the comparison view on narrow screens. Users need to be more careful when scrolling the page on narrow screens — which is why the bar in the Indesit example disappears entirely on mobile. Keeping the bar above the table just seems a bit more reliable.
Obviously, it’s going to be very difficult to display all selected products as columns at all times. A table view works well if you have two to three products to compare, but probably not so well if there are five products in the table. In that case, a common way to conduct the comparison would be by sliding horizontally.
No conversation about tables can omit a close look into their responsive behavior across screens. A discussion of tables deserves a separate post, but there are a few common tricks to keep a table meaningful on narrow screens. Quite often, each table row will become a collapsed card, or headings will jump all over the place, or the table will be restructured to expose the data better, or the user can select which columns they want to see.
Problem solved? Not so fast. The feature comparison table is a beast of a special kind. The main purpose of the element is comparison: Keeping both attribute headings and product headings visible is important — after all, the customer wants to see the products they are comparing and the features they are comparing against. This means that for easy comparison on narrow screens, we need to float product headings, while keeping the attribute column locked as the user scrolls down the page. That doesn’t leave us with a lot of space to display actual product details.
Sadly, almost every other retail website makes feature comparison unavailable on narrow screens. Selected products will often disappear altogether, the comparison feature will be hidden, and loading a shared comparison link will appear to broken. In fact, it proved to be quite a challenge to find even a handful of examples out there.
Some interfaces try to make the best of what they have. Crutchfield110109‘s interface, for example, is responsive, but that doesn’t mean it’s useful. On narrow views, items are displayed in a 2 × 2 grid, and so are product attributes. Because there is no visual relation to the actual product, it makes it very difficult to compare features.
ProductReportCard112111 displays products in sets of three at a time. The attributes of each products are squeezed into a 33% column on narrow screens, making reading quite tiring, and comparison quite difficult.
Urban Ladder114113 allows its customers to shortlist and compare items in the product grid. Once the user hits the “Compare” button, they’re presnted with a quick overview of similar products which are auto-suggested. On narrow screens, users can compare only two items at a time.
One way to manage this problem would be to avoid a table view altogether. Instead, we could highlight similarities and differences in a list by default, allowing customers to switch between these views.
Alternatively, we could ask the user to choose the attributes that they care about most, and once the input is done, we could highlight relevant features, and perhaps even pull some data from reviews, displaying both of them in a list. Every relevant attribute row could become an expanded card, while all less relevant attributes could be displayed as collapsed cards below.
As always, limited space requires a more focused view and since differences are usually what matter the most, highlighting them and removing everything else seems quite reasonable.
Admittedly, with all of these options, we are losing the big-picture view that a table can provide. If you’d like to keep a table, usually you’ll have at most one column to fill in with actual content — as another column has to be reserved for attribute headings. To make it work, you could provide a stepper navigation between products, so that the user is able to switch between products predictably. In the same way, sometimes floating arrows are used left and right, similar to a slider.
OBI116115 allows customers to add as many products as they wish for comparison. In a comparison view, the navigation between products in the table happens via a stepper in the left upper corner. Unfortunately, the feature comparison isn’t available on narrow views.
Alternatively, you could also extend the table with a segmented control or multi-combination selector at the top, allowing users to choose two or more products out of the product comparison list — and display them side by side. With two products, the user would end up with a beautifully readable, responsive comparison table, and with more selected items, they would get either a scrollable area or a summary of differences and similarities. The user could then choose what they’d rather see.
What to choose then? If the feature comparison table contains mostly numerical data, then it might be easier just to explain differences in products up front. If that’s not the case or if the contents of the table is unpredictable, an option with stepper navigation, or a multi-combination selector, might work well. And if the product is complex and so attribute descriptions would be numerous and lengthy, then extracting relevant data and highlighting it, rather than sending the user on a journey through dozens of attributes, might be a better option.
When talking about responsive behavior of components, we tend to focus on “regular” and “narrow” screens, but we could be exploring adjustments for “wide” screens as well. If we do have enough space to display a feature comparison prominently on wide screens, why not make the best use of it? As the user navigates the category page, for example, we could display the feature comparison as a floating pane on the right, while the left area could be dedicated to products highlighted in that category. As the customer adds an item for comparison, it could appear in the side-by-side comparison right away. In his article on “Responsive Upscaling119,” Christian Holst mentions a good number of techniques applicable to e-commerce UX on large screens. They can be quite relevant for feature comparison as well.
What exactly happens before the comparison table appears? The customer will probably land on a category page, selecting a few items to compare, only to discover a button to prompt for the comparison. At this point, the customer might (or might not) know details about some of the selected items. In the same way, the order of selection for comparison might (or might not) be random. When displaying comparison results, a safe bet then is to display columns in the order of selection, because any different order might cause confusion.
As they are in the process of comparing, the customer will (hopefully) start to see things a bit more clearly, filtering out products that are clearly outperformed by selected competitors. To clear up the comparison view, we will allow the customer to remove a product from the comparison, of course, often indicated with an “x” in the upper-right corner of the column (or the floating header).
As it turns out, sometimes users will quickly dismiss one of the options, for example because it’s too expensive anyway, but they would want to keep that option in the comparison view for reference — just to put other candidates in context. That “reference” option might end up being stuck in the middle of the table, getting in the way of the comparison between two or more “real” candidates.
Obviously, the best arrangement for these options would be to display the main candidates first, side by side, followed by the “reference” candidates. In fact, you could even go as far as to allow the customer to downgrade or downvote some candidates and push them a bit to the side, displayed in a less prominent gray color.
A slightly more robust option would be to allow users to drag columns as they wish. That would help in the beginning when the customer has added quite a few items to the list but then, for instance, realized that the price difference was too high and so wanted to rearrange the products. It would also help in the case with “reference” candidates. In fact, in interviews, users sometimes compared product columns with cards or brochures or sticky notes that they could move around to group important ones against less important ones. A digital equivalent of the same experience in a feature comparison table would be draggable columns.
On Digital Photography Review159158121120, for example, users can move selected items left and right. That’s a nice accessible alternative to drag-and-drop.
The nature of SocialCompare123122 requires users to be able to drag columns and rows as they wish. However, moving columns around like cards might be helpful for customers of retail websites as well.
It’s important to note that drag-and-drop is (obviously) not accessible, so screen reader users would need to have access to navigation within the column headings. For example, you could have a select
dropdown or a group of radio buttons as a fallback in that case.
But what if, after a detailed comparison, a customer is dissatisfied with all the options presented in the comparison view? In addition to being able to remove items from the list, it’s important to be able to add relevant items to the comparison view — and “relevant” is important here. In most cases, the “add” button will simply return customers to the category page, where they would be asked to add more items for comparison. Instead, we could suggest products that are likely to fit the bill, perhaps by showing ones similar to the items selected.
On Car Showroom125124, customers can add new items by typing in the model reference and using autosuggest. Also notice that the interface provides navigation within the comparison — comfortable for quick jumps to relevant features.
Because feature comparison is relevant mostly for purchases that take time, the more important the purchase, the more likely the customer is to explore the idea of buying an item over a long period of time. One thing we’ve noticed by observing shoppers is that, every now and again, in a moment of doubt, they will take a screenshot (or a series of screenshots) of the comparison table, and store it “for future reference,” until they’ve made a decision. Well, that’s not the full truth because one of the main reasons for storing that screenshot is to send it over to friends and colleagues who have a better understanding of technical details and to ask for their second opinion.
Indeed, second opinions matter for many people — even from a close friend who isn’t that knowledgeable in whatever category the product belongs to. That precious screenshot will end up wandering through Facebook chats and Skype chats, email attachments and WhatsApp groups. If your data tells you that many of your customers need a second opinion before purchasing items (and that will surely be the case for electronics or appliances), make it possible to “save the comparison for later or share it,” enhanced with friendly and encouraging copy. This means that the every comparison should have a unique URL, featuring all or selected attributes, the expanded and collapsed groups of attributes and the order of products.
It’s no secret that many customers misuse their shopping cart or wish lists to keep a selection of products intact for when they visit the website next time (often shortly afterwards). In the same way, storing the comparison table persistently (perhaps in localStorage or in a Service Worker) for some time is a good idea. In fact, no customer would be pleased if compared products were to disappear after they accidentally closed the tab.
Eventually, once the user visits the page a few days (or weeks) later, you could open a little message bar stating that their recently viewed items and compared items are still available, with an option to “dismiss” it. Should the user choose to explore that comparison, they could do it from the message bar. Should they browse a category and choose other products for comparison, obviously the comparison view should be overwritten with the newly selected products.
Interaction with a feature comparison table might appear to be quite self-explanatory, but many tiny decisions have to be made before the user even gets to see the comparison.
For one, the comparison feature obviously has to be indicated, promoted or featured somehow — but where exactly? There are many options. It could appear on the home page, in the category list or on the product page. It could also be available on the shopping cart page or on search results pages. On most e-commerce websites, the option to compare is visible only on the category page, often for the obvious reason of not distracting the customer from the purchasing funnel. Is it always the best solution, though?
Well, we should ask ourselves first, when would a customer want to compare items in the first place? One common use case is when they are looking at similar options but can’t decide which one to choose. This usually isn’t the case on the home page (too early) or on the shopping cart page (too late), but it definitely is the case on a category page and (often) on the product page.
On top of that, one can spot an interesting behavioral pattern when observing customers navigate category pages. When exploring options for purchase, a good number of users will open every potential product candidate in a separate tab and examine each thoroughly one by one first, closing tabs only if the candidate is clearly not good enough. Now, these customers might find a strong candidate and head straight to the checkout, or (more commonly) they might lean towards a few options.
In the latter case, being able to add items for comparison on a product page would obviously save those annoying roundtrips between product pages and category pages. However, we would save not just clicks or taps — more importantly, we would avoid deadlocks, those situations where a customer is indecisive and can’t proceed to check out, abandoning the purchase altogether. If the customer is undecided about the options, they will definitely end up not checking out; and if they do, you can expect the risk of high refund costs. In a way, feature comparison is an easy, helpful way to keep customers on the website by helping them making the right decision.
Another common use case is when a customer comes to a website with strong options in mind already but is looking for more detailed specifics of each option. In that situation, the customer is likely to search for these products right in the search field, often typing in obscure model numbers that they wrote down in a physical retail store. If the appliance can’t be found using search, some customers will still try to find it on the category page, but if their first attempts don’t bring the expected results, they will abandon the website altogether. Similar to the previous case, here we can guide potential customers by suggesting the products they might have meant and making it easier for them to make a decision. Perhaps we could even provide more competitive price and delivery options than a physical store can. Again, adding the comparison selection right in the search results might be a good option to consider as well.
There is another option, though. We could also highlight feature comparison as part of the global navigation. If you have a very limited range of products, each of them targeting a specific audience, it might be useful to clearly communicate what groups of customers each product is designed for.
For example, Konica Minolta128127 provides a separate feature comparison link in the main navigation. Unfortunately, it’s nothing but a list of all specifications for all products in a side-by-side view. Perhaps explaining the advantages of each product and whom it’s best for would be more helpful. Still, customers can export and print out results for easy scanning and reading.
Vizio130129 prominently integrates feature comparison in the main navigation. All products can be chosen for comparison, but every navigation section also contains a “Compare Sizes / Models” link, which features the entire spectrum of products, all broken down into groups, with filters for choosing the relevant ones. The attributes are broken down in groups, too, and displayed as accordions in a tabular view, while the products always remain visible in a floating bar.
Quite surprisingly, Amazon131 doesn’t display feature comparison as an option on the category page. In fact, it is quite difficult to notice on the product page as well. But rather than allowing customers to select the products they’d like to compare, Amazon allows them to only “Compare with similar products.” Only six attributes are displayed on mobile by default: the product’s title and its thumbnail, the customer rating, the price, shipping info and the retailer. The attributes are disclosed progressively, upon a tap or click.
Don’t get me wrong: of course the main goal of the website isn’t to bring as many people as possible to a comparison view, but rather to bring them to the checkout — with an item that will actually meet their needs. Because a comparison can help avoid deadlock, try enabling “adding to comparison” for product pages, category pages and search results, and then monitor conversion. If you have just a few products in the inventory, clearly labelling and targeting each group of customers might be a better (and simpler) option.
Once we know which pages a feature comparison will appear on, we should ask ourselves how users will actually add items for comparison. This requires us to look very closely into the microscopic details of how the feature is indicated and how the user would interact with it.
While some designers choose to use a link or button with a label (for example, “Add to compare”), others use iconography (a plus sign or a custom “compare” icon) to indicate comparison. A more common option, though, seems to be a good ol’ checkbox with a label. A checkbox naturally communicates that and how an item can be selected and unselected, and with a proper label in place, it conveys the functionality unambiguously.
Now, where would you place that checkbox, you might ask? Frankly, if you look around e-commerce websites, you’ll find it pretty much everywhere — sometimes residing on top above headings, sometimes below thumbnails, sometimes in the bottom-right corner next to reviews, and quite often just above the price, where it’s difficult to miss. Admittedly, we couldn’t spot any significant difference; however, one thing was noticeable: The options with a checkbox seemed to consistently make feature comparison slightly more obvious and easy to find than plain text links.
Once the user has selected an item for comparison, it’s important to confirm the selection — a checkbox does a good job of that, but we could also change the wording (for example, from “Add to compare” to “Remove from comparison”) or change the background color (slightly highlighted) or fade in a label or a flag (“Shortlisted”) or a popover. We also have to indicate the change of state for screen readers.
Every selection should be easy to unselect with one tap as well, without resetting the entire selection. Unfortunately, the latter isn’t that uncommon, as some websites choose to disable the checkbox to prevent double-selection, effectively making it impossible to remove the product from comparison without prompting a comparison view.
Obviously, we also need to place a “compare” button somewhere, so that customers can easily proceed over to the comparison view. Now, that view wouldn’t make sense if there is no or only one item shortlisted for comparison. So, rather than displaying a disabled, grayed-out “comparison” button when there aren’t enough items to compare, we could display it only if there are at least two items in the list — perhaps inlined next to those “Add to compare” checkboxes or links of all of the candidates that the customer has selected.
Sony144, for example, uses the text label “Select to compare” for all products in a category first, and if one item is selected, it changes the checkbox label on that item to “Select two or more to compare.” When one more item is added for comparison, the label changes to “Selected,” with a “Compare now” link appearing inline on all selected products.
In fact, in practice, that “fancy” comparison button is unlikely to be very fancy, otherwise it would fight for attention with the primary buttons, such as “Add to cart.” Therefore, more often than not, it’s a subtle tertiary button that doesn’t fight for attention but is noticeable, close to the comparison checkboxes. Still, we could gently highlight it for a blink of a second with a subtle transition or animation once a new item has been added for comparison.
Wait a second! You might be thinking: well, if the feature comparison is so important, why not display a confirmation in a lightbox, prompting the customer to choose to go straight to the comparison or to continue browsing on the website? Well, the problem with this option is that it massively interrupts the flow. Rather than keeping the focus on the products, it directs the customer’s attention to a confirmation message that has to be responded to with every new added item.
Of course, we don’t know if the customer will add two or four or more items for comparison, but having to get rid of the lightbox to continue browsing products seems excessive and just plain unnecessary. With an inlined “comparison” button, we get the best of both options: Should the user want to continue browsing, they would do so seamlessly. Should they want to compare, they can compare easily as well. And the focus always stays on what matters the most: the products.
However, it’s not the best we can do. One issue we kept noticing in usability sessions is that as customers explore their options and add items for comparison, eventually they are ready to prompt the comparison view, but often can’t find the button to prompt it. In fact, they end up having to refind the products they’ve selected because that’s where “compare now” buttons are located. That’s especially difficult in a paginated category with a long list of scattered products.
We can solve this problem by displaying a semi-transparent comparison overlay at the bottom of the page. The overlay could appear when a customer adds the very first item for comparison and could fade away when the selection is cleared. By dedicating a portion of the screen to comparison, we regain just enough space to subtly confirm the user’s actions and to inform them about their next steps, without interrupting the flow.
Home Depot149148 uses a 60px tall comparison overlay at the bottom to highlight thumbnails of the selected products. The overlay us used to guide users through the selection — for example, by explaining how many items are required for comparison. Customers don’t have to search for the selected items on a category page, but they can unselect options right from the overlay. That’s also where an omnipresent “Compare” button resides.
Electrolux1511507472 displays notifications about selected items in the 75px tall bottom bar. It might be a bit too subtle to understand quickly. Rather than changing the text for “showing the differences” or “displaying all attributes,” it uses a pseudo-checkbox that users can toggle on and off.
Appliances Connection153152 uses a slightly less subtle 40px tall bar at the bottom, with a clear link indicating comparison and access to recently viewed items. The comparison view is sliding from top to bottom, and users can switch to recently viewed items as well.
The design of showing and hiding similar features is slightly off, tucked in the upper-right corner. Also, customers can add “Stock ID or SKU” for comparison — but not many customers will know what that means.
Abcam154 implements the bottom bar slightly differently, as an accordion with items lined up in a vertical list. Unfortunately, once the user is in the comparison mode, it’s impossible to remove items or clear the selection.
Delta157156 displays “Add to compare” only on hover, along with other important details, such as price. Unlike in previous examples, “Add to comparison” prompts an overlay at the top of the screen, where the customer can add more items for comparison.
In fact, overlay seems to be a quite common solution, and in fact, it can be helpful in quite many ways. For instance, if only one item is shortlisted, we could use the space to suggest similar comparable items, or even items that other customers often check out as well (“Suggest similar or better options”).
We could also group similar items and complement a comparison list with a shortlisted selection of products. What’s the difference? Instead of prompting the customer to pick one type of products, then select specific items of that type and compare them, we could enable customers to add products of different kinds, group them in the background and keep them accessible for any time later — not necessarily only for comparison. Think of it as a sort of extended list of favorites, or wishlist, with each selection getting a label and perhaps even a shareable URL.
Digital Photography Review159158121120 does just that. The user can “mark” any item for shortlist and then compare items in a particular category later. That’s a good example of resilient, forgiving design: Even if a customer selects batteries and laptops for comparison, they would never appear in a side-by-side comparison because they would be grouped separately. Each item can be removed individually, or the customer can remove an entire group, too.
While slightly more complex to implement, that’s pretty much an absolute solutions that seems to be working fairly well. Alternatively, just having a “comparison” bar docked at the bottom of the page is surely a reliable solution as well.
While some interfaces are very restrictive, allowing exactly 2 items to be compared at a time, it’s more common to allow up to 4–5 items for comparison — usually because of space limitations in the comparison view. Admittedly, the comparison becomes very complex with more than 5 items in the list, with columns getting hidden and “showing differences” getting less useful. But what if the customer chooses to compare more items after all?
Well, not many customers are likely to do that, except for one specific exception. Some customers tend to misuse the shopping cart and feature comparison as wishlist, “saving items for later” as reference. If they choose to save a large number of items, we could of course let them navigate through products using a stepper, but perhaps by default we could reshape the table and extract highlights, advantages and disadvantages instead. That might be slightly less annoying than being disallowed to add an item for comparison altogether.
Eventually, after tapping on those checkboxes or links, the customer hopefully will choose to see a comparison of the shortlisted options side by side. This comparison is usually a short-lived species: It’s used as long as it serves its purpose, potentially getting shared with friends and colleagues, only to disappear into oblivion a short while after. Now, the comparison could appear in different ways:
What’s best? In most situations, the second option might be difficult to pull off meaningfully, just because of the amount of space that a feature comparison needs to enable quick comparison of attributes. Both the first and the third options are usually easier to implement, but the first one might appear slightly faster because no navigation between pages is involved. However, it will also require proper implementation of the URL change based on the state of the comparison. With a standalone page, this problem would be slightly easier to solve. As an alternative, you could suggest to “save the comparison” and generate a link that can be shared.
The fourth option depends on your stake in the never-ending discussion of whether links should be opened in new tabs163 by default. That’s probably a matter of preference, but usually we must have a very good reason to open a window in addition to the existing one. While it might make sense for PDF files or any pages that might cause a loss of inputted data, it might not be critical enough for a comparison view.
Ideally, you could provide both options — the link could lead directly to the comparison view in the same tab, and a Wikipedia-like external-link icon could be used to indicate a view to be opened in a separate tab.
In the end, we just want to help users find relevant comparable attributes quickly. What better way to find them than by first asking the user to select the attributes that matter most to them?
For instance, we could extract some of those attributes automatically by looking into the qualities that appear in reviews for selected products, and suggest them in a small panel above the side-by-side comparison — pretty much like tags that the user can confirm or add.
Once the relevant attributes are defined, we could calculate the match score for all selected products (based on reviews and specifications), and if their average is way below expectations, suggest alternative products with a higher score instead.
The option with the highest score could be suggested as the “recommended purchase” or as the winner, with the percentage of customers who have ended up buying that product in the category and maybe even scores from external professional reviews. There, we could show options to purchase the item or pick it up in a store nearby more prominently. To round up, we could even complement the comparison with a lovely “battle” loading indicator to convey that we are “working hard” to find the best option.
Top Ten Reviews165164 manages to display 10 products in a side-by-side comparison. Each product has a rating broken down by specific groups of features, but also an overall score. The winner is highlighted with a “Gold Award,” and on narrow screens its column is fixed, while other products are compared against it. That’s a slightly more opinionated design, but perhaps it’s also slightly easier to detect the winning candidate from the user’s perspective.
When looking into comparisons, we naturally think about feature comparison tables, but perhaps a filtered view or a visual view would be a better option for comparisons — especially for complex ones. Product Chart167166, for example, uses a matrix presentation of products, with price mapped against screen size for monitors. Features and attributes can be adjusted as filters on the left, and the fewer the candidates, the larger the thumbnails. That’s not an option for every website, but it’s interesting to see a comparison outside the scope of a tabular layout.
Feature comparison can, but doesn’t have to be a complex task for customers. We could take care some of the heavy lifting by suggesting better options based on customer’s preferences. Unfortunately, I’m yet to find any example of this concept in a real eCommerce interface.
But what if we drop the idea of having a dedicated feature comparison altogether — and use a slightly more integrated approach instead? Customer’s experiences reflected in reviews are often more valuable than product specs, so what if we let customers explore suggestions based on keywords extracted from reviews?
In his article on UX Breakdown of Customer Reviews168, Raviteja Govindaraju suggested a couple of options of how it could look.
A product page could display extracted review keywords upon tap or click. On a category page, a product comparison would extend “common” filters with sorting by these keywords. Finally, instead of a feature comparison table, the customer could select the features they care about most and the overview would provide a list of “best” options for them.
In the same way, if a customer is looking for a set of products rather than just one standalone product, we could provide “recommended” options in a contextual preview176. Based on measurements of an apartment, for example, we could suggest electronics and furniture that might work well. The feature might be particularly useful for the fashion industry as well.
These solutions basically provide a slightly extended filtering option, but it shows how a feature comparison can go beyond a “traditional” side-by-side comparison. The better and smarter the filtering options, the less critical a side-by-side feature comparison could be.
While many of us180 would consider the table
element to mark up a comparison table, in accessibility terms, sometimes that might not be the best idea. The comparison could be just an unordered list (li
) with headings — for instance, an h2
for the title of each product and h3
subheadings for the features of each product. Screen readers provide shortcuts for navigating between list items and headings, making it easier to jump back and forth to compare.
That way, we could basically create cards, collapsed or not by default, and then progressively enhance the list towards a tabular view for easier visual scanning. Highlghting differences would then mean just rearranging cards based on customer’s preferences. Still, with labels and headings, a table might be a good option as well.
As Léonie Watson181, an accessibility engineer and W3C Web Platform WG co-chair, put it, “casting your eyes between two data sources is relatively easy to do, but a screen reader doesn’t have any really good way to emulate that behavior”. According to Léonie, “if there is a single comparison table (where the data to be compared is in different columns/rows), then the most important thing is that the table has proper markup. Without properly marked up row/column headers, it is hard to understand the context for the data in an individual table cell.
Screen readers have keys for moving up/down through columns, and left/right through rows. When a screen reader moves focus left/right into a table cell, the column header is automatically announced before the content of the cell. Similarly, when screen reader focus moves up/down into a cell, the row header is announced before the cell content.
If the data sources for comparison are in different places/tables, then things get a bit harder. You have to remember the data from one source long enough to be able to navigate to the data source for comparison, and frankly that’s a cognitive burden most people will struggle with.
A more general purpose solution is to offer customers choices of how the data is presented — for example, to choose to view all data in a single table, or to select certain objects for comparison.”
Phew! That was quite a journey. Below you’ll find all of the design considerations one has to keep in mind when designing a feature comparison table. You thought it was easy? Think again.
Now, below is a list of features that a good comparison is likely to have. We covered most of them in the beginning of this article, but they are worth having in one place after all:
And here are the questions the team will have to consider when designing and implementing a comparison table.
This article is a part of the new ongoing series about design patterns here, on your truly Smashing Magazine. We’ll be publishing an article in this series every two–three weeks. Don’t miss the next one, on builders and configurators. Ah, interested in a (printed) book covering all of the patterns, including the one above? Let us know in the comments, too — perhaps we can look into combining all of these patterns into one single book and publish it on Smashing Magazine. Keep rockin’!
Huge thanks to Heydon Pickering, Léonie Watson, Simon Minter, Penny Kirby, Marta Moskwa, Sumit Paul for providing feedback for this article before publication.
(al, yk, il)
Recently, I was leading a training session for one of our clients on best practices for implementing designs using HTML and CSS. Part of our time included a discussion of processes such as style-guide-driven development1, approaches such as OOCSS242 and SMACSS, and modular design. Near the end of the last day, someone asked, “But how will we know if we’ve done it right?”
At first, I was confused. I had just spent hours telling them everything they need to “do it right.” But after thinking about it, I realized the question was rooted in a deeper need to guide and evaluate what is often a set of subjective choices — choices that are sometimes made by a lot of different people at different times. Stuff like consistent naming conventions and live style guides are the end result, but these “best practices” are rooted in a deeper set of values that aren’t always explicit. For example, specific advice like “Minimize the number of classes with which another class collaborates3” isn’t as helpful without a broader appreciation for modularity.
I realized that in order to really know whether our work is any good, we need a higher level of principles that can be used as a measuring stick for implementing design. We need something that is removed from a specific language like CSS or an opinionated way of writing it. Much like the universal principles of design4 or Nielsen’s usability heuristics5, we need something to guide the way we implement design without telling us exactly how to do it. To bridge this gap, I’ve compiled nine principles of design implementation.
By using just a couple of CSS tricks, less than 0.5 KB of JavaScript and, importantly, some static HTML, Heydon Pickering introduces an experimental solution for progressively enhanced single-page applications. Read more →6
This is not a checklist. Instead, it is a set of broad guidelines meant to preserve an underlying value. It can be used as a guide for someone working on implementation or as a tool to evaluate an existing project. So, whether you’re reviewing code, auditing CSS or interviewing candidates for a role on your team, these principles should provide a structure that transcends specific techniques and results in a common approach to implementing design.
To make it easier to follow along and see how each principle applies to a project, we’ll use a design mockup from one of my projects as the basis for this article. It’s a special landing page promoting daily deals on an existing e-commerce website. While some of the styles will be inherited from the existing website, it’s important to note that the majority of these elements are brand new. Our goal is to take this static image and turn it into HTML and CSS using these principles.
The document is written semantically and logically, with or without styles.
The principle here is that the content of our document (HTML) has meaning even without presentational styles (CSS). Of course, that means we’re using properly ordered heading levels and unordered lists — but also using meaningful containers such as <header>
and <article>
. We shouldn’t skip out on using things such as ARIA labels, alt
attributes and any other things we might need for accessibility.
It might not seem like a big deal, but it does matter whether you use an anchor tag or a button9 — even if they’re visually identical — because they communicate different meanings and provide different interactions. Semantic markup communicates that meaning to search engines and assistive technologies and even makes it easier to repurpose our work on other devices. It makes our projects more future-proof.
Creating a well-structured document means learning to write semantic HTML10, familiarizing yourself with W3C standards11 and even some best practices12 from other experts, and taking the time to make your code accessible. The simplest test is to look at your HTML in a browser with no styles:
One of the best things you can do to ensure a structured document is to start with the HTML. Before you think about the visual styles, write out the plain HTML for how the document should be structured and what each part means. Avoid div
s and think about what an appropriate wrapping tag would be. Just this basic step will go a long way toward helping you to create an appropriate structure.
<section> <header> <h2>Daily Deals</h2> <strong>Sort</strong> <span></span> <ul> <li><a href="#">by ending time</a></li> <li><a href="#">by price</a></li> <li><a href="#">by popularity</a></li> </ul> <hr /> </header> <ul> <li aria-labelledby="prod7364536"> <a href="#"> <img src="prod7364536.jpg" alt="12 Night Therapy Euro Box Top Spring" /> <small>Ends in 9:42:57</small> <h3>12" Night Therapy Euro Box Top Spring</h3> <strong>$199.99</strong> <small>List $299</small> <span>10 Left</span> </a> </li> </ul> </section>
Starting with HTML only and thinking through the meaning of each element results in a more structured document. Above, you can see I’ve created the entire markup without using a single div
.
The least amount of markup and assets are used to achieve the design.
We have to think through our code to make sure it’s concise and doesn’t contain unnecessary markup or styles. It’s common for me to review code that has div
s within div
s within div
s using framework-specific class names just to achieve a block-level element that’s aligned to the right. Often, an overuse of HTML is the result of not understanding CSS or the underlying framework.
div
itis. Think about what the markup needs to be, not what the framework can do to achieve the desired design. (View large version14)In addition to the markup and CSS, we might need other external assets, such as icons, web fonts and images. There are a lot of great methods and opinions about the best ways to implement these assets, from custom icon fonts to base64 embeds to external SVGs. Every project is different, but if you’ve got a 500-pixel PNG for a single icon on a button, chances are you’re not being intentional about efficiency.
When evaluating a project for efficiency, there are two important questions to ask:
Efficiency in implementation also overlaps with the following principles on standardization and modularity, because one way of being efficient is to implement designs using set standards and to make them reusable. Creating a mixin for a common box shadow is efficient, while also creating a standard that is modular.
Rules for common values are stored and used liberally.
Creating standards for a website or app is usually about establishing the rules that govern things like the size of each heading level, a common gutter width and the style for each button type. In plain CSS, you’d have to maintain these rules in an external style guide and remember to apply them correctly, but using a preprocessor such as LESS or Sass is best, so that you can store them in variables and mixins. The main takeaway here is to value standards over pixel-perfect designs.
So, when I get a design mockup with a gutter width of 22 pixels, instead of the 15 pixels we’re using elsewhere, I’m going to assume that such precision is not worth it and instead will use the standard 15-pixel gutter. Taken a step further, all of the spacing between elements will use this standard in multiples. An extra wide space is going to be $gutter-width * 2
(equalling 30 pixels), rather than a hardcoded value. In this way, the entire app has a consistent, aligned feel.
.product-cards { li { display: inline-block; padding: @gutter-width/4; color: @text-color; text-decoration: none; background-color: @color-white; .border; margin-bottom: @gutter-width/2; margin-right: @gutter-width/2; } } .product-status { font-size: @font-size-small; color: @grey-darker; font-weight: @font-weight-bold; margin-bottom: @gutter-width/4; }
Because we’re using standardized values derived from LESS variables or mixins, our CSS doesn’t have any numerical values of its own. Everything is inherited from a centralized value.
To check for standardization, review the CSS and look for any hardcoded unit: pixels, HEX colors, ems or pretty much any numerical value.
As often as possible, I use standard values and create new ones only as an exception. If you find yourself adjusting an element 5 pixels here and 1 pixel there, chances are your standards are being compromised.
In my experience, the majority of preprocessed CSS should use centralized variables and mixins, and you should see almost no numeric, pixel or HEX values in individual components. Occasionally, adding a few pixels to adjust the position of an individual component might be appropriate — but even those cases should be rare and cause you to double-check your standards.
Base elements are separated from a specific context and form a core framework.
I originally called this principle “frameworked” because, in addition to creating the one specific project you’re working on now, you should also be working toward a design system that can be used beyond the original context. This principle is about identifying larger common elements that need to be used throughout the entire project or in future projects. This starts as broad as typography and form field inputs and all the way up to different navigation designs. Think of it this way: If your CSS were going to be open-sourced as a framework, like Bootstrap or Foundation, how would you separate the design elements? How would you style them differently? Even if you’re already using Bootstrap, chances are that your project has base elements that Bootstrap doesn’t provide, and those also need to be available in your project’s design system.
The key here is to think of each element in more generic terms, rather than in the specific context of your project. When you look at a particular element, break it into parts, and give each part overall styles that that element would have regardless of the specific implementation you’re working with now. The most common elements are typography (heading styles, line height, sizes and fonts), form elements and buttons. But other elements should be “frameworked” too, like the callout tag or any special price formatting that might have been designed for our Daily Deals but would also be useful elsewhere.
When checking your project for abstraction, ask:
Thinking through a more general implementation of each element is key. These pieces should be stored as completely separate and independent classes or, better yet, as separate LESS or Sass files that can be compiled with the final CSS.
This principle is easier in a web component19 or module app architecture because the widgets are probably already separated in this way. But it has as many implications for our thinking as anything else. We should always be abstracting our work from the context it was derived from to be sure we’re creating something flexible.
Common elements are logically broken into reusable parts.
Overlapping with the “Abstracted” principle, making our designs modular is an important part of establishing a concrete design system that is easy to work with and maintain. There is a fine line between the two, but the difference is important in principle. The nuance is that, while global base elements need to be abstracted from their context, individual items in context also need to be reusable and to maintain independent styles. Modules may be unique to our app and not something we need available in the entire framework — but they still need to be reusable so that we aren’t duplicating code every time we use that module.
For example, if you’re implementing the product card list from the previous example for a Daily Deals landing page, instead of making the HTML and CSS specific to Daily Deals, with class names like daily-deal-product
, instead create a more general product-cards
class that includes all of the abstracted classes yet could also be reused outside of the Daily Deals page. This would probably result in three separate places where your component gets its styles:
daily-deal
component (and any children) containing styles or customizations specific to Daily Deals. For many, this will be an actual JavaScript web component, but it could just be a parent template that includes the HTML necessary to render the entire design.Of course, you can take this too far, so you’ll have to exercise judgement. But for the most part, everything you create should be as reusable as possible, without overcomplicating long-term maintenance.
Customizations to base elements are available through optional parameters.
Part of building a design system is about thinking through options that the project might need now or in the future. It’s not enough to implement the design only as prescribed. We also have to consider what parts might be optional, turned on or off through a different configuration.
For example, the callout flags in our design show only three variations of color, all pointing to the left. Rather than create three separate classes, we’ll create a default class and add additional class names as the optional parameters. Beyond that, I think someone might come along and want to point the flag right for a different context. In fact, using our default brand colors for these callouts is also useful, even though the design doesn’t specifically call for it. We’d write the CSS specifically to account for this, including both left and right as options.
While you’re thinking through a particular design element, think about the options that might be valuable. An important part of understanding this is thinking critically about other contexts in which this element might be reused.
Using a methodology such as BEM, OOCSS242 or SMACSS to organize your CSS and establish naming conventions can help you make these decisions. Working through these use cases is a big part of building a configurable design system.
The code is easily extended and anticipates enhancements in the future.
In the same spirit as the principle of “Configurable,” our implementation also has to expect changes in the future. While building in optional parameters is useful, we can’t anticipate everything that our project will need. Therefore, it’s important to also consider how the code we’re writing will affect future changes and intentionally organize it so that it’s easy to enhance.
Building scalable CSS usually requires me to use more advanced features of LESS and Sass to write mixins and functions. Because all of our call out flags are the same except for the colors, we can create a single LESS mixin that will generate the CSS for each call out without the need to duplicate code for each variation. The code is designed to scale and is simple to update in one place.
@angle: 170; .callout { &.qty-left { .callout-generator(@color-deals, @color-white, @angle); } &.qty-sold { .callout-generator(@color-white, @color-deals, @angle, 2px solid @color-deals); } &.qty-out { .callout-generator(@color-grey, darken(@color-grey, 10%), @angle); } }
To make the callouts scalable, we’ll create a LESS mixin named .callout-generator
that accepts values for such things as the background color, text color, angle of the point and border.
.review-flag { .callout-generator(@color-brand, @color-white, 75); }
In the future, when a new requirement calls for a similar design pattern, generating a new style will be easy.
To create a scalable design system, learn to anticipate the changes that are common in projects, and apply that understanding to make sure the code you write is ready for those changes. Common solutions include using variables and mixins, as well as storing values in arrays and looping through them. Ask yourself:
All elements are described for others to use and extend.
Documenting design is undervalued and is often the first corner to be cut in a project. But creating a record of your work is more than about just helping the next person figure out what you intended — it’s actually a great way to get all of your stakeholders onboard with the entire design system, so that you’re not reinventing the wheel everytime. Your documentation should be a reference for everyone on the team, from developers to executives.
The best way to document your work is to create a live style guide, one that is generated directly from the comments in your code. We use an approach called style-guide-driven development, along with DocumentCSS29, which pays for itself in dividends. But even if your project can’t have a live style guide, creating one manually in HTML or even a print-formatted PDF is fine. The principle to remember is that everything we do must be documented.
To document your design system, write instructions to help someone else understand how the design has been implemented and what they need to do to recreate it themselves. This information might include the specific design thinking behind an element, code samples or a demo of the element in action.
The final output is an appropriate representation of the intended design.
Finally, we can’t forget that what we create has to look just as great as the original design concept it’s intended to reflect. No one is going to appreciate a design system if it doesn’t meet their expectations for visual appeal. It’s important to emphasize that the result can only be an appropriate representation of the design and will not be pixel-perfect. I’m not fond of the phrase “pixel-perfect” because to suggest that an implementation has to be exactly like the mockup, pixel for pixel, is to forget any constraints and to devalue standardization (never mind that every browser renders CSS a little differently). Complicating accuracy is the fact that static designs for responsive applications rarely account for every possible device size. The point is that a certain degree of flexibility is required.
You’ll have to decide how much of an appropriate representation is needed for your project, but make sure that it meets the expectations of the people you’re working with. In our projects, I’ll review major deviations from pixel-perfection with the client, just to be sure we’re on the same page. “The designs show a default blue button style with a border, but our standard button color is slightly different and has no border, so we opted for that instead.” Setting expectations is the most important step here.
The goal of these nine principles is to provide a guide for implementing design in HTML and CSS. It is not a set of rules or prescriptive advice as much as it is a way of thinking about your work so that you can optimize for the best balance between great design and great code. It’s important to give yourself a certain amount of flexibility in applying these principles. You won’t be able to achieve perfection with each one every time. They are ideals. There are always other distractions, principles, and priorities that prevent us from doing our best work. Still, the principles should be something to always strive for, to constantly be checking yourself against, and to aggressively pursue as you take your design from the drawing board to the final medium in which it will be experienced. I hope they will help you to create better products and build design systems that will last for many years.
I’d love to hear from you about your experience in implementing design. Post a comment and share any advice or other principles you might be using in your own work.
(rb, vf, al, il)
John-David Dalton announces the release of standard/esm, an opt-in, spec-compliant, ECMAScript (ES) module loader that enables a smooth transition between Node and ES module formats with near built-in performance.
Editor’s Note:This article is targeted at readers experienced in using Google Analytics. If you’re new to Analytics, the following guide might be challenging.
Many websites use internal advertising in the form of banners or personalized product recommendations to bring additional products and services to the attention of visitors and to increase conversions and leads.
Naturally, the performance and effectiveness of internal marketing campaigns should be assessed, too, as this is one of the most powerful instruments for generating more leads, more conversions and more revenue on your website. In many cases, web analysts use Google Analytics’ UTM campaign parameters3 to track internal advertising.
For those of you who are not familiar with UTM parameters, this is what an internal link could look like if you add UTM parameters:
www.yourdomain.tld/superproduct.htm?utm_source=internal&utm_medium=internal-ads&utm_campaign=cross-selling
The problem: UTM parameters are intended to be used in external campaigns (for example, promoted posts on Facebook). Unfortunately, they are not suitable for tracking internal campaigns. In this article, I’ll explain why you would corrupt your Google Analytics data when using UTM parameters for internal tracking purposes.
The solution: I have developed a set of URL parameters (called ITM parameters) that make tracking internal marketing just as simple and convenient as the familiar UTM parameters. Set-up takes a little time, but then you’d have a means of tracking internal marketing that both is easy to use and delivers accurate data. This article presents the solution and includes a precise description of all the necessary steps.
Did you know that CSS can be used for collecting statistics? Indeed, there’s even a CSS-only approach for tracking UI interactions using Google Analytics. Read more →4
Well, yes and no. There’s no technical problem with using UTM parameters for internal links as well. However, in the context of web analytics, it is definitely not advisable! As soon as a visitor clicks on an internal link with UTM parameters, their current session in Google Analytics is ended and a new session is started with the source
and medium
information from the UTM parameters. This has disagreeable consequences for your data in Google Analytics:
source
and medium
information from the UTM parameters, which makes it more difficult to quantify the contribution of various external traffic sources to your conversions.source
and medium
information from the UTM parameters. (View large version8)Naturally, you want to avoid these negative consequences, because they reduce the quality of your website’s analytics.
Nevertheless, the use of UTM parameters to track banners ads and product recommendations is widespread. For one thing, many web analysts are unaware of the problem described above. But the deciding factor is something else: The UTM parameters are easy to use, very flexible and accessible, even for the less technically adept among us, which is why they are so often misused for internal campaigns.
In my blog post “Tracking Teasers and Internal Links in Google Analytics9” (in German only, unfortunately), I’ve already covered how clicks on internal banner ads can be monitored and evaluated using event tracking or enhanced e-commerce tracking.
In practice, I’ve discovered that setting up tracking is too much for many people and/or they don’t follow through with it systematically. As a result, they fall back on using the UTM parameters for internal purposes.
So, I asked myself the following question: If the UTM parameters are so popular, can I find a way to track and evaluate internal marketing campaigns using URL parameters?
The answer is yes, it is possible!
Not with UTM parameters, because the type of evaluation you can do with these is predetermined in Google Analytics. What we can do, however, is define a new set of URL parameters that we then use to track internal marketing campaigns.
I call these parameters simply ITM parameters. Instead of using utm_source
, utm_medium
and so on, you would now use the parameters itm_source
, itm_medium
and so on for tracking your internal advertising. I consciously took the names of the UTM parameters, so that existing URLs can be easily modified with “find and replace.”
OK, let’s get started. I’ll show you how to use Google Tag Manager and Google Analytics to create a set of URL parameters for tracking internal marketing campaigns and for analyses.
Drawing on the UTM parameters, we’ll use the following ITM parameters to track internal marketing campaigns:
itm_source
itm_medium
itm_campaign
itm_content
text_link
or banner_468x60
.itm_term
A URL that uses all five ITM parameters might look something like this:
http://www.mydomain.tld/superproduct.htm?itm_source=mydomain.tld&itm_medium=banner_ad&itm_campaign=sale-2017&itm_content=banner_468x60&itm_term=special_offers
Now we have to make sure that the information we are collecting with the ITM parameters is passed to Google Analytics and available for analysis.
Note: To analyze ITM parameters in Google Analytics, we need to create customs reports. In this article, I’ll show you how to create these reports, but I’ve uploaded them to Google Analytics’ Solutions Gallery, too! You’re free to download the reports here10 and here11.
All of the information that we collect with the ITM parameters should be saved in Google Analytics. To this end, we’ll create custom dimensions in Google Analytics. Here, we have to consider their scope: Should we create the new dimensions at the session or hit level?
Let’s go back to the UTM parameters for a moment. The UTM parameters are session-level parameters — that is, the information regarding source, medium, campaign and so on applies to the entire session. What this means for internal campaign tracking is that only the information regarding the last link clicked is captured with UTM parameters.
However, if we want to measure the influence of internal ads on conversion rates, then we would be interested in all of the clicks on internal banners, not just the last one. For this reason, it is advisable to create the new dimensions in Google Analytics at the hit level (for example, pageviews) in order to record the individual clicks on banner ads accurately.
The catch is that session-based and hit-based dimensions can only be combined in custom reports in exceptional cases. That means that we can’t combine conversions (session level) with individual clicks on banners (hit level), and it means that an internal promotion report, like the one we know from enhanced ecommerce, is not available as a custom report.
So, how do we solve this problem?
It’s up to you which method to use. If you capture the information from the ITM parameters on a session basis, it will be easier to manage the reports in Google Analytics, but the data will be less precise. If you go with the second variant, you will capture very accurate click data for internal banners but will have to invest more time to link this data to your conversions.
Alternatively, you could employ both methods in parallel by creating two custom dimensions for each ITM parameter in Google Analytics: one at the session level, the other at the hit level. Then, you will be free to decide how you want to analyze the data. The disadvantage of this solution is that you need 10 custom dimensions in Analytics to implement it, rather than 5. This might be a critical point, since the free version of Analytics allows a maximum of 20 custom dimensions.
In the following step, we’ll create two sets of dimension: one at the hit level and one at the session level. If you’ve already decided whether to count clicks on internal ads in sessions only or as hits only, then you’ll only need to create the one set that you require.
Click on “Admin” in Google Analytics. Select “Custom Dimensions” under “Custom Definitions” in the “Property” area.
Now click on “+ New Custom Dimension”:
itm_source_h
. The _h
at the end of the name indicates the scope “Hit.”Repeat these steps for the dimensions itm_medium_h
, itm_campaign_h
, itm_content_h
and itm_term_h
.
When you’re done, you should have five new dimensions at the hit level in Google Analytics:
Repeat the steps again for the second set of dimensions (at the session level):
itm_source_s
. The _s
at the end of the name indicates the scope “Session.”Repeat these steps for the dimensions itm_medium_s
, itm_campaign_s
, itm_content_s
and itm_term_s
.
Now, you should have five new dimensions at the session level as well:
When you add the ITM parameters to your URLs, these enhanced URLs will also be displayed in Google Analytics (for example, in the content reports). In this case, you would see the same page twice: once with the additional ITM parameters and once without. We want to prevent this, because the content of the pages with and without ITM parameters would be identical. Thankfully, Google Analytics provides a simple means of excluding query parameters.
First, select your “Property” in the “Admin” view, and then the desired “data view.” Under the “View Settings” menu item, you’ll find the section “Exclude URL Query Parameters”:
Enter the ITM parameters that are to be used for tracking in the field provided: itm_source
, itm_medium
, itm_campaign
, itm_content
, itm_term
.
Then, just save the changes, and we’re done here.
Remember that the Google Bot will also find your URLs with the ITM parameters. This could mean that these URLs will also land in Google’s index and cause duplicate content. We can prevent duplicates from arising with a minor tweak in Google Search Console. Select “URL Parameters” from the “Crawl” section in Search Console:
Now click on the “Add Parameter” button to let Google know that the ITM parameter doesn’t affect the page’s content:
itm_source
in the “Parameter” field.Repeat these steps for the parameters itm_medium
, itm_campaign
, itm_content
and itm_term
as well. When you’re finished, all of the ITM parameters should be configured as follows:
Now that we have laid the groundwork, we finally come to the point that probably interests you the most: How will the ITM parameters be read with Google Tag Manager and be passed to the custom dimensions in Google Analytics?
This is surprisingly easy. All we need to do is store the content of the ITM parameters in user-defined variables and then send them to Google Analytics with the pageview
tag. That’s it!
Let’s begin
For each of the five ITM parameters, we’re going to create a variable in Tag Manager. When a URL that contains one of these parameters is called, its value will be saved in the corresponding variable.
Click on “Variables” in the “Workspace” in Tag Manager and then on “New” under “User-Defined Variables”.
In the window that opens, we’ll define the first variable, itm_source URL-Parameter
, where we’ll be storing the value from the URL parameter itm_source
.
24
itm_source URL-Parameter
.itm_source
. This is the name of the URL parameter that is going to be saved in this variable.Repeat these steps for the four other parameters (itm_medium
, itm_campaign
, itm_content
and itm_term
).
Once you’re finished, there will be five variables available in Tag Manager to save the values from the ITM parameters.
In this screenshot, you can see not only the five newly created variables (itm_xxx URL-Parameter
), but also five additional variables with the type “Constant” (itm_xxx Index
). Let’s take a closer look at the variable itm_source Index
:
itm_xxx
index variablesThe variable itm_source Index
is a constant and has the value 14
.
What is it good for?
In the next step, we’re going to send the contents of the five itm_xxx URL-Parameter
variables to the custom dimensions we prepared in Google Analytics. Each of these custom dimensions is addressed using an index number. In the example, the index number for the dimension itm_source
is 14
(see the section “Creating Dimensions for the ITM Parameters”). In your case, the number will probably be different. If you use the custom dimensions in different tags, you will probably have to check the number of the relevant dimension every time in Google Analytics. That’s why I like to save the dimension number in its own variable — so that I don’t have to remember it. Saving the index numbers in separate variables is not necessary; you can also just address the dimensions in the tag directly with the respective number.
Even with the most basic configuration of Google Analytics and Tag Manager, you will have at least one tracking tag activated — namely, the tag used to send the pageviews to Google Analytics. This tag is ideally suited to be enhanced for the ITM parameters.
Click on “Tags” in the “Workspace” in Tag Manager, and then select the tag with the trigger “All Pages”:
Clicking on the name of the tag will display its details:
Make sure that the “Track Type” is set to “Pageview.” This is the tag used to send pageviews to Google Analytics.
Open the configuration page for the tag, and add the ITM parameters:
{{itm_source Index}}
in the “Index” field and the variable {{itm_source URL-Parameter}}
in the “Dimension Value” field. In this way, the content of the URL parameter itm_source
— which we saved before in the variable itm_source URL-Parameter
— will be passed to dimension number 14 in Analytics.15
). Add the four remaining dimensions for the variables itm_medium-URL Parameter
, itm_campaign URL-Parameter
,itm_content URL-Parameter
and itm_term-URL Parameter
.Here, at the latest, you’ll have to decide whether the information from the ITM parameters should be saved at the session or hit level in Google Analytics. In the example above, I used the index numbers of the session-based dimensions. You will have to adjust this according to your needs.
Now that we have enhanced the pageviews tag, don’t forget to publish the changes in Tag Manager. Now, when the requested URL contains additional ITM parameters, Tag Manager will read them and pass the information to Google Analytics.
After you have finished setting up ITM parameter tracking in Tag Manager, it’s time to take a closer look at the analysis options in Google Analytics. In doing so, we will have to decide whether to save the ITM parameters at the session or hit level (see the section “Creating Custom Dimensions in Google Analytics”).
If you save the ITM parameters in custom dimensions with the scope “Session,” then evaluation of the internal marketing campaign will work in much the same way as with UTM parameters. As I’ve already mentioned, the disadvantage of this method is that there is only one set of ITM data for the whole session, which is overwritten each time a URL with ITM parameters is clicked. As a result, you will only see the information relating to the last click on an internal banner. Of course, this was already the case when using UTM parameters.
Session-based tracking of ITM parameters is more convenient in terms of web analytics, but less accurate than capturing the ITM parameters at the hit level.
The simplest way to create a custom report for evaluating internal marketing campaigns is via the standard reports for campaigns. In Google Analytics, select the report via “Acquisition” → “Campaigns” → “All Campaigns.” You can then modify this report to suit your evaluation requirements by clicking on the “Customize” button.
I’ve made the report for session-based evaluation of internal marketing available34 in the Google Analytics Solutions Gallery.
This is what it looks like:
itm_campaign_s
→ itm_content_s
→ itm_term_s
. So, the internal marketing campaign level is immediately visible in this report. The two other dimensions, itm_source_s
and itm_medium_s
, can be added easily as required.dimension itm_campaign_s
is not empty.Let’s look at the second tab in the report:
itm_source_s
, itm_medium_s
, itm_campaign_s
, itm_content_s
and itm_term_s
.Important tip: The table only displays sessions that have values in all five(!) ITM dimensions. If, for example, you don’t use the parameter itm_term
, then the dimension itm_term_s
will remain empty, which means that no sessions would be displayed in the table. We can eliminate this restriction in two ways: either by removing the unused dimensions from the report or by using Google Tag Manager to set a default value in the dimension if the corresponding ITM parameter is empty. The second option necessitates more work in Tag Manager, as we would then have to distinguish between mandatory parameters and optional parameters.
With the aid of some simple example data, I’d like to illustrate how the data from internal marketing campaigns is presented in this report.
In the “Explorer” tab, it is possible to combine various dimensions with one another; for example, itm_campaign_s
(marketing campaign) and itm_content_s
(ad content):
Or you can analyze the effectiveness of internal marketing campaigns in relation to the external traffic sources. This, for instance, is not possible with UTM parameters:
The table contained in the report provides you with a session-based view of all the ITM parameters and makes it simple to export data for further processing in Excel, Google Docs, etc.
Hit-based evaluation of internal marketing campaigns provides you with an accurate overview of how often specific advertising content has been clicked. However, an additional step is necessary in order to establish the relationship to the conversions achieved. This makes this method of analysis more time-consuming than session-based evaluation. However, it enables more sophisticated analyses.
There is no standard report for hit-based evaluation that we can take and customize for our purposes, so we’ll have to create our own report that will provide us with information on how often the individual pieces of ad content have been clicked. Based on this report, we will then infer the data segments that we need for our analysis. But first, the report.
I’ve also made this report available45 in the Google Analytics Solutions Gallery.
This is what it looks like:
itm_source_h
→ item_medium_h
→ itm_campaign_h
→ itm_content_h
→ itm_term_h
.dimension itm_source_h
is not empty.Let’s look at the second tab in the report:
itm_source_h
, itm_medium_h
, itm_campaign_h
, itm_content_h
and itm_term_h
.Important tip: This table also only displays hits that have values in all five(!) ITM dimensions. If, for example, you don’t use the parameter itm_term
, then the dimension itm_term_h
would remain empty, which means that no hits would be displayed in the table. In this case, you would either have to remove the unused dimensions from the table or use default values for the parameters (see above).
As I already mentioned, combining hit-based data (such as clicks on internal ads) and session-based data (such as conversions) directly is not possible in Google Analytics. That’s why we first use the custom report “Internal Marketing Campaigns (hit-based)” to identify data segments that we can then apply to the acquisition reports, for example.
Let’s look at the report, jumping straight to the table this time:
In the table, we see the number of clicks (hits) on internal ads. The data is grouped based on the combinations of ITM parameters that occurred. In a sense, this is our raw data. Now we have to consider which data segments we can identify:
itm_term_h
, which identifies ad content with a relationship to web analytics (webanalyse
) or AdWords (adwords
).Even with so little data, we can continue to slice it up into new segments. For example, you could create segments from the dimensions itm_term_h
and itm_content_h
to examine which type of ad content works better for itm_term_h = "webanalyse"
or itm_term_h = "adwords"
. But that’s just a side note.
I’m not going to go into the details of creating the data segments. You can see the definition of the segments in their names.
We’ll start with the segment itm_campaign_h = marketing2017
. To make the difference clearer, I also defined a segment that includes all of the users who didn’t click on internal ads. This segment is named itm_campaign_h != marketing2017
. !=
is the operator for “not equal to.”
In the second short analysis, we’ll consider the segments itm_term_h = webanalyse
and itm_term_h = adwords
. These segments enable us to differentiate based on the context of the internal ad with regard to content — in this example, therefore, AdWords (adwords
) and Web Analytics (webanalyse
).
54
adwords
) and Web Analytics (webanalyse
). Once again, I’ve activated the segment itm_campaign_h != marketing2017
(users without clicks on internal ads) as a control group.itm_term_h = webanalyse
and itm_term_h = adwords
would be six conversions, but it is actually seven conversions. This is a consequence of hit-based evaluation. It is possible that users click on banner ads for AdWords and banner ads for Web Analytics during a single session. These users would, then, be part of both data segments!Naturally, these examples are just a taste of the many analyses that are possible with data segments. But they clearly show how much more the potential for analysis is when clicks on internal ads are captured at the hit level.
All done! This article ended up being much longer than I originally planned.
Thanks for sticking with me right to the end and for taking on the challenges of tracking and analyzing internal marketing campaigns with me. As you’ve seen, there are a number of decisions to be made and various settings to be configured.
But they’re worth the effort — internal advertising is one of the most powerful instruments for generating more leads, more conversions and more revenue on your website. In order to employ this instrument profitably, you’ll need data that allows for the evaluation and optimization of your internal marketing campaigns. Particularly if you’re offering personalized product recommendations and the like, detailed data is indispensable for identifying jumping-off points for optimizations.
All the best in the analysis of your internal marketing campaigns!
(da, yk, vf, al, il)
AsciiDots is an esoteric programming language based on ASCII art. In this language, dots, represented by periods, travel down ASCII art paths and undergo operations. By Aaron Janse.
Creating good user experiences for apps inside messaging platforms poses a relatively new design challenge. When moving from desktop web to mobile interfaces, developers have had to rethink interaction design1 to work around a constrained screen size, a new set of input gestures2 and unreliable network connections. Like our tiny touchscreens, messaging platforms also shake up the types of input that apps can accept, change designers’ canvas size, and demand a different set of assumptions about how users communicate.
Our extended UX guide walks you through designing a good experience end to end, but here, we’ll focus on a few things:
Apps are often abandoned due to a poorly designed interface or an overall negative experience. Make sure that you clearly show users why they need your app. Read more →3
This is probably the most critical step when it comes to building your user experience. In order to cater to your users, you need to know what they need and expect from the messaging service they’re using, and what they need from your app.
We’ll spare you any preaching on the value of user personas for consumer apps; in this article, though, we do want to call out specific needs that users have in enterprise messaging apps.
The most basic assumption about people using an enterprise messaging app is that they are using the messaging client at work, for work. It’s a big assumption but is key to everything else: You are building an app for an organization, and your app is helping that organization be productive.
There are many variables to consider:
Your app might target all of these people or just a subset of them, but your users could come from any company. They will be people of all ages, races, genders and ability levels. They might have poor Internet connections, use the messaging app only on mobile or be forced to use it by their boss.
The four factors below will ensure that they all have a great experience.
There are 5-person non-profits and 50,000-person enterprises that could use your app. Some teams keep their conversations in a dozen channels, while others create five channels for every new project or subteam across their organization.
To make your app work well for 5-person teams and 50,000-person teams, take into account how your app uses lists of users and channels. You might need to leave room in your UI for extra channels, or find ways to abbreviate or truncate what you display.
Even on a single team, users might be spread out across multiple time zones. If you’re planning to post notifications at a particular time of day, understand that some people might be seeing the notification at a different time than everybody else on their team.
People also use their work messaging apps while traveling, so they might be in one time zone when they installed your app but in a different time zone a few months later.
Access controls are extremely important in enterprise software. For example, team administrators might permit only certain people to install and manage apps according to company policy. Prompting a user to install your app when they don’t have permission to will fail; check their access levels before suggesting an action, or fail gracefully with informative error messages and an escalation path to their team administrator. If you can, test the installation flow and interactions in your app using a variety of user types.
Just because somebody installs your app on their team doesn’t necessarily mean that everybody else on the team knows about it. In fact, some people might not even realize they’ve installed an app and might think that your app is part of the messaging client’s built-in functionality. As the app developer, you are responsible for making a great first impression on those interacting with your app.
Messages inside any enterprise messaging tool should be designed to help people get work done efficiently. Here are some general rules we’ve learned from seeing hundreds of apps.
Create a storyboard of your app’s interactions before you start coding it. It’s a great way to stay user-centric and provide the most valuable and pleasant experience possible. Mapping out a user’s journey can also help you spot any inefficient paths to completing a task, redundant flows or confusing cycles.
People don’t read4 big blocks of text. Make text scannable by keeping it short.
When you use system features, you stay consistent with the platform’s UI (for example, fonts will look good together, buttons will stay in proportion with everything else on the screen), and you’ll also benefit from the work each company has done to optimize those features for display across mobile and desktop. Remember that your app is contained within the frame of another app, so completely rolling your own style would look more jarring than unique.
What’s more, UI elements such as buttons8, attachments9 and menus10 give you a lot of flexibility to make your messages pop. If you’re having trouble keeping your messages short, think about using images or linkified text to make them easier to read.
For example, the message below uses links and colored buttons to highlight the key elements of the message: There is a task to be completed, related to a specific message belonging to a specific topic.
Besides making sure your app’s messages look great, you’ll want to do a few more things.
Save people work wherever you can by minimizing the choices they have to make. When you give menus and buttons good default values, you decrease the number of choices users have to make from many to just one: yes or no.
Say your app helps people buy coffee. Instead of presenting a full menu of choices every time someone orders, you could make the user’s last order the default option. In the best-case scenario, this reduces the coffee order to a single click.
Users will be interacting with your app asynchronously. They might begin a task, then get interrupted and revisit later. Your app should plan for that. Interruptions or periods of inactivity may or may not signal a loss of intent on the part of the user.
Decide whether anything in your workflow is time-sensitive. Should someone be able to jump in on a task again at any time? Should some content expire or need to be redone? Make a conscious choice about the lifespan of messages.
UI-heavy messages are great in the moment you receive them: They’re easy to read, good to look at and simple to interact with. They also take up a lot of space on the person’s screen.
In your storyboard, think about what a person will need to remember about their interaction with your app when they come back to it later, at the end of the message’s life or after an exchange of several messages. Do those buttons and menus need to stick around, or could you condense the message down to a simple text record of what happened? Be considerate and update your message after the interactive portion of the conversation has expired.
If your app has a conversational bot component18, the way your bot communicates will become part of your brand’s voice. In the most literal interpretation of a chat UI, your bot is your company’s logo having a conversation with the end user — so, no matter what, you are expressing something about your brand and values, and you should be thoughtful about what you say.
If you strive to make your bot sound clear, concise and human, you can’t go far wrong. The bot’s voice could start out being more or less your own, progressively edited for clarity.
Believe it or not, if you’re doing any sort of natural language processing on your users’ responses, taking the time to write clear, concise bot copy will pay dividends. On nearly all platforms, your bot will speak to the user first. This helps set the tone for the conversation, since people generally mimic the way they’re spoken to when replying. If your bot speaks clearly and in grammatical English (or the language of your choice), you’re more likely to get grammatical replies back.
Write down some adjectives that you’d like people to use to describe your brand or your bot (for example, “friendly,” “authoritative”). Then you can go back and edit the words you would have used as yourself, and make sure they’re consistent with how someone communicates when they’re friendly or authoritative.
Small words can make a difference. Think about how you would reply to a bot that greets you like this…
Hello, how may I help you?
… versus like this:
Hey, how can I help you?
For further reading, MailChimp’s “Voice and Tone19” guide is a very helpful way to frame how you approach writing for your bot.
Your bot’s primary purpose is not to sound clever or to entertain users, but to help them accomplish a task — even if that task is inherently entertaining, like finding just the right cat GIF. Even if your app is useful, if it feels like more work chatting with your bot than just doing the same task outside of the messaging interface, then you’re going to lose some users.
A bot with personality can help you stand out, but within limits:
A little goes a long way. We cannot say this enough.
Don’t add a joke or aside just to add one. Almost every word your bot says should facilitate an interaction. (Courteous parts of speech, such as greetings, are also useful.)
Don’t do this:
Try this instead:
The second example still has plenty of distinctive personality, but gets straight to the point.
Try to write copy for your interactions that someone who doesn’t speak your language fluently could easily understand. That means:
No:
Yes:
The emoji combination is also potentially confusing and might stall some users as they try to decipher it (“Fire?… Meat?… Firemeat?”).
This button copy is similarly difficult to understand and, in the worst case, could prevent users from selecting a response at all. Try to use standard combinations on buttons (“Yes” and “No,” “Confirm” and “Cancel”) to help users have a smooth, simple experience with your app.
Read over the copy and ask yourself, “Is there anywhere a user might pause in confusion?” Better yet, watch someone read your copy and see if they get confused.
Your users could be people of all ages, races, genders and ability levels. Write for them all:
Writing for a broad audience takes a bit of practice if you’re new to it, and it is usually easier if you have a team of people from diverse backgrounds working on your bot from the start.
Words and copy used in your interactions should be easily understood even by someone who doesn’t speak the same language fluently.
Above all, don’t get too attached to anything you write for your bot. Good writing is always in the editing; be open to changes and to feedback, and you’ll iterate your way to success.
Taking your app to a new platform requires that you adapt to your users’ expectations and needs in that new medium. We hope this guide has clarified some of the things that are most impactful to enterprise users of messaging apps: the context of work, UI primitives and how to speak in messages.
We don’t have all the answers. Everything we’ve recommended here is what we’ve seen work for us (building Slackbot34) and for successful apps on Slack35. If you have your own ideas on what works, we’d love to hear them — drop us a line36!
This is an excerpt adapted from Slack’s new UX guide — a comprehensive look at what goes into building a great app for Slack. You can read the full version here37.
(rb, yk, vf, al, il)
Front page image credit: Should I Use Slackbot (Flowchart)38
Have you ever read a post that has left you feeling wholly inadequate because you know you can’t live up to the high standards they lay out? Well, that is how I feel when I read posts about how much to charge my clients.
When Smashing Magazine asked me to write an article sharing my thoughts on pricing my services, I agreed without much thought. But now I sit down to write it, and I’m faced with a conundrum. Do I write about how you should price projects or do I tell you the truth about the unorthodox approach I take?
I have read many posts about the pricing of a project. From value-based pricing1, to billing around Agile cycles2. These are all great approaches I aspire to, but have somehow never managed to implement. I suspect I am not alone.
So instead of intimidating you with complex value-based pricing formulas or boring you to death with project Gantt charts, I am going to share with you the rather inelegant approach I take to the subject. Inelegant it may be, but it has allowed me to run a lucrative business for the last 15 years.
It begins by knowing the minimum you have to charge per hour.
Unfortunately, there are clients who do not quite respect the work that you do, but there are a number of ways you can deal with them. Read more →3
Okay, so this is the one bit of the process I have made an effort to approach professionally. It is important to know the minimum you have to charge per day to live. That isn’t going to be the rate I charge my clients. It is just the rate I am not willing to go below.
So how do we calculate that rate? Fortunately, it isn’t rocket science. Just follow these steps:
Start with the minimum wage you would like to take out of the business. How much do you want to earn a year? Remember, this is the minimum figure you could survive on. We will increase that number later.
Next, calculate your costs including reoccurring costs such as software services, rent, etc. But also include a budget for one-off costs such as that shiny new Mac you want. Work out how much this all comes to a year.
Don’t forget to plan for the future. Set aside some money each month for pension and savings. Calculate the total over a year and add it to your costs and salary.
The figure you now have tells you how much money you must earn before tax. Now, add to that total the tax you would have to pay on that revenue. That will give you the minimum figure you need to earn over the year.
Before we can work out how much to charge per day, we first need to know how many days a year you work. To do that you follow these steps:
So in my case, it is 260 working days minus ten public holidays and 20 days vacation time.
6
Unfortunately, we still cannot take our target revenue and divided by 230 days. That is because you will not be able to charge out every hour you work.
There are many other factors to consider. You will spend time marketing, writing proposals, doing admin, and managing your finances. None of these is chargeable. Realistically you can’t expect to charge yourself out more than about 60% of the time.
All of this work will leave you with a minimum daily rate. Now we need to calculate how long our project will take. That is where you will begin to see my rather ad-hoc approach.
Sam Barnes wrote a brilliant post8 on calculating the time a project will take, as did Peter Mouland9. I recommend you read these because, to be honest with you, I just guess.
10
Sure, if it is a big project I break it down a bit and try to price each part separately. But mainly it is a gut feel for how long things will take. I guess I have the advantage of doing this job for over 20 years, so the chances are I have done a similar project before. But I don’t want to lie to you and pretend I have some clever system. I don’t.
I found that for me, spending hours calculating how long things would take wasn’t worth it. Whether I was bad at it or whether I am just unlucky, but there always seemed to be a curve ball that ended up making my carefully crafted figure inaccurate. I appear to do just as well taking an educated guess.
I make my best guess and times it by my minimum rate per day, and that gives me my minimum price. But this is not what I charge. In fact, if a client can only pay my minimum price then I walk away in most cases. After all, my calculation for the length of the project isn’t exactly accurate, so I need to ensure I have a markup.
My minimum price tells me if the project is viable, but it isn’t an amount the client will ever see. I decide on that pricing using three very professional (sarcasm) factors that I outline below.
You know what it is like, some projects get you excited and some you couldn’t care less if you do. So why not factor that into your pricing? Projects that sound awesome and you desperately want to win, will hardly be marked up at all. Projects that look as dull as ditchwater gets a hefty wedge added on top of the minimum rate.
12
That makes a lot of sense if you think about it. It encourages more of the kind of work you want to be known for and that you love. It might seem unfair, but if the client doesn’t want to pay your premium to do a tedious project, he can always go elsewhere.
Next up we have “the client is an ass” tax. Always, always, take every opportunity you can to speak to the client before pricing their project. Ask lots of questions and get them talking. Do your best to ascertain what kind of client they are likely to be.
If you think they are going to be difficult to work with, charge them more. Again this makes sense. Demanding clients require you to put in more effort to deliver and so should be charged a premium for that extra effort.
14
Finally, we come to the most interesting one – what can I get away with charging? I work with a huge range of clients. Some are multinational conglomerates, and others are small charities or public sector organizations.
In theory, you could argue that I should charge all of those clients the same, but I don’t. The multinational will pay more because they have more. I never got on with value based pricing, but I do recognize I have value and that my value is proportional to the organization. The larger the organization, the more they can do with the value I bring and so the more I am going to charge them for it.
16
There is a related factor here too. People often equate value with how much they pay. Therefore the more I charge them, the more they value what I produce. They take me more seriously if they are paying top dollar for me.
But what people perceive as expensive varies based on their situation. My charge out rate would seem cheap to a large multinational and costly to that smaller charity. Hence, I change my rates depending on the client.
It is important to note that none of the factors I use to decide on a price reflects how desperate I am for work. I don’t charge less if I need the work and neither do I charge more if I am busy. That just feels like a slippery slope to me and stinks of desperation.
If times are tough, I would prefer to put my energies into sales and marketing rather than working on a project that I might not even break even on.
I am conscious that this post may reflect poorly on me. I nearly didn’t write it for fear it would seem unprofessional. But I know I am not alone in taking this kind of approach. We just don’t talk about it.
In truth pricing projects is almost impossible to do accurately or in an entirely ‘fair’ way. There are just too many variables, too many things that can go wrong. All we can do is take our best guess.
Also at the end of the day, pricing is about supply and demand. Pricing isn’t a matter of calculating a rate based on hours spent or return generated. It’s your time, and if people are willing to pay, you can charge whatever you like.
(vf, il)
pdf-bot * Cboard * Electron Webpack Dashboard * WebGL Fluid Simulation * Interface Font * SVG Gradient Wave Ge…
Using voice commands has become pretty ubiquitous nowadays, as more mobile phone users use voice assistants such as Siri and Cortana, and as devices such as Amazon Echo and Google Home1 have been invading our living rooms. These systems are built with speech recognition software that allows their users to issue voice commands2. Now, our web browsers will become familiar with to Web Speech API, which allows users to integrate voice data in web apps.
With the current state of web apps, we can rely on various UI elements to interact with users. With the Web Speech API, we can develop rich web applications with natural user interactions and minimal visual interface, using voice commands. This enables countless use cases for richer web applications. Moreover, the API can make web apps accessible, helping people3 with physical or cognitive disabilities or injuries. The future web will be more conversational and accessible!
Web Speech API enables websites and web apps not only to speak to you, but to listen, too. Take a look at just some great examples of how it can be used to enhance the user experience. Read more →4
In this tutorial, we will use the API to create an artificial intelligence (AI) voice chat interface in the browser. The app will listen to the user’s voice and reply with a synthetic voice. Because the Web Speech API is still experimental, the app works only in supported browsers5. The features used for this article, both speech recognition and speech synthesis, are currently only in the Chromium-based browsers, including Chrome 25+ and Opera 27+, while Firefox, Edge and Safari support only speech synthesis at the moment.
This video shows the demo in Chrome, and this is what we are going to build in this tutorial!
To build the web app, we’re going to take three major steps:
SpeechRecognition
interface to listen to the user’s voice.SpeechSynthesis
interface to give it a synthetic voice.The entire source code9 used for this tutorial is on GitHub.
This tutorial relies on Node.js. You’ll need to be comfortable with JavaScript and have a basic understanding of Node.js.
Make sure Node.js10 is installed on your machine, and then we’ll get started!
First, let’s set up a web app framework with Node.js. Create your app directory, and set up your app’s structure like this:
. ├── index.js ├── public │ ├── css │ │ └── style.css │ └── js │ └── script.js └── views └── index.html
Then, run this command to initialize your Node.js app:
$ npm init -f
The -f
accepts the default setting, or else you can configure the app manually without the flag. Also, this will generate a package.json
file that contains the basic info for your app.
Now, install all of the dependencies needed to build this app:
$ npm install express socket.io apiai --save
With the --save
flag added, your package.json
file will be automatically updated with the dependencies.
We are going to use Express11, a Node.js web application server framework, to run the server locally. To enable real-time bidirectional communication between the server and the browser, we’ll use Socket.IO12. Also, we’ll install the natural language processing service tool, API.AI13 in order to build an AI chatbot that can have an artificial conversation.
Socket.IO is a library that enables us to use WebSocket easily with Node.js. By establishing a socket connection between the client and server, our chat messages will be passed back and forth between the browser and our server, as soon as text data is returned by the Web Speech API (the voice message) or by API.AI API (the “AI” message).
Now, let’s create an index.js
file and instantiate Express and listen to the server:
const express = require('express'); const app = express(); app.use(express.static(__dirname + '/views')); // html app.use(express.static(__dirname + '/public')); // js, css, images const server = app.listen(5000); app.get('/', (req, res) => { res.sendFile('index.html'); });
Now, let’s work on our app! In the next step, we will integrate the front-end code with the Web Speech API.
The Web Speech API has a main controller interface, named SpeechRecognition1614, to receive the user’s speech from a microphone and understand what they’re saying.
The UI of this app is simple: just a button to trigger voice recognition. Let’s set up our index.html
file and include our front-end JavaScript file (script.js
) and Socket.IO, which we will use later to enable the real-time communication:
<html lang="en"> <head>…</head> <body> … <script src="https://cdnjs.cloudflare.com/ajax/libs/socket.io/2.0.1/socket.io.js"></script> <script src="js/script.js"></script> </body> </html>
Then, add a button interface in the HTML’s body:
<button>Talk</button>
To style the button as seen in the demo, refer to the style.css
file in the source code15.
In script.js
, invoke an instance of SpeechRecognition1614, the controller interface of the Web Speech API for voice recognition:
const SpeechRecognition = window.SpeechRecognition || window.webkitSpeechRecognition; const recognition = new SpeechRecognition();
We’re including both prefixed and non-prefixed objects, because Chrome currently supports the API with prefixed properties.
Also, we are using some of ECMAScript6 syntax in this tutorial, because the syntax, including the const
and arrow functions, are available in browsers that support both Speech API interfaces, SpeechRecognition
and SpeechSynthesis
.
Optionally, you can set varieties of properties17 to customize speech recognition:
recognition.lang = 'en-US'; recognition.interimResults = false;
Then, capture the DOM reference for the button UI, and listen for the click event to initiate speech recognition:
document.querySelector('button').addEventListener('click', () => { recognition.start(); });
Once speech recognition has started, use the result
event to retrieve what was said as text:
recognition.addEventListener('result', (e) => { let last = e.results.length - 1; let text = e.results[last][0].transcript; console.log('Confidence: ' + e.results[0][0].confidence); // We will use the Socket.IO here later… });
This will return a SpeechRecognitionResultList
object containing the result, and you can retrieve the text in the array. Also, as you can see in the code sample, this will return confidence
for the transcription, too.
Now, let’s use Socket.IO to pass the result to our server code.
Socket.IO18 is a library for real-time web applications. It enables real-time bidirectional communication between web clients and servers. We are going to use it to pass the result from the browser to the Node.js code, and then pass the response back to the browser.
You may be wondering why are we not using simple HTTP or AJAX instead. You could send data to the server via POST
. However, we are using WebSocket via Socket.IO because sockets are the best solution for bidirectional communication, especially when pushing an event from the server to the browser. With a continuous socket connection, we won’t need to reload the browser or keep sending an AJAX request at a frequent interval.
Instantiate Socket.IO in script.js
somewhere:
const socket = io();
Then, insert this code where you are listening to the result
event from SpeechRecognition
:
socket.emit('chat message', text);
Now, let’s go back to the Node.js code to receive this text and use AI to reply to the user.
Numerous platforms and services enable you to integrate an app with an AI system using speech-to-text and natural language processing, including IBM’s Watson20, Microsoft’s LUIS21 and Wit.ai4022. To build a quick conversational interface, we will use API.AI, because it provides a free developer account and allows us to set up a small-talk system quickly using its web interface and Node.js library.
Once you’ve created an account, create an “agent.” Refer to the “Getting Started23” guide, step one.
Then, instead of going the full customization route by creating entities and intents, first, simply click the “Small Talk” preset from the left menu, then, secondly, toggle the switch to enable the service.
Customize your small-talk agent as you’d like using the API.AI interface.
Go to the “General Settings” page by clicking the cog icon next to your agent’s name in the menu, and get your API key. You will need the “client access token” to use the Node.js SDK.
Let’s hook up our Node.js app to API.AI using the latter’s Node.js SDK! Go back to your index.js
file and initialize API.AI with your access token:
const apiai = require('apiai')(APIAI_TOKEN);
If you just want to run the code locally, you can hardcode your API key here. There are multiple ways to set your environment variables, but I usually set an .env
file to include the variables. In the source code on GitHub, I’ve hidden my own credentials by including the file with .gitignore
, but you can look at the .env-test
26 file to see how it is set.
Now we are using the server-side Socket.IO to receive the result from the browser.
Once the connection is established and the message is received, use the API.AI APIs to retrieve a reply to the user’s message:
io.on('connection', function(socket) { socket.on('chat message', (text) => { // Get a reply from API.AI let apiaiReq = apiai.textRequest(text, { sessionId: APIAI_SESSION_ID }); apiaiReq.on('response', (response) => { let aiText = response.result.fulfillment.speech; socket.emit('bot reply', aiText); // Send the result back to the browser! }); apiaiReq.on('error', (error) => { console.log(error); }); apiaiReq.end(); }); });
When API.AI returns the result, use Socket.IO’s socket.emit()
to send it back to the browser.
Let’s go back to script.js
once again to finish off the app!
Create a function to generate a synthetic voice. This time, we are using the SpeechSynthesis
controller interface of the Web Speech API.
The function takes a string as an argument and enables the browser to speak the text:
function synthVoice(text) { const synth = window.speechSynthesis; const utterance = new SpeechSynthesisUtterance(); utterance.text = text; synth.speak(utterance); }
In the function, first, create a reference to the API entry point, window.speechSynthesis
. You might notice that there is no prefixed property this time: This API is more widely supported than SpeechRecognition
, and all browsers that support it have already dropped the prefix for SpeechSysthesis
.
Then, create a new SpeechSynthesisUtterance()27 instance using its constructor, and set the text that will be synthesised when the utterance is spoken. You can set other properties28, such as voice
to choose the type of the voices that the browser and operating system should support.
Finally, use the SpeechSynthesis.speak()
to let it speak!
Now, get the response from the server using Socket.IO again. Once the message is received, call the function.
socket.on('bot reply', function(replyText) { synthVoice(replyText); });
You are done! Let’s try a chit-chat with our AI bot!
Note that the browser will ask you for permission to use the microphone the first time. Like other web APIs, such as the Geolocation API and the Notification API, the browser will never access your sensitive information unless you grant it, so your voice will not be secretly recorded without your knowledge.
You will soon get bored with the conversation because the AI is too simple. However, API.AI is configurable and trainable. Read the API.AI documentation31 to make it smarter.
I hope you’ve enjoyed the tutorial and created a fun chatbot!
Voice interaction has transformed the way users control computing and connected devices. Now with the Web Speech API, the user experience is transforming on the web, too. Combined with AI and deep learning, your web apps will become more intelligent and provide better experiences for users!
This tutorial has covered only the core features of the API, but the API is actually pretty flexible and customizable. You can change the language of recognition and synthesis, the synthetic voice, including the accent (like US or UK English), the speech pitch and the speech rate. You can learn more about the API here:
Also, to learn Node.js and the libraries used in this tutorial, check out the following:
Finally, check out the different natural-language-processing tools and conversational platforms!
(rb, yk, al, il)
A very interesting article by Akar Sumset that explains how gamification can work by showing the relationship between gamification, UX design, and BJ Fogg’s modern persuasion phenomenon, “mass interpersonal persuasion.”
The world around us is full of little things and experiences that shape us, our way of thinking, but also how we tackle our work. Influenced by these encounters, every designer develops their unique style and workflow, and studying their artwork — the compositions, geometry of lines and shapes, light and shadows, the colors and patterns1 — can all inspire us to look beyond our own horizon and try something new.
It really doesn’t take much to let your mind wander. Always remember to take a closer look at things around you; you’ll be sure to find inspiration in the little things2. But for now, let’s dig into another collection of brilliant illustrations and photographs.
Do you often find yourself having mental blocks? Why not get out a bit and attend an event? We’ve prepared a list of upcoming events that will help you make a shift in your mindset. Read more →3
What a great friendly vintage atmosphere! Well done.
Latest project from Maria Svarbova. Again, cleverly playing with symmetry and color.
Diging the retro-futuristic-exciting style in this one.
Perfect lines and shapes, but also such great use of color.
Loving the special color choices in this illustration, and all of the movement that’s been going on.
You should always stop to taste a delicious tomato. I like the atmosphere created in this one.
Clever concept and execution mixed with subtle use of color and texture.
Great black silhouette to use as a centerpiece in this illustration so that everything else can be in color.
A brilliant choice of style and textures in this one!
Wow. Now these are some exceptional colors. Loving the vibrant contrast!
This one has quite a special style and excellent usage of textures.
DKNG got to create a poster for their favorite band Radiohead playing at the iconic Greek Theater in Berkeley, CA. Beautiful geometrical design with superb dark shadows and light effects.
It’s a wonderful thing to get to see the imagination of an illustrator who thinks “imagining what it would be like to paddle a kayak on those serene sunset waters”… The colors and gradients used here to reflect the sunset are just so well done.
Just look at that view!
Nicely designed character poses. I love the subtle background elements and overall cute style.
Gorgeous style by Carll Cneut from Belgium.
All those lovely eyes!
I love these reflections and the beautifully soft light. Such an incredible and tranquil image.
On point! Part of the head makes me think about Magnum P.I. played by Tom Selleck.
Nice work, especially the color choices and the toned down background scene.
Pretty spectacular sunset at Siesta Key Beach.
Great illustration by Sébastien Plassard. The beard and the hair are simply beautiful.
Incredible shot captured in Keyes, Oklahoma by storm chaser @VanessaNeufeld48.
Really nice illustration and some inspiring color choices.
The patterns throughout this piece are mesmerizing. Loving that gold accent color as well.
Loving those candy colors. Also look at that skateboard! I love this ‘gummy’ bendable look.
Such beautiful contrasts! The subtle textures like on the lobster gives this one an edge.
That eagle and those hand combos combined with the typography are making this a great shot.
The yearly circus every July.
Nice example of using just two colors.
Great composition of a scene in which shapes are being used as either desks or surfaces to stand on.
Wonderful school posters!
Super dope! I love the pattern on the sweater. The faces and different beard styles are also ace.
Great diverse bunch of characters.
Very nice to see all hallmark sights nicely integrated into the letters.
Enjoying the style, especially the lines that just guide you to see the rest.
The iron work on the fences and patterns on the tiles in this Morrocan riad is so beautiful. The colors are also perfect.
A beautiful style with some isometric influences.
Interesting approach to the tire shapes. Those are some lovely soft tones as well.
Beautiful! Love the movement.
Great graphical elements on the fish.
Classic and elegant. Love the metaphor to open the door for better weather or a new season.
Illustrations that explore imagination are always among my favorites. Thumbs up for the muted color palette as well.
It’s great to see how all those ‘etch’ lines are capable of accentuating the details in this illustration.
Colors and composition are on point.
Wonderful badge art for Field Trip Music Festival‘s 2017 branding.
Not an ordinary everyday color palette. Love the sense of speed in it.
Top notch work as always with an inspiring color selection.
The right mix of floral elements to achieve a perfect balance.
Those soft subdued tones and light really compliment the wild and remote feeling of this scene. Composed perfectly as well with just one inclusion of the person.
If you’re like me, then being persuaded requires a scientific approach and concrete examples. And that’s exactly what this article does. It explains how gamification can work by showing the relationship between gamification, UX design, and BJ Fogg’s modern persuasion phenomenon, “mass interpersonal persuasion.” And it has a lot of practical gamification examples that you can apply to your own products for more engaging experiences.
Today, virtually all companies (except for special ones like Basecamp1) have to grow non-stop. Why? Well, that’s simply how the capitalist engine works. Investors pour money into startups, banks loan money to entrepreneurs, employees accept stock options instead of cash, all in the hope of the company growing much bigger. That’s why there is so much emphasis on growth. Otherwise, the whole system would collapse. It’s kind of crazy when you think a bit more deeply about it, but I’ll leave that part to you for now.
What we call “growth” in the tech world is called “persuasion” in academia. With this article, I want to show why gamification is a great tool for growth and how persuasion science (more precisely, the “mass interpersonal persuasion” phenomenon) proves that. I’ll do that with examples and facts. Let’s get going.
Not only can gamification help sell your products better, but it can also be used to improve the user experience of your websites and apps. Read more →2
I think a lot about words, their meanings and how they shape our perception. This is of special importance to us UX and product people because we’re flooded with jargon. Let’s look at the following example to better understand the importance of words.
“UX is not UI” is a common reproach, and it is correct. Thanks to this famous photograph above, we now better understand that UX is not UI. But UX — or, more precisely, user experience design — is not usability either, as implied in the photograph. It requires an understanding of business goals as well as user needs and satisfaction of both, in a coherent fashion. But because the term “user experience design” does not imply anything about business, nobody talks about business. Daniel Kahneman, Nobel Prize winner in Economics, has a term for this phenomenon: What you see is all there is4. We do not see “business” in user experience design, so it becomes all about users.
Gamification is another victim of misnaming. Contrary to popular belief, it does not entail users playing or giving them points. Yes, those are useful components, but not the whole thing. The purpose of gamification is not to make people have fun, either. The purpose is to use fun to motivate people towards certain behaviors. Motivation is the key here. As shown6 above by Michael Wu, motivation and game components are in parallel. That’s why we use gamification to motivate users. If that parallel were provided by something else — say, biology — then we’d use biologification to motivate users.
So, what is gamification? One of my favorite definitions comes from Juho Hamari7 of Tampere University of Technology:
Gamification is a process of enhancing a service with affordances for gameful experiences in order to support user’s overall value creation.
My other favorite definition comes from Kevin Werbach8 of the University of Pennsylvania:
Gamification is the process of making activities more game-like. In other words, it covers coordinated practices that objectively manifest the intent to produce more of the kinds of experiences that typify games.
As much as I like the definitions above, I still miss the emphasis on motivation and behaviors. So, here goes my definition of gamification:
Gamification is about using game-like setups to increase user motivation for behaviors that businesses target.
Naturally, my definition resembles user experience design. It does that by mixing the first two definitions. I’ve tried to convey how gamification satisfies users and businesses at the same time. I am not sure which definition is the most accurate, but I know this for sure: We have been playing games since we lived in caves, and we enjoy them for some reason. It’s only sensible to get inspiration from games, be it for business, education or something else.
If we want to understand persuasion9, then we should understand, before anything else, that people are predictably irrational10. Predictably irrational means that, even though people do not behave rationally most of the time, there are still patterns in this irrationality that help us predict future behaviors. This is why logic alone is not enough to persuade people. If people were consistently rational beings, then we would be living in a completely different world. For example, TV ads would merely consist of logical statements instead of gorgeous video productions. Coca-Cola ads would be like, “Coca Cola > Pepsi,” and Sony’s famous “Like no other” slogan would turn into “Sony !≈ anything else.”
Persuasion requires understanding neurology, psychology, biology, technology… a lot of “-ologies”. But arguably, the most important of all these ologies is technology, thanks to the unprecedented advancements in Internet and mobile in the last decade.
So much so that BJ Fogg said the following12 (PDF, 208 KB):
This phenomenon (Mass Interpersonal Persuasion) brings together the power of interpersonal persuasion with the reach of mass media. I believe this new way to change attitudes and behavior is the most significant advance in persuasion since radio was invented in the 1890s.
Bear in mind that, from a scientific point of view, persuasion is an umbrella term13 for affecting people’s attitudes, behaviors, intentions or beliefs. It does not necessarily require changing people’s beliefs or ideas.
Let me give you an example.
My father, 62 years old, has always been critical of iPhones because he finds the prices unreasonable — not because he cannot afford one, but because an iPhone 7 Plus (256 GB) costs almost four times the minimum wage in Turkey, where we live. But he bought an iPhone 7 for himself last month. How come? Well, for a year or so, he has been telling me how his friends have these big-screen phones and show him pictures of their grandchildren. Eventually, he got fed up with not being able to do the same and bought an iPhone 7. (All he needs now is a grandchild… sigh!) He still finds it expensive, but he bought it anyway. His idea did not change, but his behavior did. That’s what we call persuading without changing beliefs.
In 2007 a new form of persuasion emerged: mass interpersonal persuasion (MIP). The advances in online social networks now allow individuals to change attitudes and behaviors on a mass scale.
This is how BJ Fogg defines MIP14. The advances he mentions in the definition start with the launch of Facebook Platform in 2007. Facebook Platform is an aggregation of services and products available to third-party developers so that they can create games, applications and other services using Facebook data. Facebook’s success triggered other platforms to provide similar services. Fast-forward to today: We are living in an era when we type passwords no more, thanks to sign-in with Facebook, Google and Twitter. Or, if we want something more advanced, we can get a personality analysis15 just by providing our Twitter handle. For an example that’s even more advanced — and scary — we can look at the debates on Facebook’s alleged influence on the latest US elections16. This is how powerful social platforms are today.
MIP consist of six components. To better understand MIP and its connection to gamification, let’s look at what they are, one by one, with examples.
The following quote (and the remaining ones in this article) is taken from BJ Fogg17:
An experience that is created to change attitudes, behaviors, or both.
The key here is the intentionality to change behaviors or attitudes by providing experiences, as opposed to just stating facts and expecting people to be reasonable enough to change their behaviors or attitudes accordingly.
Now, let’s remember our definition of gamification:
Gamification is using game-like setups to increase user motivation for behaviors that businesses target.
Similar to MIP, gamification is quite intentional about changing behaviors. It does that by focusing on the entirety of the users’ experience to find the relevant spots where it can blend in the experience and do its magic. A great example of this is Sweden’s Speed Camera Lottery. The Speed Camera Lottery is a simple solution. If you do not drive over the speed limit, then you instantly get a chance to participate in a lottery. Even funnier is that the winnings comes from the fines paid by speeders.
To better understand the intentionality behind behavior change, let’s compare the Speed Camera Lottery with the campaign of New York City’s Department of Transportation (NYC DOT).
Sweden’s Speed Camera Lottery
NYC DOT’s campaign is quite impressive, with its powerful visual and message. “Hit at 40 mph: There’s a 70% chance I’ll die. Hit at 30 mph: There’s an 80% chance I’ll live.” It’s hard to compare these two campaigns because the cultures in these two countries differ quite a lot, and NYC DOT’s campaign encompasses a lot of different initiatives, such as new traffic signals, speed bumps, and pedestrian walkways. However, when viewed from a purely behavioral science point of view, the Speed Camera Lottery is more likely to influence the behavior of obeying the speed limit. Why?
That being said, though highly successful (reducing the average speed by 22%20), the Speed Camera Lottery had one downside. Some geniuses started circling around to increase their likelihood of winning the lottery. Well, that did not quite work out for them, but we should always be wary of cheaters.
Digital technology structures the persuasive experience.
We saw how the core of gamification is to create persuasive experiences with the first component of MIP. Now let’s look at the link between gamification and automated structures.
By design, gamification produces well-structured processes. Regardless of what product we are building, we need a tool to quantify behaviors to even start with gamification. Think of something similar to Google Analytics or MixPanel. For behavior tracking to be useful, we do not just count how many people perform a certain behavior, but rather define rules like, “If a user clicks five help links in a session, then open the chat window.” Gamification, by nature, is built on top of these kinds of rules:
We could easily add more examples to the list. Obviously, these are very simple examples, but the point is that gamification is inherently based on rules. That’s why it is very easy to build an automated structure to create a persuasive experience using gamification.
Example: Nike Fuel
Fuel presents a lot of examples of automated structure here.
Example: FitWell
I did gamification design for FitWell23, an app that tailors meal plans and workout regimens according to the app’s assessment. Our research showed that the most important problem people encounter during their fitness journey is that they lack feedback after a while. At the beginning, we feel energized, see changes in our posture and, thus, feel motivated. After a while, though, progress slows, and we start worrying that our efforts are accomplishing nothing. That’s where gamification comes into play. With a lot of automated feedback loops, users get various encouraging feedback when their body fails to provide any.
Example: Duolingo
Duolingo takes the automated experience a step further with “Shop.” Thanks to the shop, not only do I get feedback on my progress, but I also get to reward myself with Lingots (the in-app currency) all by myself.
Yes, we do not have to gamify our products to provide these kinds of experiences, but it is much easier if we do. Gamification forces us to think of actions and feedbacks that, by nature, produce an automated structure.
The persuasive experience is shared from one friend to another.
We just saw how gamification helps us with automating persuasive experiences. Now let’s see how gamification fuels social distribution.
Just four words: “Invite friends, earn money!” Money here is a variable. It could be anything from free disk space to an invitation to that new cool app. The key here is that it always involves friends and some kind of reward.
Example: Dropbox
Notice how Dropbox not only offers rewards but also makes it extremely easy to share.
Example: Airbnb
Airbnb does everything Dropbox does and take it a step further: If your friend travels using Airbnb, then you get $75 more.
Example: Flipkart
The pattern is obvious by now: invite → sign up → earn money → perform extra behavior → earn even more money.
But that is not necessarily the only way. Look at what Gmail does with Inbox.
Example: Inbox
Do you remember the days when Inbox came out? Did you too harass your friends for an invitation, like my friends did to me?
Gmail had more than 500 million users when Inbox was released as an invitation-only product. So, obviously, Inbox was not after acquisition. But what was it after?
Adoption. This is why it turned the social distribution scheme upside down. Instead of rewarding people with money or free disk space, it rewarded people with the privilege of having invitations. Those privileged people (the innovators and early adopters33) were already going to try Inbox. By giving innovators and early adopters a higher status, Google turned them into a distribution tool. Limited access made the early majority crave for Inbox, which in turn both accelerated adoption and increased the satisfaction of those lucky enough to use Inbox.
Has it worked for Google? I don’t know the exact numbers, but the screenshot above, along with insights from an ex-Google product manager34, are key signals that it worked out very well for Google.
Speaking of the “Invite people and earn X” tactic, I have this friend who subscribed to a healthy-eating service that gives free meals in exchange for invitations. Following this tactic, he eventually had to cancel his subscription because he brought on too many people and ended up gaining more weight!
What this means is that the time between invitation, acceptance, and a subsequent invitation needs to be small.
On a more abstract level, rapid cycle can be restated as follows:
What this means is that the time between action, feedback, and a subsequent action needs to be small.
When viewed like this, Nir Eyal’s hook model35, the most important tool in my gamification toolbox, perfectly matches rapid cycle. ‘Hook’ is Nir’s explanation for why some products are so habit forming. Simply put, we get motivated if we get positive and instant feedback for our behaviors. Even better, if we get a chance to take a further step, we get even more motivated.
I won’t explain the whole hook model here, but here is the gist:
Let’s see a couple of examples of the hook model.
Examples
(RJ Metrics Blog, Janessa Lantz)
The persuasive experience can potentially reach millions of people connected through social ties or structured interactions.
Having millions of users is not enough for MIP to happen. What you need is millions of connected people, and the nice part is that they do not have to be your users either. You need the potential to reach millions. How? Well, for one, there are social networks. Use social log-in and leverage your users’ networks on those platforms. But that is not the only way. Suppose you have a SaaS analytics product. How can you reach millions? Provide Google Analytics integration and voilà! Now you’re relevant to millions of people.
Let’s look at how gamification helps connect people.
Example: Quora
Quora’s “Ask to Answer”
Quora suggests people with related expertise when we ask a question. This is an amazing solution. Why?
And this is all possible thanks to a very simple game mechanic: mastery. None of this would work if Quora did not have those domain experts.
Example: Yemeksepeti
This example is from my hometown — hence, the language in the photo. Yemeksepeti is the Turkish version of Delivery Hero. They recently introduced a “muhtar” feature. Muhtar means “headman” in Turkish. A muhtar knows everyone and every detail about a neighborhood. So, the one with the most points in a neighborhood becomes the muhtar. As you can see, Alper G. is the muhtar in my neighborhood (the list on the right is the leaderboard).
I’ve been using Yemeksepeti for more than five years, and this is the first time I’ve been more curious about the people using it than about the restaurants on Yemeksepeti. The reason is the muhtars. Not only does it show who a neighbourhood’s muhtar is, but it also shows their recent orders and what other participants are doing on Yemeksepeti. The muhtar feature provides the basic social-proof mechanism that Yemeksepeti needed. It helps greatly with making faster decisions and increases the credibility of the restaurants’ scores. (People score a restaurant after a delivery, similar to scoring an Uber driver.)
The Muhtar feature also paves the way for Yemeksepeti to introduce its own version of A2A. I don’t know if they plan to do this (although it’s one of the ideas we presented to them four years ago), but they could surface experts who help others answer the toughest of all questions: “What should I eat?”
That’s the power of gamification. By introducing competition (or collaboration, as we saw with Quora), it makes socialization possible on a very large scale without people actually having to know each other.
The effect of the persuasive experience is observable by users and creators.
One of the core components of gamification is quantification of what users do and of the things happening around them. This way, gamification makes everything measurable by nature. Even the tiniest of behaviors are quantified and presented in various ways, sometimes as raw data, other times as points, levels or progress bars. Let’s look at some examples.
Example: Twitter
Everything, including followers, moments, likes and retweets, is quantified and put front and center.
Example: Quora and Medium
Medium stats (View large version49)
Medium and Quora are very different in how people create content, but in the end, it is content they create. That’s why it is not surprising to see that almost identical statistics are provided.
One by one, we saw how the six components of mass interpersonal persuasion relate to gamification, with examples. I chose well-known examples so that they would be easier to understand and relate to. However, I realize that this makes gamification design intimidating. You might be thinking, “Of course, Quora would do that — they have all of these great designers,” or, “Obviously, Nike would succeed — they have all of those technologies and tools”. Perhaps also, “What does MIP have to do with growth?”. Take a look at this:
Let’s go back to the fall of 2007 — a time when there was no WhatsApp, Instagram or Snapchat, when Twitter was a one-year-old baby, when Facebook announced its Platform. When BJ Fogg heard about Platform, he decided to start a new course to apply MIP principles to Facebook and measure the impact of the application of those principles. Grading was based on metrics on the Platform. There was no homework or quizzes. Students were graded based on the number of users they’ve reached and engaged through the apps they’ve built.
The numbers shown in the image above are the results of that course. The students, some of whom had no experience in coding, design or digital marketing, reached 16 million users in 10 weeks. And this happened in 2007. 2007 is the year when the first iPhone was unveiled. Think about it: Some of those apps generated so much revenue (more than $1 million in three months) that even the teaching assistant, Dan Ackerman, dropped out of school. Five of those apps made it to the top-100 apps on Facebook and reached more than 1 million users each.
So, if those students were able to design such successful experiences, why couldn’t you?
(cc, vf, yk, al, il)
FullStory helps you build incredible online experiences by capturing every click, swipe, and scroll, then replaying sessions with pixel-perfect clarity.
In its move to patch a security hole as part of the iOS 10.3 release, Apple has introduced (yet) another redirection mechanism that developers must handle when attempting to implement mobile deep-link routing (i.e. the mechanism to route users to a specific page inside a mobile app, rather than the App Store or app home page).
This redirection instance has introduced additional friction to the app download and reopening process, and data shows that it has decreased conversion rates on iOS 10.3. This post examines the issue in detail and discusses solutions to help developers fix it.
You’ve launched your app and it’s doing well. So, how do you maintain that momentum and ensure that your app keeps gaining in popularity? Read more →1
With iOS 10.3, Apple has gifted the world powerful new features2, as well as fixes for critical security holes. For your typical iPhone user, it’s a really nice upgrade. For a software developer who is responsible for either a mobile website or a native app, it can be a huge pain.
Why? At some point in early 2017, a few enterprising scammers figured out how to hijack iOS Safari3 by abusing the custom URI scheme confirmation alert. This alert prevented user interaction until it was dismissed; so, the result of triggering it in an endless loop was essentially low-tech ransomware. Unfortunately, it was realistic enough to trick many users into paying up. In iOS 10.3, Apple fixed this security hole by changing the confirmation alert into a new non-blocking dialog. It looks like this:
From a user’s perspective, no big deal. For developers, there is a hidden change that has more important implications: the App Store had always received a special exemption from the old version of this alert, but that exemption has now been removed.
A basic deep-linking system for an app has two goals:
Apple’s official deep-linking standard, “universal links,” is designed for the first case. It’s not perfect: Configuration is complicated, and there are many places (Facebook, Twitter and any app using SFSafariViewController
, to name a few) where things don’t “just work.” But the user experience of deep-linking into an app is generally quite good once that app is installed. None of this has changed in iOS 10.3.
It’s the second case where iOS 10.3 makes things complicated. If a user doesn’t have your app installed, they have always ended up in Safari, looking at the web version of that link. You are then responsible for redirecting that user to download the app. Because Apple has not implemented universal links for the App Store, developers have had to rely on a custom URI scheme redirection. And a custom URI scheme redirect on iOS 10.3 now means an alert. Apple even does it this way itself: Just try visiting https://itunes.apple.com/us/app/airbnb/id4016262635 on an iOS 10.3 device, and you’ll run straight into the new confirmation dialog.
Here’s the situation. When a user clicks any link that leads to the App Store, iOS 10.3 will display a modal asking the user whether they’d like to go there. We’ve tested Apple’s appsto.re
short links, full App Store long links, links from attribution providers and deep-linking platforms, and our own Branch-hosted deep links. There is no way around this new alert.
Why is this bad? There are actually two problems:
You can’t avoid the alert. And the reality is that some users will click “Cancel,” either on purpose or by mistake. What you can do is give more context, to help visitors complete their journey if they fall off in the middle. I’m calling this a “second chance” screen, and it looks like this:
Yes, the new iOS 10.3 confirmation dialog is still there. But now we also have a friendly URL in Safari’s address bar, the app logo and name in the background, and a button that users can click to try again:
At Branch9, we pushed the first version of this second-chance screen live for all apps on the Branch platform within hours of discovering this new edge case in iOS 10.3. It has since become a widely adopted solution; here are just a few examples we have seen pop up in the last few weeks from various services:
Making the best of a bad situation, some apps have built custom second-chance screens:
All of these screens are solving the same basic problem: give visitors an escape hatch if they accidentally hit that “Cancel” button. It is still less than ideal, but the result works:
Here is the default template13 we use on the current second-chance screen for all of the apps on Branch’s platform:
The key part of this is the JavaScript snippet at the end:
<script type="text/javascript"> window.onload = function() { window.location = "<% iTunes Store URL %>"; }; </script>
The logic works like this:
However, I wouldn’t personally recommend building this solution yourself; you have better things to do than to constantly fix new edge cases like these from Apple, Google, Facebook, etc. If you’re using a hosted deep-link provider such as Branch or Firebase (with its Dynamic Links), then this edge case is already being handled for you. Attribution tools such as Adjust and AppsFlyer have also built similar workarounds for their paid tracking links.
We wanted to know how much this new confirmation alert actually affects download conversion rates. The Branch platform has millions of link clicks per day, across almost 25,000 apps, so we took a sample of this data from 2 May 2017. Here is what we found:
What does this actually mean? Let’s break it down
Safari does not allow clicks on this new “Cancel” button to be tracked directly. However, Branch can infer the number based on changes to other metrics that we measure, further down the funnel. In our sample, almost 19% of users were clicking it.
The good news is that visitors still want your app — they are just getting confused by this new warning. When we give them another opportunity to click by showing a content preview with a download button, over 5% of our sample continued to install successfully.
Here is the bottom line: This new confirmation dialog is enough of a roadblock that almost a fifth of iOS users press the “Cancel” button. Even with a workaround enabled, the iOS 10.3 installation rate in our sample was about 2.25% lower than on iOS 10.2. Data shows that a second-chance screen helps, but some users still fail to make it all the way through to download.
From a more technical perspective, serving up a screen like this requires returning an HTTP 200 response, serving a page of content and waiting for the client to execute Javascript. The costs of adding just 100 milliseconds in latency are well known16, and sophisticated deep-linking implementations have long since moved to the far more efficient 307 redirection to reduce this redirection delay. Apple’s new iOS 10.3 behavior has broken this option, forcing the ecosystem to fall back on a slower, outdated solution.
Patching the original ransomware-esque custom URI exploit was the right thing for Apple to do, but the App Store is unlike any other platform. It is a core part of the iOS infrastructure. Applying such a flawed UX to a critical platform component is a costly decision.
With the early iOS 11 betas showing no change to this behavior, it seems possible we are stuck with a confirmation alert for the long haul. This makes it even more critical for you to offer your app’s users a fallback option. In the competitive mobile app world, having such an easy way to increase your installations is unheard of and is absolutely worth the small amount of effort it takes.
(al)
Component-based libraries or frameworks such as Vue have given us the wonderful ability to create reusable components1 to be spread throughout their respective application, ensuring that they are consistent, and (hopefully) simplifying how they are used.
In particular, form inputs tend to have plenty of complexity that you’d want to hide in a component, such as custom designs2, labels, validation, help messages, and making sure each of these pieces are in the correct order so that they render correctly.
Are you excited to take advantage of new JavaScript language features but not sure where to start, or how? Read more →3
On top of that though, Vue has a built-in directive called v-model
that simulates 2-way binding by binding a value and capturing input events. If you’re going to build a custom input component, then you’ll definitely want to support the v-model
directive.
Sadly, when I looked around for examples of custom inputs in Vue for radio buttons or checkboxes, they either didn’t take v-model
into consideration at all, or they failed to implement it correctly. There is some decent documentation for custom text inputs4, but since it doesn’t explain customizing radios or checkboxes, we’ll discuss that here.
This tutorial aims to help you…
v-model
works on native inputs, focusing primarily on radios and checkboxesv-model
works on custom components by defaultv-model
works on them nativelyQuick note before we get started: ES2015+ code will be used throughout the code examples. I’ll also be favoring the Single File Component5 syntax over using Vue.component
or new Vue
.
v-model
Work Normally? LinkThe official Vue documentation6 is actually pretty good on this topic, but there are a few minor blind spots. In any case, we’ll be trying to cover it pretty thoroughly here.
In essence, v-model
is just a shorthand directive that gives us 2-way data binding, and the code it is shorthand for depends on what type of input it is being used on.
<input v-model="message" placeholder="edit me"> <p>Message: {{ message }}</p> <!-- OR --> <p>message:</p> <p>{{ message }}</p> <textarea v-model="message" placeholder="add multiple lines"></textarea>
When using a text input
(including types such as email
, number
, etc.) or textarea
, v-model="varName"
is equivalent to :value="varName" @input="e => varName = e.target.value"
. This means that the value of the input is set to varName
after each update to the input varName
is updated to the value of the input. A normal select
element will act like this too, though a multiple
select will be different.
So, what about radio buttons?
<input type="radio" value="One" v-model="picked"> <input type="radio" value="Two" v-model="picked"> <span>Picked: {{ picked }}</span>
This is equivalent to:
<input type="radio" value="One" :checked="picked == 'One'" @change="e => picked = e.target.value"> <input type="radio" value="Two" :checked="picked == 'Two'" @change="e => picked = e.target.value"> <span>Picked: {{ picked }}</span>
Note how v-model
isn’t even touching value
anymore. It’s still doing the same thing in the change
event handler (though it was changed to change
instead of input
), but now it’s determining whether checked
should be true or false depending on whether picked
is the same as the value of that radio button.
Checkboxes are a bit more difficult to talk about because they have two different behaviors depending on whether there is only a single checkbox with a given v-model
or multiple.
If you are using a single checkbox, v-model
will treat it like a boolean and ignore the value
.
<input type="checkbox" value="foo" v-model="isChecked">
is the same as…
<input type="checkbox" value="foo" :checked="!!isChecked" @change="e => isChecked = e.target.checked">
If you want it to be something other than true
and false
, you can use the true-value
and false-value
attribute, which control what values your model will be set to when the checkbox is checked or not.
<input type="checkbox" value="foo" v-model="isChecked" true-value="1" false-value="0">
is the same as…
<input type="checkbox" value="foo" :checked="isChecked == '1'" @change="e => isChecked = e.target.checked ? '1' : '0'">
That’s pretty much it for single-checkbox examples. If you have multiple checkboxes that share a model, then those checkboxes will fill an array with values of all the checkboxes that are checked, but make sure the model that you pass in is already an array or you’ll get some odd behavior. Also, the true-value
and false-value
attributes no longer affect anything.
<template> <div> <input type="checkbox" value="foo" v-model="checkedVals"> <input type="checkbox" value="bar" v-model="checkedVals"> <input type="checkbox" value="baz" v-model="checkedVals"> </div> </template> <script> export default { data: () => ({ checkedVals: ['bar'] }) } </script>
The equivalent is a bit more difficult to keep inside the template, so I’ll move some of the logic to methods on the component:
<template> <div> <input type="checkbox" value="foo" v-model="checkedVals"> <input type="checkbox" value="bar" v-model="checkedVals"> <input type="checkbox" value="baz" v-model="checkedVals"> </div> </template> <script> export default { data() { return { checkedVals: ['bar'] } }, methods: { shouldBeChecked(val) { return this.checkedVals.includes(val) }, updateVals(e) { let isChecked = e.target.checked let val = e.target.value if (isChecked) { this.checkedVals.push(val) } else { this.checkVals.splice(this.checkedVals.indexOf(val), 1) } } } } </script>
That’s a lot more complicated than what we’ve seen before, but if you break it down, it’s not too bad. shouldBeChecked
is true
when that checkbox’s value is included in the array and false
if it isn’t. updateVals
adds the checkbox’s value to the array when it gets checked and removes it when it gets unchecked.
v-model
Work On Components? LinkSince Vue doesn’t know how your component is supposed to work, or if it’s trying to act as a replacement for a certain type of input, it treats all components the same with regards to v-model
. It actually works the exact same way as it does for text inputs, except that in the event handler, it doesn’t expect an event object to be passed to it, rather it expects the value to be passed straight to it. So…
<my-custom-component v-model="myProperty" />
…is the same thing as…
<my-custom-component :value="myProperty" @input="val => myProperty = val" />
A component can change this to a small extent using the model
property:
export default { name: 'my-custom-component', model: { prop: 'foo', event: 'bar' }, // ... }
v-model
will look at these properties and instead of using the value
attribute, it’ll use the attribute you specify in prop
and instead of listening for the input
event, it’ll use the event you specified in event
. So the above my-custom-component
example would actually expand out to the following:
<my-custom-component :foo="myProperty" @bar="val => myProperty = val" />
This is nice, but if we’re making a custom radio or checkbox, this doesn’t work very well. With some work, though, we can move the logic that v-model
uses on radios and checkboxes inside our custom components.
v-model
On Custom Radios LinkCompared to a checkbox, custom radios are quite simple. Here’s a very basic custom radio that I build that just wraps the input
in a label and accepts a label
property to add the label text.
<template> <label> <input type="radio" :checked="shouldBeChecked" :value="value" @change="updateInput"> {{ label }} </label> </template> <script> export default { model: { prop: 'modelValue', event: 'change' }, props: { value: { type: String, }, modelValue: { default: "" }, label: { type: String, required: true }, }, computed: { shouldBeChecked() { return this.modelValue == this.value } } methods: { updateInput() { this.$emit('change', this.value) } } } </script>
Note: I only included props
that are helpful for explaining how these should work with v-model
, but input
tags can take advantage of several other attributes (such as name
or disabled
), so make sure you create all of the props
you’ll need and pass them on to input
. You’ll also want to consider accessibility by adding WAI-ARIA attributes7, as well as using slots8 for adding content rather than props like I did here with label
.
You may think that since I didn’t include name
in this example, a group of radios wouldn’t actually sync up with one another. Actually the updating of the model will in turn update the other radio buttons that share that model, so they don’t need to share a name like they do in plain HTML forms as long as they share the same model.
v-model
On Custom Checkboxes LinkMaking custom checkboxes is noticeably more complex than the radio buttons, primarily because we have to support two different use cases: a single true/false checkbox (that may or may not use true-value
and/or false-value
) and multiple checkboxes that combine all the checked values into an array.
So how do we determine which use case it is? You might think that we need to determine if there are other checkboxes with the same name
attribute, but that’s not actually what Vue’s built-in system uses. Just like the radios, Vue doesn’t take the name
attribute into consideration at all. That’s only used when natively submitting a form. So then you might think it determines it based on whether there are other checkboxes that share the same model, but that’s not it either. It’s determined by whether or not the model is an array. That’s it.
So the code will be structured similarly to the custom radio button’s code, but inside shouldBeChecked
and updateInput
the logic will split depending on whether or not modelValue
is an array.
<template> <label> <input type="checkbox" :checked="shouldBeChecked" :value="value" @change="updateInput"> {{ label }} </label> </template> <script> export default { model: { prop: 'modelValue', event: 'change' }, props: { value: { type: String, }, modelValue: { default: false }, label: { type: String, required: true }, // We set `true-value` and `false-value` to the default true and false so // we can always use them instead of checking whether or not they are set. // Also can use camelCase here, but hyphen-separating the attribute name // when using the component will still work trueValue: { default: true }, falseValue: { default: false } }, computed: { shouldBeChecked() { if (this.modelValue instanceof Array) { return this.modelValue.includes(this.value) } // Note that `true-value` and `false-value` are camelCase in the JS return this.modelValue === this.trueValue } }, methods: { updateInput(event) { let isChecked = event.target.checked if (this.modelValue instanceof Array) { let newValue = [...this.modelValue] if (isChecked) { newValue.push(this.value) } else { newValue.splice(newValue.indexOf(this.value), 1) } this.$emit('change', newValue) } else { this.$emit('change', isChecked ? this.trueValue : this.falseValue) } } } } </script>
And there you have it. It may be better, though, to split this into two different components: one for handling the single true/false toggle and one for use in lists of options. That would allow it to more closely follow the Single-Responsibility Principle, but if you’re looking for a drop-in replacement to checkboxes, this is what you’re looking for (plus the addition of all the other useful attributes and custom features you might want).
There’s plenty more to learn about Custom Inputs, Vue Components, and Vue in general. I recommend giving some of these resources a look-through.
(rb, vf, al, il)
pdf-bot * Cboard * Electron Webpack Dashboard * WebGL Fluid Simulation * Interface Font * SVG Gradient Wave Ge…
Could there be a better way to welcome the new month as with a tidy desktop and a fresh wallpaper? Well, we’ve got you covered. To help you start into August freshly inspired, artists and designers from across the globe once again1 challenged their artistic skills to create unique desktop wallpapers for you to indulge in — wallpapers that are a bit more distinctive as the usual crowd.
All wallpapers in this collection can be downloaded for free and come in versions with and without a calendar — to keep your deadlines always in sight or to stick to your favorite wallpaper even after the month has ended. A big thank-you to everyone who shared their artworks with us! Now it’s up to you to decide which one will become your August companion.
Please note that:
“Many people find August one of the happiest months of the year because of holidays. You can spend days sunbathing, swimming, birdwatching, listening to their joyful chirping, and indulging in sheer summer bliss. August 8th is also known as the Happiness Happens Day, so make it worthwhile.” — Designed by PopArt Studio7 from Serbia.
Designed by BootstrapDash52 from India.
“During bright summer days, while wandering around unfamiliar places, it is finally forgotten that one of the biggest human inventions is time itself, future becomes the past, past becomes the present and there are no earthly boundaries, just air.” — Designed by Ana Masnikosa97 from Belgrade, Serbia.
Designed by UrbanUI140 from India.
“I love the summer nights and the sounds of the sea, the crickets, the music of some nice party.” — Designed by Maria Karapaunova181 from Bulgaria.
“Melon Day (second Sunday in August) is an annual national holiday in Turkmenistan devoted to festivities to celebrate the country’s muskmelon. Another reason for me to create this wallpaper is that melons are just awesome!” — Designed by Melissa Bogemans226 from Belgium.
“The best rides of our lives come along only once in a while. Don’t wait for it. Sometimes you just have to ride the wave you’re given!” — Designed by PlusCharts269 from India.
“La Tomatina is a food fight festival held on the last Wednesday of August each year in the town of Bunol near Valencia in Spain. Thousands and thousands of people come from all corners of the world to participate in La Tomatina, which is known as the ‘biggest food fight’, where more than one hundred metric tons of over-ripe tomatoes are thrown on each other in the streets.” — Designed by Suman Sil314 from India.
“When I think of August I think of vacation. August is the last month of summer break in Belgium so that’s why I like travelling then to enjoy that last month. I like visiting countries where the weather is pretty hot and that’s why I decided to draw a wallpaper where you are basically on the road to the sun.” — Designed by Senne Mommens345 from Belgium.
“In Melbourne it is the last month of quite a cool winter so we are looking forward to some warmer days to come.” — Designed by Tazi360 from Australia.
“Let us take a pledge to save these endangered species and create a world that is safe for them to live and perish just like all creatures.” — Designed by Acodez IT Solutions385 from India.
“The warm, clear summer nights make me notice the stars more — that’s what inspired this space-themed design!” — Designed by James Mitchell430 from the United Kingdom.
“Moments in life comes with hiccups and hitches, and so it remains unpredictable all along. There are always things you must meet in your day to day life, being afraid or running backward won’t take those away from you. In a nutshell, it’s a box full of new challenges, new thrills, new problems and new solutions, and so what we are left with is our perspective to deal with it! Face each moment until it concludes to be your last, with valor, attitude and a sturdy charm. Meeting the situations are mandatory, the thing that counts is how you face it, be yourself!” — Designed by Sweans451 from London.
“Photography is a way of feeling, of touching, of loving. What you have caught on film is captured forever. It remembers little things, long after you have forgotten everything. Applauding all the photographers who are capable of capturing what your eye cannot see on this World Photography Day.” — Designed by Areva Digital496 from India.
“Liqiu signifies the beginning of autumn in East Asian cultures. After entering the Liqiu, the mountains in Eastern Taiwan’s East Rift Valley are covered in a sea of golden flowers, very beautiful. The production season for high-mountain daylilies is in August. Chihke Mountain, in Yuli Township, and Sixty-Stone Mountain, in Fuli Township, which are both located in Hualien County, are two of the country’s three high-mountain daylily production areas.” — Designed by Hong, Zi-Qing537 from Taiwan.
“Janmashtami – day The Lord Krishna was born —, an important Hindu Festival which is celebrated worldwide. The idea was to create the Lord Krishna’s playing flute persona, in the minimalist design form.” — Designed by Damn Perfect556 from Jaipur, India.
“Buon giorno! (That’s ‘hello’ in Italian.) My name is Anopheles and yes, I’m a member of the much-feared Malaria Mafia. I’m sure you would have heard of us. I’ve something to tell you, lean closer… You know, every 30 seconds, a person dies from malaria and yes, we alone are responsible for that! No matter how long your clothing, no matter how secure your mosquito net, and no matter how high you climb, we will find you, suck your blood and cover your body in enormous, itchy welts! Wait a minute; you are going to celebrate the World Mosquito Day on August 20th? No worries, we will be there with you, as your beating heart!” — Designed by IPIX Technologies601 from India.
“Visitors to DC’s iconic Washington Monument in the sweltering August heat might wish it were a giant popsicle. For now, we’ll just imagine it that way. Here’s hoping everyone beats the heat!” — Designed by The Hannon Group642 from Washington, DC.
“August is the month of respect. Give respect, Take respect!” — Designed by Alrais Labs669 from Dubai.
Designed by Metrovista714 from Orlando, FL.
“In a world that get’s more divided each day, it is really important to understand that even if we are different we could all play together and have fun.” — Designed by Maria Keller741 from Mexico.
“Some colors are energetic, while others are much more calming and relaxing by nature. This summer, add some color to your life!” — Designed by StarAdmin Free Bootstrap Admin Template794 from India.
“One of my favourite books, ‘The Railway Children’, inspired me to create this wallpaper. August the 15th marks the birthday of E. Nesbit who wrote this brilliant classic! I even included an inspirational quote from the book.” — Designed by Safia Begum821 from the United Kingdom.
“This will be my final semester of grad school, and the last time August will mean back to school for me.” — Designed by Caitey Kennedy840 from the United States.
Please note that we respect and carefully consider the ideas and motivation behind each and every artist’s work. This is why we give all artists the full freedom to explore their creativity and express emotions and experience throughout their works. This is also why the themes of the wallpapers weren’t anyhow influenced by us, but rather designed from scratch by the artists themselves.
A big thank you to all designers for their participation. Join in next month863!
What’s your favorite theme or wallpaper for this month? Please let us know in the comment section below.
More than 10,000 teams already get organized with Dapulse, the next generation visual project management tool.
Do you ever wish you had a time machine? I certainly do, but not for the usual reasons. I want a time machine so I can go back and have a frank conversation with my younger self. I’ll let you in on a bit of a secret: My younger self was an idiot!
I have been working on the web for over 22 years now, and I feel like I wasted so many of those years. If only I could go back and share a few hard truths with myself at the start of my career. Unfortunately, I cannot, but I can share that advice with you.
Admittedly, you are almost certainly not as idiotic as I was. But hopefully, there will be something in this advice that inspires you.
Speaking of inspiration, that leads me nicely into my first piece of wisdom!
I used to be a dedicated follower of fashion who wasted so much time looking at other “cool” websites and browsing galleries of inspirational websites. My design style would morph to embrace the latest trends, from Web 2.0 to hero banners.
The result of this was bland “me too” design. But worst of all, it never put the user first. It was all about making something look good in my portfolio.
It was such a waste because so much inspiration is all around us: great books on classic print design, architectural trends, even airport signage (a personal obsession of mine).
Don’t make my mistakes. You don’t even have the luxury of my excuses. With CSS grid3, the possibilities are endless, and we should all embrace them.
On the subject of latest trends, that brings me to my next transgression: obsessing over tools.
We’ve wasted hours arguing over what tool is best. Should we code in PHP or classic ASP? (Yes, I am that old.) Can I be a “proper” web designer and code in Dreamweaver? Which content management systems should we use? The list went on.
Some tool or other would become trendy for whatever reason, and we would all jump on the bandwagon, until the next one emerged, and we jumped to that after an even more furious debate.
I see the same today: arguments over frameworks4 and whether we should embrace Angular or React. I don’t follow these discussions anymore because somewhere along the line I realized something: There is no single answer.
A lot of these choices come down to personal preference or the requirements of the individual client. Remain flexible and open to change. If you don’t, you’ll go the way of Flash developers.
All of that time I wasted arguing about tools would have been so much better spent elsewhere, like on improving my soft skills.
I was an insufferable know-it-all when I was young. I always had the answers and always knew a better way to do something. I am sure you are not like that, although, let’s be honest, how would you know if you were? I certainly had no idea how irritating I was, despite the warning signs.
For a start, I found myself constantly arguing with everybody. Everything seemed like a battle because nobody around me “got it.” In hindsight, that was because I was too busy irritating everybody to take the time to explain things properly. But at the time, it just felt like everybody else was stupid.
I wish I had realized how weak I was in this area. Perhaps then I would have invested time and energy in improving how I worked alongside other people. Maybe I would have listened more and put the same effort into understanding my colleagues as I did my users.
I am not suggesting I should have done this necessarily to be a good man (trust me, I am not now). Instead, I should have done this because it would have made my life so much easier. I wasted endless time arguing and alienating people, people I needed on my side to do my job. It was incredibly frustrating.
If I had developed that skill of working with people earlier, it would have also allowed me to push beyond the confines of my role.
I confess that, for many years, I was a bit of a job’s worth. I was a designer, and I spent much of my working life complaining because other people weren’t doing their jobs properly. Clients failed to deliver copy, developers didn’t implement my designs correctly, and project managers were always putting unrealistic constraints on me.
To be fair to my younger self, these were all real problems. But I did nothing but moan about them. I made no effort to help my colleagues fix these issues. I never questioned why the client was failing to deliver content or why the project manager seemed so unreasonable? I didn’t bother to understand the constraints they faced.
When I did eventually wake up and start paying attention, I discovered a bigger world. I found out just how interconnected digital and the user experience are, and how many things beyond the screen influence the experience.
I learned so much over that time, and you can, too. Take the time to understand the roles of those around you. Understand their challenges and constraints. Understand their perspectives and motivations. This will not only improve your working relationship, but make you better at your job, too.
If you are a designer, this will enhance your designs, making them more useful in the “real world.” If you are a developer, you will understand the challenges users face and the impact you have on the user experience11. And so it goes on.
Ultimately, this will make you better at your job and hopefully progress your career. But a successful career is about more than being good at your job.
You could be the best designer or developer in the world, but if nobody has heard of you, you will have little success. That probably isn’t right or fair, but that is the reality.
I’ll be honest with you: Many people are far better at their jobs than me. But I speak all around the world, write books and have built a significant following, not because I am good at what I do, but because I put myself out there.
But it took me so long to realize that. I wasted years moaning about how it was unfair that other people got to write and speak and how my ideas were just as good as theirs.
Eventually, it twigged that I didn’t need anybody’s permission to start sharing my thoughts. I could write on a blog without a publisher and speak on a podcast without a conference.
You can, too. Not only that, you should! If you are not sharing what you have learned, you are invisible, and that will hamper your career.
You might feel you have nothing new to say. Don’t worry, just share what you have learned. There will always be people who haven’t learned those lessons yet.
You might feel nobody is listening. Again, don’t worry. If you persevere, eventually people will start paying attention. I’ll let you in on a secret: Quality is not the number one reason for success. Consistency is. Even second-rate content will draw attention if you release it regularly enough.
Put yourself out there, in whatever way you choose. It will enable you to build contacts in the industry. That will help you avoid the last mistake my younger self-made: wasting too many years working for appalling bosses.
I worked for some truly nasty people, ranging from the incompetent to the criminal. Two ended up in prison, and the only good guy I ever worked for died of a heart attack due to stress!
I wasted years working for these people, years of them undervaluing my work and failing to invest in enabling me to do it better. Admittedly, I could be a bit of an idiot, as we have already established. But even with hindsight, these people were terrible. Unfortunately, apathy and fear prevented me from moving on.
Don’t make my mistake. There is no need. We are much in demand. Getting good digital staff is incredibly challenging, and you owe no loyalty to a boss who doesn’t value your expertise.
Instead, find a company that is going to nurture you and help you grow in your career. I’ll be honest: I never achieved that. I never had a mentor or somebody to teach me. I stumbled my way through my career, and I think I am the poorer for it. So, don’t settle. You deserve better, and loads of great jobs are out there.
(al)