Curt Long

Editor’s Note: In the world of web design, we tend to become preoccupied with the here and now. In “Resilient Web Design¹“, Jeremy Keith emphasizes the importance of learning from the past in order to better prepare ourselves for the future. So, perhaps we should stop and think more beyond our present moment? The following is an excerpt from Jeremy’s web book.

Design adds clarity. Using colour, typography, hierarchy, contrast, and all the other tools at their disposal, designers can take an unordered jumble of information and turn it into something that’s easy to use and pleasurable to behold. Like life itself, design can win a small victory against the entropy of the universe, creating pockets of order from the raw materials of chaos.

Further Reading on SmashingMag: Link²

• CSS Inheritance, The Cascade And Global Scope: Your New Old Worst Best Friends³
• Improving Your UI Design Skills With Copywork⁴
• Pursuing Semantic Value⁵

The Book of Kells is a beautifully illustrated manuscript created over 1200 years ago. It’s tempting to call it a work of art, but it is a work of design. The purpose of the book is to communicate a message; the gospels of the Christian religion. Through the use of illustration and calligraphy, that message is conveyed in an inviting context, making it pleasing to behold.

⁶

Design works within constraints. The Columban monks who crafted the Book of Kells worked with four inks on vellum, a material made of calfskin. The materials were simple but clearly defined. The cenobitic designers knew the hues of the inks, the weight of the vellum, and crucially, they knew the dimensions of each page.

Prints And The Revolution Link

Materials and processes have changed and evolved over the past millennium or so. Gutenberg’s invention of movable type was a revolution in production. Whereas it would have taken just as long to create a second copy of the Book of Kells as it took to create the first, multiple copies of the Gutenberg bible could be produced with much less labour. Even so, many of the design patterns such as drop caps and columns were carried over from illuminated manuscripts. The fundamental design process remained the same: knowing the width and height of the page, designers created a pleasing arrangement of elements.

⁸

The techniques of the print designer reached their zenith in the 20th century with the rise of the Swiss Style. Its structured layout and clear typography is exemplified in the work of designers like Josef Müller‐Brockmann and Jan Tschichold. They formulated grid systems and typographic scales based on the preceding centuries of design.

⁹

Knowing the ratio of the dimensions of a page, designers could position elements with maximum effect. The page is a constraint and the grid system is a way of imposing order on it.

Taking Your Talent To The Web Link

When the web began to conquer the world in the 1990s, designers started migrating from paper to pixels. David Siegel’s Creating Killer Websites came along at just the right time. Its clever TABLE and GIF hacks allowed designers to replicate the same kind of layouts that they had previously created for the printed page.

Those TABLE layouts later became CSS layouts, but the fundamental thinking remained the same: the browser window — like the page before it — was treated as a known constraint upon which designers imposed order.

There’s a problem with this approach. Whereas a piece of paper or vellum has a fixed ratio, a browser window could be any size. There’s no way for a web designer to know in advance what size any particular person’s browser window will be.

Designers had grown accustomed to knowing the dimensions of the rectangles they were designing within. The web removed that constraint.

If It Ain’t Fixed, Don’t Break It Link

There’s nothing quite as frightening as the unknown. These words of former US Secretary of Defense Donald Rumsfeld should be truly terrifying (although the general consensus at the time was that they sounded like nonsense):

There are known knowns. There are things we know we know. We also know there are known unknowns, that is to say we know there are some things we do not know. But there are also unknown unknowns — the ones we don’t know we don’t know.

The ratio of the browser window is just one example of a known unknown on the web. The simplest way to deal with this situation is to use flexible units for layout: percentages rather than pixels. Instead, designers chose to pretend that the browser dimensions were a known known. They created fixed‐width layouts for one specific window size.

In the early days of the web, most monitors were 640 pixels wide. Web designers created layouts that were 640 pixels wide. As more and more people began using monitors that were 800 pixels wide, more and more designers began creating 800 pixel wide layouts. A few years later, that became 1024 pixels. At some point web designers settled on the magic number of 960 pixels as the ideal width.

It was as though the web design community were participating in a shared consensual hallucination. Rather than acknowledge the flexible nature of the browser window, they chose to settle on one set width as the ideal …even if that meant changing the ideal every few years.

Not everyone went along with this web‐wide memo.

Dao Or Dao Not Link

In the year 2000 the online magazine A List Apart published an article entitled A Dao of Web Design. It has stood the test of time remarkably well.

In the article, John Allsopp points out that new mediums often start out by taking on the tropes of a previous medium. Scott McCloud makes the same point in his book Understanding Comics:

Each new medium begins its life by imitating its predecessors. Many early movies were like filmed stage plays; much early television was like radio with pictures or reduced movies.

With that in mind, it’s hardly surprising that web design began with attempts to recreate the kinds of layouts that designers were familiar with from the print world. As John put it:

“Killer Web Sites” are usually those which tame the wildness of the web, constraining pages as if they were made of paper — Desktop Publishing for the Web.

Web design can benefit from the centuries of learning that have informed print design. Massimo Vignelli, whose work epitomises the Swiss Style, begins his famous Canon with a list of The Intangibles including discipline, appropriateness, timelessness, responsibility, and more. Everything in that list can be applied to designing for the web. Vignelli’s Canon also includes a list of The Tangibles. That list begins with paper sizes.

The web is not print. The known constraints of paper — its width and height — simply don’t exist. The web isn’t bound by pre‐set dimensions. John Allsopp’s A Dao Of Web Design called on practitioners to acknowledge this:

The control which designers know in the print medium, and often desire in the web medium, is simply a function of the limitation of the printed page. We should embrace the fact that the web doesn’t have the same constraints, and design for this flexibility.

This call to arms went unheeded. Designers remained in their Matrix-like consensual hallucination where everyone’s browser was the same width. That’s understandable. There’s a great comfort to be had in believing a reassuring fiction, especially when it confers the illusion of control.

There is another reason why web designers clung to the comfort of their fixed‐width layouts. The tools of the trade encouraged a paper‐like approach to designing for the web.

Ship Of Tools Link

It’s a poor craftsperson who always blames their tools. And yet every craftsperson is influenced by their choice of tools. As Marshall McLuhan’s colleague John Culkin put it, “we shape our tools and thereafter our tools shape us.”

When the discipline of web design was emerging, there was no software created specifically for visualising layouts on the web. Instead designers co‐opted existing tools.

Adobe Photoshop was originally intended for image manipulation; touching up photos, applying filters, compositing layers, and so on. By the mid nineties it had become an indispensable tool for graphic designers. When those same designers began designing for the web, they continued using the software they were already familiar with.

If you’ve ever used Photoshop then you’ll know what happens when you select “New” from the “File” menu: you will be asked to enter fixed dimensions for the canvas you are about to work within. Before adding a single pixel, a fundamental design decision has been made that reinforces the consensual hallucination of an inflexible web.

Photoshop alone can’t take the blame for fixed‐width thinking. After all, it was never intended for designing web pages. Eventually, software was released with the specific goal of creating web pages. Macromedia’s Dreamweaver was an early example of a web design tool. Unfortunately it operated according to the idea of WYSIWYG: What You See Is What You Get.

While it’s true that when designing with Dreamweaver, what you see is what you get, on the web there is no guarantee that what you see is what everyone else will get. Once again, web designers were encouraged to embrace the illusion of control rather than face the inherent uncertainty of their medium.

It’s possible to overcome the built‐in biases of tools like Photoshop and Dreamweaver, but it isn’t easy. We might like to think that we are in control of our tools, that we bend them to our will, but the truth is that all software is opinionated software. As futurist Jamais Cascio put it, “software, like all technologies, is inherently political”:

Code inevitably reflects the choices, biases and desires of its creators.

Small wonder then that designers working with the grain of their tools produced websites that mirrored the assumptions baked into those tools — assumptions around the ability to control and tame the known unknowns of the World Wide Web.

Reality Bites Link

By the middle of the first decade of the twenty‐first century, the field of web design was propped up by multiple assumptions:

• that everyone was browsing with a screen large enough to view a 960 pixel wide layout;
• that everyone had broadband internet access, mitigating the need to optimise the number and file size of images on web pages;
• that everyone was using a modern web browser with the latest plug‐ins installed.

A minority of web designers were still pleading for fluid layouts. I counted myself amongst their number. We were tolerated in much the same manner as a prophet of doom on the street corner wearing a sandwich board reading “The End Is Nigh” — an inconvenient but harmless distraction.

There were even designers suggesting that Photoshop might not be the best tool for the web, and that we could consider designing directly in the browser using CSS and HTML. That approach was criticised as being too constraining. As we’ve seen, Photoshop has its own constraints but those had been internalised by designers so comfortable in using the tool that they no longer recognised its shortcomings.

This debate around the merits of designing Photoshop comps and designing in the browser would have remained largely academic if it weren’t for an event that would shake up the world of web design forever.

Stuck Inside Of Mobile Link

An iPod. A phone. And an internet communicator. An iPod. A phone …are you getting it? These are not three separate devices. This is one device. And we are calling it: iPhone.

With those words in 2007, Steve Jobs unveiled a mobile device that could be used to browse the World Wide Web.

¹¹

Web‐capable mobile devices existed before the iPhone, but they were mostly limited to displaying a specialised mobile‐friendly file format called WML. Very few devices could render HTML. With the introduction of the iPhone and its competitors, handheld devices were shipping with modern web browsers capable of being first‐class citizens on the web. This threw the field of web design into turmoil.

Assumptions that had formed the basis for an entire industry were now being called into question:

• How do we know if people are using wide desktop screens or narrow handheld screens?
• How do we know if people are browsing with a fast broadband connection at home or with a slow mobile network?
• How do we know if a device even supports a particular technology or plug‐in?

The rise of mobile devices was confronting web designers with the true nature of the web as a flexible medium filled with unknowns.

The initial reaction to this newly‐exposed reality involved segmentation. Rather than rethink the existing desktop‐optimised website, what if mobile devices could be shunted off to a separate silo? This mobile ghetto was often at a separate subdomain to the “real” site: m.example.com or mobile.example.com.

This segmented approach was bolstered by the use of the term “the mobile web” instead of the more accurate term “the web as experienced on mobile.” In the tradition of their earlier consensual hallucinations, web designers were thinking of mobile and desktop not just as separate classes of device, but as entirely separate websites.

Determining which devices were sent to which subdomain required checking the browser’s user‐agent string against an ever‐expanding list of known browsers. It was a Red Queen’s race just to stay up to date. As well as being error‐prone, it was also fairly arbitrary. While it might have once been easy to classify, say, an iPhone as a mobile device, that distinction grew more difficult over time. With the introduction of tablets such as the iPad, it was no longer clear which devices should be redirected to the mobile URL. Perhaps a new subdomain was called for — t.example.com or tablet.example.com — along with a new term like “the tablet web”. But what about the “TV web” or the “internet‐enabled fridge web?”

We Are One Link

The practice of creating different sites for different devices just didn’t scale. It also ran counter to a long‐held ideal called One Web:

One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using.

But this doesn’t mean that small‐screen devices should be served page layouts that were designed for larger dimensions:

However, it does not mean that exactly the same information is available in exactly the same representation across all devices.

If web designers wished to remain true to the spirit of One Web, they needed to provide the same core content at the same URL to everyone regardless of their device. At the same time, they needed to be able to create different layouts depending on the screen real‐estate available.

The shared illusion of a one‐size‐fits‐all approach to web design began to evaporate. It was gradually replaced by an acceptance of the ever‐changing fluid nature of the web.

Positive Response Link

In April of 2010 Ethan Marcotte stood on stage at An Event Apart in Seattle, a gathering for people who make websites. He spoke about an interesting school of thought in the world of architecture: responsive design, the idea that buildings could change and adapt according to the needs of the people using the building. This, he explained, could be a way to approach making websites.

One month later he expanded on this idea in an article called Responsive Web Design. It was published on A List Apart, the same website that had published John Allsopp’s A Dao Of Web Design ten years earlier. Ethan’s article shared the same spirit as John’s earlier rallying cry. In fact, Ethan begins his article by referencing A Dao Of Web Design.

Both articles called on web designers to embrace the idea of One Web. But whereas A Dao Of Web Design was largely rejected by designers comfortable with their WYSIWYG tools, Responsive Web Design found an audience of designers desperate to resolve the mobile conundrum.

The Adjacent Possible Link

Writer Steven Johnson has documented the history of invention and innovation. In his book Where Good Ideas Come From, he explores an idea called “the adjacent possible”:

At every moment in the timeline of an expanding biosphere, there are doors that cannot be unlocked yet. In human culture, we like to think of breakthrough ideas as sudden accelerations on the timeline, where a genius jumps ahead fifty years and invents something that normal minds, trapped in the present moment, couldn’t possibly have come up with. But the truth is that technological (and scientific) advances rarely break out of the adjacent possible; the history of cultural progress is, almost without exception, a story of one door leading to another door, exploring the palace one room at a time.

This is why the microwave oven could not have been invented in medieval France; there are too many preceding steps required — manufacturing, energy, theory — to make that kind of leap. Facebook could not exist without the World Wide Web, which could not exist without the internet, which could not exist without computers, and so on. Each step depends upon the accumulated layers below.

By the time Ethan coined the term Responsive Web Design a number of technological advances had fallen into place. As I wrote in the foreword to Ethan’s subsequent book on the topic:

The technologies existed already: fluid grids, flexible images, and media queries. But Ethan united these techniques under a single banner, and in so doing changed the way we think about web design.

1. Fluid grids. The option to use percentages instead of pixels has been with us since the days of TABLE layouts.
2. Flexible images. Research carried out by Richard Rutter showed that browsers were becoming increasingly adept at resizing images. The intrinsic dimensions of an image need not be a limiting factor.
3. Media queries. Thanks to the error‐handling model of CSS, browsers had been adding feature upon feature over time. One of those features was CSS media queries — the ability to define styles according to certain parameters, such as the dimensions of the browser window.

The layers were in place. A desire for change — driven by the relentless rise of mobile — was also in place. What was needed was a slogan under which these could be united. That’s what Ethan gave us with Responsive Web Design.

Changing Mindset Link

The first experiments in responsive design involved retrofitting existing desktop‐centric websites: converting pixels to percentages, and adding media queries to remove the grid layout on smaller screens. But this reactive approach didn’t provide a firm foundation to build upon. Fortunately another slogan was able to encapsulate a more resilient approach.

Luke Wroblewski coined the term Mobile First in response to the ascendency of mobile devices:

Losing 80% of your screen space forces you to focus. You need to make sure that what stays on the screen is the most important set of features for your customers and your business. There simply isn’t room for any interface debris or content of questionable value. You need to know what matters most.

If you can prioritise your content and make it work within the confined space of a small screen, then you will have created a robust, resilient design that you can build upon for larger screen sizes.

Stephanie and Bryan Rieger encapsulated the mobile‐first responsive design approach:

The lack of a media query is your first media query.

In this context, Mobile First is less about mobile devices per se, and instead focuses on prioritising content and tasks regardless of the device. It discourages assumptions. In the past, web designers had fallen foul of unfounded assumptions about desktop devices. Now it was equally important to avoid making assumptions about mobile devices.

Web designers could no longer make assumptions about screen sizes, bandwidth, or browser capabilities. They were left with the one aspect of the website that was genuinely under their control: the content.

Echoing A Dao Of Web Design, designer Mark Boulton put this new approach into a historical context:

Embrace the fluidity of the web. Design layouts and systems that can cope to whatever environment they may find themselves in. But the only way we can do any of this is to shed ways of thinking that have been shackles around our necks. They’re holding us back.

Start designing from the content out, rather than the canvas in.

This content‐out way of thinking is fundamentally different to the canvas‐in approach that dates all the way back to the Book of Kells. It asks web designers to give up the illusion of control and create a materially‐honest discipline for the World Wide Web.

Relinquishing control does not mean relinquishing quality. Quite the opposite. In acknowledging the many unknowns involved in designing for the web, designers can craft in a resilient flexible way that is true to the medium.

Texan web designer Trent Walton was initially wary of responsive design, but soon realised that it was a more honest, authentic approach than creating fixed‐width Photoshop mock‐ups:

My love for responsive centers around the idea that my website will meet you wherever you are — from mobile to full‐blown desktop and anywhere in between.

For years, web design was dictated by the designer. The user had no choice but to accommodate the site’s demand for a screen of a certain size or a network connection of a certain speed. Now, web design can be a conversation between the designer and the user. Now, web design can reflect the underlying principles of the web itself.

On the twentieth anniversary of the World Wide Web, Tim Berners‐Lee wrote an article for Scientific American in which he reiterated those underlying principles:

The primary design principle underlying the Web’s usefulness and growth is universality. The Web should be usable by people with disabilities. It must work with any form of information, be it a document or a point of data, and information of any quality — from a silly tweet to a scholarly paper. And it should be accessible from any kind of hardware that can connect to the Internet: stationary or mobile, small screen or large.

References Link

1. A Dao of Web Design¹³ by John Allsopp
2. The Vignelli Canon¹⁴ by Massimo Vignelli
3. Openness and the Metaverse Singularity¹⁵ by Jamais Cascio
4. One Web¹⁶ by Jo Rabin and Charles McCathieNevile
5. Responsive Web Design¹⁷ by Ethan Marcotte
6. A Richer Canvas¹⁸ by Mark Boulton
7. Fit To Scale¹⁹ by Trent Walton
8. Long Live the Web: A Call for Continued Open Standards and Neutrality²⁰ by Tim Berners‐Lee

(yk, il)

Footnotes Link

1. 1 https://resilientwebdesign.com/
2. 2 https://www.smashingmagazine.com/2016/11/building-shaders-with-babylon-js/#further-reading-on-smashingmag
3. 3 https://www.smashingmagazine.com/2016/11/css-inheritance-cascade-global-scope-new-old-worst-best-friends/
4. 4 https://www.smashingmagazine.com/2017/02/improving-ui-design-skills-copywork/
5. 5 https://www.smashingmagazine.com/2011/11/pursuing-semantic-value/
6. 6 https://www.smashingmagazine.com/wp-content/uploads/2017/03/book-of-kells-large-opt.jpg
7. 7 https://www.smashingmagazine.com/wp-content/uploads/2017/03/book-of-kells-large-opt.jpg
8. 8 https://www.smashingmagazine.com/wp-content/uploads/2017/03/gutenberg-bible-preview-opt.jpg
9. 9 https://www.smashingmagazine.com/wp-content/uploads/2017/03/jan-tchichold-medieval-manuscript-framework-large-opt.png
10. 10 https://www.smashingmagazine.com/wp-content/uploads/2017/03/jan-tchichold-medieval-manuscript-framework-large-opt.png
11. 11 https://www.smashingmagazine.com/wp-content/uploads/2017/03/iphone-large-opt.jpg
12. 12 https://www.smashingmagazine.com/wp-content/uploads/2017/03/iphone-large-opt.jpg
13. 13 http://alistapart.com/article/dao
14. 14 http://www.vignelli.com/canon.pdf
15. 15 http://www.kurzweilai.net/openness-and-the-metaverse-singularity
16. 16 https://www.w3.org/TR/mobile-bp/#OneWeb
17. 17 http://alistapart.com/article/responsive-web-design
18. 18 http://markboulton.co.uk/journal/a-richer-canvas
19. 19 http://trentwalton.com/2011/05/10/fit-to-scale/
20. 20 https://www.scientificamerican.com/article/long-live-the-web/

↑ Back to topTweet itShare on Facebook

The checkout page is the last page a user visits before finally decide to complete a purchase on your website. It’s where window shoppers turn into paying customers. If you want to leave a good impression, you should provide optimal usability of the billing form and improve it wherever it is possible to. In less than one day, you can add some simple and useful features to your project to make your billing form user-friendly and easy to fill in.

Further Reading on SmashingMag: Link

• Reducing Abandoned Shopping Carts In E-Commerce¹
• Form-Field Validation: The Errors-Only Approach²
• Fundamental Guidelines Of E-Commerce Checkout Design³
• An Extensive Guide To Web Form Usability⁴

Credit-card details are among the most commonly corrected fields in forms. Fortunately, nowadays almost every popular browser has an autofill feature, allowing the users to store their card data in the browser and to fill out form fields more quickly. Also, since iOS 8, mobile Safari users can scan their card’s information with the iPhone’s camera and fill in their card’s number, expiration date and name fields automatically. Autocomplete is simple, clear and built into HTML5, so we’ll add it to our form first.

Both autofill and card-scanning work only with forms that have special attributes: autocomplete for modern browsers (listed in the HTML5 standard⁵) and name for browsers without HTML5 support.

Note: A demo with all the functions covered below is available⁶. You can find its code in the GitHub repository⁷.

Credit cards have specific autofill attributes. For autocomplete:

• cc-name
• cc-number
• cc-csc
• cc-exp-month
• cc-exp-year
• cc-exp
• cc-type
• cc-csc

For name:

• ccname
• cardnumber
• cvc
• ccmonth
• ccyear
• expdate
• card-type
• cvc

To use autofill, you should add the relevant autocomplete and name attributes for the input elements in your index.html file:

<input type="text" placeholder="XXXX XXXX XXXX XXXX" pattern="[0-9]{14,23}" required autofocus autocomplete="cc-number" name="cardnumber"> <input type="text" placeholder="MM" pattern="[0-9]{1,2}" required autocomplete="cc-exp-month" name="ccmonth"> <input type="text" placeholder="YYYY" pattern="[0-9]{2,4}" required autocomplete="cc-exp-year" name="ccyear"> <input type="text" placeholder="CARDHOLDER NAME" required autocomplete="cc-name" name="ccname"> 

Don’t forget to use placeholder in input fields to help users understand the required data formats. We can provide input validation with HTML5 attributes: pattern (based on JavaScript regular expressions) and required. For example, with pattern="[0-9s]{14,23}" required attributes in a field, the user won’t be able to submit the form if the field is empty, has a non-numeric or non-space symbol, or is shorter than 14 symbols or longer than 23 symbols.

Once the user has saved their card data in the browser, we can see how it works:

⁸

Notice that using one field for the expiration date (MM/YYYY) is not recommended because Safari requires separate month and year fields to autocomplete.

Of course, autocomplete and autofill attributes are widely used not only for billing forms but also for names, email and postal addresses and passwords. You can save the user time and make them even happier by correctly using these attributes in your forms.

Even though we now have autocomplete, Google Payments and Apple Wallet, many users still prefer to enter their credit-card details manually, and no one is safe from making a typo with a 16-digit number. Long numbers are hard to read, even more painful to write and almost impossible to verify.

To help users feel comfortable with their long card number, we can divide it into four-digit groups by adding the simple VanillaMasker⁹ library by BankFacil to our project. Inputted data will be transformed to a masked string. So, we can add a custom pattern with spaces after every fourth digit of a card number, a two-digit pattern for the expiration month and a four-digit pattern for the expiration year. VanillaMasker can also verify data formats: If we have passed only “9” (the default number for the masker) to the ID, then all non-numeric characters will be deleted after input.

npm install vanilla-masker --save 

In our index.js file, let’s import the library and use it with one string for every field:

import masker from 'vanilla-masker'; const cardNumber = document.getElementById('card__input_number'); const cardMonth = document.getElementById('card__input_month'); const cardYear = document.getElementById('card__input_year'); masker(cardNumber).maskPattern('9999 9999 9999 9999 99'); masker(cardMonth).maskPattern('99'); masker(cardYear).maskPattern('9999'); 

Thus, the digits of the card number in our form will be separated, like on a real card:

¹⁰

The masker will erase characters with an incorrect value type or length, although our HTML validation will notify the user about invalid data only after the form has been submitted. But we can also check a card number’s correctness as it is being filled in. Did you know that all plastic credit-card numbers are generated according to the simple and effective Luhn algorithm? It was created in 1954 by Hans Peter Luhn and subsequently set as an international standard. We can include the Luhn algorithm to pre-validate the card number’s input field and warn the user about a typo.

To do this, we can use the tiny fast-luhn¹¹ npm package, adapted from Shirtless Kirk’s gist¹². We need to add it to our project’s dependencies:

npm install fast-luhn --save 

To use fast-luhn, we’ll import it in a module and just call luhn(number) on the input event to check whether the number is correct. For example, let’s add the card__input_invalid class to change the outline and field’s text color when the user has made an accidental error and a check has not been passed. Note that VanillaMasker adds a space after every four-digit group, so we need to convert the inputted value to a plain number without spaces using the split and join methods, before calling lunh.

The result is code that looks like this:

import luhn from 'fast-luhn'; const cardNumber = document.getElementById('card-number'); cardNumber.addEventListener('input', (event) => { const number = event.target.value; if (number.length >= 14) { const isLuhnCheckPassed = luhn(number.split(' ').join('')); cardNumber.classList.toggle('card__input_invalid', !isLuhnCheckPassed); cardNumber.classList.toggle('card__input_valid', isLuhnCheckPassed); } else { cardNumber.classList.remove('card__input_invalid', 'card__input_valid'); } }); 

To prevent luhn from being called while the user is typing, let’s call it only if the inputted number is as long as the minimum length with spaces (14 characters, including 12 digits) or longer, or else remove the card__input_invalid class.

Here are the validation examples in action:

¹³

The Luhn algorithm is also used for some discount card numbers, IMEI numbers, National Provider Identifier numbers in the US, and Social Insurance Numbers in Canada. So, this package isn’t limited to credit cards.

Many users want to check their card details with their own eyes, even if they know the form is being validated. But human beings perceive things in a way that makes comparison of differently styled numbers a little confusing. As we want the interface to be simple and intuitive, we can help users by showing a font that looks similar to the one they would find on a real card. Also, the font will make our card-like input form look more realistic and appropriate.

Several free credit-card fonts are available:

• Halter¹⁴, Apostrophic Labs
• Kredit¹⁵, Typodermic Fonts
• Credit Card¹⁶, K-Type (free for personal use)

We’ll use Halter. First, download the font, place it in the project’s folder, and create a CSS3 @font-face rule in style.css:

@font-face { font-family: Halter; src: url(font/HALTER__.ttf); } 

Then, simply add it to the font-family rule for the .card-input class:

.card-input { color: #777; font-family: Halter, monospace; } 

Don’t forget that if you input the CSS in a JavaScript file with the webpack bundle, you’ll need to add file-loader:

npm install file-loader --save 

And add file-loader for the font file types in webpack.config.js:

module: { loaders: [ { test: /.(ttf|eot|svg|woff(2)?)(?[a-z0-9=&.]+)?$/, loader: 'file', }], }, 

The result looks pretty good:

¹⁷

You can make it even fancier, if you like, with an embossed effect using a double text-shadow and a semi-transparency on the text’s color:

.card-input { color: rgba(84,110,122,0.5); text-shadow: -0.75px -0.75px white, 0.75px 0.75px 0 black; font-family: Halter, monospace; } 

¹⁸

Last but not least, you can pleasantly surprise customers by adding a coloring feature to the form. Every bank has its own brand color, which usually dominates that bank’s card. To make a billing form even more user-friendly, we can use this color and print the bank’s name above the form fields (corresponding to where it appears on a real card). This will also help the user to avoid making a typo in the number and to ensure they have picked the right card.

We can identify the bank of every user’s card by the first six digits, which contain the Issuer Identification Number (IIN) or Bank Identification Number (BIN). Banks DB¹⁹ by Ramoona is a database that gets a bank’s name and brand color from this prefix. The author has set up a demo of Banks DB²⁰.

This database is community-driven, so it doesn’t contain all of the world’s bank. If a user’s bank isn’t represented, the space for the bank’s name will be empty and the background will show the default color (#fafafa).

Banks DB assumes one of two ways of using it: with PostCSS or with CSS in JavaScript. We are using it with PostCSS. If you are new to PostCSS, this is a good reason to start using it. You can learn more about PostCSS in the official documentation²¹ or in Drew Minns’ article “An Introduction to PostCSS²²”.

We need to install the PostCSS Banks DB²³ plugin to set the CSS template for Banks DB and install the PostCSS Contrast²⁴ plugin to improve the readability of the bank’s name:

npm install banks-db postcss-banks-db postcss-contrast --save 

After that, we’ll add these new plugins to our PostCSS process in accordance with the module bundler and the load configuration used in our project. For example, with Webpack and postcss-load-config²⁵, simply add the new plugins to the .postcssrc file.

Then, in our style.css file, we need to add a new class rule template for Banks DB with the postcss-contrast plugin:

@banks-db-template { .card_bank-%code% { background-color: %color%; color: contrast(%color%); } } 

We could also set a long transition on the whole .card class to smoothly fade in and out the background and text color, so as not to startle users with an abrupt change:

.card { … transition: background 0.6s, color 0.6s; } 

Now, import Banks DB in index.js, and use it in the input event listener. If the BIN is represented in the database, we’ll add the class containing the bank’s name to the form in order to insert the name and change the form’s background.

import banksDB from 'banks-db'; const billingForm = document.querySelector('.card'); const bankName = document.querySelector('.card__bank-name'); const cardNumber = document.getElementById('card__input_number'); cardNumber.addEventListener('input', (event) => { const number = event.target.value; const bank = banksDB(number); if (bank.code) { billingForm.classList.add(`card_bank-${(bank.code || 'other')}`); bankName.innerText = bank.country === 'ru' ? bank.localTitle : bank.engTitle; } else { billingForm.className = 'card'; bankName.innerText = ''; } }); 

If you use webpack, add json-loader for the .json file extension to webpack’s configuration in order to input the database in the bundle correctly.

Here is a working example of Banks DB:

²⁶

In case you see no effect with your bank card, you can open an issue or add your bank to the database.²⁷

Conclusion Link

Improving your billing form can make the user experience much more intuitive and, as a result, ensure user convenience and increase confidence in your product. It’s an important part of web applications. We can improve it quickly and easily using these simple features:

• suitable autocomplete and name attributes for autofilling,
• placeholder attribute to inform the user of the input format,
• pattern and require attributes to prevent incorrect submission of form,
• VanillaMasker to separate card digits,
• fast-luhn to verify the card number,
• Halter font for easy comparison,
• Banks DB for a nicer presentation of colors.

Note that only Banks DB requires a module bundler; you can use the others within the simple script. Adding all of this functionality to your checkout page would most likely take less than a day.

(rb, al, il)

Footnotes Link

1. 1 https://www.smashingmagazine.com/2014/10/reducing-abandoned-shopping-carts/
2. 2 https://www.smashingmagazine.com/2012/06/form-field-validation-errors-only-approach/
3. 3 https://www.smashingmagazine.com/2011/04/fundamental-guidelines-of-e-commerce-checkout-design/
4. 4 https://www.smashingmagazine.com/2011/11/extensive-guide-web-form-usability/
5. 5 https://html.spec.whatwg.org/multipage/forms.html#inappropriate-for-the-control
6. 6 https://billing-form.herokuapp.com/
7. 7 https://github.com/gretchenfitze/billing-form
8. 8 https://www.smashingmagazine.com/wp-content/uploads/2017/01/1-autocomplete.gif
9. 9 https://github.com/BankFacil/vanilla-masker
10. 10 https://www.smashingmagazine.com/wp-content/uploads/2017/01/2-masker.gif
11. 11 https://www.npmjs.com/package/fast-luhn
12. 12 https://gist.github.com/ShirtlessKirk/2134376
13. 13 https://www.smashingmagazine.com/wp-content/uploads/2017/01/3-luhn.gif
14. 14 http://www.dafont.com/halter.font?text=ssfrshgrsdeh
15. 15 https://www.fontspring.com/fonts/typodermic/kredit
16. 16 http://www.k-type.com/fonts/credit-card/
17. 17 https://www.smashingmagazine.com/wp-content/uploads/2017/01/4-halter-1.png
18. 18 https://www.smashingmagazine.com/wp-content/uploads/2017/01/4-halter-2.png
19. 19 https://github.com/ramoona/banks-db
20. 20 https://ramoona.github.io/banks-db-demo/
21. 21 https://github.com/postcss/postcss
22. 22 https://www.smashingmagazine.com/2015/12/introduction-to-postcss/
23. 23 https://github.com/ramoona/postcss-banks-db
24. 24 https://github.com/stephenway/postcss-contrast
25. 25 https://github.com/michael-ciniawsky/postcss-load-config
26. 26 https://www.smashingmagazine.com/wp-content/uploads/2017/01/5-db.gif
27. 27 https://github.com/ramoona/banks-db#contributing

↑ Back to topTweet itShare on Facebook

I started out as a web developer, and that’s now one part of what I do as a full-stack developer, but never had I imagined I’d create things for the desktop. I love the web. I love how altruistic our community is, how it embraces open-source, testing and pushing the envelope. I love discovering beautiful websites and powerful apps. When I was first tasked with creating a desktop app, I was apprehensive and intimidated. It seemed like it would be difficult, or at least… different.

It’s not an attractive prospect, right? Would you have to learn a new language or three? Imagine an archaic, alien workflow, with ancient tooling, and none of those things you love about the web. How would your career be affected?

OK, take a breath. The reality is that, as a web developer, not only do you already possess all of the skills to make great modern desktop apps, but thanks to powerful new APIs at your disposal, the desktop is actually where your skills can be leveraged the most.

In this article, we’ll look at the development of desktop applications using NW.js¹ and Electron², the ups and downs of building one and living with one, using one code base for the desktop and the web, and more.

Further Reading on SmashingMag: Link

• Pixel-Perfect Specifications Without The Headaches³
• Building A First-Class App That Leverages Your Website⁴
• Mobile Considerations in UX Design: “Web or Native?”⁵
• A Beginner’s Guide To Progressive Web Apps⁶

Why? Link

First of all, why would anyone create a desktop app? Any existing web app (as opposed to a website, if you believe in the distinction) is probably suited to becoming a desktop app. You could build a desktop app around any web app that would benefit from integration in the user’s system; think native notifications, launching on startup, interacting with files, etc. Some users simply prefer having certain apps there permanently on their machine, accessible whether they have a connection or not.

Maybe you’ve an idea that would only work as a desktop app; some things simply aren’t possible with a web app (at least yet, but more about that in a little bit). You could create a self-contained utility app for internal company use, without requiring anyone to install anything other than your app (because Node.js in built-in). Maybe you’ve an idea for the Mac App Store. Maybe it would simply be a fun side project.

It’s hard to sum up why you should consider creating a desktop app because there are so many kinds of apps you could create. It really depends on what you’d like to achieve, how advantageous you find the additional APIs, and how much offline usage would enhance the experience for your users. For my team, it was a no-brainer because we were building a chat application⁷. On the other hand, a connection-dependent desktop app that doesn’t really have any desktop integration should be a web app and a web app alone. It wouldn’t be fair to expect a user to download your app (which includes a browser of its own and Node.js) when they wouldn’t get any more value from it than from visiting a URL of yours in their favorite browser.

Instead of describing the desktop app you personally should build and why, I’m hoping to spark an idea or at least spark your interest in this article. Read on to see just how easy it is to create powerful desktop apps using web technology and what that can afford you over (or alongside of) creating a web app.

NW.js Link

Desktop applications have been around a long time but you don’t have all day, so let’s skip some history and begin in Shanghai, 2011. Roger Wang, of Intel’s Open Source Technology Center, created node-webkit; a proof-of-concept Node.js module that allowed the user to spawn a WebKit browser window and use Node.js modules within <script> tags.

After some progress and a switch from WebKit to Chromium (the open-source project Google Chrome is based on), an intern named Cheng Zhao joined the project. It was soon realized that an app runtime based on Node.js and Chromium would make a nice framework for building desktop apps. The project went on be quite popular.

Note: node-webkit was later renamed NW.js to make it a bit more generic because it no longer used Node.js or WebKit. Instead of Node.js, it was based on io.js (the Node.js fork) at the time, and Chromium had moved on from WebKit to its own fork, Blink.

So, if you were to download an NW.js app, you would actually be downloading Chromium, plus Node.js, plus the actual app code. Not only does this mean a desktop app can be created using HTML, CSS and JavaScript, but the app would also have access to all of the Node.js APIs (to read and write to disk, for example), and the end user wouldn’t know any better. That’s pretty powerful, but how does it work? Well, first let’s take a look at Chromium.

⁸

There is a main background process, and each tab gets its own process. You might have seen that Google Chrome always has at least two processes in Windows’ task manager or macOS’ activity monitor. I haven’t even attempted to arrange the contents of the main process here, but it contains the Blink rendering engine, the V8 JavaScript engine (which is what Node.js is built on, too, by the way) and some platform APIs that abstract native APIs. Each isolated tab or renderer process has access to the JavaScript engine, CSS parser and so on, but it is completely separate to the main process for fault tolerance. Renderer processes interact with the main process through interprocess communication (IPC).

¹⁰

This is roughly what an NW.js app looks like. It’s basically the same, except that each window has access to Node.js now as well. So, you have access to the DOM and you can require other scripts, node modules you’ve installed from npm, or built-in modules provided by NW.js. By default, your app has one window, and from there you can spawn other windows.

Creating an app is really easy. All you need is an HTML file and a package.json, like you would have when working with Node.js. You can create a default one by running npm init --yes. Typically, a package.json would point a JavaScript file as the “main” file for the module (i.e. using the main property), but with NW.js you need to edit the main property to point to your HTML file.

{ "name": "example-app", "version": "1.0.0", "description": "", "main": "index.html", "scripts": { "test": "echo "Error: no test specified" && exit 1" }, "keywords": [], "author": "", "license": "ISC" } 

<!-- index.html --> <!DOCTYPE html> <html> <head> <title>Example app</title> <meta name="viewport" content="width=device-width, initial-scale=1"> </head> <body> <h1>Hello, world!</h1> </body> </html> 

Once you install the official nw package from npm (by running npm install -g nw), you can run nw . within the project directory to launch your app.

¹²

It’s as easy as that. So, what happened here was that NW.js opened the initial window, loading your HTML file. I know this doesn’t look like much, but it’s up to you add some markup and styles, just like you would in a web app.

You could drop the window bar and chrome if you like, or create your own custom frame. You could have semi to fully transparent windows, hidden windows and more. I took this a bit further recently and resurrected Clippy¹⁴ using NW.js. There’s something weirdly satisfying about seeing Clippy on macOS or Windows 10.

¹⁵

So, you get to write HTML, CSS and JavaScript. You can use Node.js to read and write to disk, execute system commands, spawn other executables and more. Hypothetically, you could build a multiplayer roulette game over WebRTC that deletes some of the users’ files randomly, if you wanted.

¹⁷

You get access not only to Node.js’ APIs but to all of npm, which has over 350,000 modules now. For example, auto-launch²⁰ is an open-source module we created at Teamwork.com²¹ to launch an NW.js or Electron app on startup.

Node.js also has what’s known as “native modules,” which, if you really need to do something a bit lower level, allows you to create modules in C or C++.

To top it all off, NW.js exposes APIs that effectively wrap native APIs, allowing you to integrate closely with the desktop environment. You can have a tray icon, open a file or URL in the default system application, and a lot lot more. All you need to do to trigger a notification is use the HTML5 notification API:

new Notification('Hello', { body: 'world' }); 

Electron Link

You might recognize GitHub’s text editor, Atom, below. Whether you use it or not, Atom was a game-changer for desktop apps. GitHub started development of Atom in 2013, soon recruited Cheng Zhao, and forked node-webkit as its base, which it later open-sourced under the name atom-shell.

²²

Note: It’s disputed whether Electron is a fork of node-webkit or whether everything was rewritten from scratch. Either way, it’s effectively a fork for the end user because the APIs were almost identical.

In making Atom, GitHub improved on the formula and ironed out a lot of the bugs. In 2015, atom-shell was renamed Electron. Since then it has hit version 1.0, and with GitHub pushing it, it has really taken off.

²⁴

As well as Atom, other notable projects built with Electron include Slack, Visual Studio Code, Brave, HyperTerm and Nylas, which is really doing some cutting-edge stuff with it. Mozilla Tofino is an interesting one, too. It was an internal project at Mozilla (the company behind Firefox), with the aim of radically improving web browsers. Yeah, a team within Mozilla chose Electron (which is based on Chromium) for this experiment.

How Does It Differ? Link

But how is it different from NW.js? First of all, Electron is less browser-oriented than NW.js. The entry point for an Electron app is a script that runs in the main process.

²⁶

The Electron team patched Chromium to allow for the embedding of multiple JavaScript engines that could run at the same time. So, when Chromium releases a new version, they don’t have to do anything.

Note: NW.js hooks into Chromium a little differently, and this was often blamed on the fact NW.js wasn’t quite as good at keeping up with Chromium as Electron was. However, throughout 2016, NW.js has released a new version within 24 hours of each major Chromium release, which the team attributes to an organizational shift.

Back to the main process. Your app hasn’t any window by default, but you can open as many windows as you’d like from the main process, each having its own renderer process, just like NW.js.

So, yeah, the minimum you need for an Electron app is a main JavaScript file (which we’ll leave empty for now) and a package.json that points to it. Then, all you need to do is npm install --save-dev electron and run electron . to launch your app.

{ "name": "example-app", "version": "1.0.0", "description": "", "main": "main.js", "scripts": { "test": "echo "Error: no test specified" && exit 1" }, "keywords": [], "author": "", "license": "ISC" } 

// main.js, which is empty 

Not much will happen, though, because your app hasn’t any window by default. You can open as many windows as you’d like from the main process, each having its own renderer process, just like they’d have in an NW.js app.

// main.js const {app, BrowserWindow} = require('electron'); let mainWindow; app.on('ready', () => { mainWindow = new BrowserWindow({ width: 500, height: 400 }); mainWindow.loadURL('file://' + __dirname + '/index.html'); }); 

<!-- index.html --> <!DOCTYPE html> <html> <head> <title>Example app</title> <meta name="viewport" content="width=device-width, initial-scale=1"> </head> <body> <h1>Hello, world!</h1> </body> </html> 

You could load a remote URL in this window, but typically you’d create a local HTML file and load that. Ta-da!

²⁸

Of the built-in modules Electron provides, like the app or BrowserWindow module used in the previous example, most can only be used in either the main or a renderer process. For example, the main process is where, and only where, you can manage your windows, automatic updates and more. You might want a click of a button to trigger something in your main process, though, so Electron comes with built-in methods for IPC. You can basically emit arbitrary events and listen for them on the other side. In this case, you’d catch the click event in the renderer process, emit an event over IPC to the main process, catch it in the main process and finally perform the action.

OK, so Electron has distinct processes, and you have to organize your app slightly differently, but that’s not a big deal. Why are people using Electron instead of NW.js? Well, there’s mindshare. So many related tools and modules are out there as a result of its popularity. The documentation is better. Most importantly, it has fewer bugs and superior APIs.

Electron’s documentation really is amazing, though — that’s worth emphasizing. Take the Electron API Demos app³⁰. It’s an Electron app that interactively demonstrates what you can do with Electron’s APIs. Not only is the API described and sample code provided for creating a new window, for example, but clicking a button will actually execute the code and a new window will open.

³¹

If you submit an issue via Electron’s bug tracker, you’ll get a response within a couple of days. I’ve seen three-year-old NW.js bugs, although I don’t hold it against them. It’s tough when an open-source project is written in languages drastically different from the languages known by its users. NW.js and Electron are written mostly in C++ (and a tiny bit of Objective C++) but used by people who write JavaScript. I’m extremely grateful for what NW.js has given us.

Electron ironed out a few of the flaws in the NW.js APIs. For example, you can bind global keyboard shortcuts, which would be caught even if your app isn’t focused. An example API flaw I ran into was that binding to Control + Shift + A in an NW.js app did what you would expect on Windows, but actually bound to Command + Shift + A on a Mac. This was intentional but really weird. There was no way to bind to the Control key. Also, binding to the Command key did bind to the Command key but the Windows key on Windows and Linux as well. The Electron team spotted these problems (when adding shortcuts to Atom I assume) and quickly updated their globalShortcut API so both of these cases work as you’d expect. To be fair, NW.js has since fixed the former but not the latter.

There are a few other differences. For instance, in recent NW.js versions, notifications that were previously native are now Chrome-style ones. These don’t go into the notification centre on Mac OS X or Windows 10, but there are modules on npm that you could use as a workaround if you’d like. If you want to do something interesting with audio or video, use Electron, because some codecs don’t work out of the box with NW.js.

Electron has added a few new APIs as well, more desktop integration, and it has built-in support for automatic updates, but I’ll cover that later.

But How Does It Feel? Link

It feels fine. Sure, it’s not native. Most desktop apps these days don’t look like Windows Explorer or Finder anyway, so users won’t mind or realize that HTML is behind your user interface. You can make it feel more native if you’d like, but I’m not convinced it will make the experience any better. For example, you could prevent the cursor from turning to a hand when the user hovers over a button. That’s how a native desktop app would act, but is that better? There are also projects out there like Photon Kit³³, which is basically a CSS framework like Bootstrap, but for macOS-style components.

³⁴

Performance Link

What about performance? Is it slow or laggy? Well, your app is essentially a web app. It’ll perform pretty much like a web app in Google Chrome. You can create a performant app or a sluggish one, but that’s fine because you already have the skills to analyze and improve performance. One of the best things about your app being based on Chromium is that you get its DevTools. You can debug within the app or remotely, and the Electron team has even created a DevTools extension named Devtron³⁶ to monitor some Electron-specific stuff.

Your desktop app can be more performant than a web app, though. One thing you could do is create a worker window, a hidden window that you use to perform any expensive work. Because it’s an isolated process, any computation or processing going on in that window won’t affect rendering, scrolling or anything else in your visible window(s).

Keep in mind that you can always spawn system commands, spawn executables or drop down to native code if you really need to (you won’t).

Distribution Link

Both NW.js and Electron support a wide array of platforms, including Windows, Mac and Linux. Electron doesn’t support Windows XP or Vista; NW.js does. Getting an NW.js app into the Mac App Store is a bit tricky; you’ll have to jump through a few hoops. Electron, on the other hand, comes with Mac App Store-compatible builds, which are just like the normal builds except that you don’t have access to some modules, such as the auto-updater module (which is fine because your app will update via the Mac App Store anyway).

Electron even supports ARM builds, so your app can run on a Chromebook or Raspberry Pi. Finally, Google may be phasing out Chrome Packaged Apps³⁷, but NW.js allows you to port an app over to an NW.js app and still have access the same Chromium APIs.

Even though 32-bit and 64-bit builds are supported, you’ll get away with 64-bit Mac and Windows apps. You will need 32-bit and 64-bit Linux apps, though, for compatibility.

So, let’s say that Electron has won over and you want to ship an Electron app. There’s a nice Node.js module named electron-packager³⁸ that helps with packing your app up into an .app or .exe file. A few similar projects exist, including interactive ones that prompt you step by step. You should use electron-builder⁷⁹³⁹, though, which builds on top of electron-packager, plus a few other related modules. It generates .dmgs and Windows installers and takes care of the code-signing of your app for you. This is really important. Without it, your app would be labelled as untrusted by operating systems, your app could trigger anti-virus software, and Microsoft SmartScreen might try to block the user from launching your app.

The annoying thing about code-signing is that you have to sign your app on a Mac for Mac and on Windows for Windows. So, if you’re serious about shipping desktop apps, then you’ll need to build on multiple machines for each release.

This can feel a bit too manual or tedious, especially if you’re used to creating for the web. Thankfully, electron-builder was created with automation in mind. I’m talking here about continuous integration tools and services such as Jenkins⁴⁰, CodeShip⁴¹, Travis-CI⁴², AppVeyor⁴³ (for Windows) and so on. These could run your desktop app build at the press of a button or at every push to GitHub, for example.

Automatic Updates Link

NW.js doesn’t have automatic update support, but you’ll have access to all of Node.js, so you can do whatever you want. Open-source modules are out there for it, such as node-webkit-updater⁴⁴, which handles downloading and replacing your app with a newer version. You could also roll your own custom system if you wanted.

Electron has built-in support for automatic updates, via its autoUpdater⁸⁰⁴⁵ API. It doesn’t support Linux, first of all; instead, publishing your app to Linux package managers is recommended. This is common on Linux — don’t worry. The autoUpdater API is really simple; once you give it a URL, you can call the checkForUpdates method. It’s event-driven, so you can subscribe to the update-downloaded event, for example, and once it’s fired, call the restartAndInstall method to install the new version and restart the app. You can listen for a few other events, which you can use to tie the auto-updating functionality into your user interface nicely.

Note: You can have multiple update channels if you want, such as Google Chrome and Google Chrome Canary.

It’s not quite as simple behind the API. It’s based on the Squirrel update framework, which differs drastically between Mac and Windows, which use the Squirrel.Mac⁴⁶ and Squirrel.Windows⁴⁷ projects, respectively.

The update code within your Mac Electron app is simple, but you’ll need a server (albeit a simple server). When you call the autoUpdater module’s checkForUpdates method, it will hit your server. What your server needs to do is return a 204 (“No Content”) if there isn’t an update; and if there is, it needs to return a 200 with a JSON containing a URL pointing to a .zip file. Back under the hood of your app (or the client), Squirrel.Mac will know what to do. It’ll go get that .zip, unzip it and fire the appropriate events.

There a bit more (magic) going on in your Windows app when it comes to automatic updates. You won’t need a server, but you can have one if you’d like. You could host the static (update) files somewhere, such as AWS S3, or even have them locally on your machine, which is really handy for testing. Despite the differences between Squirrel.Mac and Squirrel.Windows, a happy medium can be found; for example, having a server for both, and storing the updates on S3 or somewhere similar.

Squirrel.Windows has a couple of nice features over Squirrel.Mac as well. It applies updates in the background; so, when you call restartAndInstall, it’ll be a bit quicker because it’s ready and waiting. It also supports delta updates. Let’s say your app checks for updates and there is one newer version. A binary diff (between the currently installed app and the update) will be downloaded and applied as a patch to the current executable, instead of replacing it with a whole new app. It can even do that incrementally if you’re, say, three versions behind, but it will only do that if it’s worth it. Otherwise, if you’re, say, 15 versions behind, it will just download the latest version in its entirety instead. The great thing is that all of this is done under the hood for you. The API remains really simple. You check for updates, it will figure out the optimal method to apply the update, and it will let you know when it’s ready to go.

Note: You will have to generate those binary diffs, though, and host them alongside your standard updates. Thankfully, electron-builder generates these for you, too.

Thanks to the Electron community, you don’t have to build your own server if you don’t want to. There are open-source projects you can use. Some allow you to store updates on S3⁴⁸ or use GitHub releases⁴⁹, and some even go as far as providing administrative dashboards⁵⁰ to manage the updates.

Desktop Versus Web Link

So, how does making a desktop app differ from making a web app? Let’s look at a few unexpected problems or gains you might come across along the way, some unexpected side effects of APIs you’re used to using on the web, workflow pain points, maintenance woes and more.

Well, the first thing that comes to mind is browser lock-in. It’s like a guilty pleasure. If you’re making a desktop app exclusively, you’ll know exactly which Chromium version all of your users are on. Let your imagination run wild; you can use flexbox, ES6, pure WebSockets, WebRTC, anything you want. You can even enable experimental features in Chromium for your app (i.e. features coming down the line) or tweak settings such as your localStorage allowance. You’ll never have to deal with any cross-browser incompatibilities. This is on top of Node.js’ APIs and all of npm. You can do anything.

Note: You’ll still have to consider which operating system the user is running sometimes, though, but OS-sniffing is a lot more reliable and less frowned upon than browser sniffing.

Working With file:// Link

Another interesting thing is that your app is essentially offline-first. Keep that in mind when creating your app; a user can launch your app without a network connection and your app will run; it will still load the local files. You’ll need to pay more attention to how your app behaves if the network connection is lost while it’s running. You may need to adjust your mindset.

Note: You can load remote URLs if you really want, but I wouldn’t.

One tip I can give you here is not to trust navigator.onLine⁵¹ completely. This property returns a Boolean indicating whether or not there’s a connection, but watch out for false positives. It’ll return true if there’s any local connection without validating that connection. The Internet might not actually be accessible; it could be fooled by a dummy connection to a Vagrant virtual machine on your machine, etc. Instead, use Sindre Sorhus’ is-online⁵² module to double-check; it will ping the Internet’s root servers and/or the favicon of a few popular websites. For example:

const isOnline = require('is-online'); if(navigator.onLine){ // hmm there's a connection, but is the Internet accessible? isOnline().then(online => { console.log(online); // true or false }); } else { // we can trust navigator.onLine when it says there is no connection console.log(false); } 

Speaking of local files, there are a few things to be aware of when using the file:// protocol — protocol-less URLs, for one; you can’t use them anymore. I mean URLs that start with // instead of http:// or https://. Typically, if a web app requests //example.com/hello.json, then your browser would expand this to http://example.com/hello.json or to https://example.com/hello.json if the current page is loaded over HTTPS. In our app, the current page would load using the file:// protocol; so, if we requested the same URL, it would expand to file://example.com/hello.json and fail. The real worry here is third-party modules you might be using; authors aren’t thinking of desktop apps when they make a library.

You’d never use a CDN. Loading local files is basically instantaneous. There’s also no limit on the number of concurrent requests (per domain), like there is on the web (with HTTP/1.1 at least). You can load as many as you want in parallel.

Artifacts Galore Link

A lot of asset generation is involved in creating a solid desktop app. You’ll need to generate executables and installers and decide on an auto-update system. Then, for each update, you’ll have to build the executables again, more installers (because if someone goes to your website to download it, they should get the latest version) and binary diffs for delta updates.

Weight is still a concern. A “Hello, World!” Electron app is 40 MB zipped. Besides the typical advice you follow when creating a web app (write less code, minify it, have fewer dependencies, etc.), there isn’t much I can offer you. The “Hello, World!” app is literally an app containing one HTML file; most of the weight comes from the fact that Chromium and Node.js are baked into your app. At least delta updates will reduce how much is downloaded when a user performs an update (on Windows only, I’m afraid). However, your users won’t be downloading your app on a 2G connection (hopefully!).

Expect the Unexpected Link

You will discover unexpected behavior now and again. Some of it is more obvious than the rest, but a little annoying nonetheless. For example, let’s say you’ve made a music player app that supports a mini-player mode, in which the window is really small and always in front of any other apps. If a user were to click or tap a dropdown (<select/>), then it would open to reveal its options, overflowing past the bottom edge of the app. If you were to use a non-native select library (such as select2 or chosen), though, you’re in trouble. When open, your dropdown will be cut off by the edge of your app. So, the user would see a few items and then nothing, which is really frustrating. This would happen in a web browser, too, but it’s not often the user would resize the window down to a small enough size.

⁵³

You may or may not know it, but on a Mac, every window has a header and a body. When a window isn’t focused, if you hover over an icon or button in the header, its appearance will reflect the fact that it’s being hovered over. For example, the close button on macOS is gray when the window is blurred but red when you hover over it. However, if you move your mouse over something in the body of the window, there is no visible change. This is intentional. Think about your desktop app, though; it’s Chromium missing the header, and your app is the web page, which is the body of the window. You could drop the native frame and create your own custom HTML buttons instead for minimize, maximize and close. If your window isn’t focused, though, they won’t react if you were to hover over them. Hover styles won’t be applied, and that feels really wrong. To make it worse, if you were to click the close button, for example, it would focus the window and that’s it. A second click would be required to actually click the button and close the app.

To add insult to injury, Chromium has a bug that can mask the problem, making you think it works as you might have originally expected. If you move your mouse fast enough (nothing too unreasonable) from outside the window to an element inside the window, hover styles will be applied to that element. It’s a confirmed bug; applying the hover styles on a blurred window body “doesn’t meet platform expectations,” so it will be fixed. Hopefully, I’m saving you some heartbreak here. You could have a situation in which you’ve created beautiful custom window controls, yet in reality a lot of your users will be frustrated with your app (and will guess it’s not native).

So, you must use native buttons on a Mac. There’s no way around that. For an NW.js app, you must enable the native frame, which is the default anyway (you can disable it by setting window object’s frame property to false in your package.json).

You could do the same with an Electron app. This is controlled by setting the frame property when creating a window; for example, new BrowserWindow({width: 800, height: 600, frame: true}). As the Electron team does, they spotted this issue and added another option as a nice compromise; titleBarStyle. Setting this to hidden will hide the native title bar but keep the native window controls overlaid over the top-left corner of your app. This gets you around the problem of having non-native buttons on Mac, but you can still style the top of the app (and the area behind the buttons) however you like.

// main.js const {app, BrowserWindow} = require('electron'); let mainWindow; app.on('ready', () => { mainWindow = new BrowserWindow({ width: 500, height: 400, titleBarStyle: 'hidden' }); mainWindow.loadURL('file://' + __dirname + '/index.html'); }); 

Here’s an app in which I’ve disabled the title bar and given the html element a background image:

⁵⁵

See “Frameless Window⁵⁷” from Electron’s documentation for more.

Tooling Link

Well, you can pretty much use all of the tooling you’d use to create a web app. Your app is just HTML, CSS and JavaScript, right? Plenty of plugins and modules are out there specifically for desktop apps, too, such as Gulp plugins for signing your app, for example (if you didn’t want to use electron-builder). Electron-connect⁵⁸ watches your files for changes, and when they occur, it’ll inject those changes into your open window(s) or relaunch the app if it was your main script that was modified. It is Node.js, after all; you can pretty much do anything you’d like. You could run webpack inside your app if you wanted to — I’ve no idea why you would, but the options are endless. Make sure to check out awesome-electron⁵⁹ for more resources.

Release Flow Link

What’s it like to maintain and live with a desktop app? First of all, the release flow is completely different. A significant mindset adjustment is required. When you’re working on the web app and you deploy a change that breaks something, it’s not really a huge deal (of course, that depends on your app and the bug). You can just roll out a fix. Users who reload or change the page and new users who trickle in will get the latest code. Developers under pressure might rush out a feature for a deadline and fix bugs as they’re reported or noticed. You can’t do that with desktop apps. You can’t take back updates you push out there. It’s more like a mobile app flow. You build the app, put it out there, and you can’t take it back. Some users might not even update from a buggy version to the fixed version. This will make you worry about all of the bugs out there in old versions.

Quantum Mechanics Link

Because a host of different versions of your app are in use, your code will exist in multiple forms and states. Multiple variants of your client (desktop app) could be hitting your API in 10 slightly different ways. So, you’ll need to strongly consider versioning your API, really locking down and testing it well. When an API change is to be introduced, you might not be sure if it’s a breaking change or not. A version released a month ago could implode because it has some slightly different code.

Fresh Problems to Solve Link

You might receive a few strange bug reports — ones that involve bizarre user account arrangements, specific antivirus software or worse. I had a case in which a user had installed something (or had done something themselves) that messed with their system’s environment variables. This broke our app because a dependency we used for something critical failed to execute a system command because the command could no longer be found. This is a good example because there will be occasions when you’ll have to draw a line. This was something critical to our app, so we couldn’t ignore the error, and we couldn’t fix their machine. For users like this, a lot of their desktop apps would be somewhat broken at best. In the end, we decided to show a tailored error screen to the user if this unlikely error were ever to pop up again. It links to a document explaining why it has occurred and has a step-by-step guide to fix it.

Sure, a few web-specific concerns are no longer applicable when you’re working on a desktop app, such as legacy browsers. You will have a few new ones to take into consideration, though. There’s a 256-character limit on file paths in Windows, for example.

Old versions of npm store dependencies in a recursive file structure. Your dependencies would each get stored in their own directory within a node_modules directory in your project (for example, node_modules/a). If any of your dependencies have dependencies of their own, those grandchild dependencies would be stored in a node_modules within that directory (for example, node_modules/a/node_modules/b). Because Node.js and npm encourage small single-purpose modules, you could easily end up with a really long path, like path/to/your/project/node_modules/a/node_modules/b/node_modules/c/.../n/index.js.

Note: Since version 3, npm flattens out the dependency tree as much as possible. However, there are other causes for long paths.

We had a case in which our app wouldn’t launch at all (or would crash soon after launching) on certain versions of Windows due to an exceeding long path. This was a major headache. With Electron, you can put all of your app’s code into an asar archive⁶⁰, which protects against path length issues but has exceptions and can’t always be used.

We created a little Gulp plugin named gulp-path-length⁶¹, which lets you know whether any dangerously long file paths are in your app. Where your app is stored on the end user’s machine will determine the true length of the path, though. In our case, our installer will install it to C:Users<username>AppDataRoaming. So, when our app is built (locally by us or by a continuous integration service), gulp-path-length is instructed to audit our files as if they’re stored there (on the user’s machine with a long username, to be safe).

var gulp = require('gulp'); var pathLength = require('gulp-path-length'); gulp.task('default', function(){ gulp.src('./example/**/*', {read: false}) .pipe(pathLength({ rewrite: { match: './example', replacement: 'C:\Users\this-is-a-long-username\AppData\Roaming\Teamwork Chat\' } })); }); 

Fatal Errors Can Be Really Fatal Link

Because all of the automatic updates handling is done within the app, you could have an uncaught exception that crashes the app before it even gets to check for an update. Let’s say you discover the bug and release a new version containing a fix. If the user launches the app, an update would start downloading, and then the app would die. If they were to relaunch app, the update would start downloading again and… crash. So, you’d have to reach out to all of your users and let them know they’ll need to reinstall the app. Trust me, I know. It’s horrible.

Analytics and Bug Reports Link

You’ll probably want to track usage of the app and any errors that occur. First of all, Google Analytics won’t work (out of the box, at least). You’ll have to find something that doesn’t mind an app that runs on file:// URLs. If you’re using a tool to track errors, make sure to lock down errors by app version if the tool supports release-tracking. For example, if you’re using Sentry⁶² to track errors, make sure to set the release property when setting up your client⁶³, so that errors will be split up by app version. Otherwise, if you receive a report about an error and roll out a fix, you’ll keep on receiving reports about the error, filling up your reports or logs with false positives. These errors will be coming from people using older versions.

Electron has a crashReporter⁶⁴ module, which will send you a report any time the app completely crashes (i.e. the entire app dies, not for any old error thrown). You can also listen for events indicating that your renderer process has become unresponsive.

Security Link

Be extra-careful when accepting user input or even trusting third-party scripts, because a malicious individual could have a lot of fun with access to Node.js. Also, never accept user input and pass it to a native API or command without proper sanitation.

Don’t trust code from vendors either. We had a problem recently with a third-party snippet we had included in our app for analytics, provided by company X. The team behind it rolled out an update with some dodgy code, thereby introducing a fatal error in our app. When a user launched our app, the snippet grabbed the newest JavaScript from their CDN and ran it. The error thrown prevented anything further from executing. Anyone with the app already running was unaffected, but if they were to quit it and launch it again, they’d have the problem, too. We contacted X’s support team and they promptly rolled out a fix. Our app was fine again once our users restarted it, but it was scary there for a while. We wouldn’t have been able to patch the problem ourselves without forcing affected users to manually download a new version of the app (with the snippet removed).

How can you mitigate this risk? You could try to catch errors, but you’ve no idea what they company X might do in its JavaScript, so you’re better off with something more solid. You could add a level of abstraction. Instead of pointing directly to X’s URL from your <script>, you could use Google Tag Manager⁶⁵ or your own API to return either HTML containing the <script> tags or a single JavaScript file containing all of your third-party dependencies somehow. This would enable you to change which snippets get loaded (by tweaking Google Tag Manager or your API endpoint) without having to roll out a new update.

However, if the API no longer returned the analytics snippet, the global variable created by the snippet would still be there in your code, trying to call undefined functions. So, we haven’t solved the problem entirely. Also, this API call would fail if a user launches the app without a connection. You don’t want to restrict your app when offline. Sure, you could use a cached result from the last time the request succeeded, but what if there was a bug in that version? You’re back to the same problem.

Another solution would be to create a hidden window and load a (local) HTML file there that contains all of your third-party snippets. So, any global variables that the snippets create would be scoped to that window. Any errors thrown would be thrown in that window and your main window(s) would be unaffected. If you needed to use those APIs or global variables in your main window(s), you’d do this via IPC now. You’d send an event over IPC to your main process, which would then send it onto the hidden window, and if it was still healthy, it would listen for the event and call the third-party function. That would work.

This brings us back to security. What if someone malicious at company X were to include some dangerous Node.js code in their JavaScript? We’d be rightly screwed. Luckily, Electron has a nice option to disable Node.js for a given window, so it simply wouldn’t run:

// main.js const {app, BrowserWindow} = require('electron'); let thirdPartyWindow; app.on('ready', () => { thirdPartyWindow = new BrowserWindow({ width: 500, height: 400, webPreferences: { nodeIntegration: false } }); thirdPartyWindow.loadURL('file://' + __dirname + '/third-party-snippets.html'); }); 

Automated Testing Link

NW.js doesn’t have any built-in support for testing. But, again, you have access to Node.js, so it’s technically possible. There is a way to test stuff such as button-clicking within the app using Chrome Remote Interface⁶⁶, but it’s tricky. Even then, you can’t trigger a click on a native window control and test what happens, for example.

The Electron team has created Spectron⁶⁷ for automated testing, and it supports testing native controls, managing windows and simulating Electron events. It can even be run in continuous integration builds.

var Application = require('spectron').Application var assert = require('assert') describe('application launch', function () { this.timeout(10000) beforeEach(function () { this.app = new Application({ path: '/Applications/MyApp.app/Contents/MacOS/MyApp' }) return this.app.start() }) afterEach(function () { if (this.app && this.app.isRunning()) { return this.app.stop() } }) it('shows an initial window', function () { return this.app.client.getWindowCount().then(function (count) { assert.equal(count, 1) }) }) }) 

Because your app is HTML, you could easily use any tool to test web apps, just by pointing the tool at your static files. However, in this case, you’d need to make sure the app can run in a web browser without Node.js.

Desktop And Web Link

It’s not necessarily about desktop or web. As a web developer, you have all of the tools required to make an app for either environment. Why not both? It takes a bit more effort, but it’s worth it. I’ll mention a few related topics and tools, which are complicated in their own right, so I’ll keep just touch on them.

First of all, forget about “browser lock-in,” native WebSockets, etc. The same goes for ES6. You can either revert to writing plain old ES5 JavaScript or use something like Babel⁶⁸ to transpile your ES6 into ES5, for web use.

You also have requires throughout your code (for importing other scripts or modules), which a browser won’t understand. Use a module bundler that supports CommonJS (i.e. Node.js-style requires), such as Rollup⁶⁹, webpack⁷⁰ or Browserify⁷¹. When making a build for the web, a module bundler will run over your code, traverse all of the requires and bundle them up into one script for you.

Any code using Node.js or Electron APIs (i.e. to write to disk or integrate with the desktop environment) should not be called when the app is running on the web. You can detect this by checking whether process.version.nwjs or process.versions.electron exists; if it does, then your app is currently running in the desktop environment.

Even then, you’ll be loading a lot of redundant code in the web app. Let’s say you have a require guarded behind a check like if(app.isInDesktop), along with a big chunk of desktop-specific code. Instead of detecting the environment at runtime and setting app.isInDesktop, you could pass true or false into your app as a flag at buildtime (for example, using the envify⁷² transform for Browserify). This will aide your module bundler of choice when it’s doing its static analysis and tree-shaking (i.e. dead-code elimination). It will now know whether app.isInDesktop is true. So, if you’re running your web build, it won’t bother going inside that if statement or traversing the require in question.

Continuous Delivery Link

There’s that release mindset again; it’s challenging. When you’re working on the web, you want to be able to roll out changes frequently. I believe in continually delivering small incremental changes that can be rolled back quickly. Ideally, with enough testing, an intern can push a little tweak to your master branch, resulting in your web app being automatically tested and deployed.

As we covered earlier, you can’t really do this with a desktop app. OK, I guess you technically could if you’re using Electron, because electron-builder can be automated and, so, can spectron tests. I don’t know anyone doing this, and I wouldn’t have enough faith to do it myself. Remember, broken code can’t be taken back, and you could break the update flow. Besides, you don’t want to deliver desktop updates too often anyway. Updates aren’t silent, like they are on the web, so it’s not very nice for the user. Plus, for users on macOS, delta updates aren’t supported, so users would be downloading a full new app for each release, no matter how small a tweak it has.

You’ll have to find a balance. A happy medium might be to release all fixes to the web as soon as possible and release a desktop app weekly or monthly — unless you’re releasing a feature, that is. You don’t want to punish a user because they chose to install your desktop app. Nothing’s worse than seeing a press release for a really cool feature in an app you use, only to realize that you’ll have to wait a while longer than everyone else. You could employ a feature-flags API to roll out features on both platforms at the same time, but that’s a whole separate topic. I first learned of feature flags from “Continuous Delivery: The Dirty Details⁷³,” a talk by Etsy’s VP of Engineering, Mike Brittain.

Conclusion Link

So, there you have it. With minimal effort, you can add “desktop app developer” to your resumé. We’ve looked at creating your first modern desktop app, packaging, distribution, after-sales service and a lot more. Hopefully, despite the pitfalls and horror stories I’ve shared, you’ll agree that it’s not as scary as it seems. You already have what it takes. All you need to do is look over some API documentation. Thanks to a few new powerful APIs at your disposal, you can get the most value from your skills as a web developer. I hope to see you around (in the NW.js or Electron community) soon.

Further Reading Link

• “Resurrecting Clippy⁷⁴,” Adam Lynch (me)
  
  How I built clippy.desktop with NW.js.
• “Essential Electron⁷⁵,” Jessica Lord
  
  A plain-speak introduction to Electron and its core concepts.
• Electron Documentation⁷⁶
  Want to dig into the details? Get it straight from the source.
• “Electron Community⁷⁷”
  
  A curated list of Electron-related tools, videos and more.
• “Serverless Crash Reporting for Electron Apps⁷⁸,” Adam Lynch (me)
  
  My experience dabbling with serverless architecture, specifically for handling crash reports from Electron apps.
• electron-builder⁷⁹³⁹, Stefan Judis
  
  The complete solution for packaging and building a ready-for-distribution Electron app, with support for automatic updates (and more) out of the box.
• “autoUpdater⁸⁰⁴⁵,” Electron Documentation
  
  See just how simple Electron’s automatic-update API is.

(rb, al, il)

Footnotes Link

1. 1 http://nwjs.io/
2. 2 http://electron.atom.io/
3. 3 https://www.smashingmagazine.com/2016/08/pixel-perfect-specifications-without-the-headaches/
4. 4 https://www.smashingmagazine.com/2016/02/building-first-class-app-leverages-website-case-study/
5. 5 https://www.smashingmagazine.com/2012/06/mobile-considerations-in-user-experience-design-web-or-native/
6. 6 https://www.smashingmagazine.com/2016/08/a-beginners-guide-to-progressive-web-apps/
7. 7 https://teamwork.com/chat
8. 8 https://www.smashingmagazine.com/wp-content/uploads/2017/01/chromiumDiagram-large-opt.png
9. 9 https://www.smashingmagazine.com/wp-content/uploads/2017/01/chromiumDiagram-large-opt.png
10. 10 https://www.smashingmagazine.com/wp-content/uploads/2017/01/nwjsDiagram-large-opt.png
11. 11 https://www.smashingmagazine.com/wp-content/uploads/2017/01/nwjsDiagram-large-opt.png
12. 12 https://www.smashingmagazine.com/wp-content/uploads/2017/01/nwjsHelloWorld-large-opt.png
13. 13 https://www.smashingmagazine.com/wp-content/uploads/2017/01/nwjsHelloWorld-large-opt.png
14. 14 http://engineroom.teamwork.com/resurrecting-clippy/
15. 15 https://www.smashingmagazine.com/wp-content/uploads/2017/01/clippy-large-opt.png
16. 16 https://www.smashingmagazine.com/wp-content/uploads/2017/01/clippy-large-opt.png
17. 17 https://www.smashingmagazine.com/wp-content/uploads/2017/01/moduleCounts-large-opt.png
18. 18 http://modulecounts.com/
19. 19 https://www.smashingmagazine.com/wp-content/uploads/2017/01/moduleCounts-large-opt.png
20. 20 https://github.com/Teamwork/node-auto-launch
21. 21 https://www.teamwork.com/
22. 22 https://www.smashingmagazine.com/wp-content/uploads/2017/01/atom-large-opt.png
23. 23 https://www.smashingmagazine.com/wp-content/uploads/2017/01/atom-large-opt.png
24. 24 https://www.smashingmagazine.com/wp-content/uploads/2017/01/logos-large-opt.png
25. 25 https://www.smashingmagazine.com/wp-content/uploads/2017/01/logos-large-opt.png
26. 26 https://www.smashingmagazine.com/wp-content/uploads/2017/01/electronDiagram-large-opt.png
27. 27 https://www.smashingmagazine.com/wp-content/uploads/2017/01/electronDiagram-large-opt.png
28. 28 https://www.smashingmagazine.com/wp-content/uploads/2017/01/electronHelloWorld-large-opt.png
29. 29 https://www.smashingmagazine.com/wp-content/uploads/2017/01/electronHelloWorld-large-opt.png
30. 30 https://github.com/electron/electron-api-demos
31. 31 https://www.smashingmagazine.com/wp-content/uploads/2017/01/apiDemosApp-large-opt.png
32. 32 https://www.smashingmagazine.com/wp-content/uploads/2017/01/apiDemosApp-large-opt.png
33. 33 http://photonkit.com/
34. 34 https://www.smashingmagazine.com/wp-content/uploads/2017/01/photon-large-opt.png
35. 35 https://www.smashingmagazine.com/wp-content/uploads/2017/01/photon-large-opt.png
36. 36 http://electron.atom.io/devtron/
37. 37 http://blog.chromium.org/2016/08/from-chrome-apps-to-web.html
38. 38 https://github.com/electron-userland/electron-packager
39. 39 https://github.com/electron-userland/electron-builder
40. 40 https://jenkins.io/
41. 41 http://codeship.com/
42. 42 https://travis-ci.org/
43. 43 https://www.appveyor.com/
44. 44 https://github.com/edjafarov/node-webkit-updater
45. 45 http://electron.atom.io/docs/api/auto-updater/
46. 46 https://github.com/Squirrel/Squirrel.Mac
47. 47 https://github.com/Squirrel/Squirrel.Windows
48. 48 https://github.com/ArekSredzki/electron-release-server
49. 49 https://github.com/GitbookIO/nuts
50. 50 https://github.com/ArekSredzki/electron-release-server
51. 51 https://developer.mozilla.org/en-US/docs/Web/API/NavigatorOnLine/onLine
52. 52 https://github.com/sindresorhus/is-online
53. 53 https://www.smashingmagazine.com/wp-content/uploads/2017/01/dropdownComparison-large-opt.png
54. 54 https://www.smashingmagazine.com/wp-content/uploads/2017/01/dropdownComparison-large-opt.png
55. 55 https://www.smashingmagazine.com/wp-content/uploads/2017/01/hiddenTitleBar-large-opt.png
56. 56 https://www.smashingmagazine.com/wp-content/uploads/2017/01/hiddenTitleBar-large-opt.png
57. 57 http://electron.atom.io/docs/api/frameless-window
58. 58 https://github.com/Quramy/electron-connect
59. 59 https://github.com/sindresorhus/awesome-electron
60. 60 http://electron.atom.io/docs/tutorial/application-packaging/
61. 61 https://github.com/Teamwork/gulp-path-length
62. 62 https://sentry.io/welcome/
63. 63 https://docs.sentry.io/clients/javascript/config/#optional-settings
64. 64 http://electron.atom.io/docs/api/crash-reporter/
65. 65 https://www.google.ie/analytics/tag-manager/
66. 66 https://github.com/cyrus-and/chrome-remote-interface
67. 67 http://electron.atom.io/spectron/
68. 68 https://babeljs.io/
69. 69 http://rollupjs.org
70. 70 https://webpack.github.io
71. 71 http://browserify.org
72. 72 https://github.com/hughsk/envify
73. 73 https://www.youtube.com/watch?v=JR-ccCTmMKY
74. 74 http://engineroom.teamwork.com/resurrecting-clippy/
75. 75 http://jlord.us/essential-electron/
76. 76 http://electron.atom.io/docs/
77. 77 http://electron.atom.io/community/
78. 78 http://engineroom.teamwork.com/serverless-crash-reports-for-electron-apps/
79. 79 https://github.com/electron-userland/electron-builder
80. 80 http://electron.atom.io/docs/api/auto-updater/

↑ Back to topTweet itShare on Facebook

In 2017, the question is not whether we should use a responsive design framework. Increasingly, we are using them. The question is which framework should we be using, and why, and whether we should use the whole framework or just parts of it.

With dozens of responsive design frameworks available to download, many web developers appear to be unaware of any except for Bootstrap. Like most of web development, responsive design frameworks are not one-size-fits-all. Let’s compare the latest versions of Bootstrap, Foundation and UIkit for their similarities and differences.

Further Reading on SmashingMag: Link

• Creating A Complete Web App In Foundation For Apps¹
• Diverse Test-Automation Frameworks For React Native Apps²
• Hybrid Mobile Apps: Providing A Native Experience With Web Technologies³
• The Basics Of Test Automation For Apps, Games And The Mobile Web⁴

Three years ago, I wrote an article for Smashing Magazine, “Responsive Design Frameworks: Just Because You Can, Should You?⁵” In the article, I argued that responsive design frameworks should be used by professionals under the right circumstances and for appropriate projects. Custom design still has its place, of course. However, a fully customized approach is not appropriate to every website, under every timeline, every budget and every set of browser support guidelines.

Since that time, the industry has evolved at its typical breakneck pace. Sass, the CSS preprocessor, has become standard to most workflows. We’re more accustomed to adjusting Sass variables to customize existing code. We confidently work with mixins, building our own styles. We’ve even got Sass formulas for generating color schemes⁶ that we can incorporate in our work.

Workflows themselves have become standard, making use of technologies such as Node.js, Bower, Grunt, Gulp, Git and more. Old browsers continue to fall away, allowing front-end developers to confidently use more features of HTML5 and CSS3, with fewer worries about significant cross-browser compatibility issues.

Revisiting the 131 comments on my 2014 article, I saw readers suggesting a number of approaches to making use of responsive design frameworks:

• Some suggested using part of a framework with your own custom code.
• Several developers plugged their own framework, either written from scratch or with code forked from another framework.
• Several developers suggested frameworks that I did not cover, including Susy, Singularity, Breakpoint, UIkit, Pattern Lab, Toolkit, Pure, Cardinal, Skeleton, ResponsiveBP and many others.

All of these are legitimate approaches. Hundreds of frameworks are available. Many who have been in the business for some time have a favorite, whether it’s an established framework or one they’ve created.

However, increasingly, I see students, clients and web development firms defaulting to Bootstrap as their starting point, often with little critical evaluation of whether it’s an appropriate solution to the task at hand. Clients hire me for training in Bootstrap, for example, and then ask how they can add functionality that’s native to Foundation. When I ask, “Why not use Foundation?,” they tell me they’ve never heard of it and didn’t know there are options beyond Bootstrap for responsive design.

There is no way I could review the dozens, if not hundreds, of responsive design frameworks. However, given that Bootstrap is the 500-pound gorilla of responsive design, I’ve chosen two other frameworks to evaluate compared to Bootstrap⁷: Foundation⁸ and GetUIkit⁹. I’ve chosen these three frameworks based on the characteristics they share, in that they are full-service responsive design frameworks. They offer grid systems, SCSS with piles of variables and mixins for customizations, basic styling of nearly all HTML5 tags, prestyled components such as badges, labels and cards, and piles of JavaScript-based features such as dropdown menus, accordions, tabs, image galleries, image carousels and so much more. All three frameworks offer ways of reducing file sizes to just those styles and functionalities needed to work on a given website. They are all in active development.

Again, I am not suggesting that these are the only responsive design frameworks, nor am I implying that they are the best frameworks. These are, however, popular frameworks with piles of features out of the box, making them attractive to many development firms wanting to work with “Bootstrap or a close equivalent.”

Background Information Link

To start the discussion, let’s examine some of the basic background features of each framework.

	Bootstrap 4	Foundation for Sites 6	UIkit 3
Current version, release date	4.0.0-alpha 6, released January 2017	6.3.0, released January 2017	3.00 beta 9, released February 2017
Owned by	Originally developed at Twitter by Mark Otto and Jacob Thornton, now an open-source project	ZURB, a web development company in Campbell, California	YOOtheme, a WordPress and Joomla theme development company in Hamburg, Germany
Website	Bootstrap10	Foundation11
Standard distribution package includes	Required CSS (1 minified, 1 standard, both with .map files); required JavaScript (1 minified, 1 standard). Former theme is incorporated in Sass files, activated by variables. (Glyphicons are not distributed with Bootstrap 4.) Also contains two additional sets of CSS files (1 minified, 1 standard, both with .map files): bootstrap-grid, which appears to be a flexbox-based grid system, possibly redundant at this point; and bootstrap-reboot, based on normalize.css. A CDN is available for standard distribution files.	Four distributions12: Complete, Essential, Custom, Sass. Complete version includes compiled CSS (minified and not), plus compiled JavaScript, including individual vendor files. Essential includes typography, grid, Reveal, and Interchange only. Custom can be customized on the website for downloading, and the developer can choose elements to include and change a few variables. The Sass version can only be downloaded using the command line, Foundation CLI or Yeti Launcher. A CDN is available for standard distribution files.	Distribution includes a single minified CSS file, a single minified JavaScript file and 26 SVG graphics. LESS, CSS, and JavaScript source files are available via Bower or npm. A CDN is available for standard distribution files.
Additional JavaScript libraries required?	Yes, you must download or link to a CDN separately: jQuery 3.1.1 Slim, Tether 1.4.0. Files are linked to just before end of body element.	All dependencies are bundled in the distribution. jQuery is required, but it is part of the distribution. Files are linked to just before end of body element.	All dependencies are bundled in the distribution. jQuery is required, but it is part of the distribution. Linking to files in the head is recommended.
Browser support	Latest versions of: Chrome (macOS, Windows, iOS and Android), Safari (macOS and iOS), Firefox (macOS, Windows, Android, iOS) (latest version of Firefox plus Extended Support Release), Edge (Windows, Windows 10 Mobile), Opera (macOS, Windows), Android Browser & WebView 5.0+, Windows 10 Mobile, Internet Explorer 10+	Last two versions of Chrome, Firefox, Safari, Opera, mobile Safari, Internet Explorer mobile, as well as Internet Explorer 9+ and Android browser 2.3+	Latest versions of Chrome, Firefox, Opera, Edge, Safari 7.1+, Internet Explorer 10+, No mention of mobile-specific browsers
Internet Explorer support	Internet Explorer 10 and higher (Bootstrap 3 recommended for Internet Explorer 8 and 9)	Internet Explorer 9 and higher	Internet Explorer 10 and higher
Other browser support notes	“Unofficially, Bootstrap should look and behave well enough in Chromium and Chrome for Linux, Firefox for Linux, and Internet Explorer 9, though they are not officially supported.” (source13)	“JavaScript: Our plugins use a number of handy ECMAScript 5 features that aren’t supported in IE8.” (source14)
License and copyright	Code and documentation copyright (2011 to 2017) of the Bootstrap authors and Twitter, Inc. Code released under the MIT License. Docs released under Creative Commons.	MIT license, no mention of copyright	MIT license, copyright of YOOtheme GmbH
Build tools	“Bootstrap uses Grunt for its CSS and JavaScript build system and Jekyll for the written documentation. Our Gruntfile includes convenient methods for working with the framework, including compiling code, running tests, and more.” (source15)	To access Sass files16, you must install using the command line, the Node.js-powered Foundation CLI, or with its Yeti Launch application (Mac only). “Foundation is available on npm, Bower, Meteor, and Composer. The package includes all of the source SCSS and JavaScript files, as well as compiled CSS and JavaScript, in uncompressed and compressed flavors.” Other versions of Foundation are available as simple downloads without using these tools, but without SCSS files.	Bower and npm. Offer a SublimeText plugin and an Atom plugin for working with UIkit 3 as well.

In general, all three frameworks are in active development (all were updated in January or February 2017) and are mobile-first. All generally have some type of CSS preprocessor. UIkit version 3 beta currently only offers LESS. It will offer a SCSS port, as it’s offered in previous versions of UIkit, in future releases.

@jen4web²³¹⁷ Yes, we will have a SASS port too. (like we have in UIkit 2)

— UIkit (@getuikit) February 9, 2017¹⁸

Bootstrap transitioned from LESS to SCSS as part of its version 4 update. Foundation has always been written in SCSS, because ZURB is a Ruby on Rails shop, and Sass hails from the Ruby on Rails world.

There are notable differences with the build tools. Foundation is extremely picky about you using its workflow when working with the framework, if you wish to work with SCSS files. Unfortunately, Foundation offers few choices in tools. Bootstrap is much less picky about workflow, offering several options, including no workflow at all, even with its SCSS files. All frameworks offer at least one distribution ZIP file, containing all elements of the framework. Foundation offers a way to choose only certain elements in a download. Bootstrap 4 alpha and UIkit 3 beta do not offer this functionality currently, but they have previously offered this in older Bootstrap and UIkit versions. We can assume that once these frameworks reach their stable releases, this functionality will be offered as well.

Grid System Link

Each framework comes with a grid system, as one might expect. Bootstrap and Foundation’s grid systems include multiple breakpoints, nested grids, offsets and source ordering (i.e. changing the order of content on collapse). Exact breakpoint values vary, but the breakpoints are generally customizable with SCSS. UIkit’s grid is radically different and is described below.

With the most recent alpha 6 release, Bootstrap features a flexbox-based grid system by default. (This is partly the reason for its Internet Explorer 10+ browser support.) By default, Foundation features a floated grid system (which helps, in part, with its Internet Explorer 9+ support). Optionally in Foundation, you can compile a flexbox-based grid system by toggling an appropriate Sass variable and recompiling to CSS. Foundation notes that flexbox is not supported in Internet Explorer 9, so keep this in mind if this is a target browser for you.

Foundation offers a few more grid features than Bootstrap, including centered columns, incomplete rows, responsive gutters, semantic grid options and fluid rows.

Equal-height columns are a common problem when working with float-based grid systems. Foundation includes a JavaScript component named Equalizer. Because UIkit and Bootstrap are based on flexbox and not floats, equal-height columns are built into the grid system and are never an issue.

UIkit has a very different grid than Foundation and Bootstrap. Rather than a standard 12-column system, UIkit has broken its layouts into three components: grid, flex and width. Starting with the grid component¹⁹, you can create as many columns as you wish:

To create the grid container, add the uk-grid attribute to a <div> element. There’s no need to add a class. Add child <div> elements to create the cells. By default, all grid cells are stacked. To place them side by side, add one of the classes from the Width component. Using uk-child-width-expand will automatically apply equal width to items, regardless of how many there are.

As implied in the documentation, grid sets up the boxes that might be next to each other in some layouts, while width determines the width of those boxes, and flex determines the layout within each box, using flexbox properties. Finally, unlike other grid systems, UIkit offers a border between grid columns.

²⁰

CSS And Default Styling Link

All three frameworks come with some level of CSS styling. The styling can be changed through an overriding style sheet or by modifying the provided SCSS or LESS preprocessor files. Generally speaking, basic styling is provided for all, or nearly all, HTML5 elements. All frameworks provide some quantity of utility classes, generally used for printing, responsiveness and the visibility of elements. Foundation and UIkit offer right-to-left support for languages written in that direction. UIkit states that it will feature a RTL version and the option to compile UIkit with a custom prefix.

@jen4web²³¹⁷ Also a RTL version and the option to compile UIkit with a custom prefix (like ba- instead of uk-)

— UIkit (@getuikit) February 9, 2017²⁴

It is unclear from its documentation whether Bootstrap 4 is offering RTL support, but it has been available in previous versions. It seems like this might be part of a future stable release²⁵. There is much interest in including this feature in the Bootstrap community.

The framework with the least out-of-the-box styling is Foundation. This framework has long assumed that its users are more advanced developers who will want to write their own styling for their projects. Therefore, ZURB has always provided less styling out of the box by design, meaning there will be fewer styles to override later.

UIkit offers two color options, accessible via the Inverse component. They include the standard scheme (light backgrounds and dark text) and a contrast scheme (dark backgrounds and light text). UIkit also offers some unique styled components, such as Articles and Comments, as well as Placeholder, which provides an empty space for drag-and-drop file-uploading interfaces. If you recall YOOtheme’s WordPress and Joomla theming roots, these features make perfect sense. Neither Bootstrap nor Foundation includes this styling specific to content management systems, so this is a distinguishing characteristic of the framework.

²⁶

Bootstrap offers much more than Foundation. Indeed, Bootstrap’s distinctive look has permeated websites for several years. Bootstrap 4 has a similar look to Bootstrap 3. Bootstrap still offers several colors, such as “warning,” “danger,” “primary,” “info” and “success,” and it typically offers a few variations on styling certain HTML elements, such as tables and forms.

It’s also worth comparing the CSS units in each framework. Bootstrap 4 uses rem as its primary CSS unit throughout. However, it states, “pixels are still used for media queries and grid behavior as viewports are not affected by type size.” Bootstrap also increased its base font size from 14 pixels in version 3 to 16 pixels in version 4.

Foundation says²⁹, “We use the rem unit nearly everywhere in Foundation, and even wrote a Sass function to make it a little easier. The rem-calc() function can take one or more pixel values and convert them to proper rem values.”

Finally, UIkit seems to use pixels as a primary size unit, although occasionally uses percentages and rems in a few places in its LESS files. Its CSS size philosophy is not addressed in its documentation.

Navigation And Navigation Elements Link

All three frameworks ship with responsive navigation elements. All include some fairly common navigation components, like formatted breadcrumbs, tabs, accordions and pagination. There are minor variations between these, but they all typically work as expected.

All three frameworks ship with dropdown menus. In general, these dropdowns may be used in several scenarios: with standard responsive navbars, with tabs, with buttons, etc. All three include vertical dropdowns. Foundation and UIkit also include horizontal dropdowns, in which the dropdown is displayed as a row rather than a column.

Navigation bars are present in all three frameworks. Each navbar can accommodate website branding and search and can be made sticky, and elements can be aligned left or right in the bar. All navigation bars collapse, but they may present collapsed content differently (some via a hamburger button plus a dropdown, some via an off-canvas menu). The navigation bars also have a few differences among themselves.

³⁰

Bootstrap offers some basic horizontal and vertical navigation bars with different styling options (tabs, pills, stacked pills, justified or plain styling). It offers a separate horizontal responsive navigation bar, which creates a hamburger button on collapse. Two color schemes are available, with colors and breakpoints customizable through SCSS.

Foundation had a responsive navigation bar in previous versions similar to Bootstrap’s. In version 6, it has turned several navigation bar treatments into individual elements that can be combined. For example, on collapse, the navigation may be hidden behind a hamburger button, behind an off-canvas treatment or behind a drilldown menu, in which the user loads screens of menu items. These types of navigation treatment may be changed at specific screen sizes. For example, the full navigation bar may be available at desktop dimensions but switch to a drilldown for mobile.

UIkit’s bar offers functionality similar to Bootstrap’s. By default, it does not have a built-in toggle, but this is easily added with the appropriate CSS classes and JavaScript. Collapsed content is typically behind a hamburger button, and it may be coupled with off-canvas functionality. UIkit also specifically offers an icon-based navigation bar (iconbar). It ships with 26 SVG icons, which can be integrated in this bar, with the promise of more icons in the future.

JavaScript Components Link

All three frameworks depend on jQuery for their JavaScript-based components. Foundation and UIkit ship with a copy of jQuery, while Bootstrap relies on connecting to jQuery via a CDN or a download.

All three frameworks contain similar types of functionality: tooltips, modal windows, accordions, tabs, dropdown menus, image carousels, etc.

Foundation has two handy components that set it apart. One is Abide, a full-featured HTML5 form-validation library. It can handle client-side error-checking of forms. The other is Interchange, a JavaScript-based responsive image loader. It’s compatible with images and with bits of HTML and text. It loads the appropriate content on the page based on media queries. Despite the fact that one of the defining characteristics of responsive design is images that resize, neither Bootstrap nor UIkit offers similar functionality.

UIkit combines its styles and JavaScript components in its documentation, calling it all “components.” Some of the unique JavaScript-based components currently available in its beta release include Scroll, which allows smooth scrolling to other parts of the web page, and Sortable, which enables drag-and-drop grids on the page.

In future versions of UIkit³³, we are promised many components from UIkit 2, including “Slideshow, Slider, Slideset, Parallax, Nestable, Lightbox, Dynamic Grid, HTML editor, Date- and Timepicker components.” It’s worth highlighting HTML Editor, and the Date- and Timepicker components, because these are typically used in administrative interfaces and in applications. Remember that YOOtheme creates Joomla and WordPress themes as part of its business, so these are important components for it. Neither Foundation nor Bootstrap includes these admin-friendly widgets, so this is a distinguishing characteristic of this framework.

One of UIkit’s most distinguishing JavaScript features³⁴, however, is this:

UIkit is listening for DOM manipulations and will automatically initialize, connect and disconnect components as they are inserted or removed from the DOM. That way it can easily be used with JavaScript frameworks like Vue.js and React.

So, Which Is Best? Link

It depends! All three projects are actively maintained and have devoted followers. In the end, the right framework for you will depend on your project’s requirements, where you need help in programming (making it pretty? coding functionality?) and your personal coding philosophy (rems versus pixels? LESS versus Sass?). As with all technology, there is no perfect choice, and you will have to make compromises on features, functionality and code styles.

With this in mind, here are some points to weigh in making your decision.

• Browser support
  
  The framework versions reviewed here support similar browsers. However, going back one framework version, or following the instructions for incorporating polyfills, might increase support for important browsers. In particular, if you need Internet Explorer 8 support, you might want to look at Bootstrap 3.
• CSS unit differences
  
  Foundation keeps nearly all of its units in ems and rems. Bootstrap uses mostly ems and rems, with pixels for media queries. UIkit uses mostly pixel measurements. Some developers have strong opinions about these approaches and might choose a framework based on them.
• Quantity of styling
  
  UIkit has a lot of out-of-the box styling. Foundation has much less. Bootstrap is somewhere in between. How much styling do you need to override? How much styling do you want to be present already? Do you want to write very little or none?
• CSS preprocessors
  
  Foundation was written in SCSS natively. Bootstrap had a port from LESS to SCSS in version 3, then rewrote its SCSS in version 4. UIkit continues to work in LESS while in beta, but it will offer a SCSS port in future releases. This could also affect your choice of framework.
• Workflow
  
  If you wish to modify SCSS files, know that Foundation will lock you into a fairly rigid workflow. Bootstrap and UIkit offer a workflow, but you can choose a different workflow or no workflow at all.
• JavaScript components
  
  Foundation offers form validation and responsive content management. UIkit is specifically built to work with reactive JavaScript frameworks, and it includes components for building an admin interface. Depending on the components you require, this could sway your decision.
• Grid differences
  
  Bootstrap and Foundation offer 12-column grids. UIkit offers a very different approach to grid layout, with very different styling. Foundation’s grid can easily be modified to greater or fewer columns with SCSS, and it can be made semantic as well. Grids for UIkit and Bootstrap are flexbox-based by default, while Foundation’s are float-based, but convertible to flexbox through SCSS.

(da, al, il)

Footnotes Link

1. 1 https://www.smashingmagazine.com/2015/04/creating-web-app-in-foundation-for-apps/
2. 2 https://www.smashingmagazine.com/2016/08/test-automation-frameworks-for-react-native-apps/
3. 3 https://www.smashingmagazine.com/2014/10/providing-a-native-experience-with-web-technologies/
4. 4 https://www.smashingmagazine.com/2015/01/basic-test-automation-for-apps-games-and-mobile-web/
5. 5 https://www.smashingmagazine.com/2014/02/responsive-design-frameworks-just-because-you-can-should-you/
6. 6 http://tallys.github.io/color-theory/
7. 7 http://getbootstrap.com/
8. 8 http://foundation.zurb.com/
9. 9 https://getuikit.com/
10. 10 http://v4-alpha.getbootstrap.com/
11. 11 http://foundation.zurb.com/sites/docs/
12. 12 http://getuikit.com/
13. 13 http://v4-alpha.getbootstrap.com/getting-started/browsers-devices/
14. 14 http://foundation.zurb.com/sites/docs/compatibility.html
15. 15 https://v4-alpha.getbootstrap.com/getting-started/build-tools/
16. 16 http://foundation.zurb.com/sites/docs/installation.html
17. 17 https://twitter.com/jen4web
18. 18 https://twitter.com/getuikit/status/829680161968775168
19. 19 https://getuikit.com/docs/grid#usage
20. 20 https://www.smashingmagazine.com/wp-content/uploads/2017/02/foundation-grid-opt.png
21. 21 http://foundation.zurb.com/sites/docs/equalizer.html
22. 22 https://www.smashingmagazine.com/wp-content/uploads/2017/02/foundation-grid-opt.png
23. 23 https://twitter.com/jen4web
24. 24 https://twitter.com/getuikit/status/829680541179985920
25. 25 https://github.com/twbs/bootstrap/issues/19555
26. 26 https://www.smashingmagazine.com/wp-content/uploads/2017/02/uikit-comment-opt.png
27. 27 https://getuikit.com/docs/comment#lists
28. 28 https://www.smashingmagazine.com/wp-content/uploads/2017/02/uikit-comment-opt.png
29. 29 http://foundation.zurb.com/sites/docs/typography-base.html
30. 30 https://www.smashingmagazine.com/wp-content/uploads/2017/02/bootstrap-nav-opt.png
31. 31 http://v4-alpha.getbootstrap.com/components/navbar/
32. 32 https://www.smashingmagazine.com/wp-content/uploads/2017/02/bootstrap-nav-opt.png
33. 33 https://yootheme.com/blog/2017/01/09/uikit-3-beta-released
34. 34 https://getuikit.com/docs/javascript#uikit-and-reactive-javascript-frameworks

↑ Back to topTweet itShare on Facebook

We’re all designers. Whether we do a layout, a product design or write code to design a product technically doesn’t matter here. What does matter though, is that we always take the context of a project into consideration. Because as someone shaping a project so that it is appealing to the clients and works in the best way possible for the target audience, we have a pretty big responsibility.

Imagine architects building a wall out of recycled material that also looks nice — sounds pretty great, right? But seen in the context that this will be a wall that divides people and encourages racism and even more inequality in our society, our first impression of the undertaking suddenly shifts into the opposite direction. We have to make new decisions every time we start a new project, and seeing things in context is crucial to live up to our responsibility — both in our work and our lives.

Further Reading on SmashingMag: Link

• Getting The Sketch Workflow Right: Meet “The Sketch Handbook”¹
• A Glimpse Into The Future With React Native For Web²
• Front-End Performance Checklist 2017 (PDF, Apple Pages)³

News Link

• We waited for this update 2.5 years, now Microsoft is finally working on object-fit and object-position for Microsoft Edge⁴. A great step towards better web compatibility and I really hope that it’ll land in an official build soon.
• With Sketch 43, the app developers announced that the Sketch file format will be open-source⁵ from now on. This is great news because it means that everyone will be able to build a Windows app or a Sketch file viewer app. Since the format of choice will be JSON, we can even think of building automation for files via web services.

⁶

General Link

• Ethan Marcotte wrote a thought-provoking article about “the bricks we lay⁹”. In it, he describes a situation where people do work claiming they’re only focusing on the task they do and therefore are apolitical. But your work is never neutral.
• In the last edition of the web development reading list, I shared the first part¹⁰ of Bruce Lawson’s story about the “World Wide Web, Not Wealthy Western Web”. Today comes the second part¹¹ of the mandatory read of this week.

Tools & Workflows Link

• Remy Luisant came up with a tool that optimizes your CSS output just a little bit better than you’re used to: CSS Remynification¹².
• Bit¹³ is an interesting concept of a distributed virtual component repository that combines a lot of existing strategies into one universal component manager.

Security Link

• Maybe it’s still not a good idea to use a messenger that’s build to gather as much data as it can, as a recent data leak of Google’s Allo messenger shows¹⁴.
• Scott Arciszewski explains why JOSE (Javascript Object Signing and Encryption) is a bad standard that everyone should avoid¹⁵. Note that JOSE is part of JSON Web Tokens to which not all of the complaints and issues apply.
• Researchers just broke MAC address randomization¹⁶ and tracked 100% of the test devices, including Android and Apple devices.

Web Performance Link

• Nick Sullivan from Cloudflare explains how they enabled Zero Round Trip Time Resumption for all free users¹⁷, now serving TLS 1.3 for better performance.
• This week, Google announced their project Guetzli¹⁸, a new open source JPEG encoder that can save up to 35% of file size. This is great, but to put things into perspective, we also have to consider that it’s up to 100 times slower¹⁹ as Mozilla’s mozJPEG encoder and in many cases it doesn’t achieve the same quality at the same file size either.
• Jacob Beltran shares lessons learned from optimizing performance in React applications²⁰.

²¹

JavaScript Link

• Firefox 52 hit the release channel last week, and it includes a few changes to setTimeout() and setInterval()²⁴. Please read this update post and check if your code still works as expected.

And with that, I’ll close for this week. If you like what I write each week, please support me with a donation²⁵ or share this resource with other people. You can learn more about the costs of the project here²⁶. It’s available via email, RSS and online.

— Anselm

Footnotes Link

1. 1 https://www.smashingmagazine.com/sketch-handbook/
2. 2 https://www.smashingmagazine.com/2016/08/a-glimpse-into-the-future-with-react-native-for-web/
3. 3 https://www.smashingmagazine.com/2016/12/front-end-performance-checklist-2017-pdf-pages/
4. 4 https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6263790-object-fit-and-object-position
5. 5 https://medium.com/sketch-app-sources/sketch-43-is-coming-to-town-with-a-new-game-an-open-file-format-ae62e7e7c223
6. 6 https://medium.com/sketch-app-sources/sketch-43-is-coming-to-town-with-a-new-game-an-open-file-format-ae62e7e7c223#.y94mlusbd
7. 7 https://medium.com/sketch-app-sources/sketch-43-is-coming-to-town-with-a-new-game-an-open-file-format-ae62e7e7c223
8. 8 https://medium.com/sketch-app-sources/sketch-43-is-coming-to-town-with-a-new-game-an-open-file-format-ae62e7e7c223#.y94mlusbd
9. 9 https://ethanmarcotte.com/wrote/the-bricks-we-lay/
10. 10 https://www.smashingmagazine.com/2017/03/world-wide-web-not-wealthy-western-web-part-1/
11. 11 https://www.smashingmagazine.com/2017/03/world-wide-web-not-wealthy-western-web-part-2/
12. 12 https://luisant.ca/remynifier
13. 13 https://github.com/teambit/bit
14. 14 http://www.recode.net/2017/3/13/14912394/google-allo-search-history-privacy-messaging-app
15. 15 https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid
16. 16 https://www.bleepingcomputer.com/news/security/researchers-break-mac-address-randomization-and-track-100-percent-of-test-devices/
17. 17 https://blog.cloudflare.com/introducing-0-rtt/
18. 18 https://research.googleblog.com/2017/03/announcing-guetzli-new-open-source-jpeg.html
19. 19 https://mobile.twitter.com/kornelski/status/842513840898228224
20. 20 https://blog.vixlet.com/react-at-light-speed-78cd172a6411
21. 21 https://blog.cloudflare.com/introducing-0-rtt/
22. 22 https://blog.cloudflare.com/introducing-0-rtt/
23. 23 https://blog.cloudflare.com/introducing-0-rtt/
24. 24 https://blog.wanderview.com/blog/2017/03/13/firefox-52-settimeout-changes/
25. 25 https://wdrl.info/donate
26. 26 https://wdrl.info/costs/

↑ Back to topTweet itShare on Facebook

Sometimes we tend to think of our designs as if they are pieces of art. But if we think of them this way, it means they won’t be ready to face the uncertain conditions of the “real world.” However, there is also beauty in designing an interface that is ready for changes — and, let’s admit it, interfaces do change, all the time.

Further Reading on SmashingMag: Link

• Conversational Interfaces: Where Are We Today? Where Are We Heading?¹
• Content Prototyping In Responsive Web Design²
• Getting Started With VR Interface Design³
• How To think Like An App Designer⁴

One of the things I like most about designing a mobile app is that, from the initial concepts to the time when you are fine-tuning and polishing all of the interface details, this is a process with many steps. In this process, I, together with several other members of the team (from researchers to illustrators to developers), am involved as a designer. But this also means that a lot of decisions have to be made in each and every stage — and some of them don’t always seem to be as fun to make as others.

As UX specialists, we have varied and diverse backgrounds, but visual interfaces are what we spend most of our time on (and are what is most often attributed to us). We are visual thinkers with a highly trained eye. That’s why it’s tempting sometimes to jump straight to the visual UI design stage when starting a new project, and one of the reasons why we may be bored by some other tasks.

This also means that we often postpone (or, worse yet, neglect) other important parts of our process and workflow: defining user needs and goals, sketching task flows, working on all the details of the information and interaction design, etc. These are critically important, too, and at the same time, they are more abstract and more difficult for many people to visualize how they will become a tangible part of the final product.

⁵

When we’re working on a visual design, the so-called pixel-perfect philosophy could be a trap that makes us spend more time than necessary crafting the little details until even the smallest of them is in the “perfect” place in the interface. This leads to a generation of designers who use Dribbble and Behance⁹ mainly to show polished screens of apps and websites and who are more concerned with looks than with how a design actually works. And in the real world, things tend not to go as well as we expect.

Or, as Paul Adams¹⁰ puts it:

I see designer after designer focus on the fourth layer without really considering the others. Working from the bottom up rather than the top down. The grid, font, colour, and aesthetic style are irrelevant if the other three layers haven’t been resolved first. Many designers say they do this, but don’t walk the walk, because sometimes it’s just more fun to draw nice pictures and bury oneself in pixels than deal with complicated business decisions and people with different opinions. That’s fine, stay in the fourth layer, but that’s art not design. You’re a digital artist, not a designer.

Personally, I think the best designs (when speaking about user interface design) are the ones that not only look and feel good, but also respond elegantly to variable conditions and even unpredictable situations.

In the long road of building a product, there are phases when designers need to be more collaborative and less focused on the visual design. And this is precisely where I’m going to focus on for the sake of this article’s length (I don’t want you to fall asleep at the keyboard!). In the next few paragraphs, I’ll give you some hints and tips on how to put that app design you are working on to the test, and to see whether it’s ready to be released into the wild.

Finding Beauty In Imperfection Link

When I was studying graphic design in college, they taught us about the beauty of balance, alignment, proportion and tension and how to position elements in space in such a way that they are harmonious and pleasing to the eye. With this knowledge, my life changed and I started to look at the world with different eyes. Later on, I started designing interfaces and I tried to put those same principles into action — all of the information on the screen should form a visual composition that’s highly satisfying to look at.

If you apply these principles to mobile app design, then we’d find that we must display just the right amount of information. For example, if a screen has to list people’s names, the designer would usually select a few short and common ones and arrange them together perfectly — leaving no room for an unexpectedly long name that could break the design or make it fall apart later.

This approach is based on the assumption that there is no beauty in chaos and imperfection — even though these two aspects appear frequently in the real world. But visual interfaces are not static pieces of art to be admired; they are dynamic, functional spaces that change and adapt for each person using them. We should not succumb to the temptation to design purely for aesthetics, because we can never control everything an interface must present to (and also do for) people.

Instead, we must design for change! This is what the Japanese call wabi-sabi¹¹, a “worldview centered on the acceptance of transience and imperfection.”

Because of this, it’s important to think and design differently:

• try to present data in your design in many ways;
• whenever possible, use real data.

When you try to present data in a few ways, including some unpredictable ones, you will be able to test whether the interface is ready to handle these situations that are beyond the design’s “comfort zone.” Also, be prepared for extreme cases (when none or a lot of information is present, for example), and try to avoid the “centers” (when everything looks good and balanced).

If you have already launched the product, this will be easier because you can pay attention to the real data¹² and use it in your ongoing design process as a reference. But if you are working on something new, then you will have to dig a bit deeper, do some research and try to understand how (and what kind of) information will be presented later on. You can also talk about this with a developer from your back-end team, who will be able to better explain to you what kinds of data will be stored and presented.

¹³

I’ll give you one last, more graphic example with something that a developer friend¹⁶ of mine calls “the pretty friend syndrome.” When we are designing a screen that will contain pictures of people, like user profiles, we tend to use nearly-stock photos of people who look good and fit well within the design. Yet when he sees such designs, my friend says, “I wish I had friends so handsome.”

So, an alternative to “perfect” imagery could be to use more random photos¹⁷ of people with varying colors. That way, you will be able to test how overlaid elements look with different kinds of backgrounds, allowing you to see whether contrast and legibility are still intact.

¹⁸

Don’t Be Too Optimistic Link

We are optimists by nature on how an app is going to work. We suppose that everything will go quickly and smoothly and without interruption because… why not? That’s why we sometimes forget how to design and handle some of the potentially not-so-good situations that the user might face later on.

Just to name a few, what would happen if suddenly the Internet connection drops? Or what if there’s an error while the browser is trying to connect to the API when executing a task? And if the connection is too slow, will there be a loading indicator (such as a spinner or progress bar), or will there be some placeholders to (temporarily) fill the display blocks while the actual data is being loaded? And what about the possibility of refreshing certain screens of the app? When (and in which cases) would this be possible?

²⁰

As you can see, I’m not talking about errors made by the user (for example, making a mistake when filling a form), but about errors that are out of their control but that happen nevertheless. In this case, it’s even more important to talk to developers to know and understand what could go wrong on different screens, and then to devise an approach that could get the user out of trouble easily, giving them the option to try again later or to perform a different action.

In any case, it’s always a good idea to identify the specific conditions that trigger each error and to design a helpful error message for each individual case. These helpful messages will help the user to respond appropriately in each case and to know what to do next to fix the problem. Even if it’s somewhat tempting, avoid a generic error message at all costs.

Understand The Flows Link

An interface comprises many elements that together form the whole layout of the application. However, when we focus on the user interface as a whole, we often forget that some elements also have smaller tasks to perform that contribute to the general goal.

Speaking of goals, this is like football (or soccer, if you happen to live in the US). You see, I’m a big fan of this sport, like most people in Argentina, where I’m from. In order for the team as a whole to win, the coach needs to know what to expect from each player and what task they will perform at different moments — even when the unpredictability of some of them (I’m thinking about the magic of Messi²³) can make this harder.

²⁴

Moving forward and (hopefully) forgetting about my sports analogies, let’s translate this to our design cases. If there is a button or item that triggers some kind of interaction, then look ahead and think about the next step: Will a loading state be displayed while the action is being performed? Could it be disabled for some reason? What if the user is holding down the button for a while; will there be any feedback? Just as there are different states for whole screens²⁶, the same should apply to individual elements as well.

In addition, remember to consider how the logic of the product matches the user’s mental model, helping them to accurately and efficiently achieve their goal and to complete their tasks in a meaningful and predictable way.

What I do to address all of these points is to just stop what I’m doing, pause, step back and look at the bigger picture of the entire flow of multiple screens and states over a sequence of steps and actions. I’ll look for the multiple paths that lead to that point, and the multiple paths that lead away from it.

You can do the same while using a prototype, performing the actions slowly, conscientiously and carefully. If this is too challenging for you — because you have probably done this several times before and it’s become kind of an automated task now — borrow some fresh eyes (not literally, of course!) and simply ask a colleague, friend or active user to look at the design or prototype. Seeing someone else use and interact with your design can be illuminating, because we are often too close to and too familiar with it and, so, can overlook things.

Designing For Your Screen Link

When I’m designing, I usually have my phone next to me, so that I can preview my work and make adjustments in real time. To do this, I use Mira²⁷, Crystal²⁸ or Sketch Mirror²⁹, depending on whether I’m designing for Android or iOS.

I think this is a good practice, but this way it’s also easy to forget about all of the other phones different from yours that people may be using. A lot of different screen sizes are out there (especially on the Android platform); try to consider all possible variations.

One way of knowing where to start is to check what kinds of devices your actual users have.

And when preparing your design for those various screen sizes and orientations, it’s not just about stretching boxes and repositioning elements. Carefully consider how to make the most of each situation and, furthermore, how to make the necessary adjustments even when it means deviating a bit from the original design.

³⁰

In these cases, the same principles that we’ve discussed before still apply: unpredictable situations, different kinds of content, variable amounts of information, missing data and so on — you have to design for all kinds of possible scenarios. Don’t fall into the trap of designing screens as separate, individual parts of the product — they are all connected.

This will be helpful not only to you, but also to your developer friend, who will need to know many of the possible scenarios in order to write the code and prepare the interface to tackle these situations.

What You Need Today, You May Need Tomorrow Link

You may have noticed that the goal of many of the points in this article is to reduce the unexpected. Even so, there will be many situations in which you won’t have a clear answer. Developers will often ask, “So, what would happen if I do this instead of that?” — pointing to a potential outcome that you hadn’t considered before.

If this happens, then you will have to solve that particular issue for only one case and only one screen. But always try to think globally, and consider how the answer to that particular problem could be designed to work in a flexible way so that you could potentially reuse it later on.

After all, this is what we, UX designers, do — we design and define flexible systems that adapt to unanticipated states, conditions and flows. Think of your interface as a living ecosystem of moving, changing smart parts, instead of a collection of individual blocks of pixels.

³²

During this part of the process, you’ll need to work very closely with developers on your team, mostly to define a set of rules of behaviors for many different situations. But keep a good balance — try not to over-design things. Set your own limits with a dash of common sense. You need to strike a good balance between functionality and consistency. Remember that a good design system is flexible and is prepared for some exceptions to the rules on certain occasions.

On the other hand, think of how elements you have already designed could be tweaked to fit new situations. You will see this better if you make a library of design components, so that, with just a quick overview of the library, you will know whether you need to design something from scratch or you can use something readymade.

Final Tips And Tricks Link

If you want to prepare your designs to face the unpredictable and the unknown — and if you want to also, hopefully, get along better with your lead developer by providing them with everything they will need beforehand — here are some final tips.

Work More Closely With the Developer Link

One of my best experiences with a developer so far (hi, Pier³⁵!) came about simply from sitting right next to him. This is very important, and it will make a huge difference because it will improve communication. Talk often in order to better understand the product and how it works and what they will need to learn from you. Ask, and ask over and over again, in order to see the bigger picture of all possible outcomes.

Get Involved in Your Own Design Link

Get involved in your own design in a conscious, critical way, paying attention to details and small interactions. Get involved and commit yourself. At every step, think of the purpose of each element, which interactions define it and what would happen if something either goes well or goes wrong.

Test in Different Scenarios Link

See how things behave in circumstances different from the ones you have while working on the design, beyond the design’s comfort zone. Leave your desk and speak with the actual people who are using (or will be using) the app. And, if possible, bring along others from your team with you. This is also very important — everybody has to be in touch with the real world, so that you all understand better the situations of real users.

Avoid Nonsense Buzzwords, Communicate Well Link

The key to good communication is to understand each other well. We sometimes use fancy words to sound “smarter” or to justify our work, but more important is for everybody on the team to be on the same page. Mutual understanding is key here.

Developers have jargon of their own, but most of the time you will be talking about the same things, only with different words. For example, what you call a “screen” is a “view” to them, and what you call a “button” is a “control,” and so on. So, try to align and agree on the terminology that you will be using, to make the exchange of information easier.

This is just as important when you’re talking to product managers and business partners. Designers need to be “multilingual” and understand everyone.

Use Components, Rules and Internal Patterns Link

Did I mention that I am a big advocate of design systems? Using a component library, I can design a new screen in literally five minutes (don’t tell my boss!), because I already have what I need to make it. Sometimes you will need to define those components the first time they arise, but they can be reused later for similar cases, not just to save the day in an emergency. Even though it might look like a waste of time in the beginning, it really will pay off in the long run.

Note: This article is not focused on components or pattern libraries, but here’s an excellent (and very detailed) read that I recommend in case you would like to learn more: “Taking Pattern Libraries to the Next Level⁴⁶³⁶.”

³⁷

Last but not least, don’t reinvent the wheel unless you have to. By taking advantage of common patterns and elements of the operating system and the app itself, you will design faster, the developers will build the screens more easily and, finally, the user’s learning curve will be less steep.

Discussion Is Better When Something’s on the Table Link

Do some design and prototyping even before you know whether the idea is feasible. It’s always better to show what you have in mind with a (hopefully) working live prototype as a means of communication.

Responding to a tangible proposal is always easier for people than imagining something theoretical. Don’t fall in love with your idea too early because it could be easily dismissed, but at least the prototype will help everyone to see what you’re talking about. (I wrote a little something about prototyping and prototyping tools not long ago: “Choosing the Right Prototyping Tool⁴¹”.)

Conclusion Link

Having a clearly defined problem with an elegant solution based on a design system will make the visual design part of our work even more fun, because we can focus on the refinements, polish and delight of the interface, without having to iterate endlessly. When we jump to the visuals too soon, we have to solve the problem and craft the interface at the same time, which often leads to frustration and burnout.

Changing your workflow might be challenging in the beginning, but after a while you will enjoy working within the constraints. This will also transform the way you think, and hopefully help you to move away from focusing on the visual details. You will become a more complete and capable UX designer, using the appropriate deliverables, and not just churning out an endless stream of visual mockups and compositions.

Good luck, dear reader! Do tell me what your thoughts are in the comments below, or ping me on Twitter⁴², I’d like to hear your feedback!

Further Reading Link

• “Modern Design Tools: Using Real Data⁴³,” Josh Puckett, Medium
• Craft⁴⁴, InVision
  
  A plugin for the Sketch app that enables you to use real data in a design.
• “The Dribbblisation of Design⁴⁵,” Paul Adams, Intercom
• “Taking Pattern Libraries to the Next Level⁴⁶³⁶,” Vitaly Friedman, Smashing Magazine
• “How to Fix a Bad User Interface⁴⁷,” Scott Hurff
• “Building a Visual Language⁴⁸³³,” Karri Saarinen, Airbnb

(mb, al)

Footnotes Link

1. 1 https://www.smashingmagazine.com/2016/07/conversational-interfaces-where-are-we-today-where-are-we-heading/
2. 2 https://www.smashingmagazine.com/2011/09/content-prototyping-in-responsive-web-design/
3. 3 https://www.smashingmagazine.com/2017/02/getting-started-with-vr-interface-design/
4. 4 https://www.smashingmagazine.com/2015/04/thinking-like-an-app-designer/
5. 5 https://www.smashingmagazine.com/wp-content/uploads/2017/02/weather-large-opt.jpg
6. 6 https://www.behance.net/gallery/18092551/Just-another-weather-app
7. 7 https://twitter.com/webshocker_net
8. 8 https://www.smashingmagazine.com/wp-content/uploads/2017/02/weather-large-opt.jpg
9. 9 https://blog.intercom.com/the-dribbblisation-of-design/
10. 10 https://blog.intercom.com/the-dribbblisation-of-design/
11. 11 https://en.wikipedia.org/wiki/Wabi-sabi
12. 12 https://medium.com/bridge-collection/modern-design-tools-using-real-data-62d499e97482#.cif18ebov
13. 13 https://www.smashingmagazine.com/wp-content/uploads/2017/02/using-a-scrim-for-text-on-images-large-opt.jpg
14. 14 https://css-tricks.com/design-considerations-text-images/
15. 15 https://www.smashingmagazine.com/wp-content/uploads/2017/02/using-a-scrim-for-text-on-images-large-opt.jpg
16. 16 https://twitter.com/sergiandreplace
17. 17 https://tinyfac.es/
18. 18 https://www.smashingmagazine.com/wp-content/uploads/2017/02/tinyfaces-avatars-large-opt.jpg
19. 19 https://www.smashingmagazine.com/wp-content/uploads/2017/02/tinyfaces-avatars-large-opt.jpg
20. 20 https://www.smashingmagazine.com/wp-content/uploads/2017/02/facebook-loading-process-large-opt.png
21. 21 https://medium.com/ui-collection/the-psychological-speed-of-mobile-interfaces-df25276295dd#.wswar9e8z
22. 22 https://www.smashingmagazine.com/wp-content/uploads/2017/02/facebook-loading-process-large-opt.png
23. 23 https://www.youtube.com/results?search_query=lionel+messi
24. 24 https://www.smashingmagazine.com/wp-content/uploads/2017/02/google-maps-save-button-large-opt.png
25. 25 https://www.smashingmagazine.com/wp-content/uploads/2017/02/google-maps-save-button-large-opt.png
26. 26 http://scotthurff.com/posts/why-your-user-interface-is-awkward-youre-ignoring-the-ui-stack
27. 27 https://play.google.com/store/apps/details?id=com.suicidesquad.mira
28. 28 https://play.google.com/store/apps/details?id=com.smithyproductions.crystal
29. 29 https://itunes.apple.com/us/app/sketch-mirror/id677296955?mt=8
30. 30 https://www.smashingmagazine.com/wp-content/uploads/2017/02/google-calendar-layout-large-opt.jpg
31. 31 https://www.smashingmagazine.com/wp-content/uploads/2017/02/google-calendar-layout-large-opt.jpg
32. 32 https://www.smashingmagazine.com/wp-content/uploads/2017/02/airbnb-components-large-opt.png
33. 33 http://airbnb.design/building-a-visual-language/
34. 34 https://www.smashingmagazine.com/wp-content/uploads/2017/02/airbnb-components-large-opt.png
35. 35 https://piercifani.github.io/
36. 36 https://www.smashingmagazine.com/taking-pattern-libraries-next-level/
37. 37 https://www.smashingmagazine.com/wp-content/uploads/2017/02/general-electric-predix-system-large-opt.png
38. 38 https://medium.com/ge-design/ges-predix-design-system-8236d47b0891
39. 39 https://www.smashingmagazine.com/taking-pattern-libraries-next-level/
40. 40 https://www.smashingmagazine.com/wp-content/uploads/2017/02/general-electric-predix-system-large-opt.png
41. 41 https://www.smashingmagazine.com/2016/09/choosing-the-right-prototyping-tool/
42. 42 http://www.twitter.com/millonestarde
43. 43 https://medium.com/bridge-collection/modern-design-tools-using-real-data-62d499e97482
44. 44 https://www.invisionapp.com/craft
45. 45 https://blog.intercom.com/the-dribbblisation-of-design/
46. 46 https://www.smashingmagazine.com/taking-pattern-libraries-next-level/
47. 47 http://scotthurff.com/posts/why-your-user-interface-is-awkward-youre-ignoring-the-ui-stack
48. 48 http://airbnb.design/building-a-visual-language/

↑ Back to topTweet itShare on Facebook

Pull-to-refresh is one of the most popular gestures in mobile applications right now. It’s easy to use, natural and so intuitive that it is hard to imagine refreshing a page without it. In 2010, Loren Brichter created Tweetie, one of numerous Twitter applications. Diving into the pool of similar applications, you won’t see much difference among them; but Loren’s Tweetie stood out then.

It was one simple animation that changed the game — pull-to-refresh, an absolute innovation for the time. No wonder Twitter didn’t hesitate to buy Tweetie and hire Loren Brichter. Wise choice! As time went on, more and more developers integrated this gesture into their applications, and finally, Apple itself brought pull-to-refresh to its system application Mail, to the joy of people who value usability.

¹

Today, most clients wish to see this gesture in their apps, and most designers want to create prototypes with integrated pull-to-refresh animation, preferably a custom one. This tutorial explains how to build a prototype in Flinto³, a tool that makes swipe-gesture animation possible, and obviously you cannot create a pull-to-refresh animation without a pull. However, it would be fair to say that Flinto is not the only tool that gives us the swipe gesture — Facebook Origami and POP are worth mentioning. After we create a prototype, we will code it into our design of an Android application.

This tutorial will help you master Flinto, understand the logic of creating prototypes of this kind, and learn the process of coding these prototypes in your application. To follow the steps, you will need macOS, Sketch for Mac⁴, Flinto for Mac⁵ to create the prototype, and Android Studio⁶ and JDK 7+⁷ to write the code.

Further Reading on SmashingMag: Link

• In-App Gestures And Mobile App User Experience⁸
• How Functional Animation Helps Improve UX⁹
• The Thumb Zone: Designing For Mobile Users¹⁰
• Creating Advanced Animations In Photoshop¹¹

Prototype In Flinto Link

For the prototype, I am using screens of ChatBoard¹², an Android chat application by Erminesoft¹³. The list of user chat rooms would be a perfect place to integrate a refresh animation to check new messages. Let’s begin!

Step 1 Link

We’ll make all of the designs in Sketch¹⁴. For the first step, we’ll need to create one screen with any list of items the user will be able to refresh. Now we need to export the screen to Flinto. We have two options here:

• Export as separate PNG files.
• Use the plugin Send to Flinto¹⁵.

Step 2 Link

Let’s move to Flinto for Mac, which you can buy for $99, or you can download a free trial on the website¹⁶. To make a simple pull-to-refresh animation, we need five screens. At this point, we can add a custom image or use standard Flinto forms (a rectangle or circle) to create the animated element. For this project, I am using three standard circles. Stop right there: Don’t search for a circle form. Use a rectangle (R), make a square out of it, and set a maximum corner radius. There you go — you’ve got a circle!

Step 3 Link

The first animation frame requires a separate layer with the list of content. Behind it, we’ll place the animated element in the starting position; in our case, there will be three circles placed on the same X and Y coordinates. That’s screen 1.

¹⁷

Step 4 Link

On screen 2, we need to move the content down the Y-axis, revealing the animated element hidden behind the list of content.

¹⁹

Additionally at this step (and all following steps), the transition timer (“Timer Link”) should be turned on and set to 0 milliseconds, to eliminate any lag in transition to the next animation screen. Just click on an artboard title to see the timer transition settings.

²¹

Step 5 Link

The previous screen (screen 2) shows only one circle, but remember that three circles are placed at the same X and Y coordinates. At this point (screen 3), our task is to move one of the circles 30 pixels left along the X-axis, and another circle 30 pixels right along the X-axis. Don’t forget to set the transition timer to 0 milliseconds.

²³

Step 6 Link

Let’s move on to screen 4. Repeat step 5 doing the same thing but moving the circles along the Y-axis instead of the X-axis for the same 30 pixels. The X coordinates of all of the elements should be the same and center-aligned. Don’t forget about the transition timer.

²⁵

Step 7 Link

Copy screen 2 for the new screen 5. At this step, all we need to do is change the timer link’s target not to screen 3 but to our home screen.

²⁷

Step 8 Link

All of the preparations are done, and we can now move to the animations. Create a new transition. Select the layer of content on the home screen, press F, and link it to screen 2.

(By the way, the key F refers to the name of the program itself, “Flinto.” It is its signature key.)

Apply the following transition settings:

• Gesture: down swipe
• Target: “Screen 2”
• Transition: “New transition”

²⁹

Step 9 Link

Now we get to the custom transition animation section. The first thing to do here is to lay one screen above the other. This creates the impression that it is one animated screen, instead of two screens, because it technically is.

Step 10 Link

At this point, we need to set the connections between elements throughout the screens in order for the program to associate them. For example, the element named “Circle-1” on the home screen is the same object on all of the screens. We just need to select two identical elements and click “Connect Layers.”

³¹

We have to connect all identical elements in this way for our “New Transition.” You can try out various kinds of animations in the “Effects” section, but in this particular case, I advise you to use “Spring,” to make our circles bounce.

³³

Step 11 Link

Click “Save & Exit.” Now we need to select this transition type for all of the transitions in our project, including our timers.

(An interesting fact: In Principle, the prototyping tool, layers are connected automatically when the program finds two elements with identical names. I find the automatic connection more convenient for those who keep Sketch’s layers’ names in order. Flinto is a better choice for the lazy ones who prefer to connect all animated elements while creating a prototype.)

Additionally, to achieve a more realistic effect, you can make the refreshed screen show an update or an additional item.

In case things don’t go as expected when you follow this tutorial, simply download the related Flinto template³⁵.

Despite the simplicity of this animation, it delivers surprising dynamics and responsiveness to the prototype. It also gives a feeling of product completeness, and it is necessary to making a prototype feel as product-like as possible.

Prototyping is a crucial stage in application development, not only impressing the client and verifying the design concept, but also helping to establish a hand-off process between the designers (who create the animations) and the developers (who implement them). Prototypes can become a valuable asset of communication between team members because they ensure that coders understand the project’s specifications and can implement the designer’s custom animations.

Now, let’s proceed to code our prototype in a Java application for Android mobile devices.

Code Link

The whole process of creating a custom PullToRefreshListView for Android involves only three steps:

1. Create the animated element.
2. Code a custom ListView.
3. Integrate the element into the application’s code.

1. The Animated Element Link

Take the drawable folder in our project, and create a file named point.xml with the following content:

<?xml version="1.0" encoding="utf-8"?> <shape xmlns:android="http://schemas.android.com/apk/res/android" android:dither="true" android:shape="oval"> <gradient android:endColor="#ffff6600" android:gradientRadius="10dp" android:startColor="#ffffcc00" android:type="radial" android:useLevel="false" /> <size android:height="10dp" android:width="10dp" /> </shape> 

The element has now been formed. The next step is to build the animated movement of these elements. Let’s jump to the anim folder (or create it if it’s absent), and add two files, named left_step_anim.xml and right_step_anim.xml.

The following code listing is for left_step_anim.xml:

<?xml version="1.0" encoding="utf-8"?> <set xmlns:android="http://schemas.android.com/apk/res/android" android:duration="800" android:repeatMode="restart"> <translate android:fromXDelta="0%" android:toXDelta="-50" /> <translate android:startOffset="800" android:toYDelta="50" android:toXDelta="50" /> <translate android:startOffset="1600" android:toYDelta="-50" /> </set> 

The following code should be placed in right_step_anim.xml:

<?xml version="1.0" encoding="utf-8"?> <set xmlns:android="http://schemas.android.com/apk/res/android" android:duration="800"> <translate android:fromXDelta="0%p" android:toXDelta="50" /> <translate android:startOffset="800" android:toYDelta="-50" android:toXDelta="-50" /> <translate android:startOffset="1600" android:toYDelta="50" /> </set> 

Now we need to add our animation to the markdown. Browse to the layout folder, and create a file named ptr_header.xml, with the following code:

<?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:orientation="vertical" android:layout_width="match_parent" android:layout_height="match_parent" android:gravity="center_horizontal"> <RelativeLayout android:id="@+id/ptr_id_header" android:layout_width="fill_parent" android:layout_height="wrap_content" android:gravity="center_vertical" android:padding="5dp"> <ImageView android:id="@+id/point" android:paddingTop="30dp" android:paddingBottom="30dp" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_centerHorizontal="true" android:contentDescription="point" android:scaleType="fitCenter" android:src="@drawable/point" /> <ImageView android:id="@+id/point2" android:paddingTop="30dp" android:paddingBottom="30dp" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_centerHorizontal="true" android:contentDescription="point" android:scaleType="fitCenter" android:src="@drawable/point" /> <ImageView android:id="@+id/point3" android:paddingTop="30dp" android:paddingBottom="30dp" android:layout_width="wrap_content" android:layout_height="wrap_content" android:contentDescription="point" android:scaleType="fitCenter" android:src="@drawable/point" android:layout_alignTop="@+id/point" android:layout_alignLeft="@+id/point" android:layout_alignStart="@+id/point" /> </RelativeLayout> </LinearLayout> 

The file we’ve created will serve as the animated element. Let’s proceed to the second step.

2. Custom ListView Link

We need to create an item to use in our custom ListView. To do this, navigate to the layout folder and create a file named list_item.xml, containing one TextView element. This is what it should look like:

<?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="fill_parent" android:layout_height="wrap_content" > <TextView android:id="@+id/textView1" android:layout_width="wrap_content" android:layout_height="fill_parent" android:padding="5dp" android:singleLine="true" android:textColor="@android:color/black" android:textSize="10pt" /> </LinearLayout> 

Now, let’s add a file with our ListView to the layout folder. In our case, it is a file named main.xml in a folder named layout. It should read as follows:

<?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="fill_parent" android:layout_height="fill_parent" android:orientation="vertical"> <erminesoft.com.listreload.PullToRefreshListView android:id="@+id/pull_to_refresh_listview" android:layout_height="fill_parent" android:layout_width="fill_parent" android:background="@android:color/white" android:cacheColorHint="@android:color/white" /> </LinearLayout> 

The custom ListView has now been created.

3. Integrating The Elements Link

The last step of this process involves binding together all of the elements above. We need to create two classes. The first class is named PullToRefreshListViewSampleActivity and is used when launching the application. The second class, PullToRefreshListView, will contain our element.

In the PullToRefreshListViewSampleActivity class, our attention is on the onRefresh() method of the onCreate() method. This method is exactly where all of the ListView refreshing magic will happen. Because this is an example, we’ve added our own test data with the loadData() method of the internal class PullToRfreshListSampleAdapter. The remaining code of the PullToRefreshListViewSampleActivity class is relatively simple.

Let’s move on to the PullToRefreshListView class. Because the main functionality is built on the standard ListView, we’ll add extends ListView to its name. The class is quite simple, yet animation involves a few constants that are defined by experimentation. Besides that, the interface implements the onRefresh() method.

Now let’s add a file with our ListView to the layout folder. In our case, it is a file named main.xml in a folder named layout. It should read as follows:

public interface OnRefreshListener{ void onRefresh(); } 

This method will be used to refresh the ListView. Our class also contains several constructors to create the View element.

public PullToRefreshListView(Context context){ super(context); init(context); } public PullToRefreshListView(Context context, AttributeSet attrs){ super(context, attrs); init(context); } public PullToRefreshListView(Context context, AttributeSet attrs, int defStyle){ super(context, attrs, defStyle); init(context); } 

The class also includes the onTouchEvent and onScrollChanged event handlers. These are standard solutions that have to be implemented. You will also need the private class HeaderAnimationListener, which handles animation in the ListView.

private class HeaderAnimationListener implements AnimationListener{ ... } 

There you go! The code is available on GitHub³⁶.

This tutorial is intended to encourage designers and developers to work together to integrate a custom pull-to-refresh animation and to make it a small yet nice surprise for users. It adds a certain uniqueness to an application and shows that the developers are dedicated to creating an engaging experience for the user above all else. It is also the foundation for making more complex animation, limited only by your imagination. We believe it’s important to experiment with custom animations, adding a touch of creativity to every project you build!

(da, al, il)

Footnotes Link

1. 1 https://www.smashingmagazine.com/wp-content/uploads/2016/12/pull-to-refresh-large-opt.png
2. 2 https://www.smashingmagazine.com/wp-content/uploads/2016/12/pull-to-refresh-large-opt.png
3. 3 https://www.flinto.com/mac
4. 4 https://www.sketchapp.com/
5. 5 https://www.flinto.com/mac
6. 6 https://developer.android.com/studio/index.html
7. 7 http://docs.oracle.com/javase/7/docs/webnotes/install/
8. 8 https://www.smashingmagazine.com/2016/10/in-app-gestures-and-mobile-app-user-experience/
9. 9 https://www.smashingmagazine.com/2017/01/how-functional-animation-helps-improve-user-experience/
10. 10 https://www.smashingmagazine.com/2016/09/the-thumb-zone-designing-for-mobile-users/
11. 11 https://www.smashingmagazine.com/2015/06/creating-advanced-animations-in-photoshop/
12. 12 https://play.google.com/store/apps/details?id=com.erminesoft.chatboard
13. 13 http://www.erminesoft.com
14. 14 https://www.sketchapp.com/
15. 15 https://www.flinto.com/mac_sketch_plugin
16. 16 https://www.flinto.com/mac
17. 17 https://www.smashingmagazine.com/wp-content/uploads/2016/12/3-large-opt.png
18. 18 https://www.smashingmagazine.com/wp-content/uploads/2016/12/3-large-opt.png
19. 19 https://www.smashingmagazine.com/wp-content/uploads/2016/12/4-large-opt.png
20. 20 https://www.smashingmagazine.com/wp-content/uploads/2016/12/4-large-opt.png
21. 21 https://www.smashingmagazine.com/wp-content/uploads/2016/12/5-large-opt.png
22. 22 https://www.smashingmagazine.com/wp-content/uploads/2016/12/5-large-opt.png
23. 23 https://www.smashingmagazine.com/wp-content/uploads/2016/12/6-large-opt.png
24. 24 https://www.smashingmagazine.com/wp-content/uploads/2016/12/6-large-opt.png
25. 25 https://www.smashingmagazine.com/wp-content/uploads/2016/12/7-large-opt-1.png
26. 26 https://www.smashingmagazine.com/wp-content/uploads/2016/12/7-large-opt-1.png
27. 27 https://www.smashingmagazine.com/wp-content/uploads/2016/12/8-large-opt.png
28. 28 https://www.smashingmagazine.com/wp-content/uploads/2016/12/8-large-opt.png
29. 29 https://www.smashingmagazine.com/wp-content/uploads/2016/12/9-large-opt.png
30. 30 https://www.smashingmagazine.com/wp-content/uploads/2016/12/9-large-opt.png
31. 31 https://www.smashingmagazine.com/wp-content/uploads/2016/12/10-large-opt.png
32. 32 https://www.smashingmagazine.com/wp-content/uploads/2016/12/10-large-opt.png
33. 33 https://www.smashingmagazine.com/wp-content/uploads/2016/12/11-large-opt.png
34. 34 https://www.smashingmagazine.com/wp-content/uploads/2016/12/11-large-opt.png
35. 35 https://drive.google.com/file/d/0B5mFiaC5f_0gMHk0OFBKZU0zLWc/view?usp=sharing
36. 36 https://github.com/erminesoft-com/pull-to-refresh

↑ Back to topTweet itShare on Facebook

Over the last five years, Node.js¹ has helped to bring uniformity to software development. You can do anything in Node.js, whether it be front-end development, server-side scripting, cross-platform desktop applications, cross-platform mobile applications, Internet of Things, you name it. Writing command line tools has also become easier than ever before because of Node.js — not just any command line tools, but tools that are interactive, useful and less time-consuming to develop.

If you are a front-end developer, then you must have heard of or worked on Gulp², Angular CLI³, Cordova⁴, Yeoman⁵ and others. Have you ever wondered how they work? For example, in the case of Angular CLI, by running a command like ng new <project-name>, you end up creating an Angular project with basic configuration. Tools such as Yeoman ask for runtime inputs that eventually help you to customize a project’s configuration as well. Some generators in Yeoman help you to deploy a project in your production environment. That is exactly what we are going to learn today.

Further Reading on SmashingMag: Link

• A Detailed Introduction To Webpack⁶
• An Introduction To Node.js And MongoDB⁷
• Server-Side Rendering With React, Node And Express⁸
• Useful Node.js Tools, Tutorials And Resources⁹

In this tutorial, we will develop a command line application that accepts a CSV file of customer information, and using the SendGrid API¹⁰, we will send emails to them. Here are the contents of this tutorial:

1. “Hello, World”¹¹
2. Handling command line arguments¹²
3. Runtime user inputs¹³
4. Asynchronous network communication¹⁴
5. Decorating the CLI output¹⁵
6. Making it a shell command¹⁶
7. Beyond JavaScript¹⁷

“Hello, World”

This tutorial assumes you have installed Node.js on your system. In case you have not, please install it¹⁸. Node.js also comes with a package manager named npm¹⁹. Using npm, you can install many open-source packages. You can get the complete list on npm’s official website²⁰. For this project, we will be using many open-source modules (more on that later). Now, let’s create a Node.js project using npm.

$ npm init name: broadcast version: 0.0.1 description: CLI utility to broadcast emails entry point: broadcast.js 

I have created a directory named broadcast, inside of which I have run the npm init command. As you can see, I have provided basic information about the project, such as name, description, version and entry point. The entry point is the main JavaScript file from where the execution of the script will start. By default, Node.js assigns index.js as the entry point; however, in this case, we are changing it to broadcast.js. When you run the npm init command, you will get a few more options, such as the Git repository, license and author. You can either provide values or leave them blank.

Upon successful execution of the npm init, you will find that a package.json file has been created in the same directory. This is our configuration file. At the moment, it holds the information that we provided while creating the project. You can explore more about package.jsonin npm’s documentation²¹.

Now that our project is set up, let’s create a “Hello world” program. To start, create a broadcast.js file in your project, which will be your main file, with the following snippet:

console.log('hello world'); 

Now, let’s run this code.

$ node broadcast hello world 

As you can see, “hello word” is printed to the console. You can run the script with either node broadcast.js or node broadcast; Node.js is smart enough to understand the difference.

According to package.json’s documentation, there is an option named dependencies²² in which you can mention all of the third-party modules that you plan to use in the project, along with their version numbers. As mentioned, we will be using many third-party open-source modules to develop this tool. In our case, package.json looks like this:

{ "name": "broadcast", "version": "0.0.1", "description": "CLI utility to broadcast emails", "main": "broadcast.js", "license": "MIT", "dependencies": { "async": "^2.1.4", "chalk": "^1.1.3", "commander": "^2.9.0", "csv": "^1.1.0", "inquirer": "^2.0.0", "sendgrid": "^4.7.1" } } 

As you must have noticed, we will be using Async³⁹²³, Chalk⁴⁵²⁴, Commander³⁰²⁵, CSV³¹²⁶, Inquirer.js²⁷ and SendGrid³⁶²⁸. As we progress ahead with the tutorial, usage of these modules will be explained in detail.

Handling Command Line Arguments

Reading command line arguments is not difficult. You can simply use process.argv²⁹ to read them. However, parsing their values and options is a cumbersome task. So, instead of reinventing the wheel, we will use the Commander³⁰²⁵ module. Commander is an open-source Node.js module that helps you write interactive command line tools. It comes with very interesting features for parsing command line options, and it has Git-like subcommands, but the thing I like best about Commander is the automatic generation of help screens. You don’t have to write extra lines of code — just parse the --help or -h option. As you start defining various command line options, the --help screen will get populated automatically. Let’s dive in:

$ npm install commander --save 

This will install the Commander module in your Node.js project. Running the npm install with --save option will automatically include Commander in the project’s dependencies, defined in package.json. In our case, all of the dependencies have already been mentioned; hence, there is no need to run this command.

var program = require('commander'); program .version('0.0.1') .option('-l, --list [list]', 'list of customers in CSV file') .parse(process.argv) console.log(program.list); 

As you can see, handling command line arguments is straightforward. We have defined a --list option. Now, whatever values we provide followed by the --list option will get stored in a variable wrapped in brackets — in this case, list. You can access it from the program variable, which is an instance of Commander. At the moment, this program only accepts a file path for the --list option and prints it in the console.

$ node broadcast --list input/employees.csv input/employees.csv 

You must have noticed also a chained method that we have invoked, named version. Whenever we run the command providing --version or -V as the option, whatever value is passed in this method will get printed.

$ node broadcast --version 0.0.1 

Similarly, when you run the command with the --help option, it will print all of the options and subcommands defined by you. In this case, it will look like this:

$ node broadcast --help Usage: broadcast [options] Options: -h, --help output usage information -V, --version output the version number -l, --list <list> list of customers in CSV file 

Now that we are accepting file paths from command line arguments, we can start reading the CSV file using the CSV³¹²⁶ module. The CSV module is an all-in-one-solution for handling CSV files. From creating a CSV file to parsing it, you can achieve anything with this module.

Because we plan to send emails using the SendGrid API, we are using the following document as a sample CSV file. Using the CSV module, we will read the data and display the name and email address provided in the respective rows.

First name	Last name	Email
Dwight	Schrute	dwight.schrute@dundermifflin.com
Jim	Halpert	jim.halpert@dundermifflin.com
Pam	Beesly	pam.beesly@dundermifflin.com
Ryan	Howard	ryan.howard@dundermifflin.com
Stanley	Hudson	stanley.hudson@dundermifflin.com

Now, let’s write a program to read this CSV file and print the data to the console.

const program = require('commander'); const csv = require('csv'); const fs = require('fs'); program .version('0.0.1') .option('-l, --list [list]', 'List of customers in CSV') .parse(process.argv) let parse = csv.parse; let stream = fs.createReadStream(program.list) .pipe(parse({ delimiter : ',' })); stream .on('data', function (data) { let firstname = data[0]; let lastname = data[1]; let email = data[2]; console.log(firstname, lastname, email); }); 

Using the native File System³² module, we are reading the file provided via command line arguments. The File System module comes with predefined events, one of which is data, which is fired when a chunk of data is being read. The parse method from the CSV module splits the CSV file into individual rows and fires multiple data events. Every data event sends an array of column data. Thus, in this case, it prints the data in the following format:

$ node broadcast --list input/employees.csv Dwight Schrute dwight.schrute@dundermifflin.com Jim Halpert jim.halpert@dundermifflin.com Pam Beesly pam.beesly@dundermifflin.com Ryan Howard ryan.howard@dundermifflin.com Stanley Hudson stanley.hudson@dundermifflin.com 

Runtime User Inputs

Now we know how to accept command line arguments and how to parse them. But what if we want to accept input during runtime? A module named Inquirer.js³³ enables us to accept various types of input, from plain text to passwords to a multi-selection checklist.

For this demo, we will accept the sender’s email address and name via runtime inputs.

… let questions = [ { type : "input", name : "sender.email", message : "Sender's email address - " }, { type : "input", name : "sender.name", message : "Sender's name - " }, { type : "input", name : "subject", message : "Subject - " } ]; let contactList = []; let parse = csv.parse; let stream = fs.createReadStream(program.list) .pipe(parse({ delimiter : "," })); stream .on("error", function (err) { return console.error(err.message); }) .on("data", function (data) { let name = data[0] + " " + data[1]; let email = data[2]; contactList.push({ name : name, email : email }); }) .on("end", function () { inquirer.prompt(questions).then(function (answers) { console.log(answers); }); }); 

First, you’ll notice in the example above that we’ve created an array named contactList, which we’re using to store the data from the CSV file.

Inquirer.js comes with a method named prompt³⁴, which accepts an array of questions that we want to ask during runtime. In this case, we want to know the sender’s name and email address and the subject of their email. We have created an array named questions in which we are storing all of these questions. This array accepts objects with properties such as type, which could be anything from an input to a password to a raw list. You can see the list of all available types in the official documentation³⁵. Here, name holds the name of the key against which user input will be stored. The prompt method returns a promise object that eventually invokes a chain of success and failure callbacks, which are executed when the user has answered all of the questions. The user’s response can be accessed via the answers variable, which is sent as a parameter to the then callback. Here is what happens when you execute the code:

$ node broadcast -l input/employees.csv ? Sender's email address - michael.scott@dundermifflin.com ? Sender's name - Micheal Scott ? Subject - Greetings from Dunder Mifflin { sender: { email: 'michael.scott@dundermifflin.com', name: 'Michael Scott' }, subject: 'Greetings from Dunder Mifflin' } 

Asynchronous Network Communication

Now that we can read the recipient’s data from the CSV file and accept the sender’s details via the command line prompt, it is time to send the emails. We will be using SendGrid’s API to send email.

… let __sendEmail = function (to, from, subject, callback) { let template = "Wishing you a Merry Christmas and a " + "prosperous year ahead. P.S. Toby, I hate you."; let helper = require('sendgrid').mail; let fromEmail = new helper.Email(from.email, from.name); let toEmail = new helper.Email(to.email, to.name); let body = new helper.Content("text/plain", template); let mail = new helper.Mail(fromEmail, subject, toEmail, body); let sg = require('sendgrid')(process.env.SENDGRID_API_KEY); let request = sg.emptyRequest({ method: 'POST', path: '/v3/mail/send', body: mail.toJSON(), }); sg.API(request, function(error, response) { if (error) { return callback(error); } callback(); }); }; stream .on("error", function (err) { return console.error(err.response); }) .on("data", function (data) { let name = data[0] + " " + data[1]; let email = data[2]; contactList.push({ name : name, email : email }); }) .on("end", function () { inquirer.prompt(questions).then(function (ans) { async.each(contactList, function (recipient, fn) { __sendEmail(recipient, ans.sender, ans.subject, fn); }); }); }); 

In order to start using the SendGrid³⁶²⁸ module, we need to get an API key. You can generate this API key from SendGrid’s dashboard³⁷ (you’ll need to create an account). Once the API key is generated, we will store this key in environment variables against a key named SENDGRID_API_KEY. You can access environment variables in Node.js using process.env³⁸.

In the code above, we are sending asynchronous email using SendGrid’s API and the Async³⁹²³ module. The Async module is one of the most powerful Node.js modules. Handling asynchronous callbacks often leads to callback hell⁴⁰. There comes a point when there are so many asynchronous calls that you end up writing callbacks within a callback, and often there is no end to it. Handling errors gets even more complicated for a JavaScript ninja. The Async module helps you to overcome callback hell, providing handy methods such as each⁴¹, series⁴², map⁴³ and many more. These methods help us write code that is more manageable and that, in turn, appears like synchronous behavior.

In this example, rather than sending a synchronous request to SendGrid, we are sending an asynchronous request in order to send an email. Based on the response, we’ll send subsequent requests. Using each method in the Async module, we are iterating over the contactList array and calling a function named __sendEmail. This function accepts the recipient’s details, the sender’s details, the subject line and the callback for the asynchronous call. __sendEmail sends emails using SendGrid’s API; you can explore more about the SendGrid module in the official documentation⁴⁴. Once an email is successfully sent, an asynchronous callback is invoked, which passes the next object from the contactList array.

That’s it! Using Node.js, we have created a command line application that accepts CSV input and sends email.

Decorating The Output

Now that our application is ready to send emails, let’s see how can we decorate the output, such as errors and success messages. To do so, we’ll use the Chalk⁴⁵²⁴ module, which is used to style command line inputs.

… stream .on("error", function (err) { return console.error(err.response); }) .on("data", function (data) { let name = data[0] + " " + data[1]; let email = data[2]; contactList.push({ name : name, email : email }); }) .on("end", function () { inquirer.prompt(questions).then(function (ans) { async.each(contactList, function (recipient, fn) { __sendEmail(recipient, ans.sender, ans.subject, fn); }, function (err) { if (err) { return console.error(chalk.red(err.message)); } console.log(chalk.green('Success')); }); }); }); 

In the snippet above, we have added a callback function while sending emails, and that function is called when the asynchronous each loop is either completed or broken due to runtime error. Whenever a loop is not completed, it sends an error object, which we print to the console in red. Otherwise, we print a success message in green.

If you go through Chalk’s documentation, you will find many options to style this input, including a range of console colors (magenta, yellow, blue, etc.) underlining and bolded text.

Making It A Shell Command

Now that our tool is complete, it is time to make it executable like a regular shell command. First, let’s add a shebang⁴⁶ at the top of broadcast.js, which will tell the shell how to execute this script.

#!/usr/bin/env node const program = require("commander"); const inquirer = require("inquirer"); … 

Now, let’s configure the package.json to make it executable.

… "description": "CLI utility to broadcast emails", "main": "broadcast.js", "bin" : { "broadcast" : "./broadcast.js" } … 

We have added a new property named bin⁴⁷, in which we have provided the name of the command from which broadcast.js will be executed.

Now for the final step. Let’s install this script at the global level so that we can start executing it like a regular shell command.

$ npm install -g 

Before executing this command, make sure you are in the same project directory. Once the installation is complete, you can test the command.

$ broadcast --help 

This should print all of the available options that we get after executing node broadcast --help. Now you are ready to present your utility to the world.

One thing to keep in mind: During development, any change you make in the project will not be visible if you simply execute the broadcast command with the given options. If you run which broadcast, you will realize that the path of broadcast is not the same as the project path in which you are working. To prevent this, simply run npm link in your project folder. This will automatically establish a symbolic link between the executable command and the project directory. Henceforth, whatever changes you make in the project directory will be reflected in the broadcast command as well.

Beyond JavaScript

The scope of the implementation of these kinds of CLI tools goes well beyond JavaScript projects. If you have some experience with software development and IT, then Bash tools⁴⁸ will have been a part of your development process. From deployment scripts to cron jobs⁴⁹ to backups, you could automate anything using Bash scripts. In fact, before Docker⁵⁰, Chef⁵¹ and Puppet⁵² became the de facto standards for infrastructure management, Bash was the savior. However, Bash scripts always had some issues. They do not easily fit in a development workflow. Usually, we use anything from Python to Java to JavaScript; Bash has rarely been a part of core development. Even writing a simple conditional statement in Bash requires going through endless documentation and debugging.

However, with JavaScript, this whole process becomes simpler and more efficient. All of the tools automatically become cross-platform. If you want to run a native shell command such as git, mongodb or heroku, you could do that easily with the Child Process⁵³ module in Node.js. This enables you to write software tools with the simplicity of JavaScript.

I hope this tutorial has been helpful to you. If you have any questions, please drop them in the comments section below or tweet me⁵⁴.

(rb, al, il)

Footnotes Link

1. 1 https://nodejs.org/
2. 2 http://gulpjs.com
3. 3 https://cli.angular.io
4. 4 https://cordova.apache.org
5. 5 http://yeoman.io
6. 6 https://www.smashingmagazine.com/2017/02/a-detailed-introduction-to-webpack/
7. 7 https://www.smashingmagazine.com/2014/05/detailed-introduction-nodejs-mongodb/
8. 8 https://www.smashingmagazine.com/2016/03/server-side-rendering-react-node-express/
9. 9 https://www.smashingmagazine.com/2011/09/useful-node-js-tools-tutorials-and-resources/
10. 10 https://github.com/sendgrid/sendgrid-nodejs
11. 11 #hello-world
12. 12 #cli-arguments
13. 13 #runtime-inputs
14. 14 #async-communication
15. 15 #chalk
16. 16 #shell-command
17. 17 #beyond-js
18. 18 https://nodejs.org/
19. 19 https://www.npmjs.com
20. 20 https://www.npmjs.com
21. 21 https://docs.npmjs.com/files/package.json
22. 22 https://docs.npmjs.com/files/package.json#dependencies
23. 23 http://caolan.github.io/async/docs.html
24. 24 https://github.com/chalk/chalk
25. 25 https://www.npmjs.com/package/commander
26. 26 https://www.npmjs.com/package/csv
27. 27 https://github.com/SBoudrias/Inquirer.js/
28. 28 https://github.com/sendgrid/sendgrid-nodejs
29. 29 https://nodejs.org/docs/latest/api/process.html
30. 30 https://www.npmjs.com/package/commander
31. 31 https://www.npmjs.com/package/csv
32. 32 https://nodejs.org/api/fs.html
33. 33 https://github.com/SBoudrias/Inquirer.js
34. 34 https://github.com/SBoudrias/Inquirer.js#methods
35. 35 https://github.com/SBoudrias/Inquirer.js/
36. 36 https://github.com/sendgrid/sendgrid-nodejs
37. 37 https://app.sendgrid.com/settings/api_keys
38. 38 https://nodejs.org/api/process.html#process_process_env
39. 39 http://caolan.github.io/async/docs.html
40. 40 http://stackoverflow.com/a/25098230/757449
41. 41 http://caolan.github.io/async/docs.html#each
42. 42 http://caolan.github.io/async/docs.html#series
43. 43 http://caolan.github.io/async/docs.html#map
44. 44 https://sendgrid.com/docs/API_Reference/Web_API_v3/index.html
45. 45 https://github.com/chalk/chalk
46. 46 http://unix.stackexchange.com/a/87600
47. 47 https://docs.npmjs.com/files/package.json#bin
48. 48 https://en.wikipedia.org/wiki/Bash_(Unix_shell)
49. 49 https://en.wikipedia.org/wiki/Cron
50. 50 https://www.docker.com
51. 51 https://www.chef.io
52. 52 https://puppet.com
53. 53 https://nodejs.org/api/child_process.html
54. 54 https://twitter.com/nihar_sawant

↑ Back to topTweet itShare on Facebook

Editor’s Note: Making big changes doesn’t necessarily require big efforts — it’s just a matter of moving in the right direction. We can’t wait for Paul’s new book on User Experience Revolution¹ (free worldwide shipping starting from April 18!), and in this article, Paul shares just some of the little tricks and techniques to bring around a big UX revolution into your company — with a series of small, effective steps.

It feels like everywhere I turn somebody is saying that user experience is the next frontier in business, that we have moved beyond the age of features to creating outstanding experiences.

But for many of us who work on in-house teams, the reality feels a million miles away from this. Getting management to understand the importance of user experience² seems so tough. Even colleagues don’t seem to see the benefit. For those of us in-house, how are we going to get to this golden age of user experience design that people keep promising us?

After all, design-led companies have outperformed the rest of the market by 228% over 10 years³. 89% of customers say⁴ they’ve stopped doing business with a company after a bad experience. Why then aren’t companies falling over themselves to create a better experience? Why is your job so frustrating at times?

The answer is simple. Change is hard. The world has changed. Digital has changed it, and people’s expectations are higher than ever. People and not companies now have the power. Yet many managers still live in the past, in a world of mass production and mass market.

We need to provide the wake-up call our clients and management need. We need to help them realize the potential of user experience design, its potential to reshape their business and provide a competitive advantage. But how?

First, we need to realize we cannot do it alone.

Further Reading on SmashingMag: Link

• Better User Experience With Storytelling⁵
• How Functional Animation Helps Improve User Experience⁶
• Think Your App Is Beautiful? Not Without User Experience Design⁷
• Are We Thinking About Digital All Wrong?⁸
• The Elements Of The Mobile User Experience⁹

Find Like-minded People Link

Sometimes we designers are our own worst enemy. We sit around moaning that nobody gets it, that nobody understands. But that isn’t true. Designers are not the only people who see the value of a great customer experience. Others might not know the term UX, but that doesn’t mean they don’t care.

Marketers and sales people understand; they know that a satisfied customer is the best form of advertising. Customer support staff know; they know that happy customers are less likely to call them with problems. Even the finance people get it; they understand that happy customers are less likely to return products, that they are more likely to make repeat purchases.

Neither are we the only people with insights into the user. Marketers have done their market research. Customer-support staff talk to customers every day.

If we want to bring about change in our organization, we cannot continue to be the lone wolf. We need to find allies. We need to bring together all those who care about the user’s experience.

This was part of the reason why Google’s culture shifted from being engineering focused to embracing the importance of design. Designers across the company started to reach out to each other. They started to talk to one another and united around shared values. You need to do the same.

Take the time to seek out people who share your belief in customer experience and start talking to them. Create a Slack channel or mailing list. Get together over lunch. Keep in touch. Share experiences and ideas.

Of course, chatting over lunch or in Slack isn’t going to bring about change. For that, you need to start a movement. You need to unite the group around a common goal, around a common cause.

Unite Around A Cause Link

There is power in numbers. Management is more likely to listen to you if you have a clear, consistent message.

Once you have formed your group, outline some principles on how the company could work to create a better user experience.

But be careful. This shouldn’t turn into a list of everything you perceive to be wrong with the company. That would do nothing but anger and threaten. Also, managers spend their lives hearing problems from employees. If you want to get their attention, you need to be more positive.

Instead, create a positive set of values that will encourage change, the kind of values that put user needs at the centre of decision-making, values such as “Design with data” and “If in doubt, test.”

¹⁰

There is no shortage of principles to inspire you, from the Government Digital Service in the UK¹³ to Google¹⁴. In fact, Jeremy Keith has kindly compiled a list¹⁵ of them over on his website.

On day one, these principles aren’t going to have teeth. Management won’t have bought into them. They aren’t something you can enforce. All of that can come later. For now, they will unite the group and strengthen your resolve.

But most of all, they will give you a clear message to take to the rest of the company, a message that has the customer at its heart.

Raise The Profile Of Customers Link

The next step in your campaign for change is to raise the profile of the customer. It is shocking how little most organizations talk about customer needs — or at least talk about it in any meaningful way.

Take a look at the average office wall. Companies cover them with certificates, product shots, executives shaking hands and motivational posters — all inward-looking, all focusing on the achievements of the organization. Rarely do you see the user.

Meanwhile, they shove the things that give insights into the user in a drawer somewhere: the personas, customer journey maps and user research. Why aren’t these things on the wall? Why don’t you make sure they are.

Instead of lecturing colleagues about users, make it impossible to ignore them. Turn that user research into attractive infographics. Cover the walls of your office with them. Sneak in at night and replace those inward-looking wall hangings. Put personas, data and quotes about the user in their place.

¹⁶

But don’t stop there. Open up those usability sessions that you run (you do run them, don’t you?) and invite anybody to come along. Bribe them with food if you have to, anything to get them to see users firsthand.

Failing that, record those sessions. Edit together the highlights, and distribute the video to colleagues.

¹⁸

Also, start sharing best practices on the user experience. Send out a weekly newsletter. Use it to highlight what others are doing to improve the customer experience. Quote experts and research in the field. Share testimonials from customers you have interviewed.

Consider running lunchtime sessions, presentations in which you share best practices, but also in which you share your research. Once again, lay out some food to encourage people to attend. If the budget allows, bring in the occasional outside speaker, someone who will add some credibility to the proceedings.

In short, create some buzz around the customer experience. Treat it like a product launch or marketing campaign. Get imaginative and make it impossible for your colleagues to escape the user.

But don’t target management. The biggest mistake I see people make is going to management for permission too soon. If you want to win over management, timing is everything. You need momentum and numbers behind you. You also need a clear vision of a better future.

Create A Vision Of The Future Link

As user experience designers, we tend to be visual people. We find it easy to imagine what could be. But not everybody is like that. Most people need to see the potential, rather than be told.

If we want management to care, we need to excite them. To excite them, we need to show them a better future, something they can see potential in. That is why, before we ever approach management, we need to have something to show.

Employees at Disney had an idea. They envisioned a MagicBand²⁰ that visitors to their parks would wear. The band would allow visitors to pay for anything, unlock their hotel room door and more. It would track one’s position so that Mickey could walk up to a child and wish them a happy birthday by name. It would allow a maître d’ to greet a patron personally as they arrived at the restaurant.

²¹

Winning over the executives would be tough. The investment was going to be large. So, they built a prototype. They converted an empty warehouse into a cardboard park. It had rides and hotel rooms and restaurants, everything they needed to show their idea.

They invited along the executives. They strapped paper prototypes of the MagicBand around their wrists. They then guided them around the cardboard park, giving them a sense of what the experience would be like.

By showing the executives, rather than telling them, they created excitement. That is what you need to do. A document or slide presentation isn’t going to do the job.

Build a prototype showing management a better way. Visualize a better user journey. Do whatever it takes to excite them about the potential.

You might have to work evenings to get it done. You might have to squeeze it between other work. But it will be worth it when you finally approach management to get them on board.

Approach Management Link

You are going to need management’s support if you want to see the company become user-centric. No amount of grassroots change is going to get the job done without them. So, when the moment comes, you need to make sure you don’t blow it.

First, put off talking to management until you have to. The longer you leave it, the better prepared you will be, the more momentum among colleagues will be behind you. Remember that management’s job is to shoot down half-baked ideas, so we want to give them no excuse.

Your prototype or vision of the future will help, but it won’t be enough. Some managers get excited by concepts and potential. Others are more risk-averse and prefer hard numbers. That is why you will want some data to back up your proposal. If possible, test the prototype with real users.

You can further mitigate risk by referring to outside data and experts. Third-party sources add credibility to your argument. Management will also consider them more impartial. That is why many choose to bring in an external consultant at this stage.

As you sit down to talk to management, bear in mind one important thing: They don’t care about the user experience, and no amount of arguing will change that. Tim Cook once said:

Most business models have focused on self interest instead of user experience.

Although you want to change that in the long term, you are not there yet. So, focusing on improvements to the user experience will not convince them.

Instead, we need to learn from Jared Spool. In his article “Why I Can’t Convince Executives to Invest in UX (and Neither Can You)²³,” he gets to the heart of the issue:

You can find out what your executives are already convinced of. If they are any good at what they do, they likely have something they want to improve. It’s likely to be related to improving revenues, reducing costs, increasing the number of new customers, increasing the sales from existing customers, or increasing shareholder value. Good UX can help with each of those things.

Whatever you want to do to improve the user experience, frame it with what management cares about. If you don’t know what that is, find out. Dig out that company strategy you never bothered to read. That will tell you exactly what they want to achieve. Now all you need to do is show how your ideas will move the company closer to those goals.

Of course, the big question is, what should you ask management for? What is it you want them to do? This is where things can go wrong.

If you ask them for wholesale change, you will overwhelm them. If you ask for a big investment, they will be hesitant. That would require you to have a very compelling case or a great track record of delivering on big-budget projects.

Instead, start small. Earn their trust and build their confidence. Avoid overwhelming them.

Start by outlining your vision of the future. Get them excited. But to avoid overwhelming them, you need to make the next step easy.

Instead of asking for wholesale change, ask them to take one small step. Ask permission to build a proof of concept, something to show that user experience can make a difference to the business.

Begin With A Proof Of Concept Link

A proof of concept is a chance to prove yourself and user experience design to management. It will show how you can make a difference to the business. So, getting the right proof of concept is critical.

There are three considerations in picking a project:

• You need a project that is not expensive to build. Otherwise, management will be hesitant to say yes.
• You need something that supports one of management’s goals and that uses UX design to achieve it.
• You want something measurable, so that you can prove whether the project works.

For example, suppose management wants to increase the number of leads the company gets. You might agree to run a project that encourages newsletter signups, but to run it in a way that provides value to the user, rather than tricking people into signing up. This will give you a chance to show that putting the user first provides better returns.

This project would work well because you can tie it to a management goal. It would also be inexpensive to build, and its effectiveness would be easy to measure.

The key to a successful proof of concept is to gather as much evidence of success as possible. Measure relentlessly. Even trial more than one approach for comparison. This will provide the evidence that management needs to be confident in you and in the benefits of user experience. It will give them the confidence to take the next step.

This Is A Marathon, Not A Sprint Link

A proof of concept is still only the beginning of the journey. You will need to run many such projects that guide management step by step towards your vision of the future.

Remember that this is a marathon and not a sprint. It will take time. It will be frustrating. But what is so obvious to you isn’t to everybody. They will need to go on that journey at their own pace. We need to stand with them, encouraging folks to take that next step, keeping them focused on the end goal.

That is why we cannot hope to do it alone. We need to unite with others around this common aim and vision of the future. We need to work hard to raise the profile of the customer and to approach management with care. But most of all, we need a plan, a plan that starts with some simple pilot projects to build trust, but also one that shows the importance of user experience.

You might conclude that it is not worth the hassle, that you would prefer to work somewhere that already gets it. That is fine. This role is not for everybody. But if you do persevere and change the culture of your company, you will become invaluable. It is the kind of journey that can make a career and transform a company. From my perspective at least, that is worth it.

(al, il)

Footnotes Link

1. 1 https://www.smashingmagazine.com/user-experience-revolution/
2. 2 https://www.smashingmagazine.com/2010/10/what-is-user-experience-design-overview-tools-and-resources/
3. 3 http://dmi.org/?DesignValue
4. 4 http://customerthink.com/25-statistics-on-the-power-of-positive-customer-service/
5. 5 https://www.smashingmagazine.com/2010/01/better-user-experience-using-storytelling-part-one/
6. 6 https://www.smashingmagazine.com/2017/01/how-functional-animation-helps-improve-user-experience/
7. 7 https://www.smashingmagazine.com/2014/09/think-your-app-is-beautiful-not-without-user-experience-design/
8. 8 https://www.smashingmagazine.com/2014/03/are-we-thinking-about-digital-all-wrong/
9. 9 https://www.smashingmagazine.com/2012/07/elements-mobile-user-experience/
10. 10 https://www.smashingmagazine.com/wp-content/uploads/2017/03/GDS-Principles-large-opt.jpg
11. 11 https://www.smashingmagazine.com/wp-content/uploads/2017/03/GDS-Principles-large-opt.jpg
12. 12 https://www.gov.uk/design-principles
13. 13 https://www.gov.uk/design-principles
14. 14 https://www.google.com/about/company/philosophy/
15. 15 https://principles.adactio.com/
16. 16 https://www.smashingmagazine.com/wp-content/uploads/2017/03/Personas01-preview-opt.jpg
17. 17 https://blog.mailchimp.com/new-mailchimp-user-persona-research/
18. 18 https://www.smashingmagazine.com/wp-content/uploads/2017/03/lookback-smashing-large-opt.jpg
19. 19 https://www.smashingmagazine.com/wp-content/uploads/2017/03/lookback-smashing-large-opt.jpg
20. 20 https://disneyworld.disney.go.com/plan/my-disney-experience/bands-cards/
21. 21 https://www.smashingmagazine.com/wp-content/uploads/2017/03/Disney-MagicBands-Park-Ticket-large-opt.jpg
22. 22 https://www.smashingmagazine.com/wp-content/uploads/2017/03/Disney-MagicBands-Park-Ticket-large-opt.jpg
23. 23 https://www.uie.com/brainsparks/2011/06/08/why-i-cant-convince-executives-to-invest-in-ux-and-neither-can-you/

↑ Back to topTweet itShare on Facebook

In part 1¹ of this article, we looked at where in the world the new entrants to the World Wide Web are, and some of the new technologies the standards community has worked on to address some of the challenges that the next 4 billion people are facing when accessing the web. In short, we’ve tried to make some supply-side improvements to web standards so that websites can be made to better serve the whole world, not just the wealthy West.

But there are other challenges to surmount, such as ways to get over creaky infrastructure in developing markets (which can be done with stopgap technological solutions, such as proxy browsers), and we’ll also look at some of the reasons why some of the offline billions remain offline, and what can be done to address this.

Proxy Browsers

A common problem people encounter in emerging economies relates to networks. Networks are getting better, but they’re not there yet. In 2016, Ericsson reported²:

While cellular networks have improved… smartphone users are still facing issues as frequently as they did in 2013. Globally, 26 percent of smartphone users say they face video streaming issues daily, increasing to over one third in markets like Brazil, India and Indonesia.

This is an excellent statement of the problem. Infrastructure is expensive to upgrade, especially in countries like Indonesia, which is made up of thousands of islands, and India, which is huge and has vast mountain ranges. And as soon as infrastructure is upgraded, more people come online and want to consume video rather than boring old text, and so much more bandwidth is required, and the newly upgraded network crawls again.

In places where bandwidth is seriously constrained (in congested Asian megacities, not just rural areas; I’m in the heart of an Indian city with an international airport, and power cuts and Internet outages occur daily), a lot of people opt to use proxy browsers. Proxy browsers do a lot of the heavy lifting of rendering web pages on their servers and sending compressed versions down to the user, resulting in often significant reductions in data consumption. This is obviously a very appealing proposition for consumers in territories where bandwidth is expensive. Because the data transferred is smaller, websites render faster, too.

Scientia Mobile reported³ in 2016 that, for global market share of proxy browsers, Opera Mini is at 42%, Opera Turbo is at 9%, Chrome is at 39% and UCWeb is at 6%, and there is also Puffin, Silk and others. Opera reports more than 250 million active monthly users of Opera Mini.

Websites compressed by proxy browsers and sent as binary blobs also have a better chance of getting through congested networks. In 2013, Avendus reported (in “India’s Mobile Internet: The Revolution Has Begun,” no longer online):

In India, only 96k of the 736k cell towers are 3G enabled… only 35k of those towers have a fiber-optic connection to the backbone.

(If you’re a real networking anorak, you’ll find the report 2G Network Issues Observed While in India⁴ to be even more fun than a game of Werewolf at a Star Wars convention.)

Limitations of Proxy Browsers

So, if proxy browsers are so great, why doesn’t everyone use them? The answer is that such compression comes at a cost; websites can look very different in a proxy browser, and JavaScript can often behave unexpectedly.

In a proxy browser, everything happens on the server, everything needs user interaction, and everything needs a round-trip to the server. Opera Mini on Android and iOS has two modes; one uses proprietary compression techniques and the device’s standard web view, and thus JavaScript isn’t affected. In Opera Mini’s extreme mode, all of the rendering is done on Opera’s server farms, on which JavaScript is allowed to run for 5 seconds and then is throttled. (Disclosure: I was Deputy CTO of Opera until November 2016 and can talk authoritatively about its technology. However, I have no relationship with the company now.)

Therefore, to make websites work in Opera Mini’s extreme mode, treat JavaScript as an enhancement, and ensure that your core functionality works without it. Of course, it will probably be clunkier without scripts, but if your website works and your competitors’ don’t work for Opera Mini’s quarter of a billion users, you’ll get the business.

Mini’s extreme mode has design constraints, too: it doesn’t do CSS rounded corners or gradients, because it can’t rely upon every client device to draw those things successfully; so, to render it on the server, it would need to convert them into bitmaps, which would bloat the page. But that’s OK; CSS is for design, and people in highly bandwidth-constrained situations are happy to get the words.

Similarly, Mini’s extreme mode doesn’t do CSS or SVG animations, only showing the first frame. The reason for this is that animations consume CPU cycles, and CPU cycles consume battery. Yes, your animations are lovely, but if you are sitting on a bus in Lagos in a traffic jam and need to phone your sister to ask her to pick up your children from school, you need that battery life more than you need pretty animations.

Neither does Mini’s extreme mode download web fonts, which can be huge files that are primarily for aesthetics. On many very small monochrome screens, the system fonts tend to be designed for those screens and work better. If you want icons, use SVG rather than icon fonts because, well, that’s what SVG is for.

Revolutionary New Development Technique

The best way to ensure that your website or web app (is there a real difference?) will work for people on proxy browsers, conventional browsers with very slow connections and everyone else is to adopt a revolutionary new development methodology.

Airbnb tried it with its new app and wrote excitedly⁵:

… we’ve launched our first Holy Grail app… It looks exactly the same as the app it replaced, however initial pageload feels drastically quicker…

What voodoo magic did they employ?

… we serve up real HTML instead of waiting for the client to download JavaScript before rendering. Plus, it is fully crawlable by search engines.… It feels 5x faster.

Who knew? The best way to ensure that everyone gets your content is to write real, semantic HTML, to style it with CSS and ensure sensible fallbacks for CSS gradients, to use SVG for icons, and to treat JavaScript as an enhancement, ensuring that core functionality works without scripts. Package up your website with a manifest file and associated icons, add a service worker, and you’ll have a progressive web app in conforming browsers and a normal website everywhere else.

I call this amazing new technique “progressive enhancement.”

You heard it here first, folks!

What If We Threw A Party And Nobody Came?

We have supply-side improvements such as HTML responsive images, progressive web apps, renewed CSS work on vertical text. We have the methodology of progressive enhancement. We have proxy browsers that compress websites for people in low-bandwidth and expensive data plans. We have an explosion of ever-cheaper smartphones (and I’m not talking about the Galaxy Note 7 here). So, why aren’t the next 4 billion already on the web?

There are demand-side problems in emerging markets.

One of those is that the market for smartphones is either flat⁶ or declining⁷, depending on which statistics you read. There are many potential reasons for this: the slowdown in the Chinese economy (China, India and the US are the largest consumers of smartphones⁸); it could be a classic case of market saturation — everyone who wants a smartphone and can afford one already has one.

It could also have to do with devices like the one shown below, which was given to me at the Mobile World Congress SynergyFest.

⁹

It’s a feature phone, made in China; it doesn’t have Wi-Fi but is dual-SIM (very important in places like Africa and Asia); it has an FM radio; and it can connect to the web with a WAP-like browser. Its retail price in Africa and Latin America is $2.36 USD.

In a country like Cambodia, where a garment worker’s minimum wage is $140¹¹ a month, or Liberia, where an unskilled worker’s minimum wage is $4¹² a day, even a $60 to $70 entry-level smartphone is practically unaffordable. But $2.36? That’s affordable.

But it is not just affordability that stops people from coming to the web. As GSMA Intelligence wrote¹³ in July 2016:

Despite the fact that Africa has the lowest income per capita of any region, affordability was only identified as the most important barrier in one out of 13 markets in our survey.

And it’s not just about networks either, as GSMA Intelligence reports¹⁴:

Network coverage was not perceived as an issue in most countries, reflecting the increasing availability of mobile networks. However, mobile broadband (3G or 4G) coverage remains low in most parts of Africa.

The problem is much more profound, and doesn’t have a technological solution. From the same report:

A lack of awareness and locally relevant content was considered the most important barrier to internet adoption in North Africa and the second biggest barrier in Sub-Saharan Africa.

There’s also a worrying lack of digital skills that prevents people from using the web in Africa:

A lack of digital skills was identified as the biggest barrier to internet adoption in Sub-saharan Africa and the second biggest in North Africa.

The World Bank reports¹⁵:

In Africa, seven in ten people who do not use the internet say they just don’t know how to use it, and almost four in ten say they do not know what the internet is.

This is true not only of developing economies, by the way. The World Bank continues:

In high-income Poland and the Slovak Republic, one-fifth of adults cannot use a computer.

And in 2014, Pew Research Centre reported¹⁶:

41% [of American seniors] do not use the internet at all, 53% do not have broadband access at home, and 23% do not use cell phones.

The lack of digital skills is felt acutely by Asia, too. In its January 2016 Asia survey¹⁷, GSMA Intelligence wrote:

A lack of awareness and locally relevant content was the most commonly cited barrier to internet adoption: 72% of non-internet users across the six survey markets felt this was a barrier.… 50% of websites worldwide are in English, a language spoken by only 10% of speakers in the survey countries. By way of contrast, only 2% of websites worldwide are in Mandarin and less than 0.1% are in Hindi.

Below is a video made in a user-testing lab in rural Pakistan, featuring a man in his 20s. He has used a feature phone but never a smartphone. He’s given a simple-sounding task: Go to Google and search for the the name of your favourite actress. Watch the video. Watch it all.

Presumably, he’s stuck because he’s been accustomed to a feature phone with physical keys, and he simply doesn’t know how to call up the virtual keyboard. Anytime you believe that doing something in your web app is “obvious” or “intuitive”, watch this video again.

Digital Divide

Just as there is a digital divide between “the West” and developing economies, there is a digital divide in income, age, rural and urban, and women and men across the developing world. The World Bank illustrates a divide in income, gender, age and location (rural and urban).

¹⁸

In February 2016, 53% of urban areas²⁰ had mobile Internet connectivity, a growth of 71% in one year. In the same period, Internet usage in rural India increased by 93%, but that means that only 9% of people in rural India has access. As I write this, there is a copy of The Hindu newspaper next to my laptop, which today reports²¹ that the Indian government is recommending a community model of Wi-Fi hotspots, such as in neighborhood grocery stores, in rural areas where connectivity is poor and laying cables is not feasible.

The World Bank reports that in many countries (Cuba, Cambodia, Brazil and others), computers are taxed as luxury goods.

²²

Many countries, such as Fiji, Bangladesh and Pakistan, tax mobile phones as luxuries, too.

²⁴

Pressure For Change

The World Bank recommends that:

Making the internet universally accessible and affordable should be a global priority.

There are moves afoot to make this happen, such as an initiative called FASTAfrica²⁶. FAST stands for fast, affordable, secure and transparent. In a series of grassroots events across Africa in 2016, the organization has demanded:

• fair and transparent taxes on information and communications technology (ICT),
• greater effort from governments and donors,
• agreement on affordability (1 GB for 2% of disposable income),
• prioritization of getting women online.

World Wide Web Women

The World Bank writes:

Online work can prove particularly beneficial for women, youth, older workers, and the disabled, who may prefer the flexibility of working from home or working flexible hours.

GSMA Intelligence writes²⁷:

In India… women are 62% less likely to use the internet than men. Many of the underlying reasons for this — affordability, skills and content — are the same as for men; they are simply felt more acutely by women.

In rural India, only 2% of web users are women²⁸.

Yet we know that the web empowers women. Across the world in non-agricultural employment, women make up 25% of the work force, but in online work, women make up 44% of the work force.

When asked why online work is advantageous, women overwhelmingly cited the ability to work flexible hours from home as the primary advantage. (32% of women, compared with 23% of men, said that the primary disadvantage to online work is that payment is not high enough, which suggests that Africa, too, has an unjustifiable difference between what women and men get paid.

One successful government initiative is the Kudumbashree project²⁹, here in Kerala, India, where I’m writing this. “Kudumbashree” means “prosperity of the family” in the local Malayalm language. The World Bank reports:

The government of Kerala, India, outsources information technology services to cooperatives of women from poor families … Average earnings were US$45 a month, with close to 80 per-cent of women earning at least US$1 a day. Nine in ten of the women had previously not worked outside the home. Samasource, RuralShores, and Digital Divide Data are three private service providers. Samasource splits jobs into microwork for almost 6,400 workers, mostly in Ghana, Haiti, India, Kenya, and Uganda, on average more than doubling their previous income.

A similar story is happening in China:

Online shop owners using Alibaba in China, on average, employ 2.6 additional workers. Four in ten shop owners are women, 19 percent were previously unemployed, 7 percent were farmers, and about 1 percent are persons with disabilities.

What Can Be Done, And How Can You Help?

The World Bank says that:

Access to the internet is critical, but not sufficient. The full benefits of the information and communication transformation will not be realized unless countries continue to improve their business climate, invest in people’s education and health and promote good governance

Should you happen to be a politician in Africa, Asia or Latin America, please take note of the above. But, because you’re reading this, I expect you’re a web professional — but you can play your part! Make sure your websites are ready for the next 4 billion people, with their (potentially) slow networks and browsers and devices you may never have heard of.

• Progressively enhance to make sure your core functionality works without JavaScript.
• Use feature detection, rather than browser sniffing. You will never, ever be able to maintain a list of all devices in the world and their UA strings.
• Compress images properly and remove unnecessary meta data with a tool such as ImageOptim³⁰.
• Use HTML responsive images (and generate WebP³¹ versions of all of your assets), and send them to supporting browsers with the picture element.
• Focus relentlessly on performance.
• Write a progressive web app, rather than a native app.
• Test in a proxy browser, such as Opera Mini.

Developing countries are home to 94% of the global offline population. These people may be your next potential customers. But if they can’t buy from you because your website is a Wealthy Western Website rather than a World Wide Website, you can bet that your competitors will be happy to take their money.

McKinsey Global Institute writes³²:

An increase in internet maturity similar to the one experienced in mature countries over the past 5 years creates an increase in real GDP per capita of $500 on average during this period. It took the industrial revolution of the 19th century 50 years to produce same result.

But it’s not just about money. It’s about doing the right thing and keeping the web open, democratic and global.

Millions of people in Bangladesh, Nepal and India have miles to walk to visit a doctor, so a feature phone and the free online book Where There Is No Doctor³³ (often translated to their local language) becomes first-line medical care.

Millions of people in Subsaharan Africa can’t afford school textbooks, but Worldreader³⁴ has tens of thousands of books available for free online, and the books work fine even on old feature phones.

And millions of people in despotic regimes have the web as their only way to contact the outside world.

Please, do your part to ensure the health of the web that has provided you with so much, and pay it forward so the next people can benefit.

---

Thanks to Mrunmaiy Abroal³⁵, until recently Opera’s Head of Comms in India, and Peko Wan³⁶, Head of PR & Communications for Opera in Asia, for their help collecting some of the information in this article. Thanks to Karin Greve-Isdahl³⁷, VP Communications at Opera for allowing me to use charts and illustrations made while I was at Opera. Big thanks to Clara at Damcho Studio³⁸ for helping to prepare this article.

(vf, al, il)

Footnotes Link

1. 1 https://www.smashingmagazine.com/2017/03/world-wide-web-not-wealthy-western-web-part-1/
2. 2 https://www.ericsson.com/thinkingahead/consumerlab/consumer-insights/experience-shapes-mobile-customer-loyalty
3. 3 http://data.wurfl.io/MOVR/pdf/2016_q1/MOVR_2016_q1.pdf
4. 4 https://docs.google.com/presentation/d/1fZ7ftsJJ4adiPov4y_8AtV_zjqAmEASaSxRBHBwkiOw/edit#slide=id.g73cf3c208_0_158
5. 5 http://nerds.airbnb.com/weve-launched-our-first-nodejs-app-to-product/
6. 6 http://www.mobileworldlive.com
7. 7 https://www.strategyanalytics.com/strategy-analytics/blogs/devices/smartphones/smart-phones/2016/04/28/global-smartphone-shipments-decline-3-percent-in-q1-2016#.VyIu60GNL-Q
8. 8 http://businesskorea.co.kr/article/10453/poor-performance-samsung-phones-struggling-india-china
9. 9 https://www.smashingmagazine.com/wp-content/uploads/2017/02/pt2-www-img2-lawson-large-opt.png
10. 10 https://www.smashingmagazine.com/wp-content/uploads/2017/02/pt2-www-img2-lawson-large-opt.png
11. 11 https://business-humanrights.org/en/cambodia-2015-minimum-wage-negotiations
12. 12 http://www.liberianobserver.com/politics/passed-minimum-wage-set-us6day
13. 13 https://www.gsmaintelligence.com/research/2016/07/consumer-barriers-to-mobile-internet-adoption-in-africa/568/
14. 14 https://www.gsmaintelligence.com/research/2016/07/consumer-barriers-to-mobile-internet-adoption-in-africa/568/
15. 15 http://www.worldbank.org/en/publication/wdr2016
16. 16 http://www.pewinternet.org/2014/04/03/older-adults-and-technology-use/
17. 17 https://www.gsmaintelligence.com/research/2016/06/consumer-barriers-to-mobile-internet-adoption-in-asia/559/
18. 18 https://www.smashingmagazine.com/wp-content/uploads/2017/02/pt2-www-img3-lawson-large-opt.png
19. 19 https://www.smashingmagazine.com/wp-content/uploads/2017/02/pt2-www-img3-lawson-large-opt.png
20. 20 http://www.gadgetsnow.com/tech-news/Only-9-of-rural-India-has-access-to-mobile-internet-Report/articleshow/50840296.cms
21. 21 http://www.thehindu.com/business/Wi-fi-hotspots-coming-soon-to-a-store-near-you/article17264038.ece
22. 22 https://www.smashingmagazine.com/wp-content/uploads/2017/02/pt2-www-img4-lawson-large-opt.png
23. 23 https://www.smashingmagazine.com/wp-content/uploads/2017/02/pt2-www-img4-lawson-large-opt.png
24. 24 https://www.smashingmagazine.com/wp-content/uploads/2017/02/pt2-www-img5-lawson-large-opt.png
25. 25 https://www.smashingmagazine.com/wp-content/uploads/2017/02/pt2-www-img5-lawson-large-opt.png
26. 26 https://webwewant.org/fast-africa/
27. 27 https://www.gsmaintelligence.com/research/2016/07/consumer-barriers-to-mobile-internet-adoption-in-africa/568/
28. 28 https://www.bcgperspectives.com/content/articles/globalization-customer-insight-rising-connected-consumer-rural-india/
29. 29 http://www.kudumbashree.org/
30. 30 https://imageoptim.com/
31. 31 https://en.wikipedia.org/wiki/WebP
32. 32 http://www.mckinsey.com/industries/high-tech/our-insights/internet-matters
33. 33 http://hesperian.org/books-and-resources/
34. 34 https://www.worldreader.org/what-we-do/our-books/
35. 35 https://mrunmaiy.com/
36. 36 https://twitter.com/peko0413
37. 37 https://twitter.com/kgisdahl
38. 38 http://www.damcho.com

↑ Back to topTweet itShare on Facebook

This week was a big week in terms of web development news. We got much broader support for CSS Grids and Web Assembly, for example, but I also stumbled across some great resources that teach us a lot of valuable things.

With this Web Development Reading List, we’ll dive deep into security and privacy issues, take a look at a lightweight virtual DOM alternative, and get insights into how we can overcome our biases (or at least how we can better deal with them). So without further ado, let’s get started!

Further Reading on SmashingMag: Link

• Designing Card-Based User Interfaces
  
  ¹
• CSS Grid, Flexbox And Box Alignment: Our New System For Web Layout²
• Web Design Criticism: A How-To³
• Dealing With Loud And Silent Burnout⁴

News Link

• Chrome 57⁵ was released this week, and it brings us CSS Grids, the Media Session API, and Web Assembly. Also new is that Chrome will return an error for SHA1 certificates from now on.
• A new Firefox version was released to the public this week: Firefox 52⁶. The new version will display a prominent warning if a user fills in their password on a non-secure page, rel="noopener" was implemented, too, just like broad support for CSS Grids⁷, Web Assembly, and async/await. They also disabled all plugins except for Adobe Flash.
• The Samsung Internet browser beta is now available⁸ in the Google Play Store and via Samsung Galaxy Apps. It runs on Chromium 51, has support for progressive web apps, Service Worker, and content blockers.

General Link

• By analyzing the large-scale issues the web faced in the past month (think Amazon’s S3 outage causing a downtime of millions of websites, Cloudflare’s data leak that required users of very popular websites to change their passwords, or Google’s accidental WiFi reset which wiped out customers’ Internet profiles) Tristan Louis reflects on the question if we are breaking the Internet⁹. The trend towards a few services hosting a majority of the Internet’s infrastructure is causing more and more large-scale problems. If we want to avoid issues like these, we need to rethink this new kind of centralization and fix it.
• Bruce Lawson wrote about the “World Wide Web, Not Wealthy Western Web¹⁰”. It’s about the bias of western web developers, about ignoring other continents, and why we need to see the bigger picture instead. A piece you should definitely take the time to read.

Concept & Design Link

• It’s easy to build a standard card design, but we could do so much more with them. Andrew Coyle wrote about designing better cards¹¹, a component we use in nearly every design today.

¹²

Security Link

• In an attempt to participate in their own bug bounty program, Brett Buerhaus and Ben Sadeghipour analyzed AirBNB’s web service. And indeed, they stumbled over some pretty good examples of how to bypass a lot of security measurements¹⁵ they already had implemented.
• We know backups are crucial in IT operations. But what we often don’t think about is the backup’s security. A company that’s responsible for a lot of email spam recently exposed their backups to the public¹⁶ for over a month. Initially, we might think that’s great as this mishap makes it relatively easy to bring their operations to a halt, but then others have probably already picked up all the data to use it for their operations and, thus, producing an increase of spam.
• Tobias Laudinger and some of his co-workers conducted the first comprehensive study of client-side JavaScript library usage¹⁷ and the security implications it brings along. Based on data from over 133K websites, they found that 37% of websites include at least one library with a known vulnerability. Time to reconsider our use of external dependencies and how we can keep them up-to-date.

Privacy Link

• Another big data leak was revealed by WikiLeaks this week, this time it’s called “Vault7 — CIA Hacking Tools Revealed¹⁸”. And, well, it does, in fact, confirm the worst fears privacy researchers had: The CIA is spying on Samsung TVs¹⁹, and it’s extremely likely that Amazon’s Alexa is no exception²⁰, just like a lot of other centralized, not end-to-end-encrypted services, too. The findings also caused a lot of discussion about whether messaging apps like Whatsapp and Signal are safe since their encryption was reportedly broken as well. But you need to differentiate here, because, in the case of the messaging apps, the encryption was broken by infecting only selected targeted devices with malware. Together with this news about decrypted PGP messages²¹, the published data shows that apps like Signal do indeed work as expected: They prevent third parties from mass-capturing private data and instead force them to target individual devices.

JavaScript Link

• Andrea Giammarchi shared his latest project, a lightweight virtual DOM alternative called hyperHTML²⁴²².

²³

CSS/Sass Link

• Since this week, we’re able to play around with CSS Grids in a lot more public browsers²⁶ (Chrome, Firefox, Edge with the old spec). When you do, this quite complete guide to CSS grid²⁷ might come in handy.
• Did you know you can use CSS to lint your HTML markup²⁸? Ire Aderinokun shared a couple of use cases and some very neat tricks — how to check for unlabelled form elements or inaccessible viewport attributes, for example.

²⁹

Work & Life Link

• Behavioral economist Dan Ariely wants to fix an issue that consumes an ever-expanding portion of his time: email³². He already gained a lot of insights from which everyone can profit, so it’s worth following the story a bit.
• Lots of celebrities from presidents to actors and many others recommend getting only six hours of sleep, so you have 18 hours of the day to get things done. But Sara Soueidan disagrees and shares her experiences, including dealing with burnout³³.
• We know that giving feedback is never really objective. But acknowledging our bias³⁴ before giving feedback can improve the way it will be perceived.

Going Beyond… Link

• A team around the co-inventor of Lithium-ion batteries developed the first all-solid-state battery cells³⁵ that could lead to safer, faster-charging, longer-lasting rechargeable batteries.
• Jelmer Mommers recently stumbled across a video from the oil company Shell that shows that they were aware of the dangers that global warming brings along already more than 25 years ago. Unfortunately, they decided to focus on short-term solutions nevertheless, for financial reasons. This great article shows how money can make us ignore important facts³⁶. I really believe that you and me, we can do better than Shell.

And with that, I’ll close for this week. If you like what I write each week, please support me with a donation³⁷ or share this resource with other people. You can learn more about the costs of the project here³⁸. It’s available via email, RSS and online.

— Anselm

Footnotes Link

1. 1 https://www.smashingmagazine.com/2016/10/designing-card-based-user-interfaces/
2. 2 https://www.smashingmagazine.com/2016/11/css-grids-flexbox-and-box-alignment-our-new-system-for-web-layout/
3. 3 https://www.smashingmagazine.com/2010/03/web-design-criticism-a-how-to/
4. 4 https://www.smashingmagazine.com/2015/10/dealing-with-loud-silent-burnout/
5. 5 https://blog.chromium.org/2017/02/chrome-57-beta-css-grid-layout-improved.html
6. 6 https://developer.mozilla.org/en-US/Firefox/Releases/52
7. 7 https://hacks.mozilla.org/2017/03/firefox-52-introducing-web-assembly-css-grid-and-the-grid-inspector/
8. 8 https://medium.com/samsung-internet-dev/samsung-internet-beta-now-available-without-sign-up-e0d5d4010838
9. 9 https://www.fastcompany.com/3068627/are-we-breaking-the-internet
10. 10 https://www.smashingmagazine.com/2017/03/world-wide-web-not-wealthy-western-web-part-1/
11. 11 https://uxdesign.cc/design-better-cards-c0d12ab581c4
12. 12 https://uxdesign.cc/design-better-cards-c0d12ab581c4#.dfp2dsxh2
13. 13 https://uxdesign.cc/design-better-cards-c0d12ab581c4#.dfp2dsxh2
14. 14 https://uxdesign.cc/design-better-cards-c0d12ab581c4#.dfp2dsxh2
15. 15 https://buer.haus/2017/03/08/airbnb-when-bypassing-json-encoding-xss-filter-waf-csp-and-auditor-turns-into-eight-vulnerabilities/
16. 16 http://www.csoonline.com/article/3176433/security/spammers-expose-their-entire-operation-through-bad-backups.html
17. 17 https://blog.acolyer.org/2017/03/07/thou-shalt-not-depend-on-me-analysing-the-use-of-outdated-javascript-libraries-on-the-web/
18. 18 https://wikileaks.org/ciav7p1/
19. 19 https://motherboard.vice.com/en_us/article/the-cia-spied-on-people-through-their-smart-tvs-leaked-documents-reveal?asd
20. 20 https://twitter.com/BusterUSMC/status/839489658283261952
21. 21 https://motherboard.vice.com/en_us/article/dutch-cops-say-theyve-decrypted-pgp-messages-on-seized-server
22. 22 https://medium.com/@WebReflection/hyperhtml-a-virtual-dom-alternative-279db455ee0e
23. 23 https://medium.com/@WebReflection/hyperhtml-a-virtual-dom-alternative-279db455ee0e
24. 24 https://medium.com/@WebReflection/hyperhtml-a-virtual-dom-alternative-279db455ee0e
25. 25 https://medium.com/@WebReflection/hyperhtml-a-virtual-dom-alternative-279db455ee0e
26. 26 http://caniuse.com/#search=grid
27. 27 https://tympanus.net/codrops/css_reference/grid/
28. 28 https://bitsofco.de/linting-html-using-css/
29. 29 https://tympanus.net/codrops/css_reference/grid/
30. 30 https://tympanus.net/codrops/css_reference/grid/
31. 31 https://tympanus.net/codrops/css_reference/grid/
32. 32 https://www.theatlantic.com/business/archive/2017/03/economist-email-less-painful/518934/
33. 33 https://superyesmore.com/its-not-how-many-hours-of-sleep-you-get-31511419ec81ce17835eeeb6c1a570a5
34. 34 https://www.fastcompany.com/3068689/the-science-of-work/your-feedback-will-always-be-biased-but-heres-what-to-do-about-it
35. 35 https://news.utexas.edu/2017/02/28/goodenough-introduces-new-battery-technology
36. 36 https://thecorrespondent.com/6311/shell-took-a-good-long-look-at-climate-change-and-then-went-back-to-looking-for-oil/2244455904680-2a618a43
37. 37 https://wdrl.info/donate
38. 38 https://wdrl.info/costs/

↑ Back to topTweet itShare on Facebook

What would life be without surprises? Pretty plain, wouldn’t you agree? Today, we are happy to announce a freebie that bubbles over with its friendly optimistic spirit, bound to sprinkle some unexpected sparks of delight into your projects: Ballicons 3. If that name rings a bell, well, it’s the third iteration of the previous Ballicons icon set¹ created by the folks at Pixel Buddha¹⁹¹⁸².

This icon set covers a vibrant potpourri of subjects, 30 icons ranging from nature, travel and leisure motifs to tech and office. All icons are available in five formats (AI, EPS, PSD, SVG, and PNG) so you can resize and customize them until they match your project’s visual style perfectly. No matter if you like it bright and bubbly or rather sleek and simple — the set has the makings to become a real allrounder in your digital tool belt.

³

Please note that this icon set is released under a Creative Commons Attribution 3.0 Unported⁵ license. This means that you may modify the size, color and shape of the icons. No attribution is required, however, reselling of bundles or individual icons is not cool. If you want to spread the word in blog posts or anywhere else, feel free to do so, but please remember to credit the designers and provide a link to this article.

Further Reading on SmashingMag: Link

• Easy Steps To Better Icon Design⁶
• Icons As Part Of A Great User Experience⁷
• Icon Design Tutorial: Drawing A Pencil Icon⁸
• How To Create Icons In Adobe XD⁹

A Closer Look At Some Of The Icons Link

¹⁰

¹²

Full Preview Of The Icon Set Link

¹⁴

Insights From The Designers Link

“Creation of icons is something special for our team, as it’s our first icon set which made us refuse from client work and concentrate on crafting content for other specialists. Ballicons and Ballicons 2 have become really popular, and today, after 2.5 years we’ve realized we’re willing to present another iteration of the icons from this series — even more striking and interesting.”

Download the Icon Set for Free Link

• Download the Ballicons 3 Set (30 Icons, EPS, SVG)¹⁶ (.zip, 2.7 MB)
• See the full Ballicons 3¹⁷ icon set on Pixel Buddha¹⁹¹⁸²‘s official website.

A big thank you to the folks at Pixel Buddha¹⁹¹⁸² for designing this wonderful icon set — we sincerely appreciate your time and efforts! Keep up the brilliant work!

Footnotes Link

1. 1 https://www.smashingmagazine.com/2014/06/freebie-ballicons-2-icon-set-png-psd-svg/
2. 2 https://pixelbuddha.net/
3. 3 https://www.smashingmagazine.com/wp-content/uploads/2017/02/ballicons-full-preview-1000px-opt.png
4. 4 https://www.smashingmagazine.com/wp-content/uploads/2017/02/ballicons-full-preview-1000px-opt.png
5. 5 https://creativecommons.org/licenses/by/3.0/
6. 6 https://www.smashingmagazine.com/2016/05/easy-steps-to-better-logo-design/
7. 7 https://www.smashingmagazine.com/2016/10/icons-as-part-of-a-great-user-experience/
8. 8 https://www.smashingmagazine.com/2008/06/icon-design-tutorial-drawing-a-pencil-icon/
9. 9 https://www.smashingmagazine.com/2016/07/how-to-create-icons-adobe-xd/
10. 10 https://www.smashingmagazine.com/wp-content/uploads/2017/02/ballicons-full-preview-1000px-opt.png
11. 11 https://www.smashingmagazine.com/wp-content/uploads/2017/02/ballicons-full-preview-1000px-opt.png
12. 12 https://www.smashingmagazine.com/wp-content/uploads/2017/02/ballicons-full-preview-1000px-opt.png
13. 13 https://www.smashingmagazine.com/wp-content/uploads/2017/02/ballicons-full-preview-1000px-opt.png
14. 14 https://www.smashingmagazine.com/wp-content/uploads/2017/02/ballicons-full-preview-1000px-opt.png
15. 15 https://www.smashingmagazine.com/wp-content/uploads/2017/02/ballicons-full-preview-1000px-opt.png
16. 16 http://provide.smashingmagazine.com/Freebies/smashing-freebie-ballicons3-icon-set.zip
17. 17 https://pixelbuddha.net/ballicons3/
18. 18 https://pixelbuddha.net/
19. 19 https://pixelbuddha.net/

↑ Back to topTweet itShare on Facebook

The past year has seen quite a rise in UI design tools. While existing applications, such as Affinity Designer¹, Gravit² and Sketch³, have improved drastically, some new players have entered the field, such as Adobe XD⁷⁵⁴ (short for Adobe Experience Design) and Figma²⁵⁵.

For me, the latter is the most remarkable. Due to its similarity to Sketch, Figma was easy for me to grasp right from the start, but it also has some unique features to differentiate it from its competitor, such as easy file-sharing⁶, vector networks⁷, “constraints⁴⁶⁸” (for responsive design) and real-time collaboration⁹.

In this article, I’d like to compare both apps in detail and highlight where each of them shines.

Further Reading on SmashingMag: Link

• Using Sketch For Responsive Web Design (A Case Study)¹⁰
• Designing A Responsive Music Player In Sketch¹¹
• Exploring Repeat Grid In Adobe XD¹²
• Designing With Real Data In Sketch Using The Craft Plugin¹³

Platform Link

The greatest weakness of Sketch has always been its lock-in to the Apple ecosystem. You need a Mac not only to design with it but also to open and inspect files. If you are on Windows or Linux, you’re out of luck. (Technically, you could get Sketch running on Windows, as Martijn Schoenmaker¹⁴ and Oscar Oto Mir¹⁵ describe, but it might not be worth the hassle for some.) That’s why, over time, a few paid services¹⁶ have emerged that enable you to provide teammates with specifications of Sketch files, but that’s still an unfortunate extra step.

¹⁷

That’s probably one of the reasons why Figma took a different route right from the start: It can be used right in your web browser, on basically any device in the world. No installation whatsoever needed: Just open Chrome (or Firefox), set up an account and start designing. While I’ve been hesitant with browser-based tools before, Figma blew my doubts away in a single stroke. It’s as performant as Sketch (if not more), even with a multitude of elements on the canvas.

Even standalone desktop apps of Figma for Windows and Mac are available, but basically, they are no more than wrappers of the browser version. While they give you better support for keyboard shortcuts, they don’t save you from having to be online all the time.

Winner: Figma

Why: It is platform-independent.

Usability (Features And User Interface) Link

Basically, Figma can be best described as an in-browser version of Sketch. It offers mostly the same features, the interface looks similar, and even the keyboard shortcuts are mostly taken from its competitor. If you knew Sketch already, you could have easily found your way around Figma when it was released at the beginning of 2016.

Figma has improved on many aspects since then, and has even surpassed Sketch in parts, but some features are still missing, such as plugins⁸³¹⁹, integration with third-party tools²⁰ and the ability to use real data²¹ (with the help of the Craft plugin). Nevertheless, at the pace Figma is improving, it may be just a matter of time before it’s on par with Sketch.

Winner: A draw

Why: At the moment, they don’t differentiate enough. But still, Sketch is more mature, offers more odds and ends to make you more productive.

Pricing Link

Sketch initially started with a one-time fee of around $99 USD for each new major version. But having finally realized that this business model is not sustainable, Bohemian Coding has recently changed its pricing to a kind of subscription-based model: For $99 USD, you get one year of free updates. After that, you can keep using the app as is or invest the same amount of money to get another year of updates.

This price increase might seem inappropriate at first, but what’s $99 for your main tool as a designer? Right, not much, and still cheaper than Adobe’s Creative Cloud²² subscription price. (Also, note that when you stop paying for your Creative Cloud subscription, you cannot keep using any of the Adobe CC apps, whereas your existing version of Sketch will continue running with no problems at all.)

For the time being, Figma is still free to use for everybody, but that might change later this year. I’d bet that it will also be subscription-based, with a monthly fee of around $10 to $15 USD (don’t hold me to that, though). One thing’s for sure: Figma will always be free for students²³ (similar to how Sketch offers a reasonable discount²⁴ to students and teachers).

Winner: A draw

Why: No word yet on the pricing of Figma.

Collaboration Features Link

The main differentiator of Figma is probably the real-time collaboration feature, called “multiplayer.” It allows a user not only to edit a file at the same time as others but also to watch somebody else fiddle around in a design and communicate changes with the built-in commenting system. For one, this simultaneous editing is great for presentations and remote teams, but it also ensures that everyone involved sees the same state, and it prevents unintended overwrites.

Sketch doesn’t offer anything like that (not even with the help of plugins), and it’s probably the better for it. Designers are skeptical of this feature, and rightly so, because it can lead to the dreaded “design by committee” and to a mentality of “Make this button bigger. No, wait! I’ll just do it by myself!” Of course, I’m exaggerating a bit here. This feature can be somewhat valuable, but it has risks if you don’t set certain rules up front.

Winner: Figma

Why: Allows multiple people to work on the same file at the same time.

File Sharing and Spec’ing Link

Somewhat related to real-time collaboration is the sharing of design files. Because everything in Figma happens in the browser, every file naturally has a URL that you can send to your peers and bosses (in view-only mode, too). Another huge advantage of this browser-based approach is that everybody, developers foremost, can open a design and inspect it right away, with no third-party tool needed.

²⁶

That’s exactly what you need in Sketch in order to offer teammates all of the necessary information on a file, such as font sizes, colors, dimensions, assets and so on. However, as mentioned, to help you here, you’ll need paid tools such as Zeplin²⁸, Sympli²⁹, InVision’s Inspect³⁰, Avocode³¹ or Markly³². To be fair, the first three are free for a single project, but that might not be enough when you’re working on more complex stuff.

If you need more or don’t want to invest money in such (admittedly basic) functionality, there are also the free plugins Marketch³³ and Sketch Measure³⁴. Many paid apps also allow you to add comments and create style guides automatically.

Alternatively, you could even import your Sketch files into Figma and inspect them there, because Figma supports the Sketch file format.

³⁵

If you just need to let your teammates have a look at a design, then the built-in Sketch Cloud³⁸ does exactly that. To view a design on your iOS device, you have Sketch Mirror³⁹ and Figma Mirror⁴⁰; for an Android device, you can use Mira⁴¹ and Crystal⁴². Figma doesn’t offer an Android-based app, but opening www.figma.com/mobile-app⁴³ on the device after selecting a frame or component (on your desktop computer) will give you a kind of preview.

Winner: Figma

Why: Files are easily shareable, right in the browser, without the need for a third-party tool.

Organizing Files Link

Thanks to the organizational capabilities that Sketch gives with its pages, you can design an entire app or website in a single file, and switch between its pages quickly. Figma is left behind here: It doesn’t provide pages, but you can at least combine files into a project.

⁴⁴

Another important concept of Sketch — artboards — has been taken on as well, but in an enhanced form. In Figma, you can apply fills, borders and effects to artboards, and they can also be nested and be easily created from groups. For one, this allows for containers of elements that are bigger than their combined bounds, which can be helpful for the “constraints⁴⁶⁸” functionality. Furthermore, each artboard can have its own nested layout grid, which helps with responsive design.

It’s worth mentioning that Sketch also allows you to nest artboards, but the implementation is not nearly as powerful as Figma’s.

Winner: A draw

Why: Sketch has pages, but Figma’s artboards (frames) are more powerful.

Responsive Design Link

A feature that Figma introduced (and that Sketch followed with months later) is responsive design, or the ability to set how elements respond to different artboard or device sizes. There have been plugins that offer such functionality in Sketch, but they’ve always felt a bit clunky. Only the native “group resizing⁴⁷” feature has been easy to use, competing with Figma’s “constraints” feature.

⁴⁸

They do basically the same thing but are very different in execution. In Sketch, you just have a dropdown menu with four options, and it can be a bit hard to imagine what they do. Figma offers a more visual way to define these properties; for example, to pin an element to the edge of an artboard or to let it resize proportionally.

A huge advantage of Figma is that these constraints work in combination with layout grids. Elements can be pinned to certain columns (or rows), for example, or take on their relative width. Furthermore, you are able to change these settings independently for each axis, and they work not only for groups but also for artboards. None of that is possible in Sketch.

Winner: Figma

Why: Its constraints functionality is far more advanced and offers more options.

Vector Manipulation Link

One major feature of Figma when it was released was “vector networks.” No longer is a vector just a sequence of connected points (nodes). Now, you can easily branch off from any node with a new line. Creating an arrow, for example, is as easy as pie.

⁵²

But there’s much more to it. Parts of a vector can be easily filled (or removed) with the Paint Bucket tool. You can move entire segments (or bend them) with the help of the Bend tool. And copying lines (as well as points) from one vector to another is a snap.

⁵³

This feature alone sets Figma apart from Sketch in a very special way and makes it so much more suitable for icon design. Compared to it, the tools available in Sketch feel almost archaic. While Sketch might have everything you’ll ever need to create and manipulate vector objects, as soon as more complex vector operations are involved, it can get a bit too tricky.

⁵⁴

While most of the time you’ll need to use Boolean operations⁵⁵ to create certain types of shapes in Sketch, much of that can be achieved more easily with vector networks in Figma. The fact that in Sketch it’s often hard to join two vector objects or even flatten a shape after a Boolean operation has been applied makes things even worse — the app certainly has a lot of ground to cover in this regard.

Winner: Figma

Why: Vector networks give a whole new dimension to vector manipulation, something still unmatched in Sketch.

Supported File Types Link

Whenever a new application appears, you often face the problem of having to redo everything if you want to migrate a project. Not so in Figma: It can open Sketch files in an impressively accurate way, which gives it an immediate advantage.

Unfortunately, it doesn’t work in the other direction. Once you start designing in Figma, you are bound to it. It can’t export back to Sketch, nor is it capable of creating PDF files (or importing them). There is an option to export to SVG, but that’s not the ideal format in which to exchange complex files between design applications.

⁵⁶

Another limiting factor is that you can’t set the quality level when exporting JPG images in Figma, so you might need a separate application to optimize images. The latest version of Sketch improves the exporting options even further. It allows you to set both a prefix and a suffix for file names now, as well as provides exporting presets, which makes exporting for Android much easier.

Let’s look at the export file formats that each application supports.

Sketch:

• PNG
• JPG
• TIFF
• WebP
• PDF
• EPS
• SVG

Figma:

• PNG
• JPG
• SVG

Winner: Sketch

Why: More file formats, and better saving and exporting options.

Accessibility Link

Though Figma shares many keyboard shortcuts with Sketch, it doesn’t have the same level of accessibility. In Sketch, almost everything can be achieved with a key press. And if you are not satisfied with a certain shortcut combination, you can set your own in the system’s preferences (which largely goes for shortcut commands not assigned by default).

Note: You can learn how to change shortcuts in Sketch in the article “Set Custom Keyboard Shortcuts⁵⁸,” published on SketchTips.

⁵⁹

Because Figma lives in the browser, none of that is possible. While the desktop app makes up for it, certain functions simply can’t be assigned to the keyboard due to a lack of certain menu bar commands.

Winner: Sketch

Why: Almost all features in the application are accessible with keyboard shortcuts, and they can be customized.

Symbols (Components) Link

An important feature has only just been introduced to Figma: symbols, or, as they are called there, components. Components allow you to combine several elements into a single compound object that can be easily reused in the form of “instances.” As soon as the master component is changed, all instances inherit the change. (However, certain properties can still be modified individually, allowing for variations of the same component.)

Lately, it’s even possible to create a library of components in Figma, that can be shared across files and with multiple users — a huge step towards a robust design system.

In Sketch, the modifications of individual instances are handled in the form of overrides in the Inspector panel, allowing you to change text values, image fills and nested symbols separately for each instance. Figma lets you update the properties of an element directly on the canvas, including the fill, border and effects (shadows, blurs).

⁶¹

The true strength of symbols (and components) becomes evident with responsive design. In both apps, you can define how elements within a symbol react when their parent is resized, making it possible to use symbols in different places or screen sizes.

An area where Figma is still behind is layer⁶³ and text styles⁶⁴. You can’t save the styling of shapes or text layers and sync it with other elements. What you can do, however, is copy and paste the styling from one element to another.

Winner: A draw

Why: The implementations are quite comparable, but Figma has a slight advantage with its shareable components.

Plugins Link

Sketch is undeniably great and capable out of the box, but what makes it really awesome are the third-party plugins, which either enhance Sketch or make up for missing features. You can use them to rename multiple layers⁶⁵ at once, create dynamic buttons⁶⁶, save and load color palettes⁶⁷, easily insert images⁶⁸ from Unsplash, enable Git functionality⁶⁹ and create animations⁷⁰ right in Sketch, just to name a few. A full list of plugins can be found in the official directory⁷¹ and on GitHub⁷².

⁷³

Then there’s Figma, which has none of that up until now. To be fair, Sketch probably didn’t offer many of these helpers early on in its development, and I’d bet that a plugin ecosystem will be introduced to Figma in the future.

A word of caution: While plugins give Sketch a huge advantage, they can be somewhat of a pitfall, too. They tend to break with each new release, and the Sketch team needs to be very cautious to avoid alienating developers in the future.

Winner: Sketch

Why: It’s simple: Figma doesn’t have plugins at all.

Prototyping Link

Unlike Adobe XD⁷⁵⁴, neither Sketch nor Figma has any native prototyping capabilities. There are no plans for the latter so far, but Sketch has the Craft plugin⁸⁴⁷⁶, which brings at least basic prototyping functionality. Furthermore, Sketch’s popularity has led to broad integration with other prototyping tools: InVision⁷⁷, Marvel⁷⁸, Proto.io⁷⁹, Flinto⁸⁰, and Framer⁸¹, to name a few. The idea with these is that you can easily import a design and sync up the apps.

The only application that works with Figma so far is Framer⁸². It’s hard to say what support for similar tools will look like in the future, but it may well be that such interfaces are already in the works.

Winner: Sketch

Why: Though the Craft plugin doesn’t provide persuasive prototyping capabilities, Sketch is well integrated with many prototyping services.

Working With Real Data Link

Among the countless plugins⁸³¹⁹ that Sketch offers, you will also find some so-called “content generators.” For one, they let you fill a design with dummy content. But what’s even more interesting is that these little helpers enable you to pull in real data from various sources, or even insert content in the form of JSON files. This allows you to make more informed decisions and account for edge cases early in the design process.

By far, the best in this category is the Craft plugin⁸⁴⁷⁶ from InVision. As soon as you use it to populate an element with content, you can easily duplicate and vary it in a single step. Craft also allows you to save design assets and share them with your team, or to create a style guide automatically. For an in-depth look at the Craft plugin, have a look at my recent article “Designing With Real Data In Sketch Using The Craft Plugin⁸⁵.”

⁸⁶

Though not as sophisticated as Craft, a few more plugins with similar functionality exist: Sketch Data Populator⁸⁷, Content Generator⁸⁸ and Day Player⁸⁹.

Figma doesn’t offer such functionality yet, but I think it’s just a matter of time. It will be interesting to see which approach it takes: integrating it in the app, as Adobe XD teased some time ago⁹⁰, or relying on a plugin system.

Winner: Sketch

Why: Compensating for a lack of native functionality, various plugins allow you to use real data in Sketch easily.

Versioning Link

One thing I constantly do is undo my changes one by one with Command + Z to see what an earlier version of a design looks like — either to have a point of reference or to duplicate as a base for a new iteration. You might suppose that Figma is at a dead end here because of the browser’s limited resources, but in reality it is in no way inferior to Sketch.

Both apps save automatically, with the ability to browse and restore old versions. Sketch’s implementation, however, is far from ideal, and I don’t even know where to start. It’s laggy; you need to restore a version before you can actually inspect it; and it can lead to wasted space on the hard drive. (If you encounter this problem, Thomas Degry’s article “How Sketch Took Over 200GB of Our MacBooks⁹¹” might help.) To cap it off, things can get screwed up pretty quickly when multiple people are working on the same file in the cloud (via Dropbox, etc.).

Figma lets you restore previous versions instantaneously, which is especially useful if multiple people are editing the same file, helping you to isolate the changes of each person. You can then jump back to a previous state or duplicate the version as the starting point for a new idea.

Winner: Figma

Why: Sketch’s versioning is so imperfect that the winner is obvious.

Text Features Link

As in other regards, the handling of text is quite similar in both applications, but some differences are worth mentioning. By default, Figma just gives you Google Fonts to choose from, but with a simple installer, you can access system fonts, too.

Something I constantly miss in Sketch is the ability to change the border position of text layers; “center” is the only option here. Figma also offers “inside” and “outside,” like it does for the shape layers.

⁹²

Furthermore, Figma lets you set the vertical alignment of text, allowing for easy vertical centering inside the frame. In contrast, Sketch has more typography options and enables you to apply OpenType features such as small caps, old-style figures, stylistic alternatives and ligatures (if a font supports them).

Winner: A draw

Why: Both applications have their distinct advantages. Sketch might be ahead a bit, due to its advanced typography options, but not enough to win outright.

Useful Resources And Further Reading Link

Sketch has been on the market now for over six years, which has allowed the community to accumulate a huge number of useful resources (articles, tutorials, blog posts, etc.). And due to the similarities between the two apps, some Sketch concepts can be applied to Figma, which makes some resources suitable for both applications. I’ll mention only a few here:

• SketchTips⁹⁴
  My very own project, where I regularly publish articles about Sketch.
• Documentation⁹⁵, Sketch
• Sketch Facebook group⁹⁶
• Sketch App Sources⁹⁷
• Design + Sketch⁹⁸, Medium
• Sketch Tricks⁹⁹
• Sketch Talk¹⁰⁰
• Sketch Hunt¹⁰¹
• Sketch App Rocks¹⁰²
• Figma help¹⁰³ (documentation)
• Figma Facebook group¹⁰⁴
• Figma: Daily Curated Collection of Articles and Resources¹⁰⁵, Heydon Pickering

Conclusion Link

Let’s quickly recap each app’s strengths.

Where Sketch Shines Link

• Keyboard accessibility is better supported.
• Plugins and a plugin ecosystem exist.
• Third-party tools and services can be integrated.
• File types and exporting options are richer.
• A complex project can be contained in a single file (with pages).
• Real data can be easily used in Sketch.
• The app is more mature.

Where Figma Shines Link

• Being browser-based, it’s usable from anywhere in the world, on any platform.
• Collaboration in real time.
• File sharing is easy.
• Vector manipulation is excellent (via vector networks).
• Responsive design options are better (via constraints).
• A library of components can be created and shared with your team members.
• Artboards are more powerful.

The Future Link

The discontinuation of Adobe Fireworks in 2013 left a huge gap¹⁰⁶ in the world of UI design tools — a gap that Sketch gladly filled almost immediately¹⁰⁷. Sketch became so successful that it closed in on its main competitor, Photoshop, over time and even topped it last year as the tool of choice¹⁰⁸ among user interface designers.

Sketch would probably be even more successful if there was a Windows version, though, a problem with other tools, too. So, Affinity Designer and Adobe XD (two new competitors that started as Mac-only apps) quickly stretched out to support Windows as well. There is also Gravit Designer, which works in the browser¹⁰⁹ and which now also exists as a desktop app¹¹⁰ (for Windows, Mac and Linux); but like Affinity Designer and Adobe XD, it’s hard for it to compete with Sketch, which is probably the most mature tool of them all at the moment.

And now we have Figma¹¹¹: Not only is its feature set similar to Sketch’s, but it supports multiple platforms because the only thing you needed to run it is a modern browser. Moreover, Figma allows you to open Sketch files, which means you can basically continue in Figma where you’ve left off in Sketch, without much effort. (Figma requires you to be signed in and online to use it, though, a serious limitation¹¹² in some cases.)

But as different as all of these tools are, they all have one thing in common: They want a slice of the pie, and so they are challenging Sketch in every possible way. But the Sketch team isn’t resting on its laurels. It is constantly improving the application and pushing new updates often, with the goal of making it the best possible UI design tool out there. So far, they are succeeding, but the pressure is growing.

(mb, al, il)

Footnotes Link

1. 1 https://affinity.serif.com/designer/
2. 2 https://gravit.io/
3. 3 https://www.sketchapp.com/
4. 4 http://www.adobe.com/products/experience-design.html
5. 5 https://www.figma.com/
6. 6 #file-sharing-and-specing
7. 7 #vector-manipulation
8. 8 #responsive-design
9. 9 #collaboration-features
10. 10 https://www.smashingmagazine.com/2015/04/using-sketch-for-responsive-web-design-case-study/
11. 11 https://www.smashingmagazine.com/2017/01/designing-responsive-music-player-sketch-part-1/
12. 12 https://www.smashingmagazine.com/2016/11/exploring-repeat-grid-in-adobe-xd/
13. 13 https://www.smashingmagazine.com/2017/02/design-with-real-data-sketch-using-craft-plugin/
14. 14 https://medium.com/sketch-app-sources/how-i-started-using-sketch-app-in-windows-756e7091b0bc
15. 15 https://blog.prototypr.io/three-reasons-why-my-windows-adobe-team-moved-from-adobe-to-sketch-2ecf5fdd45d6
16. 16 #file-sharing-and-specing
17. 17 https://www.smashingmagazine.com/wp-content/uploads/2017/02/screenshot1-large-opt.png
18. 18 https://www.smashingmagazine.com/wp-content/uploads/2017/02/screenshot1-large-opt.png
19. 19 #plugins
20. 20 #prototyping
21. 21 #working-with-real-data
22. 22 https://creative.adobe.com/plans
23. 23 https://www.figma.com/education
24. 24 https://www.sketchapp.com/store/edu/
25. 25 https://www.figma.com/
26. 26 https://www.smashingmagazine.com/wp-content/uploads/2017/02/screenshot3-large-opt.png
27. 27 https://www.smashingmagazine.com/wp-content/uploads/2017/02/screenshot3-large-opt.png
28. 28 https://zeplin.io
29. 29 https://sympli.io/
30. 30 http://blog.invisionapp.com/inspect-design-development-workflow/
31. 31 https://avocode.com/
32. 32 http://marklyapp.com/
33. 33 https://github.com/tudou527/marketch
34. 34 https://github.com/utom/sketch-measure
35. 35 https://www.smashingmagazine.com/wp-content/uploads/2017/02/screenshot4-large-opt.png
36. 36 https://www.smashingmagazine.com/sketch-handbook/
37. 37 https://www.smashingmagazine.com/wp-content/uploads/2017/02/screenshot4-large-opt.png
38. 38 https://www.sketchapp.com/learn/documentation/sketch-cloud/
39. 39 https://itunes.apple.com/us/app/sketch-mirror/id677296955?mt=8
40. 40 https://itunes.apple.com/us/app/figma-mirror/id1152747299?mt=8
41. 41 http://mirapp.io/
42. 42 https://play.google.com/store/apps/details?id=com.smithyproductions.crystal
43. 43 https://www.figma.com/mobile-app
44. 44 https://www.smashingmagazine.com/wp-content/uploads/2017/02/screenshot5-large-opt.png
45. 45 https://www.smashingmagazine.com/wp-content/uploads/2017/02/screenshot5-large-opt.png
46. 46 #responsive-design
47. 47 https://www.smashingmagazine.com/2017/01/designing-responsive-music-player-sketch-part-2/#from-fixed-to-fluid
48. 48 https://www.smashingmagazine.com/wp-content/uploads/2017/02/screenshot6-large-opt.png
49. 49 https://www.smashingmagazine.com/wp-content/uploads/2017/02/screenshot6-large-opt.png
50. 50
51. 51 https://www.smashingmagazine.com/2017/01/designing-responsive-music-player-sketch-part-1/
52. 52 https://www.smashingmagazine.com/wp-content/uploads/2017/03/vector-networks-figma.gif
53. 53 https://www.smashingmagazine.com/wp-content/uploads/2017/03/segments-easily-moved-and-bent.gif
54. 54 https://www.smashingmagazine.com/wp-content/uploads/2017/03/figma-removing-fill.gif
55. 55 https://www.sketchapp.com/learn/documentation/shapes/boolean-operations/
56. 56 https://www.smashingmagazine.com/wp-content/uploads/2017/02/screenshot11-large-opt.png
57. 57 https://www.smashingmagazine.com/wp-content/uploads/2017/02/screenshot11-large-opt.png
58. 58 http://www.sketchtips.info/articles/custom-shortcuts
59. 59 https://www.smashingmagazine.com/wp-content/uploads/2017/02/screenshot12-large-opt.png
60. 60 https://www.smashingmagazine.com/wp-content/uploads/2017/02/screenshot12-large-opt.png
61. 61 https://www.smashingmagazine.com/wp-content/uploads/2017/02/screenshot13-large-opt.png
62. 62 https://www.smashingmagazine.com/wp-content/uploads/2017/02/screenshot13-large-opt.png
63. 63 https://www.sketchapp.com/learn/documentation/styling/shared-styles/
64. 64 https://www.sketchapp.com/learn/documentation/text/text-styles/
65. 65 https://github.com/rodi01/RenameIt
66. 66 https://github.com/ddwht/sketch-dynamic-button
67. 67 https://github.com/andrewfiorillo/sketch-palettes
68. 68 https://github.com/fhuel/unsplash-it-sketch
69. 69 https://github.com/mathieudutour/git-sketch-plugin
70. 70 http://animatemate.com/
71. 71 https://sketchapp.com/extensions/plugins/
72. 72 https://github.com/sketchplugins/plugin-directory
73. 73 https://www.smashingmagazine.com/wp-content/uploads/2017/02/screenshot14-large-opt.png
74. 74 https://www.smashingmagazine.com/wp-content/uploads/2017/02/screenshot14-large-opt.png
75. 75 http://www.adobe.com/products/experience-design.html
76. 76 https://www.invisionapp.com/craft
77. 77 https://www.invisionapp.com/craft
78. 78 https://marvelapp.com/prototype-with-sketch
79. 79 https://proto.io/en/new-features/photoshop-and-sketch-plugins/
80. 80 https://www.flinto.com/mac_sketch_plugin
81. 81 https://framer.com/getstarted/import/
82. 82 https://blog.framerjs.com/posts/import-with-figma.html
83. 83 #plugins
84. 84 https://www.invisionapp.com/craft
85. 85 https://www.smashingmagazine.com/2017/02/design-with-real-data-sketch-using-craft-plugin/
86. 86 https://www.smashingmagazine.com/wp-content/uploads/2017/03/sketch-duplicating-elements.gif
87. 87 https://github.com/preciousforever/sketch-data-populator
88. 88 https://github.com/timuric/content-generator-sketch-plugin
89. 89 https://github.com/tylergaw/day-player
90. 90 https://medium.com/@anirudhs/project-comet-designing-with-real-data-959beccb5c1a#.3iz4x4e5h
91. 91 https://medium.com/@thomasdegry/how-sketch-took-over-200gb-of-our-macbooks-cb7dd10c8163#.uoufoz23m
92. 92 https://www.smashingmagazine.com/wp-content/uploads/2017/02/Screenshot16-large-opt.png
93. 93 https://www.smashingmagazine.com/wp-content/uploads/2017/02/Screenshot16-large-opt.png
94. 94 http://sketchtips.info
95. 95 https://sketchapp.com/learn/documentation/
96. 96 https://www.facebook.com/groups/sketchformac
97. 97 https://www.sketchappsources.com/
98. 98 https://medium.com/sketch-app-sources
99. 99 http://sketchtricks.com
100. 100 http://sketchtalk.io
101. 101 http://sketchhunt.com
102. 102 http://sketchapp.rocks
103. 103 https://help.figma.com/
104. 104 https://www.facebook.com/groups/figma/
105. 105 http://heydesigner.com/figma/
106. 106 https://www.smashingmagazine.com/2013/12/present-future-adobe-fireworks/
107. 107 https://medium.com/habit-of-introspection/the-past-present-and-future-of-sketch-d5237879b7af#.lqrnygtug
108. 108 http://tools.subtraction.com/interface-design.html
109. 109 https://www.smashingmagazine.com/2016/04/exploring-a-new-illustration-ui-design-app-gravit/
110. 110 http://designer.io/
111. 111 https://medium.com/@mengto/figma-vs-sketch-c01e5e74eddd
112. 112 https://www.quora.com/How-does-Figma-compare-to-Sketch

↑ Back to topTweet itShare on Facebook