Although I like the nightlife, I wouldn’t say I want the nights to get longer. I enjoy a long day’s – well – daylight. With autumn having undoubtedly arrived, nights are getting longer. We leave home for work in the dark and get back when it’s dark already. To save you from depression and give you a little perspective during the cold and sinister season we’ve put together another round of free WordPress themes for self-hosted blogs, just like we did last month and the month before and the…
Sometimes, while rambling the web, you stumble upon real gems. That’s what just happened to me. It was by pure coincidence that I found the website of Anders Norén. Anders Norén, among other things, develops WordPress themes. These are not only mostly completely free, but also picture-perfect. You can grab them from WordPress.org. If you are into the WordPress theme universe, you already know that the majority of free themes is plain disappointing. They are designed and even more so coded in a half-assed attempt to get some short-dated attention. Others may be good, yet batter you with a plethora of mostly superfluous functions – the jack of all trades approach. Neither of these is Anders Norén’s take. He cares for great contemporary design, outstanding typography and clean code. This is reason enough to introduce you to his works…
Back when my agency started taking content seriously, we invested a lot time in developing a process to produce content. The biggest challenge was always figuring out how to get clients onboard with this new process.
Most of our clients were totally happy riffing on how to meet the business objectives of a project or how to approach the visual design, but they always struggled to get to grips with our process for producing content. We found that the most effective way to get their buy-in was to run a content-planning workshop.
Workshops work really well to get everyone onboard with how to produce content (while also clarifying how to agree on content). By involving as many people from the client’s side as possible in these workshops, you can really underline people’s responsibilities, while also highlighting that this process won’t happen overnight.
In this article, I’ll share the approach we developed to run content-planning workshops with our clients. While you will need to adapt the format to your scenario, you should be able to apply most of the steps.
1. Prepare
You’ll have to sort out a few things before inviting your client to the workshop. These workshops have a few components, so put in the work beforehand to make sure everything runs smoothly and you don’t have awkward pauses during the session.
Put in some planning work beforehand to make sure everything runs smoothly and to avoid awkward pauses.
Find a Venue
You’ll want to get a room with a large table and a whiteboard. You could bring the client to your agency’s boardroom or do the workshop somewhere off-site that you agree on. Having an inspiring new environment is always good for the client. Sometimes the client will be engaged, but I’ve been in a few workshops where no one wanted to be there and were constantly checking their email or not taking it seriously. Working off-site might hold everyone’s interest better; it also makes it easier to set ground rules (no phones, for example).
Invite the Project Manager, Project Owner and Senior Editor
These roles will vary hugely according to the project. Either way, involve some kind of senior manager and someone on the ground who will actually be producing the content. This way, you’ll get buy-in from the top and a realistic plan from the bottom.
Invite a technical person, too, so that they can talk about CMS formatting and any details regarding migration and publishing processes. By inviting people who represent key areas of the project, you are minimizing risk. I’ve been in workshops where someone from legal turned up and effectively redefined the requirements by sharing important legal requirements.
Invite Representatives From Different Teams
Invite one or two representatives from each of these groups: writers and producers, subject experts, and digital producers. Again, these roles will vary according to your situation. Essentially, you want to get managers from a cross-section of departments, as well as the people who will actually be carrying out the production process that you map out. Be aware of organizational politics and the workloads of the people you’re involving.
Bring Materials
Bring plenty of sticky notes and markers and some big sheets of paper. These will be used throughout the workshop, and you will need enough for up to three groups.
2. Map Your Process
First, look at the production stages that a piece of content will need to go through before it is ready to be published. This generally starts with identifying the key content types (for example, “product pages,” “course summary pages,” “how-to guides”). Content types are not necessarily “pages” as such, but could be more modular components of the website — things like product specifications or staff biographies.
Look at the production stages that a piece of content will need to go through before it is ready to be published.
Once you’ve identified the main content types, look at what’s involved in taking them from a basic page brief (which outlines what an item of content is supposed to achieve) to a product that is published and maintained.
Choose a Content Type
Choose a content type that you expect to appear on your new website, such as a service or product page, a blog post or a course outline. Choose something that everyone can relate to; avoid specialized content types such as legal documents and engineering reports.
Map a Publishing Process
In groups, map out a production process to get a single piece of content published on the new website. Again, this will vary a lot according to your team (for example, depending on who will be doing the heavy lifting of producing the content).
A simple workflow might look something like this:
Draft content
Edit tone of voice
Review internally
Get approval from client
Optimize for search engines
Import to CMS
Review web page
Publish
Maintain
The workflow will vary considerably from project to project. You might need to account for legal and compliance reviews or technical accuracy, or you might need to specify phases for formatting and publishing content (such as formatting for mobile or converting items into downloadable PDF documents). This is another reason to start with a fairly generic piece of content, and then move on to creating more elaborate workflows for specific content types or sections of the website.
The bias that stems from people’s roles in the project is always interesting to see (which is why having people with different roles involved in the workshop is so valuable in the first place). You might find legal representatives claiming to need four separate stages for legally reviewing every page, while a copywriter might want to break the editing for tone of voice into multiple phases. A concerted team effort should result in a workflow that is balanced, realistic and agreed on.
3. Assign Responsibility
One of the most powerful things about these workshops is that you assign responsibility, making clear who exactly is accountable for which work. Failing to clarify responsibility over content is one of the most common causes for delays. Bottlenecks happen usually because people simply do not know they were expected to produce content or because responsibility has all been put on one person. This part of the workshop should prevent such trouble.
Failing to clarify responsibility over content is one of the most common causes for delays.
Assign Responsibility
Annotate each stage on your sheet with the person or role responsible for it. This might look something like this:
Draft content: subject expert
Edit tone of voice: copywriter
Review internally: senior editor
Get approval from client: project owner
Optimize for search engines: SEO editor
Import to CMS: CMS editor
Review web page: project owner
Publish: CMS editor
Maintain: subject expert
Identify Lack of Ownership
Mark any stages that don’t have a clear owner. This is often a huge revelation. “We need to hire an SEO editor!” “We need a copywriter!” “We need a pastry chef!” By simply highlighting the parts of the process for which no one is responsible, you’ll quickly see where the challenges for your project lie. By acknowledging these now, you will save a huge amount of stress down the line. You might find that the plan is solid and has no gaps, or you might immediately see that hiring a copywriter will save you a whole lot of trouble. Either way, this part of the workshop is critical.
Clarify Responsibilities
Ask, “Do the people responsible know they are responsible?” This is another great opportunity to minimize risk. Make sure that everyone knows what’s expected of them, and see whether anyone has too much on their plate. A well-organized content inventory or dedicated project-management software comes in handy here.
4. Identify Risks In The Process
Building on the previous step, make sure the following questions are resolved to avoid bottlenecks.
“Do Too Many People Have a Say?”
Multiple heads are sometimes not better than one for producing content. Keep an eye out for pages or sections of the website that have a lot of editors and reviewers involved. I’ve seen so many projects delayed because content was bounced between editors for days on end, often just leading to over-edited and nonsensical text.
“Is One Person Overburdened?”
These workshops are the perfect time to assess the volume of work assigned to individuals and assess how realistically they can get it done. Give less outspoken people a chance to air their concerns, which is a lot easier when you’ve estimated the hours of work involved. Speak with each individual to review their workload.
“Do We Have the Skills Required?”
Is poorly written content a risk? Or could the content be misinformed (due to a lack of expertise)? Will the content be optimized for search engines? Go back to your content requirements and make sure you have the manpower to meet them all. If you don’t, call for some outside help.
“Where Might Things Get Political or Contentious?”
It’s an awkward subject to broach, but organizational politics could pose a serious threat to the project. I’ve often seen people hold back their opinion (or, more dangerously, overestimate their ability to deliver work) due to certain people being in the room or politics. The best way to deal with this is simply to treat all team members as equals and to ask probing questions of everyone in the room.
5. Estimate Hours
It might not be easy, but try to calculate the man hours of work required to complete each stage of the process. This isn’t the same as calculating how long it will take to complete a stage, although both are important when planning resourcing.
Estimatehow much effort is required to complete each stage.
Estimate Workload
Estimate (in fractions of hours) how much effort is realistically required to complete each stage. Once you’ve come to an agreement on the time required, write the number beside each stage. If the debate about estimates is taking too long, you could try adapting the “planning poker1” technique used in scrum.
Calculate Time
Add up the time required to complete all stages. This might be a good time for a break.
Estimate Total Workload
Multiply the total time by the number of pages anticipated for the website to get an estimate of the total amount of effort required for all of your content. As mentioned, you might be dealing with modules or items of content (things like product specifications or staff biographies), rather than pages. Either way, consider the average size of these items to get a realistic estimate of the time required to get the work done. I often group together additional content, such as microcopy, treating it as a single item in the calculation.
The calculation might look like this: 4 hours (time to produce and approve one page) × 125 pages = 500 hours of work.
6. Present The Process
Everyone should review the process at the end of the workshop to be clear on what’s going to happen, who is doing what and how it will be implemented. This is also a good time to outline the next steps.
Walk Through the Process
Each group should walk the whole team through their process (on a sheet of paper) and then open up the presentation for discussion. The person facilitating the workshop should go around and get input from everyone in the room. Address any concerns or anxieties immediately. Concerns tend to focus on whether there is enough time! Also, address any technical issues that people might not feel confident asking about.
Try to film the presentations so that any absent stakeholders can keep up with the discussion.
Following this discussion, move on to the slightly more serious task of setting realistic deadlines for the content and assigning responsibility. Talk about the software you might use to host your editorial calendar2, once you have a clear idea of the process that the software has to support. Choosing the software first could lead you to have to shoehorn the process in; this is best avoided!
Workshops Work
That’s the process we’ve developed to run workshops with our clients. Hopefully, this template will help you to run successful content-planning workshops of your own and, more importantly, help you to get content finished on time and to a high standard.
With everyone on the same page (literally), the risk of delays with content production will be far less.
In March 2014, the Baymard Institute, a web research company based in the UK, reported that 67.91%1 of online shopping carts are abandoned. An abandonment means that a customer has visited a website, browsed around, added one or more products to their cart and then left without completing their purchase. A month later in April 2014, Econsultancy stated2 that global retailers are losing $3 trillion (USD) in sales every year from abandoned carts.
Clearly, reducing the number of abandoned carts would lead to higher store revenue — the goal of every online retailer. The question then becomes how can we, as designers and developers, help convert these “warm leads” into paying customers for our clients?
Before Cart Abandonment
Let’s begin by looking at recognized improvements we can make to an online store to reduce the number of “before cart” abandonments. These improvements focus on changes that aid the customer’s experience prior to reaching the cart and checkout process, and they include the following:
Show images of products.
This reinforces what the customer is buying, especially on the cart page.
Display security logos and compliance information.
This can allay fears related to credit-card and payment security.
Display contact details.
Showing offline contact details (including a phone number and mailing address) in addition to an email address adds credibility to the website.
Make editing the cart easier.
Make it as simple as possible for customers to change their order prior to checking out.
Offer alternative payment methods.
Let people check out with their preferred method of payment (such as PayPal and American Express, in addition to Visa and MasterCard).
Offer support.
Providing a telephone number and/or online chat functionality on the website and, in particular, on the checkout page will give shoppers confidence and ease any concerns they might have.
Don’t require registration.
This one resonates with me personally. I often click away from websites that require lengthy registration forms to be filled out. By allowing customers to “just” check out, friction is reduced.
Offer free shipping.
While merchants might include shipping costs in the price, “free shipping” is nevertheless an added enticement to buy.
Be transparent about shipping costs and time.
Larger than expected shipping costs and unpublished lead times will add unexpected costs and frustration.
Show testimonials.
Showcasing reviews from happy customers will alleviate concerns any people might have about your service.
Offer price guarantees and refunds.
Offering a price guarantee gives shoppers the confidence that they have found the best deal. Additionally, a clear refund policy will add peace of mind.
Optimize for mobile.
Econsultancy reports that sales from mobile devices increased by 63% in 2013. This represents a real business case to move to a “responsive” approach.
Display product information.
Customers shouldn’t have to dig around a website to get the information they need. Complex navigation and/or a lack of product information make for a frustrating experience.
Unfortunately, even if you follow all of these recommendations, the reality is that customers will still abandon their carts — whether through frustration, bad design or any other reason they see fit.
After Cart Abandonment
The second approach is to look at things we can do once a cart has been abandoned. One tactic is to email the customer with a personalized message and a link to a prepopulated cart containing the items they had selected. This is known as an “abandoned cart email.”
The concept is pretty simple. At the right time, a customizable email is sent, complete with a personalized message and a link to the customer’s abandoned cart. Of course, this approach assumes that the customer has submitted their email address — effectively, they’ve done everything but paid. Abandoned cart emails represent one last attempt by the merchant to convince the buyer to check out.
In September 2013, Econsultancy outlined3 how an online cookie retailer recaptured 29% of its abandoned shopping carts via email. This is a huge figure and one we might naturally be skeptical of.
To get a more realistic perspective, I asked my colleagues at Shopify4 to share some of their data on this, and they kindly agreed. Shopify introduced “abandoned cart recovery” (ACR) in mid-September 2013 (just over a year ago at the time of writing). Here’s a summary of its effectiveness:
In the 12 months since launching automatic ACR, $12.9 million have been recovered through ACR emails in Shopify.
4,085,592 emails were sent during this period, of which 147,021 carts were completed as a result. This represents a 3.6% recovery rate.
Shop owners may choose to send an email 6 or 24 hours after abandonment. Between the two, 6-hour emails convert much better: a 4.1% recovery rate for 6 hours versus 3% for 24 hours.
It’s worth noting that the 3.6% recovery rate is from Shopify’s ACR emails. Many merchants use third-party apps5 instead of Shopify’s native feature. Given that Shopify is unable to collect data on these services, the number of emails sent and the percentage of recovered carts may well be higher.
Given the statistics, abandoned cart emails are clearly an important part of an online retailer’s marketing strategy. Luckily, most leading e-commerce platforms enable merchants to send custom emails, either in plain text or HTML. Knowing how to implement these notifications is a useful skill if you are designing for e-commerce, and they represent added value to your services.
Creating An HTML Abandoned Cart Email
The implementation of abandoned cart emails varies from platform to platform. Some platforms require third-party plugins, whereas others have the functionality built in. For example, both plain-text and HTML versions are available on Shopify. While the boilerplates are very usable, you might want to create a custom HTML version to complement the branding of your store. We’ll look at options and some quick wins shortly.
In recent years, HTML email newsletters have really flourished. You only have to look at the many galleries6 to see how far this form of marketing has progressed. Sending an HTML version, while not essential, certainly allows for more flexibility and visual design (although always sending a plain-text version, too, is recommended). However, it’s not without its pain points.
If you’ve been developing and designing for the web since the 1990s, then you will remember, fondly or otherwise, the “fun” of beating browsers into shape. Designing HTML newsletters is in many ways a throwback to this era. Table-based layouts are the norm, and we also have to contend with email clients that render HTML inconsistently.
Luckily for us, the teams at both Campaign Monitor7 and MailChimp8 have written extensively on this subject and provide many solutions to common problems. For example, Campaign Monitor maintains a matrix and provides a downloadable poster9 outlining the CSS support of each major desktop and mobile email client. MailChimp, for its part, provides numerous resources on CSS10 and email template design11. Familiarizing yourself with the basics before tackling your first HTML email is worthwhile — even if you ultimately use a template.
Open-Source Responsive Email Templates
While many of you might wish to “roll your own” template, I often find it easier to build on the great work of others. For example, a number of great open-source projects focus on HTML email templates, including Email Blueprints12 by MailChimp.
Another example comes from Lee Munroe. His “transactional HTML email templates13” differ in that they are not intended for use as newsletters, but rather as “transactional” templates. To clarify the difference, Lee breaks down transactional email into three categories:
action emails
“Activate your account,” “Reset your password”
email alerts
“You’ve reached a limit,” “A problem has occurred”
billing emails
monthly receipts and invoices
The templates are purposefully simple yet elegant. They also have the added benefit of having been throughly tested in all major email clients. Finally, because they are responsive, they cater to the 50+%14 of emails opened via mobile devices.
The Challenge
Lee’s templates are a good option for creating a simple HTML email for abandoned carts. Therefore, let’s move on from the theory and look at how to create an HTML template for the Shopify platform.
Let’s begin by setting some constraints on the challenge:
make the fewest number of markup changes to Lee’s template;
make use of the boilerplate text that is set as the default in the abandoned cart HTML template in Shopify;
inline all CSS (a best practice for HTML email);
send a test email with dummy data, and review the results in Airmail, Gmail and Apple Mail (on iOS).
1. Create a Local Copy of the Action Email Template
Having looked at the three templates, the “action” version appears to offer the best starting point. You can download the HTML for this template directly from GitHub15 if you wish to follow along.
The first step is to take the contents of Lee’s template and save it locally as abandoned-cart.html. A quick sanity check in a browser shows that the style sheet isn’t being picked up.
Inlining all CSS is recommended (we’ll look at this in a later step), so add the styles to the section of abandoned-cart.html. You can copy the CSS in its entirety from GitHub18 and then paste it in a element. Another check in the browser shows that the styles are being applied.
CSS applied.
2. Add the Content
Now that the template is working as a standalone document, it’s time to look at integrating Liquid19‘s boilerplate code from Shopify’s default template. This can be found in the Shopify admin section under “Settings” ? “Notifications” ? “Abandoned cart.” If you wish to follow along with these code examples, you can set up a free fully featured development store20 by signing up to Shopify’s Partner Program21.
Hey{% if billing_address.name %} {{ billing_address.name }}{% endif %},
Your shopping cart at {{ shop_name }} has been reserved and is waiting for your return!
In your cart, you left:
{% for line in line_items %}{{ line.quantity }}x {{ line.title }}{% endfor %}
But it's not too late! To complete your purchase, click this link:
{{ url }}
Thanks for shopping!
{{ shop_name }}
All notification emails in Shopify make use of Liquid, the templating language developed by Shopify and now available as an open-source project and found in tools such as Mixture22 and software such as Jekyll23 and SiteLeaf24. Liquid makes it possible to pull data from the store — in this case, all of the details related to the abandoned cart and the user it belonged to.
Having studied the markup, I’ve decided to place the boilerplate content in a single table cell, starting on line 2725 of Lee’s original document.
After pasting in the boilerplate code, let’s double-check that the template renders as expected in the browser. At this stage, Liquid’s code is appearing “as is.” Only once the template is applied to Shopify’s template will this be replaced with data from the store.
Boilerplate text added.
3. Modify the Boilerplate Code
The next stage involves tidying up some of the boilerplate code, including wrapping the boilerplate text in
tags. Then, it’s time to work out how best to display the cart’s contents in markup. For speed, I’ve chosen an unordered list. Liquid’s refactored for loop26 is pretty straightforward:
<ul>
{% for line in line_items %}
<li>{{ line.quantity }} x {{ line.title }}</li>
{% endfor %}
</ul>
After another sanity check, things are looking much more promising. However, we need to make a few final tweaks to make it work:
remove unwanted table rows,
add the correct link to the blue call-to-action button,
change the contents of the footer.
Tidying up.
4. Make Final Adjustments
Lee’s template includes markup to create a big blue “Click me” button. You can see this on line 3827:
<a href="http://www.mailgun.com" class="btn-primary">Upgrade my account</a>
Let’s turn this into a relevant link by changing the markup to this:
<p><a href="{{ url }}" class="btn-primary">Check out now</a></p>
Adding the call-to-action URL.
In this case, {{ url }} represents the link to the abandoned (and saved) cart. I’ve enclosed the anchor in a paragraph to ensure consistent spacing when the email is rendered, and I’ve moved it up into the main section.
Finally, we’ve changed the unsubscribe link in the footer to a link to the shop:
After a few minutes of editing, the template looks more than respectable. However, we’ve neglected one section, the text in the yellow highlighted “alert” section. I’ve changed this, along with the title element in the HTML, to this:
Changing the header text and footer link.
Your cart at {{ shop_name }} has been reserved and is waiting for your return!
Email notifications in Shopify have access to a number of variables that can be accessed via Liquid. A full list is available in Shopify’s documentation28.
5. Inline the CSS
To recap, we’ve changed the template’s markup very little, and the CSS is identical to Lee’s original (albeit in the template, rather than in an external file). Shopify’s boilerplate text is also intact, albeit with a very small change to Liquid’s for loop.
The next step is to inline the CSS in the HTML file. Because some email clients remove and tags from email, moving the CSS inline means that our email should render as intended. Chris Coyier penned “Using CSS in HTML Emails: The Real Story29” back in November 2007 — the landscape hasn’t changed much since.
Thankfully, taking your CSS inline isn’t a long or difficult process. In fact, it’s surprisingly easy. A number of free services30 enable you to paste markup and will effectively add your styles inline.
I’ve chosen Premailer31 principally because it has a few extra features, including the ability to remove native CSS from the section of the HTML document, which saves a few kilobytes from the file’s size. After pasting in the markup and pressing “Submit,” Premailer generates a new HTML version that you can copy and paste back into your document. It also creates a plain-text version of the email, should you need it.
32Premailer has the ability to remove native CSS which saves a few kilobytes. (View large version33)
Another great feature of Premailer is that you can view the new markup in the browser. You’ll find a link above the text box containing the new markup, titled “Click to View the HTML Results.” Clicking the link opens a hosted version of the new markup, which you can use to check your sanity or share with colleagues and clients.
If you are keen to automate the creation of e-commerce notification emails, then Premailer also offers an API34. A number of libraries that support it are also available on GitHub, including PHP-Premailer35.
The final task is to copy the new HTML code and paste it in the “HTML” tab of our abandoned cart notification in Shopify’s admin area. Once it’s applied, you can preview the email in the browser, as well as send a dummy copy to an email address.
The process of turning Lee’s template into a usable email took around 30 minutes, and I am pretty pleased with the result from such little input.
Of course, this process screams out for automation. For those who are interested, Lee has also posted about his workflow for creating HTML email templates46 and the toolkit he uses (Sketch, Sublime, Grunt, SCSS, Handlebars, GitHub, Mailgun, Litmus).
Taking It Further
The template produced above is admittedly quite basic and only scratches the surface of what is possible. We could do plenty more to customize our email for abandoned carts, such as:
consider tone of voice,
show product images to jog the customer’s memory,
add a discount code to encourage the user to return and buy,
add upsells,
list complementary products.
Dodo Case
Tone of voice is a key consideration and goes a long way to engaging the customer. Dodo Case4947 has a great example:
As always, context is very important when it comes to tone of voice. What’s right for Dodo Case might not be right for a company specializing in healthcare equipment.
Let’s review a few examples (taken from Shopify’s blog51) to get a taste of what other companies are doing.
The language and tone used in Chubbies’ email really stands out and is in line with the brand: fun-loving people. There’s also no shortage of links back to the cart, including the title, the main image and the call to action towards the bottom of the email.
Black Milk Clothing62 includes a dog photo and employs playful language, such as “Your shopping cart at Black Milk Clothing has let us know it’s been waiting a while for you to come back.”
Finally, Holstee6664 asks if there’s a problem they can help with. It even goes so far as to include a direct phone number to its “Community Love Director.” Having worked with Holstee, I can confirm that this is a real position within the company!
Conclusion
While there are many tactics to persuade customers to buy, inevitably some people will get to the payment screen and decide not to continue. Any tactic that helps to seal the deal is certainly worth considering, and given the small amount of work involved in implementing an email to recover abandoned carts, it’s a great place to start. Designers and developers are in a powerful position to help their clients increase their revenue, and being armed with tactics such as the ones outlined in this article will hopefully enable them to offer a wider range of services.
When you browse your favorite website or check the latest version of your product on your device of choice, take a moment to look at it differently. Step back from the screen. Close your eyes slightly so that your vision is a bit clouded by your eyelashes.
Can you still see and use the website?
Are you able to read the labels, fields, buttons, navigation and small footer text?
Can you imagine how someone who sees differently would read and use it?
In this article, I’ll share one aspect of design accessibility: making sure that the look and feel (the visual design of the content) are sufficiently inclusive of differently sighted users.
I am a design consultant on PayPal’s accessibility team. I assess how our product designs measure up to the Web Content Accessibility Guidelines (WCAG) 2.0, and I review our company’s design patterns and best practices.
I created our “Designers’ Accessibility Checklist,” and I will cover one of the most impactful guidelines on the checklist in this article: making sure that there is sufficient color contrast for all content. I’ll share the strategies, tips and tools that I use to help our teams deliver designs that most people can see and use without having to customize the experiences.
Who benefits from designs that have sufficient contrast? Quoting from the WCAG’s page:
The 4.5:1 ratio is used in this provision to account for the loss in contrast that results from moderately low visual acuity, congenital or acquired color deficiencies, or the loss of contrast sensitivity that typically accompanies aging.
As an accessibility consultant, I’m often asked how many people with disabilities use our products. Website analytics do not reveal this information. Let’s estimate how many people could benefit from designs with sufficient color contrast by reviewing the statistics:
Over the age of 40, most everyone will find that they need reading glasses or bifocals to clearly see small objects or text, a condition caused by the natural aging process, called presbyopia6.
Let’s estimate that 10% of the world population would benefit from designs that are easier to see. Multiply that by the number of customers or potential customers who use your website or application. For example, out of 2 million online customers, 200,000 would benefit.
Macular degeneration
Up to 50% of people are affected by age-related vision loss.
Diabetic retinopathy
In people with diabetes, leaking blood vessels in the eyes can cloud vision and cause blind spots.
Cataracts
Cataracts clouds the lens of the eye and decreases visual acuity.
Retinitis pigmentosa
This inherited condition gradually causes a loss of vision.
All of these conditions reduce sensitivity to contrast, and in some cases reduce the ability to distinguish colors.
Color-vision deficiencies, also called color-blindness, are mostly inherited and can be caused by side effects of medication and age-related low-vision conditions.
Deuteranopia
This is the most common and entails a reduced sensitivity to green light.
Protanopia
This is a reduced sensitivity to red light.
Tritanopia
This is a reduced sensitivity to blue light, but not very common.
Achromatopsia
People with this condition cannot see color at all, but it is not very common.
Reds and greens or colors that contain red or green can be difficult to distinguish for people with deuteranopia or protanopia.
Experience Seeing Differently
Creating a checklist and asking your designers to use it is easy, but in practice how do you make sure everyone follows the guidelines? We’ve found it important for designers not only to intellectually understand the why, but to experience for themselves what it is like to see differently. I’ve used a couple of strategies: immersing designers in interactive experiences through our Accessibility Showcase, and showing what designs look like using software simulations.
In mid-2013, we opened our PayPal Accessibility Showcase9 (video). Employees get a chance to experience first-hand what it is like for people with disabilities to use our products by interacting with web pages using goggles and/or assistive technology. We require that everyone who develops products participates in a tour. The user scenarios for designing with sufficient color contrast include wearing goggles that simulate conditions of low or partial vision and color deficiencies. Visitors try out these experiences on a PC, Mac or tablet. For mobile experiences, visitors wear the goggles and use their own mobile devices.
Fun fact: One wall in the showcase was painted with magnetic paint. The wall contains posters, messages and concepts that we want people to remember. At the end of the tour, I demonstrate vision simulators on our tablet. I view the message wall with the simulators to emphasize the importance of sufficient color contrast.
Showcase visitors wear goggles that simulate low-vision and color-blindness conditions.Some of the goggles used in the Accessibility Showcase.
Software Simulators
Mobile Apps
Free mobile apps are available for iOS and Android devices:
Chromatic Vision Simulator
Kazunori Asada’s app simulates three forms of color deficiencies: protanope (protanopia), deuteranope (deuteranopia) and tritanope (tritanopia). You can view and then save simulations using the camera feature, which takes a screenshot in the app. (Available for iOS6210 and Android6311.)
VisionSim
The Braille Institute’s app simulates a variety of low-vision conditions and provides a list of causes and symptoms for each condition. You can view and then save simulations using the camera feature, which takes a screenshot in the app. (Available for iOS6412 and Android.)13
Chromatic Vision Simulator
The following photos show orange and green buttons viewed through the Chromatic Vision Simulator:
14Seen through Chromatic Vision Simulator, the green and orange buttons show normal (C), protanope (P), deuteranope (D) and tritanope (T). (View large version15)
This example highlights the importance of another design accessibility guideline: Do not use color alone to convey meaning. If these buttons were online icons representing a system’s status (such as up or down), some people would have difficulty understanding it because there is no visible text and the shapes are the same. In this scenario, include visible text (i.e. text labels), as shown in the following example:
16The green and orange buttons are viewed in Photoshop with deuteranopia soft proof and normal (text labels added). (View large version17)
Mobile Device Simulations
Checking for sufficient color contrast becomes even more important on mobile devices. Viewing mobile applications through VisionSim or Chromatic Vision Simulator is easy if you have two mobile phones. View the mobile app that you want to test on the second phone running the simulator.
If you only have one mobile device, you can do the following:
Take screenshots of the mobile app on the device using the built-in camera.
Save the screenshots to a laptop or desktop.
Open and view the screenshots on the laptop, and use the simulators on the mobile device to view and save the simulations.
How’s the Weather in Cupertino?
The following example highlights the challenges of using a photograph as a background while making essential information easy to see. Notice that the large text and bold text are easier to see than the small text and small icons.
18The Weather mobile app, viewed with Chromatic Vision Simulator, shows normal, deuteranope, protanope and tritanope simulations. (View large version19)
Low-Vision Simulations
Using the VisionSim app, you can simulate macular degeneration, diabetic retinopathy, retinitis pigmentosa and cataracts.
20The Weather mobile app is being viewed with the supported condition simulations. (View large version21)
Adobe Photoshop
PayPal’s teams use Adobe Photoshop to design the look and feel of our user experiences. To date, a color-contrast ratio checker or tester is not built into Photoshop. But designers can use a couple of helpful features in Photoshop to check their designs for sufficient color contrast:
Convert designs to grayscale by going to “Select View” ? “Image” ? “Adjustments” ? “Grayscale.”
Simulate color blindness conditions by going to “Select View” ? “Proof Setup” ? “Color Blindness” and choosing protanopia type or deuteranopia type. Adobe provides soft-proofs for color blindness22.
Examples
If you’re designing with gradient backgrounds, verify that the color-contrast ratio passes for the text color and background color on both the lightest and darkest part of the gradient covered by the content or text.
In the following example of buttons, the first button has white text on a background with an orange gradient, which does not meet the minimum color-contrast ratio. A couple of suggested improvements are shown:
add a drop-shadow color that passes (center button),
change the text to a color that passes (third button).
Checking in Photoshop with the grayscale and deuteranopia proof, the modified versions with the drop shadow and dark text are easier to read than the white text.
If you design in sizes larger than actual production sizes, make sure to check how the design will appear in the actual web page or mobile device.
23Button with gradients: normal view; view in grayscale; and as a proof, deuteranopia. (View large version24)
In the following example of a form, the body text and link text pass the minimum color-contrast ratio for both the white and the gray background. I advise teams to always check the color contrast of text and links against all background colors that are part of the experience.
Even though the “Sign Up” link passes, if we view the experience in grayscale or with proof deuteranopia, distinguishing that “Sign Up” is a link might be difficult. To improve the affordance of “Sign Up” as a link, underline the link or link the entire phrase, “New to PayPal? Sign Up.”
25Form example: normal view; in Photoshop, a view in grayscale; and as a proof, deuteranopia. (View large version26)
Because red and green can be more difficult to distinguish for people with conditions such as deuteranopia and protanopia, should we avoid using them? Not necessarily. In the following example, a red minus sign (“-”) indicates purchasing or making a payment. Money received or refunded is indicated by a green plus sign (“+”). Viewing the design with proof, deuteranopia, the colors are not easy to distinguish, but the shapes are legible and unique. Next to the date, the description describes the type of payment. Both shape and content provide context for the information.
Also shown in this example, the rows for purchases and refunds alternate between white and light-gray backgrounds. If the same color text is used for both backgrounds, verify that all of the text colors pass for both white and gray backgrounds.
27Normal view and as a proof, deuteranopia: Check the text against the alternating background colors. (View large version28)
In some applications, form fields and/or buttons may be disabled until information has been entered by the user. Our design guidance does not require disabled elements to pass, in accordance with the WCAG 2.0’s “Contrast (Minimum): Understanding Success Criterion 1.4.34129:
Incidental: Text or images of text that are part of an inactive user interface component,… have no contrast requirement.
In the following example of a mobile app’s form, the button is disabled until a phone number and PIN have been entered. The text labels for the fields are a very light gray over a white background, which does not pass the minimum color-contrast ratio.
If the customer interprets that form elements with low contrast are disabled, would they assume that the entire form is disabled?
30Mobile app form showing disabled fields and button (left) and then enabled (right). (View large version31)
The same mobile app form is shown in a size closer to what I see on my phone in the following example. At a minimum, the text color needs to be changed or darkened to pass the minimum color-contrast ratio for normal body text and to improve readability.
To help distinguish between labels in fields and user-entered information, try to explore alternative visual treatments of form fields. Consider reversing foreground and background colors or using different font styles for labels and for user-entered information.
32Mobile app form example: normal, grayscale and proof deuteranopia. (View large version33)
NoCoffee Vision Simulator for Chrome
NoCoffee Vision Simulator6634 can be used to simulate color-vision deficiencies and low-vision conditions on any pages that are viewable in the Chrome browser. Using the “Color Deficiency” setting “achromatopsia,” you can view web pages in grayscale.
The following example shows the same photograph (featuring a call to action) viewed with some of the simulations available in NoCoffee. The message and call to action are separated from the background image by a practically opaque black container. This improves readability of the message and call to action. Testing the color contrast of the blue color in the headline against solid black passes for large text. Note that the link “Mobile” is not as easy to see because the blue does not pass the color-contrast standard for small body text. Possible improvements could be to change the link color to white and underline it, and/or make the entire phrase “Read more about Mobile” a link.
35Simulating achromatopsia (no color), deuteranopia, protanopia using NoCoffee. (View large version36)37Simulating low visual acuity, diabetic retinopathy, macular degeneration and low visual acuity plus retinitus pigmentosa, using NoCoffee. (View large version38)
Using Simulators
Simulators are useful tools to visualize how a design might be viewed by people who are aging, have low-vision conditions or have color-vision deficiencies.
For design reviews, I use the simulators to mock up a design in grayscale, and I might use color-blindness filters to show designers possible problems with color contrast. Some of the questions I ask are:
Is anything difficult to read?
Is the call to action easy to find and read?
Are links distinguishable from other content?
After learning how to use simulators to build empathy and to see their designs differently, I ask designers to use tools to check color contrast to verify that all of their designs meet the minimum color-contrast ratio of the WCAG 2.0 AA. The checklist includes a couple of tools they can use to test their designs.
Color-Contrast Ratio Checkers
The tools we cite in the designers’ checklist are these:
There are many tools to check color contrast, including ones that check live products. I’ve kept the list short to make it easy for designers to know what to use and to allow for consistent test results.
Our goal is to meet the WCAG 2.0 AA color-contrast ratio, which is 4.5 to 1 for normal text and 3 to 1 for large text.
What are the minimum sizes for normal text and large text? The guidance provides recommendations on size ratios in the WCAG’s Contrast (Minimum): Understanding Success Criterion 1.4.34129 but not a rule for a minimum size for body text. As noted in the WCAG’s guidance, thin decorative fonts might need to be larger and/or bold.
Testing Color-Contrast Ratio
You should test:
early in the design process;
when creating a visual design specification for any product or service (this documents all of the color codes and the look and feel of the user experience);
all new designs that are not part of an existing visual design guideline.
We want to make sure that body and normal text passes the WCAG 2.0 AA. Note that light gray (#999999) does not pass on a white background (#FFFFFF).
43Test dark-gray, medium-gray and light-gray using the WebAim Color Contrast Checker.(View large version44)
In the tool, you can modify the light gray (#999999) to find a color that does pass the AA. Select the “Darken” option to slightly change the color until it passes. By clicking the color field, you will have more options, and you can change color and luminosity, as shown in the second part of this example.
45In the WebAim Color Contrast Checker, modify the light gray using the “Darken” option, or use the color palette to find a color that passes. (View large version46)
Tabular information may be designed with alternating white and gray backgrounds to improve readability. Let’s test medium-gray text (#666666) and light-gray text (#757575) on a gray background (#E6E6E6).
Note that with the same background, the medium text passes, but the lighter gray passes only for large text. In this case, use medium gray for body text instead of white or gray backgrounds. Use the lighter gray only for large text, such as headings on white and gray backgrounds.
For mobile applications, designers might use RGB color codes to specify visual designs for engineering. You can use the TPG Colour Contrast Checker49. you will need to install either the PC or Mac version and run it side by side with Photoshop.
Let’s use the Colour Contrast Checker to test medium-gray text (102 102 102 in RGB and #666666 in hexadecimal) and light-gray text (#757575 in hexadecimal) on a gray background (230 230 230 in RGB and #E6E6E6 in hexadecimal).
Open the Colour Contrast Checker application.
Select “Options” ? “Displayed Color Values” ? “RGB.”
Under “Algorithm,” select “Luminosity.”
Enter the foreground and background colors in RGB: 102 102 102 for foreground and 230 230 230 for background. Mouse click or tab past the fields to view the results. Note that this combination passes for both text and large text (AA).
Select “Show details” to view the hexadecimal color values and information about both AA and AAA requirements.
In our example, light-gray text (117 117 117 in RGB) on a gray background (230 230 230 in RGB) does not meet the minimum AA contrast ratio for body text. To modify the colors, view the color wheels by clicking in the “Color” select box to modify the foreground or background. Or you can select “Options” ? “Show Color Sliders,” as shown in the example.
Colour Contrast Analyser, with RGB codes. Show color sliders to modify any color that does not meet minimum AA guidelines.
In most cases, minor adjustments to colors will meet the minimum contrast ratio, and comparisons before and after will show how better contrast enables most people to see and read more easily.
Best Practices
Test for color-contrast ratio, and document the styles and color codes used for all design elements. Create a visual design specification that includes the following:
typography for all textual elements, including headings, text links, body text and formatted text;
icons and glyphs and text equivalents;
form elements, buttons, validation and system error messaging;
background color and container styles (making sure text on these backgrounds all pass);
the visual treatments for disabled links, form elements and buttons (which do not need to pass a minimum color-contrast ratio).
Documenting visual guidelines for developers brings several benefits:
Developers don’t have to guess what the designers want.
Designs can be verified against the visual design specification during quality testing cycles, by engineers and designers.
A reference point that meets design accessibility guidelines for color contrast can be shared and leveraged by other teams.
Summary
If you are a designer, try out the simulators and tools on your next design project. Take time to see differently. One of the stellar designers who reviewed my checklist told me a story about using Photoshop’s color-blindness proofs. On his own, he used the proofs to refine the colors used in a design for his company’s product. When the redesigned product was released, his CEO thanked him because it was the first time he was able to see the design. The CEO shared that he was color-blind. In many cases, you may be unaware that your colleague, leader or customers have moderate low-vision or color-vision deficiencies. If meeting the minimum color-contrast ratio for a particular design element is difficult, take the challenge of thinking beyond color. Can you innovate so that most people can pick up and use your application without having to customize it?
If you are responsible for encouraging teams to build more accessible web or mobile experiences, be prepared to use multiple strategies:
Use immersive experiences to engage design teams and gain empathy for people who see differently.
Show designers how their designs might look using simulators.
Test designs that have low contrast, and show how slight modifications to colors can make a difference.
Encourage designers to test, and document visual specifications early and often.
Incorporate accessible design practices into reusable patterns and templates both in the code and the design.
Priorities and deadlines make it challenging for teams to deliver on all requests from multiple stakeholders. Be patient and persistent, and continue to engage with teams to find strategies to deliver user experiences that are easier to see and use by more people out of the box.
Enjoy one of those Deals of the Week that are few and far between. Grab really large stock photos for really small money. Mighty Deals, again the deal provider this week, had Depositphotos on offer in the past. That deal was wildly popular, and people didn’t stop calling for a reiteration. Today we have proof that their calls didn’t go unanswered. With the growth of Depositphoto’s portfolio you have even more excellent material to choose from, at the same laughable prices…
50+ Brand-new scary, yet free pictograms are offered by icons8, the icon foundry you can always trust. If you like to scare your friends at the end of October, here’s what you need. Hand-made for terror, these pictograms will look good in any app or website with the horror touch. Best of all, they are completely free of charge. Let’s take a closer look…
According to a recent report1, HTML is the most widely used language for mobile app developers. The main reasons among developers for selecting web technologies2 are cross-platform portability of code and the low cost of development. We’ve also heard that hybrid apps tend to be sluggish and poorly designed. Let’s prove whether it’s possible to deliver the native look and feel that we’re used to.
This article provides many hints, code snippets and lessons learned on how to build great hybrid mobile apps. I’ll briefly introduce hybrid mobile app development, including its benefits and drawbacks. Then, I’ll share lessons I’ve learned from over two years of developing Hojoki and CatchApp, both of which run natively on major mobile platforms and were built with HTML, CSS and JavaScript. Finally, we’ll review the most prominent tools to wrap code in a native app.
What Are Hybrid Mobile Apps?
Mobile apps can be generally broken down into native, hybrid and web apps. Going the native route allows you to use all of the capabilities of a device and operating system, with a minimum of performance overhead on a given platform. However, building a web app allows your code to be ported across platforms, which can dramatically reduce development time and cost. Hybrid apps combine the best of both worlds, using a common code base to deploy native-like apps to a wide range of platforms.
There are two approaches to building a hybrid app:
WebView app
The HTML, CSS and JavaScript code base runs in an internal browser (called WebView) that is wrapped in a native app. Some native APIs are exposed to JavaScript through this wrapper. Examples are Adobe PhoneGap3 and Trigger.io4.
Compiled hybrid app
The code is written in one language (such as C# or JavaScript) and gets compiled to native code for each supported platform. The result is a native app for each platform, but less freedom during development. Examples are Xamarin5, Appcelerator Titanium6 and Embarcadero FireMonkey7.
While both approaches are widely used and exist for good reasons, we’ll focus on WebView apps because they enable developers to leverage most of their existing web skills. Let’s look at all of the benefits and drawbacks of hybrid apps compared to both native and mobile web apps.
Benefits
Developer can use existing web skills
One code base for multiple platforms
Reduced development time and cost
Easily design for various form factors (including tablets) using responsive web design
Access to some device and operating system features
Advanced offline capabilities
Increased visibility because the app can be distributed natively (via app stores) and to mobile browsers (via search engines)
Drawbacks
Performance issues for certain types of apps (ones relying on complex native functionality or heavy transitions, such as 3D games)
Increased time and effort required to mimic a native UI and feel
Not all device and operating system features supported
Risk of being rejected by Apple if app does not feel native enough (for example, a simple website)
These drawbacks are significant and cannot be ignored, and they show that the hybrid approach does not suit all kinds of apps. You’ll need to carefully evaluate your target users, their platforms of choice and the app’s requirements. In the case of many apps, such as content-driven ones, the benefits outweigh the drawbacks. Such apps can typically be found in the “Business and Productivity,” “Enterprise” and “Media” categories in the app store.
Both Hojoki and CatchApp are very content-driven productivity apps, so we initially thought they would be a great match for hybrid development. The first three benefits mentioned above were especially helpful to us in building the mobile app for Hojoki in just four weeks. Obviously, that first version lacked many important things. The following weeks and months were filled with work on optimizing performance, crafting a custom UI for each platform and exploiting the advanced capabilities of different devices. The learning in that time was crucial to making the app look and feel native. I’ll share as many lessons as possible below.
So, how do you achieve a native look and feel? To a mobile web developer, being able to use the features of a device and operating system and being able to package their app for an app store sounds just awesome. However, if users are to believe it is a native app, then it will have to behave and look like one. Accomplishing this remains one of the biggest challenges for hybrid mobile developers.
Make Your Users Feel at Home
A single code base doesn’t mean that the app should look and feel exactly the same on all platforms. Your users will not care at all about the underlying cross-platform technology. They just want the app to behave as expected; they want to feel “at home.” Your first stop should be each platform’s design guidelines:
While these guidelines might not perfectly suit all kinds of apps, they still provide a comprehensive and standard set of interfaces and experiences that users on each platform will know and expect.
DIY vs. UI Frameworks
Implementing all of these components, patterns and animations on your own can be quite a challenge. All kinds of frameworks exist to help you with that, ranging from commercial (Kendo UI11) to open-source ones (Ionic12) and from ones with a common UI (jQuery Mobile13 and Onsen UI14) to many platform-specific UIs (Sencha Touch7615 and ChocolateChip-UI16). Some are really good at providing a pixel-perfect layout, while others are rather sloppy, thus making it easy for the user to identify a web app. However, my impression is that their main drawbacks are performance-related, because most UI frameworks try to be as all-embracing as possible. Judge for yourself by taking a few minutes to try the demos on your own device.
At Hojoki, we try to craft all components on our own using CSS3 and minimal JavaScript. This keeps us in control of performance and reduces overhead. We obviously use small libraries for complicated tasks that someone else has solved just fine.
Custom UI Components
Custom UI components also have many good use cases. Deciding between a platform’s UI and a custom UI will obviously depend on your target audience. If you want to do your own thing, you should have a deep understanding of UX design, because the guidelines linked to above were crafted by experts to meet the particular requirements of their platform’s users.
Whether you stick to a platform’s UI guidelines or do your own thing with custom components, know that there are certain design patterns that most people use every day and love. How are people usually introduced to a new app? Through a slideshow walkthrough or an instructional overlay. How do people navigate? With a tab bar or a sidebar drawer17. How do users quickly load or refresh data? By pulling to refresh. (Native-like scrolling will be covered extensively further below.)
One important part of a UI is the header bar, with its title and navigation elements, most notably the “up” and “back” buttons. To me, many popular frameworks fail to provide a HTML and CSS solution that compares to a native app. Mimicking this part of the UI with a minimal DOM and a few lines of CSS for each platform is actually fairly easy:
<header>
<button class="back">Feed</button>
<h1>Details</h1>
<!-- more actions (e.g. a search button on the right side) -->
</header>
Using the same DOM across all platforms is generally preferable because it results in cleaner code and, therefore, maximizes maintainability. I’ve found this to be easily possible for many UI components on iOS and Android (including the header bar, tab bar, custom navigation menu, settings page, popover and many more). However, this becomes much harder when adding support for Windows Phone, which comes with some very different design patterns.
Support High-Resolution Screens
Nowadays, smartphones and tablets with high-resolution screens make up the vast majority of mobile devices, making up more than 80% of iOS devices22 and over 70% on Android devices23. To make your images look crisp for everyone, you usually have to deliver twice the dimensions than what is actually shown in your app. Serving properly sized images for all different resolutions is one of the most discussed topics in responsive web design. There are various approaches, each with its benefits and drawbacks related to bandwidth, code maintainability and browser support. Let’s quickly review the most popular ones, in no particular order:
server-side resizing and delivering
client-side detection and replacement via JavaScript
HTML5 picture element
HTML5 srcset attribute
CSS image-set
CSS media queries
Resolution-independent images (SVG)
As always, there is no silver bullet for responsive images. It pretty much depends on the type of images and how they are used in the app. For static images (such as the logo and tutorial images), I try to use SVG. They scale perfectly without any extra effort and have great browser support as long as you’re fine with Android 3+24.
When SVG is not an option, the HTML5 picture element and srcset attributes25 are definitely where front-end development is heading. Currently, their main drawback is the very limited browser support and, therefore, their need for polyfills.
/* Normal-resolution CSS */
.logo {
width: 120px;
background: url(logo.png) no-repeat 0 0;
}
/* HD and Retina CSS */
@media
only screen and (-webkit-min-device-pixel-ratio: 1.25),
only screen and ( min--moz-device-pixel-ratio: 1.25),
only screen and ( -o-min-device-pixel-ratio: 1.25/1),
only screen and ( min-device-pixel-ratio: 1.25),
only screen and ( min-resolution: 200dpi),
only screen and ( min-resolution: 1.25dppx) {
.logo {
background: url(logo@2x.png) no-repeat 0 0;
background-size: 120px; /* Equal to normal logo width */
}
}
However, your app might already contain a lot of content (such as news articles), and adjusting all of the img tags or replacing them with CSS would be exhausting. A server-side solution is the best choice in this case.
Starting last year, more and more Android manufacturers have gone one step further with what is called XXHDPI (or very very high-resolution) screens. Whichever solution above fits your need, keep in mind that you’ll need images that are three times the original dimensions to support Android’s latest flagship devices.
Use System Fonts
A simple yet important way to make users feel at home is to use system fonts.
Furthermore, iOS 7 offers some interesting presets that automatically set the correct font family, font size and line height. It’s as easy as using font: -apple-system-body for normal text and font: -apple-system-headline for headings. This not only simplifies font declarations, but also improves accessibility through “dynamic type30,” Apple’s system-wide font-size setting. You can dig deeper into iOS 7 font presets in a post by Thomas Fuchs31.
An Icon Is Worth A Thousand Words
Iconography is an important part of the user experience on all major mobile platforms. As with fonts, you’re usually best off using icons that your target audience already knows. Recalling what I said about high-resolution screens earlier, make sure that your icons are scaleable. Implementing them as a font via CSS’ @font-face rule is a great way to achieve this, and it comes with wide browser support32. It even allows you to change an icon’s appearance (for example, its color, shadow and transparency) seamlessly via CSS. Here are my recommendations:
Get various platform icon fonts. Ionicons33 is our baseline set because it includes nearly everything we need. This includes specific icons for iOS and Android in addition to their general ones. The rest come from specific platform icon fonts for iOS34, Android set 135 and set 236 and Windows Phone37.
Combine them with a icon font generator.
Using multiple icon fonts is confusing and quickly adds up in size. That is why we use Fontello38 to combine the different sets, adjust key codes and export them for each platform. The result is s, which looks like a search icon on iOS, Android and Windows Phone. Also, check out the popular alternatives IcoMoon39 and Fontastic40.
Performance is usually considered to be one of the major disadvantages of a hybrid mobile app. This is mostly true if your app has a lot of heavy animations, contains huge scrolling lists and needs to run on old devices. However, if you are all right with supporting only newer platform versions (Android 4+, iOS 7+ and Windows Phone 8+), then you’ll very likely have satisfying results. It’s ultimately a question of how much effort you put into optimizing DOM and CSS selectors, writing performant JavaScript, reducing rendering time and minimizing the number of reflows and repaints. An endless number of articles and tutorials cover mobile web performance. These are some of my favorites:
Beyond that, mobile hardware and rendering engines are improving at a rapid pace, with new devices coming out every other day. Developers can make the performance of a hybrid WebView app difficult to distinguish from that of a fully native app on the iPhone 5 series and on Android phones comparable to Nexus 4 and 5.
Increase Perceived Speed
Building a performant app is one thing, but making it feel fast is a whole other. Whether your app needs some time for a certain task (such as some heavy calculation or client-server communication), presenting instant feedback is crucial to providing a fluid and responsive experience. A common technique is to delay tasks that the user doesn’t need yet, while predicting and preloading the steps the user might take next. A famous example is Instagram, which uploads photos in the background47 while the user is busy adding tags and sharing. Perceived speed can be very different from actual speed, so let’s use it in our favor. Here are some no-brainers.
Remove the Click Delay on Touch Devices
A normal JavaScript click event handler on a touch device comes with a slight delay between the touchstart and the click being fired (usually around 300 milliseconds). This feature is built into the browser to detect whether the user is performing a single- or double-tap. If you don’t need the “double-tap to zoom” feature, you can safely eliminate these 300 milliseconds to get a much more responsive tap behavior. My favorite solution for this is the FastClick48 library. Use it on everything except Internet Explorer:
if ('ontouchstart' in window) {
window.addEventListener('load', function() {
FastClick.attach(document.body);
}, false);
}
Internet Explorer 10+ is a bit easier. You just need some CSS:
As soon as the user taps an actionable element such as a button or a link, they should immediately get some kind of feedback that the app has detected their action. While the CSS pseudo-class :hover works great for this on the desktop, you need to switch to :active or a JavaScript solution for it to work on mobile. I’ve compared the three approaches to the active state49 on JSFiddle. While they all work one way or another, you judge which is best for you.
Furthermore, remove the default tap highlight while adjusting your active states on mobile. I’d also recommend disabling user selections on actionable elements, because the selection menu would be quite disruptive if the user accidentally taps the button for too long.
Whenever your app is performing an action that will take some time to finish, even just for a second, consider adding a loading indicator. If you don’t, users will think that your app freezes occasionally, or they’ll click around when they shouldn’t, or they might even break things and then blame your app. From what I’ve experienced, animated GIFs are usually a bad idea in mobile browsers. As soon as there is a load on the CPU, the GIF freezes, thus defeating its entire purpose. I prefer Spin.js50 for its configurability and ease of use. Also, check out some other JavaScript solutions51 and CSS loaders52.
Cross-platform tools like PhoneGap and Trigger.io also provide access to native loaders, which is great for showing a full-screen loading animation.
Get the Scrolling Right
Scrolling is one of the most important factors in the user experience of many apps. This is both a curse and a blessing because the success of its implementation will depend heavily on the scrolling niceties that your app relies on and on the mobile operating systems that need to be supported.
Scrollable content and a fixed header and/or footer bar are common to nearly all apps. There are two common approaches to achieving this with CSS:
Enabling scrolling on the body, and applying position: fixed to the header;
Disabling scrolling on the body, and applying overflow: scroll to the content;
Disabling scrolling on the body, and applying JavaScript custom scrolling to the content.
While the first option has some benefits (such as iOS’s native scroll-to-top action and a simple code structure), I highly recommend going with the second option, overflow: scroll. It has fewer rendering issues53 (although still a lot), and browser support is great on modern platforms (Android 4+, iOS 5+ and Windows Phone 8+), with a nice little polyfill for some older ones54. Alternatively, you could replace overflow: scroll with a custom scrolling library (the third option), such as iScroll55. While these JavaScript solutions allow for more flexibility with features (for example, the scroll position during momentum, event handling, customization of effects and scrollbars, etc.), they always penalize performance. This becomes critical when you’re using a lot of DOM nodes and/or CSS3 effects (such as box-shadow, text-shadow, opacity and rgba) in the content area.
Let’s look at some of the basic scrolling features.
Momentum Effect
The touch-friendly momentum effect enables users to quickly scroll through large content areas in an intuitive way. It can be easily activated with some simple CSS on iOS 5+ and in some versions of Chrome for Android. On iOS, this will also enable the content to bounce off the top and bottom edges.
Various solution for this are available on the web, such as the one by Damien Antipa5756. While the solutions for iOS and Windows Phone have a similar look and feel, Android recently introduced its own mechanism (see below). We’ve implemented this in CatchApp using some JavaScript and CSS keyframes. (I have yet to wrap it up nicely and put it on GitHub, so stay tuned!)
Unfortunately, disabling scrolling on the body will also break iOS’ native feature that enables users to quickly get to the top of the page by tapping the status bar. I’ve written a small script that can be added to any element and that takes care of scrolling to the top using JavaScript60, even if the content is currently in momentum. Add it to the header of your mobile website or to the status bar with a native plugin (for example, in PhoneGap).
Many other scrolling features could be implemented on top of the native overflow: scroll, such as snapping to a certain element or just infinite scrolling. If your requirements are more advanced, definitely look at the JavaScript options out there.
Make It Easy To Hit Stuff
When performing a touch action, users will quite often miss their target by a few pixels, especially on small buttons (such as the ones in iOS’ top bar). Developers can assist users while keeping the design elegant by enabling an invisible touch area around small targets:
You’ll have to put the event handler on the button element, while restricting the styles to div.innerButton. Check out the full example, including CSS61, on JSFiddle.
Using Touch Gestures
A smartphone is all about touching and gestures. We swipe, pinch, zoom, drag and long-tap all the time when interacting with touch devices. So, why not offer users the same means of controlling your hybrid app? QuoJS62 and Hammer.js63 are well-known libraries for supporting all kinds of gestures. If you’d like more choice, check out Kevin Liew’s comparison of “11 Multi-Touch and Touch Events JavaScript Libraries64.”
Don’t Miss Out on Native Functionality
Building your app with web technology doesn’t necessarily mean that you can’t use native features. In fact, all major cross-platform development tools provide built-in access to the most important functionality. This includes APIs for device data, the file system, the network connection, geolocation, the accelerometer, notifications (including push) and much more.
You can usually even extend a development tool by building custom plugins. At Hojoki, we added many missing features, including reading the user’s setting for push notifications for our app, detecting the user’s time zone, and checking whether a third-party app is installed and launching it. Let’s look at two very simple examples for things that can be realized with native plugins. First, let’s enable JavaScript focus() for input fields on iOS 6+:
Web developers often overlook how to handle bad situations in a hybrid app (for example, a connection timeout, a bad input, a timing issue, etc.). A hybrid app is fundamentally different from a website, mainly because there is no global refresh button, and an app can easily run in the background for weeks on some mobile operating systems. If the user runs into a dead end, their only option will be to restart the app, which entails force quitting and then restarting. Many people don’t even know how to do that, especially on Android 2.x (where it’s hidden deep in the app’s settings) and on iOS 6 and below (where you have to double-tap the home button, long-press the icon and kill it).
So, ignore the refresh button during development, and handle bad situations as they come up. For all other situations that would have unexpected outcomes, such as ones involving client-server communication, be prepared for things to go wrong, and provide a way out for users. This could be as easy as showing a full-screen error message — “Oops! Something bad happened. Please check your connection and try again” — with a big “Reload” button below.
How To Wrap It
Developing a hybrid mobile app means using the same tools and processes that you would usually use to develop (mobile) websites. Having said that, one thing I really like about the hybrid approach is that you can deploy HTML, CSS and JavaScript code as a mobile web app with relative ease. Make sure to implement fallbacks for native features, or find elegant workarounds if they are not supported at all. Most mobile developers prefer to keep users in a native app, and you could even advertise the app to your mobile website’s users.
65A native WebView wrapper, with an HTML, CSS and JavaScript code base. (View large version66)
What about the native part? Your mobile web app (plain HTML, CSS and JavaScript) will be loaded in a WebView, which is an internal browser engine that renders an app the way a default browser on the device would render it (there might be slight differences — your mileage may vary). Additionally, native “bridges” are used to expose features of the device and operating system through an API to make them accessible with JavaScript. This usually includes access to the device’s camera, address book, geolocation, file system and native events (for example, via one of the hardware buttons on Android), to name just a few features.
A few cross-platform development tools provide that native bridge and simplify the whole process of wrapping it. Let’s dive into some options.
PhoneGap and Apache Cordova
PhoneGap67 is certainly one of the most popular tools for cross-platform development. The name itself is often used synonymously with hybrid mobile app development.
There has been some confusion about its name68 and relation to Apache Cordova69, which is understandable. The latter is a top-level Apache project that was formerly called PhoneGap. It offers a set of device APIs to access native functionality from HTML, CSS and JavaScript code running in a WebView. Now, Adobe PhoneGap is a distribution of Cordova — not unlike the way Chrome uses WebKit as its engine.
Both are open-source and free to use, with support for all major platforms and with an active community developing all kinds of plugins and extensions.
PhoneGap has shaped the hybrid lanscape significantly, and many new tools have emerged that offer additional services or that streamline the development process. They usually add a lot of convenience by enabling you to build an app in the cloud, thereby saving you the effort of locally installing all of the different platform SDKs and tools. Each tool has a different focus, level of platform support and price:
Sencha Touch7615 started out as a UI framework for the mobile web and has been around for years. Traditionally, developers have used Sencha to build an app while using another service, like PhoneGap, to deploy it as a hybrid app. Nowadays, Sencha offers this kind of functionality built in for free. Platform support includes iOS and Android (both via Sencha’s own native packager) BlackBerry, Windows 8 and more (via PhoneGap Build).
Trigger.io
At Hojoki, we started using Trigger.io77 two and a half years ago because we were looking for a lightweight alternative to PhoneGap. Even though iOS and Android are its only supported platforms, it offers a good set of native APIs, custom plugins and third-party integration (including Parse push notifications, Flurry analytics and parts of Facebook’s SDK). Trigger.io’s command-line tools allowed us to integrate the app’s packaging into our Grunt78 build process, which is great if you love automation.
One of its key features is Reload9179, which enables developers to push HTML, CSS and JavaScript updates to an app on the fly. Unlike PhoneGap Build’s Hydration80, Reload is specifically designed for development and production apps. This makes it possible to legally bypass Apple’s submission process to push bug fixes and iterate quickly with A/B testing.
Once the 14-day trial is up, Trigger.io’s steep pricing81 is probably the biggest downside for many developers.
With MoSync having gone offline a couple of days ago, Trigger.io seems to be the only remaining tool that is not associated with PhoneGap.MoSync82 seems to be another tool that is not associated with PhoneGap, however I’m not sure how actively it is being developed at the moment.
Test on Real Devices
Building a mobile app with web technologies obviously tempts us to do most of our testing in a web browser. This might be fine when developing non-native features, but definitely avoid it when releasing. Test with as many manufacturers, platforms and form factors as possible before submitting the app. Android’s fragmentation brings endless possibilities of differences in browser rendering, unsupported features and manufacturer modifications. While iOS does much better with rendering differences, Apple has a growing number of devices with varying sizes, resolutions and pixel densities. Check out “Prioritizing Devices: Testing and Responsive Web Design83” to learn more.
When Facebook famously ditched most of its HTML5 and went native in 2012, it cited missing debugging tools and developer APIs84 as one of its main reasons. LinkedIn drew the same conclusions85 half a year later, stating that HTML5 itself is ready, but basic tools and the ecosystem don’t support it yet. From what I’m seeing, the situation is getting better, with remote debugging in WebView on Android 4.4+ and an increasing number of development tools on all platforms:
When building an app for web browsers, deploying a hot fix to users is a simple step, which means that testing can lose some of its importance. This obviously needs to be reconsidered when you’re releasing an app through an app store. Think of it like software development in the ’90s: You’re now living in the world of hard releases.
So, why is this bad? First, the submission process could easily take a week or two (Hello, Apple!). Secondly, even if your hot fix is released quickly, that doesn’t guarantee that users will update the app any time soon. Here are my suggestions:
Make testing a high priority.
Have some kind of “force update” logic to deprecate old client versions.
Use mechanisms like Trigger.io’s Reload9179 to fix code on the fly.
The tools mentioned above spit out a binary for each platform, which can then be submitted to the relevant store. From this point on, the process is exactly the same as publishing a “normal” native app. Some of the tools we’ve looked at might even have better documentation for this. Nevertheless, here are the official guides:
Now that our hybrid mobile apps have been in Apple’s App Store and in Google Play for two years, I’d like to recapitulate some of the benefits and drawbacks mentioned at the beginning of this article.
For us, a web startup company with very limited resources and no native iOS or Android experience, building an app for multiple platforms in just a few weeks would have been impossible. Choosing the hybrid path enabled us to reuse a lot of code from the web app and to iterate quickly based on user feedback. We’ve even managed to publish native apps for Windows 8 for the desktop and Microsoft Surface as well as Mac OS X with exactly the same code base. The effort of moving to another platform will depend largely on the capabilities of the given browser and device and on the level of your need for native functionality. We needed push notifications, in-app purchases and access to the user’s contacts, among other things. Depending on your needs, a lot of native functionality could make you heavily dependent on the native wrapping tool that you choose.
Finally, let’s see whether hybrid apps really can deliver a native look and feel. Below is a compilation of user reviews from the app stores. Both positive and negative comments are included, but many of the negative reviews are for early releases, which had the same UI for all platforms and was comparatively slow in performance.
? Great idea, but not a good app. The app runs extremely slow on my Samsung Galaxy Ace and Tab. The app also looks and controls like an iPhone app. This is confusing when you have never had an iPhone.
?? Another reason apps should not use WebViews for UI.
?? Service great but WebView app sucks.
??? It’s the right app in concept, but it really is too laggy to be practically used. And I’m using Jellybean so there is no excuse.
??? It lags a lot and the UI is not beautiful.
??? Good but very very slow.
???? This app is very handy, but is a little slow to boot up.
????? This is working really hard well since the update. It’s a great app to begin with and now it’s working smoother and faster than before.
????? Extremely smooth and effective.
????? The app work flawlessly…
????? Beautiful designed app! Love the interface and the great overview of all your tools! Good job! Keep shippin!
????? This is an absolutely beautiful aggregate that runs buttery smooth, even on a 3GS. Recommend to anyone doing any sort of project.
We’re definitely moving away from platform-specific app development and towards the many new technologies that are emerging. Larry Page said this97 when asked at Google I/O last year about the future of the web:
In the very long term, I don’t think you should have to think about, as a developer, am I developing for this platform or another, or something like that. I think you should be able to work at a much higher level, and software you write should run everywhere, easily.
The (mobile) web is a major success story in this regard. Being able to use this platform and still be able to distribute an app in all stores is a huge step forward. It will be interesting to see how this all plays out. Whatever happens, using a technology that over a third of the world’s population98 (over two thirds in Europe and the US) relies on probably won’t be a bad choice.
Beautiful art can be both awe-inspiring and intriguing. Some of it simply awakens the creativity or beauty inside of us all, and other stunning works of art makes us really think about deeper issues. No matter the level of intensity of the piece, great artworks cause most people to stop, if even for just a moment, to have an emotional experience. And this experience, these emotions, will be re-lived every time the viewer encounters that piece of art again.
Have you ever dreamt of buying a professionally crafted font for 30 cent, then woke up laughing? What one can dream… Today, with our most recent Deal of the Week, that dream can come true. Mighty Deals has exactly that on offer. More than 90 fonts from 18 different font families are up for grabs at two percent of their original price. Secure yourself a large set of professionally crafted Sans and Art fonts with all the benefits of the OTF format. Web fonts are available, too.
