While I don’t think it overrides the font settings on a site currently using @font-face, it’s really fun to see what FF Dagny Web would look like on Dribbble, or how Mark Boulton’s blog would shape up with FF Meta Serif Web.  Got a favorite FontFonter experiment? Let me know…

My HTML is simply a dynamic unordered list and my CSS looks like this:
Note: the Opera and universal code is future proofing & wishful thinking.
.tag_list ul {
-webkit-column-count: 4; -webkit-column-gap:20px;
-moz-column-count:4; -moz-column-gap:20px;
-o-column-count:4; -o-column-gap:20px;
column-count:4; column-gap:20px;
}

Safari / Chrome shuffles an extra item into the last column & hides my last tag.

Mobile Safari does better, showing all tags & arraying them in left-hand columns first.

Firefox performs fairly well, filling out each column from left to right.

Opera doesn’t currently offer support for column-count.

Admittedly, this property needs quite a bit more hashing out before I’d recommend implementing it on the home page of a client site.  That being said, I’m happy to continue to use this for my Tags list.  It’s lightweight, efficient and a constant reminder that the web is ever-evolving.

After picking through Safari’s CSS Reference I found -webkit-appearance, which changes the appearance of buttons & controls to resemble a native apple UI. I added this code for comment & search forms to retain the basic style I defined in my CSS: -webkit-appearance:none;

There are quite a few parameters for this property that you may want to take advantage of and/or watch out for. Also, If you simply wanted to disable inner-shadows of input fields you could just use -webkit-appearance:caret;.

Much of it doesn’t exist anymore. Gone. Vanished. All that hard work, thinking, stressing… poof. It’s a nice reminder of what’s important, and the reality of the ever-evolving web. A lot of this junk is just temporary.  – Dan Cederholm

Feel free to download any of the following resolutions:
iPad 1024 x 1024
2560 x 1600
2560 x 1400
1920 x 1080
1440 x 900

A few days after Steve Jobs announced the release of the iPad, I read that sentence in Apple’s Reference Library: Preparing Your Web Content for iPad, and started to realize the drastic implications the evolution of multi-touch would have on interaction design. Anything we design for the web that requires a hover state has an uncertain future and could be subject to serious usability issues.

The Touch-Screen Boom

If you think this is something that can be addressed later, when multi-touch “catches on”, consider this: as of June 22, 2010 Apple has sold 3 million iPads in 80 days, 1.03 million touch screen phones are sold per day, and companies like Dell and HP have been developing & releasing touch interfaces for tablets and laptops for quite a while now.

The Hover Crutch

Hover states are everywhere. I don’t think I’ve ever written a stylesheet or designed a site without putting a significant amount of thought into how they should behave. As users, we’ve been conditioned to rely on hovers states to trigger changes in link color, reveal action items, and navigate through multiple tiers of a drop-down menu. Sliding our mouse pointers across a page to reveal hidden clickable points of action has become an automatic addition to our web browsing skill-set. As designers, we’ve turned to hover states to accommodate extra content and allow visual aesthetics to trump usability. Like it or not, those days are over and the interactions we design are going to have to stand on their own two feet.

I believe that in most cases, the best solution isn’t pursuing alternatives such as multi-touch hovering technology, trying to adapt hover-dependent designs, or transforming your website into an iPad/iPhone application. Instead of adding scripts, kilobytes, and billable hours to treat symptoms, I think the focus should be on simplicity and bullet-proof user experience design. In line with Luke Wroblewski’s statement that we should start designing for the web mobile-first, I propose that we should be designing for Multi-Touch first, and moving forward, we can only afford to add hover states as enhancements only.

Try to Avoid

• Hyperlinks that aren’t 100% obvious
• Javascript tooltips that show important information or metadata
• Displaying action items on hover. Examples I’ve seen typically involve edit / delete items.
• Displaying graphics in a less-than-ideal state until hovered: all those semi-opaque or black & white screenshots and photos that only display full color when covered by a cursor
• Drop-down menus. While some of these can be revealed on click or tap, be sure the user has cues that show those options.
• Focusing too much on hover dependent CSS3. I know it’s a bit of a heartbreaker, but while these have always been seen as enhancements, we’re going to have to settle with the fact that multi-touch users won’t be seeing our fancy transitions.

How do we adapt?

More often than not, making adjustments won’t be a quick or a simple process. The more layers of interaction a site has, the more work is going to have to be done to address usability issues. I’ve noticed that a few of my favorite sites have already taken a variety of steps to provide some fixes.

Show everything.

Prioritize your content, and if you’ve been hiding things behind hover states, make room to display them. The WordPress admin posts screen is a great example of this. Normally, action items are only visible on hover, but if you login with a touch device the links are always displayed.

Utilize tap to reveal a hover state.

Depending upon the implementation, this can be risky; Amazon has done fairly well with this method for their category-based shopping navigation. The paneled list and orange arrows help to make those areas clearly tappable. Another example can be found in Basecamp’s edit and delete controls for to-do lists, milestones, and files. When you hover over one of these the action items appear. For touch-screens they’ve built a javascript popup that works fairly well once you’ve figured it out. The problem is that users get no cue that tapping the to-do text is even an option, and I can’t help but think a solution similar to WordPress would have worked better. That being said, I’d happily pay a few extra pennies per month to get a mobile version of Basecamp.

Build specifically for touch-screen devices

and take advantage of native device controls, gestures and popovers. Touch-screen apps for Twitter and Gowalla play a key role in their overall success and are probably used more than the websites themselves. I use the Netflix iPad app regularly, but in many cases it feels like a hover-dependent website dropped into an iPad viewport. Currently, if you’re browsing instant titles and want to add something to your queue by tapping, you’re looking at a 3 step series of taps instead of an instant hover reveal option with a point-and-click interface. If you’re going to build specifically for touch, you’ve got to follow through.

Wait for touch hover technology.

I’m not convinced this would do anyone any good. It may be exciting to see what Cypress has come up with, and to know that Apple has applied for a patent for a proximity sensing touch-screen, but this does worry me. I’d hate to see us revert to our old shortcuts and make user experience sacrifices just because the technology is in place. Plus, we’re going to look like a bunch of idiots who are afraid to touch our smart phones & iPads. On the bright side, Phil Dunphy would love it!

We’re going to be OK.

Ultimately, I think seeing hover states fade away will make the web a better place. There never has been any substitute for concise content, clear interaction, and simple design. If we focus on core elements that make browsing the web great, our sites will function properly no matter how people use them.

Similar to Kyle Meyer’s experiment, I noticed a significant improvement and added the property to my body CSS for this site.  Overall, type looks much tighter and successive capital letters, like “CSS”, seem more evenly spaced.  Firefox uses optimizeLegibility by default for font sizes 20px or larger and I agree with Paul Irish’s thought that Webkit should do the same.

• When the site launched, I had Typekit serving up only the regular version of FF Meta Serif Web Pro to the web, iPhone and iPad versions.  Knowing that multiple styles and weights being pulled from the same font via Typekit could crash Mobile Safari, I opted for a single font file to rule them all.
• After seeing Stephen Coles’ comment about faux italics I did a little more peeking around.  Taking into account mobile load times, the inability to apply styles through CSS in Mobile Safari and how great the real italic version of FF Meta Serif looks, I changed my plan and switched both iPhone and iPad support OFF to let the stacked Georgia render instead.  I really like this solution, and while I haven’t made up my mind on what to do about an iPhone version for this site, I’m satisfied with where it lies.
• Yesterday, Typekit announced that iPhone iOS4 includes a fix for the multiple weights/styles crashing issue.  I switched iPhone support ON in my kit editor and was glad to see that the fonts were loading perfectly.  Ultimately, I decided to switch iPhone support back OFF and serve Georgia instead of FF Meta Serif.  In this case, I think the speed for Wi-Fi-less users is essential.  However, when iPad gets the updated iOS4 I’ll revisit my game-plan and consider enabling in that case.

I’d also like to state my support for Typekit.  They’re doing a lot of good work on multiple fronts: customer & tech support, working with foundries to make more fonts available and participating in the greater discussion on how browsers should handle them once we can serve ‘em up.  Any inquiries or questions I’ve had have been fielded quickly and I think that paying for any  service like this doesn’t just get you fonts easily, it endorses the web-font movement and supports progress.  It’s messy work, and I’m glad it’s being done.