CSS-Tricks

Five Questions with Paul Irish

Chris Coyier — Thu, 27 Oct 2011 04:41:47 +0000

Paul probably doesn't need an introduction around here. He's this smart successful front end developer dude who's work fuels our inner critic. So instead of a lengthy intro, I'm just going to drop a bunch of links so we don't have to worry about it later.

Works at the Goog on the Chrome Developer Relations Team. Lead developer of Modernizr. One of the creators of the HTML5 Boilerplate. Member of the jQuery Team. Creator of a bunch of useful one page sites. Links up a bunch of cool stuff on Twitter. Doesn't like bands.

Here's five questions I thought would be interesting to hear Paul answer.

*Chris: Would we be better off or worse off if Internet Explorer decided they were going to use the WebKit rendering engine? Long term and short term.

Paul: Tough to say, but as it's never going to happen, I'll just sidestep the meat of your question. Gecko, WebKit and Trident will be around and will never merge. Ever!

At this point though, the IE engineering team is so engaged that really the priority is not getting WebKit into IE, but rather fixing IE's situation. We're looking at yearly releases from IE, which looks pretty good. But each release is expected to last 10 years in the wild. (IE8, 9, and 10 will be supported until 2020) Compare that to Chrome and Firefox, who sunset their old versions after 6 weeks when the new version ships... and it means we're going to have a mess of IEs to simultaneously support. So, really, our pain isn't standards compliance and developer pain with IE's new releases, it's dealing with many versions of IE to design our experiences, QA against, and deal with for years after their launch.

*Chris: How does the development of the developer tools in WebKit work? Are they actively improved by the Chrome team, then contributed back to the WebKit project, and in turn used by Safari? Or is there collaboration there by multiple teams?

Paul: Chrome has a really good-sized team actively working on the Chrome Devtools. Though, while I normally call them the Chrome DevTools, I could just as well say the WebKit Inspector; virtually all the work is committed directly upstream to WebKit, so Safari and the other WebKit ports get to benefit. My buddy Peter Beverloo made a nice RSS feed of all inspector commits if you'd like to watch the tools improve day by day.

There are some features in the Chrome DevTools that are unique to Chrome: live-editing of script and heap profiling are two big examples. But I'm very excited about the work the team has done on remote debugging as that is now available to all mobile WebKit ports, which means you're able to profile, view network detail, and edit the CSS live on your device. So pumped for that.

*Chris: Chrome uses a 6-week release cycle. So next spring Chrome will be at "Version 20". What are the advantages to a release cycle like this? What do you say to browsers that aren't on as quick and regular a schedule? And to the peanut gallery with their "version releases used to mean something" mutters.

Paul: There are three parts to this topic:

browser release frequency
versioning
browser version half-life

Release frequency: Chrome, and now Firefox, ship a new version every six weeks. That's good for browser engineers and good for users' security and users' experience with Chrome.

Versioning: Jeff Atwood wrote recently about the Infinite Version and detailed some of the engineering work behind Chrome's update architecture. Web apps iterate quickly (Github ships to production 10+ times a day); I think it's fine that browsers ship with quick iterations, and version numbers are merely just a means to keep track. Applying semantics to version numbers isn't going to work unless we go back in time and Knuth makes demands that everyone abides by. (Webkit is at version 535, FWIW).

Half-life: If Chrome didn't update all its users upon every release, all 120+ million Chrome users would be split across 16 versions. However, with the IE teams new engineering energy, we're seeing a great new browser shipping annually from them, but without a clear picture of how users will be moved to the latest and greatest. I wrote about this a lot more recently.

*Chris: The picture that this paints is pretty grim. Do you really think it will get that bad? If IE can get on the auto-updating browser bandwagon, this problem should melt away pretty quicky right?

Paul: It's tricky. Even if IE10+ are auto-updating (*fingers-crossed*), we'll still have a slow death of IE8 (slow slow slow death, that is. I think we''ll always be in for a lot of pain. So, in order to keep yourself sustainably sane, be sure to develop awesome stuff.

Oh and I didn't mention the situation on mobile, where we have lots of different browsers with unique feature sets. I suppose I should mention the value of feature detection now. That's certainly key to making great experiences that can adapt to all the various browsers viewing your craftsmanship. Writing your own feature detects is tough, so I recommend you hop over to Modernizr's site and create a small custom build of just the few tests you need.

*Chris: How about some advice for the people. What do front end developers need to be doing these days to be "doing it right"?

Paul: A lot! amirite? First, you're deciding: am I making a webapp or a site? Is it for mobile or desktop? Responsive with top-down media queries or mobile-first responsive with bubble-up styles? Oh wait, I hear content-first was best. It's tricky to keep track of all this so I'm a big proponent of not reinventing all wheels each project.

Ideally you use HTML5 Boilerplate to kick off new projects, use Bootstrap or your own custom equivalent. Making good use of preprocessors like SASS is also a huge timesaver and using Compass means you can let that manage all the prefix knowledge for you. Also hopefully you are experimenting with new features to stay ahead of the curve. There's a lot of exciting stuff already in browsers that nobody has explored yet. Like you do, Chris, I'm happy to see people write down what they have discovered; helps out everyone and yourself. :)

*Chris: Thanks Paul!
Five Questions with Paul Irish is a post from CSS-Tricks

Results of Group Design Project on Rating Three Candy Bars

Chris Coyier — Wed, 26 Oct 2011 03:41:47 +0000

Last week I proposed a little design challenge: design a small part of an interface which allowed a user to rate three candy bars in order of how much they liked them. Quite a few folks took a stab at it. I'd like to round up what I feel were the best entries for discussion and then pick the "winners" (and remember, this is just me picking my favorites, not necessarily what would absolutely work the best in every app in the world).

Remember, in Tinkerbin, you often have to click the green "Run" button for most of these to work properly.

The very first entry by Jesse Shawl was just three dropdown menus:

View

I'm glad Jesse posted this because it highlights an important aspect of this challenge. The design is very simple, which is good (although I'd work on the spacing to make it more clear what goes with what). But it allows a user to make a mistake. The user can rate each candy bar, but that user can choose the same rating for each candy bar, which doesn't solve the problem of rating them in order.

Also utilizing dropdown menus is an entry by Moritz:

View

At first only one dropdown is shown, with all three choices. After you choose from the original dropdown, a second dropdown is shown with only the remaining two candy bar choices, and lastly a third dropdown with the final choice. I'd critique that the last choice isn't needed, but it does complete the flow.

An entry by David Booth is clever in that it uses the candy bar itself as a bar chart to reflect its current rating.

View

Unfortunately it falls victim to the same problem as Jesse's solution in that a user could rate two or more candy bars the same rating. It also doesn't utilize any known web affordances. Yes, it says "Click a candy bar", but that's a rather unusual request that isn't intuitive. Also a bit strange how it requires 5 clicks to go through a cycle when there are only 3 possible ratings.

Nate was the first to try out a drag-and-drop interface.

View

This solves the problem of each candy bar having a unique rating. In other words, it's not possible to have the candy bars in an invalid rating order state.

There are similar drag and drop solutions Martin Blackburn, Josh, stursby, Kyle Sevenoaks, Remco Hendriksen, Óscar Mario Víquez, Michael Crawford, and Kirby. Cooper also did a drag and drop technique, which has the neat feature that a notification message pops up quickly summarizing the change.

Another by Todd Wolfson who also attempted a variation: select-and-drop. Zach Smith created "wells" for which the candy bar icons can be dropped, with an "X" option to move them back out in case you make a mistake. Daniel again with the wells.

A word on drag and drop

Drag and drop has been around in computer operating systems for a long time. Users know how to do it and feel comfortable doing it. But drag and drop is far newer on the web. It's not all that common and (I don't have any data, but I would wager) that many users don't even think to try it on the web.

But darn if drag and drop isn't useful! Particular in cases like this. I'll put forth that if we choose to implement it, we should do all we can to tell the user what we expect of them. Some options:

The mouse cursor should be set to "move":

.move {
//AN_Xml:   cursor: move;
//AN_Xml:}

Text explaining what to do (e.g. "to change the order of the candy bar ratings, drag the one you wish to move to the number you wish it to be.").
The design should scream "drag and drop". Perhaps a little handle by which to drag them and a dotted-line "well" for which to drop them.
Have an alternative interaction besides drag and drop that can accomplish the same goal (if more cumbersome). This is particularly important for mobile, since there is no mouse. It's possible for a tap-drag-tap thing to work, but it's certainly not an established pattern.

In Wufoo, in the Form Builder, we offer drag and drop to add new fields to your form and rearrange the current ones. We explain it via text and show the correct cursor. But everything that can be done via drag and drop can be done just through clicking as well. It's more cumbersome in that all new fields go to the bottom and you need to click over and over to position how you want it, but it's possible. Drag and drop just makes things easier if a user bothers to try and learn it.

A similar UI to drag-and-drop, but allowing for clicking instead was done by Rafał Krupiński.

View

Rolling over the second or third candy bar reveals an arrow, which when clicked, moves that candy bar up one spot. Very simple. As a slight improvement I might suggest making the "move up" arrows even more obvious (so as not to require explanatory text) and visible at all times. (Alternative with text). Offering only an up arrow is also slightly weird in that it might not jive with a user's own mental model. What if they think to themselves "Snickers, ewww!" and want to move it down. They can only do that by moving something else up, the opposite of what they are currently thinking.

prabhu.webdev tried out a voting system where there are up and down arrows for each candy bar which affect a numeric value.

View

It's nice to see a totally different approach to the UI, but unfortunately this again doesn't solve the problem that two candies could be rated the same. If this idea was extended to having a group decide which candy bar was best, this might be just the ticket.

Similar "voting" concept by Tauseef Jamadar.

Richard Bland tackled a number of the problems with drag and drop with this "winners block" idea:

View

This UI makes the concept of drag and drop a bit more intuitive since most users likely understand the concept of a winners block and that each contestant should occupy one tier. Unfortunately dragging each candy bar onto a block isn't overly satisfying (it's hard to tell if you "did it right") and there is nothing preventing multiple candy bars from sitting on the same block, or deactivating unused blocks.

Richard updated it to utilize some "drop zones" and snapping behavior, which conceptually is a good idea but came out a bit buggy.

Raphael Lopes utilized drag and drop but in a unique way: by making the candy bars into vertical sliders.

View

This felt a little more natural to me than some of the other drag and drop solutions, but I wish there were more affordances going on, like the browser default UI of a slider, a move cursor, or some helpful text.

This one by Thomas Dybdahl Ahle I quite enjoyed because he brought some mathematics into it. This one requires the least number of actions to complete the task (2) by just offering two comparisons.

View

I wish that, visually, it didn't look like it was going to be a three-step process. I think it would be nice if it literally told you it was going to be a two-step process. It would only show you the first comparison, then reveal the second comparison on completion of the first.

Similar click-to-vote idea by Zach Malone. More by Pablo Botta, William Blanchette, and IJas require three clicks to "finish".

Damon combined the idea of voting with a bar graph:

View

Neat idea, but it is victim to the early problems we discussed like being able to vote the same candy bar the same rating and is a bit too complex, allowing 1-10 values rather than just rating in order.

Baylor Rae' implemented something very similar to the "Radio Buttons with Two Way Exclusivity" idea:

View

I quite like the use of simple form elements. My biggest critique is that the two-way exclusivity feels like kind of a bummer as a single click can sometimes deactivate multiple previous selections if there are conflicts. An improvement would be to use value-swapping, which feels nicer as it deals with conflicts by swapping instead of deactivating.

Baylor also updated this technique. It falls back on the radio button grid, but when JavaScript is enabled, goes with the two-click ordering system.

Another version of the click-to-rank system is from Remi:

View

Two clicks to rank all three. It does rely on a hover effect (important to remember how mobile doesn't really have hover). But that could probably be cleared up with some text.

This technique from Peeter combines stuff from a lot of the others. It looks like the radio button grid at a glance, but it's more like a click-to-vote in practice, and the result looks like the bar graphs.

View

Peeter wasn't the only one to implement UI that forced people to choose extremes like "Awful!" and "Delicious!". I was more interested in simply ranking them rather than applying labels. With extreme labels like these, it might detract from a user filling it out at all, if they disagree with them. For instance, someone might really love all three but one slightly more than the others and one slightly less (LIKE ME).

This technique from Caio Dettmar used actual sliders:

View

Sliders are pretty established patterns but this has the same issue as many earlier in that you can slide two candy bars to the same value. Also why the editable input? The slider doesn't seem to change when you change that value. Typically, a slider is used when the actual numeric value isn't important (like it isn't in this case).

The most imaginative and "out there" idea was by David Booth who created the "Candy Bar Sniper":

View

It's like the Winner Stand idea, but balloons float overhead carrying the candy bars. You click the balloon (popping it) and the candy bar falls into the trophy, rating it. If the goal is speed and practicality, of course this it out, but whatever, this is super clever and fun! Using an idea like this may just be a huge hit with users encouraging engagement and sharing. For instance, when creating a new Wufoo account, right after you are done with the forms and before you see the app screens for the first time you are taken to a screen that says "Assembling Wufoo Powers" where a series of abstract icons flash up in a row. This isn't because the site needs time to create your account (it's already done by that point), it's because it is super fun and makes the experience of creating an account more special.

I wasn't too concerned about the technology behind the design, but Richard came up with a clever way to rearrange the candy bars in order of preference using only CSS. The especially cool part is that it uses radio button inputs, so theoretically this could submit the data like a real form.

View

A similar mostly-CSS technique was done by mike, with just a touch of jQuery to prevent duplicates.

In an extreme attempt to reduce the number of clicks to solve the problem, this UI by David Herrera only requires one click:

View

Clearly not scalable (as David said himself) but it's interesting to see the extremes.

Closing Thoughts

It was amazing to see all the ideas roll in. There was lots of interesting submissions. Sorry if anyone was missed here. A few I just couldn't get to work or were just too far off-the-mark. If you are itching to view more, read through the whole comment thread.

This accomplished just what I had hoped: to highlight how many different ways even the simplest user interface mechanism can be done. Next time you need to design a bit of user interaction, think of this and how complex even the seemingly simplest things can be.

One surprise for me is that no single practical solution stood out as "clearly the best" in my mind. Perhaps that's to be expected since we had so little context to work with.

"Winners"

Remember, not an indication of the best possible UI for any app, but these three I thought did an exceptional job.

Baylor Rae' - Simple click-to-rank with non-JavaScript fallback.
David Booth - Candy Bar Sniper
Richard - Mostly-CSS click-to-rearrange that was a real

Congrats ya'll - let's do this again sometime.

Results of Group Design Project on Rating Three Candy Bars is a post from CSS-Tricks

How CSS Animations Work on Sales Page for iPhone 4S

Chris Coyier — Tue, 25 Oct 2011 13:46:45 +0000

Impressed by the CSS animations on the Apple 4S sales page? I am. John B. Hall makes it clear by showing a miniaturized version where we can see all the off-screen elements.

Direct Link to Article — Permalink

How CSS Animations Work on Sales Page for iPhone 4S is a post from CSS-Tricks

HTML5 for Web Designers Website

Chris Coyier — Mon, 24 Oct 2011 21:59:11 +0000

The content of HTML5 for Web Designers, the first A Book Apart book by Jeremy Keith, is online. Under the hood, the title bar at the top of the page is actually the <title> element, unhidden and styled up.

Direct Link to Article — Permalink

HTML5 for Web Designers Website is a post from CSS-Tricks

What We Don’t Know

Chris Coyier — Sun, 23 Oct 2011 22:13:39 +0000

We don't know which browser, which version of that browser, or what kind of computer a user visiting our website is using.

That's why we have web standards we follow which give us the ability to code one website that can work everywhere. We use normalized templates (e.g. HTML5 Boilerplate) to give our projects a consistent and healthy starting point. We use JavaScript libraries (e.g. jQuery) to make things easier for us an alleviate cross browser issues.

We don't know the capabilities of the browser the user is visiting our website with.

So we feature test and polyfill where we can. That way we can build the fantastic experience we want to and deliver perfectly acceptable experiences to all browsers.

We don't know what the size of browser window is of a user viewing our website.

So we should design our sites to be fluid and utilize media queries to optimize the site for any screen size (responsive web design).

We don't know what the internet connection speed is of a user viewing our website.

So we try and load as few resources as possible. We make those resources as small and compressed as we can. We serve those resources through servers optimized just for that and geographically closer to our users (e.g. NetDNA). That way our website loads as fast as possible.

We don't know the mindset of a user viewing our website.

So we conduct user research (e.g. Silverback) and try to find out. We try and accommodate different ones. We use our experience (and sometimes gut instinct as users ourselves) to make the right decisions. We design for humans.

We don't know the physical location of a user viewing our website.

So if our site needs it or could be better by knowing it, we can ask for it. Either literally or through HTML5.

We don't know what languages a visitor to our site understands.

So if we have the resources to do it, we use translation services (e.g. Smartling) to offer our website in a user's native tongue. If we are trying to be as professional as we can, we also probably try and be sensitive to culture differences worldwide.

We don't know how "computer savvy" a user is visiting our site.

So we try and make it very obvious how to use our site and not make too many assumptions. We use common design patterns to accommodate "affordances". We sweat the details in our design, copy, and overall "user experience".

We don't know what disabilities a user visiting our site might have.

So we try and craft our sites with accessibility in mind.

We know very little about a visitor to our website. We actually know less and less every day, as the demographics of internet users widens (younger and older, no longer a nerd thing, more areas geographically, etc.) So as we march forward toward the next 6 billion people using the web, let's embrace the unknown by accommodating for it.

What We Don’t Know is a post from CSS-Tricks

Abbr’s for Web Nerd Acronyms

Chris Coyier — Wed, 19 Oct 2011 23:51:23 +0000

I'm really lazy about using tags for acronyms. Most people who read a techy blog like this probably understand them, but surely there are some visitors who don't where a simple tooltip explanation would be beneficial. Maybe with this easy copy-and-paste resource to reference I'll actually start doing it. This is an education blog, after all.

CRM
//AN_Xml:CMS
//AN_Xml:SQL
//AN_Xml:ISO
//AN_Xml:PHP
//AN_Xml:HTML
//AN_Xml:XHTML
//AN_Xml:CSS
//AN_Xml:JS
//AN_Xml:ECMAScript
//AN_Xml:ISP
//AN_Xml:IP
//AN_Xml:HTTP
//AN_Xml:RSS
//AN_Xml:IRC
//AN_Xml:FTP
//AN_Xml:AJAX
//AN_Xml:DNS
//AN_Xml:DOM
//AN_Xml:OOP
//AN_Xml:DRY
//AN_Xml:SSL
//AN_Xml:RoR
//AN_Xml:KISS
//AN_Xml:LAMP
//AN_Xml:XSS
//AN_Xml:SEO
//AN_Xml:JPG
//AN_Xml:GIF
//AN_Xml:PNG
//AN_Xml:PSD
//AN_Xml:AI
//AN_Xml:SaaS
//AN_Xml:SASS
//AN_Xml:RGB
//AN_Xml:HSL
//AN_Xml:UI
//AN_Xml:UX
//AN_Xml:JSP
//AN_Xml:ASP
//AN_Xml:WYSIWYG

Maybe there could be some WordPress plugin that could REGEX post content and automatically do it?

Got some ones I should add to the list? I'll probably keep the list above specifically web development acronyms not general computer/internet ones.

Abbr’s for Web Nerd Acronyms is a post from CSS-Tricks

Group Design Project: Rate Three Candy Bars In Order

Chris Coyier — Mon, 17 Oct 2011 22:26:25 +0000

Last time we did a group design project, we did a list with functions and we got lots of interesting ideas. Then the other day I linked to a video of Ryan Singer, a tiny part of which inspired the idea of radio buttons with 2-way exclusivity. Then reader Erik Edhagen suggested I do more of those group design project things... so here we are!

Your Mission

Create an interface where a user is able to rate three candy bars (a Snickers, a Twix, and a Butterfinger) in the order of how much they like them (1st, 2nd, 3rd).

You don't need to save the data. You don't need to build an entire web page around it. Just the part where you do the rating.

Create your demo using Tinkerbin and post the link (and any notes/comments you might have) in the comments below. If you want to use a JS library in Tinkerbin you gotta link it up in the HTML section.

There are no other rules. Get creative.

Prize

I'll pick three users who I think did a particularly good job and send them a CSS-Tricks T-Shirt.

Let's say about a week. I'll close the comments on this post on Tuesday, October 25th and pick the winners. Follow conversation will happen in some kind of roundup post.

Why?

Just to be clear, I have no particular need for this. I'm not trying to get "free work" out of you.

I think this is just a fun and useful exercise for practicing design. You learn while thinking through how you think it's best to approach this. You learn while creating it. You learn while seeing other people's approaches. You learn dissecting and discussing all the approaches.

Group Design Project: Rate Three Candy Bars In Order is a post from CSS-Tricks

CSS Shaders

Chris Coyier — Fri, 14 Oct 2011 16:32:10 +0000

A bunch of crazy awesome affects you can apply via CSS through the filter property: blur, drop-shadow, gamma, grayscale, hue-rotate, invert, opacity, saturate, sepia, and sharpen. Adobe has been doing some great stuff with CSS lately. Their last amazing demo isn't just a demo anymore, it will be implemented in IE 10. Let's hope these make it into the spec and implemented as well.

Direct Link to Article — Permalink

CSS Shaders is a post from CSS-Tricks

Dart

Chris Coyier — Fri, 14 Oct 2011 16:02:03 +0000

It's a new language the runs in the browser and servers. A lot of it is over my head, but I always celebrate new thinking especially when it has a bunch of smart people behind it. The obvious point is that, if it's a direct competitor to JavaScript, that JavaScript has far more browser support. I'm sure that fact isn't lost on the team.

Wasn't this the last Google-originated language? Did that go anywhere?

Direct Link to Article — Permalink

Dart is a post from CSS-Tricks

New Poll: Ideal Page Weight

Chris Coyier — Thu, 13 Oct 2011 17:01:46 +0000

Since that last post was kind of a bust (in a good way!) - let's kick off another one right away. We'll keep it along the same lines: page weight, this time regarding the page as a whole.

Way back in the day Google used to only index 100k of a page (although I think that's the HTML only) but that's not true anymore. 200k for the entire page (including all resources: css, images, js, etc) used to be a common goal. I'd say very few web pages these day come in at under 200k.

The CSS-Tricks homepage right now weighing in at 607k

So the new poll is:

What do you think is reasonable page size to try and stay under for a modern web design?

Poll is in the sidebar.

New Poll: Ideal Page Weight is a post from CSS-Tricks

CSS-Tricks

Five Questions with Paul Irish

*Chris: Would we be better off or worse off if Internet Explorer decided they were going to use the WebKit rendering engine? Long term and short term.

*Chris: How does the development of the developer tools in WebKit work? Are they actively improved by the Chrome team, then contributed back to the WebKit project, and in turn used by Safari? Or is there collaboration there by multiple teams?

*Chris: The picture that this paints is pretty grim. Do you really think it will get that bad? If IE can get on the auto-updating browser bandwagon, this problem should melt away pretty quicky right?

*Chris: How about some advice for the people. What do front end developers need to be doing these days to be "doing it right"?

*Chris: Thanks Paul!Five Questions with Paul Irish is a post from CSS-Tricks

Results of Group Design Project on Rating Three Candy Bars

A word on drag and drop

Closing Thoughts

"Winners"

How CSS Animations Work on Sales Page for iPhone 4S

HTML5 for Web Designers Website

What We Don’t Know

We don't know which browser, which version of that browser, or what kind of computer a user visiting our website is using.

We don't know the capabilities of the browser the user is visiting our website with.

We don't know what the size of browser window is of a user viewing our website.

We don't know what the internet connection speed is of a user viewing our website.

We don't know the mindset of a user viewing our website.

We don't know the physical location of a user viewing our website.

We don't know what languages a visitor to our site understands.

We don't know how "computer savvy" a user is visiting our site.

We don't know what disabilities a user visiting our site might have.

Abbr’s for Web Nerd Acronyms

Group Design Project: Rate Three Candy Bars In Order

Your Mission

Prize

Why?

CSS Shaders

Dart

New Poll: Ideal Page Weight

*Chris: Thanks Paul!
Five Questions with Paul Irish is a post from CSS-Tricks