Web Design

12 Little-Known CSS Facts

CSS Tricks - Fri, 04/18/2014 - 18:57

Sometimes these types of articles are cheezy and filled with fairly obvious stuff, but not when Louis Lazaris does them. All of these are pretty non-obvious.

Direct Link to ArticlePermalink

12 Little-Known CSS Facts is a post from CSS-Tricks

Categories: Web Design

Improve the payment experience with animations

CSS Tricks - Fri, 04/18/2014 - 18:43

Nice stuff by Michaël Villar. Tasteful, subtle, informative animations is a trend I can be behind.

Reminds me of the nice stuff Val Head has been teaching, Hakim El Hattab's experiments, Codrops examples, Pasquale D’Silva's thinking, Effeckt.css...

Direct Link to ArticlePermalink

Improve the payment experience with animations is a post from CSS-Tricks

Categories: Web Design

Animating SVG with CSS

CSS Tricks - Thu, 04/17/2014 - 16:52

There isn't just one way to animate SVG. There is the <animate> tag that goes right into the SVG code. There are libraries that help with it like Snap.svg or SVG.js. We're going to look at another way: using inline SVG (SVG code right inside HTML) and animating the parts right through CSS.

I played with this personally recently as my Alma mater Wufoo was looking to freshen up the advertising graphic we're running here. My latest design around here uses SVG quite a bit and I thought this would be another perfect opportunity to use it some more.

The finished product is pretty simple. Here's it is:

See the Pen Wufoo SVG Ad by Chris Coyier (@chriscoyier) on CodePen.

Let's check out how it's done.

1. Design the Ad / Have a Plan

This might seem like an how to draw an owl moment, but this article is about animation so let's get there as quickly we can.

My plan for this ad was to make a super simple Wufoo ad with their classic logo, colors, and general branding. Then add a little flair.

  1. Make the letters kind hop off the page a little. Wufoo is a fun word, let the letters have some fun.
  2. Back in the day we made a T-Shirt with dinosaurs on the front and on the back it said "Fast. Smart. Formidable." Which are traits of both dinosaurs and Wufoo, not to mention the fun little play on words with FORMidble. Let's make those fade in and out.
  3. To make the connection with the dinosaur thing complete, we'll have a T-Rex head pop up from the bottom curiously, then zoom away. The word "Fast." will come in as he zooms away which is another nice little connection.

I put all the parts together in Illustrator.

Notice how the logo and tagline text are outlines. That means they are just vector shapes and will render just perfectly as-is in the SVG, as <path>s. The text you see there "Fast." is left as text in Illustrator.

When I save this out from Illustrator, that will be left as a <text> element.

2. Save as SVG

Illustrator can save this directly as SVG:

You can open that SVG file in a code editor and see the SVG code:

4. Clean Up the SVG, Give Shapes Classes

You might wanna run it through SVGO to optimize it and remove the DOCTYPE and stuff. But more importantly for this post, you'll want to give the the different shapes class names, that way we can select them in CSS and do stuff!

<svg version="1.1" id="wufoo-ad" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 400 400" enable-background="new 0 0 400 400" xml:space="preserve"> <!-- background --> <rect class="wufoo-background" fill="#D03E27" width="400" height="400" /> <!-- logo letters --> <path class="wufoo-letter" fill="#F4F4F4" d="M60.858,129...." /> <path class="wufoo-letter" fill="#F4F4F4" d="..." /> <!-- etc --> <!-- dinosaur --> <g class="trex"> <path ... /> <path ... /> </g> </svg> 3. Insert the SVG

You can copy-and-paste that SVG right into the HTML where you want the ad. But that'll just slop up the template probably. In all likelihood you'll just do something like:

<aside class="sidebar"> <div class="module module-ad"> <?php include("ads/wufoo.svg"); ?> </div> ... 4. Animate!

Now we have these shapes in the DOM that we can target and style like any other HTML element, let's do that.

Let's say we want to do this as a 10 second timeline.

Words Fade In/Out First

The first thing we want to happen is the Fast. Smart. Formidable. thing. Each word will show for one second. So we'll make an animation where the word shows for 10% of the time:

@keyframes hideshow { 0% { opacity: 1; } 10% { opacity: 1; } 15% { opacity: 0; } 100% { opacity: 0; } }

Then target that first word and have the animation last for 10 seconds (10% of that is 1 second):

.text-1 { animation: hideshow 10s ease infinite; }

The next two letters will start out hidden (opacity: 0;) and then use the exact same animation, only delayed to start a bit later:

.text-2 { opacity: 0; animation: hideshow 10s 1.5s ease infinite; } .text-3 { opacity: 0; animation: hideshow 10s 3s ease infinite; }

The extra 0.5s on each is to accommodate the fading out time period of the word before it.

Letter Pops

As soon as those letters are done animating, we'll have the letters in WUFOO do their jiggle jump thing, like this:

The trick here is that we'll make the animation only 5 seconds long, but run it once forwards and once backwards. That way it matches our 10 second timeline, is placed right in the middle where we want it, and we only need to scale in one direction, because when it reverses it will scale back.

Each letter has a slight bit of delay so they happen off-kilter a bit:

.wufoo-letter { animation: kaboom 5s ease alternate infinite; &:nth-child(2) { animation-delay: 0.1s; } &:nth-child(3) { animation-delay: 0.2s; } &:nth-child(4) { animation-delay: 0.3s; } &:nth-child(5) { animation-delay: 0.4s; } } @keyframes kaboom { 90% { transform: scale(1.0); } 100% { transform: scale(1.1); } }

The above is in SCSS just for brevity, and does not include any prefixing (as you would need in production).

I feel like animation-delay is a property that would benefit from native randomization in CSS. Would be neat to see the letters be randomly delayed just a bit each time.

Dinosaur Last

As soon as the words are done, the dinosaur will peak its head up. Even though the dinosaur is made up of lots of <path>s, we can target them all together by targeting the <g> (group) tag that wraps them all.

Because using translate to animate position is better, we'll do that in the keyframes:

@keyframes popup { 0% { transform: translateY(150px); } 34% { transform: translateY(20px); } 37% { transform: translateY(150px); } 100% { transform: translateY(150px); } }

We wanted this animation to "last" about 3 seconds. It actually runs in 10 second loops, but you'll only see it do stuff for 3 seconds. When the translateY(150px) is in effect, the dinosaur is moved so far below, you don't see anything. By 37% of that animation (around 3 seconds) you'll have seen it move slowly up, then quickly back down).

When we apply this animation, we'll make sure that:

The dinosaur is hidden at first
The animation is delayed so it starts right after the words are done with their fade in/out dance.

.trex { transform: translateY(150px); animation: popup 10s 6.5s ease infinite; }

The dinosaur pops down right at the last second, which is when the word "Fast." pops back onto the screen (because all the animations are set to infinite, which re-runs them forever). That's a bit of fun synergy there.

5. Making it a responsive / clickable ad

One of the beautiful things about SVG is that it's scaleable to any size without losing quality. To make an inline SVG like this scale while maintaining its aspect ratio, we can use the ol' padded box technique.

<div class="wufoo-ad-wrap"> <svg class="wufoo-ad"> ... </svg> </div> .wufoo-ad-wrap { height: 0; padding-top: 100%; position: relative; } .wufoo-ad { position: absolute; top: 0; left: 0; width: 100%; height: 100%; }

The idea here is that the "wrap" will always be a perfect square, relative to its width. Then we absolutely position the SVG within that perfect square, which will happily resize itself.

Since this is an ad (which of course should be clickable), rather than using a <div> for the wrap, you could use an <a href="">, just make sure you set that to be display: block;.

Final thing, for reference.

I think there is a future for this kind of thing in display advertising, particularly because of the CSS control and easy, sharp resizing.

Animating SVG with CSS is a post from CSS-Tricks

Categories: Web Design

Product Management Learnings

snook.ca - Thu, 04/17/2014 - 12:29

I've been a product manager for over a year now. I'd like to think I've learned a lot along the way. I want to document that journey to date and into the future.

It's the inaugural issue of the newsletter. I'm kicking this one off with a bunch of books that I've read plus a couple articles to boot. Expect more of the same in future newsletters. If you have any article suggestions, feel free to ping me on Twitter at @snookca or via email at jonathan@snook.ca. Thanks for following along!

The Innovator's Solution: Creating and Sustaining Successful Growth eBook

The Innovator's Solution is much more technical than I expected and does a great job of breaking down what's needed to avoid "the innovator's dilemma".

The Discipline of Market Leaders: Choose Your Customers, Narrow Your Focus, Dominate Your Market eBook: Michael Treacy, Fred Wiersema: Kindle Store

This book is a great companion piece to The Innovator's Solution. This book is older, having been written near the end of the 1990s. It's also not as technical of a book as The Innovator's Solution. However, there's plenty of good useful bits to frame where where I work now (Shopify) to the concepts outlined in the book.

Book: Lean Analytics

Part of the Lean series, Lean Analytics teaches you to "Use Data to Build a Better Startup Faster". Useful for determining what metrics to track and determining your KPI.

Top Hacks from a PM Behind Two of Tech's Hottest Products

"I don't see the PM's job as having all the product ideas. I see it as keeping the engineering and design teams firing on all cylinders." There's so many useful bits in this lengthy article that speak to the heart of product management.

But what IS the Minimum Lovable Product?

Despite the title, the article mostly focuses on how to rapidly prioritize stories and using that to figure out what the minimum "lovable" product is.

If you'd like to follow along more closely to this journey, subscribe to the newsletter.

Categories: Web Design

The Death of the Web Design Agency?

A List Apart - Thu, 04/17/2014 - 11:19

Others have gone as far to say that the very concept of a user experience-focused agency simply isn’t a long-term play, largely because of what the big folks are up to. Facebook and Google went on a design/product buying spree specifically because they needed to figure out how to own this thinking themselves, and other tech companies have followed. And more traditional industries, like insurance, media, and retail? They’ll develop robust in-house capabilities soon, if they haven’t already.

Ready to pack up your things and start a landscaping business? Not so fast.

Greg Hoy, Differentiate or Die?

In The Pastry Box Project today, Greg Hoy of Happy Cog talks honestly about why the first quarter of this year sucked for most web design agencies (including ours), assesses the new and growing long-term threats to the agency business model, and shares his thinking on what we in the client services design business can do to survive, and maybe even thrive.

Categories: Web Design

Cennydd Bowles on UX & Design: Letter to a Junior Designer

A List Apart - Thu, 04/17/2014 - 08:30

I admit it: you intimidate me. Your work is vivid and imaginative, far superior to my woeful scratchings at a similar age. The things I struggle to learn barely make you sweat. One day, you’ll be a better designer than me.

But for now, I can cling to my sole advantage, the one thing that makes me more valuable: I get results. I can put a dent in cast-iron CEO arguments. I can spot risks and complications months in advance. In the wager that is design, I usually bet on the right color. People trust me with their stake.

So, if you’ll humor me, maybe I can offer a few suggestions to speed you toward the inevitable.

Slow down

You’re damn talented. But in your eagerness to prove it, you sometimes rush toward a solution. You pluck an idea from the branch and throw it onto the plate before it has time to ripen. Don’t mistake speed for precocity: the world doesn’t need wrong answers in record time.

Perhaps your teachers exalted The Idea as the gem of creative work; taught you The Idea is the hard part. I disagree. Ideas aren’t to be trusted. They need to be wrung dry, ripped apart. We have the rare luxury that our professional diligence often equates to playfulness: to do our job properly, we must disassemble our promising ideas and make them into something better.

The process feels mechanical and awkward initially. In time, the distinction between idea and iteration will blur. Eventually, the two become one.

So go deeper. Squander loose time on expanding your ideas, even if you’re sure they’re perfect or useless. Look closely at decisions you think are trivial. I guarantee you’ll find better solutions around the corner.

Think it through

We’d love to believe design speaks for itself, but a large part of the job is helping others hear its voice. Persuasive rationale—the why to your work—is what turns a great document into a great product.

If you haven’t already, sometime in your career you’ll meet an awkward sonofabitch who wants to know why every pixel is where you put it. You should be able to articulate an answer for that person—yes, for every pixel. What does this line do? Well, it defines. It distinguishes. But why here? Why that color? Why that thickness? “It looks better” won’t suffice. You’ll need a rationale that explains hierarchy, balance, gestalt—in other words, esoteric ways to say “it looks better,” but ways that reassure stakeholders that you understand the foundations of your craft. Similarly, be sure you can explain which alternatives you rejected, and why. (Working this through will also help you see if you have been diligent or if you’ve been clinging to a pet idea.) This might sound political. It is. Politics is just the complex art of navigating teams and people, and the more senior you get, the more time you’ll spend with people.

Temper your passion

Your words matter: be careful not to get carried away. Passion is useful, but you’ll be more effective when you demonstrate the evidence behind your beliefs, rather than the strength of those beliefs. Softer language earns fewer retweets but better results. If you have a hunch, call it a hunch; it shows honesty, and it leaves you headroom to be unequivocal about the things you’re sure of.

Similarly, your approach to your work will change. Right now design is an ache. You see all the brokenness in the world: stupid products, trivial mistakes, bad designs propped up with scribbled corrections. That stupidity never goes away, but in time you learn how to live with it. What matters is your ability to change things. Anyone can complain about the world, but only a good few can fix it.

That fury, that energy, fades with time, until the question becomes one of choosing which battles to arm yourself for, and which to surrender. Often this means gravitating toward the biggest problems. As you progress in the field, your attention may turn from tools and techniques to values and ethics. The history of the industry is instructive: give it proper attention. After all, all our futures shrink with time, until finally the past becomes all we have.

You’ll come to appreciate that it can be better to help others reach the right outcomes themselves than do it yourself. That, of course, is what we call leadership.

Finally, there may come a point when you realize you’re better served by thinking less about design. Work and life should always be partially separate, but there’s no doubt that the experiences you have in your life shape your work too. So please remember to be a broad, wise human being. Travel (thoughtfully) as much as you can. Read literature: a good novel will sometimes teach you more than another design book can. Remind yourself the sea exists. You’ll notice the empathy, sensitivity, cunning, and understanding you develop make your working life better too.

But you’re smart, and of course you realize this is really a letter to the younger me. And, alongside, it’s a lament at my nagging sense of obsolescence; the angst of a few grey hairs and the emerging trends I don’t quite understand. Which is mildly ridiculous at my age—but this is a mildly ridiculous industry. And you’ll inherit it all, in time. Good luck.

Yours,
Cennydd

Categories: Web Design

This week's sponsor: Harvest

A List Apart - Wed, 04/16/2014 - 12:48

Have you ever billed hourly? A List Apart is brought to you this week by Harvest, a beautifully crafted time tracking tool for creative shops.

Start a trial before the year slips away.

Categories: Web Design

How to Deal with Merge Conflicts in Git

CSS Tricks - Wed, 04/16/2014 - 08:00

The following is a guest post by by Tobias Günther. Tobias works for Tower, the Git client for Mac and authored the new (free) book Learn Version Control with Git - A step-by-step guide for the complete beginner. Tobias is going to share a bit of information about a very uncomfortable moment when using Git: the merge conflict.

Everybody has a list of things they don't like: an appointment at the dentist, a traffic jam, or a canceled flight. When I was preparing my book, I wasn't surprised that a lot of designers and developers would add merge conflicts to this list without hesitation.

When using Git for version control, there is nothing to fear. Once you understand how merge conflicts work and how to deal with them, I'm sure you'll be able to cross them off this list.

You Cannot Break Things

The first thing that you should keep in mind is that you can always undo a merge and go back to the state before the conflict occurred. You're always able to undo and start fresh.

If you're coming from another version control system (e.g. Subversion) you might be traumatized: conflicts in Subversion have the (rightful) reputation of being incredibly complex and nasty. One reason for this is that Git, simply stated, works completely different in this regard than Subversion. As a consequence, Git is able to take care of most things during a merge - leaving you with comparatively simple scenarios to solve.

Also, a conflict will only ever handicap yourself. It will not bring your complete team to a halt or cripple your central repository. This is because, in Git, conflicts can only occur on a your local machine - and not on the server.

How a Merge Conflict Occurs

In Git, "merging" is the act of integrating another branch into your current working branch. You're taking changes from another context (that's what a branch effectively is: a context) and combine them with your current working files. Have a look at this introduction to branching if you're new to the concept in general.

A great thing about having Git as your version control system is that it makes merging extremely easy: in most cases, Git will figure out how to integrate new changes.

However, there's a handful of situations where you might have to step in and tell Git what to do. Most commonly, this is when there are changes to the same file on both branches. Even in this case, Git will most likely be able to figure it out on its own. But if two people changed the same lines in that same file, or if one person decided to delete it while the other person decided to modify it, Git simply cannot know what is correct. Git will then mark the file as having a conflict - which you'll have to solve before you can continue your work.

How to Solve a Merge Conflict

When faced with a merge conflict, the first step is to understand what happened. Did one of your colleagues edit the same file on the same lines as you? Did they delete a file that you modified? Did you both add a file with the same name?

Git will tell you that you have "unmerged paths" (which is just another way of telling you that you have one or more conflicts) via "git status":

Conflict Markup

Let's take an in-depth look on how to solve the most common case: when two changes affected the same file on the same lines.

Now is the time to have a look at the contents of the conflicted file. Literally open it in your code editor. Git is nice enough to mark the problematic area in the file by enclosing it in "<<<<<<< HEAD" and ">>>>>>> [other/branch/name]".


The code from your current branch is on top, the code from the branch you are merging in is on the bottom.

The contents after the first marker originate from your current working branch. After the angle brackets, Git tells us where (from which branch) the changes came from. A line with "=======" separates the two conflicting changes.

Cleaning Up

Our job is now to clean up these lines: when we're done, the file should look exactly as we want it to look. It can be necessary to consult the teammate who wrote the conflicting changes to decide which code is finally correct. Maybe it's yours, maybe it's theirs, or maybe a mixture between the two.

Opening the raw file in your editor and cleaning it up there is perfectly valid, but not very comfortable. Using a dedicated merge tool can make this job a great deal easier. You can configure your tool of choice using the "git config" command. Consult your tool's documentation for detailed instructions. Note that just because you have git installed doesn't mean you have a dedicated merge tool installed, these are separate, optional software tools.

Then, in case of a conflict, you can later invoke it by simply typing "git mergetool".

For this example, I've used Kaleidoscope on Mac:

The left and right panes stand for the conflicting changes; a far more elegant visualization than <<<<<<<" and ">>>>>>>".

You can now simply toggle which change shall be taken. The middle pane shows the resulting code; in good tools, you can even edit this further.

Now, after cleaning up the file with the final code, all that's left is to save it. To give Git a hint that you're done with this file, you should quit the merge tool to continue. Behind the scenes, this told Git to execute a "git add" command on the (now formerly) conflicted file. This marks the conflict as solved. Should you decide not to use a merge tool and instead clean up the file in your editor, you'll have to mark the file as resolved by hand (by executing "git add <filename>").

Finally, after resolving all conflicts, a merge conflict situation needs to be concluded by a regular commit.

How to Undo a Merge

As already said, you can return to the state before you started the merge at any time. This should give you the confidence that you can't break anything. On the command line, a simple "git merge --abort" will do this for you.

In case you've made a mistake while resolving a conflict and realize this only after completing the merge, you can still easily undo it: just roll back to the commit before the merge happened with "git reset --hard <commit-hash>" and start over again.

Tools Can Make Things Easier

I've already mentioned it briefly: being equipped with good tools can make your life quite a bit easier. A proper merge tool will help you better understand a conflict scenario and make the right decision.

Have Confidence

With all the safety nets in place that Git provides, there's really no need to be afraid of merge conflicts in any way. Once understood how they work and what your options are, you should be ready to merge like there's no tomorrow. Always keep in mind: you can't break anything!

Note from the Editor

Tobias modestly left out Tower as an excellent tool to help with merge conflicts. In fact one of the reasons I personally use Tower is because I like how it helps with with merge conflicts.

It's very clear when you have a conflict:


And right-clicking on the conflicted file gives you some nice options:

So my process is usually:

  1. Is it very obvious to me whether my changes to this file or the other branches changes to this file should "win"? If so, select the relevant "Resolve <file> Using Mine" or "Resolve <file> Using Theirs"
  2. If I need a closer look, pop it open in a code editor and check it out. Then maybe still I can use one of those options.
  3. If it's more complicated, manually fix it up and then choose "Mark <file> as Manually Resolved" from Tower.
  4. Sometimes use a Merge Tool if there is a lot of complex fixes, which Tower also supports opening conflicts in via the "Open <file> in Merge Tool" option.

How to Deal with Merge Conflicts in Git is a post from CSS-Tricks

Categories: Web Design

Features Are Complicated

CSS Tricks - Mon, 04/14/2014 - 21:51

Why can't I edit my tweets?! Twitter should allow that.

It's so simple right? CRUD apps (Create, Read, Update, and Delete) are app-building 101! What a gross oversight. But wait. Just as a fun nerdy little exercise, let's think about what a feature like this might take for the Twitter team. I don't work there or have any inside knowledge, so this is all hypothetical for the sake of understanding app development.

  • Should you be able to edit any tweet you've ever tweeted at any time?
  • Or should you just have a few minutes to do it until it locks?
  • Do you offer this to everyone? Opt-in? Opt-out?
  • Should you be able to edit tweets or direct messages also?
  • What does it look like to edit a tweet? Can it be simple and obvious? Does it need additional UI? How do you expose that UI? Is it worth the extra UI?
  • Does the tweet go out to the public timeline immediately or after the editing grace period?
  • What if someone favorites a tweet and it is later edited? Does it shed the favorites? E.g. a tweet that originally said "I like pancakes!" could be later edited to "People that favorited this like clubbing seals!" (or much worse).
  • Same question, with retweets. And with replies.
  • Are there any social or moral implications of this?
  • How does tweet editing affect the overall feel of using Twitter? Would a time delay affect that feel? Would people think of tweets differently?
  • Does tweet editing make hacked accounts an even more dangerous prospect?
  • How do third party clients handle tweet editing? Is there a public API for it? How complex is that?
  • Or do you only offer tweet editing through the web? How does that move go over with developers?
  • How do you ensure third party editing offers an up-to-par UX? Does that matter?
  • If tweets aren't time-delayed, how do you handle edited tweets through the API? - How do you tell third-party clients to update a tweet they are currently displaying rather than show a new one?
  • Where do edited tweets go? Back on top of the timeline, or stay where they are?
  • Should it be visually displayed that a tweet has been edited? How do you enforce that in third-party apps?
  • Are there legal implications here? What if someone tweets something illegal and then changes it to something legal?
  • Does tweet editing open up any kind of bad guy behavior? What kind of mis-use can be expected?
  • What are the infrastructural concerns? Are all revisions saved? How much additional web server and database load is this?
  • Do you throttle editing like you presumably do for tweet creation?
  • How actually requested is this feature? Is it just a vocal minority?
  • What's in it for Twitter if they go down this path? Happier users? Is that a guarantee?
  • How much time, effort, and money is this going to take? (Design, development, UX, testing, etc) Are they prepared to support this for the life of the product?
  • Is the team into the idea or would it be grueling and not-fun?

We could probably double that list on our own and that's just looking from the outside. Software is tough. Being smart and responsible with the features of that software is even tougher.

Features Are Complicated is a post from CSS-Tricks

Categories: Web Design

Style Guides On Parade

A List Apart - Fri, 04/11/2014 - 12:00
» Style Guides On Parade

If you loved this week’s “Creating Style Guides” piece by Susan Robertson, you’ll thrill to Susan’s follow-up posting, on her personal site, of style guide links galore!

Categories: Web Design

The decline of the mobile web

CSS Tricks - Thu, 04/10/2014 - 15:25

Chris Dixon:

Mobile is the future. What wins mobile, wins the Internet. Right now, apps are winning and the web is losing.

John Gruber:

We shouldn’t think of “the web” as only what renders in web browsers. We should think of the web as anything transmitted using HTTP and HTTPS. Apps and websites are peers, not competitors. They’re all just clients to the same services.

Perhaps it's not HTTP and back end web that is in danger, but it's the front end that's in danger.

For whatever reason I don't feel particularly worried for the web, even front end. It feels like a safe long-term bet.

Direct Link to ArticlePermalink

The decline of the mobile web is a post from CSS-Tricks

Categories: Web Design

This week's sponsor: New Relic

A List Apart - Thu, 04/10/2014 - 12:38

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.

Categories: Web Design

CSS-Tricks Chronicle XVII

CSS Tricks - Thu, 04/10/2014 - 09:02

I've had the pleasure of being on a couple of podcasts recently other than ShopTalk (where we most recently interviewed Julie Ann Horvath about, among other things, her GitHub exit).

I was on How to Hold a Pencil where Reuben Ingber and I chat about what it's like to be a beginner and where to go next.

I was on Pencil vs Pixel where Cesar Contreras and I talked about capturing ideas, motivation, and the future.

I was on the CDNify podcast as well.

Spring is breaking finally here in Wisconsin so it feels good to be back biking around town. I've been doing a good job at going to the gym and sticking with my training. We even trained outside today for the first time this year.

I'm just about to take off for a few weeks though. I'm headed down to Tampa, Florida to see some friends (I used to live there, back in the Wufoo days) and we're also getting together there as Team CodePen for an in-person sprint.

I leave from Florida and head up to North Carolina where I'm picking up a new camper trailer, the SylvanSport Go, which I'm pretty stoked about. It just so happens that MerleFest is going on at the same time so I'm going to meet some of my bluegrass buddies there for the weekend.

Then I need to high tail it back to Wisconsin because I have a flight down to Champaign, Illinois for the University of Illinois Web Conference where I get to keynote one of the days.

From there I fly to Columbia, South Carolina for ConvergeSE.

Then finally back home, where I only have a week before another big adventure. I'll save that for next time.

We've been hard at work at at CodePen. The new feature releases were a little slow for a while because we were buried in a huge one: Teams. It might seem like a simple thing, but it was anything but. We even talked about it a bit on the podcast.

Perhaps I haven't mentioned here? We're doing a new podcast over at CodePen, a kind of self-documentary of what it's like running a web software business. We call it CodePen Radio.

Taxes are another thing on my mind. They are due the 15th here in the US, and despite starting on them as early as I could, I'm cutting it down to the wire. It's crazy how late you can get needed documents to do it all properly. I think I'm just about done and it's a very painful year (mostly due to my own lack of planning in paying quarterlies). Gonna have to tighten the belt for a few months.

CSS-Tricks Chronicle XVII is a post from CSS-Tricks

Categories: Web Design

Matt Griffin on How We Work: My Life with Email

A List Apart - Thu, 04/10/2014 - 08:30

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:

We don’t need no stinking badges

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?”

Filters, filters, filters

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).

More apps!

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!).

Say when

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.

Save your brainpower

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.

It’s all in the timing

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.

Inaction leads to rumination

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.

Expectations for the medium

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.

And on and on

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.

Categories: Web Design

Easy Color Contrast Testing

A List Apart - Wed, 04/09/2014 - 08:30

We have plenty of considerations to design for when crafting websites. 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.

Animation showing a progression through step one

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.”

Animation showing a progression through step two

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.

Animation showing a progression through step three

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.

Animation showing a progression through step four

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.

Categories: Web Design

The Heartbleed Bug (or: You Should Consider SSL Unsafe for a While)

A List Apart - Tue, 04/08/2014 - 15:00

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

Be careful out there.

Categories: Web Design

Font Size Idea: px at the Root, rem for Components, em for Text Elements

CSS Tricks - Tue, 04/08/2014 - 09:33

Me, for the last year or so: "rem's are so cool! I'm gonna size everything with them, that way I can adjust the font-size on the root element and everything will scale with it!" It was a nice dream. And it wasn't a disaster. That's what I'm doing right now here on CSS-Tricks and this is how it plays out in a very simple scenario:

That comes from essentially:

/* Document level adjustments */ html { font-size: 17px; } @media (max-width: 900px) { html { font-size: 15px; } } @media (max-width: 400px) { html { font-size: 13px; } } /* Type will scale with document */ h1 { font-size: 3rem; } h2 { font-size: 2.5rem; } h3 { font-size: 2rem; }

I admit that I like that simplicity, but I'm starting to think it's a little too dreamy for all but the simplest of sites. The main issue: you just can't expect type that you set at one screen size to look just right by simply scaling it down entirely proportionally. Big type might get too big scaling up. Small type might get too small (a common one that gets me). Or even the reverse of either, where big type might not get small enough.

If any of those things happen, then you're making @media query specific adjustments which not only gets confusing but isn't very efficient (adjusting size just to adjust it again to fix it).

So here's my idea: you still keep px size adjustments at the document level so you can make easy/efficient sweeping size changes. But then each module on the page has a font-size set in rem. Actual text elements (h1, h2, p, li, whatever), if you size them at all, are sized in em, and thus become relative to the module.

This way you can adjust font-size at a module level, which is pretty easy. The chances the type within a single module have good proportions and can scale together nicely is high. So that would play out like this:


Not to scale. Just showing what units would go on what.

You can play around with the idea here by adjusting the sliders:

See the Pen Em AND Rem by Chris Coyier (@chriscoyier) on CodePen.

At a certain medium size, everything looks fine. Scaling up, you can get to a point where the main articles are a good big size, but the sidebar stuff doesn't need to be that big. With this system it would be easy to target them and notch them back down. Scaling down, those sidebar modules get a bit too small too fast, so you could notch them back up easily. There might even be sizes where you equalize things because you've gone single column (or the like).

This is how it would go down:

/* Document level adjustments */ html { font-size: 17px; } @media (max-width: 900px) { html { font-size: 15px; { } @media (max-width: 400px) { html { font-size: 13px; } } /* Modules will scale with document */ .header { font-size: 1.5rem; } .footer { font-size: 0.75rem; } .sidebar { font-size: 0.85rem; } /* Type will scale with modules */ h1 { font-size: 3em; } h2 { font-size: 2.5em; } h3 { font-size: 2em; }

I put "idea" in the title because I haven't actually built a site doing this yet, but it makes sense to me and I'd surely try it.

Font Size Idea: px at the Root, rem for Components, em for Text Elements is a post from CSS-Tricks

Categories: Web Design

Creating Style Guides

A List Apart - Tue, 04/08/2014 - 08:00

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.

What is a style guide?

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.

Starbucks style guide.

(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).

Why should I use a style guide?

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.

Imagine starting a page build with information like this from the South Tees Hospital guide; a donation box would be done in seconds.

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.

Yelp clearly states how buttons are used, keeping button styles consistent across the site.

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.

Steps to build out your guide

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).

Assemble your site’s basics

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.

Yelp. Add in more patterns

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.

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.

South Tees Hospital.

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.

Document interactivity

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.

Tooltips in the Editorially guide. Make maintenance easy

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.

Iterate your guide

Once you have the bulk of your site’s or application’s components listed in your guide, you’ve got a wealth of tools to make it even more handy. As I built out the style guide for Editorially, a colleague pointed out the fantastic tool by Filament Group, X-rayHTML, which is a small JavaScript library to help you build out documentation. X-rayHTML takes the styled objects on your page and generates a nicely formatted code block below them, without any further code from you. You can also add prism.js for syntax highlighting, which color-codes the code for greater readability.

A look at the Editorially style guide with X-rayHTML at work.

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.

Using the guide

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.

Categories: Web Design

The Z-Axis: Designing for the Future

A List Apart - Tue, 04/08/2014 - 08:00

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.

Using the z-axis to solve design problems

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.

1. Layers

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.

Menus

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.

Action buttons

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.

Storytelling

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.

2. Transitions

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

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.

Zooming

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.

Other transitions

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.

What comes next

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.

Categories: Web Design

Frosting Glass with CSS Filters

CSS Tricks - Mon, 04/07/2014 - 12:36

The following is a guest post by Bear Travis, a Web Standards Engineer at Adobe. I'm a fan of how Adobe is pushing the web forward with new design capabilities, and doing it in a responsible way. CSS filters is a good example. They knew they were desired because Photoshop paved the way. They brought them to the web with a sensible syntax and they helped with both the spec and browser implementation. Now we're seeing them in stable browsers, and they are advocating use through responsible progressive enhancement. Hallelujah. Here's Bear with a tutorial about just that.

While filters such as contrast, saturate, and blur have existed in image editors for some time, delivering them on the web has historically required serving images with those filters already applied. As browsers begin to incorporate filters as part of the web platform, we can begin breaking down complex visual effects into their component parts, and implementing them on the web. This article will examine one such effect, frosted glass, and how CSS filters provide a cleaner, more flexible solution than static images.

Old School: Frosted Glass with Images

The frosted glass effect has been kicking around the internet for a while; we even saw it here on CSS-Tricks back in 2008. The idea behind the effect is relatively simple: just blur and lighten the area behind overlaid content. The content gains higher contrast with its background, but you still maintain a rough idea of what's going on behind it. The CSS-Tricks article uses two images: a standard version and a frosted version (blurred with a white tint). In our example, a card slides up to reveal content, while frosting over the background.

Demo

See the Pen Frosted Glass Effect Using Multiple Images by Adobe Web Platform (@adobe) on CodePen.

The HTML

The markup is relatively simple. We only have a single article that contains content.

<article class="glass down"> <h1>Pelican</h1> <p>additional content...</p> </article> The CSS

We first size everything to the viewport. Then, we overlay a blurred version of the background on top of the original background. Finally, we add a white tint. The overflow is hidden to prevent scrolling and to clip the effect to the .glass element.

html, body, .glass { width: 100%; height: 100%; overflow: hidden; } body { background-image: url('pelican.jpg'); background-size: cover; } .glass::before { display: block; width: 100%; height: 100%; background-image: url('pelican-blurry.jpg'); background-size: cover; content: ' '; opacity: 0.4; } .glass { background-color: white; }

The above CSS will create our blurred and lightened overlay. We also need to shift the overlay down to the bottom of the page, leaving just enough space to view the header text. Since the blurred image is a child of the overlay, we also need to shift it back up by the opposite amount in order to keep it aligned with the body background. Because the demo uses transitions, I chose to use CSS transforms rather than the background-attachment property, as CSS transforms can be hardware accelerated.

.glass.down { transform: translateY(100%) translateY(-7rem); } .glass.down::before { transform: translateY(-100%) translateY(7rem); } .glass.up, .glass.up::before { transform: translateY(0); } Notes

If you'd like a further breakdown, I built a deconstructed version of the effect.

The above technique is straightforward, and has solid browser support. Although I spruced up the demo a bit with transitions, the other required features – generated content, opacity, transforms and background-size – all have solid browser support ranging back to IE 9 (with the exception of Opera Mini).

New School: Frosted Glass with Filters

The duplicate image technique requires maintaining a blurred image along with the original, which can become a pain if you need to reuse the effect for multiple images. For example, responsive designs may require swapping in different images at different screen sizes. Or, template layouts may drop in images dynamically (eg, a different header image for every blog post). For these cases, it would be nice to generate the effect using only the source image. After all, we're just blurring it.

This is where CSS Filters come in handy. They allow us to apply the blur in the browser, using the CSS filter property.

The CSS

We can adjust the CSS for the frosted glass overlay to be the original image with a blur filter applied.

.glass::before { background-image: url('pelican-blurry.jpg'); } .glass::before { background-image: url('pelican.jpg'); filter: blur(5px); } Demo

See the Pen Frosted Glass Effect Using Filter Effects by Adobe Web Platform (@adobe) on CodePen.

Caveats

Easy peasy, right? Unfortunately, CSS Filters are somewhat new. That means they may be vendor prefixed, and that their browser support is not yet universal. However, filters have a longer history in SVG, and applying SVG filters to HTML content via CSS has wider browser support. You can easily add them as a fallback for when CSS filters are not supported. The above demo actually does just that.

To add an SVG filter, we include some inline SVG in our HTML markup, and reference the filter with a url(). Pro tip: An alternative is to encode the SVG filter and reference as a data url, but that format is a bit more difficult to read in an article.

<svg xmlns="http://www.w3.org/2000/svg" version="1.1"> <defs> <filter id="blur"> <feGaussianBlur stdDeviation="5" /> </filter> </defs> </svg> .glass::before { background-image: url('pelican.jpg'); /* Fallback to SVG filters */ filter: url('#blur'); filter: blur(5px); }

There will still be cases where neither CSS nor SVG Filters are supported by a browser. In that case, the user will see text on a lightened (tinted but unblurred) background, which isn't too shabby.

Conclusion

Filters allow us to use effects in the browser that were previously only available in image editors. As an element's style, rather than a rendered image, they are easier to alter and reuse. You can use CSS Filters in current versions of Chrome, Safari, and Opera, and they are under active development in Firefox (no word yet on Internet Explorer). With a little care towards fallback behavior, you can start using them today.

Frosting Glass with CSS Filters is a post from CSS-Tricks

Categories: Web Design