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!

Styling Links with Real Underlines

Before we come to how to style underlines, we should answer the question: should we underline?

In graphic design, underlines are generally seen as unsophisticated. There are nicer ways to draw emphasis, to establish hierarchy, and to demarcate titles.

That’s clear in this advice from Butterick’s “Practical Typography”:

If you feel the urge to underline, use bold or italic instead. In special situations, like headings, you can also consider using all caps, small caps, or changing the point size. Not convinced? I invite you to find a book, newspaper, or magazine that underlines text. That look is mostly associated with supermarket tabloids.

But the web is different. Hyperlinks are the defining feature of the internet; and from the internet’s inception, they have been underlined. It’s a universally understood convention. The meaning is crystal clear — an underline means a link.

However, plenty of popular websites have ditched underlines: The New York Times, New York Magazine, The Washington Post, Bloomberg, Amazon, Apple, GitHub, Twitter, Wikipedia. When they removed underlines from their search results page in 2014, Google lead designer Jon Wiley argued that it created a cleaner look. Notably though, the majority of these sites have kept slight variances on the traditional lurid blue color (#0000EE) that’s been the browser default since the beginning of the web. While this provides a visual cue for the majority of users, it may not be enough to pass WCAG accessibility compliance.

Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
WCAG 2.1

WCAG do not strictly mandate using underlines for links, but it does recommend them. Color blind users need to be able to discern a link. You could differentiate them in other ways, such as with a bold font-weight. Or you could keep this long-established visual affordance. But if we’re going to use underlines, we want them to look nice. Marcin Wichary, a designer at Medium, described the perfect underline as:

[…] visible, but unobtrusive — allowing people to realize what’s clickable, but without drawing too much attention to itself. It should be positioned at just the right distance from the text, sitting comfortably behind it for when descenders want to occupy the same space.

Achieving this has traditionally required CSS tricks.

The hacks we’ve had

This is one trick all developers will be familiar with: border-bottom. By emulating an underline using border-bottom, we gain control over color and thickness. These pseudo-underlines have one problem: an overly large distance from the text. They are underneath the descenders of the letters. You could potentially solve this issue by using line-height, but that comes with its own issues. A similar technique utilises box-shadow. Marcin Wichary pioneered the most sophisticated technique, using background-image to simulate an underline. They were useful hacks but are thankfully no longer needed.

Styling real underlines

Finally we can demarcate links without sacrificing style thanks to two new CSS properties.

  • text-underline-offset controls the position of the underline.
  • text-decoration-thickness controls the thickness of underlines, as well as overlines, and line-throughs.

According to the WebKit blog:

You can also specify from-font to both of these properties which will pull the relevant metric from the used font file itself.

UX agency Clearleft make bold use of (pseudo) underlines, calling clear attention to links with colorful styling. Here’s one example of a faux underline:

a { text-decoration: none; border-bottom: #EA215A 0.125em solid;
}

Notice that this fake underline is clearly below the descender of the letter “y”:

Here’s the same paragraph, using DevTools to apply the same styling to a real underline using the new CSS properties:

a { text-decoration-color: #EA215A; text-decoration-thickness: .125em; text-underline-offset: 1.5px;
}

You’ll notice I’m using the em unit in my example code. The spec strongly encourages using it rather than pixels so that the thickness scales with the font.

These properties have already shipped in Safari and are coming in Firefox 70.

With the move to Chromium for Microsoft’s Edge browser, we will finally have cross browser support for the text-decoration-style property, which offers the options: solid (the default), double, dotted, dashed, and wavy. When combined, these new properties open up a whole range of possibilities.

Perhaps the biggest upgrade for underlines on the web, however, has come without developers needing to do anything. In the bad old days, descenders were unceremoniously sliced through by underlines, which was far from elegant. Developers used to hack around this shortcoming by applying a text-shadow that matched the background color. text-decoration-skip-ink brought a better way to make space for descenders.

The default value of auto (left) and a value of none (right)

Handily, it’s set as the new default value for underlines; meaning the look of underlines has improved while most web developers remain unaware that this property exists. Should you want an underline to cross over glyphs, you can set this property to none.

The post Styling Links with Real Underlines appeared first on CSS-Tricks.

Working with Attributes on DOM Elements

The DOM is just a little weird about some things, and the way you deal with attributes is no exception. There are a number of ways to deal with the attributes on elements. By attributes, I mean things like the id in

. Sometimes you need to set them. Sometimes you need to get them. Sometimes you get fancy helpers. Sometimes you don’t.

For this article, I’ll assume el is a DOM element in your JavaScript. Let’s say you’ve done something like const el = document.querySelector("#cool"); and matched

or whatever.

Some attributes are also attributes of the DOM object itself, so iff you need to set an id or title, you can do:

el.id; // "cool"
el.title = "my title";
el.title; // "my title";

Others that work like that are lang, align, and all the big events, like onclick.

Then there are attributes that work similarly to that but are nested deeper. The style attribute is like that. If you log el.style you’ll see a ton of CSS style declarations. You can get and set them easily:

el.style.color = "red";
module.style.backgroundColor = "black";

You can get computed colors this way too. If you do module.style.color hoping to get the color of an element out of the gate, you probably won’t get it. For that, you’d have to do:

let style = window.getComputedStyle(el);
style.color; // whatever in CSS won out

But not all attributes are like first-class attributes like that.

el['aria-hidden'] = true; // nope

That “works” in that it sets that as a property, but it doesn’t set it in the DOM the proper way. Instead, you’ll have to use the generic setter and getter functions that work for all attributes, like:

el.setAttribute("aria-hidden", true);
el.getAttribute("aria-hidden");

Some attributes have fancy helpers. The most fancy is classList for class attributes. On an element like:

You’d have:

el.classList.value; // "module big"
el.classList.length; // 2
el.classList.add("cool"); // adds the class "cool", so "module big cool"
el.classList.remove("big"); // removes "big", so "module cool"
el.classList.toggle("big"); // adds "big" back, because it was missing (goes back and forth)
el.classList.contains("module"); // true

There’s even more, and classList itself behaves like an array so you can forEach it and such. That’s a pretty strong reason to use classes, as the DOM API around them is so handy.

Another attribute type that has a somewhat fancy help is data-*. Say you’ve got:

test

You’ve got dataset:

el.dataset;
/*
{ active: "true", "placement", "top right"
*/ el.dataset.active; // "true"
el.dataset.extraWords; // "hi", note the conversion to camelCase el.dataset.active = "false"; // setters work like this

The post Working with Attributes on DOM Elements appeared first on CSS-Tricks.

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)
5 Secrets for Creating Successful Mid-Level Pages

Designing mid-level feature pages is one of the hardest parts of building or revamping your website. How do you divide your business into neat, tidy sections? How many categories should you use? Does it make sense to combine this feature with that one? How do you find the optimal balance of text, images and graphics? What keywords should you target? Are you building these pages for humans to buy your products or search engine crawlers to rank you higher? 

I could go on, but it’s a safe bet that your head is already spinning. Developing the optimal information architecture design for your business can be a major struggle — but it’s definitely one worth putting the time, energy and resources into getting right.

Here are six tips to design better mid-level feature pages:

1. Organise Your Information Architecture into the Right Categories

Instead of rushing to get a new website up as fast as you can, spend some time thinking deeply about natural categories that align with your products, services, and core values. An hour’s brainstorm and quick sketch will probably not suffice here.

proper due-diligence before building out mid-level pages will save you countless headaches down the road

Discuss with your team. Look at your competitors’ sites. Consult an SEO consulting service. Think about providing your customer with the best possible browsing experience. Consider the most important keywords that you want to rank for. Doing proper due-diligence before building out mid-level pages will save you countless headaches down the road.

When we started building mid-level feature pages for our PDF SaaS app, we thought long and hard about how to organise mid-level feature pages so users could access the information that they were seeking quickly and intuitively. After a ton of research and countless conversations with people who brought different vantage points, we decided on three overarching feature page categories: “Create PDF,” “Edit PDF,” and “Convert PDF.” These broad categories covered the three main services that we provide and allowed the flexibility for us to build out 22 more specialised mid-level pages for specific features like compression, and format conversion.

2. Keep it Simple 

You are passionate about your business and want to share your whole story with prospective clients. It’s natural to try to include everything on your mid-level feature pages, but that is a recipe for clutter and confusion. Design a clean, consistent markup that includes a healthy balance of text, images and infographics. Readers tend to skim (or completely skip) text-heavy sections. Try to use bullets, integrate graphics and err on the side of brevity whenever possible.

Make sure that your layouts are consistent across all mid-level pages. People usually notice different layouts on similar level pages. Whether they note the differences consciously or not, the inconsistencies give off an unprofessional vibe and should be smoothed out before going live. We developed a template that was easy to replicate for each additional mid-level page. Each mid-level page follows the same blueprint which simplifies navigation:

  • a header
  • a drag-and-drop upload button
  • three steps of directions
  • two or three images
  • a brief explanation of the specific feature
  • options to explore other features near the bottom of the page

3. Match Each Mid-Level Page With a Primary Keyword That You’re Targeting

Keyword research is an essential step in constructing effective information architecture. Knowing the most important search terms that you want to rank for will help you develop site structure and content that drives the right traffic to your site and keeps it there. There are lots of good tools out there to research search volume and identify related keywords. We used Google Keyword Planner, SEMRush, CanIRank and a few other keyword research tools to figure out the most valuable keywords we should go after. One of the nice things about these three tools is that they give you search volume reports on related keywords as well. Oftentimes, the keyword you expected to be best actually isn’t, and a similar iteration turns out to be a better fit. 

Most of us seasoned website architects aim to match each mid-level feature page with a high-volume keyword that is valuable to our business. By targeting specific related keywords, you are signalling to Google and other search engines what your website is about, and building topical relevance for your site. As you build out multiple mid-level pages targeting specific keywords related to your business, you will boost both your page relevancy (for each individual page) and overall website relevancy. This will help you improve your SERP rankings for the keywords that matter most to your business and drive traffic into your conversion funnel.

Remember to have only one primary keyword per page. The primary keyword should be featured prominently in your H1 header and also used consistently throughout the page. In addition, you should include several “secondary” keywords that are related to the primary keywords. Using your favorite keyword research tool, identify a primary keyword, several secondary keywords, and other related keywords to build your page around. Be cognizant not to have separate mid-level pages targeting similar keywords. It’s easy to have two pages “cannibalisze” each other — which will drive both pages’ rankings down.

4. Include a Clear, Catchy, Concise Call-to-Action

You’ve designed the perfect information architecture, done your keyword research, matched each page to a high-volume keyword, and written stellar content that includes the right balance of keywords. Finally, it’s time to let out a big sigh of relief, right? Well, not exactly. After doing all this work, it would be a shame not to nail your call-to-action. 

After doing all this work, it would be a shame not to nail your call-to-action

After all, your goal is not merely to get traffic to visit and stay on your mid-level page; it’s to move them further down the conversion funnel and actually buy your product or service! Be strategic with your language and graphics to encourage users to try out your service, sign-up for your newsletter, enter a contest, share on social media or take whatever action you want them to take. We have a big “Click to upload” button at the top of the page for users who just want to take action quickly without reading in more detail about the feature. For more investigative readers, we have other “Upload your file” buttons conveniently positioned in the middle of the page content. Our goal is to make using our software so simple and intuitive that users always can easily navigate their way further down the conversion funnel.

5. Design For Your Audience(s)

So in this long haul of building mid-level pages, are search engines or humans our primary audience? Reasonable minds disagree on this one, but for our purposes today, I recommend targeting both — because you will not be successful targeting one but not the other. 

Think about the key steps in your customer’s journey. She hears about a cool new product that you sell and decides to check it out. She searches for it on Google. If your page isn’t optimized properly to rank highly and catch her eye, it really doesn’t matter how amazing or persuasive your content is. Conversely, if your page is optimized to rank atop page 1 but includes a lacklustre call-to-action, you will have a high bounce rate and fail to convert in ways that bring your business tangible value.

Always keep the big picture in mind and design your mid-level feature pages to meet the needs of search engines and humans.

 

Featured image via DepositPhotos.

Source
p img {display:inline-block; margin-right:10px;}
.alignleft {float:left;}
p.showcase {clear:both;}
body#browserfriendly p, body#podcast p, div#emailbody p{margin:0;}

The Best (GraphQL) API is One You Write

Listen, I am no GraphQL expert but I do enjoy working with it. The way it exposes data to me as a front-end developer is pretty cool. It’s like a menu of available data and I can ask for whatever I want. That’s a massive improvement over REST and highly empowering for me as a front-end developer who desires to craft components with whatever data I think is best for a UI without having to make slew of calls for data or ask a back-end developer to help make me a new bespoke API for my new needs.

But… who builds that menu of data? Somebody does.

If that somebody is a person or team at your own company because you’ve built out your own GraphQL API for your own needs, that’s great. Now you’ve got control over what goes in there (and when and how).

But sometimes GraphQL APIs are just handed to you. Perhaps that is how your CMS delivers its data. Still cool and useful, but that control is at the mercy of the CMS. You still have a menu of options, but the menu just is what it is. No substitutes, to continue the metaphor. If the menu doesn’t have what you need, you can’t go back into the kitchen and add extra sauerkraut to that reuben or have the steak fries come with fried mushrooms.

This came up in a discussion with Simen Skogsrud and Knut Melvær on an episode of ShopTalk. Their product, Sanity, is like cloud storage for JSON data, and a CMS if you need it. A modern product like this, you’d think a GraphQL API would be a no-brainer, and indeed, they have a beta for it.

But instead of GraphQL being the main first-class citizen way of querying for and mutating data, they have their own special language: GROQ. At first glance, I’m like: eeeeeesh, there’s a way to shoot yourself in the foot. Invent some special language that people have to learn that’s unique to your product instead of the emerging industry standard.

But Simen and Knut made a good point about some of the limitations of GraphQL in the context of a third-party handing you an API: you get what you get. Say a GraphQL API offers a way to retrieve authors. A generic API for that is probably designed something like this:

{ allAuthors { author { name username avatar } }
}

But what I actually want is just how many authors we have on the site. Perhaps I wish I could do this:

{ allAuthors { count }
}

But that’s not in the API I was given. Well, too bad. I guess I’ll have to request all the authors and count them myself. I might not control the API.

This means that something like a CMS that offers a GraphQL endpoint needs to make a choice. They are either very strict and you just get-what-you-get. Or, they offer not only a GraphQL API but a way to control and augment what goes into that API.

In Santiy’s case, rather than offer the later, they offer GROQ, which is a query language that is powerful enough you can get whatever you want out of the (JSON) data. And rather than making it this proprietary Sanity-only thing, they’ve open sourced it.

With GROQ, I don’t need any permission or alterations to the API to ask how many authors there are. I’d do something like…

{ "totalAuthors": count(*[* in authors]) }

(I actually have no idea if the above code is accurate, and of course, it depends on the JSON it is querying, but it’s just conceptual anyway.)

By giving someone a query language that is capable of selecting any possible data in the data store, it has a big benefit:

  • You can query for literally anything
  • You don’t need a middle layer of configuration

But it comes at a cost:

  • Complexity of syntax
  • No middle layer means less opportunity for connecting multiple APIs, exposing only certain data based on permissions, etc.

The post The Best (GraphQL) API is One You Write appeared first on CSS-Tricks.

Maskable Icons: Android Adaptive Icons for Your PWA

You’ve created a Progressive Web App (PWA), designed an icon to represent it, and now you’re installing it to your Android home screen.

Folder containing icons with transparent backgrounds or solid backgrounds

But, if you have a recent Android phone, your icons will show up like this:

Homescreen with icons inside white circles

What happened? Well, Android Oreo introduced adaptive icons, a new icon format that enforces the same shape for all icons on the home screen. Icons that don’t follow the new format are given a white background.

However, there is a new web feature called maskable icons that is coming soon to Firefox Preview and other web browsers. This new icon format will let your PWAs have their own adaptive icons on Android.

I work at Mozilla and have implemented support for maskable icons in Firefox Preview. I’ll show you how to add them to your own PWAs for Android.

What are maskable and adaptive icons?

Until a few years ago, Android app icons were freeform and could be any shape. This meant that web apps could also reuse the same transparent icon when pinned to the home screen.

Icons of various shapes and sizes

However, manufacturers, like Samsung, wanted to make all icons on a device the same shape to keep things consistent. Some manufacturers even wanted different shapes. To deal with the variety of requirements from manufacturers and devices, Android introduced “adaptive icons.” You supply an image with extra space around the edges, and Android will crop it to the correct shape.

Icons restricted to different shapes

But web apps are designed to work on any platform, so they don’t have APIs to create these special Android icons. Instead, icons would get squished into white boxes like this:

Icons stuck in shapes with white backgrounds

Lo and behold, last September a brand new API descended upon us and was added to the W3C spec. Maskable icons allow web developers to specify a full-bleed icon that will be cropped. It’s platform agnostic, so Windows could use them for tiles or iOS could use them for icons.

Icons with detailed backgrounds restricted to different shapes

How to create maskable icons

Since the maskable icon format is designed work with any platform, the size and ratios are different from the size and ratios of Android’s adaptive icons. This means you can’t reuse the same asset.

Maskable icons can be any size, and you can continue to use the same sizes that you’d use for normal transparent icons. But when designing the icon, ensure that important information is within a “safe zone” circle with a radius equal to 40% of the image’s size.

The safe zone

All pixels within this zone are guaranteed to be visible. Pixels outside the zone may be cropped off depending on the icon shape and the platform.

Warning: If you already have an Android app, avoid copying and pasting the icon from your Android app to your web app. The ratios are different, so your icons would look too small.

Adding the icon to your Web App Manifest

Once the icons are created, you can add an entry to your Web App Manifest similar to other icon assets. The Web App Manifest provides information about your web app in a JSON file, and includes an "icons" array.

{ ... "icons": [ ... { "src": "path/to/maskable_icon.png", "sizes": "196x196", "type": "image/png", "purpose": "maskable" ] ...
}

Maskable icons use a special new key, "purpose", to indicate that they are meant to be used with icon masks. Icons with transparent backgrounds have a default "purpose" of "any", and icons can be used for multiple purposes by separating each option with a space.

"purpose": "maskable any"

Preview your icons

Do you want to see what your own maskable icons will look like? I’ve created a tool, Maskable.app, to help you evaluate how the icon appears in different shapes.

The app lets you preview your icon in various shapes that can be found on Android devices. I hope this tool helps you create unique icons for your Progressive Web Apps.

Once you’re satisfied with the results, you can start testing your app with Mozilla’s Reference Browser. This special browser is a testing ground for features before they reach Firefox Preview, and you can use it to check out how your PWA looks. Chrome is working on maskable icon support too.

Tools like PWACompat also have support for maskable icons. You can automatically generate icons for iOS and other devices based on your new maskable icons!

Time to build your own icons

If you want to more control over how your PWA icons are displayed on Android, maskable icons is the way to go. With maskable icons you can customize how your icon is displayed from edge-to-edge. Hopefully this article can get you started on creating your first maskable icon.


Icon Credits:

The post Maskable Icons: Android Adaptive Icons for Your PWA appeared first on CSS-Tricks.

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)
Nested Gradients with background-clip

I can’t say I use background-clip all that often. I’d wager it’s hardly ever used in day-to-day CSS work. But I was reminded of it in a post by Stefan Judis, which consistently was itself a learning-response post to a post over here by Ana Tudor.

Here’s a quick explanation.

You’ve probably seen this thing a million times:

The box model visualizer in DevTools.

That’s showing you the size and position of an element, as well as how that size is made up: content size, padding, margin, and border.

Those things aren’t just theoretical to help with understanding and debugging. Elements actually have a content-box, padding-box, and border-box. Perhaps we encounter that most often when we literally set the box-sizing property. (It’s tremendously useful to universally set it to border-box).

Those values are the same values as background-clip uses! Meaning that you can set a background to only cover those specific areas. And because multiple backgrounds is a thing, that means we can have multiple backgrounds with different clipping on each.

Like this:

See the Pen
Multiple background-clip
by Chris Coyier (@chriscoyier)
on CodePen.

But that’s boring and there are many ways to pull off that effect, like using borders, outline, and box-shadow or any combination of them.

What is more interesting is the fact that those backgrounds could be gradients, and that’s a lot harder to pull off any other way!

See the Pen
Nested Gradients
by Chris Coyier (@chriscoyier)
on CodePen.

The post Nested Gradients with background-clip appeared first on CSS-Tricks.

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)
Privacy Settings
We use cookies to enhance your experience while using our website. If you are using our Services via a browser you can restrict, block or remove cookies through your web browser settings. We also use content and scripts from third parties that may use tracking technologies. You can selectively provide your consent below to allow such third party embeds. For complete information about the cookies we use, data we collect and how we process them, please check our Privacy Policy
Youtube
Consent to display content from Youtube
Vimeo
Consent to display content from Vimeo
Google Maps
Consent to display content from Google