An Event Apart Roundup – Part 1

This is Part 1 of a series. Visit Part 2 here.

I had the good fortune to attend An Event Apart Boston last week. The speakers were inspirational. The content was brilliant. Even the food was excellent. Jeffrey Zeldman and Eric Meyer really know how to put on a show. This is (part 1 of) a breakdown of what I learned at the event and how I plan to use it.

The short version

Don’t have time to read the whole post? That’s ok. I know you’re busy. Here’s the Reader’s Digest version.

The long version

Ok, now on the good stuff. Pieces of this roundup were drawn from Notes from An Event Apart by the brilliant and more-talented-than-me Fred LeBlanc.

Put Your Worst Foot Forward

By Jeffrey Zeldman

People make mistakes. Designers & developers make lots of them. Zeldman hit a home run explaining how and why these mistakes can actually be good for us. They can help us learn and evolve.

Trust your gut

When we meet new people, we instantly start to form impressions of them. A meeting may be brief, but we come away with lasting impressions―good or bad. This is never more true than in job or client interviews. While a potential boss or client asks questions & interviews you, use that time to interview them as well. Form opinions. Be discerning. If it’s not a good match―if it doesn’t feel right―don’t take the job.

Take your time

It’s tempting to dive right in to a new project. Don’t do it. Be slow and methodical in collecting data and defining expectations. Boilerplate contracts are a bad idea. Give each situation its due.

Communicate clearly

Reporting to a committee is bad. A change in leadership is bad. Define a project manager on your end and a singular point of contact on the client’s end. One-to-one conversations are always clearer and simpler than many-to-many.

Be flexible―plan for change

Add padding to your estimates (extra time and extra money―30 or 40% extra). You will inevitably spend that time and money anyway. Never budget exactly what is needed. Projects never work out that way.

Raise your rates

The clients who send projects last-minute and try to nickel-and-dime us are the ones who don’t respect what we do. Quoting a higher rate (double it every two years) will drive away those clients and bring in better, more professional, more respectful and cooperative clients.

Summary

1. Know before you go.
2. Keep expectations on track and in sync.
3. Constantly course-correct.
4. Tell the truth.
5. Phrase it from the client’s/boss’s point of view.
6. Report bad news before the client/boss notices it.
7. Have a recovery plan.
8. Apologize—but never denigrate yourself or your team.
9. Have an exit strategy.
10. We all make mistakes.

Object Oriented CSS

By Nicole Sullivan

CSS and front-end optimization have a much bigger impact on page load than databases or processing (much to my surprise). Nicole proved this point with statistics and data from Google, Yahoo, Bing, ShopZilla, and AOL. Stubbornella, as she’s known on the web, explains and demonstrates how treating CSS as object-oriented markup can dramatically improve a site’s performance and overall experience.

Why performance matters

Yahoo monitored their page load time and compared it with users’ activity. They found that a 400ms delay in load time (less than half a second) caused a 5-9% drop in full-page traffic. By running experiments, Google found that if you slow down your user experience, people will use your site less.

These sites & experiments found that abandonment, searches, page views, and conversions are all impacted by poor performance. More importantly, they found that their most active users are most affected. I.e., if your site is slow, you are hurting your best customers the most.

How to fix your slow site

The two biggest factors are HTTP requests and file sizes. This lesson is well-learned with things like CSS sprites: combine images, call them only once. The same is true with CSS files. And yes, you should compress your files before serving them.

Want smaller files? Write less code

If we write better CSS code, we can do more with less. Browsers have different default stylesheets, so they render things differently. These differences account for a lot of our headaches and excess code. Use a global reset, but be smart about it. Don’t reset a font-color once and then re-reset it later.

The cascade, inheritance, and specificity

Classes can be applied in any order, it doesn’t matter. Last-appearing rules will overrule previously-defined rules. The same is true for first or last-appearing stylesheets. Properties are always inherited from parent tags. Styles applied to an ID will always “win” over styles applied to a class. Inline-styles are stronger than stylesheet rules. However, !important will win over everything, even inline styles.

Aggregation

It’s a good practice to style for the general rule, and then define a few exceptions. For example, your site has error message, success messages, and info messages. Since they’re all messages, create .message { border:1px solid; } and then, define exceptions: .error { border-color:red; } and .success { border-color:green; } etc. In your markup, add class="message error" and class="message success". This way, you only define the border-width and style once. Re-using the .message class will be a performance freebie. It has already been defined and doesn’t tax the browser’s engine more than once.

Note: Nicole strongly recommends against “daisy chaining” classes: .message.error in your CSS. It’s unnecessary, since these rules will be applied with .error anyway. And, it’s unsupported by some older browsers.

Stylesheet Sanity―what we can do

• Reduce or avoid duplication. Look for patterns. Does one style or theme repeat itself? Define the commonalities and then define the exceptions (instead of defining new versions over and over).
• Improve your code’s predictability. New team members (or you, 6 months from now) should understand and respect patterns in the code, rather than writing new patterns.
• Apply styles to classes, not IDs or elements. This way all rules start with the same strength. Let the cascade determine specificity.

In conclusion―avoid CSS kudzu

Work hard to minimize your code. Be economical about how many lines you write. The goal is to be efficient and effective with as few lines as possible. (Kudzu, by the way, is a vine that is growing out of control.)

The CSS3 Experience

By Dan Cederholm – A live demo of Dan’s talk is available here

Dan Cederholm gives us a simple, yet brilliant new way of thinking about the web. Websites have three layers: markup on the bottom, style in the middle, and now experience on top. CSS3 creates the experience.

Progressive enhancement

In other media, we let the capability of the device determine the user experience. Consider the example of black & white TV vs. color HDTV. Networks broadcast the same content, but the experience of consuming that content will be very different. With CSS3, we can apply the same principle to the web, providing an enhanced experience to those who support it.

Critical vs. optional

Progressive enhancement should not be used for critical elements. Things like branding, core content, and necessary functionality should be accessible to all, on any device. Use CSS3 enhancements for non-critical, “bonus” pieces.

Vendor prefixes

Prefixing our CSS3 rules with -webkit, -moz, -o, etc. is annoying. But, since the CSS3 spec isn’t finished yet, it’s the best we can do. Live with it for now :)

Also, think future! When using vendor-prefixes, place the non-prefixed version last. This way, when browsers support non-prefixed CSS3 rules, the generic one overwrites the prefixed rule.

RGBa & opacity

Using rbga values allows us to combine color and opacity in one rule. Specify red, green, and blue values, along with an alpha channel opacity value. I.e., rgba(0, 128, 255, 0.5). This rule defines a light blue color, and sets it to 50% opacity. Rgba is not supported by older browsers, so be sure to specify a color using hex or rgb first, then overwrite it with rbga for more modern browsers.

Multiple backgrounds

Silverback, a popular user testing application, uses a Parallax effect on their site. As the browser window changes width, multiple background layers move at different rates, creating a 3d feel. In CSS3, we are able to define multiple background images to the same element and position them independently. (The 3d-like movement of these background images is a different story.)

Defining multiple backgrounds is simple… div { background:url(img-1.png) repeat-x fixed 0 0, url(img-2.png) repeat-x fixed 40% 0; } As with rgba, be sure to define critical background images in separate declarations to allow for IE.

Animation

CSS animations are pre-defined rules, set to an assigned name. Trigger those named rules with “-webkit-animation” (and the non-prefixed version, “animation.”) These animations are best when used in user-interaction (on hover, for example).

Define your animation before you call it. This code is taken from Dan Cederholm’s Moon example. He calls his animation “pulse.”

@-webkit-keyframes pulse {
0% { -webkit-box-shadow: 0 0 12px rgba(51,204,255,.2); }
50% { -webkit-box-shadow: 0 0 12px rgba(51,204,255,.9); }
100% { -webkit-box-shadow: 0 0 12px rgba(51,204,255,.2); }
}

Once the animation is defined, call it, using the assigned name as an attribute:

#pulse:focus {
-webkit-animation: pulse 1.5s infinite ease-in-out;
}

Part 1 Conclusion

Contained in these three talks are years and years of brilliance and expert-level experience. I’m humbled to have witnessed and understood them. If I may summarize these three 60-minute sessions of genius in short list, here it is.

Zeldman

• Be clear, cautious, and honest when accepting clients
• Only take the good ones who respect what we do
• Raise your rates

Sullivan

• Front-end performance is hugely important
• Write smart, well-organized, efficient CSS
• No CSS kudzu

Cederholm

• Use CSS3 to progressively enhance your users’ experience
• The experience won’t be the same in every browser
• That’s ok

This is part 1. Visit Part 2 here. AEA screen photo borrowed (without permission―please don’t sue me) from ZDnet’s The Web Life.