There's a huge resource of Newsfeeds on the Net which brings up-to-date
information and content on a wide range of subjects.
Here are just a few relating to web development.
Thanks to our sponsor, New Relic.
New Relic helps web and mobile app developers improve app performance by showing you bottlenecks and making it easy to spot code bugs. Do your apps a favor, try New Relic.
I’d like to take a moment to address something decidedly unsexy. We all do it. And it’s never pretty. You guessed it: I’m talking about email.
No, I don’t mean responsive design approaches for email newsletter templates. Nope. Not even that much fun. I’m talking about reading and responding to that everyday, humdrum, never-ending stream of communication that flows through the inscrutable ether to your very own inbox.
Staying in control of your life with email is a challenge (look no further than your friends’ triumphant cries of “inbox zero!”). When you run your own business, as I do, there is every motivation to always stay on top of these messages. It is, after all, your thing. You own it. Shouldn’t you be addressing every issue as it crops up, and responding with lightning speed?
This lifestyle really caught up with me a year or so ago. It was affecting my sleep and productivity, and saddling me with all kinds of extra cognitive overhead. It was no fun at all. Over the course of several months, I worked at establishing rules and procedures for email that helped me regain my sanity and improve the quality of my workdays (not to mention my weekends). In no particular order, here they are:
One of the first and most obvious things I did was turn off notifications and badges for email. Turning on email notifications is like asking to be interrupted by anyone at any time, no matter what you’re doing. If you must have notifications, consider adding essential people to a VIP list, and hiding all other notifications. Ask yourself, “who would I need to drop everything for, no matter how important my task is at that moment?”
OMG, filters, guys! Filters that route the endless stream of notifications (for instance Basecamp updates, or emails from your ticketing system) are great. They keep things organized neatly so that you can address like emails all at once. Since these sorts of emails will often be project-specific—this also makes it easier to remember to track your time while you’re doing it (hint, hint).
On the weekend, I really don’t want to accidentally open a troublesome work email. To keep a clear distinction between my personal and work emails, I started using a separate app for personal email. Personally, I’m quite happy with Mailbox, but I also know some smart folks who like Boxer. I’m sure there are plenty of other great ones, too (reader comments, activate!).
Just like the ticket queue of tasks, you’re never really finished answering emails. To help me focus on my home life when I’m not at work, I use a timed “do not disturb” setting in iOS to make sure that I get no notifications of anything between 7 p.m. and 7 a.m.
I find that my mind is sharpest and I do my best work in the morning, and yet I used to start each work day with email—a task that arguably requires the least of my creativity and mental acuity. So now I set aside the first hour of my day for something challenging. I often write these columns during that time slot. Or tackle a particularly gnarly IA or design problem. But email? Email can wait till 10 a.m.
And when you’ve finished that batch of email responses and are ready to return to your work? Close that email client, friend! Don’t open it back up until you’re ready to dedicate your attention to it again. Otherwise, it’s just a distraction. I find it useful to set times for checking my email throughout the day, for instance 10 a.m., 1:30 p.m., and 4 p.m.
Ever check your email while you only have a few seconds or minutes to spare? You get some troublesome message, but don’t really have time to read through it carefully or respond. Then you spend the next few hours with that static buzzing around your brain, distracting from whatever it is you’re working on. I now have a simple rule: if I don’t have time to sit down and directly address whatever messages may be waiting for me, I don’t check my email. Making reading and responding to email a dedicated task keeps you out of that vague cognitive limbo, and can reduce the anxiety of opening the inbox.
Remember: email is asynchronous communication. By its nature, it encourages a lag in response, and everyone expects that. If there’s a real emergency, someone will doubtless pick up a phone. Email can wait a few hours, even a day. The world won’t explode, and you won’t get fired. Give those messages their proper place in the hierarchy of your day.
There are doubtless many other ways to keep the great beast email under control. These are the ones that have helped me hold on to my sanity and reduce email-induced anxiety. These little strategies make me happier and more productive every day.
How about you? What are your email troubles? What have you tried that’s worked? Get in those comments, people, and share what you’ve learned. Something tells me we could all use a little help in this department.
We have plenty of considerations to design for when crafting web sites. Web accessibility is not a new design consideration, but is still very important, no matter the size or speed of device we’re testing on. The Web Content Accessibility Guidelines (WCAG) tells us our content should be distinguishable and requires we “[m]ake it easier for users to see and hear content including separating foreground from background.”
We know that our color contrast ratio should be 3:1 for non-decorative text, sized larger than 18-point or larger than 14-point if bold. Text smaller than that should meet a contrast ratio of at least 4.5:1.
Maybe you have amazing eyeballs that can help you recognize contrast levels. If, like me, you do not have magical corneal calculators, then you probably have utilized one of the tools out there to check contrast, such as: WebAIM’s color contrast checker, Snook’s contrast slider, Check my colors URL input check, or a WCAG checker add-on for Firefox.
I recently switched to using Chrome’s Accessibility Developer Tools built in contrast checker and I love it. Take a look at the audits being run by the tools and let’s look at how to begin using it once installed.
Load up the website you’d like to check and bring up the Developer Tools. I’ll pick on myself and use my own site for this example. Once open, click over to the “Audits” tab and make sure “Accessibility” is checked. Click “Run”.
Expand the “Text elements should have a reasonable contrast ratio” section. This will show you the HTML of the elements that don’t have sufficient contrast. Identify one to examine further.
Select the chosen offender in the browser and inspect it. If you can’t see the contrast values, use the menu to pull up the “Accessibility Properties.” You’ll see the current contrast ratio of your element. You’ll also see a suggested color value pair to match the WCAG AA or AAA recommendation. Select the swatch to the right of those values to see the preview of that change. In this case, we’ll see what grey we’d have to adjust our background to in order to keep the white text.
As you can see in this second example, I could make the date text darker to meet the guidelines, which is very helpful in making a fast change.
When it’s this quick and simple to check contrast, there’s no reason not to add this accessibility test into our workflow.
If you run a server that uses SSL and the OpenSSL library, you need to update it. If you regularly visit a site that uses SSL (and I can’t imagine you don’t), you should try to limit your visits today. Once the dust has settled, we should all change our passwords. Pretty much everywhere.
In short, yesterday the OpenSSL Project released an update that addresses a vulnerability in the OpenSSL library. Officially named CVE-2014-0160, the Heartbleed bug has been around—and un-identified—for a long time. It’s not known if the vulnerability has been exploited, but it’s theoretically possible that someone has been snooping on transmissions we thought were secure. It’s very likely that bad guys are snooping on un-patched servers now, so be careful which services you log in to today.
Visit Heartbleed.com for a lot more information, and anyone running a server should consider these words from Cody Sorland:
Ubuntu servers running nginx/SSL?
sudo apt-get update && sudo apt-get dist-upgrade
sudo restart nginx
Do it now. #heartbleed— Cody Soyland (@codysoyland) April 8, 2014
Ubuntu servers running nginx/SSL?
sudo apt-get update && sudo apt-get dist-upgrade
sudo restart nginx
Do it now. #heartbleed
Be careful out there.
Several years ago, I was working on a large, complex application. It was a bit of a legacy project: many different designers and front-end developers had come and gone, each appending a new portion to the sprawling application. By the time I arrived, the CSS was huge, the styles were varied, and it took a lot of effort to find out if anything was reusable.
During all this, I discovered style guides—a way to control markup and CSS so neither veered out of control or ballooned. In jobs since, I’ve seen firsthand how style guides save development time, make communication regarding your front end smoother, and keep both code and design consistent throughout the site. It has been a revelation, and in this article, I want to show you how to build and maintain them, too.
To me, a style guide is a living document of code, which details all the various elements and coded modules of your site or application. Beyond its use in consolidating the front-end code, it also documents the visual language, such as header styles and color palettes, used to create the site. This way, it’s a one-stop place for the entire team—from product owners and producers to designers and developers—to reference when discussing site changes and iterations. Several companies have even put their guides online; Starbucks is the most well known of the bunch, but others exist.
(I should also mention that what I call a style guide, some people call a pattern library. Many of the guides I reference use the term style guide, but pattern library is gaining in popularity.)
When I started working at Editorially, one of the first things I did was tackle the style guide. Creating the guide was probably the most useful thing I’ve ever done when settling into a new job: it forced me to go through every single line of CSS and read it, digest it, understand how it was used, and then document it for my own, and the team’s, future reference. In addition to catching inconsistencies and errors by poring through the CSS, if I didn’t understand how certain pieces of code were being used, I annotated the guide with questions (which my teammates graciously answered).
As your team grows and changes over time, your style guide will help you in several ways. First, creating your guide will take some time up front, but I’ve found that this pays off with faster build times for new sections and pages, because anyone joining an ongoing project can refer to the guide for the exact styles to use.
Second, a guide allows us to standardize the CSS, keeping it small and quick to load. By using the guide as an inventory of modules and code, both designers and developers can quickly see if new designs deviate from established standards, and decide as a team if it’s worth expanding the codebase or if something already written is easily extended. When you have no guide, this is impossible, which in my experience usually means that new styles are written—resulting in bloated CSS.
Third, design consistency is easier to maintain, as the designer can look in one place to reference the site’s components and ensure a cohesive look and feel throughout. This is especially helpful on larger teams and at enterprise-level companies where you may have an entire team of designers working on the site. And when design consistency is maintained, the codebase is also kept smaller.
Fourth, communication becomes clearer as well. When I built out pages in a large-scale project and passed them off to the designer, she used the language of the various classes in the guide to ask for changes. This meant that we didn’t have any confusion on either of our parts as we sped through revisions. It also gave the entire team a shared vocabulary, like the names of modules, to use in talking about the designs once they were coded.
The final benefit I’ve found is that you can use your guide to do a quick QA pass. The guide may not be identical to the pages you eventually build out, but it can point out issues you may have in various browsers. By tackling these early on, you’ll avoid them in later testing.
Below, I’ll take you through starting your own guide, based on my first few weeks at Editorially. (Because when I work on a project without a guide, I’m soon jonesing to make one—just ask my colleagues).
Start your guide with some of your site’s foundations. A foundational element may include the color palette, your grid layout system, or the basic type styles for headers and body text: whatever you feel are the very basic elements to create a page. For Editorially, the most foundational part of our site was the color guide, so I began with that and went from there. I created an HTML document with the markup, linking to the application CSS, so any CSS changes would be automatically reflected in the style guide.
When you look at the style guide created by Yelp, you can see how it starts with the basics: typography, grid, and colors, adding more patterns as it goes along.
A pattern is any self-contained set of markup and styles to make some of your site’s basic objects, like a call-out box used repeatedly, buttons, or the way you lay out a list of links horizontally. At Editorially I documented all the variations possible of button and link styles. So go ahead and add the exact markup you need for each element to your guide.
For example, for a button in the Editorially guide, I simply put <label for="btn" class="btn" href="#">.btn <input type="submit" name="btn" value=".btn" /></label>. And because we link to the same CSS as the application does, the CSS shows correctly in the style guide. Should we change the .btn style, the style guide would change as well.
<label for="btn" class="btn" href="#">.btn <input type="submit" name="btn" value=".btn" /></label>
Keep going through your site and add in patterns as you see them; you may use particular layouts over and over, or a media-object pattern, or a vertical list pattern. Below is an another example from South Tees Hospital, showing some of their patterns for what they call feature blocks. Look for similar things on your own site to document in your guide.
This is also a good time to ask your team what else would be helpful to have in the style guide. Share it, let them take a look, and hopefully they’ll help you fill out all the patterns and modules needed. Don’t forget to have the entire team help you round it out, as it’s a resource for everyone.
If possible, add the bits of interactivity that your site uses, such as dropdowns, modals, or tooltips, which are small hovers with helpful text that gives the user more information. This lets your team see not just the static versions of these things, but the animations as well. So when you’re looking at the guide and hover over or click on items, they’ll actually act as they would on your site.
If you have to do extra work to update your style guide when making changes to your look and feel, the likelihood of it staying up to date is pretty slim. I’ve said it a few times now, but that’s why we linked the Editorially guide to the same CSS as the application—that way, we didn’t have to manually update the guide ourselves. It can be difficult to make updating the guide a priority, but maintenance is critical. Depending on how quickly you iterate on your site or application, you should check up on the guide as a regular task, whether it’s weekly or monthly. When you’re making changes to your site, update your style guide as part of the workflow.
If you’re interested in automation, there are other tools that can make creating the guide even smoother. Two of these include KSS and Hologram. Both tools use things like commenting or YAML inside your stylesheets in combination with something like Ruby to automatically generate your style guide. It would take some work to go back and retrofit your stylesheets with the appropriate comments or YAML for these approaches, but you’d save time in the long run, as these tools make maintenance much, much easier. In addition, A List Apart has put their pattern library on GitHub and featured a blog post on its creation, demonstrating yet another method of building a style guide. The possibilities of what you can do are far greater than what I’ve outlined here; you might poke around to see what may be most helpful for you and your team.
Phew. You’ve done all this work and you’ve created this guide, so now what? How do you get people to use it? The first step is to talk about it. If a new team member comes on board, introduce her to the guide as a way of orienting her with the site, since the guide encompasses so much of both the visual and code languages of your front end.
As long as you’re iterating on a site or application, your style guide will never truly be finished. But having something documented early on, and showing it to teammates and getting their feedback, is a huge help. Involving the whole team in building the guide also makes it feel more like the team’s guide—and gets everyone invested in maintaining and using it on a regular basis.
We’ve made the Editorially guide available as both a public repo on GitHub and online. This was very much a work in progress and an internal team document, so we’ve also got notes, patterns, and a lot of messiness. But the reason for showing it is to reinforce the fact that a style guide doesn’t have to look perfect to be useful. Despite the mess, all of this was incredibly helpful for me and other team members as we continued to work on the application.
So, are you convinced? Are you wishing you had a style guide for your site or application? It will be well worth the effort: make the time, get your team on board, start the build—and be rewarded with a document that speeds up the discussion and development of your site.
For years we’ve thought about the web as a two-dimensional space filled with pages that sit side by side on a flat, infinite plane. But as the devices we design for take on an increasingly diverse array of shapes and sizes, we should embrace new ways of designing up and down. By building interfaces using a system of layers, we solve tricky design problems, flexibly adapt to a variety of screens, and create new patterns that will point the way to future interactions.
In geometric terms, the z-axis is the vertex that measures space above and below the x- and y-axes. Translation for those of us who napped through geometry: it’s how we describe panels and layers that sit above or below one another.
Designing on the z-axis simply means incorporating three-dimensional physics—as represented by the z-axis—into our interface designs. Not the faux-depth of skeuomorphic text shadows and button highlights, but an interface made of components that exist on distinct layers and move independently of one another.
As Andy Clarke has noted, the page is an outdated metaphor for what we’re designing today. Unlike the permanence of ink on paper, a website is a series of dynamic views that can occur in many combinations. Applications require us to consider numerous happy and unhappy paths, and even static marketing sites need reusable design components that can adapt to different content needs.
By using the z-axis to place interface elements above or below one another, we can create better design systems that are more flexible and intuitive to use.
While juggling the constraints of making an interface work across many different screens, I often encounter the same problems. Where do I put this? How do I make this effective for touchscreens? What can I show right away, and what can I hide?
The answers aren’t easy, but fortunately we can count on the z-axis to be there when extra pixels aren’t. Got an options panel that just won’t fit? Trying to add filters but the excess UI clutter doesn’t seem worth it? When you’re running out of space and searching for a clever solution, remembering that you have three dimensions to design in can save the day.
Creating an interface that seamlessly works across the z-axis requires two important elements: layers and transitions.
Incorporating layers is the key to designing on the z-axis, since layers are the way we differentiate levels above and below one another. A layer might contain a single UI element that sits above the rest of the view, or it might be a full screen that appears and disappears as necessary. However you incorporate layers, each should have a purpose—a reason it exists—and be used consistently throughout your site in a way that helps users better understand your design.
A panel that covers up the entire interface, for example, should be one of the most important functions on a site. On the other hand, an option in a secret panel that slides out from behind another object should relate to whatever sits above it, but be less important.
Generally speaking, the higher something sits on the z-axis, the more important it is. Primary navigation menus are usually placed on a higher level than other elements; they might pop over the rest of the view, they might stick to the top of the screen, or they might be accessed by zooming out to a larger menu presentation.
Teehan + Lax takes this to the extreme with the menu overlay on its website. It’s more than a popover; it’s like a page takeover. Look at our menu! it shouts. The sliding animation combined with a new screen layer grabs the user’s attention, while huge font sizes and a larger-than-usual menu of links deliver more content than a typical primary nav bar and (probably) justify the need for a separate layer.
Do I love this bold menu presentation? Yes. Do I think it’s a best practice we should incorporate into every site we build? No way. Not every site needs that much dramatic flair.
But I love how this inspires me to think about a menu as a piece of content in and of itself, and not just more interface cruft. Teehan + Lax highlights the act of presenting a menu to the user and how it can be more than popping up or sliding over from the left—it can be an opportunity for surprise and delight.
Primary action buttons, such as checking in or adding a new post, are often placed above other elements on the z-axis. It’s easy to tell what an app thinks is its most important feature when it’s sitting on top of everything else. Just take a look at Facebook’s chat heads.
Right now, Facebook clearly thinks that messaging is its most important feature. (If you’re unconvinced, Facebook also has a separate Messaging app, and recently paid $19 billion for What’s App.) Since layers allow elements to remain fixed in one place while everything else moves around them, floating action buttons are an easy way to make them more prominent without taking up a lot of valuable screen real estate.
The z-axis gives Facebook an easy way to keep messaging front and center, and even if I don’t like tapping on the disembodied faces of my friends and family, it seems to be working. For clients who want a button to “pop” a bit more, using the z-axis to give it its own layer is one of the more elegant possibilities.
Objects on different layers of the z-axis can move at asynchronous speeds during scrolling. This effect—usually called parallax—was pioneered in video games, but it’s become quite popular in interactive design. When objects move at different speeds, it creates the appearance of depth and simulates the passing of time, making parallax a powerful tool for online storytelling.
Superfluous use of parallax as a trendy eye-catcher has been rightfully criticized, but the ability to move layers independently of one another allows us to animate stories on the web in a way that hasn’t been as effective without the use of video. Sites like Let’s Free Congress and Inception Explained use asynchronous scrolling to turn what could have been flat infographics into visual narratives. By breaking elements apart using layers, each thread can unfold at its own speed while the user controls the pace of the action.
Web designers have always worked within the confines of flat, pixel-based screens, forcing complex interactions onto two visual axes. Layers on flat screens are a hack, but an important one; they’re the first step toward the true multidimensional interactions that are only a few years away. By creating layered patterns in our interfaces now, we help prepare users—and ourselves—for what’s ahead.
When you use layers in an interface design, it’s important to include animations that smooth the transitions between them. Animated transitions serve several important functions: they help soften what could otherwise be a jarring moment of change, they describe where you came from and where you’ve arrived, and they provide cues about how information on the new layer relates to everything else.
Sliding is one of the most common animated transitions because it’s relatively easy to execute and simple to understand. Navigation menus, hidden panels—just slide them out quickly whenever you need them, right? But like anything “simple,” sliding requires more care than you might expect.
The ubiquitous left-hand menu, used in many mobile apps including Gmail, is a perfect example. When activated, Gmail’s menu doesn’t slide anywhere; it’s actually the main window that slides to the right, revealing the menu on the left underneath your inbox.
The distinction is important, because the ability to see the first few words of each subject line keeps the inbox functional even when the menu is engaged; without that persistence, there’s little point to the inbox remaining there at all. Mobile websites that seek to mimic this interaction should take note—sliding a left menu over the top of a webpage usually feels clunky and intrusive compared to sliding the main view over instead.
You can also slide existing elements out of view to reveal hidden panels. Tweetlist slides the keyboard down to show additional tweet options like geotagging or attaching a photo. It’s a clever way to display secondary features that don’t need to be visible at all times, and using the back of the keyboard reinforces the relationship between these options and sending a tweet.
Zoom animation has been around for a while, but its frequent use in Apple’s iOS 7 has increased both its popularity and its infamy. Some people have said the zooming used throughout the operating system—particularly when opening and closing apps—makes them nauseous. While this may be the case, it’s worth understanding the different ways we can use zooming to transition from one layer to another, and why some types of zoom may be more stomach-churning than others.
Enlarging or shrinking single objects has been a common animation in the Apple universe since the release of Mac OS X and the introduction of the dock. It naturally found its way into the mobile world on the iPhone, and users quickly grew accustomed to tapping a photo and zooming into it to see more detail.
In the case of photos, zooming is a simple illusion created by enlarging the image. Everything around the photo remains in place; only the photo itself moves.
The zoom effect used in iOS 7 is more complex. It works by moving the “camera” in and out as you open and close apps so that everything on the screen changes, not just one object. When you close an app, for example, the app window shrinks down into its icon on the homescreen. Watch the background behind the window and you’ll see all the other homescreen objects zoom back into the view as well.
This key difference—zooming the camera rather than a single element—creates a much more immersive illusion. It shifts the viewer’s perspective to a new level on the z-axis. That simulated perspective-shift adds to the wow factor by introducing an element of super-realism: it mimics real-world physics, while producing an effect that would be impossible in real life. It’s no wonder designers are eager to take advantage of the possibilities it offers, in spite of the potential side-effects.
This design experiment from Creative Dash shows how zooming the camera all the way out allows us to use the liminal space around a window. Our canvas is both deep and wide, and this takes advantage of both—though the extreme zoom depth would probably make quite a few users feel sick.
Foursquare has used a much more subtle version of zooming the camera to reveal map details. You don’t travel very far forward, but the zoom-in reinforces the notion that you’re going to a deeper level of information.
Whether you apply zoom to a single object or an entire view, it’s important for the animation to be consistent with the information hierarchy you’re using. When you move the camera out, you should be at a higher level, while zooming in should provide more detail.
Sliding and zooming are two of the most common animated transitions used today, but there are other options, including flipping or folding.
Three-dimensional objects have two (or more) sides, but most user interfaces are like the moon: they have a “light” side that’s always visible and a “dark” side we never see. Flipping an object over creates a new visual space that’s easy for users to understand. The only downside? Flipping is, well, flipping slow.
While flipping is sometimes applied to create a more magazine-like feel, 180 degrees is a big transition; it often feels slow and disruptive. In contexts where speed is critical, the time a flip adds to interactions usually isn’t worth it. That said, if deployed in the right place in the right way, it could be flipping fantastic. Card-based layouts offer plenty of opportunities to flip objects over and reveal additional information.
Gesture-based command centers, holographic interfaces—whatever technology lies over the horizon, we’ll be better prepared to adapt our skills if we understand the principles of designing for information, not just visual tricks for laying things out with boxes and color. Just as print designers once learned to take their talents to the web, we need to learn to take our talents beyond the screen—and getting comfortable with the z-axis is a great place to start.
It’s extremely likely that sometime in 2014, the number of internet users will pass 3 billion. Not surprisingly, the largest areas of growth are developing markets—predominantly Africa and the Asia-Pacific region. These markets are being flooded with mobile devices small and large, fast and slow, smart or otherwise.
Connectivity in these regions is of great interest to large tech companies scrambling for control. Today, however, bandwidth is limited, reliability is questionable, and data plans are small. Even in markets saturated with mobile usage, like the US and much of Europe, connections are often flaky and unreliable.
For all those reasons and more, now is the time to test what you build in sub-optimal situations. Thankfully, there are a handful of tools that can help you do just that from the comfort of your high-bandwidth connection and favorite chair, rather than trekking out to a remote field with a Faraday cage.
If you’re using Grunt or Node.js, there’s a fantastic plugin and module, respectively, that can slow your local server’s connection down to a configurable speed. It’s a great start to network performance testing, but it’s fairly one-dimensional.
Charles is a more robust throttler exposing a lot more control. In addition to amazing tools allowing complete insight to all network requests, Charles can throttle your entire connection, so when enabled, all traffic in and out of your machine is affected. Throttling isn’t the only factor of network performance, however. Latency is a major contributor, and Charles provides control over that aspect, as well.
Unfortunately, these tools don’t expose control over the final, and potentially most important aspect of network performance—packet loss. It has always been the toughest aspect to simulate, but if you’re a Mac and/or iOS user, you have access to the Network Link Conditioner. With control over upstream and downstream transfer speeds, latency, packet loss, and even DNS delay, Network Link Conditioner is a super-powered system-level tool that will fundamentally change the way you build and test things.
Apple provides the Network Link Conditioner through their developer platform, and luckily, it’s accessible through the free developer program, so you don’t have to pay to use it.
The Network Link Conditioner comes with some built-in presets to match common connections, such as EDGE, 3G, and DSL. You can even create and save your own presets, allowing you to easily switch between connection levels for fast testing.
All of these tools open up a new realm of testing and optimization available to us, and as the world changes, network performance testing becomes more and more important. Have you used any other tools or techniques for testing? Share them below in the comments!
Designers are renowned for having egos. But we’re really not all big-headed prima donnas. It’s just that we can devote so much of our time and care to our work that it becomes entangled with our self-esteem.
We’d all love our work to be perfect at the first draft. If we could solve all the potential problems in the project in one pass, without anybody else’s intervention, wouldn’t that make us perfect designers?
Our desire for perfection sets us up for that crushing feeling when a client doesn’t love our work the first time. It creates anger, tears, condescension, bitterness: all the ugly things. Our ego doesn’t want us to see ourselves as flawed, so we’re tempted to see the client as foolish in order to have something to blame the flaws in the work on. That’s how this big fat fragile ego can really get in the way of a good client relationship.
As with any working relationship, we need to be able to empathize with the other party, and understand the position that they’re coming from with their opinions. Design is nuanced; there’s far more to it than finding that one right way to solve a problem and rejecting all the “wrong” ways. Our ideas and the client’s are as likely to be conflicting as they are to be complementary. We can’t let ego get in the way of compromise.
Bravado is ego’s younger, stupider brother. Most days I feel in control of my bravado, but sometimes I’m a little too vocal and critical of the work and actions of others. By showing off my supposed knowledge, I’m trying to mask my insecurity when my work doesn’t feel good enough. That pretty much explains my general attitude at art college and university… (Hey fellow RSAD and Bath Spa students and tutors, I’m sorry you had to put up with that!).
But we need that spike of confidence that ego brings. How could we ever share our work if we didn’t think it was any good? We could spend forever revising our ideas until our designs feel “good enough.” We need a little bit of ego so we can share with others.
Striving for perfection without the input of others doesn’t just put pressure on our self-esteem, it also restricts the scope for a solution. Every time I get that downhearted feeling over client feedback, I remind myself of other projects where I felt that way. In the end, the solution on those projects was always far stronger after multiple iterations. Feedback from clients brought in valuable constraints and thoughtful ideas from someone who understands their context and goals far better than I do.
Sometimes I just need to remind myself that I’m working on a solution with the client: we are both invested. And what we create together may be my adopted project for a few months, but it’s their product to own for many months or years to come.
After almost three years in pursuit of a standardized solution to the problem of responsive images, the Responsive Images Community Group is excited to announce that the picture element is officially coming to a browser near you. Once it lands, we’ll see the trend toward massive, bandwidth-heavy responsive websites begin to slow—and hopefully, reverse—over time.
Since starting out, the Responsive Images Community Group has evolved from a handful of passionate developers sending emails to an organization producing detailed specifications alongside WHATWG and HTML WG members and holding summits attended by representatives of all the major browsers. It took us a while to learn all the rules, but we’ve gotten pretty damn good at playing the web standards game.
When a company is interested in seeing a feature added to the web platform—something that they feel stands to benefit developers and users alike—they invest. After getting a formal thumbs-up from browser representatives, they’ll contribute their employees’ hours to seeing that feature through—from writing the initial proposal to submitting the code that brings that feature to the browsers. Adobe’s work on the WebKit project is a great example of this process in action.
Unfortunately, the last step is the one where we saw ourselves coming up short, for sheer lack of time: submitting the code to land the feature itself. The picture element specification came to life during evenings and weekends, thanks to the efforts of dozens of designers and developers just like you—mailing list conversations took place during desk lunches and Friday nights spent in front of a screen. Blog posts were—and are, in fact—written on crowded commuter trains. We can compete on determination and willingness to put in what time we have, but we just don’t have as much time as a dedicated team of employees. Writing browser patches takes that kind of time.
For that reason, the RICG recently asked the community to sponsor Yoav Weiss’s work on the Blink and WebKit implementations of picture, and together we’ve managed to raise over $10,000 in a little more than a week—enough to cover several months of full-time work on implementation.
Having helped write the spec and prototyped picture in Chromium before, Yoav will know many of the the potential gotchas right out of the gate. In the meantime, the Blink team has plenty of work to do on their side, well beyond just reviewing Yoav’s code. This is a collaborative effort—adding the new code for the picture element means a lot of changes to Chrome’s internals, and those are best left to the experts on the Blink team. Blink developer Christian Biesinger is our point person there, and he’s already working hard to pave the way for picture. Without Christian’s changes throughout the rendering engine, getting picture into the DOM wouldn’t be possible.
Alongside Firefox’s upcoming implementation, spearheaded by Mozilla’s Marcos Caceres—of RICG fame himself—and John Schoenick, this will give us coverage in Firefox, Opera, Chrome, and hopefully soon, Safari. Our aim is to have picture land in the majority of common rendering engines within the year.
We’re putting a lot on Yoav, I know—but I also know that he’s the right person for the job, and implementation is already well underway. Let’s clear the way for him, and together we’ll do something that has never been done before: introduce a feature to the web that was specced, tested, funded, and implemented by the community.
Together we have an opportunity to contribute to the web in tremendously meaningful ways: by introducing a feature that could reverse the trend toward massive, resource-heavy responsive sites, and by further changing the role of web developers in web standards from spectators to active participants. We have a chance to provide a solution to our fellow developers and, above all else, provide a better experience to users—not just our users, but all users of the web.
The method I outlined in my recent article, “Content-out Layout,” is actually the culmination of quite a few different influences. If you’re interested in a deep dive, I have compiled this list of the most useful thinking on the web about ratios, grids, and fluid design. Enjoy!
Grids, as we know them, are having to adapt to a fluid canvas. It helps, first, to have a strong understanding of how grids are built, how they’ve traditionally been applied in design, and how they work into responsive design:
As we stop designing pages on the web, and start designing systems to be applied across myriad viewports, it helps to have the right mindset:
Ratios are nothing new in design. The underlying mathematics of natural phenomena have inspired architects, sculptors and humans in general for centuries:
Using ratios in web layouts has been explored before. I found these two very different posts inspirational in searching for a way to work with ratios in fluid design:
Typographers will find working with scales familiar. There is lots of great thinking, here, that can be adapted for layout:
I didn’t get the space to touch on this much in my article, but even in a fluid environment, it is ideal to think about the relationship of your content area and the viewport. Book designers have been exploring this idea since the 16th century:
I speak fairly frequently at conferences, and I get to listen to a lot of web designers and developers giving their presentations at these events. I often have my laptop open on my knee to keep an eye on Perch support while I listen. What I hear from designers espousing the latest techniques in my conference circuit world jars with the queries I answer in support. An ever-widening gulf seems to be emerging between the “thought leaders” of the web, and the reality of people doing great work for clients on often extremely limited budgets.
At one conference recently, a speaker was reminiscing about how we used to charge for websites by the page. Yet the fact that companies such as SquareSpace are doing so well shows that out there in the world, people do want to build a few web pages. There are many people who do see their sites as being a homepage and a collection of other pages. Perhaps design businesses are charging “by the page” because it makes sense to their customers.
It is very easy—and I know because I’ve been there—to assume that everyone knows what we know, cares about the things that we care about, or has and wants the same business opportunities we do. We can end up participating in a Twitter echo chamber of people who have experiences similar to ours; who are at a similar stage in their career, and tend to think in a similar way. We attend conferences that have a high ticket price and so attract only those sent by companies—and therefore working in larger teams—or highly successful independent designers and developers.
Unless you are sent by a company, speaking at a conference has a cost. If you are someone who charges an hourly rate, you will find that even where a speaker fee is paid, it doesn’t cover the time it takes to prepare the talk, travel, and attend the event. Writing web books is a money earner for only a very few authors. Therefore the voices we hear most frequently are from a particular segment of the industry—those who can afford to spare the time.
We can find ourselves with a small segment of our industry speaking to the same small part of our industry. We can quickly forget that there is a much wider industry, and people working outside of our circle often have quite different challenges and concerns.
Through supporting Perch, we encounter people who are the web designer for their local area. They operate in a “high touch” world, sitting down with their customers and working out how to best serve their business. They are often charging very little for their services, yet are making a huge difference to the businesses they develop sites for. They are doing great work, if we value that work by the difference it is making to those who benefit from it. Yet I rarely hear this type of work discussed outside of talking with our customers.
It is important that best practice is discussed and strategies for working in large teams hammered out. We need thought leaders; we need the people who enjoy debating specifications; we need people who create new tools and ways of working and want to share them with us all. It’s important that there are people who have the time, energy, and space to do this—because people who are just working hard to make a living often don’t have time. The fact that it is perfectly normal on the web for companies to share the things they have learned, even releasing the source code of projects for other people to use, is one of the brilliant things about the world in which we work. It is something we all benefit from.
My fear is that by allowing ourselves to believe that everyone knows certain things, or everyone is working in a certain way, we stop producing great materials for the generalists who create small websites, on their own, with a tiny budget.
When we assume that everyone is working in a similar place to us, we risk masking the important things behind a layer of opinion about the “right” way to do things. We risk creating a barrier to knowledge by bundling accessibility with workflow and solid good practice with personal preferences. It then can all be dismissed as irrelevant in one batch, by a person who builds a website a week for a few hundred dollars for a business who couldn’t afford anything else. That’s no way to encourage the wide adoption of modern methods of building the web.
Grids serve well to divide up a predefined canvas and guide how content fits onto a page, but when designing for the web’s fluid nature, we need something more… well, responsive. Enter ratios, which architects, sculptors, and book designers have all used in their work to help set the tone for their compositions, and to scale their material from sketch to final build. We can apply a similar process on the web by focusing on the tone and shape of our content first, then working outward to design fluid, ratio-based grid systems that invite harmony between content, layout, and screen.
Layout choices can set the tone for our designs. As graphic designer Anne Burdick liked to teach, “the structure of the page can be seen as the embodiment of a particular philosophical perspective.”1 Do we favor order for our content? Or does it require a humanist touch? Should we tempt chaos? Whatever the tone, each can be successfully introduced in your layout through the use of a ratio: even (1:1), golden (1:1.618), or random proportions (no ratio), respectively.
Our chosen ratio will be the DNA from which all of our layout decisions are formed. This one number will connect every element of our design, and by adjusting it, we will be able to dramatically affect the tone of our designs. Ratios with a lower proportion—or smaller difference between numbers—will yield subtler layout differences, and work well for nuanced, quieter content like personal blogs or long reads. Greater proportions energize a composition with dramatic size differences, perfect for more dynamic content.
A ratio can consist of any two numbers, giving us an infinite palette of possibilities, but to narrow things down it might be best to start with some familiar territory. Rational ratios are friendly enough, as the math isn’t too scary:
The Rule of Thirds is a well-known example of the power of rational ratios in layout. Highly structured content—like arrays of images or videos, or text with a neutral or formal tone—is represented best by a rational ratio. These ratios work well when designing for symmetry, but can be used for asymmetrical layouts as well.
In The Book of Rectangles, Spatial Law and Gestures of The Orthogons Described (1956), Czech designer and architect Wolfgang von Wersin compiled a set of dynamic ratios used by artists, architects, and calligraphers throughout history to guide their compositions. According to Wersin, it was believed that “nothing excels these proportions.” Not a bad place to start, then.
The most famous irrational ratio in design is, of course, the golden ratio (the “Auron,” according to Wersin), which is derived from patterns in nature and the human form. Irrational ratios give us smaller increments in proportions, and their idiosyncratic relationships work best in asymmetrical layouts.
On its own, a ratio is not enough to create an engaging composition. Luckily, pure geometry is not our only guide here. I’ve always loved Bringhurst’s concept of choosing typefaces based on who designed them, and where. Perhaps a similar methodology can be applied to layout, where we derive ratios from tangential influences like type choices, or even music.
Successful compositions use variety to create hierarchy and movement. Using our chosen ratio, we can extrapolate an array of sizes much like notes on a musical scale, then build our layouts using the “notes”—or widths—from that scale. We can then repeat and skip around the scale to create a kind of visual melody.
To build our scale, we first select a base unit. I would suggest using your typography’s base font-size to further connect the proportions of your layout to your content. Let’s use 1em to keep the math simple. We then multiply our base unit by the number on the right side of our ratio to generate the next size up the scale, and repeat until we have enough size variants to build our layout. Eight should do.
By deciding sizes based on a scale, we can choose relationships that better fit the tone of our design. Large leaps across the scale can be dramatic. Small steps can be more nuanced than in traditional columnar layouts. No matter the size of the change, the result is geometrically connected by our ratio.
When working with ratios and scales, your layout decisions will become more strictly defined. For example, if we were laying out the content of a blog with the common image-plus-copy pattern (I call this a “blurb”), three or more columns are needed in an even-column grid to give any size distinction between the elements.
In a ratio-based grid, only two columns would be necessary here. Since blogs are intended to be a more personal expression, I think the golden ratio, with its humanist proportions, would be appropriate.
Each text width is 2.618 times larger than its corresponding image, or two steps up on our scale.
Reducing columns helps us out in two ways, giving us:
Our simpler, ratio-based blurb grid codifies a relationship between two elements based on the shape of the content. Using this relationship as a start, we can now flesh out a fluid, content-based grid system.
We can now design simpler grids that build upon and within each other, sharing a common ratio to keep harmony between their various contexts. I call grids like the one used for our blurb example a “content grid.” Content grids define relationships within a portable piece of content and work well for articles, sidebar modules, and other reusable elements of a design system.
To divide up the available viewport space, we can use a global “layout grid” that behaves more like the grids we’ve been using on the web for years now.
Continuing our blog example, we’ll use our scale to derive another content grid for our posts. In a typical blog post, we have a large image, the body of text, social media links, inline images, and some supporting content pulled out into the margins. By trying various arrangements from our scale, we can arrive at a grid that accommodates our content needs.
To convert these widths into fluid CSS percentages, we just need to total the corresponding widths from our scale, and then convert each column using Ethan Marcotte’s famous formula:
target ÷ context = result
…with “target” being a column width and “context” being the sum of all columns used in the grid. (Or if you’re braving flex-box for layout, you can just use the exact ratio numbers from your scale.)
We can build a simple three-section “layout grid” to accommodate our larger content sections: an area for branding and navigation, an area for the main body of content, and a third area for related and featured content links. Our main content area likely needs to be much wider to house our post content, and the navigation area much thinner. We’ll find column widths from our scale that feel right for our layout, giving the appropriate room for each section.
Finally, we place our content grids (the article grid and our blurb grid from earlier) into our layout grid, creating a layout that is both fluid and completely driven by our content. (View the blog demo.)
For comparison, I also built this same layout on Twitter Bootstrap’s 12-column grid. (View the Bootstrap blog demo.) While fairly similar, the ratio-based layout holds up better at any random size.
Adapting our layout to various viewports now becomes much simpler, as we have fewer variables to consider. For this process, we can build a fluid prototype in the browser, then scrutinize where the layout starts to falter when resizing the window.
As the viewport stretches and narrows, our relationships will strain and crack, especially at sizes in between typically targeted device sizes like “tablet” and “desktop.” After exploring how fluid layouts crumble on many well-trafficked sites, I’ve isolated some common issues that signify where a change in grid is needed:
Sevens find an image shortened as its width is scaled down, and adjacent text squished to a tall, unreadable measure. The resulting form resembles a “7,” and creates a conspicuous square of white space beneath the image. This is especially distracting when repeated across a layout.
Drifts are so far removed from their related content that they no longer have any relationship to anything. They may wind up paired with other disparate pieces of content flotsam, or just drift all by their lonesome. Across a layout, drifts destroy hierarchy and cause troubling rivers of negative space to creep in.
Pinches happen as elements get too close to other pieces of content. Relationships are destroyed as the viewer makes incorrect associations: images pair with the wrong headline, links run into a list of their own creation. In extreme cases, content collides—at the cost of all readability.
After adjusting your layouts for fluidity, certain elements will need special attention. Paragraphs should maintain a readable measure, ads should maintain size and relative position, and images should not enlarge beyond what their resolution will allow. Setting a specific width is an easy fix, but does not truly embrace fluidity. Instead, we can set a min-width and/or max-width in our CSS to maintain the integrity of this content.
The use of the grid as an ordering system is the expression of a certain mental attitude inasmuch as it shows that the designer conceives his work in terms that are constructive and oriented to the future.
A ratio-based, modular approach to grids allows us to navigate a medium where we cannot know the container size, nor what type of content will flow into that container. We can build layout systems from our content, and rely on ratios to keep harmonious compositions from these disparate parts. From there, a keen understanding of how fluid designs fail can show us when to adapt these systems, and when to add constraints.
In 2009, and again in 2010, Ethan Marcotte gave us the tools with which to respond. In 2011, Mark Boulton gave us a guiding philosophy. By weaving these highly influential ideas together with a pliable method, we can move towards more sophisticated layouts tailored to the needs of our content, patterned with unique character, and perfectly suited to the nature of our ever-changing web.
The web touches everything an organization does—marketing to customer service, product development to branding, internal communications to recruitment. This is the era of cross-platform digital services, fast networks, and mobile devices. Sounds like the ideal time to be a person who makes websites.
So why do we feel frustrated so often? Why do we experience burnout or depression? What makes it difficult to do work that has meaning, that satisfies us?
The problem is that we need to collaborate, but we haven’t focused on developing our people skills.
Back in the day, we could get by with technical skills alone. If you could get HTML and CSS to work across browsers, you’d find work, and you might even break new ground. Technical skills still matter, but today making digital services that meet users’ needs also depends on our ability to collaborate across many types of boundaries:
Learning people skills is challenging, but when you take the time to develop them, it’ll seem like you’ve gained a superpower—one that allows you to:
Behind each of these scenarios are collaboration problems. Let’s talk about four of the most common ones, and the people skills that can help with each.
Judgments of others are alienated expressions of our own unmet needs.
Although it’s counterintuitive, the first person you need to look out for when you want to collaborate is yourself. Everyone needs appreciation for their contributions. When that need isn’t met, we feel frustrated or angry, and we start judging others.
For example, imagine you’re presenting a prototype of a mobile application to your team. They seem to object, saying that the app would take too long to develop and isn’t “intuitive.” Your defensive instinct might be to tell them that they’re wrong—this is the way we “should” do it—while feeling frustrated because they’re rejecting your work. Notice the judgment? These judgmental behaviors lead to conflict, which prevents collaboration.
You can begin to spot this behavior by looking for language that implies people are “bad” or doing things “wrong,” or that tells people what they “should” do. You may also notice self-judgment, where you tell yourself you’re wrong, or that your work sucks. The jargon term is “negative self-talk” and we all do it.
Rosenberg’s Nonviolent Communication (NVC) model helps us identify these moments before they lead to conflict by focusing on four steps: observations, feelings, needs, and requests. You can observe that your colleagues offered “feedback” (rather than “criticism,” which contains a judgment). Then you can identify your feeling, in this case frustration. (If you’re stuck on “angry” or “upset,” try the NVC list of feelings to get more specific.) Next, figure out what you need: is it respect, appreciation, contribution, autonomy, growth? You may have several unmet needs: try this list for ideas.
Finally, put it all together into a request. You could say, “You shared your feedback about the prototype. I’m feeling frustrated because I need appreciation for my contribution. Would you be willing to share areas where the prototype meets user needs, as well as those where it may not?” Notice that you’re taking responsibility for your own feelings and needs.
NVC is difficult to pull off in the heat of the moment, so you need to practice. Get started by reading Rosenberg’s book.
When we collaborate, everyone shares control and no one knows exactly where they’re going. It’s uncomfortable because we’re leaving what we know and stepping into discovery. We need trust to tolerate this discomfort together. When we aren’t confident about our expertise—when we feel insecure—we can’t build trust, so we find collaboration difficult.
People want the “right” answer, the solution with proven return on investment, the fail-safe plan. Whether it’s a fixed budget, the “right” CMS for the corporate website, or the “best” mix of mobile platforms, people are asking you for certainty. You don’t have all the answers, so you can’t offer certainty without faking it. And you’re afraid that your colleagues won’t accept you unless you pretend to know everything. You feel insecure because you have an unmet need for acceptance, and it prevents you from building the trust you need with your team or client.
Instead of feeling insecure, you can choose to tell yourself that it’s okay not to have all the answers, and use coaching techniques to identify both your strengths and the areas you would like to develop. You can also learn to coach your colleagues. This will help you meet your need for acceptance because you’ll be providing real value to them, instead of pretending to have all the answers.
Coaching others means acknowledging that we we can’t “fix” other people’s problems and instead supporting them to make decisions about their own development. This allows us to get real about skills and growth while also being kind.
Get started with the GROW model, which is a structured conversation based on a set of questions. Notice that the coach doesn’t offer their own ideas or fixes:
You can both learn to coach other people and ask for coaching yourself. For yourself, this means being honest about the areas you want to develop and being brave enough to ask for help. You can even buddy up with a colleague and coach each other using this tool.
The internet is a symbol of disruption for many people: marketers are nervous of the shift from mass media to direct customer relationships, salespeople worry that websites make their skills obsolete, and publishers’ entire business models are threatened by the decline of print. We want to do digital work we can be proud of, but we’re on the front line of this disruption—a front line that’s thick with unmet needs and the feelings they create: anger, frustration, and fear.
Our culture makes things worse. We try to avoid conflict, as if ignoring it will make it go away. We tiptoe around sensitive issues or send long emails that we hope nobody will read instead of engaging face-to-face. We agree to a spec we know will never work, because it seems easier than risking an honest conversation. We choose to avoid “difficult conversations” instead of doing what the project needs.
Imagine a conflict situation: the IT director won’t approve the budget for your new cloud-based web server. Ask yourself what the other person is afraid of. What don’t they know? Why do they perceive the situation differently? To turn conflict into collaboration, you need to listen with empathy.
Listening is a superpower. When you listen to someone with empathy, you meet their need for understanding, which makes them more likely to listen to you. When you see shared humanity—that is, when you realize the person you’re talking to is a human being—you can always find common ground.
Web designers talk about having empathy for users. To overcome conflict, we need to have empathy for our clients and colleagues, too. When our needs for trust and respect are not met, we feel tense, as if we’re about to fight. That makes it difficult to listen with empathy. We can get better with practice. To get started, check out the active listening technique, where you listen, reflect what you heard the other person say, and clarify your understanding.
Our organizations are structured like industrial factories, with each department separated and optimized, working in isolation. Often digital work seems like diplomacy, as you try to get departments to collaborate instead of fighting over turf. If the team designing the mobile application won’t talk to the desktop website team, what hope do you have? You can’t change your organization’s structure on your own, so why even try?
I’ve fallen into the trap of complaining about culture as a way to avoid leading. If I say, “The culture here is the problem,” that’s a version of, “You’re doing it wrong”—i.e., somebody else needs to change. Change only happens when individuals choose to lead. Even if your organization’s culture is blocking collaboration, you can help it to adapt by leading change on a small scale.
You might think that to lead your colleagues through change, you need to present strength, crush opposition, and have a bullet-proof plan. You’ve probably seen managers behaving like this.
But being aggressive is actually a defensive response to feeling insecure. You’re trying to build yourself up by putting other people down. This makes people feel resentful and afraid, which stops them from listening to you.
In her book Daring Greatly, Brené Brown teaches that showing vulnerability is the true indicator of courage. It takes courage to be yourself, to admit that you’re imperfect. If you admit that you don’t have all the answers, people will trust you, and you’ll inspire them to be brave, too.
Being a leader often means being the first person to listen. Share your vision—e.g., designing a digital service that puts users’ needs ahead of organizational structure, and makes a profit too—and listen to your colleagues’ ideas, feelings, and needs. Overcome your insecurity, take a risk, and be brave. It could be as simple as proposing an agile process for your next project, admitting that you don’t know whether it will work, and convincing people to try it by building trust. Or you might bring together a multidisciplinary team from across the organization and work up a minimum viable product, while convincing various stakeholders to trust you. The outcome may surprise you.
As the web continues to transform our society—in ways that both excite us and scare us—we need more than new technologies to keep up. We need collaboration.
Now that you understand how people skills can enable collaboration, you have an opportunity to change your work, and perhaps your organization. Invest your time in people skills and you might just change the world.
I never thought I felt eye strain from looking at big, bright screens all day—I thought my young eyes were invincible. Then I started getting sharp headaches at the end of every day, and I realized I needed to change something.
I decided to finally take the jump and start using f.lux. f.lux is an app that changes the color temperature of your display, adapting the light you see to the time of day, which helps to reduce eye strain. There’s a new beta out for Mac that brings some really fantastic improvements and enhancements (don’t worry, there’s a Windows version too!).
In the morning and afternoon, you’ll see the blue-ish colored light that your screen normally pushes out. As the sun sets, the light will shift to a more reddish color, and when night falls, it’ll become an even deeper red. Every color step is customizable, so you decide how red-shifted you’d like each phase to be—I like mine on the deeper end of the scale.
It’s normal to see blue light during the day, but as it gets darker, that light is harsh on our eyes. Red light is easier on your eyes, especially at night—it’s why red lights are used to preserve vision at night.
When I tell people in our industry about f.lux, I often hear something like, "But what if I’m doing color-sensitive work?" The newest f.lux beta has a feature that allows you to disable f.lux in certain applications. As you switch into an application where you’ve disabled f.lux, your screen will slowly transition to normal colors. The smooth transition will help prepare your eyes for the blue wave of light you’re about to get hit with, so it’s not too jarring.
For anyone who spends hours a day looking at a screen, f.lux is a must-have. We spend a lot of time and effort making sure we use ergonomically-correct keyboards, chairs, and desks, so it’s time we gave our eyes a similar level of treatment.
“Where do you get your inspiration from?” It’s an odd question that designers ask each other. But it’s not asking what motivates us to do our work, or what makes us want to be designers in the first place.
When we’re asked where we get our inspiration from, we’re usually being asked where we find that little seed of an idea that grows into a creative solution to a problem.
As a web designer, the expected answer is often a CSS or Responsive Web Design gallery website, and the underlying question is, Where do you pinch your best ideas from?
When I was in high school, art class exercises were usually formed of slavishly copying an artist’s work. We’d use the tools and techniques the artist used in order to better understand how and why the work was created. This helped us experience the process the artist used to create such work.
Following these exercises, we would usually complete a piece of our own work, with subject matter of our choosing, but using the same tools and techniques as the artist. Here we were learning how to apply the artists’ thinking in the context of our own work.
Every design problem is unique. The context, environment, audience, and goals will never be the same again. But the problems we’re solving can be similar to those that went before. These similarities are what we can use to research potential solutions. When we’re researching the solutions through the experience and ideas of others, it’s like being back in art class again. We’re learning how it feels to use other designers’ tools and techniques, so that we can discover what might suit our own processes. Our wide-ranging explorations lead us each to find inspiration in a different artist or technique. Just as every design problem is unique, there’s no single designer, book, or gallery site that can solve every design problem.
Borrowing ideas isn’t a bad practice. We can research and learn from these resources, although to copy their aesthetics or functionality in their entirety is bad practice. If we copy other designers’ work, regardless of the context of their origins or our projects, we won’t have learned anything, and it will likely result in poor work and an inappropriate solution.
I was discussing inspiration with my friend Bevan Stephens a few weeks ago. We talked about how, at some point in our design careers, we seemed to stop looking for ideas in galleries and similar resources. We didn’t realize it at the time, but somehow we’d gained confidence, and felt we didn’t need to actively search for ideas from aesthetic showcases anymore.
When we start out, we are usually very conscious of every design decision we make. It takes time for us to familiarize ourselves with our preferred rules and patterns. The more experience we get, the more subconscious these design decisions become. We can make a decision without any conscious justification, although we can then unravel our reasoning in a perfectly clear way. I believe this confidence comes to all designers with time.
A similar thing happens with the way we research solutions. We spend a huge amount of time interacting with other designers’ work; in our research and in the products we use. Sometimes a solution, or an element of the execution, will stand out to us. We may just absorb the effectiveness (or ineffectiveness). Or we’ll remind ourselves to save it for later, in a notebook, some kind of resources library, or just in our heads.
The more experience we have, the greater the osmosis. The viewing and filing of the solutions becomes quicker, more automatic. We become more efficient at storing the information and ideas that we need.
Whilst I think I’m getting better at subconsciously storing ideas and potential solutions, occasionally I find myself returning to the design galleries. It’s not usually for a general browse, but more often for looking at a specific category, a particular type of website. I find myself needing to learn again. I seek out ideas from gallery sites when I’m feeling unsure. This usually happens when the context of a project is new to me. It’s a different type of site, product, audience, or approach. I need to supplement my mental library of ideas. I’m not blindly copying work like I might have done when I was starting out, I’m now better at identifying when I need more resources to help me understand a problem. I understand more about how to appropriate ideas and techniques without copying. Still, I need to bolster my confidence. I want to feel as though I know what I’m working with.
Design as a practice and process stays constant, but the technology, audiences and other outputs change around us. We will always be able to apply our skills of seeing, solving problems and making decisions, but the industry standards and best techniques are always changing. The evolving web means we need to keep learning. Still, we need to be smart about how we learn, and understand the difference between learning and copying so we don’t fall back on the work of others when we should be innovating for ourselves.
The revival of the picture element—the responsive images proposal that has seen the most support from the developer community—is exciting news, but there are still some outstanding questions about how the element will really work. Marcos Caceres and Yoav Weiss have put countless hours into the Responsive Images Community Group’s efforts, and are now working toward picture implementations in Firefox and Chrome, respectively. Mat Marquis asked them some questions.
So, we’re getting picture and srcset? I thought srcset was bad?
MC: srcset was never bad in itself—some parts of the syntax were just hard to understand, and it wasn’t able to handle an important use case: “art direction”. The picture element works in conjunction with srcset, giving developers a set of solutions for whatever problem they are trying to solve.
What happened to the src-n proposal that was going around a short time ago?
MC: The src-n proposal (put together by Google’s Tab Atkins and John Mellor) elegantly solved a lot of problems, but introduced some weird markup (the numbered attributes bit), which would have made a mess of browsers’ internals. Some WebKit folks went so far as to call it “a grotesque perversion of the HTML language.”
YW: The biggest innovation in src-n was the sizes attribute. This attribute allows you to specify the dimensions for a set of images and lets the browser take care of the math behind all the resource selection. We’ve incorporated that feature into the latest picture proposal—the src-n proposal was an important step in getting the complete solution that we have today.
I thought picture was done-for—what brought it back?
MC: It was really the rejection of src-n by WebKit that brought it back. By taking picture off the standardization table, there was a new sense of urgency to finding a solution for responsive images.
Mozilla was quite keen on src-n, as we thought that, despite being hard to implement, it did a fair job of addressing the problems developers were facing. But, when the WebKit community said no to src-n, the Blink community backed out as well—the Blink folks weren’t sold on it to start with, so they weren’t apt to do something the WebKit folks were not keen on either. With Mozilla having rejected the original srcset proposal, this really only left picture on the table.
Then, a clever dude from Opera software—Simon Pieters—had an epiphany: what if we flip the way that browsers process picture? If we used the picture element as sort of a controller for an old-fashioned img element, we could get all the same functionality with way less implementation overhead.
YW: The old proposal’s version of picture acted like a better featured version of img itself, in the new proposal the picture element is there only to contain possible resources for the img element, and assists it in choosing the right one.
img can keep doing what it does best: loading and displaying a resource, and the new element just handles the parts that img doesn’t excel at—namely, picking the most appropriate resource based on a combination of factors: viewport size, pixel density, and so on.
This design enables browsers to avoid re-implementation and re-testing of img’s core functionality with picture, and reduces the maintenance costs of the feature significantly.
Does picture need to land before we can do any real performance testing, or are there tests in place before the element officially hits browsers?
MC: I think picture will need to land before we can get any real numbers. However, given that srcset is already in Chrome 34, sites might already be seeing some of the benefits that come from a responsive image solution.
YW: Some of the performance benefits can be measured by using today’s polyfills. For example, the data savings from using picture are not likely to change significantly compared to the data savings benefits of using Picturefill, minus the actual polyfill download. One difference is that current polyfills have to work around browser-level optimizations—like prefetching sources—while a native solution will be able to take advantage of them.
How does the current implementation in Chrome differ from implementations in existing polyfills? Do I need to change my code to get it working natively or will it integrate seamlessly?
YW: The Blink implementation is of srcset’s DPR syntax, which is a subset of the original srcset syntax. If the polyfill you use has implemented that syntax (the x variant of srcset), and does feature testing, it’s highly possible that you won’t have to modify your site’s syntax.
MC: As with any emerging standard, things can change quickly. There is always risk in prematurely adopting a solution before it becomes a standard. Fortunately, the high visibility and level of interest in this feature means the community is already updating their polyfills. For example, Scott Jehl is planning to update Picturefill to support the new syntax and attributes of picture soon.
Will the type attribute on source be supported when picture is implemented in Chrome and Firefox?
MC: I don’t see any reason why it wouldn’t be. An important part of a responsive images solution is having the ability to use emerging image formats like WebP, particularly if using these formats will benefit users without excluding those still using legacy browsers. As a community, we need to make sure there is a solid test suite to check for support of the type attribute—and we need to hold them accountable if the browsers don’t get it right!
YW: What Marcos said!
How interoperable will picture be with MQ variables?
MC: In most cases, as long as you can use the final MQ variable syntax anywhere you would use a media query normally, then it should“just work”.
YW: The latest MQ variable proposal—dubbed “CSS aliases”—is still in its very early stages, but we’ve been thinking about how it might work with picture already. Interoperability with picture is going to be important for any MQ variable proposal.
Is bandwidth a consideration right now, or is this all mostly about viewport sizes and densities?
MC: Bandwidth detection itself isn’t a relevant factor. Consider, when you go to a conference, the Wi-Fi you connect to has high bandwidth, yet you get slow speeds. Bandwidth is variable—particularly on cellular connections. Most of the time,what users care about is costs, particularly on mobile. I think what we want is for users to have the ability to tell the browser, “If I’m on my cellular plan, just give me the 1x images.”
This is the beauty of the declarative picture solution: all developers have to do is provide a suitable set of images for the browser to choose from. It’s then on browsers to do the right thing, on behalf of the user.
You can expect that minimizing the cost of browsing is something we browser vendors will be competing on—a definite win for our users.
YW: Initial implementations likely won’t take network quality into account—but as Marcos said, the solution’s markup provides all the information the browser needs to later take that into account. All in all, the solution aims to give this control to the browsers, and through them, to the users themselves.
Is it safe to use the picture element in a production site, once these implementations launch?
MC: I would wait a little bit—until there’s public confirmation from all the big browser vendors—before using picture on a production site. I’d hate to see people include this prematurely, and a change to the markup come along later. With that caveat: the really nice thing about the new picture markup is that developers must include an img element for it to work. This means that by default—and with no exception—the fallback for picture will work with legacy browsers. It’s then up to authors to include an optimized image for legacy browsers inside the img element.
YW: In general I agree with Marcos, but I guess it also depends on the polyfills available and their support for the new markup. Once Picturefill and other polyfills support the markup, it might be possible to roll the new markup out to live sites that we control—like our own—as long as we make sure that we can adapt quickly in the unlikely event that the markup changes.
And then in 2004, a wonderful man named Dave Shea—the same prophet who had launched the CSS Zen Garden just eight months earlier—helped our entire industry kiss all that goodbye with a single, deceptively simple A List Apart article.
Rereading CSS Sprites: Image Slicing’s Kiss of Death from the comfort of today’s privileged position, it’s easy to miss how new and revolutionary Dave’s thinking was.
Today we take sophisticated CSS for granted, and we expect our markup to be just that—clean and semantic, not oozing behavior and leaking layout. But in 2004, removing all that cruft from HTML took courage. And it was an act of absolute wizardry to conceive that a grid of images in a single master GIF or JPEG could replace all those http calls and subfolders full of tiny images thanks to CSS’s hover property and cropping ability. Admittedly, Dave couldn’t have done what he did without Petr Stanicek’s (Pixy) Fast Rollovers Without Preload, an ingenious predecessor to CSS Sprites which Dave readily acknowledged in his groundbreaking ALA article.
If you want to know how big an impact CSS Sprites: Image Slicing’s Kiss of Death had on our industry, consider that, ten years later, CSS Sprites are still web design’s standard best practice for adding non-textual interactive cues to a web page.
As we celebrate 25 years of the web, let’s also admire the accomplishments of the last ten years by the brilliant members of our web design community. Congratulations and thank you, Dave Shea—and congratulations to us all.
A couple of days after Macklemore took home this year’s Grammy for Best Rap Album, Slate pop critic Jack Hamilton wrote a scathing reaction titled Don’t hate Macklemore because he’s white. Hate him because his music is terrible. Somewhere between comparing Macklemore to Upworthy—“Macklemore is the rap game Upworthy: He hawks hip-hop that switches out faked emotion for real intellect and faked intellect for real emotion”—and putting anyone that enjoys Macklemore’s music in one of three categories—shallow, dull, or even immoral—Hamilton listed the reasons why Macklemore’s music was bad: his beats and melodies are cliché, his lyricism is weak, and Macklemore is blatantly profiting off his white privilege and hypocrisy. (I have to confess that I had no clue that Upworthy had already jumped the shark.)
What was most interesting about Hamilton’s piece was the unfortunate, but abundantly common, message hidden between the lines: if you enjoy Macklemore, you have terrible taste in music.
So, let’s talk about taste.
Hamilton’s reaction is pretty representative of our individual attitudes toward subjectivity (or, if you prefer agnostic terminology, unknowability). We acknowledge that our tastes, whether they be religious, political, musical, aesthetic, and so on, are uniquely ours. But simmering just below the surface is the magma of reasons for why my tastes are better than yours. And given the right circumstances—such as an award ceremony that promises to determine the best music across today’s genres—the magma rages to the surface.
Hamilton almost catches himself mid-eruption with his nod to “a Times piece far more levelheaded than this one,” but it’s short-lived. Once the eruption is underway, there’s not much you can do except watch its bubbly awesomeness incinerate rhyme and reason.
I think we all could relate to Hamilton’s dormant rage, if not specifically for or against Macklemore or even with regards to musical selection. But when it comes to the reasoning provided, it doesn’t take a philosopher to deduce that his is circular and shaky, and barely makes a dent in trying to prove that Macklemore’s music is objectively terrible.
What is abundantly clear, though, is that Hamilton sees no beauty in Macklemore’s music.
And that’s OK. We are all entitled to our Celine Dions.
Beauty lies in the eye of the beholder is a notion that we take for granted. But often our words and actions give away our true feelings. Deep down (or actually, just below the surface), we don’t seem to really believe that beauty is subjective.
Tomes have been written about this question across the arts and sciences. One of the most holistic, succinct, cited, and relevant analyses that has stood the test of time is an essay by the 17th century philosopher David Hume. Titled Of the Standard of Taste, Hume’s essay was one of the first to explore the existence of an objective beauty. And it continues to lay the foundation for the debate even today.
Like a brilliant politician, Hume managed to (almost) convincingly argue both sides of the debate—that beauty is subjective and it is objective—in one eloquent breath. “To seek in the real beauty, or real deformity, is as fruitless an enquiry, as to pretend to ascertain the real sweet or real bitter,” he wrote, just a few paragraphs before making the seemingly contradictory assertion, “A true judge in the finer arts is observed, even during the most polished ages, to be so rare a character; Strong sense, united to delicate sentiment, improved by practice, perfected by comparison, and cleared of all prejudice, can alone entitle critics to this valuable character; and the joint verdict of such, wherever they are to be found, is the true standard of taste and beauty.”
The gist of Hume’s essay seems to be that beauty does lie in the eye of the beholder, but that some beholders are better able to identify that elusive, but existent, true beauty. Hume even provided a five-part litmus test—strong sense, united to delicate sentiment, improved by practice, perfected by comparison, and cleared of all prejudice—for identifying these truly skilled beholders.
It’s the final condition that exposes the chink in his argument’s armor, even today: cleared of all prejudice.
Three centuries since its publication, what we do know for fact thanks to advances in too many fields to list (but here’s a sampling), is that prejudice runs so deep that you’re never cleared of all of it. Sometimes our prejudices develop firm roots over time nurtured by the abundance of cognitive biases that affect our thoughts and actions every second. In other cases, as this excellent Upworthy video demonstrates, you can change what you find beautiful in 60 seconds flat. The result in either case is the same: our reasoning, no matter how sound it may seem or eloquent it may sound, is always tainted.
In The Righteous Mind, social psychologist Jonathan Haidt brings together research from a variety of fields to unequivocally conclude, “Reason is not fit to rule; it was designed to seek justification, not truth. Anyone who values truth should stop worshipping reason.”
Taking it one step further, Haidt also provides a poignant metaphor for how our minds truly work:
The mind is divided, like a rider on an elephant, and the rider’s job is to serve the elephant. The rider is our conscious reasoning—the stream of words and images of which we are fully aware. The elephant is the other 99 percent of mental processes—the ones that occur outside of awareness but that actually govern most of our behavior.
The implications of Haidt’s conclusion to the question at hand—Is there such a thing as true beauty?—is that the answer will never be a “yes” if supported only by reason.
Ironically, to prove that something is objectively beautiful, you will need to furnish more than just reasoning. Whether it’s seemingly objective (like Hume’s) or suspiciously subjective (like Hamilton’s) is mostly irrelevant.
This brings us to the obvious question for product designers: what does all of this mean to me professionally? How does it apply to designing products that are aesthetically pleasing? Does it even matter?
Even though it doesn’t sound like it, I am a believer in the notion that taste is a supremely important characteristic of good product design. But it seems clear to me the effort to acquire good taste, something that we’re very enamored with in our current design culture, is a mostly futile enterprise. In fact, it’s downright counterproductive. This is because good and virtuous taste, by its very nature, is exclusionary; it only exists relative to shallow, dull, and apparently, immoral tastes. And if good design is about finding the most appropriate solution to the problem at hand, you don’t want to start out with a solution set that has already excluded a majority of the possibilities compliments of the unicorn that is good taste.
Good taste is a myth. A story our rider creates to serve the needs of the elephant. And the sooner you kill your good taste idol, the sooner you’re going to give yourself a chance to be a better designer. It frees you up to add taste as another tool in your designer’s toolbox. Consequently, instead of focusing on good taste, your focus becomes the right taste for the problem at hand. There’s a subtle but profound difference.
An added benefit of killing your good taste idol is one that’s characteristic of all types of idolatry homicide: it is emotionally freeing. Where you once spent your time protecting the fragile shrine you built for your preferred sensibilities, whether they are excited by flat colors, skeuomorphism, tight grids, loose grids, subtle shadows, three-dimensionality, or countless other things, you are now freed up to dedicate those brain cycles to the quest for solving your problem as broadly and well as possible. And the best part is that you don’t end up riding the emotional roller coaster that’s part and parcel of all idol worship. If someone doesn’t like something, you don’t take it personally because, well, it isn’t personal to you anymore. It’s just feedback, and most often, it’s useful.
As for the Grammy for Best Rap Album? Here’s what’s fair in my opinion.
If you tell someone that Kendrick Lamar should have won instead of Macklemore, that’s completely justified. But if you erupt with the reasoning that his music is objectively better than Macklemore’s, don’t be surprised when they respond with something along the lines of Lamar’s own lyric: Bitch, don’t kill my vibe.
The World Wide Web celebrates its 25th birthday with a newly launched website commissioned by the World Wide Web Consortium (W3C) and designed and developed by A List Apart’s own creative director/designer Mike Pick and technical director Tim Murtaugh.
All of us at A List Apart are proud to know and work with you, and thrilled to contribute to the worldwide conversation the web has made possible.
Last week, the world’s largest photo service, Getty Images, announced a new policy allowing their images to be embedded on websites for no charge. The images are embedded through an iframe which pulls from Getty’s CDN, and are watermark free, though there is a 75 pixel-high footer included.
Let’s start with the good: everyone who publishes content on the web just got free access to the largest repository of images in the world—the majority of their millions of photos are embeddable.
The bad news is that Getty isn’t doing this just to be nice. That’s not to say it’s a bad decision—I think it’s a fantastic decision on their part. Craig Peters, an executive at Getty, said, “Our content was everywhere already.” Getty’s images are obviously big piracy targets, and this is a way for them to turn that around and benefit from it—it’s not a matter of if they will monetize embedded photos, it’s a matter of when.
In regards to monetization, Peters had the following to say:
We’ve certainly thought about it, whether it’s data or it’s advertising … We’ve seen what YouTube’s done with monetizing their embed capabilities. I don’t know if that’s going to be appropriate for us or not.
Advertising around the photo, over the photo, detailed tracking of image usage—they’re all options at Getty’s disposal. The most likely scenario is a combination: tracking and using data to sell ads to put around photos in a more targeted way.
In addition to the content implications of embedded photos, Benjamin Mayo brought up a few other interesting points to think about. Regarding usage of Getty’s CDN, Benjamin said:
It also means that your site now has a dependency on Getty’s CDN uptime. If their servers are down, your site has no images.
In a footnote, Benjamin brings up the fact that, though somewhat extreme, “if Getty is hacked, you could be distributing malware to your visitors in mere minutes.”
Again, all this is not to say you shouldn’t use Getty’s embedded images, but it’s important to be aware of these things when considering usage.
Aside from the content and policy implications, I was curious about how we could best implement image embeds. I did a bit of experimentation over on CodePen, and I can’t say the results were encouraging.
By default, the iframe has width and height attributes that match up to the actual image size (which is fairly small, most are 600 pixels or less). Removing those attributes to rely on CSS rules for sizing causes the image to collapse all the way down to a tiny thumbnail. The image will scale up to the maximum size it can without breaking the bounds of the iframe—but scaling images up will produce extremely pixelated results.
Performance-wise, there are a few things to keep in mind. The iframe content is entirely controlled by Getty. They could put something in there that could greatly affect your site’s performance—be it a huge, unoptimized image, slow scripts, or irresponsible requests. In that same vein, since you have no control over the images, you won’t be able to implement a responsive image strategy, once those solutions are released into the wild.
Ultimately, when considering Getty embed usage, keep in mind the advantages and disadvantages, but make the decision that’s right for you. I feel like I often end on this note, but it’s necessary: always choose what’s right for you, your team, your clients, and your use case, regardless of prevailing opinions.
Editor’s note: Updated 3/16/14 to reflect code changes made by Getty after the post’s original publication.