Aug
21

This week’s sponsor: CONTENTFUL

Source: A List Apart

CONTENTFUL, an API-first, developer-friendly CMS. Build custom content-rich front-end with the tools of your choice.


Read the full article

Aug
16

BetterUI Videos

View Original article: BetterUI Videos

Aug
16

Another 10k Apart: Create a Website in 10 KB, Win Prizes!

Source: A List Apart

It gives us great pleasure to announce the 2016 10k Apart competition. Create a fully functioning website in 10 KB or less! Amaze your friends! Astound the world! Compete for fabulous prizes!

Why 10k? Why now? It’s simple, really. In the 16 years since we told you about the first contest to create a functioning website in 5 KB or less, countless aspects of web design and development have changed. And, year after year, A List Apart has marked those changes, even instigating more than a few of them ourselves. But in all those years, one thing has remained constant: the need to keep our websites lean. Indeed, in the age of mobile slash responsive slash multidevice design, keeping sites lean and mean is more important than ever.

In 2000, Stewart Butterfield launched the original 5k competition to celebrate the skill, ingenuity, and innovation of designers and developers who wring every byte of performance out of the websites and applications they fashion. Ten years later, Microsoft and An Event Apart launched the first 10k Apart—adding progressive enhancement, accessibility, and responsive web design to the competition’s requirements.

And now, An Event Apart and Microsoft Edge have teamed up once more to entice you, the makers of websites, to improve your performance game yet again by competing in a new 10k Apart that’s even tougher than the last one. Golly!

Ah, but there’s gain for your pain. Besides fame and glory, you could win $10,000 in cash, tickets to An Event Apart, the complete A Book Apart series, and a copy of Aaron Gustafson’s Adaptive Web Design, 2nd Edition, which I consider the unofficial successor to Designing With Web Standards. So what are you waiting for? Hop on over to the 10k Apart website for complete rules and details.


Read the full article

Aug
16

Communicating Animation

Source: A List Apart

Consistent animation is crucial to both branding and UX. Interfaces obey laws of “design physics”; keeping animation consistent throughout an experience envelops users in an illusion of life, of reality. Animations that step out of line disrupt that flow and feel sloppy or jarring. But because animation sits squarely at the intersection of design, development, and UX, achieving consistency presents unique challenges:

  • Communication issues make it hard for siloed teams to understand and tackle animations together.
  • Inadequate deliverables prevent developers from moving forward quickly.
  • Lack of respect for and deference to fellow team members leads to lopsided implementations that privilege some voices at the expense of others. When it comes to animation, it’s important for everyone to be heard.

Including animations in our style guides and design systems is a great place to start. However, this is relatively new territory, and most animation documentation initiatives seem to be driven by either development or design. In an ideal world, developers and designers would live in harmony and collaboration, but all too often the two houses exist in isolation from each other.

Most examples of animation in documentation reflect this rift by falling into one of two categories: thematic and educational, as seen in Google’s Material Design guidelines; or granular and explicit, as displayed in Salesforce’s Lightning Design System. Designers want to provide guidance and overarching themes, as well as educational materials, in an effort to raise the profile of animation both within a company and within the larger web design and development communities. Meanwhile, developers aspire to define and dictate animation for maintainability and consistency.

illustration showing a designer and a developer, each thinking separate thoughts / asking separate questions

This contrast reflects the needs of each group. Designers want to know the underlying principles of motion design driving their application; developers want to know how to build that design to spec. These interests are not at odds with each other—rather, they form incomplete halves of a greater whole:

  • Documentation details what’s there and why.
  • Defaults offer building blocks and rules for spinning up new projects.
  • Unity provides a common language and choreography.
  • Guidance empowers future designers to make smart decisions.

As of this writing, there is no Ultimate Animation Style Guide/Pattern/Tile/Whatever example that combines all of these elements perfectly. There may never be an animation-style-guide pattern that satisfies everyone. Some organizations may need more of some of the above components than others, depending on the project and the animation or development literacy of the team. But all approaches share features that we can combine to create the Ultimate Animation Documentation for our own teams. Let’s have a look.

Deliverables

Deliverables are supposed to round off the design process, but I often find it helpful to start with what developers want and need. Some companies have designers who build prototypes in code. Developers then find it easy to go into the code and grab the variables needed to reproduce the UI animations. But not all workflows look like this, and many motion designers will rightly argue that the very act of animating code-first limits the ideation process.

That’s why, at many companies, designers create animations in After Effects or Photoshop and then hand them off to developers. The developers must then pick apart these videos and gifs to determine what is changing at what rate. This makes the burden of implementation especially heavy for the developer, giving animation a reputation for “taking too long to prioritize.”

illustration showing a designer blithely handing off deliverables to a beleaguered developer

I myself once had to spend six hours converting an animated GIF to SVG by eyeballing it. If the designer had provided me with the necessary values, I could have recreated the animation perfectly in thirty minutes, tops. We’ll look at these values—easing, timing, and properties—next. For the sake of simplicity and consistency, we should include them in our documentation and reuse them as much as possible across our systems.

Easing

illustration showing a designer blithely handing off deliverables to a beleaguered developer

Easing describes the rate at which something changes over a period of time. It has its roots in traditional studio animation, where it was called “cushioning” or “slowing.” Easings are shorthand for rates of acceleration, deceleration, and bounces. We can invoke generic easings with CSS via keywords like “ease-in” and “ease-out,” but when everyone uses the same defaults, everyone’s designs start to look and feel the same.

Easings provide an opportunity for us to set our UI apart from others in a very subtle way. We want custom easings that reinforce our brand—be it professional, fun, elegant, or even dark. And that’s what cubic-bezier curves were created for. Cubic-bezier curves are a set of numbers we can pass to CSS and JavaScript animation libraries to tell them how we want the animation to change over its allotted timeline. We can get some starting points at sites like easings.net or create our own using the browser’s developer tools.

It’s tempting to make one cubic-bezier curve to rule them all, but what we really want is an array of several curves for different purposes:

  • Human-initiated interactions feel faster and more natural if they respond immediately. A deceleration (moving from fast to slow), or ease-out, provides immediate feedback that tapers off.
  • System reactions are less alarming if their curve is accelerated, moving from slow to fast, or what we call ease-in.
  • Fades and color changes often look best with a more constant curve, but you could purposely buck that to express your aesthetic values.

Most design systems benefit by specifying at least an ease-out, an ease-in, and a fade curve.

Timing

Easings are a high-visibility return on investment. But animation can’t happen without a duration. On the Lightning Design System, I worked with Amy Lee, who also happens to be a musician. In a brilliant example of genius occurring in the overlap of disparate fields, she came up with the concept of timing scales: a set of time values that align at various combinations.

The concept is similar to modular scales in typography: all values are related, and if you combine them with a vertical rhythm, a piece exhibits overall harmony. You can generate a timing scale the same way you generate a typographic scale.

There are upper and lower limits. While the human eye can perceive images in as little as 13 milliseconds, it takes us between 70 and 700 milliseconds to move our eyes according to the Human Processor Model. 200–300 millisecond values typically become the workhorses of a timing scale, from button depresses to secondary animations. (The persistence of this time range across game and web development is especially interesting in light of recent research suggesting we experience the world in 400 millisecond “chunks.”) Shorter durations work better for color changes and fades, which the human eye picks up readily. Longer durations are better for larger fields of change, like page transitions, or motions that occur over longer distances, like a drag-and-drop interaction or menu slide-out over a large screen.

It’s a good idea to define durations in milliseconds rather than seconds. While most animation libraries can accept seconds and milliseconds, JavaScript timers and the Web Animations API take only milliseconds. Also, some people may find it easier to work with zeros than decimals (although that might be more of a tabs versus spaces argument).

Properties

diagram showing properties that describe what is being animated

Properties describe what is being animated. Currently in web animation, the most performant things to animate are opacity and transforms (scale, distance, rotation). But there will be times when we want to animate less performant things like color or—heaven forfend!—height. Browsers are working hard to improve their animation performance, so while it’s great to try to stick to transform and opacity, don’t be afraid to push technology with art where you can get away with it.

Knowing the properties we want to animate comes in handy when communicating animations with storyboards and specs and when we’re creating our project’s very own animation vocabulary.

Creating an Animation Language

We combine these three components—easing, timing, and properties—to create vocabularies of words like “pop,” “fade,” and “slide.” Many of these expressions start as friendly onomatopoeias: swoosh, zoom, plonk, boom. And sometimes colleagues will, say, hold a sound longer to indicate extended duration: “Can you make it more like voooooosh and less like voosh?” It makes sense to “pave the cowpaths” and adopt words like these when constructing our own animation vocabularies.

lettering illustration showing friendly onomatopoeias: swoosh, zoom, plonk, boom

Vocabularies are granular. You can layer these microanimations to create macroanimations—for instance, a modal that fades onto the screen then pops to grab user attention.

animated GIF showing a modal that fades onto the screen then pops to grab user attention

These words might seem arbitrary at first, but they yield huge benefits when it comes time to document our visual deliverables with text.

Communicating Visually

There are three ways to communicate animation: storyboards, animatics, and prototypes. All of them contain a visual component, but only storyboards include words. Words are one of the lowest common denominators of digital human information exchange—capable of being read out loud, indexed by search engines, translated by machines. In many cases these words are the key to conveying animation deliverables, so it makes sense to start with storyboards.

Storyboards

photograph of storyboards at Disney Studios

Disney Studios invented storyboards for working on feature-length animation films, and it wasn’t long before Hollywood started using them, too. Storyboards let disparate teams get an overview of a linear narrative. They reduce time spent on dead-end shots and help directors and writers visualize the final story, and edit it on the fly. These days, storyboards are used not only in cinema but also in game design and interaction development.

photograph showing a whiteboard with storyboards scrawled on it and covered in Post-its

These storyboards can range from very informal (on a small-team interaction-design project where everyone follows each stage of development closely) to very detailed and particular (for specifications and audits). One problem I have as a consultant is that I find it difficult to embed videos or GIFs in PDFs to hand to managers as a way of explaining where animation problems occur. So for long-term storage, I include a storyboard.

diagram showing a storyboard for a motion-design audit

This storyboard was part of a motion-design audit for a large project where I needed to leave the client with actionables to include in their next sprint.

Storyboards use words and illustrations to represent interactions and animations. Every animated interaction can be divided into a “before” shot and an “after” shot; it’s up to us to illustrate the in-between shot to demonstrate how we get from one to the other. Language helps us clarify why these changes are happening. Using words like this is a powerful thinking tool. Justifying animations verbally helps us sort necessary animations we can defend from ones that are perhaps less mission-critical.

Storyboarding software, most of which is geared toward cinema, is simultaneously insufficient and overkill for web development collaboration. Teams often have more fun and collaborate better with good old index cards and Post-its. I’ve written about a more formal approach to my storyboarding techniques, and you can download my storyboarding template to get started.

Animatics

If a picture is worth a thousand words, an animation is worth ten thousand meetings. Storyboards, sadly, can’t show us how something “feels” on the screen or under the thumb. Once again, studio animation provides a solution in the form of animatics, videos of the storyboard set to an audio track that can be screen-tested with an audience or presented to investors as proof of progress. We can also make small videos or GIFs with our wireframes and storyboards that demonstrate how they work.

Do not throw these mini videos over the fence to developers. Finalize animatics by combining them with the deliverables developers crave: easing, duration, and properties. At most, an animatic is a measuring stick against which we compare the final, implemented animation. And the two will only match 100 percent if we provide our developers with the inputs necessary to duplicate the original.

For creating animatics, AfterEffects is the software of choice in the motion design industry. Web designers may be more accustomed to creating animatic-like demos in Keynote to be clicked through in meetings. These can be recorded with screencasting software like Quicktime or Camtasia. And some visual prototyping tools like Principle export to video, achieving two things at once.

Prototypes

Animatics can be screen-tested on an audience, but screen-testing works best for passive media. The web is interactive: people interact with designs, which in turn react to them. There’s no way to test these reactions with storyboards or videos. When we want to be sure of how people will respond to a design, we want prototypes.

There are two approaches to prototypes: coded prototypes and prototyping software. Developers tend to prefer the former, often leaning on frameworks like framer.js and Zurb’s Foundation; designers prefer the latter, in the form of software like Invision App and UX Pin. Both approaches require team members to invest time in learning a new system, thus increasing the commitment factor.

Most prototyping software with animation features, like Pixate and Principle, is app-oriented. But the web is catching up with products like UXPin, and web and native prototyping powerhouse Invision has demonstrated its commitment to improving animation tooling with its purchase of Easee.

Coded prototypes, unlike storyboards, are terrible for documentation: only code-savvy team members can read them, and the files must be organized and sometimes compiled or served before inspection. An external agency would struggle to deliver a fully branded experience riffing off a pile of non-production code.

Pick two

If we rely on storyboards, animatics, or prototypes alone, we can’t hope to communicate animation clearly, effectively, or sustainably. But if we combine them, they work great: a demo next to a set of deliverables; a storyboard with a video. Such combinations work well for documentation and also sometimes for offering animation boilerplates.

Venn diagram showing how storyboards, animatics, or prototypes might be combined

Animation as a team sport

Many animation documents are created in the hopes that “if you write it, they will follow.” We hope our coworkers will read our sage advice and start preaching the animation gospel; we hope they’ll copy our animation deliverables perfectly for every button, gesture, and loading spinner.

In practice, though, it’s extremely rare for even half of a team to care as passionately about animation as the person writing the docs. While education and guidelines are fantastic in principle, they are a wasted effort if no one cares. Here are some quick ways to get our teammates on board:

  • Group documentation. Having a documentation format that everyone can contribute to—and then having people contribute even just a few words—helps them feel like this is their baby, too.
  • Team tweening exercises. I use these exercises in training to help get siloed teams collaborating. Take “before” and “after” wireframes, and give everyone index cards to brainstorm all the possible animations they could use in between those states to get from point A to point B.

illustration showing team tweening exercises

  • Cultivate and champion. Teams without motion and animation champions can’t sustain their animations over the long run. Someone has to grow the love for animation and make it second nature to think about it, same way we think about color or fonts. Otherwise, animation risks being sidelined the way accessibility and user testing often are. Many organizations assume an initial effort is sufficient to address what should become an integral part of their design process.
  • Have a coconspirator or two. We should always be on the lookout for coconspirators. One champion isn’t enough. Eventually we all move on to other projects, and a healthy system is one that can function when one of its pieces goes missing.
  • Do it anyway. Sometimes people just have to see the difference animation makes to believe it. You can ask for forgiveness later.

illustration of a happy team

A template library will need different documentation than, say, an interactive story app. What matters is clearly recording and communicating those deliverables and cultivating a concern for animation among our peers. People fear what they don’t understand, and they fear change. Education, communication, and collaboration turn that fear into enthusiasm and goodwill.

There is no one right way to document animation. But when we collaborate with our teams, together we will find the right way forward. Don’t be the lone animation wolf; find or found an animation pack. Recruit other animation wonks from different areas like UX, front-end development, data visualization, design, and marketing. Diverse views will strengthen how we approach animation and help rally more support from other corners. Together, we can all find our own “way of animation” that works best for us.


Read the full article

Aug
10

UX Fiefdoms: Their Dangerous Effects

Source: UXMatters

Recently, I sat down with the CEO of my company to discuss some topics relating to User Experience. We meet pretty regularly because he is, in general, very interested in getting our customer experience right. Though this was not the focus of our conversation, we talked briefly about the fact that fiefdoms exist in every company, large or small. Some people and groups in every corporation continually seek to create little feudal empires that truly stifle creativity and impede an organization’s ability to move forward.

While our conversation just touched on this topic lightly, it got me thinking about the current state of enterprise UX—where we are in danger of creating fiefdoms. I have previously written about how UX teams are literally in a golden age, finding themselves in unprecedented positions of power and influence within organizations that are finally realizing how critical User Experience is to the success of modern-day products and services. However, the internal actions of our UX teams could easily diminish the positive effects of this golden age. READMORE

UX Fiefdoms: Their Dangerous Effects

Aug
10

Practical UX Design

Source: UXMatters

This is a sample chapter from the book Practical UX Design, by Scott Faranello, which was published by Packt Publishing Ltd. in April 2016. UXmatters is publishing this chapter with Scott Faranello’s permission. Copyright © 2016 Packt Publishing Ltd. All rights reserved.

Chapter 2: Creative UX

Practical UX Design CoverLet’s go a little deeper now and talk about another important area of focus for the practical UX practitioner: creativity. Developing a UX mindset is essential to better design work because it allows you to see things differently, which in turn will allow you to design differently, leading to more creative solutions on a consistent basis. Of course, we all want to be our most creative selves most of the time, but in the working world, we also have to deal with deadlines, meetings, office politics, and other distractions that can make creativity a major challenge and negatively affect your solutions and subsequent designs. The key, therefore, is to find a balance between creativity and decisiveness, two mindsets or modes that can often be at odds. By following some steps, inspired by someone who knows, you will be able to switch between these two modes more easily and more effectively.

In this chapter, we will look at:

  • The essential mindset for creativity
  • The six conditions needed for creativity
  • Applying creativity to UX design READMORE

Practical UX Design

Aug
10

How Innovations in Logistics Fulfill the Experience Demand

Source: UXMatters

At the risk of dating myself, when I purchased my first computer for graduate school, I recall using my friend’s dial-up modem to connect to AOL. Then I pulled up the UPS.com Web site to track its delivery status. I refreshed the status and, when the screen finally read, “Delivered,” ran down to the lobby of my apartment building in Boston to retrieve my precious package before someone tried walking away with the large Dell box. Ignoring the fact that shipping and delivery took over a week at that time, I was thrilled that I could instantly see the status of my package, then have it in my hands five minutes later. I appreciated this service-experience win years before I ever cared about service design as a profession.

The service experience that connects our desire or need to have a product and the speed at which we can get it has come a long way since those early AOL days. Today, we expect free shipping for the things we buy online, and we want them at our door within one or two days. We also want easy returns, in case we don’t like what we bought. But the behind-the-scenes complexity that’s involved in fulfilling of these needs and desires cannot be overstated. In this column, I’ll explore how and why the shipping, delivery, and logistics industry is evolving to be more customer centered and what this means to us as experience design professionals. READMORE

How Innovations in Logistics Fulfill the Experience Demand

Aug
10

Creating User-Friendly Documentation

Source: UXMatters

Simplified Technical English (STE) and minimalism are of great importance in writing user-friendly documentation, particularly for user content such as maintenance manuals. However, many technical writers experience specific problems when implementing STE and minimalism. The ASD-STE100 Specification is a complex document, and a disadvantage of this approach is its expensive learning time. Plus, literature about minimalism comprises complex documents, and training is scarce.

In this article, we’ll clearly describe the steps you need to take to implement the principles of Simplified Technical English and minimalism in designing optimized, user-friendly documentation. First, we’ll cover the concepts behind the Thumbs-Up Technique—principally, STE and minimalism. Next, we’ll detail the steps to follow in implementing STE. Finally, we’ll detail the steps to follow in implementing minimalism. By following the steps we’ll outline, you can apply the principles of STE and minimalism to your documentation quite easily. READMORE

Creating User-Friendly Documentation

Aug
10

Accessible Documentation

Source: UXMatters

Accessibility is the ability to do things differently! As the world moves toward assistive technology, one principle that has gained prominence is accessibility. With billions of users taking advantage of technology, it is imperative that technology be accessible to all. This is the basic idea from which the concept of accessibility has originated and the reason why assistive technology is gaining prominence.

Accessibility refers to the idea of creating a product with the intention that people with various disabilities can use it. The term disability encompasses different kinds of impairments that arise from physical, cognitive, visual, auditory, and neurological challenges. The American Psychological Association defines disability as a “functional limitation that affects an individual’s ability to perform certain functions.” Technology can play a huge role in helping people to overcome their disabilities to a great extent. Accessibility strives to make information and technology usable for disabled users. READMORE

Accessible Documentation

Aug
10

Practical SVG

Source: A List Apart

A note from the editors: We’re pleased to share an excerpt from Chapter 6 of Chris Coyiers’s new book, Practical SVG, available now from A Book Apart.

You’ll probably want to exert some sizing control over any graphic you put on a website. Hey! You! Logo! You should be this size:

<img src="logo.png" class="logo" />
.logo {
  width: 220px;
  height: 80px;
}

And so shall it be.

But if the element you are resizing happens to be svg, the result might not be exactly what you expect. Sizing svg is a little more complicated than sizing an img. I’m not saying this to scare you. It’s almost complicated in a good way, because it gives you more control and opens up some interesting possibilities.

Keep these two concepts in mind when you’re working with the size of SVG images:

  • The viewport is simply the height and width of the element: the visible area of the SVG image. It’s often set as width and height attributes right on the SVG itself, or through CSS.
  • The viewBox is an attribute of svg that determines the coordinate system and aspect ratio. The four values are x, y, width, and height.

Say we’re working with some SVG like this:

<svg width="100" height="100" viewBox="0 0 100 100">

<!-- alternatively: viewBox="0, 0 100, 100" -->

In this case, the viewport and viewBox are in perfect harmony (Fig 6.1). The SVG will be drawn in the exact area it visually occupies.

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

Fig 6.1: Viewport and viewBox in perfect harmony. This happens when you apply no width or height to the svg (either via attribute or CSS), or if you do, they match the aspect ratio of the viewBox.

Now say we double the width and height, like this:

<svg width="200" height="200" viewBox="0 0 100 100">

Will the svg just draw in a 100 by 100 space in the upper left side of the 200 by 200 element? Nope. Everything inside the svg will scale up perfectly to be drawn in the new, larger space (Fig 6.2).

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

Fig 6.2: With the viewport enlarged and viewBox kept the same, the graphic scales up to fit the viewport.

The square aspect ratio still matches perfectly. That’s why it’s not particularly useful to think of the numbers anywhere in SVG as pixels, because they aren’t pixels; they’re just numbers on an arbitrary coordinate system.

What if the aspect ratios don’t match, though?

<svg width="300" height="75" viewBox="0 0 100 100">

What happens now, by default, is that the SVG will draw itself as large as it can, centered along the longest dimension (Fig 6.3).

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

Fig 6.3: The viewport is enlarged, but no longer matches the aspect ratio of the viewBox. So by default, the image is drawn as large as possible without being cut off, and centered on the long dimension.

If you want to regain some control over this behavior, there’s an attribute for the svg element that can help!

preserveAspectRatio

It looks like this:

<svg preserveAspectRatio="xMaxYMax">

The x and Y parts of that value are followed by Min, Mid, or Max. The reason SVG normally centers in the viewport is because it has a default value of xMidYMid. If you change that to xMaxYMax, it tells the SVG: Make sure you go horizontally as far to the right as you can, and vertically as far to the bottom as you can. Then be as big as you can be without cutting off.

The “without cutting off” part is another aspect of preserveAspectRatio. The default value is xMidYMid meet—note the “meet.” You can replace meet with slice to say instead: Fill the area entirely; cutting off is okay.

There are nine possible alignment values combined with meet (Fig 6.4).

Several images representing rectangle pairs, demonstrating placement variations for smiley face graphics found in each rectangle.

Fig 6.4: Examples of preserveAspectRatio values with meet.

There are also nine possible alignment values combined with slice (Fig 6.5).

Several images representing rectangle pairs, demonstrating placement variations for smiley face graphics found in each rectangle. Each also exceeds the height and width of the rectangle's frame.

Fig 6.5: Examples of preserveAspectRatio values with slice.

I made a testing tool for playing with this idea. Sara Soueidan also wrote an in-depth article on this subject, where she makes an excellent observation relating this idea to CSS. The background-size property has two keywords it can take: contain and cover. The contain value means “make sure this entire image is viewable, even if you have to shrink it,” which makes it just like meet. The cover value means “make sure this covers the entire area, even if you have to cut parts off,” which makes it just like slice.

Even the alignment part of the value has a matching CSS counterpart: background-position. The default background-position is 0 0, meaning “top left.” That’s just like xMinYMin. If you were to change that to, say, 50% 100%, that would be like xMidYMax!

Fig 6.6 has some examples to make that connection a little clearer.

preserveAspectRatio values and CSS properties
preserveAspectRatio= "xMinYmax meet" background-position: 0 100%; background-size: contain;
preserveAspectRatio= "xMidYMid meet" background-position: 50% 50%; background-size: contain;
preserveAspectRatio= "xMinYmax slice" background-position: 100% 0; background-size: cover;
preserveAspectRatio= "xMidYMid slice" background-position: 50% 100%; background-size: cover;

Fig 6.6: preserveAspectRatio values and the CSS properties they are similar to.

Remember: these aren’t interchangeable bits of code; they are just conceptually related.

What if you want to throw aspect ratio out the window and have SVG scale to the viewport, like a raster image would? Turn preserveAspectRatio off (Fig 6.7)!

<svg preserveAspectRatio="none" viewBox="0 0 100 100">

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

Fig 6.7: Example of preserveAspectRatio="none". Poor little buggers.

Amelia Bellamy-Royds wrote a comprehensive article on scaling SVG, in which she covers things like the fact that svg can essentially contain other svg with different aspect ratios and behavior, so you can make some parts of an image scale and others not, which is pretty cool and unique to SVG.

Approaches to artboard sizing

When you draw SVG in editing software, that software likely gives you some kind of artboard to draw on. That’s not a technical SVG term; it’s essentially a visual metaphor for viewBox.

Let’s say you’re working with a whole set of icons for a site. One approach is to make all artboards hug each edge of the icon (Fig 6.8).

Adobe Illustrator graphics cropped to their edges

Fig 6.8: Example of graphics in Adobe Illustrator cropped to their edges.

Here’s a quick trick to get that artboard cropping in Illustrator: select the Artboard tool and then “Fit to Artwork Bounds” from the Presets menu (Fig 6.9).

Cropped view of Adobe Illustrator menu option for resizing an artboard to the edges of a graphic

Fig 6.9: The menu option in Adobe Illustrator for resizing an artboard to the edges of a graphic.

The big advantage to this technique is alignment (Fig 6.10). If you want to align any edge of any of these icons to anything else, that’s easy to do. There is no mysterious space you need to contend with, or tweaky positional CSS.

.icon.nudge {
  position: relative;
  right: -2px; /* UGHCKKADKDKJ */
}
Icons aligned to corners of graphics

Fig 6.10: Icons aligning to edges without little bits of extra space you have to account for.

The big disadvantage to the cropping technique is relative sizing. Imagine you take the practical step of sizing your icon’s width and height, like this:

.icon {
  width: 1em;
  height: 1em;
}

A tall, skinny icon will shrink to fit in that space and potentially appear awkwardly small. Or perhaps you’re trying to have an intentionally small star shape as an icon, except the star has a squarish aspect ratio and thus grows to fill the space, appearing bigger than you want it to.

Here’s an example where two icons are sized identically as a square (Fig 6.11). The “expand” icon looks right at home, since it has a square aspect ratio to match. But the “zap it” icon has a tall and narrow aspect ratio, so it looks wimpy, like it’s floating in the same square area.

Two button samples; one example has a nicely-balanced scale of icon to text, the other has an icon that is too small for the space and size of text

Fig 6.11: Two icons sized in the same square space within a button. The top one fits nicely, but the bottom one floats awkwardly in space.

The other approach here is to make consistently sized artboards (Fig 6.12):

Several similarly-sized graphics

Fig 6.12: Example of Illustrator graphics whose artboards are equal in size.

The advantages and disadvantages are exactly inverse here. You might have alignment issues, because not all edges of the icons touch the edge of the viewBox, which can be frustrating and might require tweaking sometimes (Fig 6.13).

Graphics with icons sized to be comparable to one another

Fig 6.13: You can adjust icons’ relative sizing, but that can make alignment more difficult.

You won’t have relative sizing issues, though, because the viewBox is the same for all of them. If any particular icon looks too big or small, you can adjust the artwork to bring it more in line with the set.

Since we’re learning about sizing, now is the perfect time to bring up how SVG fits into the flexible world of responsive design.

Responsive SVG

One of the hallmarks of responsive design is fluid layout. Content—images included—is designed to fit its containers and the screen. If responsive design is new to you, Ethan Marcotte’s seminal 2010 article on the subject is a fine place to start learning about it. SVG jibes extremely well with responsive design:

  • Responsive designs are flexible. So is SVG! It renders well at any size.
  • Responsive web design is a philosophy of caring about how a website looks and behaves in any browser. Comparatively smaller SVG files and performance-responsible tactics like an SVG icon system can be a part of that.

But perhaps SVG’s most obvious connection to responsive design is the possibility to react to CSS @media queries. Media queries move, hide, or show elements with CSS based on things like the width or height of the browser window. Those elements can be anything: sidebars, navigation, ads, what have you. They can be SVG elements as well.

Imagine a logo that displays different levels of detail depending on how much space is available. That’s exactly what Joe Harrison was thinking when he created a really neat demo using well-known logos, (Fig 6.14).

Modified versions of the Disney logo, progressing to greater and greater simplification

Fig 6.14: Joe Harrison’s demo of the Disney logo at different sizes.

On the web, we’ve always had the ability to swap out images with other ones. What’s appealing here is that we aren’t swapping out images; these are all the same image. Or at least they could be. That signature “D” all by itself could be the same exact “D” used in the most complex version of the logo. Easy-cheesy in CSS.

Say we organize the SVG like so:

<svg class="disney-logo">
 <g class="magic-castle">
    <!-- paths, etc -->
  </g>
  <g class="walt">
    <!-- paths, etc -->
  </g>
  <g class="disney">
    <path class="d" />
    <!-- paths, etc -->
  </g>
</svg>

This, by the way, is pretty easy to do in Illustrator (Fig 6.15). The groups and names you create there turn into IDs in the SVG output, and you can use those IDs to do the styling. Personally, though, I prefer using classes because they aren’t unique (so you don’t accidentally end up with multiple identical IDs on the page) and because classes have a lower and more manageable level of CSS specificity. It’s easy enough to change IDs to classes with a bit of find-and-replace maneuvering in a code editor.

Adobe Illustrator interface showing vector paths and layers for Walt Disney logo

Fig 6.15: Named layers and named shapes in Adobe Illustrator.

The corresponding CSS could be something like this:

@media (max-width: 1000px) {
  .magic-castle {
    display: none;
  }
}
@media (max-width: 800px) {
  .walt {
    display: none;
  }
}
@media (max-width: 600px) {
  .disney > *:not(.d) {
    display: none;
  }
}

Mind you, this is a contrived example of hiding parts of the images at different breakpoints, but that’s exactly how you would do it, along with some likely sizing adjustments. Anything you can do with CSS is on the table here. Perhaps some animation is appropriate at some breakpoints but not at others. Perhaps you change stroke sizes to beef up or trim down icons at different sizes. Perhaps you change some fill colors to simplify adjacent shapes.

And things can get even fancier! Depending on how the SVG is used, those media queries might actually be different. SVG used as img, iframe, or object has its own viewport. That means CSS embedded inside of it reacts to media queries based on that, rather than the whole browser window viewport. That means you would write, say, width-based media queries based on the width of the image, not of the entire page.

That’s a very appealing idea: an element that arranges itself based on attributes of itself, rather than the page. Am I this wide? Do this. Am I this tall? Do this. That way, the SVG reacts to the situation it’s in rather than the arbitrary document it happens to be part of.

As I write, this is referred to as “element queries” in CSS, but it doesn’t actually exist yet in regular HTML/CSS. Once again, SVG is ahead of the curve.

Graduation into animation

Speaking of things SVG is good at, let’s move into animation next. Everything we have been building on so far has prepared us for this. Hang on tight!


Read the full article

Older posts «