Recently, there has been a proliferation of virtual reality (VR) web browsers and VR capabilities added to traditional browsers. In this article, we’ll look at the state of browsers in VR and the state of VR on the web via the WebVR APIs.
The web community has experimented with VR before, with VRML, but now WebVR takes a new approach to VR, one more suited to the modern web. We’ve accelerated 3D on the web since 2011 with the release of WebGL. Now the web can handle VR thanks to new web APIs that take advantage of VR hardware using WebGL.
These APIs enable WebGL content to be displayed in 3D with a VR headset. They also provide headset and controller tracking information to give the user presence in the virtual world.
WebVR was first developed in 2014 at Mozilla. In 2016, an earlier version of the standard was available for desktop Chrome, Firefox and Samsung’s virtual reality web browser: Samsung Internet for Gear VR.
These days, the standard is incredibly well supported on phones and desktop computers for almost all major headsets.
Mozilla Firefox
Google Chrome
Microsoft Edge
Oculus Browser
Samsung Internet
Safari on iOS
HTC Vive
Developer Edition
Chromium Experimental build
–
–
–
–
Oculus Rift
Developer Edition
Chromium Experimental build
–
–
–
–
Windows Mixed Reality
–
–
Windows 10 with Creators Update and Developer Mode enabled
WebVR support as of June 2017 (Source: Mozilla Blog2)
The WebVR standards are worked on in the open, and they represent a collaboration between Mozilla, Google, Samsung, Oculus, Microsoft and, recently, Apple.
This means that a single website that uses WebVR can make an immersive scene and deliver it to all major VR platforms at once, desktop and mobile!
The web’s ability to handle VR content allows one to easily share a VR experience in a URL and view it in the browser without the complicated app stores and long downloading times associated with native VR.
WebVR APIs demonstrated in Samsung Internet for Gear VR
Additional VR-Related Web APIs In Samsung Internet Link
These APIs are not part of the WebVR API but are useful for viewing immersive content on traditional websites in an immersive web browser without needing to use WebGL.
These APIs are being developed for Samsung Internet for Gear VR. We hope they will be picked up by other browsers and standardized.
This involves the ability to play panoramic videos (monoscopic and stereoscopic) immersively by setting the type="dimension=360;" attribute on a video tag. These videos also get enhanced in Samsung Internet 5.0 by allowing the user to pan around within the video using their fingertips.
Possible values:
dimension=3d-lr: side-by-side 3D video
dimension=3d-tb: top-to-bottom 3D video
dimension=360: 360-degree video
dimension=360-lr: side-by-side 3D 360-degree video
dimension=360-tb: top-to-bottom 3D 360-degree video
dimension=180: 180-degree video
dimension=180-lr: side-by-side 3D 180-degree video
dimension=180-tb: top-to-bottom 3D 180-degree video
Another API available in Samsung Internet for Gear VR is a JavaScript API for changing the background image of the VR web browser to one of the developer’s choosing.
Your traditional 2D website will still be visible, but the surroundings will be set to one that matches the environment of your website.
WebVR is a set of cross-browser JavaScript APIs that provide a variety of VR-related utilities to place the user in an immersive environment generated using WebGL.
By providing side-by-side rendered 3D images, these APIs will handle all of the complexity involved in displaying an undistorted stereoscopic 3D image to the user.
I won’t go into the details of implementing the standard here because the standard is still changing. Most users will never need to deal with them directly, because WebGL tools and libraries often handle the WebVR APIs for you.
The current version of the API is known internally as version 1.1. Version 2.0 will change some of the method names and remove some unused methods. It will also add some additional functionality for some hardware and use cases which were not anticipated during the first iteration of the API.
Essentially, the WebVR API provides the following:
Headset tracking allows the user to look around in the virtual environment. Frame interpolation is built in, so that it is always tracking the user’s head, even if you skip the occasional frame.
Pass-through camera, demonstrating head tracking in VR
“Six degrees of freedom” and “three degrees of freedom” controller support allows controllers like those of the HTC Vive and the Gear VR to work in virtual reality. It allows the user to use their hands to interact with the virtual environment.
Information is given about how the headset needs the 3D information rendered, such as the field of view and how to position the render for each eye on the canvas.
A new headset-specific requestAnimationFrame is synced to the refresh rate of the display in the headset.
There is a method of submitting the rendered frames to the headset in the form of a WebGL-enabled canvas element.
7 Diagram describing the loop for VR. The headset provides position and rotation data; the developer uses this data to render the scene from the user’s point of view, then sends the rendered data to the headset to be distorted and displayed to the user. (View large version8)
What Does It Mean To Build A WebVR Immersive Experience? Link
Surprisingly, building a virtual reality website raises many of the same problems as building a good mobile website or progressive web app.
One of the biggest problems being tackled on the web today is network performance, which is important because:
user attention spans are shrinking,
networks are getting more congested,
websites are getting bigger than ever.
WebGL and WebVR websites are certainly no exception to size. They can get very large if one is not careful!
Right now, VR content has an edge over traditional content because it is novel and interesting enough that users will likely wait a bit longer to have a go. Still, getting your 3D experience started in under a few seconds is extremely important. Users are impatient and only getting more so.
Before your VR-capable website has loaded, it is just a 2D website and a promise of cool things to come.
My advice here is to not preload everything. Instead load just enough for the user to get started, then dynamically load and start caching the rest. This behavior should be familiar if you have read about Google’s PRPL pattern9.
Even just showing a blurred 360 skybox and some low-poly content, allowing the user to look around, will buy you precious seconds of engagement to bring in additional content and to bootstrap an engaging experience.
Showing something basic but fast is far better than losing the user because they’ve gotten bored waiting for a loading bar to complete.
But bear in mind, network operations can be CPU-intensive and block the main thread. This could give the user a bad experience if it happens a lot, so it is a fine line to walk.
Perhaps one or two very intensive assets need to be preloaded to avoid breaking the experience. However, if you have so many that it is taking a long time to start, then perhaps it’s worth thinking about finding a more performant alternative.
Making good use of a service worker and the Cache API10 to cache static assets for fast return visits is a great way to keep users coming back for more.
The two main platforms for VR are polar opposites: high-end desktop computers with advanced controllers, and mid- to high-level mobile phones, which might have only a single rotation-tracked controller or no controller at all!
11 A photo of an HTC Vive with a position-tracking controller, Samsung Gear VR, Google Daydream and a pile of Google Cardboards in the back. (View large version12)
This presents us with two challenges:
maintaining a consistent frame rate across platforms with wildly differing performance capabilities,
presenting a user-friendly experience across VR devices with a wide range of inputs.
Phones have by far the largest reach due to the popularity of Gear VR and Daydream and the cheap price and high availability of the Google Cardboard headsets.
Below, I have described some typical controller configurations. You don’t need to support them all, but handling the “no controller” situation as a baseline and also supporting another controller option if applicable will allow everyone to experience something. Supporting all controller configurations would be nice, but in my opinion is not a reasonable expectation.
14 Web-compatible controllers with increasing levels of immersion. From left to right: Gaze-Based Tracking, Traditional Gaming Controllers, Rotation-Tracked Controllers, Position- and Rotation-Tracked Controllers, Full Gesture Recognition. (Eye illustration: Wikimedia Commons) (View large version15)
Interaction mechanism
How it increases engagement
Hardware and support
Gaze-based interaction
Look at something to use it. (Most users will require this.)
Cardboard-like headsets; users with limited mobility for controllers
As with progressive enhancement on the web, supporting all levels of hardware does not mean you need to deliver the same experience to all.
A user with two fully tracked hands in the virtual world will have a much more engaging experience and should not be limited by being delivered the same experience as someone with no controller.
For example, a VR app in which you produce VR artwork could use tracked controllers to produce art on high-powered machines; on mobile, a user would be able to view this art in VR but be unable to edit it.
Another example would be a networked VR multiplayer game in which players use tracked controllers to play the game; a mobile viewer could watch it and use gazed-based interactions to choose different points of view.
Like modern web design, the key is to design mobile-first. As you build your scene, regularly test it on real mid-level smartphones with no controllers to ensure it will work for the majority of your users.
WebVR allows you to target both platforms at once. However, delivering the same content to both could result in mobile devices struggling or desktops not being used to their full potential.
There is no problem having very well-performing graphics. A stylized low-poly appearance can look fantastic and render very quickly.
To upgrade graphics, one solution is to provide options for graphical quality before the user starts using WebVR. If the user requests high quality, then start downloading the large or difficult-to-render graphics.
Something more difficult but more seamless would be to start on the lowest graphical setting and detect how well the device is performing using commands such as requestIdleCallback or measure how long the rendering takes. If the device is running well, then maybe increase the graphics settings. If frames start getting skipped, then dynamically reduce them.
When you are upgrading your scene, you might decide to do a few things:
increase draw distance,
download and use high-resolution models or textures,
use more complex shaders.
This will ensure that users on mobile and desktop get the best possible experience. For most use cases, though, it is probably fine if desktop users get the mobile experience, because you can guarantee it will maintain a great frame rate on the desktop if it also does on mobile.
After all, there is more to a great scene than visual fidelity. Highly stylized games such as Team Fortress 2 still look great today, whereas “realistic” games from the same era have not aged so well.
A great scene should have a well-designed graphical style, with bold colors and strong silhouettes. This will help low-power and low-resolution devices look good, but will also still look great on desktop devices, needing only a bit of extra polish.
In VR, bear in mind that most users will have the equivalent of poor eyesight. So, minimize text or anything that will cause the user to strain to see something.
The web is trying to solve some of the problems currently facing VR.
One of the biggest issues is that the user has to make a big commitment for a one-off experience that they might not want to come back to.
In native mobile and desktop VR, one has to download the app from an app store such as the Oculus store on Gear VR or from Steam for the HTC Vive or Oculus Rift.
This app store pattern lends itself well to expensive video games, in which users have already invested some money and so are going to return again and again. But for a one-off experience such as shopping, viewing a movie or trying a new social platform, this can be a high barrier to entry.
Users tend to be put off by the idea of having apps lying around on their device, taking up space or using up a large amount of their data allowance to download — especially users whose mobile devices have limited disk space or network data caps.
On the web, once the user leaves a page, they don’t have to worry about content hanging around, because the browser will clean it up if space is needed. If space is available, the developer can cache content on the device for when the user returns, letting the developer have their cake and eat it, too.
Of course, this requires the developer to make VR websites that are not stored as a single giant bundle; otherwise, the gains the web can provide will have been lost.
By delivering VR assets dynamically and separately like those of a web page, you can take advantage of all of the smart caching that the web can provide from the CDN, all the way down to the HTTP cache and the service worker’s Cache API on the device.
Furthermore, the user can jump right into your VR experience with very little waiting.
A highly optimized WebVR website should render the first frame within a single second of the user landing on the website — totally cutting out any lengthy initial downloads or app stores, and massively increasing engagement.
An experience can be shared with nothing but a URL, which can be distributed by social media or email or even written on a wall or displayed on a TV, making it much more likely that your VR content will go viral due to its low barrier to entry.
One feature that many WebVR websites have is that, before entering VR, the user can view and interact with the scene on their 2D display. The view will often rotate with the phone, giving the appearance of a magical window into a virtual space.
This magical window is a powerful pattern. It gives the user a preview of the VR scene without the need for a VR headset. This is great for when they don’t have their VR gear on hand or are on public transportation and don’t want to wear VR equipment in public.
Once the user has gotten a taste, they will be encouraged to bookmark your website to try it in VR at a time more suitable for them.
The Web Has High-Level Interfaces to Low-Level APIs, Bringing Advanced Technology to Any Developer Link
Many web APIs you may have heard of or used have become massively more relevant in a VR context:
WebSockets
These are used to stream text and binary data to a server in real time. For VR, they can be used to sync hundreds of users in real time to enjoy a shared experienced and to view avatars representing each other. I recently produced an open-source demo in which I did this live for over 150 users at a conference17.
WebRTC
To expand upon shared VR, one can also use WebRTC to maintain peer-to-peer connections for binary data and video and audio streaming. This can be used to allow two avatars to voice chat or to sync the position and posture of a VR avatar without going through a central server. This can be used to connect six to eight users at a time.
WebAudio
WebAudio18 is one of the most surprisingly powerful APIs. The browser contains everything you need for audio manipulation and analysis. One can even use a panner node for 3D spatial audio in VR. For producing virtual environments that have an immersive feel, WebAudio is more important than ever.
SpeechRecognition
Newer browsers contain a built-in speech recognition engine! This is useful for giving commands and entering text when a real or virtual keyboard is difficult or unwieldy. Samsung has built a great example for VR19.
What Effect Might VR Have On The Web In The Long Term? Link
VR has already had an effect on the web platform; the WebVR APIs have been implemented across multiple platforms; and there are discussions about creating a WebVR working group within the W3C.
VR is already going mainstream, and with augmented-reality and mixed-reality devices starting to enter the consumer realm, it is important that the web be ready to take advantage of the new platforms.
WebVR as we know it today relies entirely on WebGL. Optimizing for WebGL will mean that browser vendors will have to look at taking advantage of hardware optimizations to increase rendering speed towards that of a natively compiled app. Speed is important, because dropping frames in VR can have disastrous effects, even to the point of making the user ill!
WebGL 2 will soon be reaching stable browsers. Version 2 brings WebGL closer to the OpenGL ES 3.0 specification. Greater visual fidelity and faster ways to do advanced graphics will make VR truly an incredible visual experience.
WebAudio might be required to produce more accurate 3D audio transformations, known as head-related transfer functions, to better reproduce the high-quality 3D audio required by big-budget productions. Accurate 3D audio will be essential to delivering high-quality immersive video content such as 360-degree movies and immersive audio experiences.
Scripting on the web would benefit from significant performance improvements as well. A number of JavaScript APIs are in the works that can be used to increase performance on the web.
JavaScript itself can be optimized and precompiled. Another option is to compile other languages to WebAssembly (WASM). This can speed things up across the board, providing a bundle that is smaller to download and faster to parse and execute. If used wisely and modularly, WASM could be used to make the core rendering engine of a WebVR experience, which we could still interact with using JavaScript as we do today.
The browser can make use of web workers to enable calculations that do not block the main thread. This is good because the main thread is primarily used for rendering. Web workers are useful for manipulating large amounts of data with CPU-intensive calculations such as physics engines. By isolating the calculations from the main thread in this way, they are less likely to trigger frame drops.
Unfortunately, some cost is associated with sending data to and from web workers to use them in the main thread. This is alleviated partially by transferable objects. Transferable objects such as ArrayBuffers allow you to change the owner of the object, but handling the transferring of this object can be difficult and error-prone if a mistake is made. (I’ve written about using ArrayBuffers on the web20.)
A new API called SharedArrayBuffer will allow multiple workers to share the same ArrayBuffer, which is useful for this case.
On the topic of workers, part of the issue is that, right now, the thread that renders the web page also needs to be used to render the WebGL scene. So, any side effects of other code that you run on the main thread, such as garbage collection or CPU-bound functions, could cause frames to be dropped.
OffscreenCanvas enables rendering to be performed in a web worker. This will help the very important and sensitive rendering loop to be isolated from the other threads.
The other important rendering use case is prerecorded 2D and 3D video. These can be used as textures in WebGL. But they lack fine-grained control. Just as we have an audio element and an AudioContext in JavaScript, we will need to add a videoContext to enable performant video manipulation to assist with playing 360-degree videos in 3D.
An area where VR currently lies at odds with the web as a whole is the rendering of documents. Displaying documents is the core functionality of the web platform, but displaying a document in WebGL is nigh impossible without some very slow, very clever rerendering.
It would be great to bring them together by having the browser expose rendered DOM content to WebGL. This would enable us to take advantage of the web’s power for 2D interfaces, but it could potentially be a security and privacy risk!
WebGL-based VR doesn’t necessarily have to be the future of VR on the web. Having to perform even the simplest use case for WebVR in WebGL seems shortsighted at best and potentially fatal for VR on the web in the long run.
Part of the strength of the web is that HTML is a declarative language. Browsers can interpret the language according to the platform. You won’t see the exact same website on your desktop computer as you would on your phone or TV. VR is yet another platform in the variety of media to experience the web.
By being declarative, like HTML or CSS, VR on the web could automatically handle rendering to balance rendering speed and visual fidelity. A high-end computer could use advanced shaders and detailed models; a low-power mobile phone could automatically use simple shading and low-poly models — much like the way the picture element can download images that are of the correct resolution and then crop for the given device.
HTML could be extended to include some common VR use cases, such as playing 360-degree and 3D videos and images, displaying 3D models, and moving bits of a web page outside of the 2D viewport into 3D space.
Samsung has started to look at some of these use cases in the web browser, Samsung Internet for Gear VR.
It has built-in support for 3D video using the video element. Displaying a side-by-side 3D, 360-degree video requires just an HTML tag:
Of course, these needn’t be mutually exclusive. The web can partially handle and optimize for simple VR use cases, while also providing optimizations for building immersive VR from scratch with WebGL.
The Extensible Web manifesto hinges on the idea that the web does not have to sacrifice extensibility for ease of use, that the community can use the low-level tools provided to extend the web platform using libraries.
VR is one case where this vision seems very relevant. We already have the low-level tools of WebGL and the WebVR APIs.
The A-Frame21 library provides custom HTML elements to build WebGL-based 3D scenes. A-Frame is usable on its own or with popular frameworks such as React and Angular.
A-Frame enables any web developer with HTML experience to describe VR-ready 3D scenes and to control them using familiar JavaScript. Even tools such as jQuery, Angular and React can be used to change a scene because, at the end of the day, it is still just HTML.
The web has the power to bring virtual reality to the world, to every consumer, to every developer.
It is still early days for VR on the web, but now is the time to get building, to see what works and what doesn’t.
The web can show that VR is for more than video games. VR can be used to enhance everything we currently do on the web and even enable new interactions only possible in an immersive medium.
As developers, we can start building VR experiences on the web today. By getting involved and giving feedback about the standards process, we can ensure that VR on the web becomes a robust standard, paving the way for future developers to build on.
Even if you don’t think VR is mature yet, with mixed-reality and augmented-reality devices around the corner, what we build today will still be relevant then. The interface patterns we build for VR apply to all immersive media. Don’t get left behind.
Millennials are people who are born between 1977 and 2000. They are a set of audience who are early adopters of technology. They make up 21% of the US population which means that they have the direct buying power of over a trillion dollars. Moreover, they have a huge influence on the older generations and are known to be loyal customers.
As a marketer, it is extremely crucial to target [easyazon_link identifier=”1433670038″ locale=”US” tag=”americanfid09-20″]millennials[/easyazon_link] in order to tap into the power of direct purchase decisions and improve sales. As Skyler Huff points out in her article published on Millennial marketing, content falls under one of the below four quadrants:
Branded Content
Rooted Content
Social Care Content
Social Satellite Content
(Image credit millennialmarketing)
Rooted content is what the brands actually want to convey to their audiences. This content is planned and promotional in nature. Editorial authority is important before you start publishing such content, as aggressive rooted content publishing might keep the millennials away.
Social care content is based on the one-on-one interaction that the brands have with their target audiences. Content pieces that are a part of a social customer care process or a problem-solving piece shared to build brand loyalty fall under this category. Once again, editorial authority is needed before any message is posted on behalf of your business in the social channels. Remember, a wrong message can be extremely harmful for the reputation as negativity travels much faster across social channels as compared to positivity.
Branded content also falls into the planned category as writers are fully prepared before they publish content on the brand media channels. An editorial review should be a part of this process and value should be given when creating content which solves a need of the target audience on a large scale.
Social satellite content often known as the brand newsroom refers to the group of content writers who constantly keep a watch across brand mentions on social media and prepare content based on the received reactions. The goal here is to proactively manage brand promotion.
Do Not Interrupt! Help Them, Engage Them and Entertain Them
Traditional advertising mediums like television, radio, newspapers, hoardings, etc. are a form of push advertising. Such forms of push advertising often cause irritation in the minds of the millennials and do not inspire true brand love.
Use content as an opportunity to reach the consumers when they need you. Google offers some great insights reaching the customers during the crucial micro moments.
(Image displaying some of the crucial travel moments that businesses need to get right. Image credit: think with Google)
Understand the needs of the millennials. Obtain a data driven view and note the patterns of the individual journeys. Smart marketing strategy recognizes the uniqueness of each customer and engages them to take actions.
Create user personas based on their needs, goals and observed behavior patterns. Having personas will allow you to segment contacts and assign them to workflows. You can use tools like HubSpot to create user personas.
Create new opportunities for your brand to get in front of the customers. However, do not force feed a brand message. Only deliver when they need it.
Millennials like content that is entertaining, Visual, Brief, Personal, Original and Educational/Informative. Brands have even started to leverage the power of augmented reality to engage the audiences.
Making a connection with the Millennials is the most crucial factor because once a connection is made, then they can prove to be the most loyal customers on the planet today.
Create Agility in Your Content Marketing Efforts
If you expect your brand to receive a positive response from your content marketing efforts, then it is important to create agile content. Think about creating content pieces based on genuine user feedback and real customer data instead of choosing a content topic randomly. This is what Agile content is all about. Agile content pieces are revised regularly depending on user feedback thereby increasing its value and lifetime and reducing the risk of failure. An example would be to create blog posts based on the questions that your customers are regularly asking.
Agile content helps to leverage the power of real time news and events that have the power to engage people in conversations.
The content strategy adopted should be actionable, scalable and achievable.
Consumer, product and social data are combined to understand the audience behavior to produce agile content.
The major goal should be creating content pieces that the Millennials would be willing to share across their social networks.
Here Are 4 Ways You Can Create Agile Content:
Step 1:Read well! A good writer should be a good reader first. Keep an eye on the latest industry trends and focus on fresh and fast moving news. You can try creating a content feed using Feedly or Scoop.it that collects news and information from several places together. This saves time as it eliminates the need to visit several sites on a daily basis to compile information. You need to visit your feed as often as possible because you never know when a new story will hit and go viral.
Step 2: Ask questions and gather data. Make use of the site search feature under Google Analytics and look out for the FAQ’s left by the users in the chatbot database to collect as much data as possible. Moreover, create survey forms and find out what problems your customers are facing so that you can create content based on the real problems faced by the users, instead of choosing random topics that might have worked well for any other business. Remember every business is unique, and you need to create content that satisfies the needs of your current and potential customers.
Step 3: Build a content calendar. No mission is successful without proper planning. Content marketing is an ongoing activity that needs full planning that starts with topic preparation. Creating a content calendar always helps because it allows your organization to produce constant and frequent content.
Step 4: Repurpose your content. Take help of all those creative brains who are working in your content writing team to repurpose your content. This will open new channels of obtaining traffic and solidify your branding efforts without having to spend extra time or money. You can convert a popular webinar into a series of blog posts, or you can turn a blog post into an infographic. You can try such content changes to constantly publish new and improved varieties of articles that segmented users will love to read and share.
Capitalize on the Power of FOMO
FOMO stands for ‘Fear of Missing Out’ and the millennial generation, especially the women, do not want to miss out on the opportunities that your content pieces can generate.
Social media was able to garner success only because a large number of the social user base is millennials. They do not want to miss out on important news, events or personal invites and this is the reason they regularly remain logged into their social accounts; to stay connected and remain updated. They love to share things that are popular and can generate more engagement, and they love to comment on stories where they can speak up their mind.
Content created for the purpose of ‘fear of missing out’ surely has better chances of performing well in social media, and in that process, a lot of social shares and comments are generated.
Here are some ways through which you can leverage the power of FOMO in your content marketing strategy:
Create urgency because it has the power to consistently entice customers to spend more money.
Your content should motivate the customers to act, or they might miss out.
Make use of visuals like an automatic timer or a series of reminders to keep the trigger of FOMO constant.
Create user stories of your past customers and share them across social media. People are more keen to make a reactionary purchase because they witness your past customers experience across social media. I call it “personal experience FOMO or the testimonial FOMO”. You can try it too as it works really well.
Make your content pieces exclusive like member only. People love exclusive things, and when they feel they are missing out exclusive stuff because they are not part of that elite club, they will quickly subscribe to it.
Invite your customers to try out things. Generate content invitations where the scope of personal interaction is enhanced. A music festival or a party is a great way to fulfill the needs of your target audiences along with delivering your brand message and boosting your brand awareness.
Create interactive content pieces that allow readers to engage and participate with the content to have the full experience. You can use web elements like checkbox, finger swipes, object destructions, etc. to improve the overall engagement. The addition of interactive items like these not only increase the time spent by the reader on your site, but it also helps to indirectly improve the search engine rankings of your site. Google does calculate the time on page spent by the visitor before ranking any pages, and you can fully capitalize on this ranking factor by using interactive content pieces on your website.
Stay Mobile! Create Pages That Are Optimized for Mobile
Preparing content and publishing it on a desktop friendly site is not okay! Millennials spend a ton of time on their mobile devices, so producing content that is not readable on mobile is similar to producing no content at all. Stay mobile and create landing pages that are easy to read on mobile.
Here are some steps to have a mobile optimized content marketing strategy:
Prepare content that is easy for the eyes of the mobile audience. Write short paragraphs and use proper bullet points with minimal distraction so that it becomes easier for the user to scan the content.
Prepare long form content as it adds more value to the readers. Ensure the content is rendered seamlessly across a variety of devices.
Understand and track the habits of your mobile audiences like what activities they do on your site when they are browsing it using their mobile phones.
Mobile headlines are relevant and shorter so ensure the headline fits into the screen of the standard mobile device.
Make use of big fonts as they are easier to read and get to the point fast. People don’t like to wait when they are reading using a mobile device.
A bonus strategy is connecting with influencers. Millennials are largely connected to both macro and micro influencers. Rather than working on the traditional outbound advertisement model, make use of the inbound influencer marketing to convert your target audiences into loyal brand followers.
Remember Authenticity
Millennials value content that is authentic. Your potential audience should learn from the content you provide. So, never try to hard sell. Instead, focus on speaking the millennial language when delivering the content. Information that resembles those coming directly from peers is trusted more and appear to be more authentic in the eyes of the millennials.
It would be a great idea to ask a millennial to contribute to an existing content piece in some way or the other. Empower your audiences with the power of interaction and the engagement levels are bound to increase.
Marketing to millennials is incredibly intuitive. Offer authentic experiences that can engage the readers. Acquire some influencers to share your story, and the millennials will follow. Have you used any specific strategy to target millennials?
Founder and CEO of Over The Top SEO. He holds broad expertise in the areas of SEO, Social Media, Digital Marketing, B2B, B2C Brand Development and online lead generation.
As designers we usually turn to different sources of inspiration, and, well, sometimes the best inspiration lies right in front of us. With that in mind, we embarked on a special creativity mission nine years ago: to provide you with inspiring and unique desktop wallpapers1 every month. Wallpapers that are a bit more distinctive as the usual crowd and that are bound to fuel your ideas.
We are very thankful to all artists and designers who have contributed and are still diligently contributing to this mission, who challenge their artistic abilities each month anew to keep the steady stream of wallpapers flowing. This post features their artwork for September 2017. All wallpapers come in two versions — with and without a calendar — and can be downloaded for free. Time to freshen up your desktop!
Please note that:
All images can be clicked on and lead to the preview of the wallpaper,
You can feature your work in our magazine2 by taking part in our Desktop Wallpaper Calendars series. We are regularly looking for creative designers and artists to be featured on Smashing Magazine. Are you one of them?
Summer Ending
“As summer comes to an end, all the creatures pull back to their hiding places, searching for warmth within themselves and dreaming of neverending adventures under the tinted sky of closing dog days.” — Designed by Ana Masnikosa3 from Belgrade, Serbia.
“It is inevitable. Summer is leaving silently. Let us think of ways to make the most of what is left of the beloved season.” — Designed by Bootstrap Dashboards46 from India.
“This calendar was inspired by International Talk Like a Pirate Day (September 19) — one of the many obscure and quirky days we celebrate in New Orleans. Our fair, colorfully corrupt city has entertained its share of outlaws over the years, but none as infamous as the pirate Jean Lafitte, a Frenchman who terrorized sailors and ships in the Gulf of Mexico and distributed his booty from a warehouse in New Orleans in the early 1800s. This calendar is a playful tribute to all of the misfits, outcasts and swashbucklers who call New Orleans home.” — Designed by Sonnie Sulak73 from New Orleans, LA.
“As summer comes to a close, so does the end of blue crab season in Maryland. Blue crabs have been a regional delicacy since the 1700s and have become Maryland’s most valuable fishing industry, adding millions of dollars to the Maryland economy each year. With more than 455 million blue crabs swimming in the Chesapeake Bay, these tasty critters can be prepared in a variety of ways and have become a summer staple in many homes and restaurants across the state. The blue crab has contributed so much to the state’s regional culture and economy, in 1989 it was named the State Crustacean, cementing its importance in Maryland history.” — Designed by The Hannon Group108 from Washington DC.
“It’s officially the end of the summer and I’m still in vacation mood, dreaming about all the amazing places I’ve seen. This illustration is inspired by a small town in France, on the Atlantic coast, right by the beach.” — Designed by Miruna Sfia135 from Romania.
“This autumn, we expect to see a lot of rainy days and blues, so we wanted to change the paradigm and wish a warm welcome to the new season. After all, if you come to think of it: rain is not so bad if you have an umbrella and a raincoat. Come autumn, we welcome you!” — Designed by PopArt Studio178 from Serbia.
“Cats are beautiful animals. They’re quiet, clean and warm. They’re funny and can become an endless source of love and entertainment. Here for the cats!” — Designed by UrbanUI223 from India.
“After leading a photographic tour through Northwestern Argentina and while discovering its magical ravines and rock formations, I decided to make a wallpaper inspired by the Devil’s throat formation. Use human for scale!” — Designed by Diego Waisman248 from the United States.
“I designed this wallpaper to remind everyone that autumn is here and they are still reading the best design website, Smashing Magazine” — Designed by Advanced Web Ranking271 from Romania.
“Since it is already September, the leaves are falling and the days are getting shorter and shorter. It is also getting colder so therefore this lovely wallpaper to warm you up.” — Designed by Melissa Bogemans296 from Belgium.
“I was visiting a beautiful garden, taking pictures of details within the plants. The colors of this leaf were so brilliant with the sun behind.” — Designed by Philippe Brouard362 from France.
“India is a world in itself, with the richness of its heritage and culture. The beautiful festivals are a means of removing all the negativity in our minds and refreshing our souls from within. The festivals are filled with bright colors and uplifting music which rejuvenates our senses and ignites our soul with confluence of multiple energies drawn from several auspicious moments of the past. These festivals are a delight for the creative minds due to their vibrant concepts, energy, colors and art blended in to beautiful form. Every festival has a special significance and aura, I would like to communicate it to the world through this wallpaper.” — Designed by Shyam Pawar410 from India.
“Travel and change of place adds new vigor to the mind. Take a break, forget your worries and travel. Create stories of new places and adventures to tell. Meet new people, learn new languages, taste new cuisines, experience the beauty of different culture and traditions, and lose your spirit to the soul of the universe which lies in traveling. On World Tourism Day, start a new journey of your life, rejuvenate and breathe and live happily while traveling across roads you have never taken before.” — Designed by Acodez IT Solutions464 from India.
“A touch on guitar’s strings, soft caresses on the piano’s pins, resurrecting waves of joy, of love from the heart within. Come, let’s get immersed in the sound of music…” — Designed by IPIX Technologies507 from India.
“September the 13th is the birthday of legendary author, Roald Dahl. If you haven’t heard of him, where have you been? I have even included an inspirational quote from the Charlie and the Chocolate Factory book.” — Designed by Safia Begum577 from the United Kingdom.
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.
Welcome back to the second part of this tutorial on Gravit Designer. In the first part1 we took a general look at Gravit and set everything up, created the background image in the weather app and the status bar, and then started to make the initial elements of the design’s content.
Having created the main text layers of the content area in part one2 of this tutorial, let’s continue with the weather conditions for the different times of day.
Start with a simple circle of 56 pixels in diameter (remember to hold Shift), with a white 2-pixel inside border, with no fill outside of the “Status bar” group (figure 1a). Move it to “32” (X) and “368” (Y) in the “Position” fields in the Inspector.
Because we want to reuse this style for other shapes, we will create a new “Shared Style.” This allows you to sync all styling properties between various layers and to update changes with a click. To create a shared style, click on the dropdown field for “Style” in the Inspector that says “No shared style” and select “Create New Shared Style.” Now you can define which properties you want to take over — let’s keep everything checked. For the name, use “Icon outline.”
5 Figure 1a: The base for the different weather conditions is a white circle with a border. Create a “Shared Style” in the Inspector, so that you can bring over the styling to other elements. (View large version6)
Let’s turn to the icon itself now, a sun partly covered by a cloud. It consists of various shapes combined into a single form, and a few paths (for the rays).
First, the cloud (figure 2). Draw a rectangle (R) with a size of 28 × 14 pixels, with fully rounded corners (“7” — drag the slider all the way to the right) inside the circle. Because aligning the various parts of the icon to the grid wouldn’t make sense, switch it off for now with Alt + Command + G (on Windows and Linux, Alt + Control + G). Before we continue, use the zoom function with Z to zoom into the rectangle so that it’s easier to work on the following steps. If you intend to zoom in with Command + + instead, then select the shape beforehand so that Gravit Designer takes it as a reference when zooming and zooms to its center.
Note: Before drawing the rectangle, make sure that the circle isn’t selected or else it will take over all of the properties, including the shared style. This is important for when we add new shapes later: If another element is already selected, then all of its properties will be taken over; if nothing is selected, then the new element will be drawn with a default gray fill and no border. That’s also the style you can use for the rectangle for now.
Now add an ellipse (E) above the rectangle that is 15 × 15 pixels in size, that is away 3 pixels from the left edge of the rectangle and that juts out 7 pixels at the top. Clone it with Shift + Command + D (or, on Windows and Linux, Shift + Control + D), resize it to 12 × 12 in the Inspector, and offset it 10 pixels to the right and 3 pixels to the bottom. Looks like a cloud already!
7 Figure 2: The cloud consists of a rectangle with fully rounded corners and two circles. (View large version8)
However, we want an outline instead of a solid fill, so we’ll need to bring the “Merge” function into play (also called Boolean operations in other applications, such as Sketch). Select the three shapes and click on “Merge” in the toolbar; this will combine everything into a single form and allow us to assign a border in its entirety later on (figure 3). The advantage here is that you can expand the “Compound Shape” group in the Layers panel and still move the elements individually. It’s even possible to adapt the type of merge function — for example, if you want to cut the right-most circle from the other shapes (“Subtract,” the third option). Have a look at “Boolean” in the Inspector to perform this change. The lesser used types here are “Intersect” and “Difference,” which just show the part where the shapes overlay or the exact opposite, respectively.
With the “Compound Shape” group selected, change from a fill to a white inside border with 1.5 pixel thickness. Remember that you can alter the position of the border in the “Advanced stroke settings.” Now it will become immediately apparent what the Merge function has done to the shapes.
9 Figure 3: The “Merge” function combines multiple elements into a single shape but still allows you to modify them individually. After you have “merged” the shapes of the cloud, apply a white border. (Click to play video10)
Complete the cloud by giving it a proper name.
On to the sun now. Create another circle with a 12-pixel diameter outside of the other big circle. With the cloud still selected, this will take over the styling. This time, however, we need a centered border (you will see why later). Switch to the Line tool with L and draw a vertical one 3 pixels in length above the circle. Make sure that the circle is already selected (to take over the styling yet again), and hold Shift while drawing to constrain the movement. The line should be centered to the circle horizontally and have a gap of 4 pixels in the vertical direction.
Note: To directly transfer the styling from one element to another, proceed as follows: Select the root element, press Command + C (on Windows and Linux, Control + C), click on the layer (object) that you want to take the styling over to, and hit F4. Done! Try it — it’s a nice little time-saver!
How do we do the other rays now? We need to combine two techniques here (figure 4). An integral part is the “Transform” function in the top section of the Inspector, which is quite a handy tool to apply transformations to objects. It allows you not only to move, rotate and skew objects by a certain amount, but also to resize a layer relatively with percentages.
The thing that interests us most with the Transform feature at the moment, however, is the ability to adapt the rotation point of a shape — the orange rhombus at the center of the line. It defines the point around which a shape is rotated. To continue, perform the following steps:
Clone the line (Mac: Shift + Command + D, Windows and Linux: Shift + Control + D) while it is selected.
Switch to the Transform tool with a click on the button in the Inspector.
Drag the rotation point (the orange rhombus) down so that it is at the center of the circle.
Hold Shift to trigger the rotation mode, and drag the line until the “Angle” field in the Inspector says “-45°.” You might need to release Shift again to catch this exact value.
This rotated line will be the reference for the other rays. First, select and duplicate the initial unrotated line again, but this time with Command + D (on Windows and Linux, Control + D). Then, bring this duplicate to the exact same position and rotation as the other line we just adapted with the Transform function: Drag it there, and rotate it with the “Angle” field in the Inspector. (You might also need to switch off “Snap” in the toolbar for this to work.)
Now press Command + D again until all remaining six rays appear. You might need to align them individually afterward, so that all have the same distance and alignment. Also, delete the duplicate of the second ray.
11 Figure 4: Use the “Transform” feature to change the rotation point of the line, so that it can be duplicated around the circle. (click to play video12)
As with the cloud, we want to combine all of the elements of the sun into a single shape so that we are able to style it as a whole. Select everything (ideally in the Layers panel), and click on “Merge” again in the toolbar. Alternatively, you can press Command + M (on Windows and Linux, Control + M). Rename this group to “Sun.”
Note: Please make sure that the lines (i.e. the rays) are above the circle in the layer hierarchy. The styling of the bottom-most layer is always applied to the other layers when you use the “Merge” function.
One final touch is left for the sun: rounded ends for the rays. Open “Advanced stroke setting” in the Inspector again, and select the second option (“Round”) in “Ends.” Looks great!
The individual parts of the icon (the sun and cloud) are ready now, so let’s bring them together somehow. Be sure to switch on the snapping again in the toolbar. First, bring the sun to the top-right corner of the cloud, then move it about 9 pixels to the top and 8 pixels to the right with the arrow keys on the keyboard.
Now, clone both weather symbols so that we have a backup for later (Mac: Shift + Command + D, Windows and Linux: Shift + Control + D). Note: When selecting two groups, you might want to press Command (on Windows and Linux, Control) instead of Shift, to have everything working correctly. While the second sun can be hidden (use the eye symbol in the Layers panel), we will need to manipulate the copy of the cloud for the further steps. (see figure 5 for all of the steps.)
Right-click on the cloud shape and select “Convert to Path,” which will create a path with individual points instead of the compound shape. We also need to do something similar for the sun, but instead of converting the shape itself, we want to transform its border to a path. This is also possible with a right-click on the shape, but with “Vectorize Border.”
Now you can combine these two elements again to create the partly covered sun: Select both, click on the arrow next to the “Merge” icon in the toolbar, and pick “Subtract.” Just make sure that the sun is behind the cloud in the layer hierarchy.
Name this new icon “Sun” again, and delete the rays that overlap with the cloud. The easiest way is to use the Lasso tool. It can be used to draw a selection of multiple vector points — which is quite different to how a Lasso tool will perform in other applications (like Photoshop, for example, where it serves to select parts of a bitmap image).
To use it for the removal of the rays, pick the “Compound Path” within the sun group, switch to the Lasso tool with O, and drag a selection around the redundant rays. Then, delete them with Backspace (on Windows and Linux, Delete).
Finally, combine this glimpse of the sun with the copy of the cloud into a group named “Cloudy,” and align it with the bigger circle. Group them again into an overarching “Icon” group.
13 Figure 5: Subtract the sun from the cloud so that it looks as if it’s partly covered. (click to play video14)
Once we have added a description of the weather condition, we will have finished our first daytime view (figure 6). Add a text layer above the icon (press T), with the following properties in the Inspector:
Color: white
Size: 14 pixels
Weight: Regular
Line spacing: 16 px (click on the “%” label to switch to pixels)
Content: “7:00” followed by a break, followed by “Few Clouds.”
Alignment: center (the second icon).
After that, select the time within the text layer, and give it a “Semi-Bold” weight. Make sure that it is horizontally centered to the icon, with a vertical distance of about 12 pixels. Show the grid again with Alt + Command + G (on Windows and Linux, Alt + Control + G) so that you can align everything properly. Create one last group from the text and the “Icon” group, named “Icon left,” and we will be ready.
Before continuing, let’s bring some order to the Layers panel. Drag the “Status bar” group to the very top (or press Shift + Command + up arrow key on the Mac (on Windows and Linux, Shift + Control + up), followed by the three text layers, the copy of the sun and the “Icon left” group.
It’s easy to get the other weather symbols from here. Duplicate the current one (“Icon left”), center it to the page and move it to a Y position of “297,” which should align everything neatly to the grid. The group’s name of this new symbol should be “Icon middle”; for the text, use “14:00 Light rain.” Be sure that everything is centered again.
Because this one will represent the current weather condition, select the circle with a Command-click (on Windows and Linux, Control-click) to change from the border to a white fill. Create a new shared style named “Icon full.”
Now go to the Layers panel, where you will select the “Cloud” group within “Icon” → “Cloudy.” Enter the color dialog and use the color-picker symbol to pick a light-blue color for the surrounding of the icon. Now employ the “Mix” area at the bottom of the dialog to change to a darker shade, so that the icon comes to the fore against the white background. Align it to the center of the surrounding circle with the alignment icons, remove the “Cloudy” group with Shift + Command + G (on Windows and Linux, Shift + Control + G), and delete the redundant “Sun” group in the layers panel. See figure 7 for the entire process.
17 Figure 7: Create a new shared style for the middle icon, adapt the cloud and delete the redundant sun. It’s supposed to rain soon! (Click to play video18)
The first steps for the rain symbol are accomplished, but one vital part remains: the raindrops. Just like for the sun in the other icon, we need to convert the cloud to outlines first for the subsequent steps (figure 8). Right-click and select “Vectorize border” like before (which converts to a “Compound Path” group). Now we can create a rectangle of 16 × 6 pixels at the bottom, which will act as the hole for the raindrops. It should be 5 pixels away from the left edge of the cloud and overlap its bottom line. You might want to zoom (press Z) to have a better view and switch off the grid again.
Select the rectangle together with the “Compound Path” group, and create another “Subtract” operation from “Merge” in the toolbar. For it to work correctly, make sure that the rectangle is on top. After that, drag it into the “Icon middle” → “Icon” group again, and also reset its name to “Cloud.”
19 Figure 8: Vectorize the border of the cloud shape and cut away a rectangle. (Click to play video20)
Next task: the raindrops (figure 9). They consist of three vertical lines — two 10 pixels long and one 15. The distance from the first to the second should be 5 pixels, and from the second to the third 4 pixels. Start with the first one of 10 pixels in length: Switch to the Line tool with L and hold Shift to constrain the movement to the vertical axis. Assign a centered border with 1.5 pixel thickness and rounded ends (from “Advanced stroke settings”) and that has the same color as the cloud (either take it over with the color picker or use the “In use” area in the color dialog.)
Now follow these steps:
Clone the line.
Move it 4 pixels to the right with the arrow key.
Switch to the Subselect tool with D, and move the bottom point down by 5 pixels with the arrow key.
Select the first line again.
Make a second copy and move it 9 pixels to the right.
Now select and merge all of the lines (Mac: Command + M, Windows and Linux: Control + M), which will let you transform them all together with the Transform tool in the Inspector.
Enter “-30°” for “Skew” and click on “Apply.” Make sure that all other fields are set to “0” or “100%.”
Leave the tool with another click on “Transform,” so that you are able to align the skewed lines to the cloud, with a distance of 7 pixels to the left edge and 12 pixels to the top edge.
21 Figure 9: Create the lines for the raindrops, and skew them with the “Transform” tool. (View large version22)
For the correct measurement to show up, you might need to press Command + Alt (on Windows and Linux, Control + Alt) to drill into the group. To finish the icon, rename the “Compound Shape” group to “Raindrops” and create a new “Icon inner” container with the “Cloud” group. When selecting the two groups, make sure to use Command (on Windows and Linux, Control) instead of Shift. Also, drag it into the “Icon middle” → “Icon” group and align it properly to the circle again. With this, we have finished the second weather symbol. On to the third and last one!
To start, zoom out to 100% (Mac: Command + 0, Windows and Linux: Control + 0) for a better view. Select the first symbol — the “Icon left” group — and clone it to an “Icon right” group. Move it to the right of the page with the fifth alignment icon (“Align Right”), and select the “Icon” group within. It should have a gap of 32 pixels from the right edge — the grid will definitely help you here. The text of this symbol should read “22:00 Cloudy.” Like before, make sure that it is centered to the icon. Because we have cloudy weather now, we don’t need the sun anymore. Select its group in the Layers panel and delete it. As well, center the cloud to the circle again in both dimensions. That’s it! We’ve just completed all of the daytimes (figure 10).
The last element of the weather app (actually, its center part) is the enlarged display of the current weather condition at the bottom of the screen, surrounded by some elegant half circles.
Create the first half circle with a diameter of 464 pixels (figure 11) — switching off the grid might help. Proceed here as follows:
Switch to the Ellipse tool with E.
Move the cursor to the bottom center of the page until the smart guides show this spot.
Hold Shift to create a circle and Alt to start from the middle.
Move this shape down by 16 pixels (add “+16” to the “Position” → “Y” field).
Assign #708AB5 as the fill color.
Set the “Blending” to “Soft light.”
Rename it to “Ellipse 1.”
To set it off from the background image, assign an Inner Shadow at the bottom of the Inspector with a click on the “+” icon on the right. Use the following properties:
X: 0
Y: 1
Blur: 1
Opacity: 70%
Color: black
As with the other styling properties, multiple shadows can be stacked on top of each other. Create another inner shadow in the same way as above: It should share all values with its sibling, except for the “Blur” — set this one to “20.” Before you continue, create a new layer in the Layers panel (in the top-right), name it “Bottom,” drag it right above the “Overlay” layers, and move this first circle in. If you’d like, you can also assign a different color to this layer so that it differs from the status bar.
We need three more circles (figure 12). Clone the first circle with Shift + Command + D (on Windows and Linux, Shift + Control + D), and resize it to 416 pixels from the center (hold Shift + Alt and drag the bottom-right handle). Style the second circle as follows:
Fill: #809AC6
First inner shadow: 0/1/1/50% (X/Y/blur/opacity)
Second inner shadow: 0/1/12/60%
Name: “Ellipse 2”
Create a copy from this second circle, this one with the following properties:
Size: 392 pixels in diameter
Fill: #CCE0FF
First inner shadow: 0/1/1/50%
Second inner shadow: 0/1/8/100%
Name: “Ellipse 3”
For the fourth and last circle, use these settings:
Size: 370 pixels in diameter
No fill
Blending: Normal
Just one inner shadow: 0/1/3/25%
Name: “Ellipse with image”
The reason why this last circle has no fill is that it will contain another image of a cloudy sky, alongside some dark overlays. Grab the image27 and bring it into Gravit Designer. Now move it so that it fully covers the last circle, and drag the image into it in the Layers panel, which will clip it automatically to the shape. Another way to create such a mask would be to select both — the shape and image — and pick “Mask with Shape” from the right-click menu. Just make sure that the mask (i.e. the circle) is above the to-be-masked content (the bitmap image) in the layer hierarchy.
After that, create a rectangle within this new mask group (drag it in after it has been created), which will also cover the circle, and give it a black fill with a “Soft light” blending. This will make the image darker; but we need more, so create a clone of this rectangle.
28 Figure 12: The four half circles — the last one with the clipped image and the two dark overlays. (View large version29)
The last element here is an enlarged version of the rain symbol above (figure 13). Proceed as follows:
Select it (“Icon inner” in “Icon middle” → “Icon”).
Duplicate it and move the icon into the “Bottom” Layer group, in the top position.
After that, drag it to the bottom of the page on the canvas (with the Pointer tool — V).
To make it visible in front of the background image, select the “Raindrops” group and change the border color to white, as well as the fill color of the “Cloud” group.
The final move is to enlarge the icon massively to 128 pixels in width and center it to the semi-circle. Make sure that “Keep Ratio” is switched on between the width and height fields in the Inspector and that “Autoscale Borders” is selected in the “Advanced stroke settings” of the raindrops. Otherwise, they will remain at the original border thickness.
To make the icon stand out from the background even more, we could also apply a drop shadow with the properties “-3/3/0/15%.” The same goes for the text layers, but with the values “-1/2/0/10%,” except for the temperature, which harmonizes better with “-2/3/0/5%.”
After so much work, we have finally finished the first screen of the app. Press Command + 0 (on Windows and Linux, Control + 0) to set it in its full glory.
But we want more. In a second iteration, we want to show it with some friendlier conditions.
30 Figure 13: The finished enlarged icon at the bottom — and with it, the entire screen. Make sure to select “Keep Ratio” in the Inspector when resizing the icon. (View large version31)
Up until now, we’ve worked exclusively in single-page mode, meaning that we’ve had only a single page on the canvas. For the iteration, we need another one (see figure 15 for the result). To enable multi-page mode, click on the toggle next to the “Pages” label (figure 14). Now you can select the current page on the canvas with a click on the title, and press Command + D (on Windows and Linux, Control + D) to duplicate it and keep working there. Rename the first one to “Light rain” with a double-click in the page list and the second to “Sunny” so that there is no ambiguity.
Pages are ideal if you want to create different versions of a screen, to try out variations or just to fiddle around and see all iterations next to each other.
The first task for the new page is to change the time in the status bar to “07:30,” to indicate that we are at another time of day now. Also, modify the day (“Saturday, Jun 16”), as well as the temperature (“28 °C”). Furthermore, we want to display other weather conditions: The left-most and middle should be “Sunny,” the right one “Cloudy.” Ensure that all text layers are centered again. Because we have sunny weather now, this should be reflected in the background image. Unlock the current one, delete it and drag in the new image32. Ensure that it is at the bottom of the layer hierarchy again.
The easiest way to move it there is to press Shift + Command + down arrow on the keyboard (on Windows and Linux, Shift + Control + down arrow). Then, bring it back to the original size with the respective button in the Inspector (“Original size”), and center it to the page in both dimensions with the fourth and seventh alignment icons from the left in the Inspector. This time, the blur should have a slightly smaller radius of “15”; be sure to lock the image again. In addition to dark overlays, we will create a third one, with the full size of the page, a black fill and a “Soft light” blending. Name it “Overlay 3,” and put it right above the image in the layer hierarchy (also locked).
We also need an updated image for the semi-circle at the bottom, within the “Bottom” → “Ellipse with image” groups. Delete the old one and drag in a new bitmap33. It should be clipped and horizontally centered to the circle again and also be displayed at the original size. Drag it vertically until it shows a view that appeals to you. The two overlays are too dark now, so we need to adapt them. Change one to a fill color of #000560 and a “Screen” blending, and the other to #033572 with “Hard light” and an opacity of 12%.
34 Figure 14: A friendlier version of the screen, created on a separate page. Use the toggle in the “Pages” area to change from single- to multi-page mode. We’ve already started to adapt some of its parts. (View large version35)
The only thing left to do is to fix the icons so that they match the text. You can switch to single-page mode again if you like. Because the left icon says “Sunny,” we just need the sun symbol — good that we saved it before tearing it apart earlier. Look for the hidden “Sun” group in the Layers panel and show it again. Delete the old “Cloudy” icon within “Icon left” → “Icon,” and drag the sunny pendant to its place (in the Layers panel and on the canvas). The icon could be a bit bigger, though, about 30 pixels. Continue as follows:
Fully zoom into the icon with “View” → “Fit Selection” from the menu bar.
Zoom out two steps again with Command + - (on Windows and Linux, Control + -).
Grab the bottom handle, hold Shift and Alt, and drag until the width in the Inspector says about 30 pixels. Make sure that “Autoscale Borders” is selected in the “Advanced stroke settings” of the icon.
We also need to give the icon a selected state, because the current time is 7:30. First, change the border color of the sun to the same as for 14:00 — the easiest way is to use the color picker in the color dialog. Now, select the outer circle and change it from the “Icon outline” shared style to “Icon full” in the Inspector. Do the same for the middle weather condition, but in reverse. You also need to replace the rainy icon (“Icon inner”) with the sun there, but with a white outline.
The third place where the sun should appear is within the half circle at the bottom, but at a much larger size. Copy the white version and paste it right above the “Ellipse with image” group. Follow the steps above to resize it to a width of 120 pixels. Finally, use the same shadow as before (-3/3/0/15%) to give it a stronger appearance against the background image.
36 Figure 15: The finished iteration. It’s going to be very hot today! (View large version37)
We now have two versions of the app, showing different times of day and weather conditions (figure 16). Let’s export them in the final step, which is quite a snap in Gravit Designer. Either click on the export icon to the right of the toolbar or press Shift + Command + E (on Windows and Linux, Shift + Control + E) to enter the Export dialog. There, in the “Canvas” tab, you can already see the two pages, ready for exporting.
38 Figure 16: The two pages, ready for exporting in the “Export” dialog. You can open the dialog with the respective icon in the toolbar. (View large version39)
While the default settings should work just fine, you have many different options here to tweak the output to your liking. The “Format” should be pretty self-explanatory, but the “Size” holds a few hidden values: “2x” lets you export at double size for high-resolution displays (“3x” and “4x” work, too), and you can define a fixed width or height (append “w” or “h”) or both dimensions. Lastly, it’s also possible to set the DPI resolution for print designs.
Besides exporting entire pages, you can also get individual layers (objects) out of Gravit Designer. If you select a layer before entering the export dialog, it will show up in the “Selection” tab; “Assets” can be defined when you click on the “+” icon in “Make exportable” in the bottom-left in the main window. There, you have similar options like in the export dialog and can also define multiple types at the same time.
40 Figure 17: You can also export individual elements if you click on the “+” icon in “Make exportable.” They then show up in the “Assets” tab in the export dialog. (View large version41)
I hope you have enjoyed this tutorial and that it has given you valuable insight into Gravit Designer. It was just a small glimpse into the application and its features, because Gravit is capable of creating many different types of designs. Go to designer.io42 to use it online or to download the desktop application.
If you have questions, feel free to ask in the comments below.
You can always reach out to the Gravit team on Twitter43 and Facebook44, and there is also the very friendly discussion board45 where you can post your questions and ideas.
One of the biggest fallacies of our industry is that good work speaks for itself. It is a self-delusional lie that those with a good reputation tell themselves to explain their success.
Success means many things to many people. Some think it is getting to work on projects they love; others believe it is earning a lot of money, still others consider it is getting to spend more time with the family.
However you choose to define success, it will require other people’s cooperation. It will involve landing the right job, winning the right kind of work and being able to charge enough money for your services.
It would be great if that were all defined by the quality of your work, but it’s not. There is another factor at play here; your reputation.
I will let you in on a secret; I am not that amazing at my job. Don’t get me wrong; I am good. But I am not a leading mind in our industry or anything. But, people often talk as if I am.
3 My terrifying secret is that despite speaking at conferences and writing regularly for big name publications like Smashing Magazine, I am just not that talented. (Large preview4)
I would love to claim this was down to talent. But in truth, it is because I shamelessly self-promote. Hell, I am doing it right now, and I am even being paid to write this post!
I will be honest, doing so makes me feel uncomfortable. It might be because I am British. We hate talking about ourselves and despise people who are full of self-importance. But from a career perspective, it was the best thing I ever did.
It has helped me to win work to the point where I can now pick and choose the work I do. But it also had another unexpected benefit; my projects tend to run much more smoothly. That is because my clients respect me more. They know I have a reputation and so listen to what I have got to say.
Think of reputation as a currency. A currency that you can spend to advance your career, win new clients or ensure projects run that little bit easier. It a currency that you can spend to achieve your version of success.
Of course, none of this is fair. People should respect ability, not reputation. But most clients don’t know what good looks like and so have to fall back on how other people talk about you. That means that reputation is about a lot more than the quality of your work.
Every web professional is different, but no one likes to work on weekends and extra hours. Managing your time is vital, and with just a few other tricks you can easily get work done without working more hours. Read more →5
For a start, producing great work won’t build your reputation if people aren’t aware of it. Sure, word of mouth from satisfied clients is important, but that will only take you so far.
If you don’t get out there and talk about your work, then nobody will ever know about it. That is why most of us haven’t heard of Duncan Haldane6 despite having won the Nobel Prize in Physics, but you have heard of Stephen Hawking who hasn’t.
7 Stephen Hawking has a much higher profile than Duncan Haldane despite the fact he has never won a Nobel Prize. (Large preview8)
Then you also need to ensure people remember you. People have short memories and reputations can quickly fade if not constantly reinforced.
Finally, they have to like you. You can produce the best work in the world, but if you are obnoxious, then you will end up with entirely the wrong sort of reputation.
So if the quality of your work isn’t enough to build a solid reputation, then what is?
Look, I am no Gary Vaynerchuk9. I am not a Times bestseller who has built a business empire based on his ‘personal brand’. But in my little way, I have done okay.
10 Gary Vaynerchuk has built a phenomenal business empire largely based on his personal brand. (Large preview11)
I would like to say that what success I have had in self-promotion has been down to careful planning, but that would be a lie. A good degree of it was blind luck and timing. For example, when I started a web design podcast12 there was nothing else on the subject. I had a monopoly. That gives you a good head start!
You could argue that my success came from grasping the opportunity. But again that was more luck than judgement, and anyway, that is not something you can replicate in your situation.
But among all the blind luck, I have done a few things right. I could drone on about writing great posts, or why my podcast has been a success. But much of my success has boiled down to two things.
When it comes to reputation building, people give up too quickly. They start a blog and then get demoralised when nobody reads it. They submit talks to a conference but give up after a few rejections. So it goes on, a string of half arsed attempts.
Reputation building takes time, not weeks, not months, but years. Years of nobody paying you a blind bit of attention. It took me years before the number of people subscribed to my podcast got above 600. Years more before I was asked to speak at a conference or invited to write a book.
When it comes to reputation building, you need to think long term. That means that you need a reason to do what you do beyond reputation. I blogged because I wanted to get down in writing all the things I was learning. I recorded my podcast every week because I enjoyed chatting with people. Without those extra motivations, I would have given up, too.
But stubbornness plays a big part as well. It would have been easy to skip the occasional podcast episode or conclude client work was more important than posting an article nobody would read. However, you can’t think like that. If you do, self-promotion will always be at the bottom of your task list and will never happen.
To this day, I will without fail, post an article every Tuesday and a podcast every Thursday. My newsletter will go out every other Friday because I know how important it is to stay in the front of people’s minds. The only time I take a break is when I am on vacation. Because if I start slacking off, people will quickly forget me like that 80’s boy band you loved so much.
But putting out regular content is not enough. It has to be the right type of content too.
While my pigheadedness proved a benefit, my ego did not, especially when it came to building a reputation. If I’m truthful, my motivation in the early days was to win the approval of the “cool kids” of the web design world. I wanted to be a star of the web design community, and that is what drove my writing and podcasting.
Not only did this mean I found myself frustrated when nothing happened, but it also led to me writing for entirely the wrong audience. Instead of writing for people who might potentially hire me, I spent my time writing articles aimed at impressing other web designers.
Don’t misunderstand me; there is nothing wrong with sharing your knowledge with your peers. In fact, it is something we should all be doing. But, we need to remember why exactly we want to build our reputation. Ultimately it is to progress our careers and win work. That means we need to think long and hard about where we invest our time. Do we speak at a jQuery conference that we have always respected and admired, or at some soulless business event full of potential clients? Personally, I would pick the latter every time.
We also need to be focused in who we target. The larger the number of people you are trying to build a reputation with the harder it is going to be. Becoming a global superstar in web design is extremely challenging. But becoming the go-to web designer within a particular sector or niche is much easier. With limited resources at our disposal, it makes much more sense to focus on a specific area in which to build our reputation.
13 When it comes to reputation building, it is better to be a big fish in a small pond. (Large preview14)
Although the above advice will help, it is not enough on its own. Even if you became an expert in every aspect of reputation building you may still not succeed. That is because our attitude becomes our worst enemy.
I’m sick of people making excuses about why they can never build the reputation I have been talking about in this article. They have failed even before they have begun because of their mindset.
So let’s take a moment to address some of the defeatist attitudes that may be rattling around in your brain.
Maybe you’ve been dismissed as a speaker or submitted a post to Smashing Magazine that got turned down. Maybe you want to write a book but can’t find a publisher. Whatever the case, get over it. You don’t need any of those things to build a reputation.
If you get turned down as a speaker, start offering webinars. If you can’t get a book deal, self-publish. If people don’t accept your articles, start a blog. You don’t need a gatekeeper to reach an audience.
15 We don’t need gatekeepers to approve our content. If you want to write a book, self publish. (Large preview16)
Sure, you will reach fewer people initially, but it gives you time to hone your craft. Given enough time you will become good enough to attract the attention of those with larger audiences. Eventually, they will be banging down your door.
I want to let you in on a shocking truth; we all have the same number of hours in a day. My life is just as busy as yours, but I find time to post an article and podcast episode every week.
You may feel that you do not have the time because you are barely making ends meet by working weekends and evenings already. Well, you have bigger problems and should read my article on pricing your time18.
Many people are afraid to share their thoughts online for fear of criticism. They don’t think they know enough and don’t want to look like an idiot. Trust me, I get this, and everybody struggles with the same thing.
But please do not let that hold you back. In truth, there is always somebody out there who knows less than you. Admittedly, there will be people who know more, but that doesn’t mean you have nothing of value to add.
I recommend starting with sharing your personal experiences of projects that you have run. By talking about your own experience, you are on safe ground. Nobody can tell you you are wrong because you are only sharing what happened to you. Also, nobody else had that experience, and so there is nobody who is better placed to share it. Do that for a while, and you will find your confidence grows.
Finally, I hear a lot of people say that they find public speaking or writing incredibly hard. Believe it or not, this is something that I found hard at the start. As a child, I used to have a stutter and found it incredibly hard to speak in a group. I’ve also always struggled with spelling and grammar which put me off of writing for years.
But speaking and writing are just like any other skill. You eventually become good at it. That is why I don’t regret the fact that I had such a small audience for so long. It gave me time to get better and growing confidence.
Ultimately that is what building a reputation is all about. It is about growing in confidence and being willing to step out from the shadows. It is not easy especially if you are a more introverted character such as myself, but it is worthwhile. You do have something of value to share and those people you look up to are no different to you.
Most apps developed and released in Google’s Play store are abandoned by their developers. Over half of these apps get fewer than 5000 downloads, and most apps are considered unprofitable. This article is not going to make you the next Instagram, but it will hopefully help you get a nice base level of users that you can grow from.
To give you some better understanding of numbers, the example app in this article received 100,000 downloads in eight weeks. This is with a marketing budget of zero and very little work since launch. We’ll cover the basic app store optimizations that will help bring people to your Google Play page. Getting them to download and stay is up to you and up to the value your app provides.
To launch an Android app, you need a plan. Without a plan, you are destined to fail. Your hopes, dreams and code will lie untouched, hidden at the bottom of Google Play for the rest of time or until Google decides to do a clean up and wipes your failure from existence. Of course, to get traction, you need to pick a topic in which enough people are interested, and then the quality of your build is what is going to help keep these users.
The mobile app market is a growing industry, making it even more important for designers and developers to stay up to date with current trends and future prospects. And the explosive growth in the mobile app market isn’t stopping anytime soon. Read more →1
The app I am going to use as my example is Learn How to Draw372, which I launched in December 2016 in cooperation with artist Will Sliney3. We will talk about our launch goals and techniques. We will also share our results in the form of installations, usage and many more statistics, which we have directly pulled from the Google Developer Console. Hopefully, they will give you some context for what to expect.
Everyone has an idea for an app. Some possess the right skills (or have enough money) to turn that idea into reality, but very few launch successfully. The primary problem with most launches is that the developer goes for the vanity metric: “How many downloads can I get in as short a period as possible?” They want the big bang. They want to show the world they are a big success on day one. The problem with this approach is that what goes up fast and doesn’t have a good product-market fit will come down even faster. Spiking on launch followed by a loss of all your newly acquired users the same week might be worse than not spiking at all.
The goal of our launch was to find a nice steady stream of new users. From these users, you can learn what is working and, more importantly, what is not working with your product. Yes, getting articles written about you also helps with app store optimization, but putting time into this should only happen once your foundation is in place. “Thank you for stating the obvious — just tell us how you did it,” I hear you say. No problem. Here it is.
When looking into launch strategies, I categorize our user acquisition work into three categories.
Big bang
The big bang is when you get a big number of users up front, and then it dries up. An example here would be getting an article in a high-profile newspaper or getting a retweet from Mark Cuban. Yes, you will get some users long after the day of the tweet, but the majority will have come up front. There are a lot of reasons why a big-bang launch can actually have negative effects on your app. First, if you attract the wrong users, they are very likely to uninstall your app. Having a high rate of uninstallations will have a negative effect on your app store optimization. These users will also now be part of any analytics you have set, making it really difficult to know what your actual customers of interest are doing and where they are having problems. It becomes really difficult to know whether your product has a problem retaining the right users or whether you have simply attracted the wrong users, users whom your product was never going to retain.
Long tail
The next is the long tail. The long tail is where you get consistent installations. The sum of future downloads far outweighs the initial impact. Examples of methods here include being featured consistently or getting repeat recommendations.
Chain reaction
The final category, chain reaction, is where getting one installation leads to getting one more. Most social techniques fall into this bracket.
The category we will focus on in this article is the long tail. We are looking for a consistent source of relevant users. The method we used is Google Play store visibility, and our technique is app store optimization (ASO).
Our long-tail method focuses on Google Play visibility. Apple and Google are the gatekeepers. Your app’s survival hinges on how well your app places in their stores. Just like in the supermarket, if your product is not on shelves, it is not going to sell.
There are three methods in Google Play by which your app can be found by potential users. We targeted the third: direct search.
charts
features
direct search
Charts have huge power in influencing users to download. Unfortunately, to target charts is to put the cart before the horse. Get everything else right and you will end up at the top of a chart. Not much we can do here to help with your launch.
The second is to get featured. This is the equivalent of a shop placing your product beside its tills. Expect a lot more impulsive buys, but also expect a higher level of churn. These users are not very targeted and probably only downloaded your product to nose around. Again, targeting this method from launch is difficult. Hopefully, if you have stayed close to the Android guidelines and your build quality is high, Google might give you a nice surprise and feature you prominently in the store.
The third method is direct search. This is where we found our gold. Users who search for something using a term that is relevant to what you are offering are the ones you are after. Who better to find your product than people who are actually looking for it. Imagine if you built an app that taught users how to draw, and when any user searches for “learn how to draw,” your app is the first they see. That is a good place to be. The challenge here is all of those other pesky apps that want to get in front of those users. So, let’s see what happens when you search for “learn how to draw” in the Play store.
Boom! There it is.
4 Learn How to Draw appears first for the search term “learn how to draw.”
The images above give a good view of the app’s position in Play at one point in time. Seeing your own progress, good or bad, is critical to understand how your ASO is helping.
8 Learn How to Draw’s position in Play over time for the search query “learn how to draw.” The green lines shows its position (first every week). (Source: Sensor Tower15129) (View large version10)
ASO is a little like throwing mud at the wall in the dark. This is simply the way it has to be. Google’s methods for ranking search results are a close-kept secret. I’d like to think that everything in the list below helped, but to what degree we will never know. It is clear that content is key when it comes to ASO, but this is a luxury I do not have because the content in my app is rarely updated. Below is a list of methods I did use.
This is the one I am most proud of. The name Learn How to Draw covers so many good search phases. It covers “learn how to draw,” “learn to draw,” “how to draw” and “draw” all in one name. The only time I would ever consider using a name like “Drawful” is if I had such a strong brand and marketing team that people would actually look for that specific product. Not likely for most of us.
The thing to remember about the build name is that Google uses it to create your unique URL, among other things. Google is a big fan of using URLs in its search rankings. This was a technique used in the early days of the web and was fazed out by Google because people started to take advantage of it. This will probably happen on mobile, so use it while you can. Here, you can see that I use all of the keywords of interest:
This one is obvious, but people still tend not to consider ASO when writing it. The “Title,” “Short description” and “Full description” all play a part.
Updating the app is a good opportunity to get creative. The primary purpose of the text accompanying an app update is to let users know what is in the latest update. That shouldn’t stop you from being creative.
A high rating is critical to strong ASO. We look after every review, trying to move three stars to four and four stars to five. We now have a really solid 4.488 out of 5 rating, which puts us in a far better light than the competition. A second tip here is always to use your response to feedback as another opportunity to get creative with wording.
If you have read anything about traditional web search optimization, then you will know that getting links to your content from high-quality sources plays a key part in Google’s magical algorithms. The same goes for ASO. Anytime someone writes about our app Learn How to Draw, I always contact them and ask them to link to our page in the app store, using as many of our keywords in their anchor text as possible.
Getting users to your Play store page is half the battle. Now you need to get them to download your app. Our goal here was to give users a clear understanding of why they should download our app by using strong app screenshots and a video montage demonstrating the value of the app. Even with all of this work, we still seem to be failing in this step. Only 17% of users who we get to our Play store page go on to install the app. Definitely room for improvement here.
The first graph below shows installations. Here, you can see a nice consistent installation rate. Our rate is currently at 1000 new installations per day — again, with zero marketing.
There you have it. 100,000 installations in eight weeks by following the techniques above. Start throwing mud, and let us know if you get any to stick.
Most travellers make last-minute decisions, even though they spend significant time researching things to do before embarking on their trip. Finding a hotel and flight is relatively easy, but when it comes to tours and activities, the problem is that late or last-minute bookings are not always available, and if they are, the process of making a purchase online is often hard. The mobile experience can also be limited because many websites are slow or their booking process is long and complex.
In this article, we’ll present a case study and share observations on the project we designed and built, GetLocal1, an online travel-agency and booking platform in Iceland. We will share how we created a booking platform that tackles multiple challenges faced by mobile users, by building a responsive website with super-fast search and a mobile-optimized booking experience. Although this article focuses on travel, designers and developers can apply what we’ve learned to any type of e-commerce and mobile search.
If you happen to be planing your next mobile e-commerce website, keep in mind that there are many things to consider before getting started, and questions that you need to ask yourself. Read more →2
We started by writing a business plan outlining the problems we wanted to solve. A study by Google3 shows that 85% of travellers make a purchasing decision after arriving at their destination, and 50% use their mobile phone to book. With this in mind, we built multiple use cases catering to different personas. The hardest problem we needed to solve was for the people on the road who were using a mobile device with a slow connection and who needed to find a specific activity with last-minute availability and who needed to be able to finalize their booking online.
4 Our own vision of the customer journey, where excitement and mobile usage increase upon arrival at the destination.
Imagine a group of friends travelling down the south coast of Iceland, famous for its waterfalls and black-sand beaches. It’s 10:00 am, and the group wants to use the opportunity to book a glacial hike on a nearby glacier named Sólheimajökull; they need to find a tour with a certified glacial guide who is able to fit them in an afternoon tour on the same day. They have a mobile phone connected to a wireless router that came with the rental car, but in the countryside they’ll be lucky if they find a solid 3G connection. They want to book online and secure their spot.
5 Searching for a glacier tour with multiple attributes on GetLocal.is. (View large version6)
To us, designing for mobile goes beyond visual design. We look at everything from rendering speed to every single piece of content. From the beginning, GetLocal was designed mobile-first. From the first wireframe drawing to the high-definition designs in Sketch, we kept the mobile experience at the forefront.
Having this in mind helped us to simplify the navigation, as well as the information architecture; it also meant that all elements were designed for touch and that we use mobile design patterns such as horizontal sliding. We also had to overwrite many native form elements and replace them with simpler menus that are easier to use.
7 The first version of the booking UI where you would need to click, scroll and click to change the number of adults. (View large version8)9 The current version requires only a single click and doesn’t need native browser elements, making it easier to use on mobile. (View large version10)
If you compare our desktop version to the mobile version, you can see that we simply copied the mobile booking form to the desktop version. That wasn’t the plan, but once the mobile version was made, we didn’t see a need to create a different experience for the desktop.
11 Tour detail page on desktop using the same booking UI as the mobile version. (View large version12)13 The main call to action is always prominent and accessible. (View large version14)15 The mobile booking form highlights the availability on individual days. (View large version16)
The booking form queries real-time availability APIs and immediately informs you of the availability on each day. If a departure has fewer than 10 seats left, we tell you exactly how many can be booked. We do this by connecting to various inventory solutions. Once a product is loaded, we call the API and get the available days, along with the number of seats that are left. This allows us to disable days that have no inventory and show the customer how many seats are left.
Having this direct access in real time saves the user the frustration of not having to start a booking process only to find out that what they want is sold out or not available on their preferred date.
We wanted our customers to get the feeling that our website is super-fast, and we wanted to crack the 1-second start rendering time. It’s not an easy task, especially when you have a very visual website loaded with beautiful images.
We challenged our lead front-end developer, Alpesh Prajapati17 from Gateway Technolabs, to cut requests by 40% and increase the rendering speed by 60%. We wanted to be four times faster than our main competitors. To begin with, he thought it was crazy to set such an ambitious goal, but once we started scrutinizing everything we had made so far, we kept finding ways to improve and move closer to our goals.
After pushing ourselves as far as we could, we hired Harry Roberts18 to audit performance for us. Harry provided a very deep analysis and pointed out a few places where we could do better. As a result, we modified our caching strategy and refactored some of our CSS, leading to even further improvements.
We switched over to HTTP/2 in order to load requests in parallel. However, because each request from the server to the client still takes time, we reduced the number of requests by merging and compressing CSS and JavaScript files, using sprites for icons, etc. The merging and compression bring some overhead to development during updates and releases, but they’re still worth it.
We also broke up the JavaScript and CSS files to load only what is necessary on pages; for example, the CSS and JavaScript required for a calendar isn’t needed on our blog. We also removed some libraries that we were using in the beginning because we found a way around them; for example, we dropped Font Awesome, as awesome as it is.
We use a lot of images and we found that Photoshop and Sketch didn’t compress them highly enough. We started passing all images through ImageOptim19 (Mac only), and then we integrated our CMS with the ImageOptim web service20, so all images that are uploaded go through proper compression before being stored and published on our CDN.
21 Results after compressing high-resolution images in this article through ImageOptim. (View large version22)
Although compression of the images reduced the sizes a lot, we knew that serving images in different sizes based on the screen size of the device would help further. This also enables us to adjust the cropping point and even to serve different images to different devices to make the best use of the space.
We use the picture element to serve the right-sized image at different breakpoints.
For each image, we create versions 480, 780, 1200 and 2560 pixels wide. We use a Slack template to position and crop hero banners in the best way for common screen sizes, sometimes using different images if they fit better.
We preload the hero banner and serve the best-fitting size inline in the header, for optimum size and design (although preload is not supported25 by all browsers).
We have customers from all over the world, and we want customers from Brazil, Australia and China to experience the same speed as customers from Europe. All common files except critical CSS and JavaScript files are stored on Amazon’s S3, served through the CloudFront content delivery network (CDN). For most files, we set the browser cache to be immutable, which basically means that the browser will never try to fetch that file again. In order to break that cache, we change the version numbers of the files. As a backup for browsers that don’t support immutable caching, we set an expiry date very far into the future.
We use Redis26 for server-side caching for the majority of our pages, but we don’t cache everything because the inventory checks need to be live and are populated via AJAX.
When a page loads, we:
get the product details,
load the reviews,
call the real-time availability APIs and populate the calendar,
Speed has a lot to do with perception. Being able to start rendering a page within a second is important because it gives the impression that it is fast, even if the full rendering time is slower.
29 Results from a performance test on WebPagetest.org. The B grade is due to third-party scripts. (View large version30)
We do this by taking parts of our main CSS file, just what is needed to render the first part of the page, and include it in the head of our template, which allows the browser to start rendering the page, even though it hasn’t downloaded all of the CSS. Loading CSS files causes render-blocking, so we load the full style sheets asynchronously using loadCSS31.
Optimizing is a bit like going on a diet: Once you reach your goal, you tend to start slacking off and forgetting to optimize. Speed is one of our main features, so we often check to make sure we are still in good health. We use Pingdom’s speed tester32 to automatically test various pages and send us weekly results; this alerts us if something goes wrong or we become forgetful.
We’ve used Lighthouse33, WebPagetest34 and Google’s PageSpeed Insights35 to better understand what we can do to improve our website. We recommend finding a benchmark, setting a goal and optimizing until you reach that point.
Check out some of the performance articles on Smashing Magazine36. There are also a lot of great videos37 and books38 out there on the subject. Don’t be shy to hire experts to perform an audit or give you advice. This subject is really tricky and requires a lot of specialization.
Shortly after going live, we realized that one of our biggest challenges was to find tours with availability. In a relatively small market like Iceland’s, where tourism has been growing more than 20% per year, it’s become increasingly difficult to find available seats close to departure, especially on the more popular tours. We are not a meta search engine, and we integrate directly on top of inventory solutions. We handle the full lifecycle, from search to booking. So, rather than handing off the customer to another sales platform with an affiliation key, we are able to follow the customer through the purchasing funnel, making sure that every step is optimized.
We needed to find a way to map the activities available in our market, so we built a search engine using relative data points, such as location, activity type, price, duration, departure time, vehicle type and sights. Once you start looking into the challenge and throwing booking cutoff times and availability into the mix, the size of the data set starts to grow quite fast.
A tour with three departures a day, 365 days a year, and that contains multiple facets will require over a thousand rows of complex data. Multiply that by a thousand tours and you have over a million rows of data.
With such a large inventory of products on offer but with so many search facets in place (we use over a hundred data points for categorization purposes), we needed to find a solution that not only fulfills our need for speed but also is flexible and scalable enough to handle the load of processing up to a million records in just a few milliseconds.
We thought about building our own search engine and made a few prototypes, but then we came across Algolia and magic started to happen. However, integration with Algolia39 was quite tricky because we needed to design a data set that holds all of the information and facets but with a limitation of 10 KB per record (a limit set by Algolia). We also needed to build custom widgets on top of Algolia’s API because we wanted to use our own designs.
In our database, we store all of the product information that we aggregate from the inventory solutions we integrate with. This includes meta data and descriptions, photos, categorization for the search facets, as well as pricing and availability. This required us to build cron jobs that at certain intervals throughout the day send a request to the APIs of the inventory solutions; these requests check the updated availability for the next few weeks and take in the latest prices. Once an update has been made, we push the changes into Algolia via its API so that the search data set is in sync and shows real-time availability and prices.
The integration of multiple inventory solutions and Algolia was no easy task, but the end result makes us really proud. The search engine delivers a response within 25 milliseconds — it’s almost too fast!
With the result set updating instantly in 25 milliseconds we realized that we need to somehow let the user know that changes have taken place, because the results might appear below the fold.
To work around this problem, we tested using a “Submit” button to mimic a form’s submission, but the button doesn’t really do anything because once any filter is changed, the result set is updated. All the button does is act like an anchor that navigates you down to the result set, thus giving you a feeling that a change has been made in the result set below.
We also tested the yellow fade technique to highlight the change in the result set number, just to let people know that changes have taken place and that the number of results has changed.
Recently, we’ve been experimenting with a sliding panel that appears for two seconds if there is a change in the result set. On mobile, we fix the position of this preview so that people can immediately see the impact their changes have made on the results.
42 Subtle notification of changes in the result set
For us, content is a critical part of design — not only the labels and headings, but also the descriptions of the products we sell. We operate a marketplace, so our suppliers provide us with their own marketing material, including text and images. Because we work with 200 suppliers and have over 1000 tours to sell, you can imagine the vast difference from item to item.
This resulted in our need to rewrite the descriptions for the majority of products we offer. We used the opportunity to enhance the descriptions, making them shorter and more direct. We put ourselves in the shoes of a traveller, reading and trying to understand every product that we sell. What information is necessary, and what is just wasteful fluff? Are key elements missing that we can try to answer, and can we highlight key details that we find important.
This process is slow yet important; it is still in progress, but it enables us to add our personal tone and brand to all of the products we sell. We wanted our tone to be that of a friend or of a friendly local who gives you honest and direct answers, rather than glorifying tourist traps (as magnificent as they might be). This enabled us also to use slightly simpler language, because many of our customers are non-native English speakers. The Hemingway app43 has been a great tool to help us rephrase and form our sentences to make them easier to read and understand.
44 Before and after editing content using the Hemingway app to measure legibility. (View large version45)
E-commerce is full of hurdles, feelings of insecurity, and complex forms and labels. Users often have to to sign up or give away personal information that is not necessarily needed in order to complete their purchase. One small mistake and you’ve lost a customer forever. Our situation is even more difficult because most of our customers only shop once during their stay, so we don’t get much of an opportunity to build a relationship with them.
For this reason, we don’t require anyone to sign up in order to check out or to add a product to their list of favorites. We store their choices in a cookie but allow them to share a link that reveals the contents of their saved list.
46 Users can share their collection of favorite tours without signing up or providing their email address. (View large version47)
We apply the same philosophy to the checkout, having no hidden fees and not asking for any information we don’t need. We explain why we need the information we collect; we auto-suggest country calling codes; and we make sure that the input fields offer the right keyboard format.
48 Make it easier to input a credit-card number using a mobile phone. (View large version49)
For us, there are two major hurdles in e-commerce. The first is getting visitors to give up their email address, and the second is getting their credit card information. We experimented with asking for their credit card first, before asking for their name, phone number and email address. The idea behind that was that if they are willing to cross the biggest hurdle of providing their credit card, then providing the rest wouldn’t be a problem. The experiment was successful, although we didn’t see a significant change in conversions. So, we reverted to the classic approach because it felt more natural.
Building a great mobile experience is really hard and time-consuming, but with enough attention to detail, you can succeed. For us, it’s been only eight months since going live, so we are nowhere near our goal, although we have made good progress.
We’ve managed to prove our case, and currently the majority of our sales (over 70%) take place on mobile and tablet.
Our goal was to go live with a minimum viable product (MVP) in six weeks, including design and development of the first version. In the first version, we had to take a few shortcuts, but we wanted to prove that we were able to convert. We made our first sale, a $2500 snowmobile trip, within two days of going live. Since then, thousands of travellers have used us our service to book their dream vacation. Now we have started to focus on the next phase of our product, so stay tuned.
FullStory helps you build incredible online experiences by capturing every click, swipe, and scroll, then replaying sessions with pixel-perfect clarity.
Being a designer at the moment is great because a wealth of modern design applications are available that let you easily bring your ideas to the screen: Sketch1, Affinity Designer, Adobe XD (beta) and Figma, to name just a few (not to mention the classics, Photoshop and Illustrator). One app that is quite new, though — and perhaps a bit overlooked — is the free Gravit Designer2 app. Gravit gives you all of the tools needed to create functional and elegant screen designs. It can also be used to make icons, designs for print, presentations and much more.
With the recent release of version 3.1, it’s gotten even better: Now you can import your Sketch files into Gravit (similarly to Figma, which also supports3 the new Sketch file4 format), save designs locally or sync them to Gravit Cloud, and get started quickly with design templates. Gravit is free, works on all major OS platforms and is available as both a web and desktop (standalone) app.
Every new tool can feel daunting at the beginning. So, in this tutorial I will walk you through the creation of a neat weather app (designed by Claudia Driemeyer7). You can download the design file8 to inspect it or use it as the base of your own work. (Please remember that you need to select “View” → “View Mode” → “Output View,” so that the overflowing parts of the design are clipped when you initially open the design in Gravit.)
Moving From Photoshop And Illustrator To Sketch Link
If you’re a UI designer and you still haven’t made the transition, it’s worth trying out. In Sketch, you can work with various plugins that automate parts of your workflow and help you work much more efficiently. Read more →9
The first thing you will see when you open Gravit Designer is the start screen, with a broad selection of presets (see figure 2). For the purpose of this tutorial, let’s start with the “Nexus 5” template, which has the common size of 360 × 640 pixels. (Click and select the template from the dropdown.) If you don’t want to limit your imagination, you can also leave the “width” and “height” fields at the top empty, which will create an infinite canvas; going for a fixed-dimension canvas later will be easy: Just enter width and height values.
This initial screen also lets you open files (either from Gravit Cloud or from your computer) and start from a selection of templates.
10 Figure 2: Bottom-left: Start from the “Nexus 5” preset. Top: Leaving “width” and “height” empty will create a design file with an infinite canvas. (View large version11)
After having selected the “Nexus 5” preset, you will be presented with a new “page” (known as an artboard in other design applications) at the center. The page will hold all of the elements of the proposed app. Because it’s an app about weather and a potential user should see the current conditions at a glance, let’s start with a full-sized background image. I’ve prepared a rainy image12, which you can either save to your computer and drag it to the canvas from there, or copy and paste directly from the browser.
This image will create the first entry in the Layers panel (on the left), and it will also be placed in the center area of Gravit Designer, on the canvas (figure 3). In case the image hasn’t been centered to the page, right-click and select “Align” → “Align Center,” followed by “Align Middle.” Alternatively, you can drag the image until the pink smart guides show you this centered position.
Now, switch to the Pointer tool (press V), hold Shift and Alt both to constrain the ratio of the image and to resize it from the center, and drag out the bottom-right handle. It should have a width of about 415 pixels, visible from “Size” → “W” in the Inspector, the right-hand panel of Gravit Designer (figure 3). The image will overflow the page now — to clip it, select “View” → “View Mode” → “Output view.” Another handy option here is “Outline View,” which shows the outlines of the layers only.
Note: Usually, enlarging bitmap images is not a good idea, but as we will be blurring the image later on, this is not so important.
13 Figure 3: Overview of the interface of Gravit Designer. (Please note that all screenshots in this article show the Dark theme. To switch the interface theme in Gravit, select “Edit” → “Settings” from the menu bar. (View large version14)
Now is a good time to save our file. The best way is to save it to Gravit Cloud with the related option in “File” in the menu bar, which makes it available everywhere and on all devices. Want to start the design in the Mac app and keep working in the browser or on Windows? No problem. You just need to create an account, which is only a matter of seconds (you can read more about Gravit Cloud in my overview on Medium15). For the file name, use something like weather-app.
The other option, of course, is to save the file to your computer with “Save to file…” (from the desktop app version) or “Download File…” (from the web app version of Gravit).
Let’s continue with the status bar of the app, whose basic shape is a rectangle. Press R to switch to the Rectangle tool, start to draw in the top-left corner, go all the way to the right, and make it 24 pixels high.
Note: All of these tools (such as the Pointer tool mentioned a little earlier) can also be accessed from the toolbar at the top of Gravit Designer (figure 3)
In case you didn’t get the right dimensions for the rectangle, you can also enter them in the Inspector (the width should be “360.”) The reason we chose exactly 24 pixels is that we will be using an 8-point grid, which prevents an arbitrary placement and sizing of elements. You can display the grid from “View” → “Show Grid” or by pressing Alt + Command + G (or, on Windows and Linux, Alt + Control + G). The actual grid size can be set in the Inspector (“Grid” → “Width and Height”) once you click anywhere outside the page — use “8” for both fields.
16 Figure 4: The background of the status bar (a rectangle shape) placed on the 8-pixel grid. Change the color to white with the color dialog (1); either drag the color picker (2) or select a swatch (3). (View large version17)
Select the rectangle again with a click, and change the color to white. You can do so by clicking on the color field in “Fills” in the Inspector (figure 4, callout 1), which will bring up the color dialog, with many different options. For now, either drag the color picker to the top-left (figure 4, callout 2) or select white from the swatches in the bottom-right (figure 4, callout 3). To let the background image shine through, set the “Opacity” to 50%. Instead of doing that in the color dialog, close it, and enter this value just above the “Fills” area in the Inspector.
Note: The opacity affects the global transparency of the layer, while the “A” field (alpha) in the color dialog sets the opacity of only the current fill. This is especially important because you can add multiple fills with the “+” icon on the right. To delete a fill again, select it with a click and press the trash bin (delete) icon.
Back to the status bar: The next element will be the time, a white text layer with a size of 12 pixels. To add it, switch to the Text tool with T, click in the center of the rectangle, and write “14:00” for example (figure 5). When done, press Esc, set the “Size” to “12” and the font face to “Open Sans” with a “Bold” weight in the Inspector.
Note: Gravit Designer comes with a wide selection of fonts, but you can also bring in your own fonts with “File” → “Import” → “Add fonts…” in the web version; in the desktop app, all fonts on your system can be used out of the box.
18 Figure 5: The text layer for the time; check the Inspector for the correct properties. (Note: I’ve set the color to black for the screenshot, so that the text is properly visible. Use the alignment icons in the top-right to align it to the background.) (View large version19)
Select the time along with the rectangle (hold Shift and click on both), and center them to each other. You can either right-click and select “Align” → “Align Center” and “Align Middle” or use the alignment icons in the top-right — in particular, the fourth and seventh icons from the left. Another option would be to drag the time until the pink smart guides show you this centered position. At the moment, the text layer is barely visible, so we will treat the background image before continuing with the rest of the status bar’s elements.
First, create another full-width rectangle, starting from the top-left, with a height of 376 pixels. Enter the color dialog and, instead of a solid fill, select the second option at the top, a linear gradient (figure 6). It will be created horizontally by default, going from the left to the right. What we want, however, is a vertical gradient, so click on the round arrow pointing to the right twice to rotate it clockwise. The starting color stop of the gradient should still be selected — change its color to #070031 in the “Hex” field. For the other gradient stop, you can use the same color but with 0% alpha.
To blend it in with the image, click anywhere on the rectangle to close the color dialog, and select “Soft Light” from “Blending” right above the “Fills” area in the Inspector.
Note: As with the opacity of a layer, there is a “general” blending, which affects the entire element and how it blends with objects behind it, and a “separate” blending for each fill, which just affects how the various fills interact with each other.
For an even stronger effect, clone this layer with Shift + Command + D (on Windows and Linux, Shift + Control + D). Rename the first rectangle to “Overlay 1” with a double-click in the Layers panel, and the second to “Overlay 2,” select both after holding Shift, and drag them below the other white layer (the background of the status bar). Finally, lock them with a click on the lock symbol so that you don’t interfere with them by accident later on.
20 Figure 6: Create a new rectangle, and change the solid fill to a gradient (click to play video21).
Now to the background image itself. Gravit Designer enables you to directly tweak the colors of a bitmap without needing to fall back on another application. Select the image, click on “Color Adjust” in the Inspector, and change the “Brightness” to “-17%,” the “Contrast” to “27%” and the “Saturation” to “10%” (figure 7). Looks way better, and the time already comes to the fore. Besides this color correction, you have many other filters with which to modify bitmaps. Click on “More” at the bottom of the Inspector, which will show you a comprehensive list of effects to choose from. Be sure also to click on the dropdown at the top.
Back to the background image, where we need to fix one last detail: applying a “Blur” with a “Radius” of “17” (figure 7). To make the white layer of the status bar better blend in with the background image, you can also set its “Blending” to “Soft Light” in the Inspector.
Important: Keep in mind that effects such as blur can slow down Gravit Designer considerably. If you experience this, switch off the effects temporarily with “View → Show Effects” (on a Mac, Command + E, and on Windows and Linux, Control + E).
22 Figure 7: Adapt the image with “Color Adjust,” and apply a Blur effect. More effects are available from the “More” button. (View large version23)
Before we continue with the other elements of the status bar, select its existing parts (the time text layer and background rectangle), and press Command + G (on Windows and Linux, Control + G) to group them, and name this group “Status bar” by double-clicking. This lets you select the entire group, but you can still pick individual elements by holding Command (on Windows and Linux, Control) and clicking on a layer. The same behavior will be enabled with “Click-through this element” in the Inspector.
A handy alternative to using a group is to use a so-called “layer.” (Do not confuse this with a general layer, which is an individual element on the canvas and in the Layers panel.) Add such a layer with a click on the “New Layer” icon (figure 8, callout 1) in the Layers panel. Just like with a group, such a layer (group) also allows you to combine elements but has the following advantages:
You can define a color that is shown for all related elements on the canvas (click on the colored bar on the right side of a layer — see figure 8, callout 2),
You don’t need to hold Command or Control to select an individual layer within the layer (group) on the canvas.
Elements are automatically added to the layer (group) after their creation.
You have a separate “Layer” tool (press M, also available from the “Select” tools in the toolbar) that will let you select the entire Layer group.
If you like, you can add a layer and drag the elements from the group in there (and delete the now empty “Status bar” group with Backspace (or, Windows and Linux, Delete).
24 Figure 8: “Layer” is a special kind of group. Add one with a click on the “New Layer” icon (1). Amongst other advantages, a “layer” lets you define the outline color of its elements (2). (View large version25)
The next element for the status bar is the icon for the receive signal (see figure 9 for the process). We’ve drawn some inspiration from iOS’ icon here with its circles — and although that’s quite a contrast from the typical Android design, it’s the perfect opportunity to show the smart duplicate feature of Gravit Designer (more on that in a minute).
Press E to switch to the Ellipse tool, hold Shift to make it a perfect circle, and add a first circle with a diameter of 6 on the left. Switch off the grid with Alt + Command + G (on Windows and Linux, Alt + Control + G). Give it a white fill.
If you’re having trouble creating such a small element, you can also add it at a bigger size and then bring it down to 6 × 6 using the Inspector. Just be sure that “Keep Ratio” (the small icon between the width and height fields) is enabled. Alternatively, press Z to switch to the Zoom tool and drag a selection in the top-left of the page to enlarge this area.
Getting to the other four circles is easy. First, press Command + D (on Windows and Linux, Control + D) to duplicate the element. Then drag it up, so that it is at the same height as the other circle and has a distance of 1 pixel (the pink smart guides help here). After that, press Command + D again to create three more instances at the same distance. This “smart duplicate” feature works for all kinds of transformations, such as rotations, and always repeats all of the steps between the first and second duplication.
The difference between duplicate (Mac: Command + D, Windows and Linux: Control + D) and clone (Mac: Shift + Command + D, Windows and Linux: Shift + Control + D) is that the former offsets the new layer by 10 pixels in each direction (X, Y) and allows for smart duplication. The latter doesn’t.
Let’s suppose the signal isn’t the best over here. So, select the last two circles and apply a border instead of a fill. Click on the eye icon on the right side of the fill to disable it, and instead add a border with the “+” icon in the “Borders” section below. Also, give it a white color.
This default centered border isn’t suitable, however, so change it to an inside type by clicking on the “Advanced stroke settings” on the right. There, change the “Position” to the first icon. For the border width, pick “0.5.”
There are several ways to change a value in an input field in Gravit:
Click inside an input field, type the desired value, and press Enter.
Use the up or down arrow key on the keyboard to increase or decrease the value by 1;
Hold Alt and use the arrow keys to go in increments of 0.1;
Hold Shift and use the arrow keys to go in increments of 10.
For our border, the easiest way is to hold Alt and press the down arrow key five times on the keyboard. (With the rise of high-resolution mobile devices, it’s probably OK to use a half-pixel value here, because it will still appear sharp when exported.)
26 Figure 9: Create the circles, duplicate them, and change from a fill to a border (click to play video27).
Finally, select all circles and perform the following steps:
Create a group with Command + G (on Windows and Linux, Control + G).
Name it “Receive signal” (double-click in the Layers panel to rename).
Drag it into the “Status bar” group.
Move it so that it is 2 grid units (16 pixels) away from the left edge of the page. (You can show the grid again with Alt + Command + G, or on Windows and Linux, Alt + Control + G.) Pressing Alt to display the smart guides will assist you here.
In the vertical direction, center it to the white background (and rename this one to “BG”).
The next element we will tackle is the carrier name (figure 10). Pan a bit to the right (hold the space bar and drag), select the time text layer, hold Alt and drag it to the left to create a duplicate. Make sure that it’s 6 pixels away from the receive signal, change the text to “Gravit,” and the weight to Regular. Do the same for the battery level indicator, but drag it to the right, with “75%” as the content (figure 10). Remember that you can press Esc to leave text-editing mode. Of course, we could take a premade icon for the battery symbol, but where is the fun in that? Let’s give it a try (figure 11).
28 Figure 10: Add the text layers for the carrier name and the battery level indicator. (View large version29)
The first element is a simple rectangle (24 × 10) with a white inside border of 0.5 and rounded corners of “1.” (You can add the rounded corners in “Corners” in the “Appearance” section of the Inspector.)
Clone this rectangle with Shift + Command + D (on Windows and Linux, Shift + Control + D), move it to the left and down by 1 pixel with the arrow keys, and change the size so that it’s 2 pixels smaller in each dimension.
Please note that Gravit Designer supports mathematical operations in input fields, so you can use “+5,” for example, to add 5 to the current value, or “*3” to multiply by 3. In our case, enter “24-2” for the “Width” in the Inspector, and “10-2” for the “Height,” and press “Enter” to get to the desired dimensions.
This second shape should have a white fill, without a border. Also clone it, move it to the right so that its left edge touches the right edge of the bordered shape, and change the size to 1.5 × 4. Center it vertically to the other shapes.
The third shape has rounded corners on all sides now, but we only want them on the right side, so we need to enter the “Advanced Settings” on the right. Uncheck “Uniform Corners” so that you can enter “0” for the top-left and bottom-left corner, and 0.5 for the top-right and bottom-right pendants. Select all three rectangles, combine them into a “Battery” group and drag it into the “Status bar.” Make sure that it is 2 grid units (16 pixels) away from the right edge of the page, vertically centered to the status bar, and that the battery level has a gap of 6 pixels to it.
30 Figure 11: The creation of the battery symbol (click to play video31). Note: I’ve disabled the blur effect with Command + E (on Windows and Linux, Control + E) for performance reasons.
There’s one last thing to manage for the status bar: the Wi-Fi signal indicator (figure 12). We can approach it in two ways. First, a white rectangle. Create one next to the “Gravit” text layer, with a size of 9 × 9 (hold Shift to create a square). Turn it by 45 degrees, either in the Inspector (“Angle” → “R”) or by grabbing the top-most handle on the canvas and holding Shift to constrain the movement to 15-degree steps.
Now we need to convert it to a path (Mac: Shift + Command + P, Windows and Linux: Shift + Control + P, or right-click → “Convert to Path”), so that we are able to manipulate its individual points. Change to the Subselect tool (press D), select the top-most point and click on the second icon at “Joint” in the Inspector. This will convert the former “Straight” point, with no curve, to an evenly rounded “Mirror” point. Increase the curve a bit by dragging out either of the handles to the sides of the point while holding Shift (to keep the movement horizontal), and move it 3 pixels down with the keyboard. Goal accomplished!
Note: The difference between the Pointer tool (V) and the Subselect tool (D) is that the former selects entire shapes or layers, while the latter is mainly used to manipulate an individual point or to show more manipulation options.
The second approach for the Wi-Fi icon would be with the Bezigon tool (figure 12). Keep the icon we just created as a reference, but tone it down to an opacity of 40% in the Inspector. Now, enable the Bezigon tool from the “Path” area in the toolbar (or press B) and make a first click at the bottom-most point of the other Wi-Fi symbol. Make another click at the left-most point, then continue to the top-most point, but hold Alt before you click.
This move is especially vital with the Bezigon tool because it creates a curve that automatically adapts to the surrounding points. Continue at the right-most point, but release Alt again, and finish the shape with a click on the first point at the bottom. You can see how a point that was created with an Alt click of the Bezigon tool adapts automatically if you select the top-most point with the Subselect tool (D) and drag it around.
Keep the version of the icon you like, center it vertically to the status bar, and move it away 6 pixels from the “Gravit” text layer. Finally, rename it to “WiFi” before you drag it into the “Status bar” group. With this last step, we’ve finished the status bar and can turn to the contents of the app.
32 Figure 12: The creation of the icon for the Wi-Fi signal — first, with a rectangle as the base, then with the help of the Bezigon tool. Note: I’ve created a dark shape in the back to increase visibility. (Click to play video33.)
The first element here is the current date (“Friday, Jun 15”), a white text layer with a size of 18 pixels and a “Regular” weight (figure 13). Zoom out to 100% again with Command + 0 (on Windows and Linux, Control + 0), so that the placement becomes easier. Center the text layer to the page and place it on a grid line, about 36 pixels away from the status bar. Hold Alt and drag it to the bottom to create another text layer for the location. Double-click so that you can change it to “Berlin”; for the text size, choose “38.” It should also sit on a grid line right below the date and be centered to the page.
The final text layer we need now is for the temperature (“21 °C”). Proceed as before, but for the font size, you can simply add “*2” to the current value of the input field and press Enter, which will double the size. It should be about 28 pixels away from the other layer.
34 Figure 13: Add three text layers for the date, location and temperature. They should be centered and aligned to the grid. (View large version35)
With this ends the first part of the tutorial. I hope you have enjoyed it so far and that it has given you valuable insight into Gravit Designer, its features and what it can do.
In the second part36, we will look at some more sophisticated techniques, see how we can make the weather icons to create a version of the app with sunny weather, and learn how to export the final design.
If you have questions regarding this tutorial, please leave a comment below and I will gladly help you. And if you have ideas on how Gravit Designer could be further improved, don’t hesitate to reach out to the Gravit team on Twitter37 or on Facebook38, or post your questions and ideas in the Gravit discussion board39. Your feedback would be more than welcome!
If great design can imbue customers with trust, why are designers so removed from product management and the larger business strategy? As a VP of UX with an MBA, I strive to bring both worlds together to create a new model in which user experience and design align with overall business strategy and company vision to drive increased revenue and customer engagement.
1 I formulated a hypothesis: If I were educated in core business skills, I could shift myself (and design teams) from a service to a highly strategic functional asset, driving larger organizational direction. (View large version2)
As the Internet became commercially viable, “first to market” generally prevailed as a dominant corporate strategy. However, as technology has become more open and reusable, product differentiation is now a proven strategic blueprint. This tectonic shift has been a boon for the design discipline. Consequently, design has gotten the proverbial “seat at the table” and is now expected to be a driving, strategic function.
For designers, this is a celebrated, exciting advancement, yet it has also exposed a severe skills gap. Specifically, design leaders are being thrust into overarching, cross-functional executive positions, with little to no formal training in business or strategy skills.
Consider the context: Most BFA and MFA programs don’t cover traditional business skills, and companies certainly aren’t investing in cross-functional training for creative professionals. The resulting condition is tragic: Design teams and leaders are not set up for success and, subsequently, are unable to deliver, thus relegating the collective back to a service function.
I’ve experienced this first-hand. I unexpectedly found myself in boardrooms and strategy sessions armed with nothing more than Photoshop and front-end programming competencies. I knew the value of design work but simply couldn’t articulate it in a convincing and relatable form to a corporate audience.
Designers like to pride themselves on an extensive portfolio, while business folks like to see numbers. With no doubt, speaking in a language the client understands is key to good communication in any business. Read more →3
Out of frustration, I formulated a hypothesis: If I were educated in core business skills, I could shift myself (and design teams) from a service to a highly strategic functional asset, driving larger organizational direction.
Very soon, I found a workable solution: a part-time MBA program where I would study and learn actionable skills of business frameworks and best practices of management. So, for just over three years, I was a senior user experience designer by day and an MBA student by night.
Though I studied many illuminating topics (economics, financial accounting, business law, supply-chain management, corporate ethics) as they relate to design, three particular areas of study were highly impactful: statistical analysis, competitive strategy and organizational management. These subjects were most impactful because, to be candid, I had never studied or considered them at depth professionally. Yet, the more I learned, the greater the impact these courses had on my professional development and approach to design.
4 For just over three years, I was a senior user experience designer by day and an MBA student by night. Armed with this new statistical skill set, I was able to incorporate business thinking as an early step in my design process. (View large version5)
When it came to statistical analysis, as a creative professional, I had an adverse physical reaction to the very idea of spending four months pouring over Excel spreadsheets. In fact, I had done just about everything possible to avoid “math” during my academic and professional career. I was guilty, like so many, of being stuck in the construct of a left-brain and right-brain duality.
It was surprising to me that my first weeks in statistics had very little to do with mathematical calculations, but rather, with theory6. I learned that statistics actually rest upon a singular premise: ratios. If you boil down ratios to their core, it’s basic: X ÷ Y = Z. Simply, you take two forces, stack them against each other, and you achieve an output that is influenced against both forces.
Surprisingly, as a designer, the concepts and application of ratios were very familiar to me. I had comfortably worked with ratios in everyday design tasks (grids, padding, aspect ratios) throughout my career.
As I progressed through the course, week after week, I waded through increasingly complex financial models that leverage statistics. Over time, this repetition built up a muscle, and without even thinking about it, I found myself toying with basic statistical models to help guide my design decisions.
Normally, as a designer, I’d go through my design process (competitive auditing, high-level concepts, interactive wireframes, visual design, usability testing), and leave it to the business unit to figure out the impact on our company and users. Armed with this new statistical skill set, I was able to incorporate business thinking in my design process as an early step.
Let’s consider a simple redesign of a home page. For many designers, this can be very challenging because there are so many competing priorities: search functionality, email registration, illustration of the brand’s value, testimonials, etc.
Prior to using statistical analysis, I’d just try to find a design that represented a compromise for all use cases and moved on. Now, I’ve been able to step back and use statistics to help prioritize my layout. Rather than “just” designing a variant or two, I’m able to provide a thoughtful overview of the revenue impact correlated to my design decisions.
Let’s take a hypothetical example. In a first pass of a design, the layout would prioritize email registration as the primary action for a user. Consequently, this would have the immediate impact of fewer orders. Using standard Google Analytics, I was able to show the potential revenue ripple effects of that approach.
Conversely, for a second pass at the design, my layout would feature a search bar. Of course, this would lead to a decrease in email registrations but would also lift the number of immediate orders, as well as conversions (users would convert better because they found more relevant results).
7 Once I was able to build this sort of analysis into my design practice, more and more of my initiatives got investment. (View large version8)
This is a basic application of a statistical model, but as it scales, it becomes even more powerful for larger design initiatives (launch of an app, new product offering, new checkout page, e-commerce feature, brand campaign). What’s more, the model becomes more specific and predictive the more it’s used.
As I progressed, I was able to genuinely factor in cost reduction9 as a critical variable into my models. Consider a chatbot that can easily answer questions for a customer; that feature cuts down on call-center operations, thus reducing a cost driver to the business. Or consider an engaging feed, constantly being populated by fresh content; this boosts organic repeat visits, reducing pricey SEO spend. Of course, raw revenue generation will always be a key driver for business, but as designers, our work actually has a profound impact on cost reduction for the company. This type of analysis gave financial credibility to design-led projects that would have previously been considered “non-revenue generating.”
In all, once I was able to build this sort of analysis into my design practice, more and more of my initiatives got investment. It became formulaic. I would not only present a jaw-dropping, visually striking design prototype that solved actual customer problems, but would also offer precise measurement and financial gains (or savings) to the company.
Even armed with statistical analysis, I still struggled with the ask to be more “strategic.” But, to be honest, I had no idea what that really meant. How does one actually be strategic? Is it planning? Is it innovation?
In my study of competitive strategies, I read extensively about strategic frameworks to help guide decision-making. In particular, we spent a great deal of time understanding the work of Michael Porter, who is basically the Jony Ive of business thinking.
Porter constructed a simple yet far-reaching structure to guide corporate decision-making (The Economist has a good summary10). It all rests on the premise of achieving an enduring advantage over your competitors (Warren Buffett calls it the moat).11
To summarize, Porter defines the two ways in which an organization can achieve competitive advantage over its rivals: cost advantage and differentiation advantage. In short, to stand apart, you can either have a very different offering or win on price. (Mind Tools has more on this12.) If executed correctly, the business will have achieved a competitive advantage over its competitors.
13 Differentiation is a strong strategic approach, as opposed to cost leadership. We identified a pain point and a product for an emerging customer segment. (View large version14)
Today at Shutterstock, we certainly offer exceptional content at competitive prices, but many in the industry offer similar products. Using Porter’s model, we knew that differentiation would be a strong strategic approach, as opposed to cost leadership. Aligned with traditional user experience and product strategy, we identified a pain point for an emerging customer segment. Customers want to be able to quickly edit and design off our images without leaving the website. From there, our integrated editor15 tool was born. As it moved from beta to production, we have emerged with a highly differentiated experience for a new customer segment.
Porter’s model is powerful for larger-scale strategic initiatives, but is equally important for feature development. How often have we seen decision-makers deploy a strategy to merely copy existing functionality (see Instagram and Snapchat)? To this, Porter would say, “… bad strategy simply ignores competitors; average companies copy; and winning companies lead their competitors.”
From a design standpoint, articulating the flawed logic of replication becomes simple and powerful. A series of designs showing our product changes to be benchmarked to company B’s advantage showed the futility of the effort and how differentiation would never be achieved. In contrast, a differentiated product (alongside a statistical modeling) can clearly illustrate that the optimal path allows for both differentiation and long-term revenue gain.
Designers are natural optimists. Where others see disorganization, designers see the prospect of beauty. Where others wish to cut corners, designers take pride in completeness and quality. Moreover, designers are problem solvers, collaborators and, yes, a bit eccentric, too! We are the people who are wanted — who are needed — to be constant, positive creative, cultural and strategic forces within companies.
However, I would argue that while we can be epicenters of culture and innovation, our discipline hasn’t devoted much attention to successful management of our organizations. Far too often, we manage work, not the individual or the collective.
16 Design hasn’t devoted much attention to successful management of our organizations. Far too often, we manage work, not the individual or the collective. (View large version17)
For me, a breakthrough in thinking about how to structure design departments was found in the work of Edward Deming18, often referred to as the father of quality.
Deming, an academic who was brought to Japan in the 1950s following World War II, is credited with being a leading figure in post-war Japan’s economic rise. Deming based his entire business philosophy on an ideal of cooperation and complete employee fulfillment. Much of his experience and life work were codified in his brilliant 14 points19.
To me, these 14 points are an exact blueprint for how to build and scale a thriving design organization. I encourage every reader to share these with their teams and to ask for a grade on each point. I promise that you’ll find immediate areas of opportunity. If you commit to the changes, you will have all the guidance needed to build a connected, high-morale and thriving organization.
I would like to leave you with Deming’s final point, point 14: “Put everybody in the company to work to accomplish the transformation. The transformation is everybody’s job.”
To me, this point — and my entire MBA experience — reaffirmed that the foundation of design thinking, customer empathy and long-term vision is, in fact, the foundation of an enduring corporate strategy. Far too often in today’s economy, strategy is subject to the whims of short-term gains, which, over time, comes back to haunt company and consumer alike. Or, inversely, as the adage goes, if you solve your customer’s problems, they’ll solve your business problems.
I’ll end with this: Invest in yourself. Invest in learning new skills. Invest in your design team. When you do, you’ll see great returns for yourself, the team, the customer and the business.
UX design hasn’t been the same since Sketch arrived on the scene. The app has delivered a robust design platform with a refreshing, simple user interface. A good product on its own, it achieved critical success by being extended with community plugins.
The open nature of the Sketch plugin system means that anyone can identify a need, write a plugin and share it with the community. A major barrier is stopping those eager to take part: Designers and front-end developers must learn how to write a plugin. Unfortunately, Objective-C is difficult to learn!
What if users could write plugins using technologies they are already familiar with? This tutorial covers the usage of WebView technology to create a plugin using HTML, CSS and JavaScript.
This introduction to Sketch development teaches you by creating a sample plugin. This plugin is dubbed “Symbol Export.” It’s a simple tool to export document symbols to image files. A mockup of what you’ll create is below.
For the purpose of learning, the end product won’t be aesthetically pleasing. The demo will be simplistic, but you are encouraged to spice it up with your own HTML, CSS and JavaScript.
Be warned: While the tutorial leans heavily on front-end technologies to reduce the learning barrier, some Objective-C and Cocoa concepts must still be learned.
Sketch plugins are typically created using Objective-C and CocoaScript. These technologies can be confusing, and often downright frustrating, to learn for beginners. So, although developers must still know the basics to create a plugin, the difficulty will be mitigated by using WebViews.
Simply put, a WebView is a web browser. With WebView, instead of learning how to create layouts in Objective-C, you can use JavaScript, HTML and CSS. Much like a real browser, developers also get access to the powerful developer console to troubleshoot and prototype with.
You might already be familiar with WebViews in hybrid app development! The concept is the same: Barriers are removed through the use of technologies that developers are already familiar with. We will lean heavily on the WebView to meet all interface requirements.
Think of Sketch and the WebView as two separate entities. Sketch provides data to the interface, monitoring for events, and any system-level logic such as reading and writing to files. The WebView is responsible for rendering the interface and communicating events back to Sketch.
For this tutorial, we will create a Sketch plugin that lets designers export all document symbols as images. When a user presses a shortcut, they will see an interface showing all symbols to export. Clicking on an “Export” button will perform the export and close the plugin’s interface.
Sketch plugins are bundles of files set up as macOS bundles. Similar to a ZIP archive, a bundle appears as a single file but is actually made up of many. Let’s create our Sketch bundle now.
// Go to your Sketch plugins folder. // Replace {{User}} below with your Mac user name cd /Users/{{User}}/Library/Application Support/com.bohemiancoding.sketch3/Plugins/ // Create the folder with the .sketchplugin suffix mkdir SymbolExport.sketchplugin
You may now open the folder you just created with your favorite text editor. You may also consider adding a shortcut to this folder on your desktop for quick access.
Meta data for the plugin, similar to package.json for npm.
app.cocoascript
The file to run when the plugin is activated.
At a bare minimum, every Sketch plugin requires a manifest.json file and a file to call when the plugin is initiated. Beyond these requirements, any directory or file structure may be used.
Fill out meta data above to reflect your name and email address. Pay special attention to the commands array: This is where we tell Sketch the file and function to run and which shortcut to respond to.
Next, create app.cocoascript with the contents below:
/** * onRun * * Bootstraps the Sketch plugin when the user calls the plugin. * This method runs every time the plugin shortcut or menu item is fired. * * @param {object} context A generic object Sketch provides with information on the currently running Sketch instance. */ function onRun(context) { context.document.displayMessage('Hello there!'); }
Time for testing! Create a new Sketch project to see our hard work in action. You can initiate your plugin with the shortcut or by looking under the “Plugins” menu option. If all went well, you should see the message “Hello there!” at the bottom of your Sketch window each time the plugin is called.
A Primer On Sketch, Objective-C And CocoaScript Link
To be effective in creating a Sketch plugin, a developer must know the system APIs available for accessing user data. First, a short history lesson.
Objective-C was released in the 1980s as a general-purpose programming language. It’s since been used to create full-fledged applications for Apple products. Being an older language, Objective-C isn’t as intuitive as more modern ones.
Cocoa is a framework created to make working with Objective-C easier. Think of it as a library of APIs that streamline actions in Objective-C. You can often recognize Cocoa code by the NS naming convention: NSString, NSObject, NSWindow and others. This comes from its original name, NextStep.
CocoaScript is a bridge between JavaScript and Cocoa. It allows for scripting in Cocoa without needing to know as much of the language. CocoaScript simplifies the process of Objective-C development but is not a complete abstraction: Developers must still be aware of Cocoa APIs to create a Sketch plugin.
You can see an example of CocoaScript below. Don’t worry: If this is slightly confusing, that’s all right. Picking up small bits of Cocoa and CocoaScript will happen naturally as we create the Sketch plugin.
/** * Example of Objective-C/Cocoa and CocoaScript in action * * Saves a JavaScript object as a json file */ // A JavaScript object turned into a JSON string var userConfigToSave = JSON.stringify({ name: 'John Doe' }); // Convert the JavaScript string to a Cocoa string (note NS prefix) var userConfigNSString = [NSString stringWithFormat: "%@", userConfigToSave]; // The path to save the file to var savePath = '/path/to/userConfig.json'; // A Cocoa system call to save the file [userConfigNSString writeToFile:savePath atomically:true encoding:NSUTF8StringEncoding error:nil];
Our main plugin class will eventually have many JavaScript methods. Understanding the flow of the application will be easier if the logic is moved to a separate file. Change the contents of app.cocoascript to the contents below:
@import 'app/SketchPlugin.cocoascript'; /** * @type {SketchPlugin} The Sketch plugin app class. */ var plugin = new SketchPlugin(); /** * onRun * * Bootstraps the Sketch plugin when the user calls the plugin. * This method runs every time the plugin shortcut or menu item is fired. * * @param {object} context A generic object Sketch provides with information on the currently running Sketch instance. */ function onRun(context) { plugin.init(context); }
For the rest of development, our app.cocoascript file will stay the same. Its only responsibility is to load the SketchPlugin class, initialize it and then run it when the user calls the plugin.
Note the context parameter. This is a plain JavaScript object containing information on the currently running Sketch instance. It’s used to get file path information, user settings and other meta data.
On line 1, an import call is made to an uncreated file. Now, create the app folder and the SketchPlugin.cocoascript file inside it. Your directory structure should match what is below.
Add the code below to the SketchPlugin class created. The code represents a skeleton class; it doesn’t do anything useful quite yet.
/** * SketchPlugin Class * * Manages CocoaScript code for our plugin. * * @constructor */ function SketchPlugin() { // The Sketch context this.context = {}; } /** * Init * * Sets the current app and plugin context, then renders the plugin. * * @param {object} sketchContext An object provided by Sketch with information on the currently running app and plugin. * @returns {SketchPlugin} */ SketchPlugin.prototype.init = function(context) { this.context = context; return this; }
Rendering the WebView is a simple three-step process. Create a containing window, create a frame for the WebView and, finally, have the WebView load an HTML file.
A window in Cocoa is an NSWindow object. The window will be used as a container for the WebView and its frame. See the annotated code below for a new method to add to the SketchPlugin class.
SketchPlugin.prototype.init = function(context) { this.context = context; // Create a window this.createWindow(); // Blastoff! Run the plugin. [NSApp run]; return this; } /** * Create Window * * Creates an [NSWindow] object to hold a WebView in. */ SketchPlugin.prototype.createWindow = function() { this.window = [[[NSWindow alloc] initWithContentRect:NSMakeRect(0, 0, 800, 800) styleMask:NSTitledWindowMask | NSClosableWindowMask backing:NSBackingStoreBuffered defer:false ] autorelease]; this.window.center(); this.window.makeKeyAndOrderFront_(this.window); return this; };
The new createWindow method introduces the NSWindow Cocoa object. With it, we are able to create a window with many different options. Some of those are worth explaining because the methods aren’t entirely obvious.
[[[NSWindow alloc] creates an NSWindow object. An important property here is alloc, which allocates memory to the window. Without it, we couldn’t interact with the window.
JavaScript developers might be unfamiliar with memory management. In JavaScript, a “garbage collector” automatically releases objects in memory that are not in use. Unfortunately, a little extra leg work is required for Objective-C.
Think of alloc as telling the system, “Please keep this object around. I’m not done using it.” And after, it follows up with, “I’m done with this object. Please free the memory space it was using.”
So, when do you explicitly allocate memory to an object? For most actions in CocoaScript, this will only be required for window objects that you want to keep around. For now, you only need to be familiar with the concept.
initWithContentRect:NSMakeRect(0, 0, 800, 800) creates the window with the specified position and height. NSMakeRect‘s parameters are set as x, y, width, height.
X and Y values are ignored here because we’re calling this.window.center() below it, which automatically sets these values for us.
styleMask:NSTitledWindowMask | NSClosableWindowMask sets the style of the window. It’s possible to set whether or not a user can close the window, to set a window title and to set other style options.
For this project, we will use a title bar and allow the user to close the window. Note that we have not declared support for resizing the window or minimizing it.
backing:NSBackingStoreBuffered defer:false are two options that specify how the window is rendered. defer:false says we want to create the window object now, not later. And the backing type specifies how the window contents are drawn in memory. Always use NSBackingStoreBuffered, which specifies that a memory buffer should be used. That’s what the system is optimized for, and it is the most performant.
] autorelease]; states that the window object should be cleared from memory when it’s closed (remember when we used alloc?). Recall that memory management is important in Cocoa and Objective-C. If objects are not released after being used, the app might crash from a lack of memory. This unfortunate scenario is referred to as a memory leak.
centers the window and also makes it the key window.
A “key window” is the window that responds to key events. Think of it as the active window.
In addition to adding this method, review the init method: We’ve called createWindow and also added a call to [NSApp run], which launches our window.
Now, review the changes made to the init method. A createWindow call was added, as well as the [NSApp run] line. The call to NSApp runs our plugin and starts listening to events. The plugin does not stop until NSApp receives a message to terminate. In this case, the run command shows the window; clicking the close button on the window sends the “terminate!” message and releases our plugin from memory.
It’s worth pointing out line 17 as an alternative CocoaScript syntax — it certainly feels more like JavaScript! The style is often a matter personal preference, but being familiar with both forms will help you read the code of others.
We could just as easily have written the following code instead:
Don’t feel you need to know the names of objects, the methods or the syntax. For now, we only need to know that the WebView is working. Resources to learn more are listed at the end of this article.
Remember to add the call to createWebView in the init method. It should get called after the window is created:
// Create a window this.createWindow(); // Create a WebView this.createWebView();
Create the HTML Layout
If you peeked at the previous code closely, then you saw reference to an HTML file that doesn’t yet exist. Create a webview folder and an index file now.
21 Current directory structure for the WebView layout
So far, we have a working WebView to use as an interface but no data to fill it with. Next, let’s see how to communicate data between Sketch and the WebView.
This plugin will render a list of symbol data for previewing before exporting. To do that, we need to get the data from Sketch and then communicate it to the WebView.
Several options exist to communicate a large amount of data to a WebView. Keep in mind that it’s a requirement that the end user thinks the WebView is a native application, which is to say that all data should load instantaneously. The easiest means of meeting this requirement is by precompiling symbol data to a file before loading the request, then including the data as a JavaScript script.
25 Communication of data between Sketch and WebView
Other options for communicating data do exist. One way is to set JavaScript variables through CocoaScript once the WebView loads. Unfortunately, this does add a slight lag, thus failing our requirement for a native-like experience.
How to Fetch Sketch Symbol Data
The first step is to grab all symbol data from Sketch. Add the following method to your file:
/** * Get All Document Symbols * * Gets every symbol in the document (in all pages, artboards, etc) * * @returns {Array} An array of MSSymbolMaster objects. */ SketchPlugin.prototype.getAllDocumentSymbols = function() { var pages = this.context.document.pages(); var symbols = []; // Loop through all pages for (var i = 0; i < pages.count(); i++) { var page = pages.objectAtIndex(i); // Loop through all artboard layers for (var k = 0; k < page.layers().count(); k++) { var layer = page.layers().objectAtIndex(k); if ('MSSymbolMaster' == layer.class()) { symbols.push(layer); } } } return symbols; }
Sketch has many helper methods to access data in the current document. Sometimes, developers will need to do some heavy lifting, as is the case here. No helper method exists to grab all master symbols data in all pages. As a result, we must loop through data that Sketch does provide in order to find what we need.
It’s worth noting the check for MSSymbolMaster on line 20. This differs from a symbol instance in that the master is what each instance references as the original copy. If, instead, we checked for any symbol type, we would have duplicates!
Methods such as context.document.pages() and type definitions such as MSSymbolMaster are detailed in Sketch’s documentation28. Often you may find Sketch’s documentation lacking. More resources for finding what you need are included at the end of this tutorial.
Create the JavaScript File for Storing Symbols Data
Following the illustration, this step requires that we create a JavaScript file and fill it with symbol data. Add the following method to your plugin file:
/** * Create Symbols JavaScript File * * Creates a JavaScript file representing all document master symbols. * This data is consumed by the WebView for rendering symbol information. * * Generated file path: * Contents/Sketch/app/webview/symbolData.js * * @returns {SketchPlugin} * @method */ SketchPlugin.prototype.createSymbolsJavaScriptFile = function() { /** * Build the content for the JavaScript file */ var webviewSymbols = []; this.documentSymbols = this.getAllDocumentSymbols(); // Push all document symbols to an array of symbol objects for (var i = 0; i < this.documentSymbols.length; i++) { var symbol = this.documentSymbols[i]; webviewSymbols.push({ name: '' + symbol.name(), symbolId: '' + symbol.symbolID(), symbolIndex: i }); } /** * Create The JavaScript File, then fill it with symbol data */ var jsContent = 'var symbolData = ' + JSON.stringify(webviewSymbols) + ';'; var jsContentNSSString = [NSString stringWithFormat:"%@", jsContent]; var jsContentFilePath = this.context.scriptPath.stringByDeletingLastPathComponent() + '/app/webview/symbolData.js'; [jsContentNSSString writeToFile:jsContentFilePath atomically:true encoding:NSUTF8StringEncoding error:nil]; return this; };
The method loops through all document symbols, creates a new array of objects and then saves to the file path specified. Let’s review two items that could use more explanation.
webviewSymbols.push({ name: '' + symbol.name(),
This code sample is an example of where JavaScript and Cocoa sometimes clash types. The return value of symbol.name() is a Cocoa object. Without casting to a JavaScript string, nothing at all would be assigned to name!
The '' + [Object] line is shorthand for casting the value to a JavaScript string.
You will not get an exception when an unexpected type conversion doesn’t occur. Avoid bugs by being aware of each object type and documenting them in your code.
This code shows a common means of saving contents to a file. Developers do not always need to understand the underlying methods. Instead, think of some Cocoa code as a code recipe: Use this code as a template and switch out the file path and content value.
Indeed, much of CocoaScript code can be abstracted into a library for large projects.
function saveFile(string, path) { // Cocoa code goes here }
For larger Sketch plugins, consider adding abstractions like saveFile above into a utility class.
As usual, call the new createSymbolsJavaScriptFile code in the init method. Add it before the WebView is created:
SketchPlugin.prototype.init = function(context) { this.context = context; // Generate symbol data for the webview this.createSymbolsJavaScriptFile(); // Create a window this.createWindow(); // Create a WebView this.createWebView();
Running Sketch and calling the plugin now creates the JavaScript data file for us. Give it a shot! If you don’t see any generated, ensure that you have created at least one master symbol object in Sketch.
Communicating data to the WebView from Sketch was easy enough. Communicating events from the WebView to Sketch, such as a click event, requires slightly more work.
WebView Design Update
The fun in working with WebViews is that developers have full access to all CSS and JavaScript libraries desired. You should feel right at home in creating the interface. For simplicity’s sake, we won’t include any additional front-end frameworks. Instead, let’s go relive 1995.
<!doctype html> <html> <head> <script src="symbolData.js"></script> </head> <body> <!-- Header --> <h1>Export All Symbols as Assets</h1> <button>Export Now</button> <hr/> <!-- Symbols List --> <div></div> <script> var symbolListDiv = document.getElementById('symbol-list'); /** * Add all symbol data to the interface */ // Ensure symbols exist if (typeof symbolData !== 'undefined' && true === Array.isArray(symbolData) && symbolData.length) { // Append each symbol as a new div for (var i = 0; i < symbolData.length; i++) { var newDiv = document.createElement('div'); var newDivHdg = document.createElement('h3'); var symbolNameNode = document.createTextNode(symbolData[i].name); newDivHdg.appendChild(symbolNameNode); newDiv.appendChild(newDivHdg); symbolListDiv.appendChild(newDiv); } } else { symbolListDiv.innerText = 'No symbols found!'; } </script> </body> </html>
Should any design issues arise, recall that you have full access to the “Developer Console.”
Intercepting WebView Events in CocoaScript
With the stunning WebView design in place, it’s time to communicate back to Sketch when the export button is clicked.
The most reliable way to communicate a WebView event is slightly convoluted. The solution is to redirect the URL when a desired event is fired, intercept the request and then run CocoaScript code instead.
Why so confusing? You’d expect better event management in communication to a WebView. However, in CocoaScript, we have limited access to event handlers. No listener for “the user clicked something on the WebView” exists. The solution adopted is possible due to a CocoaScript event that is called any time the WebView changes its URL.
So far, the word “event” has been used to describe listeners in Objective-C. It’s time to learn about proper terminology: delegates. A “delegate” is an object that acts on another object’s behalf. It can receive messages and specify a callback when a certain message is sent. Put very simply, think of delegates as event listeners and handlers in JavaScript. From here on out, we will use the term “delegate” to refer to events on the Objective-C side.
To intercept the WebView redirect, create a delegate and assign it to the WebView. Add the createWebViewRedirectDelegate method below to your class file.
/** * Create Webview Redirect Delegate * * Creates a Cocoa delegate class, then registers a callback for the redirection event. */ SketchPlugin.prototype.createWebViewRedirectDelegate = function() { /** * Create a Delegate class and register it */ var className = 'MochaJSDelegate_DynamicClass_SymbolUI_WebviewRedirectDelegate' + NSUUID.UUID().UUIDString(); var delegateClassDesc = MOClassDescription.allocateDescriptionForClassWithName_superclass_(className, NSObject); delegateClassDesc.registerClass(); /** * Register the "event" to respond to and specify the callback function */ var redirectEventSelector = NSSelectorFromString('webView:willPerformClientRedirectToURL:delay:fireDate:forFrame:'); delegateClassDesc.addInstanceMethodWithSelector_function_( // The "event" - the WebView is about to redirect soon NSSelectorFromString('webView:willPerformClientRedirectToURL:delay:fireDate:forFrame:'), // The "listener" - a callback function to fire function(sender, URL) { // Ensure its the URL we want to respond to. // You can also fire different methods based on the URL if you have multiple events. if ('https://localhost:8080/symbolexport' != URL) { return; } // A special method to export symbols - we haven't created it yet this.exportAllSymbolsToImages(); }.bind(this) ); // Associate the new delegate to the WebView we already created this.webView.setFrameLoadDelegate_( NSClassFromString(className).new() ); return this; };
This is the most complex part of the tutorial for anyone without Objective-C and Cocoa experience. Let’s look at some of the lines and explain further.
/** * Create a Delegate class and register it */ var className = 'MochaJSDelegate_DynamicClass_SymbolUI_WebviewRedirectDelegate' + NSUUID.UUID().UUIDString(); var delegateClassDesc = MOClassDescription.allocateDescriptionForClassWithName_superclass_(className, NSObject); delegateClassDesc.registerClass();
Because we don’t have a simple abstraction to work with delegates, any delegate code will require some basic knowledge of Cocoa.
This code creates a new Cocoa delegate class. It’s important to note that some CocoaScript development involves quirks. On line 48, we see an example of this: Any class name registered through CocoaScript that isn’t unique will crash the application. This appears to be an issue with memory allocation at runtime. The simple solution is to append a unique string at the end of the class name we choose.
As you learn CocoaScript, you might come across some odd workarounds like this:
/** * Register the "event" to respond to and specify the callback function */ var redirectEventSelector = NSSelectorFromString('webView:willPerformClientRedirectToURL:delay:fireDate:forFrame:'); delegateClassDesc.addInstanceMethodWithSelector_function_( // The "event" - the WebView is about to redirect soon NSSelectorFromString('webView:willPerformClientRedirectToURL:delay:fireDate:forFrame:'), // The "listener" - a callback function to fire function(sender, URL) { // Ensure its the URL we want to respond to. // You can also fire different methods based on the URL if you have multiple events. if ('https://localhost:8080/symbolexport' != URL) { return; } // A special method to export symbols - we haven't created it yet this.exportAllSymbolsToImages(); }.bind(this)); // Associate the new delegate to the WebView we already created this.webView.setFrameLoadDelegate_( NSClassFromString(className).new());
Think of this code portion as a simple JavaScript event callback — the NSSelectorFromString being the event, and the anonymous function being the callback to run.
In the callback, notice the reference to another method, exportAllSymbols, that is not created just yet — we will create it in the next step.
// Associate the a new delegate instance to the WebView this.webView.setFrameLoadDelegate_(NSClassFromString(className).new());
The setFrameLoadDelegate_ method on our WebView allows us to associate a delegate.
This line creates a new instance of the delegate class, and it tells the WebView we want to use it to intercept events.
Take a deep breath and exhale: The most difficult part is over. Finally, add a call to the method that we just created inside the createWebView function.
// Create the WebView, frame, and set content this.webView = WebView.new(); this.webView.initWithFrame(webviewFrame); this.webView.mainFrame().loadRequest(urlRequest); this.window.contentView().addSubview(this.webView); // Assign a redirect delegate to the WebView this.createWebViewRedirectDelegate(); return this; }
The last step in this tutorial is to export all document symbols as images. Create the final method below.
SketchPlugin.prototype.exportAllSymbolsToImages = function() { /** * Loop through symbols; export each one as a PNG */ for (var i = 0; i < this.documentSymbols.length; i++) { var symbol = this.documentSymbols[i]; // Specify the path and filename to create var filePath = this.context.scriptPath.stringByDeletingLastPathComponent() + '/export/' + symbol.symbolID() + '.png'; // Create preview PNG var slice = [[MSExportRequest exportRequestsFromExportableLayer:symbol] firstObject]; [slice setShouldTrim:1]; [slice setScale:1]; [(this.context.document) saveArtboardOrSlice:slice toFile:filePath]; } // Close the plugin and display a success message this.window.close(); this.context.document.displayMessage('All symbols exported!'); };
If all goes well, calling the plugin in Sketch will create the export folder and images for you. You should see the “All symbols exported!” message flash once the operation completes. The file system will look similar to the screenshot below.
Congratulations! You’ve created your first Sketch plugin! This foundation should give you the information needed to start making larger, more complex Sketch plugins.
Below are resources to aid you in future Sketch development. Go forth and create the next best Sketch plugin!
The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.
– Brian Kernighan (Unix for Beginners, 1979)
This tutorial should have guided you well enough that troubleshooting tools were not necessary.
Take time to appreciate Kernighan’s quote. Engineers are spoiled today with great debugging tools. Unfortunately, for Sketch developers, the tool set for debugging a plugin isn’t quite there yet. Debugging often involves placing log calls throughout the plugin to see where the plugin is failing.
One utility class that helps greatly with step debugging is SketchPluginLog46. Using this utility, you are able to print information to the system log or to custom log files. Go through the setup guide and become familiar with logging before starting your next big Sketch plugin.
Sketch’s “Resources47” page lists resources for each technology involved — even JavaScript! It will provide ongoing education after you’ve reviewed the “Introduction48” for developers. The reference APIs and subsequent pages will help you find more information, but developers will quickly find that the documentation is incomplete.
Given the lack of documentation and books, the Sketch team recommends pouring over open-source plugins. The quality of code varies wildly, as do the solutions to different problems. Learning from the code of established Sketch plugins is recommended. The Plugin Directory49 on GitHub is a good reference of plugins to learn from.
The Sketch team doesn’t appear to respond directly to requests for support with plugin development, and StackOverflow isn’t very active for Sketch topics. Much of the work in plugin development will come from reviewing the code of others.
Both Objective-C and CocoaScript are difficult to use without learning the basics. For intense complex applications, consider purchasing a book on building straight Cocoa applications. Most use cases in plugin development should be solved by GitHub’s code search and by looking at code samples.
Apple has an API reference50 that will frequently come in handy. You can match up some of the calls made in this demo to the NSWindow documentation5118 for reference.
CocoaScript syntax, and how it relates to Cocoa, can sometimes be confusing as well. MagicSketch has an excellent guide on CocoaScript syntax52 to assist with translation.
What does the landscape look like for creating a Sketch plugin in the future?
Historically, the Sketch team has created some API-breaking changes with major releases. For the most part, the major updates have done well in not breaking plugins, but do keep in mind that you’ll need to test new major versions for each release.
This tutorial should remain effective through new Sketch updates, because it doesn’t touch on internal Sketch APIs to a large degree. This article will be updated for all major updates after version 42.
You might have noticed it already: in the past few weeks you might have missed Anselm’s Web Development Reading List1 issues here on SmashingMag. No worries, from now on, we’ll switch to collecting the most important news of each month in one handy, monthly summary for you. If you’d like to continue reading Anselm’s weekly reading list (and we encourage you to!), you can still do so via email2, on wdrl.info3 or via RSS4. — Editorial Team
Hello again! I’ll continue publishing this resource and am grateful for everyone who supports my ongoing work. And to celebrate the last weekly edition, I found a lot of great articles for you: Biohacking news that sound like science fiction, advances in deep learning with JavaScript, and a lot more. Happy reading!
The upcoming Chrome 615 (in beta channel now) brings support for JavaScript modules, the Payment Request API on desktop, smooth-scrolling in CSS, 8-digit hex colors (with alpha transparency), and the new Expect-CT HTTP header.
This week, Opera announced the end of Opera Max8, their data-saving browser product. The service will still stay active for a while but probably not for too long.
11 The macOS Desktop Kit12 includes desktop application and web UI elements a designer could need when building a user flow through a web app or constructing a Mac interface. (Image credit13)
Andreya Grzegorzewski explains how we can use the Cache API for offline POST requests17 in Progressive Web Apps. This super cool trick allows us to queue POST requests, such as a form submission/data upload, cache it, and send it to the server once the user is back online.
If you want to use <details>/<summary> elements together with rem font-size values on your site, be aware that there’s a bug in Safari that renders parts of a website with that CSS combination useless. After tracking it down and debugging it, I finally summarized the case18.
deeplearn.js23 is a hardware-accelerated machine intelligence library for the web. You can use it to build and train neural networks in your browser, to play color sequences or detect objects in images, for example.
flatpickr24 is a dependency-free, lightweight and powerful datetime picker.
Darius Foroux on why you should spend less time in your head31, thinking, worrying, stressing, but exercise pragmatism instead. An article about mastering your mind and realizing that most of our thoughts cannot make it into practice.
Developers and organizations alike are looking for a way to have more agility with mobile solutions. There is a desire to decrease the time from idea to test. As a developer, I often run up against one hurdle that can slow down the initial build of a mobile hypothesis: user management.
Over the years, I have built at least three user management systems from scratch. Much of the approach can be based on a boilerplate, but there are always a few key items that need to be customized for a particular client. This is enough of a concern that an entire category of user management, authentication and authorization services have sprung up to meet this need. Services like Auth01 have entire solutions based on user and identity management that developers can integrate with.
One service that provides this functionality is Amazon Web Services’ (AWS’) Cognito. Cognito is a tool for enabling users to sign up for and sign into web and mobile applications that you create. In addition to this functionality, it also allows for storage of user data offline, and it provides synchronization of this data. As Amazon states, “With Amazon Cognito, you can focus on creating great app experiences instead of worrying about building, securing, and scaling a solution to handle user management, authentication, and sync across devices.”
Carousels don’t really deserve the bad reputation they’ve gained throughout the years. They can prove to be very effective and come in many shapes and sizes. Read more →2
Last year, Amazon introduced an addition to its Cognito service, custom user pools. This functionality now provides what I and other developers need in order to have a complete, customizable, cross-platform user management system, with the flexibility needed to fit most use cases. To understand why, we need to take a quick look at what user management is and what problems it solves.
In this article, we will spend a majority of our time walking through the process of configuring a user pool for our needs. Then, we will integrate this user pool with an iOS application and allow a user to log in and fetch the attributes associated with their user account. By the end, we’ll have a limited demo application, but one that handles the core of user management. In addition, after this is in place, there will be a follow-up article that takes this quite a bit deeper.
If you have a mobile or web app, what exactly do you need in terms of user management? While user log-in is probably the first thing you would think of, we cannot stop there. If we want a flexible user management system that would work for most web and mobile app use cases, it would need to have the following functionality:
username and password log-in;
secure password hashing and storage;
password changes;
password policy and validation;
user lifecycle triggers (welcome email, goodbye email, etc.);
user attributes (first name, last name, etc.);
required configuration and optional attributes per user;
handling of forgotten passwords;
phone number validation through SMS;
email verification;
API access to endpoints based on permissions;
secure storage of access token(s) on mobile devices;
offline storage of user attributes for mobile devices;
synchronization of user attributes for online and offline states;
multi-factor authentication.
While user management might at first seem like a log-in system, the functionality must go far beyond that in order for the system to be truly flexible enough to handle most use cases. This clearly goes far beyond just a username and password.
One additional item needs to be called out here: security. One of the requirements of any user management system is that it needs to be continually evaluated for the security of the system as a whole. Many custom user management systems have vulnerabilities that simply haven’t been corrected. Within the last year, there have been security breaches of user management systems of companies such as Dropbox, Dailymotion, Twitter and Yahoo. If you choose to build a custom solution, you are on the hook for securing your system.
Amazon Cognito is a managed service that enables you to integrate a flexible and scalable user management system into your web and mobile applications. Cognito provides two distinct ways to utilize the service: federated identities, which allow for log-in via social networks such as Facebook, and user pools, which give you completely custom user management capabilities for a specific app or suite of applications.
Federated identities are great if you want users to be able to log in with Facebook (or Google, Amazon, etc.), but this means that a portion of the user management process will have been outsourced to Facebook. While this might be acceptable in some cases, users might not want to connect their Facebook account to your application. In addition, you might want to manage more of the user’s lifecycle directly, and for this, federated identities aren’t as flexible. For the purpose of today’s article, we will focus on user pools because they provide the flexibility needed for a robust user management platform that would fit most any use case. In this manner, you will have an approach that can be used in most any project.
Because this is an AWS service, there are other benefits of using Cognito. Cognito can integrate with API Gateway to provide a painless way to authorize API access based on the tokens that are returned from a Cognito log-in. In addition, if you are already leveraging other AWS services for your mobile application, you can use your user pool as an identity provider for your AWS credentials.
As with any other AWS service, there is a cost involved. Pricing for Cognito is based on monthly active users (MAUs). The great news for most developers is that there is an indefinite free tier that is capped at 50,000 MAUs when using a custom user pool. If you have a large application, this will give you a large number of users to pilot a new approach to user management. However, I suspect that many of you have experiences that will never go beyond 50,000 users. In this case, core user management will be pretty much free. The only exception to this is other AWS services that you will be leveraging as part of the user management process, such as Lambda, SNS and S3.
The first step in integrating a user pool into your mobile application is to create a Cognito user pool. This will give us the configuration values needed to plug into our example application. To create a new user pool, walk through the wizard provided in Amazon’s Cognito console5.
Let’s walk through the process of creating a user pool. I must warn you that this is a lengthy process. In many ways, this is a good thing because it shows areas of flexibility. However, you’ll want to grab a cup of coffee and buckle in for this one.
The initial step in creating a user pool involves setting a name for your user pool and selecting the approach you will be taking to create the user pool. You can either review the defaults or “step through” the settings. Because we want to have a good working knowledge of how the user pool is being configured, choose the option “Step through settings.”
Configuring attributes will require a bit of thought. For each user pool, you will need to determine which attributes will be stored in the system and which ones are required. Because the system will enforce required values, you cannot change this down the road. The best approach here is to mark only truly essential values here as required. In addition, if you want users to be able to log in with their email address, be sure to mark that one as an alias.
If you want to include custom values, you will need to do that here as well. Each custom value will have a type, optional validation rules, and an option to be mutable (changeable) or non-mutable (unchangeable). There is a hard limit of 25 custom attributes.
Finally, a point needs to be made here about usernames. The username value for each user is immutable (unchangeable). This means that, in most cases, making this value automatically generated would make sense. This is why the “preferred username” value exists. If you want to users to have a username value that they can edit, just mark the “preferred username” attribute as an alias. If you want users simply to log in with their email address, be sure to mark the “email” attribute as both required and an alias.
For our demo application, I chose to make “email,” “given name” and “family name” required.
After configuring the attributes, you will be able to configure the policies for the account. The first policy to configure is the password policy. The policy allows you to configure both the length and whether you require numbers, special characters, uppercase letters or lowercase letters. This policy will be enforced on both passwords that users enter as well as passwords that administrators assign to users.
The next policies relate to user sign-up. For a public application, you will likely want to allow users to sign up themselves. However, depending on the type of application, you might want to restrict sign-up and have the system be invitation-only. In addition, you will have to configure how quickly these invitations will expire if they are not used.
For our demo application, I chose to use just the default values, with the exception that I don’t want users to be able to sign up on their own. With these values in place, we can proceed to verifications.
The verifications step allows you to set up multi-factor authentication, as well as email and phone verification. While this functionality is relatively easy to set up in the console, note that you will need to request a spending increase12 for AWS SNS if you want to either verify phone numbers or use multi-factor authentication.
For our demo application, I chose to use just the default values.
This step allows you to customize the email and SMS messages that your user pool will send, as well as the “from” and “reply to” email addresses. For the purpose of our demo application, I will leave the default values here and proceed.
If you are new to AWS, you might not need to specify any tags. However, in case your organization uses AWS regularly, tags provide a way to analyze spending and assign permissions with IAM. For example, some organizations specify tags per environment (development, staging, production) and by project.
No matter what you enter in this step, it won’t affect our demo application.
The next step allows you to define whether the user pool will remember your user’s devices. This is an additional security step that allows you to see what devices a specific account has been logged into with. This has an extra value when you are leveraging multi-factor authentication (MFA). If the device is remembered, you can elect not to require an MFA token upon each log-in.
For the purpose of the demo application, I have chosen to set the value to “Always.”
For each application for which you want to use the user pool (such as an iOS application, web application, Android application, etc.), you should create an app. However, you can come back and create these after the user pool has been created, so there is no pressing need to add all of these just yet.
Each application has several values that you can configure. For this demo application, we will give the app a name and then leave the default values. Next, you can configure which user attributes each app can read and write.
You can set whichever values you like in this step, as long as the email address, family name and given name are all readable and writable by the application. Be sure to click the option to “Create App Client” before proceeding.
With triggers, you can use Lambda functions to completely customize the user lifecycle process. For example, if you only want users with an email address from your company’s domain to be able to sign up, you could add a Lambda function for the “Pre sign-up” trigger to perform this validation and reject any sign-up request that doesn’t pass.
For our demo application, I will not add any triggers.
I realize that this might have seemed like a lengthy and arduous process. But bear in mind that each step in creating a user pool has flexibility that allows for the solution to fit more use cases. And now for the news you’ve been waiting to hear: This is the last step.
Just review the settings to make sure you have configured them correctly for the demo application. From this screen, you can go back and edit any of the previous settings. Once the user pool is created, some configuration values (such as required attributes) cannot be changed.
With your new user pool created, you can now proceed to integrate them in a sample iOS application using the AWS SDK for iOS.
Setting Up Your iOS Application For Your User Pool Link
I have created a sample iOS application that integrates with Cognito to allow the user to log in, log out, enter their first and last name, and set a password. For this initial demo, user sign-up is not included, so I’ve used Cognito’s console to add a new user for testing.
This application uses CocoaPods28 for managing dependencies. At this point, the only dependencies are the specific pieces of the AWS iOS SDK that relate to Cognito user pools.
(A full description of CocoaPods is beyond the scope of this article, however, a resource29 on CocoaPods’ website will help you get up and running, in case this concept is new to you.)
The contents of the Podfile for this application can be seen below:
source 'https://github.com/CocoaPods/Specs.git' platform :ios, '10.0' use_frameworks! target 'CognitoApplication' do pod 'AWSCore', '~> 2.5.5' pod 'AWSCognitoIdentityProvider', '~> 2.5.5' end
Assuming that CocoaPods is installed on your machine, you can just run pod install, and the necessary dependencies will be installed for you.
The next step is to include the values for your user pool and client application. The demo application is configured to use a file, CognitoApplication/CognitoConfig.plist, from which to pull this information. Four values need to be defined:
region (string)
This is the region in which you created your user pool. This needs to be the standard region identifier, such as us-east-1 or ap-southeast-1.
poolId (string)
This is the ID of the user pool that you created.
clientId (string)
This is the clientId configured as a part of the app that you attached to the user pool.
clientSecret (string)
This is the clientSecret that is configured as a part of the app that you attached to the user pool.
With that file and the proper values in place, the demo application can be launched. If any exceptions occur during launch, be sure that you have included each of the four values shown below and that the file is placed in the correct directory.
The core of the integration with Amazon Cognito happens within the application’s AppDelegate. Our first step is to ensure that we have set up logging and have connected to our user pool. As a part of that process, we will assign our AppDelegate as the delegate of the user pool. For this basic example, we can keep this logic within the AppDelegate. For larger projects, it might make sense to handle this elsewhere.
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool { // set up logging for AWS and Cognito AWSDDLog.sharedInstance.logLevel = .verbose AWSDDLog.add(AWSDDTTYLogger.sharedInstance) // set up Cognito config self.cognitoConfig = CognitoConfig() // set up Cognito setupCognitoUserPool() return true } func setupCognitoUserPool() { // we pull the needed values from the CognitoConfig object // this just pulls the values in from the plist let clientId:String = self.cognitoConfig!.getClientId() let poolId:String = self.cognitoConfig!.getPoolId() let clientSecret:String = self.cognitoConfig!.getClientSecret() let region:AWSRegionType = self.cognitoConfig!.getRegion() // we need to let Cognito know which region we plan to connect to let serviceConfiguration:AWSServiceConfiguration = AWSServiceConfiguration(region: region, credentialsProvider: nil) // we need to pass it the clientId and clientSecret from the app and the poolId for the user pool let cognitoConfiguration:AWSCognitoIdentityUserPoolConfiguration = AWSCognitoIdentityUserPoolConfiguration(clientId: clientId, clientSecret: clientSecret, poolId: poolId) AWSCognitoIdentityUserPool.register(with: serviceConfiguration, userPoolConfiguration: cognitoConfiguration, forKey: userPoolID) let pool:AWSCognitoIdentityUserPool = AppDelegate.defaultUserPool() // we need to set the AppDelegate as the user pool's delegate, which will get called when events occur pool.delegate = self }
After this configuration is in place, we need to configure the delegate methods for the user pool. The protocol that we are implementing is AWSCognitoIdentityInteractiveAuthenticationDelegate. This delegate will get called any time the user needs to log in, reset their password or provide a multi-factor authentication code or if we need to query the user about whether they would like their device to be remembered. For our example, we only need to implement the startPasswordAuthentication and the startNewPasswordRequired methods:
extension AppDelegate: AWSCognitoIdentityInteractiveAuthenticationDelegate { // This method is called when we need to log into the application. // It will grab the view controller from the storyboard and present it. func startPasswordAuthentication() -> AWSCognitoIdentityPasswordAuthentication { if(self.navigationController == nil) { self.navigationController = self.window?.rootViewController as? UINavigationController } if(self.loginViewController == nil) { self.loginViewController = self.storyboard?.instantiateViewController(withIdentifier: "LoginViewController") as? LoginViewController } DispatchQueue.main.async { if(self.loginViewController!.isViewLoaded || self.loginViewController!.view.window == nil) { self.navigationController?.present(self.loginViewController!, animated: true, completion: nil) } } return self.loginViewController! } // This method is called when we need to reset a password. // It will grab the view controller from the storyboard and present it. func startNewPasswordRequired() -> AWSCognitoIdentityNewPasswordRequired { if (self.resetPasswordViewController == nil) { self.resetPasswordViewController = self.storyboard?.instantiateViewController(withIdentifier: "ResetPasswordController") as? ResetPasswordViewController } DispatchQueue.main.async { if(self.resetPasswordViewController!.isViewLoaded || self.resetPasswordViewController!.view.window == nil) { self.navigationController?.present(self.resetPasswordViewController!, animated: true, completion: nil) } } return self.resetPasswordViewController! } }
One key thing to note is that both of these methods return a view controller that implements a specific protocol. For example, the LoginViewController implements AWSCognitoIdentityPasswordAuthentication, which has a single method that gets called with the parameters needed to enable the user to complete the log-in process.
With all of these pieces in place in the demo application, you can now see the log-in process work from beginning to end. The main view of the application shows the username and the first name and last name of the user. To make this happen, the following steps occur:
In the AppViewController, we call the fetchUserAttributes method in the viewDidLoad method. If the user isn’t logged in, this will trigger the log-in process.
The startPasswordAuthentication method in the AppDelegate will be triggered. This method loads the LoginViewController and presents it.
The getDetails method of LoginViewController is called by the AWS SDK. This includes an object that is an instance of AWSTaskCompletionSource, which we can use to allow the user to attempt to log in.
When the user presses the “Log in” button, we pass the log-in credentials to that object. This will then call the didCompleteStepWithError method, and we can handle the result accordingly. If there is no error, we can dismiss the view controller.
If we created the user in the console, we will have another step to handle here. Because we gave the user a temporary password, they will need to set a more permanent one. In addition, because we set the given name and family name as required parameters, we need to allow the user to enter those, too. The AWS SDK will detect this and call the startNewPasswordRequired method in the AppDelegate. This will present the ResetPasswordViewController and set its instance of AWSTaskCompletionSource.
The ResetPasswordViewController works almost identically to the LoginViewController. We simply need to ask the user for the correct values and then submit those values. Once this process is completed successfully, we dismiss the view controller.
Once the entire log-in process has completed, the SDK will securely store the tokens returned by Cognito. Then, we will finally retrieve the user details, and we can use those to populate the AppViewController with the user’s username, given name and family name.
32 The working sample application, showing username and meta data
While the user pool set-up process might have several steps, those steps are easy to navigate. In addition, the amount of configuration possible should give you confidence that it can support a majority of use cases. In my day job at Universal Mind, I’ve worked with several clients who are moving their existing applications over to leverage the capabilities that Cognito provides for user management.
Regardless of whether you need to implement a user management system regularly, this is a tool that every mobile and web developer should have in their toolbox. In the next article in this series, we will begin to explore the capabilities of Cognito a bit more by implementing a more full-featured demo application that implements more of the common user management use cases.
With a bit of practice, you can go and impress all of your friends by setting up a new application that satisfies all of these user management use cases within a day. That’s pretty good for a day’s work.
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.
23 Often feature comparison is complemented with filters that help customers limit the scope of options. Liebherr24 uses filters alone, avoiding feature comparison altogether. (Large preview25)
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.
26 We can compare anything from locations to luggage to chemicals. Point in case: Abcam.com27, a supplier of protein research tools to life scientists. (Large preview28)
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.
34 Comparison is irrelevant if meta data is missing. Unfortunately, that’s the case way too often. Case in point: Sharp TV35. (View large version36)
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.
When attributes are inconsistent, feature comparison becomes irrelevant. On Hotpoint41, attributes are missing. It’s also impossible to remove an item from the selection, and on mobile, the third compared item is just dropped.
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.
43 Amazon44 translates technical attributes into more understandable terms. For example, “# of iPhone 6s charges” or “# of Samsung S6 charges” (View large version45)
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.
Versus5352 highlights how the features of the selected products compare to other products on average in a bar chart.
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.
Cool Blue5554 has a fine, well-designed feature comparison. Customer reviews and the pros and cons of each product make the comparison quite easy.
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.
Flipkart5756 extract advantages and disadvantages of compared items from user reviews.
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.
Sharp6362 allows customers to select the category of interest from a list. That dropdown doesn’t float, though.
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.
Otto6564 groups all attributes into collapsible and extendable sections.
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.
Garmin6766 displays a dropdown with grouped attributes in the floating bar on the top.
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.
Rtings.com6968 with filters applied to the entire table.
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.
Highlight Differences Or Similarities… Or Both? Link
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.
On Mediamarkt7671, a lightbox opens every time the user adds an item to the shopping cart. It might get annoying after the third click.
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.
73 Electrolux1511507472 highlights differences with a blue background without removing identical attributes. (Large preview75) On Mediamarkt7671, a lightbox opens every time the user adds an item to the shopping cart. It might get annoying after the third click.
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.
Samsung828079 allows users to choose what items are relevant to them and compare only by them.
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.
On LG8381, customers can “lock” a product, but it’s not very clear what that means.
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.
The Thing That Never Goes Away: Floating Header Link
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.
With many attributes displayed, users might need to jump back and forth in the table as they you can’t see what products they are comparing. Bol.com comparison104.
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!
Sony106105 keeps product labels and thumbnails floating above the comparison table.
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.
Indesit108107 uses a floating bottom bar to keep the mapping between the column and the product.
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.
Crutchfield110109 displays products and features in 2 × 2 grid — not very intuitive.
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.
Even if the meta data is present but the content isn’t well organized for easy scanning, comparison will be quite difficult. Extracting pros and cons is noteworthy though. (Source: ProductReportCard112111)
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.
Urban Ladder114113 allows its customers to compare at most 2 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.
OBI116115 with a stepper, allowing to switch between options predictably.
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.
One strategy for making comparison tables work on mobile is converting the columns to tabs. This means users can’t do true side by side comparison like they can on a full table, but at least they will be able to switch between products more easily than if they had to scroll or switch between mobile browser tabs.
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.
117Product suggestions, a list of recently viewed items or a feature comparison view may be placed in a sidebar for easy cross-product navigation. (View large version118)
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.
Conrad1263937 makes it possible for customers to save comparisons for future reference.
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.
Konica Minolta128127 uses a guide rather than a comparison table to help users make the right choice.]
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.
Navigation between products on Vizio130129 happens by sliding left and right. Attribute headings remain fixed.
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.
132 Amazon133 doesn’t provide feature comparison as an option on category pages — instead, it displays similar items on the product page by default. (View large version134)
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.
The Life Of A Lonely Checkbox, Or How To Indicate Comparison Link
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.
Comparison overlay on Home Depot149148. Notice how the “Compare” label on the checkbox changes to the “Compare Now” link when at least two items are shortlisted for comparison.
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.
Electrolux1511507472 with a humble subtle notification bar at the bottom of the screen.
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.
Appliances Connection153152 gives users quick access to compared and recently viewed items with a bottom bar.
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.
Abcam155 uses a subtle animation to provide visual confirmation.
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.
Delta157156 with a large comparison overlay at the top of the screen.
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:
on the same page, as a full-page overlay;
on a separate new page, integrated in the website’s layout;
on a separate new page, standalone;
in a separate tab or window opened in addition to the tab that the user is currently on.
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.
A Slightly Different Feature Comparison, Or Asking The Right Question In A Right Way Link
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.
Alternatively, to help with picking a “winner,” we could let customers highlight favorite options and then allow customers to remove everything else, rather than manually remove irrelevant options.
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.
Product Chart167166 has a matrix view for products, with filters placed on the left.
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?
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.
174 Relevant features first, selection later. A concept175172 by Raviteja Govindaraju.
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.
177 The products could be presented in a contextual preview as well. A mock-up178 by Raviteja Govindaraju. (Large preview179)
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:
Every column contains the price (or price graph), a link to the standalone product page, ratings, the number of reviews, a thumbnail, the product’s model name, and a price-matching tooltip.
For every product, useful reviews, with major advantages and disadvantages as keywords, are extracted and highlighted above the comparison.
Attributes are consistent and have comparable meta data; they are grouped, and some of them are collapsed by default.
If there isn’t enough meaningful meta data to compare against, explain that to the customer and suggest third-party reviews instead. Irrelevant tables are frustrating.
The customer can switch to seeing only differences, only similarities or all attributes.
The customer can reset their selection and return back to the products (perhaps with breadcrumb navigation at the top).
The customer can add new products to the comparison (for example, if they are unsatisfied with the results of a comparison).
Columns and rows are highlighted upon hover or tap.
The customer can rearrange columns by dragging or moving them left and right.
Every action provides confirmation or feedback.
Customers can generate a shareable link for comparison (for example, “Save comparison as…”).
If the user spends too much time in the comparison view, a window with information for hotline support or chat is displayed.
Items are stored persistently after page refresh or abandonment.
The feature comparison is responsive, bringing focus to the differences and the advantages and disadvantages of products.
And here are the questions the team will have to consider when designing and implementing a comparison table.
How do you indicate that comparison is possible?
What happens when the first item is added for comparison?
Have you disabled the option to compare when only one item has been selected?
Once an item has been selected, do you change the link or highlight the selected product, or display a comparison bar, or display a lightbox?
How do users unselect a selected option?
If only one item has been added for comparison, should we suggest products to compare or enable users to “find similar products”?
When an item has been selected, do you provide visual feedback to reaffirm and reassure users about their choice. (For example, “Good choice! That’s one of the top-10 rated cameras in the category!”)
How many items may a customer add for comparison (usually three to five)? What happens to the comparison if no or one item has been selected. What about more than five items?
As items are being compared, do we use animation or transitions to indicate comparison (such as a battle animation)?
Do we display the price (or price development), a link to the individual product page, ratings, reviews, a thumbnail, the product’s model name, and price-matching tooltip?
Can users switch to see only differences, only similarities or all attributes?
Do we group and collapse attributes by default?
Do we track whether attributes are consistent and have comparable meta data? Otherwise, seeing differences would be meaningless.
Do we highlight columns and rows upon hover or tap?
Can the user move columns left and right?
What if the user compares items in unrelated categories (for example, a laptop against batteries)?
How do we allow users to add more items for comparison?
How do we allow users to remove items from comparison?
Should we dynamically track how many items are in the comparison list, and prompt a message if there are none (“Oh, nothing to compare! Here are some suggestions.”) or one (“Boo-yah! You’ve got a winner!”) or two (“So, you have just two candidates now.”)?
Should we ask customers to choose what they care about most?
Do we suggest a “winner” among the products selected for comparison, perhaps based on the user’s most relevant attributes?
Does every action have visual and/or aural feedback to indicate change?
Have we provided a shareable link for comparison (for example, “Save comparison as…”)?
If the user spends too much time in the comparison view, should we prompt a window with information for hotline support or chat?
Are compared items stored persistently after the page is refreshed or abandoned?
Do we include a “Notify about price drop” option for email subscription?
Is the feature comparison accessible, coded as an unordered list?
How do we make the feature comparison behave responsively?
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.
11
14
Comments