Filtering Lists Dynamically With Vue on the Server Side is Easier Than You’d Think

I recently attended the ARTIFACT conference in Austin, TX, and was inspired by a few talks about accessibility through the lens of site performance. It became clear to me that there is this tendency to rely on big JavaScript frameworks to handle the work — like React, Vue, and Angular — but that can be overkill in some cases. That is, negatively affecting site performance, and thus accessibility. At the same time, these frameworks can make development easier and more efficient for developers. My big takeaway from the conference was to see how a fast, performant experience can be balanced with my own development process.

This was on my mind as I was building a list-filtering feature on a project a few days after the conference. Pretty standard stuff: I needed a list of posts and some category filtering. I was using CraftCMS for front-end routes and templating as well as some Vue components here and there for some added JavaScript juiciness. Not a full-on “single page app” but more like a sprinkle of Vue.

The typical way one might approach this is to:

  1. render the page with an empty div using Craft/Twig
  2. mount a Vue component to that div
  3. make an Ajax call from the Vue component to an API to gather the posts as JSON
  4. render the posts and tie in the filtering.

Since the posts are held as an array within Vue, dynamic list rendering is a pretty cut and dry task.

Simple. Done, right? Well… that extra Ajax request means the user is presented with no content on the initial load depending on the user’s network, which might take some time. We could add a loading indicator, but maybe we can do better?

Preferably, the posts are rendered on the initial page request from the CMS.

But how do we get the static HTML “hooked up” with Vue for the filtering?

After taking a step back to rethink the problem, I realized I could use v-if directives to achieve the same thing with some inline JavaScript from Twig (“in the loop”). Below, I’ll show how I went about it.

My original project used CraftCMS, but I’m going to do the demos below in WordPress. This is just a concept. It can be applied to CraftCMS/Twig or any other CMS/templating engine combo.

First we need a filtering UI. This will likely go above the start of the loop in an archive template.

<?php $terms = get_terms( [ 'taxonomy' => 'post_tag', // I used tags in this example, but any taxonomy would do 'hide_empty' => true, 'fields' => 'names'
] ); if(!empty($terms)): ?> <div> Filter:  <ul class="filters"> <li class="filters__item"><button class="filters__button" :class="{'filters__button--active': tag === ''}" @click="tag = ''">All</button></li> <?php foreach($terms as $term): ?> <li class="filters__item"> <button class="filters__button" :class="{'filters__button--active': tag === '<?php echo $term; ?>'}" @click="tag = '<?php echo $term; ?>'"><?php echo $term; ?></button> </li> <?php endforeach; ?> </ul> <p aria-live="polite">Showing posts tagged {{ tag ? tag : 'all' }}.</p> </div>
<?php endif; ?>

Following along with the code, we get some tags from WordPress with get_terms() and output them in a foreach loop. You’ll notice the button for each tag has some Vue directives we’ll use later.

We have our loop!

 <div class="posts"> <?php // Start the Loop. while ( have_posts() ) : the_post(); <article id="post-<?php the_ID(); ?>" <?php post_class(); ?> v-if='<?php echo json_encode(wp_get_post_tags(get_the_ID(), ['fields' => 'names'])); ?>.includes(tag) || tag === ""' > <header class="entry-header"> <h2><?php the_title(); ?></h2> </header> <div class="entry-content"> <?php the_excerpt(); ?> </div> </article><!-- #post- --> // End the loop. endwhile; ?> </div>

This is a pretty standard WordPress loop for posts. You’ll notice some Vue directives that make use of PHP outputting CMS content.

Aside from some styling, all that’s left is the Vue “app.” Are you ready for it? Here it is:

new Vue({ el: '#filterablePosts', data: { 'tag': '' }
});

Yes, really, that’s all that’s needed in the JavaScript file to get this to work!

So, what’s going on here?

Well, instead of some JSON array of posts that gets fed into Vue, we output the posts on the initial page load with WordPress. The trick is to use PHP to output what’s needed in the Vue directives: v-if and :class.

What’s happening on the filter buttons is an onclick event handler (@click) that sets the Vue variable “tag” to the value of the WordPress post tag.

@click="tag = '<?php echo $term; ?>'"

Also, if that Vue variable equals the value of the button (in the :class directive), it adds an active class for the button. This is just for styling.

:class="{'filters__button--active': tag === '<?php echo $term; ?>'}"

For the list of articles, we conditionally display them based on the value of the Vue “tag” variable:

v-if='<?php echo json_encode(wp_get_post_tags(get_the_ID(), ['fields' => 'names'])); ?>.includes(tag) || tag === ""'

The PHP function json_encode allows us to output an array of post tags as JavaScript, which means we can use .includes() to see if the Vue “tag” variable is in that array. We also want to show the article if no tag is selected.

Here it is put together using the Twenty Nineteen theme template archive.php as a base:

<?php get_header(); ?> <section id="primary" class="content-area"> <main id="main" class="site-main"> <?php if ( have_posts() ) : ?> <header class="page-header"> <?php the_archive_title( '<h1 class="page-title">', '</h1>' ); ?> </header> <div class="postArchive" id="filterablePosts"> <?php $terms = get_terms( [ 'taxonomy' => 'post_tag', 'hide_empty' => true, 'fields' => 'names' ] ); if(!empty($terms)): ?> <div class="postArchive__filters"> Filter:  <ul class="postArchive__filterList filters"> <li class="filters__item"><button class="filters__button" :class="{'filters__button--active': tag === ''}" @click="tag = ''" aria-controls="postArchive__posts">All</button></li> <?php foreach($terms as $term): ?> <li class="filters__item"> <button class="filters__button" :class="{'filters__button--active': tag === '<?php echo $term; ?>'}" @click="tag = '<?php echo $term; ?>'" aria-controls="postArchive__posts"><?php echo $term; ?></button> </li> <?php endforeach; ?> </ul> <p aria-live="polite">Showing {{ postCount }} posts tagged {{ tag ? tag : 'all' }}.</p> </div> <?php endif; ?> <div class="postArchive__posts"> <?php // Start the Loop. while ( have_posts() ) : the_post(); ?> <article id="post-<?php the_ID(); ?>" <?php post_class(); ?> v-if='<?php echo json_encode(wp_get_post_tags(get_the_ID(), ['fields' => 'names'])); ?>.includes(tag) || tag === ""' > <header class="entry-header"> <h2><?php the_title(); ?></h2> </header> <div class="entry-content"> <?php the_excerpt(); ?> </div> </article><!-- #post- --> <?php endwhile; // End the loop. ?> </div> </div>  <?php // If no content, include the "No posts found" template. else : get_template_part( 'template-parts/content/content', 'none' ); endif; ?> </main> </section> <?php
get_footer();

Here’s a working example on CodePen

See the Pen
Dynamic List Filtering in Vue using Server-side data fetching
by Dan Brellis (@danbrellis)
on CodePen.

Bonus time!

You may have noticed that I added in an aria-live="polite" notifier below the filter button list to let assistive tech users know the content has changed.

<p aria-live="polite">Showing {{ postCount }} posts tagged {{ tag ? tag : 'all' }}.</p>

To get the postCount Vue variable, we add some extra JavaScript to our Vue component:

new Vue({ el: '#filterablePosts', data: { 'tag': '', 'postCount': ''
}, methods: { getCount: function(){ let posts = this.$el.getElementsByTagName('article'); return posts.length; } }, beforeMount: function(){ this.postCount = this.getCount(); }, updated: function(){ this.postCount = this.getCount(); }
});</p>

The new method getCount is used to select the article elements in our component div and return the length. Before the Vue component mounts we get the count to add to our new Vue postCount variable. Then, when the component updates after the user selects a tag, we get the count again and update our variable.

Get Started With UI Design With These Tips To Speed Up Your Workflow

Get Started With UI Design With These Tips To Speed Up Your Workflow

Get Started With UI Design With These Tips To Speed Up Your Workflow

Tomáš Čakloš

This article is about creating limits and rules to follow throughout the entire design process. There is an unlimited number of ways in which you can combine elements in a user interface — and so you’ll need to set some rules and boundaries, or else the design workflow might become an unpleasant chore. You might be struggling with all of the possibilities and trying to pick the best option among many “correct” options. By setting (and following) some basic rules, you will make your design look more consistent, too.

This article is intended for beginner UI designers. You don’t need a lot of experience in order to be able to follow the tips and tricks shared in it.

setting limits and rules helps designing
Having a system is important!

The Importance of Making Your User-Interface Design Consistent

Let’s start at the very beginning. You want your design to look good and trustworthy, and you need to avoid chaos at all costs. For this to happen, it’s very important to have a system for your design work.

Your developers will appreciate a system, too — they’ll love the fact that your design has order, and that you are making their work easier.

A System Of Resizing By A Predetermined Size

It doesn’t matter whether you want to resize a text block, resize an image, or adjust some white space. You need to decide how big each element will be. And I’ll bet you have been in this situation: Have you ever chosen a size for an element, and after five minutes, you change it, and then again, and maybe again and again?

Which size is perfect? It could be one of the ones you tried, right? You need to avoid this endless time-wasting trap!

Start By Choosing The Basic Unit: The 8-Pixel Grid

To make the whole design look cleaner, it’s helpful to first set the measurement value that will then determine all of the sizes. It is completely up to you what value you choose, but quite often, the best option is to stick to a few proven rules. And one of these rules is to resize and move elements by exactly eight pixels. This rule will streamline your decision-making.

Aside on px versus dp: In addition to pixels (px), you may have heard of the term dp being used in screen design and prototyping. The dp unit is short for “density-independent pixel.” The unit is relative to a 160-dpi screen, so 1 dp is equal to 1 pixel on a 160-dpi screen, and equal 2 pixels on a 320-dpi screen, and so on. The numeric value formula is px = dp * (dpi/160).

Note: If you work with smaller elements or objects, it’s also OK to use 4-pixel increments, instead of 8 — occasionally, you can make further adjustments, when required.)

But Why Exactly 8 Pixels?

There are a few reasons why eight often works like a “magic number” here:

  • Eight pixels is a sufficient minimum “jump”.
  • Eight is a great number because it is divisible by four and two.
  • If you use eight, you can easily resize any element without ending up with half pixels, as 8 / 2 = 4, 4 / 2 = 2, and 2 / 2 = 1. If, on the other hand, you start with 10, you’ll end up with 5 pixels, then 2.5 pixels, then 1.25 pixels. When designing for screen, you’d like to avoid half pixels as much as possible. By using whole pixels, elements in the design will align to precise pixel boundaries, and so will look crisper.
  • Multiples of eight (8, 16, 24, 32, 40, 48, 56, 64, 72, 80, etc.) are intertwined with binary values (1, 2, 4, 8, 16, 32, 64, 128, 256, 512, etc.).
  • Finally, the numbers are easy to remember.

What Are The Advantages Of Using An 8-Pixel Grid?

  • As a designer, your decision time is precious. This will make you faster and more efficient.
  • If you are working with a developer, you can create a system that will help you and your team. If the developer needs to make some quick changes, he can adjust the values by 8-pixel increments. This will ensure consistency and order.
  • People using your website will feel comfortable when they visit it. They will trust the website, and it’ll be easier for them to use the interface.
8 pixel grid
An effective way of using the 8px grid
using an 8 pixel grid
The result of using an 8px grid

Work With A Grid To Lay Out All Elements

Horizontal Harmony

I’m sure you have already used a grid when designing websites. Using a grid helps you to accurately place all elements on the digital canvas.

The grid forms the skeleton of your interface and determines where you can place elements. The template holds the composition, and it defines clear boundaries so that your design will be more consistent. Now it will be easier for you to decide where to put the elements. As you gain more experience, you can update the boundaries as needed.

But how do you create this grid? We will cover the specifics next. Basically, the number and size of columns may be random and depends on your needs. The more detailed your design, the more columns the grid will require. If you’re hesitant, ask an experienced colleague for assistance.

Also, I recommend that you read “A Comprehensive Guide to UI Design”, which should help you understand user-interface design a bit more in depth.

horizontal harmony
Horizontal harmony

Vertical Harmony

Similar to maintaining horizontal harmony, it is important to keep vertical distances consistent in a design as well. Like the rows in a spreadsheet, they help you to keep text at evenly spaced intervals.

How big should these rows be? Again, it’s up to you. However, I recommend using 8 pixels or multiples of 8 (such as 16). Redefine boundaries where elements or text are to be aligned.

vertical harmony
Vertical harmony

Picking Font Sizes The Right Way

If you look at some well-crafted designs, you will see consistency in font sizes. This is for a reason.

Note: Keep in mind also that you need only two, maybe three, fonts in your design. However, selecting the right typefaces and making them work together is beyond the scope of this tutorial.

Begin by defining a few key font sizes to use throughout the project. (For example, it would be foolish to use 30, 31, and 32 pixels. Rather, combine these three very similar sizes into one.)

Standard Font Sizes Bring Two Benefits:

  • Your design will be more consistent and more elegant.
  • It will speed up the design process and make you more efficient.

Font Sizes

When you are defining font sizes, make sure not to increase sizes by the same increment. When you are enlarging text, it should be non-linear. This means that the larger the text you are creating, the larger the increment should be.

system in font sizes
Having a system in font sizes

Let’s say you have a text block with a 12-pixel font size, and you want to enlarge it. You try 14 pixels, and you are satisfied. But then imagine that you have a large headline (40 pixels) and you want to make it bigger. Would you increase the size by only 2 pixels, from 40 to 42? Of course not. Optically, the text requires a much bigger change. You might need to increase it by 24 pixels, giving you a bigger 64-pixel headline.

In short, this means that the bigger you want the text to be, the larger the increment you will need to use. This very simple principle applies not only to text, but also to the size of buttons, white space, and everything else.

It is typically based on a geometric progression. Here is a very useful chart demonstrating font scale:

geometric progression
Geometric progression

However, for typography, one proven scale is used with font sizes that you will want to stick with forever. The scale is 12, 14, 16, 18, 20, 24, 30, 36, 48, 60, and 72 pixels.

typography scale
Proven typography scale for sizes

Text Line Height

Once you have defined all font sizes, you will want to take care of line spacing. For line height, use increments of 4 pixels again. For example, for 16-pixel text, let’s set the line height to 24 pixels. If you want the text to breathe more, then increase the row height by 4 pixels to 28.

Define Your Project’s Colors

Do you know how many color combinations exist? A lot! You will waste too much time if you don’t predefine shades of color. You can’t limit yourself to black, white, and, say, blue. For each color, you will need other shades, and it is important to set them in advance, so that the shades are consistent throughout your design project. We don’t want to create chaos in the design. Aim for 5 to 10 shades for each color. I prefer to define 9 shades for each color.

Let’s take a closer look at color shades.

Why 9 Shades Of Each Color?

  • The first advantage is color naming. Whether you are using a graphics editor or CSS code, you will definitely benefit from this tip. Each shade would be assigned a number, such as 100, 200, 300, 400, 500, 600, 700, 800, and 900. (Why hundreds? Typically, this is how cuts of typefaces are also organized.)

  • Secondly, 9 is a handy number for defining colors. The best way to prepare these shades is to prepare a row of 9 squares and fill the squares with colors. The one in the middle will be the base color. Then, you define the lightest shade (at the far left) and the darkest shade (at the far right). The next step is to select the hues in between.

nine shades of each color
Nine shades of each color

Prepare The Different Sizes, Types, And States Of Elements

When working on a design, you will usually work with a countless number of icons, buttons, and other components. Again, it’s a good idea to prepare in advance several sizes for them, and limit the options to as few as possible. During the design process, do not add other sizes, and don’t try to adjust the size of components to suit your needs. Instead, just use the ones you have already defined, and the whole design will be more consistent and clean.

Let’s look at buttons as an example. When you begin, you’ll need to define their hierarchical structure. To do so, make a button with a primary action, a button with a secondary action, and perhaps another button with a less important action. For each button, specify its status (active, inactive) and the color variant. Always try to reduce the number of elements to the most important ones.

button styles
An example of button styles

Define Other Elements’ Properties

User interface designers often use shadows in their design work. However, for less-experienced designers, shadows can sometimes be a struggle. When creating a shadow, you must set the shadow’s distance along the x-axis and y-axis, and also the blur radius, color, and transparency. Shadows can take a lot of time to fine-tune, which is why you’ll want to prepare them before diving into the design. It is helpful to prepare a set of shadows (using the same method as for colors), and then just apply them throughout the design process.

Also, be aware of all the other properties of elements that you will be working with, such as corner radius, transparency, and color gradients.

shadow styles
An example of shadow styles

White Space

Properly adjusting white space is important. Whether you offset elements from the outside (margin) or from the inside (padding), you should rely on the magic number of 8 again. Increase the offset by 8 pixels (4 for small elements). As with font size, the larger the gap you want, the larger the increment will have to be (again, you’ll need to define these increments in advance).

white space
White space

Conclusion

To make your designs clean and consistent, define some boundaries and a clear path through the process.

When working on each element of your design, keep in mind the following:

  • See whether you have used it already somewhere in your design. If so, you can simply copy that element.
  • Follow a horizontal and vertical rhythm, and adjust the size of elements using the steps that you defined at the very beginning.
  • Avoid complicated decisions and never-ending battles with pixels. Have a system in place.
  • Do not create the same element twice. If there is order in your design, your work will be better and more efficient, you will be able to iterate faster, and you will be able to communicate with the developers more easily. The developers will set variables that follow your styles, so define them clearly. You’ll get a clean design, and the developers will be able to create better and more sustainable code. Everyone will be happy.
Smashing Editorial (mb, il)
Dark Mode Favicons

Oooo! A bonafide trick from Thomas Steiner. Chrome will soon be supporting SVG favicons (e.g. <link rel="icon" href="/icon.svg">). And you can embed CSS within an SVG with a <style> element. That CSS can use a perfers-color-sceme media query, and as a result, a favicon that supports dark mode!

<svg width="100" height="100" xmlns="http://www.w3.org/2000/svg"> <style> circle { fill: yellow; stroke: black; stroke-width: 3px; } @media (prefers-color-scheme: dark) { circle { fill: black; stroke: yellow; } } </style> <circle cx="50" cy="50" r="47"/>
</svg>

Safari also supports SVG, but it’s different…

<link rel="mask-icon" href="/favicon.svg" color="#990000">

You specify the color, so there is no opportunity there for a dark mode situation. A little surprising, since Apple is so all-in on this dark mode stuff. I have no idea if they plan to address that or what.

The post Dark Mode Favicons appeared first on CSS-Tricks.

Meet “Inclusive Components”: Accessible, Bulletproof Front-End Patterns

Meet “Inclusive Components”: Accessible, Bulletproof Front-End Patterns

Meet “Inclusive Components”: Accessible, Bulletproof Front-End Patterns

Vitaly Friedman

Front-end accessibility is still somewhat mysterious these days. How do we build accessible buttons and dropdowns? What about keyboard-friendly tooltips, tabs and notifications? Or inclusive accordions, sliders, data tables and modals? Let’s figure it out together. Meet Inclusive Components, our new handbook for building fully accessible digital products. Download a free sample PDF (1.1 MB).

<img style="border-radius:11px;" srcset="https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/50529a0d-1825-4279-a1df-b0276d5ee68c/page01-b-opt.png 400w, https://res.cloudinary.com/indysigner/image/fetch/f_auto,q_auto/w_800/https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/50529a0d-1825-4279-a1df-b0276d5ee68c/page01-b-opt.png 800w, https://res.cloudinary.com/indysigner/image/fetch/f_auto,q_auto/w_1200/https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/50529a0d-1825-4279-a1df-b0276d5ee68c/page01-b-opt.png 1200w, https://res.cloudinary.com/indysigner/image/fetch/f_auto,q_auto/w_1600/https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/50529a0d-1825-4279-a1df-b0276d5ee68c/page01-b-opt.png 1600w, https://res.cloudinary.com/indysigner/image/fetch/f_auto,q_auto/w_2000/https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/50529a0d-1825-4279-a1df-b0276d5ee68c/page01-b-opt.png 2000w" src="https://res.cloudinary.com/indysigner/image/fetch/f_auto,q_auto/w_400/https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/50529a0d-1825-4279-a1df-b0276d5ee68c/page01-b-opt.png" sizes="100vw" alt="Meet Inclusive Components, our new book for building accessible, inclusive interfaces. Written by one-and-only Heydon Pickering.”>

Print + eBook

{ “sku”: “inclusive-components”, “type”: “Book”, “price”: “39.00”, “prices”: [{ “amount”: “39.00”, “currency”: “USD”, “items”: [ {“amount”: “29.00”, “type”: “Book”}, {“amount”: “10.00”, “type”: “E-Book”} ] }, { “amount”: “39.00”, “currency”: “EUR”, “items”: [ {“amount”: “29.00”, “type”: “Book”}, {“amount”: “10.00”, “type”: “E-Book”} ] } ] } $
39.00

Quality hardcover. Free worldwide shipping. 100 days money-back-guarantee.

eBook

{ “sku”: “inclusive-components”, “type”: “E-Book”, “price”: “18.00”, “prices”: [{ “amount”: “18.00”, “currency”: “USD” }, { “amount”: “18.00”, “currency”: “EUR” } ] } $
18.00

DRM-free, of course. ePUB, Kindle, PDF.
Included with Smashing Membership.

About The Book

At its heart, Inclusive Components is a detailed, practical handbook for building fully accessible interfaces. The book examines 12 common interface patterns — accordions, tables, modals, notifications, tabs, toggles, and everything in-between — through the lens of inclusion. The result is accessible and robust components we author, plug in, and use daily.

For years, Heydon Pickering, a seasoned front-end developer with a focus on accessibility, has been writing about accessible solutions. We’ve teamed up with Heydon to produce a book with common challenges and solutions that he’s been refining over all these years.

For each component, the in-depth explorations are meticulously illustrated and all solutions are available as bulletproof code snippets, applicable to your work right away. Bonus: you’ll learn how to build your own accessible components with inclusive design in mind — all in a single book. Jump to table of contents ↓

332 pages. Quality hardcover with a stitched binding and ribbon page marker. The eBook is available as PDF, ePUB, Amazon Kindle. Written and designed by Heydon. Download a sample PDF (1.1 MB).

The cover of Inclusive Components, a new book by Heydon Pickering.
The inner spreads of Inclusive Components.

Print + eBook

{ “sku”: “inclusive-components”, “type”: “Book”, “price”: “39.00”, “prices”: [{ “amount”: “39.00”, “currency”: “USD”, “items”: [ {“amount”: “29.00”, “type”: “Book”}, {“amount”: “10.00”, “type”: “E-Book”} ] }, { “amount”: “39.00”, “currency”: “EUR”, “items”: [ {“amount”: “29.00”, “type”: “Book”}, {“amount”: “10.00”, “type”: “E-Book”} ] } ] } $
39.00

Quality hardcover. Free worldwide shipping. 100 days money-back-guarantee.

eBook

{ “sku”: “inclusive-components”, “type”: “E-Book”, “price”: “18.00”, “prices”: [{ “amount”: “18.00”, “currency”: “USD” }, { “amount”: “18.00”, “currency”: “EUR” } ] } $
18.00

DRM-free, of course. ePUB, Kindle, PDF.
Included with Smashing Membership.

Table Of Contents

Each chapter tackles a single component, addressing how different and vulnerable people might read and interact with it, and how they can be better accommodated. Download a sample PDF (1.1 MB).

1. Toggle Buttons
+
2. A Todo List
+
3. Menus & Menu Buttons
+
4. Tooltips & Toggletips
+
5. A Theme Switcher
+
6. Tabbed Interfaces
+
7. Collapsible Sections
+
8. A Content Slider
+
9. Notifications
+
10. Data Tables
+
11. Modal Dialogs
+
12. Cards
+
Inclusive Components, a peek inside.
A peek inside of Inclusive Components. A photo by Drew McMellan. See more photos. (Large preview)

About The Author

Heydon Pickering

Heydon Pickering (@heydonworks) has worked with The Paciello Group, The BBC, Smashing Magazine, and Bulb Energy as a designer, engineer, writer, editor, and illustrator. He was shortlisted for Designer Of The Year in The Net Awards.

Heydon previously wrote Inclusive Design Patterns which sold over 10,000 copies. Proceeds from this title were donated to the ACLU and The Democratic Socialists Of America, to help these organizations fight fascism and create a more inclusive society.

Here’s what Heydon shared when asked why he decided to write this book:

“A few years back, I was getting bored with web design. Then responsive design came along, presenting me with fresh challenges. It made my life and my job interesting again. Then I discovered the world of web accessibility, and my enthusiasm was once again renewed. Some people seem to think I do web accessibility because I feel morally obliged, or that I would feel guilty if I didn’t.

While I believe strongly that all sorts of people should be able to access the web, I’m also grateful for the web accessibility challenges I’ve encountered, and covered in this book, for stimulating me, and giving my work new depth.

I have written this book because I want you to know how fun it can be to make your interfaces more accessible, as well as how accomplished you can feel for having done so. Thank you for reading this, and hopefully the book as well.”

Testimonials

Artem Sapegin“Inclusive Components is a very deep and thorough explanation of development of accessible components with real world examples. Heydon Pickering shows several alternative approaches and explains pros and cons of each. It’s also a pleasure to read!”

Artem Sapegin, front-end developer, Wayfair

Sarah Federman“Inclusive Components is chock-full of practical and comprehensive advice on building accessible UI. It’s my go-to resource after the official WCAG and ARIA documentation. I’ve found it extremely helpful when building our design system!”

Sarah Federman, senior front-end developer

Andy Bell“What Heydon achieves with his work on Inclusive Components is a pragmatic, friendly and approachable set of guides that help you to generate not just accessible components, but also resilient and progressive starting-points that will help you to build better websites and web apps in general. I often describe this work as crucial learning material for this exact reason.”

Andy Bell, independent designer & developer

A preview of the book, with examples ranging from accordions to toggles, tables, notifications, dialogs etc. Download a sample PDF (1.1 MB). Large preview.

Why This Book Might Be For You

The devil is in the detail and often the things you do with good intentions can impose accessibility barriers unknowingly. Inclusive Components is for every front-end developer who wants to learn how to detect and address potential accessibility issues in their work. The book will teach you:

  1. How to use <button> elements, how to apply styles to your toggle buttons, and how to label them.
  2. How to create managed lists that allow users to create and delete content — in an inclusive way.
  3. How to address and resolve accessibility issues with navigation menus and submenus (aka “dropdowns”).
  4. How to create accessible and keyboard-friendly tooltips and toggletips.
  5. How to create a “dark mode” theme that’s both accessible and maintainable long-term.
  6. How to build an accessible content slider to prevent harm for motion-sensitive people.
  7. How to create inclusive notifications with live regions to communicate with your users through visual and aural channels simultaneously.
  8. How to create data tables that are semantically correct, responsive, and sortable.
  9. How to build accessible dialogs and modal dialogs with performance and inclusive design in mind.
  10. How to create and group inclusive cards (e.g. for teasers).

Technical Details

Community Matters ❤️

With Inclusive Components, we’ve tried to create a very focused handbook with applicable, long-living solutions and strategies to create accessible and inclusive interfaces.

Our hope is that with Heydon’s book, you will be able to make better design and coding decisions as you build your interfaces. Perhaps it will even become one of those reference books you’ll reach to every time you need to build one of those common UI components.

Producing a book takes quite a bit of time, and we couldn’t pull it off without the support of our wonderful community. A huge shout-out to Smashing Members for their ongoing support in our adventures. As a result, the eBook is and always will be free for Smashing Members. Plus, Members get a friendly discount when purchasing their printed copy.

Stay smashing, and thank you for your ongoing support, everyone!

The cover of Inclusive Components, a new book by Heydon Pickering.

Print + eBook

{ “sku”: “inclusive-components”, “type”: “Book”, “price”: “39.00”, “prices”: [{ “amount”: “39.00”, “currency”: “USD”, “items”: [ {“amount”: “29.00”, “type”: “Book”}, {“amount”: “10.00”, “type”: “E-Book”} ] }, { “amount”: “39.00”, “currency”: “EUR”, “items”: [ {“amount”: “29.00”, “type”: “Book”}, {“amount”: “10.00”, “type”: “E-Book”} ] } ] } $
39.00

Quality hardcover. Free worldwide shipping. 100 days money-back-guarantee.

eBook

{ “sku”: “inclusive-components”, “type”: “E-Book”, “price”: “18.00”, “prices”: [{ “amount”: “18.00”, “currency”: “USD” }, { “amount”: “18.00”, “currency”: “EUR” } ] } $
18.00

DRM-free, of course. ePUB, Kindle, PDF.
Included with Smashing Membership.

More Smashing Books

Promoting best practices and providing you with practical tips to master your daily coding and design challenges has always been (and will be) at the core of everything we do at Smashing. In the past few years, we were very lucky to have worked together with some talented, caring people from the web community to publish their wealth of experience as books that stand the test of time. Alla, Adam and Andy are some of these people. Have you checked out their books already?

Smashing Editorial (il, cm)
3 Essential Design Trends, December 2019

This month’s collection of design trends is a gift to behold. Each of the trends are highly usable options that are versatile, giving you plenty of room to play and make them your own. That’s the best kind of trend, right?

Here’s what’s trending in design this month.

Whimsical Illustrations

It seems like whimsical illustrations are practically everywhere. Fun drawings that can be anything from line-style illustrations to full-color pieces of art are popping up in all kinds of projects – even for brands, companies, of business types that you might not expect. Whimsical illustrations are trending for a number of reasons:

  • They create just the right feel for a project that doesn’t need to be heavy;
  • You can design the main imagery to be whatever you want;
  • They provide a source of delight for users;
  • Every project using illustrations looks a little different, creating a custom design;
  • The proliferation of illustration kits has made creating this style easier than ever.

The thing that might be best about using whimsical illustrations is the personality they bring to a project. The right illustrated element – or series of elements – can emotionally tie users to the project while setting a scene. The possibilities are almost endless. Illustrations don’t have to apply only to lighthearted projects, even though “whimsical” might imply it. The illustrations for Violence Conjugale feature a sense of whimsy for a serious topic, and it works. (Maybe we all need a little more whimsy in our life?)

Black and Blue

It’s a classic color combination that’s making a big return to projects – black and blue palettes.

The contrast of a dark background and blue accents is eye-appealing and creates a harmonious and pleasing visual aesthetic. The projects below use this color trend in different ways, all with the same cool result.

Arm Yourself uses a black background with a black and white illustration to make bright blue lettering and accents pop off the screen. Color draws users into the interactive part of the homepage design with a drag to the bullseye instruction.

Carey uses a lighter, more teal blue on a charcoal black background for a lighter feel. The blue color pulls from the logo and brand mark with buttons that have a lot of contrast from the background and brighter elements in the design. The blue continues on the scroll with bold text on a fully black background, showing the versatility of this color choice.

Adera uses a simple blue button on a black and white image to create contrast and draw the eye to the active part of the design. The color palette flips on the scroll to a blue background with darker elements on top. Contrast is a vital factor here, helping dictate user flow and how to digest and interact with information on the screen.

Anything-But-Flat Scroll Transitions

Disclaimer: I am totally in love with this trend and can’t get enough of it.

Anything-but-flat scroll transitions is a versatile design trend that’s visually interesting and contributes to usability. (It’s a win-win!) This trend is exemplified by a transition element between “screens” or “scrolls” with a visual that isn’t just a box or flat line. Think of how most parallax designs or screen-based vertical viewpoints advance from one box to another. With this trend the transition is more fluid. The examples below do this in different ways:

Oroscopo takes advantage of the blobs trend that’s been popular all year with blob elements that create waves between content elements. Contrast between light and dark backgrounds magnify this effect, while other blog shapes create visual consistency.

MAHA Agriculture Microfinance uses a simple line between scroll elements but it’s got a texture to it that makes it just a little more visually interesting that having a flat line between the hero image area at the top and the secondary content block.

Akaru uses a pretty amazing animated fluid design to offset the branding in the center of the screen. The animation carries into the background of the content below the scroll. (You’ll want to scroll all the way to the bottom of this one to see the transition from the dark animation back to white.) The effect is stunning.

Here’s why this trend works so beautifully: The fluid transition is somewhat disruptive because the user doesn’t expect this visual and seeing the edge of a transitional element encourages scrolling. Whether the user scrolls to see how the transition changes or to preview more content is irrelevant as long as the interaction happens. It’s brilliant and beautiful, especially on desktop screens.

Conclusion

The best design trends are versatile enough that you can use them in new projects or incorporate them into websites that are already live for a little refresh.

A custom illustration can add extra interest to a hero area or page within your website, a tweak to the color palette can create a brilliant black and blue combination, or a neat transition can help users engage with the scroll.

If you want to spice up a project, these trends fit the bill for sure.

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;}

Smashing Podcast Episode 4 With Heydon Pickering: What Are Inclusive Components?

Smashing Podcast Episode 4 With Heydon Pickering: What Are Inclusive Components?

Smashing Podcast Episode 4 With Heydon Pickering: What Are Inclusive Components?

Drew McLellan

Jina Anne In this episode of the Smashing Podcast, Drew McLellan talks to Heydon Pickering about his new book, Inclusive Components. Heydon is known for his work and writing on Accessibility, so what is Inclusive Design, and where do components come into play? Heydon eplains all this and more in this episode. You can listen below, or subscribe wherever you get your podcasts.

Show Notes

Transcript

Drew McLellan: He’s a freelance web accessibility consultant, interface designer and writer. His work focuses on accessible user experience design, as well as writing and editing for Smashing Magazine. He’s the author of the acclaimed book about accessible web application design, Apps For All, and has just released a new book, Inclusive Components, all about how to build accessible web interfaces, again, with Smashing Magazine. So he’s clearly an expert on the subject of accessible design, but did you know he was the first male human to jump the Sydney Harbor Bridge in a speedboat? My Smashing friends, please welcome Heydon Pickering. Hi, Heydon. How are you?

Heydon Pickering: I’m smashing. I’m on brand.

Drew: I wanted to talk to you today about the subject of your new book, Inclusive Components.

Heydon: Yes.

Drew: Obviously just a two word title, but I feel like each of those words does a lot of heavy lifting. Starting at the end, as is obviously logical to do, components, is this about sort of component-based design? What is that?

Heydon: Yeah, so I suppose it’s been a while now since people, front end developers, designers and everyone who collaborates on making interfaces, started to think about things in terms of components and dividing things up into digestible and reusable morsels. And I suppose if you’re not familiar with that way of working for whatever reason, it really is a bit like electronic components. My father is an electronic engineer. He works in the sort of analog world of circuit boards and solder and all that kind of thing.

Heydon: In fact, he’s made some components, very small components, which have been used to regulate the current going into electromagnets at CERN. And he had a lot of faith in me as a kid, because he got me to actually solder some of the bits for them. I think that batch has now been retired, so don’t worry about my poor soldering, my poor teenage soldering, being involved in CERN anymore. But yeah, I think it is analogous to … Oh, there’s too many analogs in there.

Heydon: It’s analogous to analog circuit boards in that the idea is you have single responsibilities for individual parts or components and, together, they make the circuit and, together, they augment the current in the case of a circuit or the, I guess, the interface or the outcome in whatever way, in a design system or in an interface as manifested through a design system. And so, Inclusive Components because I wanted to address the fact that, while, I mean, accessibility does tend to get left behind generally when we advance what we’re doing in different arenas, and I wanted to bring accessibility and, in the broader sense, inclusive design to bear on this kind of new way of thinking and making things using components or modules or whatever you want to call them.

Heydon: So the idea was to both bring accessibility to design systems, but by the same token, think systemically when it comes to trying to address accessibility. Think about solving kind of one problem in one place in terms of accessibility and making sure that simply propagates around the pattern [inaudible 00:03:16] the design system at large.

Drew: In a sort of a practical sense, what does it actually look like to work in a component based way? What might an example of a component be?

Heydon: So, there’s different ways of conceiving and coding components. I tend to get straight into the sort of nitty gritty of it, past the conceptual stuff and think about how I might organize the code. I’ve actually come to focus a lot on custom elements, or if not custom elements, then normal elements but with kind of JavaScript behavior attached to them in a kind of isolated, componentized way. I really like the idea of components which are interoperable. And by that, I mean that they can be used across different frameworks and systems and approaches and technical stacks. And custom elements are nice in that because they’re native. You can define them in one place and then they could be used, say, in a react application or they could be used in a view application or they could be used in an angular application, or whatever sort of larger state management technology you’re using.

Heydon: So for me, usually a component will probably be a custom element. I’ve worked on a project recently which isn’t so much focused on accessibility, although I’ve tried to make it as accessible as possible, called Every Layout, and it’s all about kind of trying to isolate very specific kind of algorithms for CSS layout. And they’re defined as custom elements and kind of they sort of deploy themselves and run their own CSS and work as kind of like primitives within the larger system.

Drew: I mean, in actual practical terms, we’re talking a component might be something like a form field?

Heydon: Yeah, so it could be something as simple as an input. Say, like a text input or it could be something complex like a tab interface. And so, the idea with Inclusive Components was to take the concept of one component with its, hopefully, single purpose, like a text input, and then think about all of the different things that could trip up different kinds of people and try and avoid them. Not avoid the people, avoid the problems. It’s not so much about including people, it’s about trying not to arbitrarily exclude people.

Heydon: That seems to be the easiest way of approaching an inclusive design process for me, is to kind of identify the potential exclusionary elements of something and try and step around them. So with a text input, with a label, you’ve got a number of different things there that you might want to worry about. So, you’d have whether or not it’s actually labeled correctly for a start. So are you using a label element and is that label element pointing to the text field using a for attribute so that the two things are programmatically associated so that when a screen reader user focuses the input, they actually hear the label being announced? So that’s one thing to get right.

Heydon: Then, on a sort of more visual level, making sure that the label is clearly associated with that field and not a different fields, and that’s a question of white space and that kind of stuff. Also, making sure that the label is not, you’re not doing something fancy like putting the label underneath their form input because then when you, for instance, when a virtual keyboard comes up, that might become obscured. So, it’s taking into consideration those sorts of things.

Heydon: Making sure that the input itself has a focus style, so when you focus it with a keyboard, whether you’re a habitual keyboard user who uses keyboards to navigate or otherwise, making sure that it’s clear from the focus style that that’s the input that you’re focused on. Making sure that, I mean, things like autocomplete, worrying about that, whether autocomplete is appropriate and helpful in the context or whether it’s not. And a lot of these things address disability directly, but a lot of them are sort of broader in terms of usability and just making things as understandable as possible.

Heydon: Quite often, there’s a very sort of fine line or perhaps a blurred line between what addresses sort of usability for everyone and what addresses disability. And then, to make it even more kind of difficult to pin down, cognitive disabilities. So if something is not very usable for someone who does not have cognitive disabilities, then it’s going to be even more difficult to work out and be able to use for someone who does have those kinds of challenges.

Heydon: So it’s just trying to think about all of those things in one place. And really, the book is just my, it’s my thought process as I’m approaching each of those. So I did it as a blog to begin with. And each pattern or each component is a blog post and the text is just me going, “So, let’s now address this potential issue. How do we go about that? Okay, we’ve checked that one off. I think we’re okay there.” And, by no means am I trying to say that these are perfect and that I’ve thought of everything, because that’s not possible.

Drew: So does taking a component based approach to how you work on individual parts of an interface, I guess, it allows you to go really deep on that particular item and make sure that you’ve really heavily optimized it in the best way you can so that it’s accessible to everyone. Is there a danger in doing that and doing that on lots of different components and then putting them all together on a page? Is there a danger that you can create issues that you weren’t aware of because you’re testing them individually and not together?

Heydon: That’s a really good point, and I was going to bring that up earlier actually. I’m glad you said that. So, in lots of ways, I think we have, philosophically, we’ve decided that we need to separate things into these individual components. And there’s virtue to doing that, because if it’s isolated then it’s easier to kind of test and sort of treat as a single thing. And you can kind of, in terms of the way we work, it makes things easier to manage. We do have to consider, as well, the fact that these things ultimately have to share the same space and join together into a larger system.

Heydon: And I don’t think, actually, enough of our effort and thought goes into that, funnily enough. I think we componentize things more to make our lives as engineers easier, so that we know what we’re working on at what time. And, but then, we often do neglect the fact that these things will be living in dynamic systems and they have to be …

Heydon: I mean, the Every Layout project, although it’s more about visual design and about layout, is all about trying to make these little CSS primitives, these little layout primitives, in such a way that they can sort of self-manage algorithmically. It’s so that you can take them out of a narrow column and put them then a wide column and then it will be, the code itself will determine how many items abreast there should be or whether it should reconfigure itself in some other way. Because we can’t afford to constantly be intervening, and it has to be a system which is sort of self-knowing and intelligent, I think.

Heydon: There’s always things which you can forget about. So maybe you make a tab interface, you’ve got a row of tabs, you choose between the tab and the tab corresponds to a tab panel, that opens something up. And then, someone will come along and they’ll say, “Well, what if I want to put a tab interface inside a tab interface, or some other component inside a tap interface?”

Heydon: And of course, I mean, it’s partially a technical concern as to whether that would be possible, but yeah, you’ve got to make the choice about whether you’re going to make things as flexible as you can so that it’s possible to sort of imbricate things in a complex way, or simply write hard rules which say, “You can’t put something inside here because the level of complexity in terms of the code would probably be too high, but also possibly in terms of how the user can perceive and use the thing.” I’m all for writing rules which say, “Don’t nest loads of complex functionality inside itself,” because it’s just not likely that people are going to be able to get their head around it, really.

Drew: Is it possible to take a fully algorithmic or automated approach to designing for accessibility?

Heydon: I don’t believe so. No. So we have automated tools and I don’t want to disparage automated tools in any way. I think they are very useful, but I use them as kind of like an early warning system to try and kind of get an impression of where the problem areas are. So, if I was doing an audit for an organization who wanted some advice on how to make their products more accessible. So it’s a good way of kind of funding where the problem areas are, but I mean, you can have an interface which is technically 100% accessible, perhaps, according to some tool, even a good tool for judging it, say, against WCAG, the web content accessibility guidelines, or some other acceptance specification. And, even though it’s a 100% sort of all the boxes checked, it can still be entirely unusable for various reasons.

Heydon: For instance, going back to what we were saying before, it can just be entirely too complex. You can just overwhelm someone with links and there’s just no way that they’d be able to get through it and then that becomes, it’s a very sort of tacit thing and difficult thing to pin down, but it’s bound to just alienate people. But there’s also, you can get, it’s very easy to get false positives and things like that. I had a thing the other day, I said the other day, it was the other month, I was working for an organization and of course they wanted to have a 100% accessibility lighthouse school and there was an iframe which was dropped in there dynamically by a analytic script or something. You know the kind of thing where it’s some sort of slightly gross code, which is just sort of chucked in the page to do some task like that.

Heydon: Now I would recommend not using analytics at all, and I recommended to them to at least support the do not track protocol so that people could opt out. Unfortunately, that protocol is kind of, doesn’t really work anymore because it was never really supported properly. But this iframe, it was saying it doesn’t have a title on it. So the idea is that if you have an iframe, it should have a title attribute because that’s the best sort of longstanding way of identifying what the iframe is for to a screen reader user. But this was an iframe that also was set to display none, so it wasn’t even perceivable to a screen reader in the first place because display none, just as it hides things visually in a screen reader, it will essentially remove it from the interface, so it won’t be encountered or announced in any way.

Heydon: So it was a false positive. I mean, it was asking me to identify an iframe that was not there to be perceived in the first place. So, there’s always going to be those kinds of errors and problems in automated testing. But ultimately, it is about knowing, although it’s just sort of a thing that programmers, I guess, don’t really like to think that they’re involved in and they find it a bit icky, but it is about human behavior and about how people understand things and that’s a very difficult thing to just have a set of kind of binary sort of, or boolean sort of rules about.

Heydon: So, I mean, I spoke to a developer when I was consulting sometime ago about this and they kept saying, “Well, as long as we’ve got automated testing, we’re fine, aren’t we? It’s just, then we can just move forward.” And I said, “You still have to test manually. There’s no automated test which can really tell you if using the interface by keyboard is impossible in one way or another.” There are sort of discrete things you can look for, but the overall experience is still something that needs to be judged by human being. Yeah.

Drew: Sometimes the danger with automated tools is they look at items in isolation or they look at one interface in isolation and not see the wider context.

Heydon: Yes.

Drew: Certainly with using lighthouse for performance audits, sometimes I might make a decision as a developer to include, there may be a lot more CSS than is used on that one page and strictly speaking, I’m downloading too much CSS, but actually, I know that once that file is loaded, by the time the user browses to the next page, they’ve already got the CSS. So it’s an an optimization that’s being made across multiple pages the tool, looking at one page in isolation, sees as an error.

Heydon: Yes, absolutely. You’re thinking ahead and you’re making a judgment call, and until we get to advanced AI to anticipate that, then yeah, you really need human beings looking at it and going through it and going … I mean, so automated testing should be in place, as I say, a sort of early warning system, diagnostic system, but there should also be, if you’re interested in your organization really caring and making things more inclusive and more accessible, there needs to be training as well. There needs to be Q & A.

Heydon: So I would write scripts for, “This is how it should work when you interact with this component with a keyboard,” or, “This is how it should work when you interact with it with a screen reader and not actually step through it. So, when you do this, this should happen. When you do this, this should happen. When you do this, this should appear,” or that kind of stuff. So, and the kind of journey stuff, as you say, automated tools aren’t aware of that. They only just see, “Oh, this doesn’t have alt text here.” And actually, in a lot of cases, maybe it shouldn’t have alt text. And also, it can’t judge whether you’ve written the alt text well or not. So I think an image without all alternative text is probably better than an image with misleading or just bad alternative text. And that’s a judgment call again, isn’t it?

Drew: One of the things that I’ve struggled with, historically, in building things in an accessible way is keeping my knowledge of the best practice up to date because it’s, each time I refer to any documentation or any sort of recommendations, it seems like what I was doing and thought I was doing the right thing, the recommendations have moved on and now I should be doing something else. And that’s a familiar story with all areas of working on the web. But I think the danger is, of course, with accessibility issues, is that, if you’re not following the best practice, if you leave something in your interface that is now not good practice, that could be affecting your users in a negative way. Does a component based approach to building an interface or a site, does it help with that at all in any way?

Heydon: I think purely in the sense that, because you have one component which then, the idea of course in all cases and not just in terms of accessibility, is that you have this component defined in one place which will then be used in different places, at least when aspects or browser support or whatever it is changes and you want to update the component, you only then have to do it in one place and then wherever it’s used, that enhancement or that change will be felt. So from that regard, I think it’s certainly more useful to have things divided into components.

Heydon: But then, yeah, as I say, that doesn’t just affect accessibility, that can affect anything that changes. But then, I’m not sure really how much changes in its … I mean, there’ll be few sort of breaking changes in terms of sort of HTML accessibility, which is, obviously, a very narrow area. But in terms of the code quality or how the code works, things are introduced into the HTML spec, obviously, very slowly and not quite as slowly but fairly slowly into the ARIA spec as well. And then, much of ARIA just mirrors what’s in the underlying baseline HTML anyway.

Heydon: I think, more so than the technology, the perception and understanding of these things tends to change over time. I mean, there was recent, in the WebAIM survey recently, they identified the sites were using ARIA were more inaccessible than sites that didn’t use it. So this technology specifically conceived in order to help people make websites more accessible, was making it worse. So it’s really, it’s just a knowledge gap, not a technology gap or a technology shortcoming. It’s people just taking the technology and misusing it because they didn’t really actually understand how it’s intended to work, unfortunately. Hopefully, some of my writing might be able to help with that. In some areas, anyway.

Drew: But a sort of well structured component-based system would enable you, once you realize that something is out of date or you’ve made a poor decision and you now know better, would enable you to more easily go in and fix that across your application.

Heydon: Yeah, exactly. Yeah, yeah, absolutely. I mean, it’s all about efficiency isn’t it, really? And this dry principle or what have you, and see, that’s why I guess I was originally very excited about this opportunity, because people always complain that making things accessible is extra work and it’s hard and it’s upsetting and all of that. And so, it was kind of an opportunity to say, “Well, you know how you’re making this stuff really, efficiently building these component systems? Get your accessibility in there for that one component that you’re making, and then you didn’t have to worry about the accessibility anymore apart from the occasional spec change or update or what have you.”

Heydon: Or just, I mean, probably most of the time, the iteration will simply be based on user feedback and ongoing research, which, obviously, you should be, as much as possible, conducting with a diverse group of people. So, you should be getting people who use different devices and have different browsing habits and use different assistive technologies and that kind of thing. And you know, things are bound to come up all the time. I think I’ve really pinned down a component, think it’s really rock solid, and then I do a bit of research and I find that I’ve made some pretty bad assumptions. But yeah, with a component system you only have to fix it in one place.

Drew: Can a component ever be fully inclusive or is it a spectrum where you’re just working ever more towards inclusivity?

Heydon: Yeah, it would be possible for a component to be, in terms of let’s say WCAC error free, it meets all of the WCAC criteria, but as I said, that only takes you so far and it could still be entirely unusable or impossible to understand even with those technical criteria met. So yeah, this is something that I talk about a lot. I try to convince people that accessibility is like any other area of design, it’s just a part of the design process and nothing can be perfectly designed just like nothing can be perfectly accessible. I think, unfortunately, a lot of folks think of it just in terms of just making sure that it is compatible with screen readers, which is obviously a very narrow scope in terms of accessibility and inclusion in general.

Heydon: So then, there will be people who, some good folks I’ve worked with like at the Paciello Group, who would say, “Well actually, I want to be known as a accessible UX person.” So it’s not just about this box ticking exercise, it’s more about actually trying to make the experience better and more valuable for the greater number of people and move more towards sort of broader principles and things which are less binary. But ultimately, it’s all that, and WCAC and other such criteria can only really identify the real hard and fast, “This is wrong,” stuff, I suppose.

Drew: So if I’m a developer, what should I be doing differently as I approach how I design and plan and build a component? Is there anything that I should be considering in my work to make sure that that component is going to end up being as inclusive as possible?

Heydon: So, I mean, depending on what you’re building, there’s going to be different criteria which need to be met. So, for instance, not every component is going to have the to have accessible imagery with alternative text, because it might not use imagery at all. It might just be text-based or what have you. Some might not be interactive. So, in terms of the specific requirements, then, it would change between component, but hopefully what some of my writing and what the Inclusive Components book helps you to do is to fall into or kind of adopt a discipline of just thinking inclusively.

Heydon: So, when you’re approaching this stuff, not just thinking, well, basically just getting out of the mindset of, “If it works for me, it probably works for everyone else,” because it’s simply not the case that the way that you or I browse things, I mean, we’ll probably do things completely differently, just us two, right?

Drew: Right.

Heydon: And we’re Western, white, English as first language people. And so, yeah, the amount of diversity in terms of the people consuming this, I mean performance people always talk about this as well, people who are interested in advocating for better performance. You’re used to using a high spec set up on a good network and a lot of your users or a lot of your potential users will certainly not be, and same with accessibility. It’s just a question of, basically, just getting out of thinking about yourself, really. Literally just that. And trying, obviously, to reach out beyond just your immediate colleagues and people in your same social group as well.

Heydon: So hopefully, it’s really just, “Here’s what I solved for this stuff,” and what I was thinking about at the time. You can reuse some of those ideas and apply precisely what I’ve applied, if that’s useful or relevant to you. Hopefully, the book is more about just, “Here is a case study of a person who tries to think inclusively. See, the kind of things they were thinking about, when you’re designing something completely different, perhaps just employ the same kind of thinking and try and open your mind up to the diversity of of users and how they go about things.”

Drew: So the book itself, how did you decide how to structure it? It seems very fiercely practical, which I like in a book, but how have you structured it?

Heydon: Very much like the previous book, actually was Inclusive Design Patterns and I had a lot of trouble that book, to begin with, because I tried to organize it in terms of kind of abstract criteria. So I started out doing a chapter which was all about keyboard accessibility, but that was very hard because then I had to kind of, every time I talked about a different type of keyboard accessibility or the thing that you have to think about, then I had to conjure some sort of component and then ditch that component and then move onto something else.

Heydon: And so, it just made more sense for me to organize things in terms of components themselves. So, Inclusive Design Patterns does this and now Inclusive Components is really just a continuation, which just covers different components. It’s different in that, in terms of features, it’s a bit different because it also includes live code examples and stuff, which I didn’t do so much for the previous books. But yeah, it is literally just, “We’re going to do this component,” whether it’s a tap interface or a collapsible section or a theme switcher or a notification flash card or toaster or whatever they’re called, and then just everything is then organized around that component.

Heydon: So it’s, “This is what we’re doing and these are the things we should consider while we’re doing it to be more inclusive,” because that’s how I work and that’s how other folks work. And as soon as I started doing it like that, it was really just me working and writing notes as I worked. And so, the thing kind of wrote itself, and then all of the effort was really in actually just making sure that I was doing a decent job of making those things not inaccessible, I guess.

Drew: Yes, I mean the table of contents really reads almost like documentation or like a self-help manual or something. Straight in with chapter one, toggle buttons. If you want to implement some toggle buttons, go to this chapter, read it and you’ll get everything you need to know about how to do that, which is an approach I really like. I see things like collapsible sections, tabbed interface, theme switches, data tables, loads of actual, real practical stuff that we’re all building every day and I think we all, probably, could be building better.

Heydon: Yeah, that was totally the idea because it wasn’t just about me making my components, it was a case, and you’ve touched on it there, which I’m glad you did, which is it was of identifying common patterns that we all use. So I mean, there’s tab interfaces everywhere and they’re all implemented differently and they’re all implemented, variously, very badly. I mean, I’ve implemented terrible tab interfaces and that I’ve learned a little about how bad they were for people, and then I’ve tried to make them a bit better and a bit better and a bit better. I’ve probably made 15 or 16 different versions of tab interfaces in my time, having been doing this kind of thing for years now.

Heydon: And you know, they’re getting a bit better, hopefully, every time. But it is just a common thing. It was a common thing that I would use quite often between different websites, I use and everyone uses. So, part of the idea was to say, “Well, actually, let’s do a design system, kind of an accessible design system for the web.” Now, people are going to branch out and they’re going to do their own versions of these things, but to kind of get the core stuff down and the accessibility is a core thing that should be in things. It shouldn’t be an add on, it shouldn’t be an either/or, it shouldn’t be a feature. It should be a core thing. And if you get that core stuff paired down, then yeah, hopefully people would look at the chapters and go, “Oh, okay, I’ve made those. I’ve seen those. Let’s see how to do it as inclusively as possible,” and then hopefully they get some value from that.

Drew: Well, what I like about it is, certainly I know I’ve, in the past, I’ve had some interface features I’ve needed to implement and I know that it’s going to be tricky from an accessibility point of view, say some sort of a fly out menu, drop down menu, something like that. I think, “Okay, here be dragons in terms of accessibility. I need to make sure I do this right.” And so, I Google for how to do it, I find a reputable source saying, “Use this method,” I use that method, I implement it and I move on, but I actually haven’t learnt anything. I haven’t learnt why the solution was that. And what I really like about the way you go into it in the book is I can do two things at once. I can figure out how I should be doing it and I can figure out why I should be doing it like that because it’s all very carefully explained. So, I think it’s really successful from that point of view.

Heydon: Oh, great. That was what I was going for. So that’s good. But yeah, that seems to be my thing. I mean, I’ve been working with the BBC for some months and we’ve kind of made a thing a bit like Inclusive Components but for the BBC, so we’ve done this sort of technical implementation with a through the lens of accessibility version of their design language called GEL. And yeah, it explains the why as well as the how and it’s not a pattern, really. The idea is that the individual departments at the BBC, because there’s so many of them, because it’s such a large organization, so there’ll be BBC Sport, BBC Weather, BBC News, they’re the ones who would be taking care of the kind of technical stack and making their pattern library. And what we’ve really provided is just, we’ve just tried to exemplify the best practices. So it was really much more of a learning resource than a simple plug and play pattern library. Yeah.

Drew: Was it difficult deciding what patterns to include in the book? Was there anything that you left out?

Heydon: The only ones I really had problems with or second thoughts about were the ones where, the tab interface, for instance, I wasn’t going to include, because I really hate tab interfaces, but then I had folks saying, “Could you please do a tab interface? Could you include a chapter of that?” Because I get asked to put them in my interface all the time by clients or whoever. So, I ended up doing one. But it’s full of caveats. And the main caveat is, probably don’t use a tab interface. Use maybe an accordion, it’s a simpler interaction paradigm. It’s easier to make responsive, it’s easier to make compatible with screen readers, et cetera, et cetera.

Heydon: So I put all those caveats in. But yeah, and some of them were ones where I just thought, “Oh, I haven’t written about this before and I could do with having sort of thought about it so that I could actually use it in my design work.” And others were people requesting, saying, “I know this is a gnarly one, I just don’t know how to go about it. Could you give it a go?” And so I gave it a go as best as I could. That is going to be the last time I write a book about accessibility because I’ve done three now.

Heydon: So if anyone wants to know any more and if they think of any other components that they might want doing, just DM me on Twitter or something and I’ll try and deal with it in that way rather than writing a whole article, because those articles are quite long and they take up quite a lot of time and I’m kind of doing other things at the moment. But I’m always happy to chat with anyone who has any questions about this stuff. They might be working on something similar to what I’ve covered and there was just something that they were unsure about or which I, for whatever reason, I hadn’t made as clear as they’d liked it. Yeah, then just contact me because I’m always happy to talk about the stuff because it helps me to sort of ruminate over things and try to, it might challenge my assumptions and help me to do a better job as well.

Drew: So, the book, Inclusive Components, is available right now from Smashing Magazine, smashingmagazine.com/books, and I’d recommend everybody check it out.

Heydon: Thank you.

Drew: So I always like to ask people, I mean, Smashing is all about learning, right, with the books, the conferences, the magazine, we’re all about learning. What is it that you’ve been learning lately?

Heydon: So, recently, well, a couple of years ago I made something, I made a drum machine using the web audio API called Beads and it’s still available as a PWA, it’s a progressive web app. If you Google search Beads GitHub or something like that, you should get the GitHub page which has it on there. But that was a alpha version and I’m now working on doing a much more advanced version of this. And it’s a different kind of drum machine because it’s polymetric, it has different, you can have different tracks of different lengths. So you can have a track which has seven beats and a track which has nine beats, a track which has four beats. And then, the rhythm evolves over time because of the changing syncopation. You’ve got these, it’s multi-threaded.

Heydon: That was the main reason that I wanted to build it, because, as someone who’s interested in kind of experimental music, that’s something I wanted to play with. Obviously, I’m trying to make this drum machine as accessible as possible. And that’s been interesting from the point of view now that I’m working with, I’m turning it into an Electron app. So, for those of you that know Electron allows you to kind of wrap a sandbox version of Chromium browser and create a desktop application but using web technology, which was really great because it makes things, for this projects anyways, because it gets around a lot of performance problems.

Heydon: But also, although I’ve been doing cross browser testing for 12 years now, it’s really nice to have a break and just to design stuff for one browser. And it’s got some, so there’s a flag in Chromium. It’s a, what’s it called, an experimental web platform feature for focus visible. So I’ve been able to make this drum machine completely keyboard accessible with these really nice, big focus outlines without those appearing for mouse users, because focus visible uses this heuristic where it detects whether or not you’re using a keyboard. So that’s been nice, to be able to incorporate that.

Heydon: But the thing recently that I’ve been learning about, just I’ve, I guess, been learning about some of the more advanced things you can do with the web audio API itself. So I had this problem where I have, you can put multiple sounds on one track so you can load in an array of audio files and it places them one after the other, and by default they overlap, so they’ll always play out out, the audio buffer will play until it finishes. So if the next sounds comes before the end of that, it just overlaps, which is fine. It’s kind of like a reverb or something. But sometimes if you’re doing an arpeggio, like a baseline or something, you don’t want them to open up. That’s not how a bass guitar works, right? If you’re on the same string, you press the next note, the first one has to finish.

Heydon: So, I was stopping a note as the next one started and there was always an audible popping sound and it’s not the web audio API having a problem or anything like that. It’s just the human ear will hear a kind of a nasty popping sound where you kind of sever away from. You just cut it, stop it dead, it’s going to sound nasty. And then, so I found that there’s a function as part of the web audio API, which allows you to choose a point where you can taper off the sound. And so I was able to detect where the sounds should end because the other sound is beginning, then taper it off very quickly, but it is a taper, like a fade out, rather than a hard cut off thing.

Heydon: So I solved that problem after it annoying me for ages. So it’s basically been web audio API stuff and messing around with sounds because I’ve always been into, as I say, into experimental music and messing about with that sort of stuff. And I’m trying to write a talk about this. And in the talk, I’m using Billy Jean by Michael Jackson because it’s a very straight, fall to the floor rhythm and I’m going to kind of warp it in various different ways. So I’ve actually had to learn the parts for Billy Jean to kind of sequence that and stuff. So, weirdly enough, that was what I was doing before doing this podcast.

Drew: That sounds like a lot of fun. So if you, dear listener, would like to learn more about Heydon or hire him to consult on your projects, you can follow him on Twitter, where he’s @heydonworks, or visit his website at heydonworks.com. Thanks for joining us, Heydon. Do you have any parting words?

Heydon: Goodbye.

Smashing Editorial (dm, ra, il)
Having a Little Fun With Custom Focus Styles

Every front-end developer has dealt or will deal with this scenario: your boss, client or designer thinks the outline applied by browsers on focused elements does not match the UI, and asks you to remove it. Or you might even be looking to remove it yourself.

So you do a little research and find out that this is strongly discouraged, because the focus outline is there for a reason: it provides visual feedback for keyboard navigation (using the Tab key), letting users who can’t use a mouse or have a visual impairment know where they are on the screen.

This button shows a focus state with Chrome’s default outline style.

That doesn’t mean you’re stuck with this outline, though. Instead of removing it, you can simply replace it with something else. That way, you’ll keep your interface accessible and get more flexibility on how it looks, so you can better match your UI.

You can start by removing the default browser outline by selecting the focused state of the element and applying outline: none. Then, you may choose from each of the options ahead to replace it:

Change the background color

This works best for elements that can be filled, such as buttons. Select the focused state of the element and apply a contrasting background color to it. The higher the contrast the better because subtle changes may not be strong enough visual cues, particularly in cases where with color blindness and low-vision.

In the example below, both background and border color change; you may pick either or both.

Click or focus with the Tab key to view how this state looks.

See the Pen
Elements replacing native outline focus with background color
by Lari (@larimaza)
on CodePen.

Change the text color

If the element has any text, you can select the focused state and change its color. This also works for icons applied with mask-image; you can select the icon as a descendant of the focused element and change its background color, like the example button below.

See the Pen
Elements replacing native outline focus with text and icon color
by Lari (@larimaza)
on CodePen.

Again, contrast is key. You may also consider using an underline on text links and making it part of the changed state because, as the Web Content Accessibility Guidelines state:

Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A)
Understanding Success Criterion 1.4.1

Apply a box shadow

The box-shadow property can do exactly the same job as the outline, except it’s much more powerful — you can now control its color, opacity, offset, blur radius and spread radius. And if a border-radius is specified, the box shadow follows the same rounded corners.

See the Pen
Elements replacing native outline focus with box shadow
by Lari (@larimaza)
on CodePen.

You can get really creative with this technique (seriously though, don’t do this):

See the Pen
Elements replacing native outline focus with insane box shadow
by Lari (@larimaza)
on CodePen.

This works for virtually any type of focusable element, like toggles, checkboxes, radio buttons and slides.

See the Pen
Toggle and radio button replacing native outline focus with box shadow
by Lari (@larimaza)
on CodePen.

Increase the element’s size

As an alternative to color change, you may also resort to subtle size modification as focus feedback. In this example, we’re using transform: scale.

See the Pen
Elements replacing native outline focus with transform scale
by Lari (@larimaza)
on CodePen.

The key here is subtlety. Extreme size changes may cause content reflow, not to mention a poor experience for those who prefer reduced motion.

Replicate existing hover styles

If the element already has a contrasting hover style, you can simply take that style and apply it for the focused state as well. This is a rather elegant solution, as you don’t have to add any new colors or outlines to the interface.

Here’s an example where both the focus and hover states adopt a high contrast to the background of an element’s default style:

See the Pen
Elements replacing native outline focus with hover styles
by Lari (@larimaza)
on CodePen.

Bonus: Customize the default outline

Everything we’ve looked at so far takes the assumption that we want to remove the focus outline altogether. We don’t have to! In fact, it’s a border that we can customize.

button:focus { outline: 3px dashed orange;
}

That’s shorthand and could have been written this way if we want to fine-tune the styles:

button:focus { outline-width: 3px; outline-style: dashed; outline-color: orange;
}

One additional superpower we have is the outline-offset property, which is separate from the outline shorthand property but can be used alongside it to change the position of the focus ring:

button:focus { outline: 3px dashed orange; outline-offset: 10px;
}

Conclusion

You can mix and match all of these options to get custom styles that look appropriate for each component type within your interface.

And it’s worth repeating: Don’t forget to use stark color contrasts and other visual cues in addition to color when adopting custom focus states. Sure, we all want an experience that aligns with our designs, but we can adhere to good accessibility practices in the process. The W3C recommends this tool to test the contrast of colors values against the WCAG guidelines.

The post Having a Little Fun With Custom Focus Styles appeared first on CSS-Tricks.

10 Awesome Cyber Monday Deals That You Should Check Out (Up to 94% Off)

It’s that time of the year again. If you skipped Black Friday there’s still Cyber Monday.

And there are tools and resources out there that you’ll find only once a year at this great price. We’ve gathered the best of them in this article.

Bookmarking this page isn’t a solution. Don’t let a slow decision ruin your chance of getting these products or resources at a discounted rate. Act fast and don’t let them slip by.

1. Brizy Cloud Website Builder

In addition to the Cyber Monday savings you could realize, Brizy has lots of free stuff to offer as well, including the website builder itself. This premium product enables designers to create multipage websites fast, easily, and efficiently. Thanks to the 150+ customizable layouts and more than 700 design blocks that come with the package, coding is not necessary.

There is a small catch. You should sign up for a free account to be able to save what you build. You have full control over what you build and how your websites and those of your clients will appear on responsive devices.

Where does the Cyber Monday deal come in? Aside from the Free Forever plan, there are two annual paid plans (Personal and Studio). These are very affordable plans that have much more to offer than the free plan and can be yours at a 40% discount if you order 2 December or 3 December. You might check out Brizy before that date to see if a paid plan is the preferred choice for you. Use discount code CM40OFF.

2. Smart Slider 3 Pro

Smart Slider Pro 3 features a free plan and three paid plans (Single Domain, Business, and Unlimited). Give it a test drive for free. Yes, you can demo it for free. And if you like it, you can buy one of the paid plans at a discount until December 3.

Smart Slider 3 Free allows you to build beautiful responsive sliders. The paid plans provide additional special effects such as parallax animation and the popular Ken Burns effect.

You won’t get bogged down with extraneous features you have no use for. There are two different editing modes (content and canvas) to work with. In the content mode the slide acts as a page builder, in the canvas mode you can work with layers unobstructed.

Features include 180+ sample sliders (one click installation), a layer animation builder, and an astonishing array of animations and special effects. Any of the pro plans can be yours at a Cyber Monday discount of 40%. Use code SAVE4019.

3. Paymo

Paymo is a work management software application teams can use to plan their workflow, track time, and invoice clients. Having all these functions managed by a single app ensures that everything is kept in sync. Project managers will know exactly how much time (including billable hours) is spent on each task, making it easy to send accurate reports and charge clients correctly and fairly.

Paymo integrates with Adobe to allow you to track work time directly on Photoshop, InDesign, Illustrator, and Premier.

Live, up-to-date reports can be generated for sharing with team members and project stakeholders. Paymo also helps team management with task planning, tracking expenses, performing leave management tasks, and more. Other important features include Gantt charting, Kanban Boards, and a resource scheduler.

Upon subscribing, use code GVX233 for a 30% Paymo discount.

4. TheGem – Creative Multi-Purpose High-Performance WordPress Theme

TheGem is a bold and beautiful WordPress theme that is regarded by many, including its 40K satisfied customers, as featuring the most complete designer’s toolkit of any theme on the market. WPBakery ensures easy and intuitive front-end page editing, plus more than 90 pre-built complete websites, installable with one click, allows you to get off to a quick start.

Premade templates and design elements are easily combinable. This premier theme is yours at a 50% discount Cyber Monday.

5. Beaver Builder

Beaver Builder is drag and drop website building plugin that enables you to separate page building from your theme, giving you total control over your content. Beaver Builder works with any theme, and you can even switch themes without any loss of content. 30+ landing pages come with the package, no coding is necessary, and Beaver Builder is SEO friendly and mobile responsive. No discount code is required. The 25% discount is automatically applied during checkout from Black Friday through Cyber Monday.

6. Kalium

Kalium is a superior choice for beginners and advanced WordPress users alike. It is easy to use and easy to maintain, it includes several of the most popular WordPress plugins, and it supports all the better known ones. This creative multipurpose theme is an award winning top seller. It’s trusted by 30,000+ clients and provides top customer support.

Normally selling for $60, Kalium can be yours Cyber Monday for $30; a 50% discount and a great deal.

7. Mobirise Website Builder

Mobirise is an offline website building app for Windows and Mac that features an extremely easy to use interface. It’s mobile friendly, it’s free for both commercial and non-profit use, and you can build fast, responsive, Google-friendly websites in minutes. Mobirise’s Website Builder Kit, normally priced at $2,654, features all premium themes, 200+ blocks, and 66 Mobirise themes and extensions.

On Monday you can purchase this all-in-one Kit for $149, a whopping 94% discount!

8. Simple Author Box

The Simple Author Box plugin’s features give you the ability to add guest authors and multiple authors to your posts, add links to author’s social networks, and select specific post types where you want your author box to show up. Simple Author Box is Gutenberg block compatible.

Although a free version is available, signing up for a subscription plan is recommended. The Cyber Monday offer of a 30% discount on all lifetime licenses is valid until 4 December.

9. MyThemeShop

This is for the designer who wants to be able to choose among a huge variety of premium themes, domain licenses, plugins, and memberships in conversion tracking, user behavior, and social media platform tool usage and more.

For Cyber Monday, MyThemeShop’s annual fee is discounted to $99.47. This Cyber Monday special is valid from 1 December to 7 December.

10. WordLift

As you write content, WordLift is busy adding semantic markups to feed to search engine crawlers with the intent of helping you reach a broader audience. This semantic SEO tool uses natural language processing, analyzes content, and transforms any text into machine-friendly content.

A quality SEO tool like WordLift makes a great investment as it produces greatly superior results as compared to attempting to create SEO friendly content on your own. Cyber Monday features a 50% discount on your first subscription.

Conclusion

Cyber Monday will fall on the 2nd of December you can witness some of the biggest online deals of the year on tech-related items. Many of these deals are available in physical stores as well. However, online shopping is generally much more convenient, especially if all you have to do is confirm your order and perhaps press “Download”. As far as comparisons with Black Friday are concerned, Cyber Monday discounts are at least as large, and often larger.

 

[– This is a sponsored post on behalf of BeTheme –]

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 Geometer’s Compass

The European Renaissance was obsessed with classical antiquity. For many of its intellectuals it marked a cultural and scientific golden age. Many classical authors, among them the likes of Lucretius and Cicero, were rediscovered and celebrated. And among the many subjects given a new lease of life during the Renaissance was geometry. A branch of […]

The post The Geometer’s Compass appeared first on I Love Typography.

Popular Design News of the Week: November 25, 2019 – December 1, 2019

Every week users submit a lot of interesting stuff on our sister site Webdesigner News, highlighting great content from around the web that can be of interest to web designers. 

The best way to keep track of all the great stories and news being posted is simply to check out the Webdesigner News site, however, in case you missed some here’s a quick and useful compilation of the most popular designer news that we curated from the past week.

Note that this is only a very small selection of the links that were posted, so don’t miss out and subscribe to our newsletter and follow the site daily for all the news.

Fascinating CSS Grid Layout Examples and Tutorials

 

The Defining Movie Poster Trend of the Decade

 

A Brutally Honest Landing Page

 

Hierarchy of Needs in UX

 

Developing a Website Redesign Strategy for 2020

 

Flowkit 3.0

 

Site Design: The Geek Designer

 

CSS Grid Layout Vs CSS Frameworks

 

The Third Generation of Interfaces

 

Buttons: Attention to Detail

 

Building Trust as a Designer

 

10 Essential UI (user-interface) Design Tips

 

WhoCanUse: Find Out Who Can Use your Color Combination

 

Shopify Vs WooCommerce Product Comparison

 

11 Christmas Icon Fonts Free for Commercial Use in 2019

 

7 Ways to Find a Niche for your Ecommerce Store

 

Tips for Choosing a Typeface (with Infographic)

 

Google Also A/B Tests the List Vs the Grid

 

Apple Pulls all Customer Reviews from Online Apple Store

 

How to Expand Globally as a Freelance Designer

 

Mouseless – Unleash your Keyboard’s Superpower

 

Designer Gift Guide 2019: The Best Holiday Gift Ideas for Designers

 

Good Design was Always Accessible

 

Can You Really Convey Luxury Through Digital Product Design?

 

Gratitude Goes a Long Way to Increase Creativity and Innovation

 

Want more? No problem! Keep track of top design news from around the web with Webdesigner News.

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;}

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