Inspired Design Decisions: Alexey Brodovitch

dreamt up by webguru in Uncategorized | Comments Off on Inspired Design Decisions: Alexey Brodovitch

Inspired Design Decisions: Alexey Brodovitch

Inspired Design Decisions: Alexey Brodovitch

Andrew Clarke



Before writing Art Direction for the Web, I began to study Alexey Brodovitch when I became fascinated by editorial and magazine design. I was drawn to his precision, in particular, the way Brodovitch brought photographs and text together.

Then, I became intrigued by his design process, how he sketched layouts, arranged them into spreads, and created a rhythm which flowed through his magazines. Later, I appreciated his rebellious rejection of anything he considered mediocre. I still love the advice he gave his students to look beyond his medium to inspiration from other forms of art, architecture, and design.

I like to think I share a little of Brodovitch’s rebelliousness, because I want to develop the web into a creative medium, rather than as merely a platform for products. An innovative approach to website design matters because it creates more engaging experiences and attractive visual designs. Those things can help our digital products and websites appeal to audiences and communicate better. In practical terms, better communication teaches how to use a product. It also helps them to understand why they should choose that product. This approach aids editorial, marketing, and news to communicate, and is crucial to developing an affinity between a brand and its audience.

There are few books currently available on Alexey Brodovitch’s work, the most definitive being Kerry William Purcell’s 2011 “Alexey Brodovitch.”

This monograph contains collections from throughout Brodovitch’s life, most interesting to me are his designs for Harper’s Bazaar magazine, some of which I’ll explore in this issue. This book will make a fabulous addition to your design collection.

  1. Inspired Design Decisions: Avaunt Magazine
  2. Inspired Design Decisions: Pressing Matters
  3. Inspired Design Decisions: Ernest Journal
  4. Inspired Design Decisions: Alexey Brodovitch

Inspired by Alexey Brodovitch

© 2019 Henri Cartier-Bresson/Magnum Photos, 
courtesy Fondation Henri Cartier-Bresson, Paris. (Large preview)

Alexey Brodovitch was born in Russia in 1898. As a young man, Brodovitch fought in the White Army again the Bolsheviks during the Russian Civil War, which wasn’t the start in life I’d expected for someone who went on to become one of the most influential art directors of the twentieth century.

Forced into exile, Brodovitch moved to Paris where — while working as a scene painter — he met artists including Marc Chagall and was exposed to movements including Bauhaus, Constructivism, Dadaism, and Futurism.

A selection of Harper’s Bazaar magazine covers 1937–1939. Art direction by Alexey Brodovitch. Various artists. (Large preview)
Constructivism

Whereas autonomous art was driven by the subconscious, and painters like Wassily Kandinsky and Joan Miro suppressed conscious control of the painting process, the constructivist movement sought to consciously and deliberately construct art.

This meant deliberately placing lines and shapes using geometry. The results were often striking, which lead to constructivism’s use in political art and propaganda. Constructivism influenced artists and designers throughout the twentieth century, including Neville Brody, who’s work on The Face Magazine I’ll cover later in this series.

Alexander Rodchenko

Seven years his senior, Alexander Rodchenko was a significant influence on Brodovitch and generations of artists, graphic designers, and photographers. Rodchenko was one of the founders of the constructivist movement.

A Yankee in Petrograd series by Aleksandr Rodchenko 1924. (Large preview)

In order to educate man to a new longing, everyday familiar objects must be shown to him with totally unexpected perspectives and in unexpected situations.

— Alexander Rodchenko

Photomontage — the technique of cutting and rearranging multiple images into a new work — was popular in Constructivism. This approach to composition inspired Brodovitch throughout his life, where he became renowned for the way he deliberately and precisely brought photography and typography together.

When Brodovitch began working part-time designing layouts for Cahiers d’Art — a contemporary art journal — and the influential design magazine Arts et Métiers Graphiques, he refined his techniques, creating striking magazine and poster designs. After beating Pablo Picasso into second place in a poster competition, Brodovitch established his own design studio and while still in his thirties became one of the most respected commercial artists in Paris.

Disillusioned by the art scene in Paris, in 1930 Brodovitch moved to the United States where he taught advertising design at what is today the Philadelphia University of the Arts. His goal was to develop American advertising to the level of design in Europe. He exposed his students to French and German magazines and taught them to reexamine their techniques. In the spirit of the Bauhaus School, Brodovitch took his students outside the classroom to find inspiration elsewhere, encouraging them to find their own creative style.

Brodovitch was “intolerant of mediocrity” and frequently asked his students to “astonish me.” Brodovitch’s courses focussed on design and photography in equal measure, so as well as influencing a generation of art directors and graphic designers, he taught photographers including Diane Arbus and Richard Avedon. He’d work with them later at Harper’s Bazaar magazine.

Brodovitch was asked by The Art Directors Club of New York to design their 1934 Annual Art Directors Exhibition. There, Carmel Snow — who at the time was editor-in-chief at the US edition of Harper’s Bazaar magazine — saw Brodovitch’s work for the first time. She said:

I saw a fresh, new conception of layout technique that struck me like a revelation: pages that “bled” beautifully cropped photographs, typography and design that were bold and arresting.

— Carmel Snow (The World of Carmel Snow. McGraw-Hill, 1962)

Astonish me

Harper’s Bazaar became Brodovitch’s most well-known project. Determined to keep his designs fresh, he frequently commissioned work from European artists including Jean Cocteau, Marc Chagall, and Man Ray. To keep Harper’s Bazaar readers surprised, Brodovitch explained:

Surprise quality can be achieved in many ways. It may be produced by a certain stimulating geometrical relationship between elements in the picture, or through the human interest of the situation photographed, or by calling our attention to some commonplace but fascinating thing we have never noticed before, or it can be achieved by looking at an everyday thing in a new interesting way.

— Alexey Brodovitch

‘Fine Figger of a Woman.’ Spread from Harper’s Bazaar, November 1934.(Large preview)

It’s Brodovitch’s art direction for Harper’s Bazaar which has influenced designers since the 1940s. His designs were elegant, something Carmel Snow once described as “good taste, plus a dash of daring.” His knowledge of photography gave his work its classic feel. Brodovitch often cropped photographs in unexpected ways, and he placed them off-centre — sometimes bleeding them outside the margins of a page — to create compositions which were full of energy and movement.

One of Brodovitch’s sketches for a Harper’s Bazaar layout, 1940–50. (Large preview)

Throughout his career at Harper’s Bazaar and beyond, Brodovitch frequently used content in photographs or illustrations to inform his placement and shape of the text. His colour choices were often bold, and he used large blocks of colour for emphasis.

I find Brodovitch’s design process as fascinating as his finished work because I learn more about how someone thinks by looking at their work-in-progress. Brodovitch began by designing his layouts as sketches on paper. Then, he arranged his spreads on the floor of his studio to create a well-paced magazine.

Scattering images

Early in his career, Brodovitch was inspired by Mehemed Fehmy Agha — the influential art director who designed the first double-page spread — and frequently scattered pictures across his pages like playing cards.

Left: For smaller sizes, I turn my group of images into a horizontally scrolling panel. Center: On medium-size screens, I scatter the images vertically to maintain visual hierarchy in portrait orientation. Right: For larger screens, I rearrange the images horizontally. (Large preview)

These might seem at first like a random arrangement of pictures, but they were deliberately placed and filled Brodovitch’s designs with movement. We can use the same technique today, even when designing flexible layouts.

For my first Brodovitch-inspired design, I scatter four differently sized images across the viewport. I can arrange these pictures either horizontally, vertically or even diagonally according to the screen dimensions.

To help me design a consistent experience across screen sizes, I form a storyboard from a short series of sketches.

Left: On medium-size screens, I scatter the images vertically to maintain visual hierarchy in portrait orientation. Right: For larger screens, I rearrange the images horizontally. (Large preview)

To develop this design, I use a combination of CSS Grid, Flexbox, and transforms. My markup is minimal and meaningful, using only three elements for layout; a top-level heading, a main element for my running text, and a figure element which contains my four images:

<h1 aria-label="Vespa"><svg>…</svg></h1>

<main>
<h2>It looks like a wasp!</h2>
</main> <figure>…</figure>

For smaller screens, I need only foundation styles for colour and typography as the normal flow, handles my single column layout. In normal flow, elements display one after another, depending on a document’s writing mode. If you’re new to these concepts, Rachel Andrew wrote an excellent primer.

To develop a small screen design consistent with larger screen sizes, I rotate images alternately within a horizontally scrolling figure element. As the browser default sets a flex container to no-wrap and arranges its flex items along a horizontal axis, I need only apply display: flex; to my figure element:

figure {
display: flex; }

By ensuring my figure never exceeds the width of my viewport and setting the horizontal overflow to scroll, I develop a simple scrolling panel which may contain as many images as I need:

figure {
max-width: 100vw;
overflow-x: scroll; }

My figure element contains four SVG images. To maintain their aspect ratio when using Flexbox, I enclose each one in its own division:

<figure>
</figure>

To fill all the horizontal space with images, I use the flex-grow property. flex-grow controls the ratio by which elements expand to occupy available space in a container, flex-shrink does the opposite. This property specifies the ratio that elements reduce in size when a container is narrower than their combined widths. I want my flex items to grow to fill any available space, but not shrink:

figure div {
flex-grow: 1;
flex-shrink: 0; }

Both flex-grow and flex-shrink allow the widths of elements to be completely fluid, with no restriction on how wide or narrow they can be. There are occasions when a flex item should start at a certain size before it grows or shrinks. In Flexbox, flex-basis provides a starting width for an element before it flexes:

figure div {
flex-basis: 40%;
/* flex: 1 0 40%; */ }

To shave a few bytes from my style sheet, I can combine those three properties into one by using the flex shorthand.

Choosing between Flexbox and Grid

People often ask me when to use Flexbox or Grid. Of course my answer depends on the style of element they’re implementing. For my set of four figure images, I can use Flexbox or Grid to develop a 2×2 arrangement where every image appears the same size. But, when I add or remove an image, the result using Flexbox isn’t what I’m looking for, as the final image expands to fill the entire width of my figure. By changing Flexbox to Grid, every item aligns to the grid which maintains their size.

Left: Using Flexbox, every item expands to fill the space available, so the final item is twice the size of the others. Right: With Grid, the elements stay aligned to my grid, which maintains their equal size. (Large preview)

It’s common in print to see design elements which overlap to create the illusion of depth. On the web, achieving this effect has been tricky, so design elements mostly stay separate. Grid enables designs which in the past were either difficult or even impossible to implement.

When a screen’s large enough to render my main and figure elements side-by-size, I apply display: grid; to the body element with column widths which match the 6+4 compound grid, I showed you in issue 2. I also set the gap between columns and rows:

@media screen and (min-width : 48em) {

body {
display: grid;
grid-template-columns: 2fr 1fr 1fr 2fr 2fr 1fr 1fr 2fr;
grid-column-gap: 2vw;
grid-row-gap: 4vh; }
}

Then, I place the heading, main, and figure elements onto that grid using line numbers:

h1 {
grid-column: 7;
grid-row: 1;  }

main {
grid-column: 6 / -1;
grid-row: 2;  }

figure {
grid-column: 1 / 6;
grid-row: 1 / 3;  }

Finally, when a screen’s large enough and I can get the biggest impact from my scattered pictures, I reposition the heading, main, and figure elements into new positions on my grid:

@media screen and (min-width : 64em) {

h1 {
grid-column: 8;
grid-row: 1; }

main {
grid-column: 2 / 6;
grid-row: 1; }

figure {
grid-column: 1 / -1;
grid-row: 2; }
}

Then, I apply grid properties to my figure element to create four columns, each one larger than the last:

figure {
grid-template-columns: 1fr 2fr 3fr 4fr;
grid-gap: 0;
align-items: end; }

I align my items to the end of their grid container, then nudge and rotate my images to give them the scattered look which Brodovitch inspired:

figure div:nth-of-type(1) {
transform: translate(20px, -20px) rotate(-20deg); }

figure div:nth-of-type(2) {
transform: rotate(-5deg); }

figure div:nth-of-type(3) {
transform: rotate(10deg); }

figure div:nth-of-type(4) {
transform: translate(-60px, -80px) rotate(-20deg); }

People have told me that designs like these are appropriate for editorial design but not for products or websites which promote or sell them. This isn’t the case at all. Graphic design principles matter as much to a digital medium as they do for print. Diverse and interesting designs stand out whichever medium you choose to deliver them.

I used scattered pictures to bring this design for a new electric Vespa scooter to life. (Author’s recreation.) (Large preview)

Alexey Brodovitch instinctively knew how to combine photographs with written content, often turning text into shapes that contrasted with or mirrored the forms in his photography. Over the next few pages, I’ll show you how to adapt his inspired design techniques to the web.

Lesson 2: Mirroring pictures and text

Aexey Brodovitch made the double-page spread his playground, using its large canvas to carefully construct his compositions. Facing pages allowed Brodovitch the possibility to contrast or connect both sides of a spread.

‘This Spring’ spread from Harper’s Bazaar, March 1954. Photographer: Lilllian Bassman. (Large preview)

I need three structural elements to implement this next Brodovitch inspired design; a heading, main, and aside:

<h1 aria-label="Vespa"><img></h1>
<main>…</main>
<aside>…</aside>

This larger screen design splits the viewport into two columns and uses colour and shape to reflect one half with the other. (Large preview)

Normal flow again handles my single column layout for small screens, and I need only foundation styles for colour and typography. These include background and foreground colours for the inverted aside:

aside {
background-color: #ba0e37;
color: #fff; }

Medium-size screens share those same foundation styles. I also reuse the same 6+4 compound grid from my previous design. To implement the asymmetric layout of elements inside my main and aside elements, I use Grid with four columns and a set of rows with a mixture of pixel and rem units:

@media screen and (min-width : 48em) {

main,
aside {
display: grid;
grid-template-columns: 2fr 1fr 1fr 2fr;
grid-template-rows: 10rem 200px 10rem auto; }
}

I add another unit, a viewport height unit, to those elements to ensure they always fill the full height of a screen:

main,
aside {
min-height: 100vh; }

My main and aside elements each contain a figure element and an SVG image and caption. To place those child elements on my grid, I apply display:contents; to my figure, and effectively remove it from the DOM for styling purposes, so its descendants take its place:

main figure {
display: contents; }

Then, I place the images and captions into columns and rows using line numbers:

main img {
grid-column: 1 / 4;
grid-row: 1 / 5; }

main figcaption {
grid-column: 4 / -1;
grid-row: 3; }

aside img {
grid-column: 2 / -1;
grid-row: 1 / 5; }

aside figcaption {
grid-column: 1;
grid-row: 3;
align-self: center; }

Next, I apply styles for larger screens, first by creating a grid with two symmetrical columns, then placing my main and aside elements onto that grid using named lines:

@media screen and (min-width : 64em) {

body {
display: grid;
grid-template-columns: [main] 1fr [aside] 1fr; }

main {
grid-column: main; }

aside {
grid-column: aside; }
}

All that remains is for me to position the heading containing the two-tone Vespa logo. As I only need this version of the logo on larger screens, I use the picture element to swap a standard version for my two-tone variation:

<h1>
<picture>
<source srcset="logo-2-tone.svg" media="(min-width: 64em)">
<img src="logo.svg" alt="ihatetimvandamme">
</picture>
</h1>

Although Flexbox and Grid have mostly taken over as my main layout tools, there are still good uses for CSS positioning. As I want my logo in the centre of my layout, I position it half-way across the viewport, then use a transform to move it left, so its centre matched the background behind it:

h1 {
position: absolute;
top: 14rem;
left: 50vw;
z-index: 2;
transform: translateX(-95px); }

Carving text into shapes

Shapes add movement to a design which draws people in. They help to connect an audience with your story and make tighter connections between your visual and written content.

I’ve seen very few examples of using CSS Shapes which go beyond Basic Shapes, including circle(), ellipse(), inset(). Even instances of a polygon() are few and far between. Considering the creative opportunities CSS Shapes offer, this is disappointing. But, I’m sure that with a little inspiration and imagination, we can make more distinctive and engaging designs.

‘If you don’t like full skirts.’ Spread from Harper’s Bazaar, March 1938. Photographer: George Hoyningen-Huene. (Large preview)

Inspired by Alexey Brodovitch, in my next design, the shape of the running text reflects shapes in the header image opposite. It often needs surprisingly little markup to develop dynamic and original layouts.

My Brodovitch inspired design uses CSS Shapes to echo the curves in the image within the column of running text. (Large preview)

To implement this design, I need just two structural elements; a header which also contains a picture element, and the main element for my running text:

<header>
<picture>…</picture>
</header>

<main>…</main>

I’ve made a simple small screen design, so I only need colour and typography foundation styles. By using a picture element in my header, browsers swap the portrait orientation image — which best suits small screens — with a landscape variation when I introduce layout styles.

For larger screens, I apply an asymmetrical two-column grid to the body and place the header and main elements using named lines. I also ensure the grid extends to the full viewport height, regardless of the amount of content:

@media screen and (min-width : 64em) {

body {
display: grid;
grid-template-columns: [header] 1fr [main] 1fr;
max-width: 100vw; }

header {
grid-column: header; }

main {
grid-column: main; }
}

I needn’t make a polygon path to flow my text around. Instead, I use a mask image which I add to the page using Generated Content applied to a pseudo-element:

main:before {
content: "";
display: block;
float: left;
width: 170px;
height: 800px;
shape-outside: url('mask.svg'); }

Note: Watch out for CORS (cross-origin resource sharing) when using images to develop your shapes. You must host images on the same domain as your product or website. If you use a CDN, make sure it sends the correct headers to enable shapes. It’s also worth noting that the only way to test shapes locally is to use a web server. The file:// protocol simply won’t work.

When you need content to flow around a shape, use the shape-outside property. You must float an element left or right for shape-outside to have any effect.

‘The Consensus of Opinion.’ Spread from Harper’s Bazaar, March 1936. Photographer: Man Ray. (Large preview)

You can also use Shapes to sculpt structural shapes from solid blocks of running text, in the style of Alexey Brodovitch.

The markup I need to implement this design is similar to my previous example, a header which again contains a picture element, and the main element for running text:

<header>
<picture>…</picture>
</header>

<main>…</main>

This design, inspired by Brodovitch’s 1936 ‘The Consensus of Opinion,’ carves my running text into a slanted columm. (Large preview)

Inside my main element are two SVG images which I use to carve my running text into its shape. To prevent these presentational images being announced by screen readers, I give them both an aria-hidden attribute and a value of true:

<img src="shape-1.svg" alt="" aria-hidden="true">
<img src="shape-2.svg" alt="" aria-hidden="true">
<p>…</p>

Using what should be by now a familiar 6+4 compound grid, I apply Grid to the body element and place the header and main elements using line numbers:

@media screen and (min-width : 64em) {

body {
display: grid;
grid-template-columns: 2fr 1fr 1fr 2fr 2fr 1fr 1fr 2fr; }

header {
grid-column: 1 / 5; }

main {
grid-column: 5 / 9; }
}

Next, I rotate the header image clockwise by twenty degrees and place its transform-origin in the centre horizontally and vertically to ensure it stays in the middle of my header:

header picture {
transform: rotate(20deg);
transform-origin: 50% 50%; }

Finally, I float the first image left, and the second image right, so that my running text flows between them and mirrors the shape of the rotated image opposite. I don’t need a class attribute on these images. Instead, I use an attribute selector which targets the image source:

[src*="shape-1"],
[src*="shape-2"] {
width: 200px;
height: 100vh; }

[src*="shape-1"] {
float: left;
shape-outside: url('mask-1.svg'); }

[src*="shape-2"] {
float: right;
shape-outside: url('mask-2.svg'); }

Tools like CSS Shapes now give us countless opportunities to capture readers’ attention and keep them engaged. I hope by now, you’re as excited about them as I am.

Developing pictures and text

When Brodovitch became frustrated with the commercial constraints of working on Harper’s Bazaar, in 1949, he began collaborating on Portfolio, the short-lived, but significant graphic design magazine. Running to just three issues, Portfolio allowed Brodovitch to focus on not just a magazine, but a “graphic experience.”

Left: ‘Jackson Pollock.’ Spread from Portfolio #3. Right: My Brodovitch inspired design uses three overlapping SVG images which are clipped using CSS clip-path and placed over background stripes implemented with a CSS gradient. (Large preview)

In issue 2 of Portfolio, Brodovitch designed a spread on the work of abstract-expressionist artist Jackson Pollock. In his design, shapes flow between columns which extend the full height of the page. I want to achieve the same style in my next Brodovitch inspired design, but whereas Brodovitch’s spread includes no copy, mine has two columns of running text. I also want the image behind my text to grow and shrink as the viewport changes size.

My markup for implementing this design contains only the bare minimum of main and aside elements:

<main>…</main>
<aside>…</aside>

The aside also contains a division which I use to place the running text onto my grid, and a figure element containing the images I need to accomplish the design:

<aside>

This design feature should be visible at any screen size, so before implementing layout styles, I set up the figure’s three separate images. The left and right images are white on a red background, and the centre image has red outlines on a white background. My first task is to establish the figure element as a positioning context for its descendants and position them absolutely in the top-left of my figure:

figure {
position: relative; }

figure img {
position: absolute;
top: 0;
left: 0; }

Next, I use the clip-path property to clip each of the images so that only one-third of them is visible:

figure img:nth-of-type(1) {
z-index: 2;
clip-path: polygon(0% 0%, 0% 100%, 33.33% 100%, 33.33% 0%); }

figure img:nth-of-type(2) {
z-index: 1;
clip-path: polygon(0% 0%, 100% 0%, 100% 100%, 0% 100%); }

figure img:nth-of-type(3) {
z-index: 2;
clip-path: polygon(100% 0%, 66.66% 0%, 66.66% 100%, 100% 100%); }

With these images positioned, I add layout styles for larger screens to place the main and aside elements onto my grid:

@media screen and (min-width : 64em) {

body {
grid-template-columns: 2fr 1fr 1fr 2fr 2fr 1fr 1fr 2fr; 
grid-column-gap: 2vw; } 

main {
grid-column: 1 / 3; }

aside {
grid-column: 3 / -1; }
}

To create the effect of three columns which extend to the full height of my page, I specify the full viewport height on my body element, then use a CSS gradient background image to give my aside element its column style. The percentage stop values in this gradient match the 33.33% widths of my clipped images:

body {
height: 100vh; }

aside {
background-image: linear-gradient(to right, 
#ba0e37 33.33%, 
#fff 33.33%, 
#fff 66.66%, 
#ba0e37 66.66%); }

All that remains is to place my column of running text and figure in the aside, so I apply grid values to the aside and place the division and figure using line numbers. As these elements overlap on my grid, I use z-index to push the figure backwards and my running text forward:

aside {
display: grid;
grid-template-columns: 1fr 1fr 1fr;
grid-template-rows: 1fr 1fr; }

aside div {
z-index: 2;
grid-column: 2;
grid-row: 1 / 3; }

figure {
z-index: 1;
grid-column: 1 / -1;
grid-row: 2; }

This design may look complicated and on a first glance may not seem achievable across a range of screen sizes, but it’s surprisingly simple to develop. It retains its personality from small screens to larger ones and is flexible at every size in-between.

Flexible designs which include precisely positioned elements were previously tricky to implement using floats and CSS positioning. Modern CSS techniques have made these designs much more straightforward to accomplish, which I hope will result in a new generation of inspired designs.

Left: ‘William Steig.’ Spread from Portfolio #2, summer 1950. Right: This design, inspired by Brodovitch’s 1950 ‘William Steig,’ uses CSS background gradients and SVG shapes. (Large preview)

My final design is again inspired by a spread from Portfolio’s second issue. Here, Brodovitch used a striking combination of black and white columns and a bold splash of colour. Implementing this design needs just two structural elements; a main and footer element:

My main element contains a headline logo, an image, and a block of running text. The footer includes two divisions, each containing a set of SVG images to accomplish the effect:


Vespa

</footer>

For medium-size screens, I place these elements on my grid using named lines:

@media screen and (min-width : 48em) {

body {
display: grid;
grid-template-columns: [main] 1fr [footer] 1fr;
min-height: 100vh; }

main {
grid-column: main; }

footer {
grid-column: footer; }
}

To adjust my layout proportions for larger screens, I need only change values for grid-template-columns on the body element:

@media screen and (min-width : 64em) {

body {
grid-template-columns: [main] 2fr [footer] 3fr; }
}

Before implementing any design, I make a simple storyboard to demonstrate how my elements will flow across a selection of screen sizes. (Large preview)

Content in the main element needs only basic styling, but the footer which occupies the right half of larger screens requires more. To accomplish this footer’s striped column effect, I again use a linear gradient and four percentage-based colour stops:

footer {
background-image: linear-gradient(to right, 
#000 33.33%, 
#fff 33.33%, 
#fff 66.66%, 
#000 66.66%); }

Each footer division contains a set of three SVG images:

<footer>
</footer>

Styling the footer’s second division involves turning it into a flex container. As the browser’s default Flexbox styles include a horizontal flex-direction and no wrapping, I need just a single line of CSS:

footer div:nth-of-type(2) {
display: flex; }

To ensure my images grow to fill the columns, but never exceed their width, I apply the flex-grow property and a value of 1, plus a max-width value of 33% to match my columns:

footer div:nth-of-type(2) img {
flex: 1;
max-width: 33%; }

The CSS clip-path property enables you to clip and element so that only part of it remains visible. These clipping paths can be any shape, from basic circles and eclipses to complex polygon shapes with any number of coordinates.

(Large preview)
  • 1. For the first image, I clip the right side leaving only the portion on the left visible (black area.)
  • 2. I position the second image absolutely and use a lower z-index value to send it to the bottom of my stacking order.
  • 3. For the third and final image, I clip the left side leaving only the portion on the right visible.
  • 4. My final result includes an SVG circle positioned over my images. A mix-blend mode tints the colour of elements below it in my stacking order.

For the images in the first division, I again position them absolutely within a positioning context, then use the clip-path property to clip each one so that only one-third of them is visible:

footer div:nth-of-type(1) {
position: relative;
min-height: 300px; }

footer div:nth-of-type(1) img {
position: absolute;
top: 0;
left: 0; }

footer div:nth-of-type(1) img:nth-of-type(1) {
clip-path: polygon(0% 0%, 0% 100%, 33.33% 100%, 33.33% 0%); }

footer div:nth-of-type(1) img:nth-of-type(2) {
clip-path: polygon(0% 0%, 100% 0%, 100% 100%, 0% 100%); }

footer div:nth-of-type(1) img:nth-of-type(3) {
clip-path: polygon(100% 0%, 66.66% 0%, 66.66% 100%, 100% 100%); }

My final task is to add an SVG circle which uses a mix-blend-mode to blend its colour with elements behind it:

footer div:nth-of-type(1) svg {
position: absolute;
mix-blend-mode: darken; }

Since I discovered his work, Alexey Brodovitch has been the most substantial influence on the work I make for the web and how I encourage my students to think about theirs. His inability to accept anything mediocre has pushed me to think beyond what’s expected from product and website design. I hope my designs include his dash of daring.

NB: Smashing members have access to a beautifully designed PDF of Andy’s Inspired Design Decisions magazine and full code examples from this article.

  1. Inspired Design Decisions: Avaunt Magazine
  2. Inspired Design Decisions: Pressing Matters
  3. Inspired Design Decisions: Ernest Journal
  4. Inspired Design Decisions: Alexey Brodovitch
Smashing Editorial
(ra, yk, il)

Source: Smashing Magazine, Inspired Design Decisions: Alexey Brodovitch

Overflow And Data Loss In CSS

dreamt up by webguru in Uncategorized | Comments Off on Overflow And Data Loss In CSS

Overflow And Data Loss In CSS

Overflow And Data Loss In CSS

Rachel Andrew



CSS is designed to keep your content readable. If you consider an HTML document that is marked up with headings and paragraphs (with no CSS applied), it displays in the browser in a readable way. The headings are large and bold, and the paragraphs have space between them which is controlled by the browser default stylesheet. As soon as you want to change the layout of your page, however, you start to take some of the control into your own hands. In some cases, this will mean that you give yourself the job of dealing with overflow.

In this article, I’m going to take a look at the different ways we encounter overflow on the web. We’ll see how new layout methods and new values in CSS can help us to deal with overflow and create less fragile designs. I’ll also explain one of the fundamental concepts behind the design of CSS — that of avoiding data loss.

CSS Lists, Markers, And Counters

There is more to styling lists in CSS than you might think. Let’s take a look at lists in CSS, and moving onto some interesting features defined in the CSS Lists specification: markers and counters. Read more  →

What Do We Mean By Overflow?

If we look back a few years (before the advent of layout methods such as Flexbox and Grid Layout), then consider being handed a design like the one below. A very simple layout of three boxes, different amounts of content in each, but the bottom of those boxes needs to line up:

Screenshot three boxes, variable amounts of content, the bottoms of the boxes line up

A neat set of boxes (Large preview)

With a floated layout, such a seemingly straightforward task was impossible. When floated, each box has no relationship to its neighbor; this means that has no way to know that the next door box is taller and to grow to match the height.

Screenshot three boxes, variable amounts of content, the bottoms of the boxes do not line up

The box bottoms do not align (Large preview)

Sometimes, in an attempt to make things line up, designers would then restrict the height of the boxes by second-guessing the amount of content in order to make the boxes tall enough to match. Of course, things are never that simple on the web and when the amount of content differed, or the text size was larger, the text would start to poke out of the bottom of the box. It would overflow.

Screenshot three boxes, variable amounts of content, content overflowing the bottom of the box

Overflow caused by fixing the box heights (Large preview)

This would sometimes lead to people asking how they could prevent too much content getting into the site. I’ve had people in support for my own CMS product asking how to restrict content for this very reason. They tell me that this extra content is “breaking the design”. For those of us who understood that not knowing how tall things were was a fundamental nature of web design, we would create designs that hid the lack of equal height boxes. A common pattern would have a gradient fading away — to mask the unevenness. We would avoid using background colors and borders on boxes. Or, we would use techniques such as faux columns to create the look of full-height columns.

This inability to control the height of things in relationship to other things therefore influenced web design — a technical limitation changing the way we designed. (I enjoy the fact that with Flexbox and Grid.) Not only did this problem disappear but the default behavior of these new layout methods is to stretch the boxes to the same height. The initial value of align-items is stretch, which causes the boxes to stretch to the height of the grid area or flex container.

See the Pen [Equal Height Boxes](https://codepen.io/rachelandrew/pen/VwZzxjV) by Rachel Andrew.

See the Pen Equal Height Boxes by Rachel Andrew.

In addition, CSS Grid gives us a nice way to ask for things to be at least a certain size, but grow larger if they need to. If you set a track size using the minmax() function, you can see a minimum and maximum size for the track. Setting rows to minmax(200px, auto) means that the track will always be at least 200 pixels in the block dimension — even if the grid items are empty. If, however, the content of a grid item means that it will be larger than 200 pixels, with the max set to auto it can grow. You can see this in the example below: The first row is 200 pixels as there are no items making it larger. The second row has a grid item with more content in than will fit, and so auto is being used and the track has grown larger than 200 pixels.

See the Pen [Minmax()](https://codepen.io/rachelandrew/pen/zYOdjKP) by Rachel Andrew.

See the Pen Minmax() by Rachel Andrew.

The minmax() function gives you the ability to create designs that look as if they have that perfect fixed size. In an ideal world (when the amount of content is pretty much as you expected), you will get those nice uniform rows. However, if additional content is added, there will be no overflow as there would be if you had fixed the height of the rows to 200 pixels. The row will expand; it might not be exactly what you wanted as a designer, but it will not be unreadable.

Inline Overflow

The potential for overflow happens whenever we restrict the size of things. In the above example, I am describing restriction in the block dimension, which horizontal language users will think of as height. However, we can also end up with overflow in the inline direction if we restrict the inline size or width of a box. This is something that we see in the “CSS is Awesome” meme:

Image contains the words ‘CSS is Awesome’ in a bordered box. The word awesome is too long to fit in the box so pokes out past the border

The ‘CSS Is Awesome’ meme (Large preview)

The author of this meme commented on a CSS-Tricks post about it saying,

“I do have a slightly better grasp on the concept of overflow now, but at the time it just blew my mind that someone thought the default behavior should be to just have the text honk right out of the box, instead of just making the box bigger like my nice, sensible tables had always done.”

So why does CSS make the text “honk right out of the box” rather than grow the box?

In the meme, you have overflow in the inline direction. The word “awesome” is larger than the width applied to the box, and so it overflows. CSS fairly reasonably assumes that if you have made the box a certain width, you want the box that width. Perhaps it needs to fit into a layout which would break if boxes suddenly became larger than set.

That particular issue (i.e. the need to set sizes on everything in a layout and making sure they did not total more than the available inline size of the container) is something that our modern layout methods have addressed for us. If we imagine that our box had that absolute inline size so that it could fit in a line with other boxes in a float-based grid, today you might choose to approach that layout using Flexbox.

With the floated layout, you have to set the sizing on each item — potentially before you know what the content will be. You will then have big things forced into small containers and small things left with a lot of space around them.

Irregular sized items in regular sized boxes

Items in a floated layout need to have a width set (Large preview)

However, if we use Flexbox, we can allow the browser to work out how much space to assign each item. Flexbox will then ensure that bigger things get assigned more space while smaller things get less. This squishy sizing means that the box that contains the word “awesome” will grow to contain the box, and the text won’t honk right out or overlap anything else. Overflow issue solved; this behavior is really what Flexbox was designed for. Flexbox excels at taking a bunch of unevenly sized stuff and returning the most useful layout for those things.

Irregular sized items in boxes which are sized to make best use of space

Flexbox distributes space between the items (Large preview)

Outside of Flexbox, it is possible to tell our box to be as big as is needed for the content and no more. The min-content keyword can be used as a value for width or inline-size if working with flow-relative logical properties. Set width: min-content and the box grows just as big as is needed to contain the word “awesome”:

See the Pen [Awesome with min-content](https://codepen.io/rachelandrew/pen/LYPjmbJ) by Rachel Andrew.

See the Pen Awesome with min-content by Rachel Andrew.

Avoiding Data Loss

The reason that the box overflows as it does (with the word escaping from the border of the box), is that the default value for the overflow property is visible. You could (if you wanted) manage that overflow in a different way. For example, using overflow: auto or overflow: scroll would give your box scrollbars. This is probably not something you want in this scenario, but there are design patterns where a scrolling box is appropriate.

Another possibility would be to decide that you are happy to crop the overflow by using overflow: hidden. Perhaps you might think that hiding the overflow would have been a better default, however, the fact that CSS chooses to make the overflow visible by default (and not hidden) is a clue to a core value of designing CSS. In CSS (as in most places), we try to avoid data loss. When we talk about data loss in CSS, we are typically describing some of your content going missing. In the case of overflow: hidden, the overflowing content disappears. This means that we have no way to get to it to see what we have missed out on.

In some cases, this could be a real problem. If you have managed to create a design so fragile that the button of your form is in the cropped-off area, your user has no ability to complete the form. If the final paragraph is trimmed off, we never know how the story ends! Also, the problem with things vanishing is that it isn’t always obvious that they have gone. As the designer, you may not spot the problem, especially if it only happens in certain viewport sizes in a responsive design. Your users may not spot the problem — they just don’t see the call to action, or think it is somehow their problem they can’t place their order and so go away. However, if things overflow messily, you will tend to spot it. Or, at worse, someone using the site will spot it and let you know.

So this is why CSS overflows in a messy, visible way. By showing you the overflow, you are more likely to get a chance to fix it than if it hides the overflow. With the overflow property, however, you get a chance to make the decision yourself about what should happen. If you would prefer the overflow be cropped (which may be the right decision in some cases), use overflow: hidden.

Data Loss And Alignment

The better alignment abilities we have gained in recent years also have the potential for data loss. Consider a column of flex items that are up against the edge of the viewport and with different sizes. Aligned to flex-start, the items all stick out more to the right. Aligned to center, however, the longer item would actually end up off the side of the viewport. Alignment could therefore cause data loss.

To prevent accidental data loss caused by alignment, CSS now has some new keywords which can be used along with the alignment properties. These are specified in the Box Alignment specification — the specification which deals with alignment across all layout methods including Grid and Flexbox. They are currently only supported in Firefox. In our example above, if we set align-items: safe center, then the final item would become aligned to start rather than forcing the content to be centered. This would prevent the data loss caused by the item being centered and therefore pushed off the side of the viewport.

If you do want the alignment (even if it would cause overflow), then you can specify unsafe center. You’ve then requested that the browser does your chosen alignment no matter what then happens to the content. If you have Firefox, then you can see the two examples: one with safe and the second with unsafe alignment.

See the Pen [Safe and unsafe alignment](https://codepen.io/rachelandrew/pen/QWLMrpE) by Rachel Andrew.

See the Pen Safe and unsafe alignment by Rachel Andrew.

In the talk on which I based this article, I described web design as being a constant battle against overflow. One of the truths of designing for the web is that it’s very hard to know how tall or how large any element that contains text (in the block dimension) will be. However, as I have shown above, we have never had so many ways to manage overflow or the potential of overflow. This means that our designs can be far more resilient, and we can create patterns that will work with varying amounts of content. These might seem like small shifts in our capabilities, but I think the possibilities they open up to us are huge.

Smashing Editorial
(il)

Source: Smashing Magazine, Overflow And Data Loss In CSS

Automating Website Deployments Through Buddy

dreamt up by webguru in Uncategorized | Comments Off on Automating Website Deployments Through Buddy

Automating Website Deployments Through Buddy

Automating Website Deployments Through Buddy

Leonardo Losoviz



(This is a sponsored article.) Managing the deployment of a website used to be easy: It simply involved uploading files to the server through FTP and you were pretty much done. But those days are gone: Websites have gotten very complex, involving many tools and technologies in their stacks.

Nowadays, a typical web project may require to execute build tools to compress assets and generate the deliverable files for production, upload the assets to a CDN and invalidate stale ones, execute a test suit to make sure the code has no errors (for both client and server-side code), do database migrations (and, to be on the safe side, first execute a backup of the database), instantiate the desired number of servers behind a load balancer and deploy the application to them (through an atomic deployment, so that the website is always available), download and install the dependencies, deploy serverless functions, and finally notify the team that everything is ready through Slack or by email.

All this process sounds like a bit too much, right? Well, it actually is too much. How can we avoid getting overwhelmed by the complexity of the task at hand? The solution boils down to a single word: Automation. By automating all the tasks to execute, we will not dread doing the deployment (and having a trembling sweaty finger when pressing the Enter button), indeed we may not be even aware of it.

Automation improves the quality of our work, since we can avoid having to manually execute mind-numbing tasks again and again, which will enable us to use all our time for coding, and reassures us that the deployment will not fail due to human errors (such as overriding the wrong folder as in the old FTP days).

Introduction To Continuous Integration, Delivery, And Deployment

Managing and automating software deployment involves both tools and processes. In particular, Git as the version control system where to store our source code, and the availability of Git-hosting services (such as GitHub, GitLab and BitBucket) which trigger events when new code is pushed into the repository, enable to benefit from the following processes:

  • Continuous Integration
    The strategy of merging changes in the code into the main branch as often as possible, upon which automated tests against a build of the codebase are run to validate that the new code doesn’t introduce errors;
  • Continuous Delivery
    An extension to Continuous Integration which also automates the release process, enabling to deploy the project into production at any moment;
  • Continuous Deployment
    An extension to Continuous Delivery which automatically deploys the new code whenever it passes all required tests (as small a change it may contain), enabling to easily identify the source of any problem that might arise, and removing pressure off the team as it doesn’t need to deal with a “release day” anymore.

Adhering to these strategies has several benefits. The most immediate one is that our product can ship new features faster, indeed they can go live as soon as the team has finished coding them. The team can also receive feedback immediately (either from team members on a development environment, from the client on a staging environment, and from the users after it goes live) and be able to react straight away, thus creating a positive feedback loop. And because the whole process is fully automated, the team can save time and focus on the code, thus improving the quality of the product.

Continuous delivery enables getting feedback as early as possible

Continuous delivery enables getting feedback as early as possible. (Large preview)

Introducing Buddy, A Tool For Automating Software Deployment

The popularity of Git has given rise to a new generation of tools to manage the complexity of software deployments. Buddy is one of these new tools, born with the goal of making it easy to implement Continuous Integration/Delivery/Deployment, while broadening the number of features our application can provide, improving its quality, and reducing its costs by allowing to incorporate the offerings of the best or cheapest cloud-based service providers (among them AWS, DigitalOcean, Google Cloud Platform, Cloudflare, Rackspace, Azure, and others) into our stacks. This way, for instance, our application can be hosted on GitHub, be protected from DDoS through Cloudflare, have its static files hosted through DigitalOcean, use serverless functions from AWS Lambda, and authenticate users through Firebase, and everything is handled seamlessly.

Buddy operates through the use of pipelines: Sets of actions defined by the developer in a specific order, executed either manually or automatically when executing a Git push, that deliver the application from a Git repository to wherever needed and transforming it as required. Pipelines are extremely flexible, enabling developers to add only the required actions and have them customized for their specific needs.

For instance, the following pipeline performs all required tasks to deploy some Node.js application: execute the build step, upload files to the server through SFTP, upload assets to AWS S3 and purge them from the CDN, restart the server and finally inform the team through Slack (as it can be appreciated in the image below, the pipeline can be self-explanatory):

Buddy pipeline example
An example of a pipeline to deploy a Node.js application. (Large preview)

We can create different pipelines for different environments, and execute special actions when the process fails (such as when a test was not successful when the server to deploy to is down, or others). For instance, the following pipeline (to deploy a Node.js & PHP app that uses DigitalOcean, Fortrabbit & AWS CloudFront for hosting) makes a backup of assets and purges the CDN only when deploying to production, and sends a notification to the team through Slack in case of failure:

Demonstration of Buddy pipeline
Pipeline configured for different environments. (Large preview)

A noteworthy effect of configuring our pipelines with actions from different cloud-service providers is that we can conveniently switch among them whenever the need arises, making it easy to avoid vendor lock-in (this includes also changing the repository provider). Buddy offers slightly over 100 actions out of the box, and also allows developers to create and use their own actions. This image shows all the readily available actions:

Buddy actions
Out of the box actions in Buddy. (Large preview)

Creating A Pipeline

Let’s see how to create a simple pipeline to test and deploy a Node.js application, and send a notification to the team. The first step is to create a new project, during which you will be asked to select the project’s hosting provider (from among GitHub, GitLab, Bitbucket, Buddy Git Hosting, and your private Git server), and then to select the repository:

Tutorial step 1: Selecting the hosting provider

Selecting the hosting provider (Large preview)

Then we can create the pipeline, specifying when it must run (either manually, automatically after new code is pushed to the repository, or automatically every x amount of time) and from which branch:

Tutorial step 2: Creating a new pipeline

Creating a new pipeline (Large preview)

Then we can add actions to the pipeline. For that, we simply click on the “+” button to add a new action, upon which we must configure it as needed. To build and test a Node.js application we add and configure a “Node.js” action:

Tutorial step 3: Adding a Node.js action

Adding a Node.js action (Large preview)

After testing the application, we can deploy it by uploading it to our production server through SFTP. For this, we add an “SFTP” action, and configure it through custom-defined environment variables ${SFTP} and ${SFTP_USER}:

Tutorial step 4: Adding an SFTP action

Adding an SFTP action (Large preview)

Finally, we send an email to the team with the results of the execution. For this, we add and configure the “Email” action:

Tutorial step 5: Adding an Email action

Adding an Email action (Large preview)

That’s it. Our pipeline will look like this:

Tutorial step 6: Pipeline finished

Pipeline finished (Large preview)

From this moment on, if the pipeline was configured to run when new code is pushed to the repository, doing a git push will trigger the execution of the pipeline.

Staying Constantly Up To Date

Web development is in a never-ending state of flux, with new tools and services being launched without a break, some of them often becoming a hot trend immediately and the new normal barely a few months later. Technologies seldom heard of a few years ago progressively gain importance and eventually become a must (voice search, machine learning, WebAssembly), new frameworks and libraries offer new ways of building sites (GraphQL, Gatsby, Next.js, Nuxt.js), and our applications need to be accessed from newly-invented devices (Amazon Echo, In-car systems). To keep our applications relevant, we must continuously evaluate the latest offerings and decide if to add them to our technology stack. Hence, it is extremely important that our platforms for developing the application do not restrict what technologies we can use.

Buddy deals with this issue by continuously collecting feedback from its users about what they need (through user polls, their forum, communication channels, and tweets), and its team strives to deliver the required features. The Buddy blog provides a glimpse of the intense pace of development: For instance, in the last few months they implemented features for building static apps and websites with Gatsby, deploying to UpCloud and to Google Cloud Functions, triggering pipelines with webhooks, integrating with Firebase, building and running Docker containers on AWS ECS, and many others.

Conclusion

Automation has become a must to avoid being overwhelmed by the complexity of modern website deployment. We can make use of Continuous Integration/Delivery/Deployment (readily feasible by hosting our source code through Git) to shorten the time needed for delivering new features into our applications and getting feedback from the users.

Buddy helps in this task, enabling developers to create pipelines to execute actions concerning a wide array of technologies and cloud-service providers, and combining these actions in any possible way to satisfy the most particular needs.

You can check out Buddy for free for 2 weeks and, if you need to host your data, you can also install it on your own premises.

Smashing Editorial
(ms, ra, yk, il)

Source: Smashing Magazine, Automating Website Deployments Through Buddy

Moving From Sketch To Figma: A Case Study Of Migrating Design Systems

dreamt up by webguru in Uncategorized | Comments Off on Moving From Sketch To Figma: A Case Study Of Migrating Design Systems

Moving From Sketch To Figma: A Case Study Of Migrating Design Systems

Moving From Sketch To Figma: A Case Study Of Migrating Design Systems

Buzz Usborne



For the past year, every time I got frustrated with Sketch, a colleague of mine suggested I try Figma. Then, when I wrote an article about building our design system in Sketch, I got a bunch of feedback from people telling me to try Figma. And recently, Linda, our Head of Design at Help Scout, asked me, “Hey Buzz, shouldn’t we be using Figma?”

I couldn’t fight it anymore… I just had to try Figma!

This isn’t a love letter to Figma or a harsh review of Sketch. Instead, it’s a cautionary tale for anyone who is thinking of moving tools. This is the story of how everything panned out, and the specifics of migrating a design system from one platform to another.

Understanding The Cost

The first thing to consider is that there’s a cost involved in switching tools — a consideration not usually factored into the conversation whenever there’s a #designtwitter pile-on. Only one-person teams can afford to change design tools at will; for busy teams, it’s not so easy.

The difficulty for us at Help Scout was the fact that our design system is built as multiple, interdependent Sketch Libraries managed with GitHub. We also have multiple in-flight projects, processes and vast documentation that all depend on Sketch files. And don’t forget the monumental effort involved in training and moving an entire team onto a new tool whilst simultaneously doing actual work!

Screenshot of the original Help Scout design system in GitHub

Contributing to Help Scout’s design system happened through GitHub. (Large preview)

There’s also a financial cost involved in someone (in this case, that’d be me) taking the time away from business-as-usual work to research and document all this good stuff. Point is, if you work in an established design team, you’ll know that changing tools is about as easy as moving offices.

But that’s how this works. Tools are “sticky” just by virtue of being hard to leave. Suffice to say, this wasn’t going to be a decision we made lightly.

Kicking The Tires

With the understanding that my decision would have an impact on the whole team and organization, I started by spending two full days exploring Figma. I watched videos, I spoke to other designers who use it often and I played with the tool… a lot! Essentially, I explored how easy it would be to move our Sketch components over. A question that came to mind was whether it would be as easy as opening a .sketch file in Figma?

Unsurprisingly, no.

It turns out that Figma and Sketch — while similar in layout and functionality — have some key differences in how they allow components to be overridden. This was the kicker. Figma allows for color, type and effects (shadows, etc.) to be customized by the user, whereas Sketch will only allow pre-determined overrides. Because of the limitations Sketch imposes on overriding components, we’d built our original design system around that — allowing full color, border and style control using a complex system of masks and building-block components.

Over-complicated? Yes. But it worked great for us.

Here’s a simple card symbol in Sketch which was made from five nested symbols that were necessary in order for us to achieve the level of flexibility we required. This is the exact kind of thing that doesn’t import well into Figma.

A side-by-side image of a component and it’s available overrides in Sketch

A preview of how we brought Figma-level overrides to Sketch (Large preview)

While this complexity in Sketch allowed us the level of flexibility Figma offers out-the-box, it meant that almost any component imported from Sketch brought an unnecessary level of complexity along with it. In order for us to use Figma, we’d need to rebuild everything from scratch to strip each component down to the essentials.

Decision Time!

Given the above, my initial decision was that although I thought Figma was the better tool, the stronger company, and the safer long-term bet, it was going to be too difficult and costly to switch. Re-building entire libraries is a big job! It was like breaking up before we’d even given it a chance.

“It’s not you, it’s us.”

But as it happens, Figma are Help Scout’s customers. On hearing our decision to stick with Sketch, our Head of Sales set up a call with the Figma product team — not necessarily to change anyone’s minds, but to share our experiences, more like as friends do. They were understandably cool about the whole thing, but asked whether they could talk to me about my decisions. And that was an opportunity not to be missed!

In the days leading up to my conversation with the Figma team, I decided to jump back into the tool — at the very least to give myself enough understanding to be able to talk with confidence and not look like a total amateur in front of people who knew a lot more in this area than me. By the time I spoke with the team, I was a convert — in just those couple of extra days, I realized how much more productive and collaborative we’d be as a team with these kinds of features at our disposal. The cost of switching hadn’t changed, but my opinion of whether the cost was worth it had. Help Scout’s Head of Design made a compelling point to that effect too: If we feel like we’ll make the switch someday, then why not today?

So my conversation with Figma ended up being more along the lines of, “Give me some advice on how to make this work,” which they graciously did.

How To Switch

So it’s possible that you might be in the same spot I was; you want to move tools but are faced with the monumental task of rebuilding hundreds of components, styles, and a load of documentation. Well, friend, you’re going to need to take a deliberate and systematic approach to this. Your mileage may vary, but this is how I moved Help Scout’s entire design system to Figma in just a week.

  1. Split Your Libraries
  2. Lean Heavily On Styles (+ Documentation)
  3. Show How Components Extend
  4. Organize Properly
  5. Importing vs. Re-Building
  6. Get Your Team On Board
  7. Go All In

1. Split Your Libraries

This applies to creating Sketch libraries too, but I strongly suggest splitting design systems into separate sub-libraries that cover different parts of your ecosystem. In our case, we have Core which contains components applicable to any designer (brand assets, illustrations, icons, etc.), then domain-specific documents. This approach makes migration a bit easier to handle when you’re moving things over in organized chunks.

Thumbnails of the four Help Scout design-system libraries

Our design libraries, separated by team. (Large preview)

In our case, migrating to Figma involved beginning with the Core elements — which were then used to build out subsequent libraries.

2. Lean Heavily On Styles (+ Documentation)

Figma has “Styles” that work in the same way you’re used to seeing Type Styles working in Sketch, but with the added benefit that these also apply to color and effects. With this in mind, it’s really useful to define all your colors and shared elements in one single library, then document them.

Documentation showing a selection of shadows available with the Library

An example of how styles are documented within each library (Large preview)

3. Show How Components Extend

Since Figma allows much greater control over how components can be extended, you’ll probably end up with fewer components than you had in Sketch — instead of “button solid color” and “button outlined,” in Figma you’ll just need “button”. Because of this, I found that it was important to document the different ways a component can be extended directly within the library itself.

For example, only one component is required to re-create an entire two-sided chat conversation in Figma. But a new designer would never know what overrides to apply, so it’s important to visually demonstrate whenever it’s possible. Here’s the same component being used in six different ways:

An example conversation built with components to demonstrate correct use

An example of how a single Figma component can construct an entire conversation (Large preview)

4. Organize Properly

I quickly abandoned trying to replicate the naming structure I had in the original Sketch files because of subtle differences in how Figma’s file system works. Ultimately, the aim is to make sure components are in a logical place and easy to find, and the best way I found to achieve that was to carefully organize my Pages by category (e.g., Forms), Frames by group classification (e.g., Inputs) and Components by individual element (e.g., Error). Being specific about naming makes components super easy to find — especially by people who didn’t originally create them.

Side-by-side of Frame names and related components

Naming is important! (Large preview)

5. Importing vs. Re-Building

Phew, I wish I had good news here about the physical act of importing Sketch components (for a lot of things, namely individual elements like icons which you can import from Sketch and it’ll all work out great). However, for more complex components (especially ones that involve masks and nested symbols), you’re better off re-creating the components from scratch. Yes, it’s extremely painful, but on the upside, you’ll get really good at using Figma in a very short time!

My workflow in Figma for re-creating the more complex Sketch components was literally to screenshot then “trace” them in Figma. As ridiculous as this sounds, it turned out to be much faster than importing from Sketch and removing the unnecessary elements. And I’m a little bit ashamed to say that I love this kind of work, but also, turns out that this workflow was more effective.

(But of course, if you’re migrating simpler components like icons, then Figma’s importing capabilities will serve you just fine.)

A timelapse of making a Figma component from a Sketch symbol
An insight into my day (Large preview)

6. Get Your Team On Board

As a 100% remote team, most things we do at Help Scout are well communicated — this was no different. So while the team was aware of the impending tool switch, it wasn’t until I had finished the design system that they got the nudge.

At this point, I gave a 20-minute demo video explaining Figma, some basics on how to use it, and some of the cool improvements they’ll find to their workflow when using components. This turned out to be a hit and definitely softened the blow for people who were perhaps a little hesitant about the move at first.

The original video that I shared with my team

7. Go All In

Part of my initial research involved seeing whether we could maintain our design system in Sketch and Figma simultaneously. I’m certain it can be done, but it’s a bit of a stretch for us given our fairly small team size and the fact we have no single person or team dedicated to the upkeep of our libraries. But instead of keeping what we had in place, I decided to go all-in on Figma.

This meant creating and updating all documentation and employee onboarding to reference the new stuff which forced me to address the migration of anything that referenced the old stuff — including existing development processes and designer hand-off. Ultimately, drawing a line in the sand meant that we were all committed to making this a success.

Of course, the Sketch libraries still exist; they’re just no longer documented nor updated. And in terms of migration, in-flight projects continue to use Sketch files (although some designers have chosen to migrate their work to Figma), whereas new projects use Figma. It’s a clean break.

Conclusion: Make A Plan!

It’s hard to conclude an article like this without sounding like I have all the answers — which I most certainly do not. But my advice to anyone switching tools is to take it slow. Put in the research, make a plan of attack, figure out the cost then weigh up whether you’re prepared to pay it — this applies whether you’re moving to Figma, Sketch, InVision Studio, Adobe XD, Framer X or some other trendy new tool I haven’t heard of yet.

For us, time will tell, but I’m still pretty confident we made the right call!

Further Reading

Smashing Editorial
(mb, yk, il)

Source: Smashing Magazine, Moving From Sketch To Figma: A Case Study Of Migrating Design Systems

Blissful Thoughts And Embracing Change (September 2019 Wallpapers Edition)

dreamt up by webguru in Uncategorized | Comments Off on Blissful Thoughts And Embracing Change (September 2019 Wallpapers Edition)

Blissful Thoughts And Embracing Change (September 2019 Wallpapers Edition)

Blissful Thoughts And Embracing Change (September 2019 Wallpapers Edition)

Cosima Mielke



Lush green slowly turning into yellows, reds, and browns in the Northern hemisphere; nature awakening from its slumber in the Southern part of the world: September is a time of change. A chance to leave old habits behind and embrace the beginning of something new. And, well, sometimes a small change of routines is already enough to spark fresh inspiration and, who knows, maybe even great ideas.

With that in mind, we embarked on our monthly wallpapers challenge more than nine years ago, and since then, artists and designers from all across the globe have accepted the challenge and submitted their designs to it to cater for a bit of variety on the screens we look at so often. Of course, it wasn’t any different this time around.

This post features their wallpapers for September 2019. All of them come in versions with and without a calendar, so it’s up to you to decide if you want to have the month at a glance or keep things simple. As a bonus goodie, we also collected some timeless favorites from past years’ editions at the end of this post. A big thank-you to all the artists who have submitted their wallpapers and are still diligently continuing to do so. Happy September!

Please note that:

  • All images can be clicked on and lead to the preview of the wallpaper,
  • We respect and carefully consider the ideas and motivation behind each and every artist’s work. This is why we give all artists the full freedom to explore their creativity and express emotions and experience through their works. This is also why the themes of the wallpapers weren’t anyhow influenced by us but rather designed from scratch by the artists themselves.

Submit your wallpaper

We are always looking for creative designers and artists to be featured in our wallpapers posts. So if you have an idea for an October wallpaper, please don’t hesitate to submit your design. We’d love to see what you’ll come up with. Join in! →

Stay Or Leave?

Designed by Ricardo Gimenes from Sweden.

Stay Or Leave?

Bear Time

Designed by Bojana Stojanovic from Serbia.

Bear Time

National Video Games Day Delight

“September 12th brings us National Video Games Day. US-based video game players love this day and celebrate with huge gaming tournaments. What was once a 2D experience in the home is now a global phenomenon with players playing against each other across statelines and national borders via the internet. National Video Games Day gives gamers the perfect chance to celeberate and socialize! So grab your controller, join online and let the games begin!” — Designed by Ever Increasing Circles from the United Kingdom.

National Video Games Day Delight

Finding Jaguar

“Nature and our planet have given us life, enabled us to enjoy the most wonderful place known to us in the universe. People have given themselves the right to master something they do not fully understand. We dedicate this September calendar to a true nature lover, Vedran Badjun from Dalmatia, Croatia, who inspires us to love our planet, live in harmony with it and appreciate all that it has to offer. Amazon, Siberia and every tree or animal on the planet are treasures we lose every day. Let’s change that!” — Designed by PopArt Studio from Serbia.

Finding Jaguar

Celebrate Like A Hispanic

“September marks the start of the Hispanic Heritage Month, a multicultural tradition we should all be proud of.” — Designed by Yaiza Narganez Gomez from Belgium.

Celebrate Like A Hispanic

Cheerful September

“Wanted to create something colorful and happening for this month.” — Designed by Ciara from India.

Cheerful September

Cozy Times

“As the days are getting shorter and colder, fall is here again. Enjoy these cozy times!” — Designed by Melissa Bogemans from Belgium.

Cozy Times

Blissful Thoughts

Designed by Thamil G from Chennai, India.

Blissful Thoughts

Give Life A Chance

“Life is all about taking chances. God is going to give you all the opportunities in life, it’s on you to take the chance and make a successful life out of it.” — Designed by Pragya from India.

Give Life A Chance

Even The Cactus Needs A Little Moist

“Even the toughest of hearts need a tiny bit of gentleness and kindness just like the cactus that needs to be nourished with a little bit of water and sunlight to stay bright and blooming in the bumpy journey of life.” — Designed by Sweans Technologies from London.

Even The Cactus Needs A Little Moist

Do Better

“Character is what you do when no one else is watching. A friend recently posted the 2nd half of this quote on their Instagram and it’s been my mantra lately.” — Designed by Marie Newell from Missouri, USA.

Do Better

For Poor Children

“We created this wallpaper, wanted to show what we wanted and done!” — Designed by Vạn Đăc Phúc from Vietnam.

For Poor Children

The Mythical Land Of School

“Going back to school is always a thrill no matter how big or small you are, facing new knowledge and challenges is one of the most satisfying feelings a human can encounter in life.” — Designed by Maria Keller from Mexico.

The Mythical Land Of School

Online Learning

“Online learning is the most popular way learning nowadays and, thus, I created a view which represents that.” — Designed by Ritu from India.

Online Learning

Put Some Green Everywhere

“I took this photo in Chaumont France, at the garden festival. For example, plants and concrete are in good association in that corner. That’s why I think we should put more plants in the cities and everywhere.” — Designed by Philippe Brouard from France.

Put Some Green Everywhere

Oldies But Goodies

Some things are too good to be forgotten. That’s why we dug out some September favorites from our wallpapers archives. Please note that these designs don’t come with a calendar. Enjoy!

Cacti Everywhere

“Seasons come and go, but our brave cactuses still stand. Summer is almost over, and autumn is coming, but the beloved plants don’t care.” — Designed by Lívia Lénárt from Hungary.

Cacti Everywhere

No More Inflatable Flamingos!

“Summer is officially over and we will no longer need our inflatable flamingos. Now, we’ll need umbrellas. And some flamingos will need an umbrella too!” — Designed by Marina Bošnjak from Croatia.

No More Inflatable Flamingos!

Funny Cats

“Cats are beautiful animals. They’re quiet, clean and warm. They’re funny and can become an endless source of love and entertainment. Here for the cats!” — Designed by UrbanUI from India.

Funny Cats

Talk Like A Pirate Day

“This calendar was inspired by International Talk Like a Pirate Day (September 19) — one of the many obscure and quirky days we celebrate in New Orleans. Our fair, colorfully corrupt city has entertained its share of outlaws over the years, but none as infamous as the pirate Jean Lafitte, a Frenchman who terrorized sailors and ships in the Gulf of Mexico and distributed his booty from a warehouse in New Orleans in the early 1800s. This calendar is a playful tribute to all of the misfits, outcasts and swashbucklers who call New Orleans home.” — Designed by Sonnie Sulak from New Orleans, LA.

Talk Like A Pirate Day

Geometric Autumn

“I designed this wallpaper to remind everyone that autumn is here and they are still reading the best design website, Smashing Magazine” — Designed by Advanced Web Ranking from Romania.

Geometric Autumn

Summer Ending

“As summer comes to an end, all the creatures pull back to their hiding places, searching for warmth within themselves and dreaming of neverending adventures under the tinted sky of closing dog days.” — Designed by Ana Masnikosa from Belgrade, Serbia.

Summer Ending

Flower Soul

“The earth has music for those who listen. Take a break and relax and while you drive out the stress, catch a glimpse of the beautiful nature around you. Can you hear the rhythm of the breeze blowing, the flowers singing, and the butterflies fluttering to cheer you up? We dedicate flowers which symbolize happiness and love to one and all.” — Designed by Krishnankutty from India.

Flower Soul

Penguin Family

“Penguins are sociable, independent and able to survive harsh winters. They work as a team to care for their offspring and I love that!” — Designed by Glynnis Owen from Australia.

Penguin Family

Shades Of Summer

“You can never have too many sunglasses” — Designed by Marina Eyl from Pennsylvania, USA.

Shades of Summer

Be The Wind Of Change

“Be the wind of change. Nature inspired us in creating this wallpaper as well as the Scorpion’s song “Wind of change” we dedicate to all creatives worldwide.” — Designed by Design19 from Romania.

Be the wind of change

Laughing In Flowers

“A colorful wallpaper to brighten up your day.” — Designed by Shavaughn Haack from South Africa.

Laughing in flowers

Colors Of September

“I love September. Its colors and smells” — Designed by Juliagav from Ukraine.

colors of September

Tsukimi

“The moon will become the roundest in mid-autumn and Japanese will eat Dango (sweet rice dumpling) while admiring the moon.” — Designed by Evangeline Neo from Japan.

Tsukimi

Red Beetle

Designed by Oxana Kostromina from Russia/Germany.

Smashing Wallpaper - september 11

It’s September But I Can Still Ride The Waves

“Summer seems to be over… but the weather is still warm and we definitely can enjoy the sea for a little longer. So… let’s go and ride the waves! Are you coming?” — Designed by WebOlution from Greece.

It’s September But I Can Still Ride The Waves

Join In Next Month!

Thank you to all designers for their participation. Join in next month!

Source: Smashing Magazine, Blissful Thoughts And Embracing Change (September 2019 Wallpapers Edition)

VuePress: Documentation Made Easy

dreamt up by webguru in Uncategorized | Comments Off on VuePress: Documentation Made Easy

VuePress: Documentation Made Easy

VuePress: Documentation Made Easy

Ben Hong



When it comes to any project that requires any user interaction (e.g., end users, maintainers, etc.), there is one critical factor that makes the difference between success and failure: good documentation. This holds true regardless of how small or large your project is. After all, short of providing one-on-one support for your project, documentation is the first line of defense for users who are trying to solve a problem. And whether you like it or not, you will never hear from users who give up after being unable to solve their problem due to inadequate documentation.

The Challenges Of Creating Good Documentation

When it comes to writing good documentation, there are four recurring issues that teams often encounter:

  1. Documentation is often out of date.
    While no documentation for a project can be a frustrating experience, it is arguably worse to have outdated documentation. After all, the purpose of having documentation is to provide users with an official body of knowledge that they can rely on. When it is out of date, users are wasting their time and ultimately losing trust in your product.

    The primary reason that documentation becomes outdated is that documentation maintenance is separate from code changes. Without investing significant time and energy, this can be difficult to solve because:

    1. Documentation usually lives in a third-party service like Confluence or a Wiki,
    2. Developers are typically more interested in writing code than documentation.
  2. Users are unable to easily provide feedback.
    No matter how good you think your documentation is, it is ultimately meaningless without testing it with real users who can provide feedback. As mentioned earlier, a common bias when evaluating the effectiveness of things like documentation is failing to account for users who were unable to solve their problems and gave up. Since no team would ever be able to account for every scenario of how users might use your product, users must have an easy and reliable way to give feedback.
  3. Documentation is often written for by power users for power users.
    The flaw with using standard tools like wikis or README files is that they often only cater to a specific set of users who often have a pre-existing knowledge of the library and/or technology stack. As a result, it is fairly simple for them to navigate the space and find what they need. However, new users lack this prior knowledge and thus often require a much more immersive experience to engage them.

    Examples of this include:

    • A well-designed website,
    • Search capability,
    • Guided side navigation,
    • Easily identifiable meta information (i.e., last updated date),
    • Immersive content that extends beyond a wall of text that is difficult to easily comprehend.
  4. Poor infrastructure that makes documentation difficult to maintain.
    As if writing good documentation that users can understand is not difficult enough, the ease in which a developer can write and/or maintain documentation is critical to its long term viability. So, for every additional barrier that developers must deal with to write and/or maintain documentation, the more likely it is that it will ultimately fail. As a result, it is critical that the authoring experience and maintenance of any documentation be as seamless and engaging as possible.

If only there was a tool that could do all of these things for us…

Enter VuePress

When first hearing of VuePress, one might be tempted to guess that it is an amalgamation of Vue.js and WordPress. Instead, you should think of VuePress as:

Vue.js + Printing Press

Because when all is said and done, VuePress is a static site generator!

Some of you might be thinking, “Wait. Another static site generator? What’s the big deal?”

While there are a number of tools that are static site generators, VuePress stands out from amongst the pack for a single reason: its primary directive is to make it easier for developers to create and maintain great documentation for their projects.

Why Is VuePress So Powerful For Creating Documentation?

The answer is simple. It was designed with one goal in mind: to help developers create great documentation sites while maintaining a fun authoring experience. This means that it provides a framework for developers to:

  • Create beautiful documentation sites,
  • Come with pre-built features essential to all documentation sites,
  • Optimize the authoring experience to make it as simple as updating a Markdown file.

VuePress Can Co-Exist With Your Existing Codebase

This is one of the main reasons why I strongly recommend it. When it comes to maintaining documentation, one way to guarantee it will go out of date is to make it difficult for developers to update docs when writing code. If you make the authoring experience difficult by forcing developers to update things in two different places, this will cause a lot of friction and often results in documentation getting left to the wayside. This is commonly seen when developers have to maintain a third party tool like a wiki, in addition to the codebase itself.

Because it is a static site generator, this means that it can live in the same exact repo as your code.

https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/5c5dd5ad-3bf5-438a-8b33-5951ac864773/00-directory.png

A sample application with VuePress docs existing next to a Vue CLI scaffolded app (Large preview)

As you can see in this sample web app structure, your code would live in the src directory as normal, but you would simply have a docs directory to contain all of your documentation. This means you get the benefits of:

  • All documentation is now version controlled;
  • Pull requests can now contain both documentation and code changes;
  • Creating separate scripts for running local instances of your code and docs at the same time;
  • Utilize build pipelines to determine whether new documentation site deployments go in sync with code deployments or not.

The Default Theme Comes With Standard Configuration

Writing documentation is hard enough as it is, so VuePress offloads a lot of the decisions that one normally has to make and has a bunch of built-in defaults to make your authoring experience easy:

  • Writing content is done primarily with Markdown.
    This means that you can leverage your existing knowledge of Markdown syntax to style and format your text.

An example of how the Markdown is rendered in VuePress

An example of how the Markdown is rendered in VuePress (Large preview)
  • Code syntax highlighting.
    If you were building a site all on your own, you would need to wrestle with color syntax highlighting libraries. But you’re in luck because you can add code blocks in VuePress is so easy since everything is ready to go with zero configuration.

An example of how code block samples render in VuePress

An example of how code block samples render in VuePress (Large preview)
  • Front matter for defining page-level meta data.
    Even though you’re authoring in a Markdown file, you can use front matter (like YAML, JSON, or TOML) to define metadata for your page to make it even easier to manage your content!
---
title: Document Like a Pro
lang: en-US
description: Advice for best practices
tags:
  - documentation
  - best practices
---
  • Custom Markdown containers.
    In case you didn’t know, Markdown has extensions to add even more useful shortcuts to create beautiful UI components like custom containers. And since they are so useful in documentation, VuePress has already configured it so you can use it right out of the box:

A demonstration of custom containers rendered in VuePress

A demonstration of custom containers rendered in VuePress (Large preview)

Built-In Search Functionality

Let’s face it. No matter how much time we spend writing great documentation, it will ultimately amount to being useless if the users can’t find it. There are generally two approaches to this:

  1. Wait for search engine robots to slowly crawl your site in hopes that one day your users will be able to find the right page on your site. Not a great solution.
  2. Build your own search functionality, but this can be difficult to implement for static sites as there’s no server-side code running to create search indexes and perform the lookups. Not to mention this is taking development time away from the product itself. So this isn’t great either.

Luckily for us, VuePress is here to save the day once again!

VuePress comes with a built-in search functionality that generates its own “search engine” — you read that right. Without any additional database setup or configuration, VuePress is setup to scrape your entire docs to generate a simple search engine that will surface all of your h1s and h2s to your user.

An example of basic searching in VuePress’ default theme
An example of basic searching in VuePress’ default theme (Large preview)

Now, some of you may be thinking,

“What if I want something that will provide lower-level indexing for searching?”

Well, VuePress has got you covered there too because it is designed to easily integrate with Algolia DocSearch which can provide that functionality to you for free if you meet their requirements:

An example of Algolia DocSearch in action

An example of Algolia DocSearch in action (Large preview)

Sidebar Navigation Is As Simple As Toggling The Feature On Or Off

For anyone who has ever been responsible for managing content, you know how complicated it can be to built a sidebar that has nested items and then track what position the reader is on while scrolling down. So, why spend the time on that when you could be writing better docs? With VuePress, the sidebar is as simple as toggling on the front matter for a page:

A demo of how the sidebar can be automatically generated through headings
A demo of how the sidebar can be automatically generated through headings (Large preview)

Automatic Generation Of Important Meta-Data That’s Commonly Overlooked

One of the most frustrating things that a user can encounter is out-of-date documentation. When a user follows the steps and has trouble understanding why something doesn’t work, being able to easily find out the last updated date can be incredibly useful to both the user and maintainers of the project.

With a simple configuration, VuePress can ensure automatically output the last updated date on the page so your users always know the last time it was updated.

A screenshot to show the ‘Last Updated’ metadata field
A screenshot to show the ‘Last Updated’ metadata field (Large preview)

On top of that, with a little bit of configuration, VuePress also makes it incredibly easy for users to contribute to your docs by automatically generating a link at the bottom of every single page that allows users to easily create a pull request to your docs.

A demo of an automatically generated ‘Edit’ link which allows users to easily submit PRs to the docs
A demo of an automatically generated ‘Edit’ link which allows users to easily submit PRs to the docs (Large preview)

It doesn’t get much easier than that for your users.

Deployment On Any Static Hosting Site

Since VuePress is a static site generator at its core, this means that you can deploy it on any popular hosting platform such as:

  • Netlify
  • GitHub Pages
  • GitLab Pages
  • Heroku
  • Now

All you need to do to build the site is run vuepress build {{ docsDir }} with where your directory lives and you’ll have everything you need to deploy it live on the web!

Note: For more in-depth guides on how to do this, check out the official deployment guides for VuePress.

Leveraging Vue Inside Your Markdown File

I know, I know. We can use Vue.js in our Markdown?! Yes, you read that right! While technically optional, this is probably one of the most exciting aspects of VuePress because it allows you to enhance your Markdown content like you’ve never been able to do before.

Define Repetitive Data In One Place And Have It Update Everywhere With Interpolation

In the example below, you’ll see a brief example of how you can leverage local variables (like the ones define in the frontmatter) as well as globally defined ones (like the site title):

---
title: My Page Title
author: Ben Hong
---

# {{ $page.title }}

Welcome to {{ $site.title }}! My name is {{ $page.author }} and I'll be your guide for today!
Use Vue Components Within Markdown

I’ll give you a moment to collect yourself after reading this, but yes, live Vue components with a full Vue instance can be yours for the taking if you want! It will take a little bit more work to configure, but this is to be expected since you are creating custom content that will be running in your documentation.

Here is a quick example of what a Counter component would look like in a Markdown file:

A demo of using Vue Components within Markdown
A demo of using Vue Components within Markdown (Large preview)

This is perhaps the most powerful part of customization available to documentation since it means you now have the freedom to create custom content extends far beyond the abilities of standard Markdown. So whether it’s providing a demo, or some interactive code, the ideas are endless!

Next Steps

If you want to set up a beautiful documentation site for your users to learn how to use your product, it doesn’t get much easier than VuePress. And even though it might be easy to assume that VuePress should only be used by projects that use Vue.js, this could not be further from the truth. Here are just some examples of the different types of projects leveraging VuePress for their documentation sites:

At the end of the day, regardless of whether you use VuePress or not, I hope this has helped to inspire you to create better documentation for your users.

Further Resources

There are many cool things that I did not cover here in this article (e.g. theming, blogging, and so on), but if you would like to learn more, check out these resources:

Smashing Editorial
(dm, yk, il)

Source: Smashing Magazine, VuePress: Documentation Made Easy

Collective #544

dreamt up by webguru in Uncategorized | Comments Off on Collective #544


C544_svgartista

SVG Artista

SVG Artista is a useful tool that helps you animate strokes and fills in your SVG image with CSS transitions.

Check it out


C537_divi

Our Sponsor

The Ultimate WordPress Page Builder

You’ve never built a WordPress website like this before. Divi is more than just a WordPress theme, it’s a completely new website building platform that replaces the standard WordPress post editor with a vastly superior visual editor.

Try it












C544_splitting

How to Accessibly Split Text

Michelle Barker takes a look at why splitting a string of text can be problematic from an accessibility point of view, and what we can do to make sure that split text is accessible to everyone.

Read it


C544_labelstudio

Label Studio

Label Studio is a multi-type data labeling and annotation tool with standardized output format.

Check it out










C544_pattern

Delaunay

Johan Karlsson implemented the Bowyer-Watson algorithm to perform the Delaynay triangulation. Click to generate a new pattern.

Check it out



C544_js13k

Js13kGames

A friendly reminder that the epic JavaScript coding competition for HTML5 Game Developers is still running for 2 weeks.

Check it out

Collective #544 was written by Pedro Botelho and published on Codrops.


Source: Codrops, Collective #544

Bottom Navigation Pattern On Mobile Web Pages: A Better Alternative?

dreamt up by webguru in Uncategorized | Comments Off on Bottom Navigation Pattern On Mobile Web Pages: A Better Alternative?

Bottom Navigation Pattern On Mobile Web Pages: A Better Alternative?

Bottom Navigation Pattern On Mobile Web Pages: A Better Alternative?

Arthur Leonov



Whenever you hear of “mobile navigation”, what’s the first thing that comes to mind? My guess would be the hamburger slide-out menu. This design pattern had been in use since the first responsive design days, and even though a lot has changed since then, this particular pattern has not. Why is that?

How did we start using the top navigation with the hamburger menu in the first place? Is there a better alternative? In this article, I will try to explore these questions.

The History Of The Top Navigation And The Hamburger

The first hamburger menu icons started appearing in the ‘80s. It was designed by Norm Cox for the Xerox Star — the world’s first graphical user interface. He also designed the document icon for the same interface. This piece of history was uncovered by Geof Allday (who actually emailed Norm Cox). You can read the whole email response by clicking here. Later, it was seen on Windows 1 &
and DOS.

The current mobile navigation — as we know it — was popularized by Ethan Marcotte’s “Responsive Web Design” book back in 2011. Since then, the top navigation and the hamburger became the industry’s standard.

The Mobile Phone Screen Size Doubled In 10 Years

Since the original iPhone, mobile sales have been increasing year after year. 2019 is the first year that the market reached saturation point and the sales have started to decrease. But that doesn’t mean people are not using phones. By 2020, we will spend 80% of our time on the Internet on mobile phones, reports Quartz and Ciodive. Compare that to 2010, when only a fourth of Internet users were phone-based.

As phone sales increased, screen sizes have more than doubled, too. The average screen size of smartphones has increased from 3.2 inches all the way to 5.5 inches. In 2017, device makers started to adopt the taller 18:9 aspect ratio with 5.7-inch and 6-inch 18:9 displays. Now, we are starting to see 6-inch 18:9 displays become the new standard in flagships as well as in the mid-range price segments, as they have more screen area than 5.5-inch 16:9 displays, XDA-Developers reports.

An overview of how the mobile scren sizes have changed

An overview of how the mobile screen sizes have changed (Image source: Scientamobile) (Large preview)

Basically, the mobile phone screen size is getting bigger and bigger. That’s fine, but how do we adapt our design patterns to reflect these changes?

Thumb-Driven Design

I first heard of the term “thumb-driven design” from Vitaly Friedman. It’s based on the Steven Hoober’s and Josh Clark’s research on how people hold their devices.

The gist of it is that in nearly every case, three basic grips were most common. 49% held their phones with a one-handed grip, 36% cradled the phone in one hand and jabbed with the finger or thumb of the other, and the remaining 15% adopted the two-handed BlackBerry-prayer posture, tapping away with both thumbs, states Josh Clark. Steven Hoober had found that 75% of users touch the screen with only one thumb. Hence, the term thumb-driven design.

There are three main ways in which we hold our phones

There are three main ways in which we hold our phones. (Large preview)

In 2016, Samantha Ingram wrote an article named “The Thumb Zone: Designing For Mobile Users” which further explores these ideas. She defined easy-to-reach, hard-to-reach and in-between areas.

Thumb-zone mapping explained by Samantha Ingram

Thumb-zone mapping explained by Samantha Ingram (Large preview)

However, I would argue, that with increasing phone sizes, the mapping has shifted a bit:

New thumb-zone mapping adjusted to larger screen sizes

New thumb-zone mapping adjusted to larger screen sizes (Large preview)

When the phones were small, most areas were easy to reach. As our screens got bigger, the top part became virtually impossible to touch without adjusting your phone. From the example above, we can see where the most expensive screen real estate is. Yet, it’s often neglected on web pages. How can we fix this?

Bottom Navigation Pattern

Every now and then, bottom navigation pattern pops up on the web. The idea itself is quite simple: move the navigation bar further down.

Slack web page navigation reimagined with new thumb-zone mapping

Slack web page navigation reimagined with new thumb-zone mapping (Large preview)

Positioning the navigation bar at the bottom makes it easier for users to click on the menu icon, while secondary items can be moved to the top. Basically, you simply switch the order. Mobile apps have been using this logic with the tap bar pattern. It’s not a new idea in itself, but it’s still not as popular in web design as it is in app design.

This is not a foolproof solution since it raises a few critical questions, but it’s a worthy alternative. Let’s explore some of the questions that may come up.

Primary And Secondary Items

As the top of the screen is becoming hard to reach, placing the primary menu items closer to the bottom is a better alternative. But what about the other things that are just as important?

I propose two ideas to tackle this problem:

  1. Placing the search bar or any non-primary items to the top;
  2. CTA buttons should remain at the bottom next to the menu items as it is a vital part of the navigation.

A wireframe of reimagined primary and secondary navigation items.

A wireframe of reimagined primary and secondary navigation items (Large preview)

How Will This Affect Scrolling With Large Menus?

Some websites have extensive menus, submenus and everything in between. Naturally, there will be scrolling involved. How does flipping the primary/secondary items work in this scenario?

A wireframe of a reimagined large menu

A wireframe of a reimagined large menu (Large preview)

Make the primary and secondary items (menu link, logo, search input) fixed while leaving the menu list scrollable. That way, your users will be able to reach the critical things they need.

You might have concerns about the logo placement. There are two ways to go about it:

  • Placing the logo at the bottom might be a bit awkward, however, the thumb will most likely not obstruct it. It can be missed, though, as we tend to scan top to bottom.
  • A more reasonable option is to keep the logo at the top of the page, but not to have it fixed. Make it a part of the content so it goes away as you scroll. That way, people will still be able to see it perfectly.

As you can see, I used the menu label in the wireframe. Kevin Robinson had found that putting a label next to the icon increased engagement by 75%:

A wireframe of the logo placed at the top while the menu can be found at the bottom

A wireframe of the logo placed at the top while the menu can be found at the bottom. (Large preview)

How Does This Work With Handlebars?

Some operating systems and browsers tend to use the bottom area of the screen for their own purposes. iOS handlebars can get in the way of bottom navigation. Make sure the navigation is spacious enough to accommodate the iOS safe area.

iOS Handlebars and safe areas

iOS Handlebars and safe areas (Large preview)

If you place the logo dead in the center, the link might clash with the handlebar functionality. A bit of padding will do the trick.

Will The Users Adjust To This Pattern Or Find It Disorentating?

As I was writing this article, I kept thinking of whether this would turn out into a big redesign or a simple usability improvement for users navigating through your website. After all, according to Jakob’s Law, users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they’re already familiar with.

As a counter-argument to Jakob’s Law, I would like to propose Fitts Law. It argues that the time to acquire a target is a function of the distance and size of the target. Basically, the smaller and further away the target is, the higher the interaction cost. NN/g has a wonderful video explaining this in more detail:

“A bottom hamburger menu icon will have a much lower interaction cost compared to the top menu icon because it’s closer. By placing the menu CTA near the thumb, we are allowing the user to reach it’s end goal faster. Would the users find the feature disorientating if it lowers their interaction cost? Probably not.”

How Will This Integrate With The Tap Bar Pattern?

A tap bar patterns lists three to five most common first-level actions to click on a single row. You may have seen it in popular apps and some websites:

iOS Tap bar design by Mengyuan Sun
Tap bar design by Mengyuan Sun (Large preview)

Hamburger menus have sparked a lot of controversy over the years. Just take a few moments to read this article, and this one, and this one, and most importantly, this one. You’ll then understand why the tap bar became the preferred navigation pattern in mobile app design.

Nielsen argues that hidden navigation (hamburger menu) significantly decreases user experience both on mobile and desktop. On mobile, people used the hidden navigation in 57% of the cases, and the combo navigation in 86% of the cases, i.e. 1.5 times more! The combo navigation that Nielsen refers to is a tab bar pattern combined with a hamburger menu — here’s an example:

Samsung app example from Rizki Rahmat Ridha for Muzli

The Samsung app example from Rizki Rahmat Ridha for Muzli (Large preview)

It might seem like the tap bar is the perfect solution, but it has its problems too. Fabian Sebastian raised a good point that it only works on top-level views. It does not work with secondary navigation items. To solve this problem, a hamburger/tap bar hybrid was born. If you pay attention to the Samsung app, you’ll see that the last item on the menu is the “*More*” button which calls up the hamburger menu.

In essence, the bottom navigation pattern integrates quite well into the tap bar pattern if you want to combine both of them. The best place to look for good examples is in the mobile app world.

I opened up Photoshop and did a quick mockup of a few popular websites in order to explain that changing the navbar to go bottom-up is not that difficult.

Let’s first take a look at Bloomberg:

Bloomberg website with a reimagined bottom navigation

The Bloomberg website with a reimagined bottom navigation (Large preview)

Next, let’s take a look at Invision:

Invision website with a reimagined bottom navigation

The Invision website with a reimagined bottom navigation (Large preview)

Last but not least, the good ol’ Reddit:

The <a href='https://www.reddit.com/'>Reddit website</a> with a reimagined bottom navigation

The Reddit website with a reimagined bottom navigation (Large preview)

Yes, this idea does raise questions, but it’s simple enough to be adapted to the web. It does make a usability difference as the interaction cost is much lower.

That Sounds Great, But How Do I Convince My Clients?

You, as the designer, might see the potential of this pattern, but what if your client or your boss doesn’t? I would answer this problem with a couple of arguments:

  • Mobile apps have been placing valuable menu items to the bottom for years already. Just send them these two articles for starters:
  • I had noticed cases in which popular mobile apps started to shift important bits to the bottom. A good example is Uber. For them, the search bar is one of the most important items on the screen. In the old design, its position was at the top. Now, they’ve shifted it to the bottom. Could we be on to something here?

Old and new Uber search bar designs

The old and new Uber search bar design (Large preview)

Shifting important navigation items to the bottom is not a new thing in mobile app design. It’s just that — for some reason — the web industry has not caught up on this just yet.

Summary

The facts are quite clear: Phones are getting bigger, and some parts of the screen are easier to interact with than others. Having the hamburger menu at the top provides too big of an interaction cost, and we have a large number of amazing mobile app designs that utilize the bottom part of the screen. Maybe it’s time for the web design world to start using these ideas on websites as well?

I understand that all of this is not a foolproof solution for all use cases, but it’s worth a shot. It helps make the experience just a tad bit better. I’m interested in hearing your thoughts below!

Useful Reading Resources

Smashing Editorial
(cc, il)

Source: Smashing Magazine, Bottom Navigation Pattern On Mobile Web Pages: A Better Alternative?

Bottom Navigation Pattern On Mobile Web Pages: A Better Alternative?

dreamt up by webguru in Uncategorized | Comments Off on Bottom Navigation Pattern On Mobile Web Pages: A Better Alternative?

Bottom Navigation Pattern On Mobile Web Pages: A Better Alternative?

Bottom Navigation Pattern On Mobile Web Pages: A Better Alternative?

Arthur Leonov



Whenever you hear of “mobile navigation”, what’s the first thing that comes to mind? My guess would be the hamburger slide-out menu. This design pattern had been in use since the first responsive design days, and even though a lot has changed since then, this particular pattern has not. Why is that?

How did we start using the top navigation with the hamburger menu in the first place? Is there a better alternative? In this article, I will try to explore these questions.

The History Of The Top Navigation And The Hamburger

The first hamburger menu icons started appearing in the ‘80s. It was designed by Norm Cox for the Xerox Star — the world’s first graphical user interface. He also designed the document icon for the same interface. This piece of history was uncovered by Geof Allday (who actually emailed Norm Cox). You can read the whole email response by clicking here. Later, it was seen on Windows 1 &
and DOS.

The current mobile navigation — as we know it — was popularized by Ethan Marcotte’s “Responsive Web Design” book back in 2011. Since then, the top navigation and the hamburger became the industry’s standard.

The Mobile Phone Screen Size Doubled In 10 Years

Since the original iPhone, mobile sales have been increasing year after year. 2019 is the first year that the market reached saturation point and the sales have started to decrease. But that doesn’t mean people are not using phones. By 2020, we will spend 80% of our time on the Internet on mobile phones, reports Quartz and Ciodive. Compare that to 2010, when only a fourth of Internet users were phone-based.

As phone sales increased, screen sizes have more than doubled, too. The average screen size of smartphones has increased from 3.2 inches all the way to 5.5 inches. In 2017, device makers started to adopt the taller 18:9 aspect ratio with 5.7-inch and 6-inch 18:9 displays. Now, we are starting to see 6-inch 18:9 displays become the new standard in flagships as well as in the mid-range price segments, as they have more screen area than 5.5-inch 16:9 displays, XDA-Developers reports.

An overview of how the mobile scren sizes have changed

An overview of how the mobile screen sizes have changed (Image source: Scientamobile) (Large preview)

Basically, the mobile phone screen size is getting bigger and bigger. That’s fine, but how do we adapt our design patterns to reflect these changes?

Thumb-Driven Design

I first heard of the term “thumb-driven design” from Vitaly Friedman. It’s based on the Steven Hoober’s and Josh Clark’s research on how people hold their devices.

The gist of it is that in nearly every case, three basic grips were most common. 49% held their phones with a one-handed grip, 36% cradled the phone in one hand and jabbed with the finger or thumb of the other, and the remaining 15% adopted the two-handed BlackBerry-prayer posture, tapping away with both thumbs, states Josh Clark. Steven Hoober had found that 75% of users touch the screen with only one thumb. Hence, the term thumb-driven design.

There are three main ways in which we hold our phones

There are three main ways in which we hold our phones. (Large preview)

In 2016, Samantha Ingram wrote an article named “The Thumb Zone: Designing For Mobile Users” which further explores these ideas. She defined easy-to-reach, hard-to-reach and in-between areas.

Thumb-zone mapping explained by Samantha Ingram

Thumb-zone mapping explained by Samantha Ingram (Large preview)

However, I would argue, that with increasing phone sizes, the mapping has shifted a bit:

New thumb-zone mapping adjusted to larger screen sizes

New thumb-zone mapping adjusted to larger screen sizes (Large preview)

When the phones were small, most areas were easy to reach. As our screens got bigger, the top part became virtually impossible to touch without adjusting your phone. From the example above, we can see where the most expensive screen real estate is. Yet, it’s often neglected on web pages. How can we fix this?

Bottom Navigation Pattern

Every now and then, bottom navigation pattern pops up on the web. The idea itself is quite simple: move the navigation bar further down.

Slack web page navigation reimagined with new thumb-zone mapping

Slack web page navigation reimagined with new thumb-zone mapping (Large preview)

Positioning the navigation bar at the bottom makes it easier for users to click on the menu icon, while secondary items can be moved to the top. Basically, you simply switch the order. Mobile apps have been using this logic with the tap bar pattern. It’s not a new idea in itself, but it’s still not as popular in web design as it is in app design.

This is not a foolproof solution since it raises a few critical questions, but it’s a worthy alternative. Let’s explore some of the questions that may come up.

Primary And Secondary Items

As the top of the screen is becoming hard to reach, placing the primary menu items closer to the bottom is a better alternative. But what about the other things that are just as important?

I propose two ideas to tackle this problem:

  1. Placing the search bar or any non-primary items to the top;
  2. CTA buttons should remain at the bottom next to the menu items as it is a vital part of the navigation.

A wireframe of reimagined primary and secondary navigation items.

A wireframe of reimagined primary and secondary navigation items (Large preview)

How Will This Affect Scrolling With Large Menus?

Some websites have extensive menus, submenus and everything in between. Naturally, there will be scrolling involved. How does flipping the primary/secondary items work in this scenario?

A wireframe of a reimagined large menu

A wireframe of a reimagined large menu (Large preview)

Make the primary and secondary items (menu link, logo, search input) fixed while leaving the menu list scrollable. That way, your users will be able to reach the critical things they need.

You might have concerns about the logo placement. There are two ways to go about it:

  • Placing the logo at the bottom might be a bit awkward, however, the thumb will most likely not obstruct it. It can be missed, though, as we tend to scan top to bottom.
  • A more reasonable option is to keep the logo at the top of the page, but not to have it fixed. Make it a part of the content so it goes away as you scroll. That way, people will still be able to see it perfectly.

As you can see, I used the menu label in the wireframe. Kevin Robinson had found that putting a label next to the icon increased engagement by 75%:

A wireframe of the logo placed at the top while the menu can be found at the bottom

A wireframe of the logo placed at the top while the menu can be found at the bottom. (Large preview)

How Does This Work With Handlebars?

Some operating systems and browsers tend to use the bottom area of the screen for their own purposes. iOS handlebars can get in the way of bottom navigation. Make sure the navigation is spacious enough to accommodate the iOS safe area.

iOS Handlebars and safe areas

iOS Handlebars and safe areas (Large preview)

If you place the logo dead in the center, the link might clash with the handlebar functionality. A bit of padding will do the trick.

Will The Users Adjust To This Pattern Or Find It Disorentating?

As I was writing this article, I kept thinking of whether this would turn out into a big redesign or a simple usability improvement for users navigating through your website. After all, according to Jakob’s Law, users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they’re already familiar with.

As a counter-argument to Jakob’s Law, I would like to propose Fitts Law. It argues that the time to acquire a target is a function of the distance and size of the target. Basically, the smaller and further away the target is, the higher the interaction cost. NN/g has a wonderful video explaining this in more detail:

“A bottom hamburger menu icon will have a much lower interaction cost compared to the top menu icon because it’s closer. By placing the menu CTA near the thumb, we are allowing the user to reach it’s end goal faster. Would the users find the feature disorientating if it lowers their interaction cost? Probably not.”

How Will This Integrate With The Tap Bar Pattern?

A tap bar patterns lists three to five most common first-level actions to click on a single row. You may have seen it in popular apps and some websites:

iOS Tap bar design by Mengyuan Sun
Tap bar design by Mengyuan Sun (Large preview)

Hamburger menus have sparked a lot of controversy over the years. Just take a few moments to read this article, and this one, and this one, and most importantly, this one. You’ll then understand why the tap bar became the preferred navigation pattern in mobile app design.

Nielsen argues that hidden navigation (hamburger menu) significantly decreases user experience both on mobile and desktop. On mobile, people used the hidden navigation in 57% of the cases, and the combo navigation in 86% of the cases, i.e. 1.5 times more! The combo navigation that Nielsen refers to is a tab bar pattern combined with a hamburger menu — here’s an example:

Samsung app example from Rizki Rahmat Ridha for Muzli

The Samsung app example from Rizki Rahmat Ridha for Muzli (Large preview)

It might seem like the tap bar is the perfect solution, but it has its problems too. Fabian Sebastian raised a good point that it only works on top-level views. It does not work with secondary navigation items. To solve this problem, a hamburger/tap bar hybrid was born. If you pay attention to the Samsung app, you’ll see that the last item on the menu is the “*More*” button which calls up the hamburger menu.

In essence, the bottom navigation pattern integrates quite well into the tap bar pattern if you want to combine both of them. The best place to look for good examples is in the mobile app world.

I opened up Photoshop and did a quick mockup of a few popular websites in order to explain that changing the navbar to go bottom-up is not that difficult.

Let’s first take a look at Bloomberg:

Bloomberg website with a reimagined bottom navigation

The Bloomberg website with a reimagined bottom navigation (Large preview)

Next, let’s take a look at Invision:

Invision website with a reimagined bottom navigation

The Invision website with a reimagined bottom navigation (Large preview)

Last but not least, the good ol’ Reddit:

The <a href='https://www.reddit.com/'>Reddit website</a> with a reimagined bottom navigation

The Reddit website with a reimagined bottom navigation (Large preview)

Yes, this idea does raise questions, but it’s simple enough to be adapted to the web. It does make a usability difference as the interaction cost is much lower.

That Sounds Great, But How Do I Convince My Clients?

You, as the designer, might see the potential of this pattern, but what if your client or your boss doesn’t? I would answer this problem with a couple of arguments:

  • Mobile apps have been placing valuable menu items to the bottom for years already. Just send them these two articles for starters:
  • I had noticed cases in which popular mobile apps started to shift important bits to the bottom. A good example is Uber. For them, the search bar is one of the most important items on the screen. In the old design, its position was at the top. Now, they’ve shifted it to the bottom. Could we be on to something here?

Old and new Uber search bar designs

The old and new Uber search bar design (Large preview)

Shifting important navigation items to the bottom is not a new thing in mobile app design. It’s just that — for some reason — the web industry has not caught up on this just yet.

Summary

The facts are quite clear: Phones are getting bigger, and some parts of the screen are easier to interact with than others. Having the hamburger menu at the top provides too big of an interaction cost, and we have a large number of amazing mobile app designs that utilize the bottom part of the screen. Maybe it’s time for the web design world to start using these ideas on websites as well?

I understand that all of this is not a foolproof solution for all use cases, but it’s worth a shot. It helps make the experience just a tad bit better. I’m interested in hearing your thoughts below!

Useful Reading Resources

Smashing Editorial
(cc, il)

Source: Smashing Magazine, Bottom Navigation Pattern On Mobile Web Pages: A Better Alternative?

Beyond The Browser: Getting Started With Serverless WebAssembly

dreamt up by webguru in Uncategorized | Comments Off on Beyond The Browser: Getting Started With Serverless WebAssembly

Beyond The Browser: Getting Started With Serverless WebAssembly

Beyond The Browser: Getting Started With Serverless WebAssembly

Robert Aboukhalil



Now that WebAssembly is supported by all major browsers and more than 85% of users worldwide, JavaScript is no longer the only browser language in town. If you haven’t heard, WebAssembly is a new low-level language that runs in the browser. It’s also a compilation target, which means you can compile existing programs written in languages such as C, C++, and Rust into WebAssembly, and run those programs in the browser. So far, WebAssembly has been used to port all sorts of applications to the web, including desktop applications, command-line tools, games and data science tools.

Note: For an in-depth case study of how WebAssembly can be used inside the browser to speed up web applications, check out my previous article.

WebAssembly Outside The Web?

Although most WebAssembly applications today are browser-centric, WebAssembly itself wasn’t originally designed just for the web, but really for any sandboxed environment. In fact, there’s recently been a lot of interest in exploring how WebAssembly could be useful outside the browser, as a general approach for running binaries on any OS or computer architecture, so long as there is a WebAssembly runtime that supports that system. In this article, we’ll look at how WebAssembly can be run outside the browser, in a serverless/Function-as-a-Service (FaaS) fashion.

WebAssembly For Serverless Applications

In a nutshell, serverless functions are a computing model where you hand your code to a cloud provider, and let them execute and manage scaling that code for you. For example, you can ask for your serverless function to be executed anytime you call an API endpoint, or to be driven by events, such as when a file is uploaded to your cloud bucket. While the term “serverless” may seem like a misnomer since servers are clearly involved somewhere along the way, it is serverless from our point of view since we don’t need to worry about how to manage, deploy or scale those servers.

Although these functions are usually written in languages like Python and JavaScript (Node.js), there are a number of reasons you might choose to use WebAssembly instead:

  1. Faster Initialization Times
    Serverless providers that support WebAssembly (including Cloudflare and Fastly report that they can launch functions at least an order of magnitude faster than most cloud providers can with other languages. They achieve this by running tens of thousands of WebAssembly modules in the same process, which is possible because the sandboxed nature of WebAssembly makes for a more efficient way of obtaining the isolation that containers are traditionally used for.
  2. No Rewrites Needed
    One of the main appeals of WebAssembly in the browser is the ability to port existing code to the web without having to rewrite everything to JavaScript. This benefit still holds true in the serverless use case because cloud providers limit which languages you can write your serverless functions in. Typically, they will support Python, Node.js, and maybe a few others, but certainly not C, C++, or Rust. By supporting WebAssembly, serverless providers can indirectly support a lot more languages.
  3. More Lightweight
    When running WebAssembly in the browser, we’re relying on the end user’s computer to perform our computations. If those computations are too intensive, our users won’t be happy when their computer fan starts whirring. Running WebAssembly outside the browser gives us the speed and portability benefits of WebAssembly, while also keeping our application lightweight. On top of that, since we’re running our WebAssembly code in a more predictable environment, we can potentially perform more intensive computations.

A Concrete Example

In my previous article here on Smashing Magazine, we discussed how we sped up a web application by replacing slow JavaScript calculations with C code compiled to WebAssembly. The web app in question was fastq.bio, a tool for previewing the quality of DNA sequencing data.

As a concrete example, let’s rewrite fastq.bio as an application that makes use of serverless WebAssembly instead of running the WebAssembly inside the browser. For this article, we’ll use Cloudflare Workers, a serverless provider that supports WebAssembly and is built on top of the V8 browser engine. Another cloud provider, Fastly, is working on a similar offering, but based on their Lucet runtime.

First, let’s write some Rust code to analyze the data quality of DNA sequencing data. For convenience, we can leverage the Rust-Bio bioinformatics library to handle parsing the input data, and the wasm-bindgen library to help us compile our Rust code to WebAssembly.

Here’s a snippet of the code that reads in DNA sequencing data and outputs a JSON with a summary of quality metrics:

// Import packages
extern crate wasm_bindgen;
use bio::seq_analysis::gc;
use bio::io::fastq;
...

// This "wasm_bindgen" tag lets us denote the functions
// we want to expose in our WebAssembly module
#[wasm_bindgen]
pub fn fastq_metrics(seq: String) -> String
{
    ...

    // Loop through lines in the file
    let reader = fastq::Reader::new(seq.as_bytes());
    for result in reader.records() {
        let record = result.unwrap();
        let sequence = record.seq();

        // Calculate simple statistics on each record
        n_reads += 1.0;
        let read_length = sequence.len();
        let read_gc = gc::gc_content(sequence);

        // We want to draw histograms of these values
        // so we store their values for later plotting
        hist_gc.push(read_gc * 100.0);
        hist_len.push(read_length);

        ...
    }

    // Return statistics as a JSON blob
    json!({
        "n": n_reads,
        "hist": {
            "gc": hist_gc,
            "len": hist_len
        },
        ...
    }).to_string()
}

We then used Cloudflare’s wrangler command-line tool to do the heavy lifting of compiling to WebAssembly and deploying to the cloud. Once done, we are given an API endpoint that takes sequencing data as input and returns a JSON with data quality metrics. We can now integrate that API into our application.

Here’s a GIF of the application in action:

GIF of our application making parallel calls to a serverless WebAssembly function, and updating plots with the data it returns.
Instead of running the analysis directly in the browser, the serverless version of our application makes several POST requests in parallel to our serverless function (see right sidebar), and updates the plots each time it returns more data. (Large preview)

The full code is available on GitHub (open-source).

Putting It All In Context

To put the serverless WebAssembly approach in context, let’s consider four main ways in which we can build data processing web applications (i.e. web apps where we perform analysis on data provided by the user):

This figure shows four ways we can structure data processing in a web app: on the server (without WebAssembly), in the browser using JavaScript, in the browser using WebAssembly, and serverless WebAssembly.

Four different architectural choices that we can take for apps that process data. (Large preview)

As shown above, the data processing can be done in several places:

  1. Server-Side
    This is the approach taken by most web applications, where API calls made in the front-end launch data processing on the back-end.
  2. Client-Side JavaScript
    In this approach, the data processing code is written in JavaScript and runs in the browser. The downside is that your performance will take a hit, and if your original code wasn’t in JavaScript, you’ll need to rewrite it from scratch!
  3. Client-Side WebAssembly
    This involves compiling data analysis code to WebAssembly and running it in the browser. If the analysis code was written in languages like C, C++ or Rust (as is often the case in my field of genomics), this obviates the need to rewrite complex algorithms in JavaScript. It also provides the potential for speeding up our application (e.g. as discussed in a previous article).
  4. Serverless WebAssembly
    This involves running the compiled WebAssembly on the cloud, using a FaaS kind of model (e.g. this article).

So why would you choose the serverless approach over the others? For one thing, compared to the first approach, it has the benefits that come with using WebAssembly, especially the ability to port existing code without having to rewrite it to JavaScript. Compared to the third approach, serverless WebAssembly also means our app is more lightweight since we don’t use the user’s resources for number crunching. In particular, if the computations are fairly involved or if the data is already in the cloud, this approach makes more sense.

On the other hand, however, the app now needs to make network connections, so the application will likely be slower. Furthermore, depending on the scale of the computation and whether it is amenable to be broken down into smaller analysis pieces, this approach might not be suitable due to limitations imposed by serverless cloud providers on runtime, CPU, and RAM utilization.

Conclusion

As we saw, it is now possible to run WebAssembly code in a serverless fashion and reap the benefits of both WebAssembly (portability and speed) and those of function-as-a-service architectures (auto-scaling and per-per-use pricing). Certain types of applications — such as data analysis and image processing, to name a few — can greatly benefit from such an approach. Though the runtime suffers because of the additional round-trips to the network, this approach does allow us to process more data at a time and not put a drain on users’ resources.

Smashing Editorial
(rb, dm, yk, il)

Source: Smashing Magazine, Beyond The Browser: Getting Started With Serverless WebAssembly