Hybrids. Image: Screenshot/Webmonkey.

A big part of developing for today’s myriad screens is knowing when to adjust the interface, based not just on screen size, but other details like input device. Fingers are far less precise than a mouse, which means bigger buttons, form fields and other input areas.

But with hybrid devices like touch screen Windows 8 laptops or dockable Android tablets with keyboards, how do you know whether the user is browsing with a mouse or a finger?

Over on the Mozilla Hacks blog Patrick Lauke tackles that question in an article on detecting touch-capable devices. Lauke covers the relatively simple case of touch-only, like iOS devices, before diving into the far more complex problem of hybrid devices.

Lauke’s answer? If developing for the web hasn’t already taught you this lesson, perhaps hybrid devices will — learn to live with uncertainty and accept that you can’t control everything.

What’s the solution to this new conundrum of touch-capable devices that may also have other input methods? While some developers have started to look at complementing a touch feature detection with additional user agent sniffing, I believe that the answer – as in so many other cases in web development – is to accept that we can’t fully detect or control how our users will interact with our web sites and applications, and to be input-agnostic. Instead of making assumptions, our code should cater for all eventualities.

While learning to live with uncertainty and providing interfaces that work with any input sounds nice in theory, developers are bound to want something a bit more concrete. There’s some hope on the horizon. Microsoft has proposed the Pointer Events spec (and created a build of Webkit that supports it). And the CSS Media Queries Level 4 spec will offer a pointer query to see what sort of input device is being used (mouse, finger, stylus etc).

Unfortunately, neither Pointer Events nor Media Queries Level 4 are supported in today’s browsers. Eventually there probably will be some way to easily detect and know for certain which input device is being used, but for the time being you’re going to have to live with some level of uncertainty. Be sure to read through Lauke’s post for more details and some sample code.

Image: Screenshot/Webmonkey

Nielson’s research reveals that while more people reach for the search box to find what they’re after on a site, few of them “know how to use it.” The normally more prosaic Nielson writes:

It would certainly be nice if schools would get better at teaching kids how to search. But I don’t hold out much hope, because most people have the literary skills of an anteater (I was going to say, “a chimpanzee,” but these animals are too smart for my metaphor). Having new and varied vocabulary words spring from their foreheads wasn’t a survival skill for ice age hunters, so most people today can’t think up good queries without help.

Presumably Nielsen means literacy skills, not literary skills. That’s a pretty harsh critique, but if you’ve ever watched a less web-savvy friend or family member search for something you might be able to relate.

So how do you design your site’s search tool to help these “mediocre searchers” as Nielsen calls them?

Nielsen is critical of instant search suggestions, currently a popular way to help people using search tools. He claims that, while sometimes helpful, auto-complete tools can also be limiting because “users often view the drop-down as a mini-SERP and assume that it lists everything the site carries.”

The better way to do search according to Nielsen is to simply return product categories. The example in his report cites Costco, which, when searching for “television” will return all of its TV product categories rather than actual individual televisions. The product category links help users refine their choice and get to the televisions they actually want without having to wade through as many individual results.

It’s important to note that Nielsen is only advocating this sort of redirecting when the search term is “unambiguous and exactly matches the category.” As Nielsen notes, “until people begin to grasp the complexities of search and develop skills accordingly, businesses that take such extra steps to help users find what they need will improve customer success — and the bottom line.”

Stop feeding your website donuts. Image: D. Sharon Pruitt/Flickr.

That’s bad for pretty much everyone, but doubly so for mobile users with constrained bandwidth.

Fortunately for mobile users, the network increasingly seems to see large page sizes as damage to route around.

Services like Instapaper, Pocket or Safari’s Reader have long offered an easy way to strip out extraneous content. Now mobile web browsers are increasingly taking it upon themselves to speed up the bloated web.

The recently unveiled WebKit-based Opera Mobile borrows Opera Mini’s proxy-based Turbo Mode, or “Off Road” mode as it’s known now. Once only deemed necessary for feature phones (Opera Mini’s primary market) proxy-based browsing will soon be available in all Opera browsers.

Google’s Chrome for Android browser is getting ready to follow suit.

The beta channel release of Chrome for Android recently introduced an experimental data compression feature which Google says will “yield substantial bandwidth savings.” Chrome’s compression is nowhere near the level of Opera’s, but it does roughly the same thing — puts a proxy server between the user and the bloated site in question and then applies various speed improvements like using the SPDY protocol and compressing images with WebP.

To turn on the compression head to chrome:flags and look for the “enable experimental data compression” option.

Here’s Google’s description of the various optimizations:

For an average web page, over 60% of the transferred bytes are images. The proxy optimizes and transcodes all images to the WebP format, which requires fewer bytes than other popular formats, such as JPEG and PNG. The proxy also performs intelligent compression and minification of HTML, JavaScript and CSS resources, which removes unnecessary whitespace, comments, and other metadata which are not essential to render the page. These optimizations, combined with mandatory gzip compression for all resources, can result in substantial bandwidth savings.

In other words, Google and Opera are doing what web developers ought to be doing but aren’t. Just like developers should have been making reader-friendly pages, but weren’t, so “reader” modes were born.

It works too. In the video embedded below Google’s Pete Le Page shows how Chrome’s new proxy options take a page from The Verge and reduce it from a husky 1.9MB to a still fat, but somewhat better 1.2MB.

Want to make sure the internet doesn’t see your site as damage it needs to route around? Check out developer Brad Frost’s article Prioritizing Performance in Responsive Design, which has a ton of great advice and links, including what I think is the most important thing developers can do: Treat Performance As Design. In other words, if your site isn’t svelte and fast, it’s not well designed no matter how pretty it might look.

[Note: It is not ironic to post about web page bloat on a page that is, arguably, pretty bloated.]

Foundation 4. Image: Screenshot/Webmonkey.

ZURB has released a major new version of its popular Foundation framework, a web development toolkit for quickly building responsive websites. The new Foundation v4 is a ground-up re-write that sees ZURB taking a mobile-first approach.

Like its erstwhile competitor Bootstrap, Foundation offers a set of HTML and CSS building blocks you can use to quickly develop basic site structure and design — layouts, typography, forms and other common design elements are all available.

There are three ways you can try out Foundation 4. You can download the straight compressed CSS and use that as a starting point for your own customizations. Alternately you can customize your build of Foundation, including only the elements you need; or you can install the SASS version of Foundation and customize it within your SASS code.

If you’re upgrading from Foundation 3 be sure to read through ZURB’s migration guide as the syntax for the grid and other elements has changed.

The real power of Foundation 4 doesn’t really come into play unless you go with the SASS option. Thanks to SASS’s “mixins” concept you can now use the grid tools in Foundation 4 without littering your HTML with the various (purely presentational) grid class names. Using Foundation 4 within your SASS project also makes it dead simple to use only the components you need, for example, you can include the grid mixins, but skip the typography if it’s not to your liking.

Be aware that the new mobile-first approach in Foundation 4 means browsers which don’t support media queries will only get very basic styling for the grid and other UI elements. Yes, that pretty much only affects IE 8. But, if your project needs more robust support for IE 8, there is a modified version of Foundation 4 with support for IE 8 (alternately, you could stick with Foundation 3).

It’s also worth noting that, because Foundation 4 is such a departure from the previous version, ZURB plans to continue supporting Foundation 3 for some time.

If you’ve got questions about Foundation 4, head on over to the official site and check out the documentation. You can also explore the code on GitHub — Foundation is one of the top 20 most-starred projects on the site.

A handful of the many canvases your site will adorn. Photo: Ariel Zambelich/Wired.com

In the bad old days of just four years ago it was pretty common for mobile users to get shunted off to some half-baked, feature-deprived “mobile” version of the website they were trying to visit. This misguided practice was common (and annoying) enough that even today Chrome for Android and other mobile web browsers ship with a feature that allows users to “request desktop site.”

To make that feature work Chrome for Android changes its user agent string. Any site that uses user agent strings to redirect mobile users will no longer because to redirect them and the desktop version is displayed.

Responsive websites don’t rely on user agent strings though. Instead they adapt to screen size based on CSS media queries so even if a user has the option for desktop sites checked in Chrome they still won’t get the “desktop” site (of course with responsive sites there really is no desktop site, just a desktop layout).

Provided your responsive designs are good, this isn’t a problem (and if they aren’t then you have bigger problems). However, Opera web standards evangelist Bruce Lawson raises an interesting edge case: what about users that have never seen the mobile layout and are disoriented when they do? If you were expecting, say, the desktop layout of the BostonGlobe.com and instead saw the mobile layout for the first time you might be understandably confused. Here’s what Lawson has to say:

My reason for wondering [about turning off responsive design] is watching my dad use his Xmas Android phone and seeing his puzzlement that some sites look completely different on that device. Non-RWD sites loaded the layout he was familiar with — the desktop layout — which meant he could verify he was on the right site, he knew where in the layout the content he wanted was, and then scroll and zoom to it. When a site looked radically different, he’d check the URL bar to ensure that he’d typed in the right address. In short, he found RWD to be confusing and it meant he didn’t trust the site – no way would he buy anything from these sites.

The first thing to note is that this isn’t a problem unique to responsive sites. The same thing would crop up with a separate mobile experience. The difference is the inability to opt out of the responsive layout. An edge case? Sure, but Lawson isn’t alone in wondering about turning off responsive designs. CSS guru Chris Coyier tackled that very question last year, writing:

Why don’t we see opt-out responsive design? My guess is two-fold:

1. It’s a bit technically challenging to implement and there aren’t a lot of precedents.
2. It’s admitting you didn’t do a very good job on the responsive design.

The latter likely being the bigger factor. Like: why are we creating this responsive design at all if we aren’t sure it’s a better experience?

I would agree with both points, but clearly there are at least a few edge cases where offering an option to turn off responsive design might be a good idea. Of course it may not be worth worrying about the edge case of unfamiliar visitors — that’s the sort of decision you can only really make by looking at your own visitors and doing your own testing.

If you actually want to try it, Coyier has some ideas on how to go about creating an option to opt out of a responsive design.

The UserLand Software logo. Image: Dave Winer

What’s in a word? A lot according to Jack Dorsey, the CEO of mobile-payments company Square. Dorsey, who also help create Twitter, believes that the technology industry needs to reconsider the word user and find something less “derogatory” to refer to people that use its products and services.

As he points out, the word user in the context of software has mainly negative origins, often being used to refer to “a person who wasn’t technical or creative, someone who just used resources.”

That’s hardly how most of see ourselves when we log in to Twitter, Gmail or Facebook.

“It’s time for our industry and discipline to reconsider the word ‘user,’” writes Dorsey on his Tumblr blog. “We speak about ‘user-centric design,’ ‘user benefit,’ ‘user experience,’ ‘active users,’ and even ‘usernames’…. While the intent is to consider people first, the result is a massive abstraction away from real problems people feel on a daily basis.”

It’s easy to sympathize with Dorsey’s argument; after all, who wants to be referred to by a word otherwise mainly associated with drug use? Indeed I try to keep the word user out of Webmonkey articles for just that reason, but sometimes writing around user is more awkward than just, er, using it. That combined with the fact that the best alternative Dorsey can come up with the is the word customer, which is better but can still be equally dehumanizing in some contexts.

As with most debates about word choice and language it comes down to the intent the word is being used to convey. As RSS founder and longtime software developer Dave Winer points out:

Every decade or so this question comes up. Why do we use that awful U-word to describe our users? It’s hard to even formulate the question without sounding stupid. And every time the discussion comes up, it lasts a while before everyone gives up because there really aren’t any better words, and this is the word everyone uses so what are you going to do.

What Dorsey is doing is eliminating the word from Square’s vocabulary, telling employees that customer will replace user. He goes on to add that “we have two types of customers: sellers and buyers. So when we need to be more specific, we’ll use one of those two words.”

Dorsey also says he’ll pay out $140 if he ever uses the word again.

Winer believes in a different approach: embracing the word user. Winer even went so far as to name his second company UserLand Software.

In the end what matters is not so much what you call your users, but how you treat them. “The answer” writes Winer, “is to love those users so much that they don’t mind being called users. That’s an art a lot of tech companies have yet to master.”

Quick, easy contrast ratios. Image: Screenshot/Webmonkey.

Making websites accessible to users with disabilities — things like poor vision, blindness, limited dexterity — has been central to the mission of the web’s overseers since the dawn of the browser.

Following accessibility guidelines actually helps just about everyone, especially when it comes to making your site readable. And one of the cornerstones of accessibility is making sure your background and text colors have proper contrast ratio. But how do you know what’s a proper contrast ratio? For that turn to WCAG 2.0, a set of accessibility guidelines that most government and many private sector websites adhere to.

Unfortunately, while the W3C has plenty of guidelines for building the web, it’s not in the business of creating tools to go with them, which means bringing the guidelines into the real world can sometimes be a hassle. That’s why developer Lea Verou built this awesome contrast ratio tool. Verou works for the W3C (though the tool is not an official W3C project) and needed a way to ensure that her color choices passed WCAG muster. That’s exactly what the contrast ratio tool does: give it any form of CSS color — hex, rgb(), rgba(), hsla(), etc — and it will automatically calculate the contrast ratio and let you know which level of the WCAG guidelines your contrast meets.

Verou’s contrast calculator even accepts semi-transparent colors for sites using overlays. To make the semi-transparent colors work Verou had to write her own algorithm. For semi-transparent backgrounds, the WCAG contrast ratio is presented with an error margin, since the actual contrast can vary depending on what’s under your semi-transparent overlay.

The contrast ratio tool supports all modern browsers and has “basic support for IE9.” The code is available on GitHub.

Also worth noting is Verou’s blog post on accessibility and contrast ratios. Like many of us, Verou “used to think that WCAG-mandated contrast ratios were too restrictive and basically tried to force you to use black and white.” The truth is, as Verou writes, “in practice, I found that in most cases they are very reasonable: When a color combination doesn’t pass WCAG, it usually is hard to read.”

The high-res future is coming fast. Photo: Ariel Zambelich/Wired.com

The rise of high-resolution displays means that web developers need resolution-independent graphics. The good-old PNG icons we’ve been relying on just aren’t going to cut it for much longer.

It’s true that a slightly blurry icon or logo on the iPad probably isn’t going to ruin a site by driving visitors away in droves, but it is a problem, and one that will only become more obvious as higher-resolution screens proliferate.

At the moment there are essentially two ways to swap out your PNG icons for something a bit crisper: icon-fonts or SVG graphics. Naturally, neither is perfect — the last time something worked perfectly on the web Tim Berners-Lee and friends were the web’s only users — so it’s worth looking into the advantages and drawbacks of each.

That’s exactly what UIX designer Simon Uray recently did, breaking down the good and the bad of both icon fonts and SVG images. Give Uray’s post a read for the finer details on both, but here’s the short story: icon fonts are probably your best bet at the moment, though you’ll have to live with the fact that some icons are a tiny bit blurry on traditional displays.

Since at the moment the vast majority of screens on the web are not high resolution, adopting icon fonts over the PNGs you’re using now might be a case of premature optimization.

As Uray writes, “sorry, if you’re looking for a silver bullet, I’m afraid it doesn’t exist.” To that we might add “yet.” But SVG support in browsers (one of the chief problems with SVG is that it isn’t as widely supported as icon fonts) continues to improve. There’s also always the option to use them all. “Maybe best,” writes Uray, “is to use PNG served in many different sizes for your high fidelity, multi-color logo and other graphics… SVG icons for your navigation that stays the same size, but also look sharp on Retina displays [and] Responsive inline SVG for bars and charts and an icon font for all your different button sizes.” The best of all worlds.

For more on icon fonts, be sure to check out Chris Coyers interactive write up on how to use icon fonts.

The Eephus League Magazine: showing publishing pros how it's done.

Baseball season is already well under way, but it’s never too late for another site about America’s favorite pastime — especially when it’s as awesome as the beautiful Eephus League Magazine.

Even if you have no idea what the name means — and fear not, even some baseball fans aren’t familiar with the Eephus pitch since it isn’t throw much (though current Red Sox reliever Vicente Padilla has something like an Eephus pitch) — the site is well worth a visit for its gorgeous layout and design.

The Eephus League Magazine is written and produced by web designer Bethany Heck, but if the interface and navigation looks slightly familiar it’s probably because the underlying code is the work of Ian Coyle, creator of Nike’s Better World site, which we featured last year.

Since then Coyle has also released Edits Quarterly, an online magazine of photography and short films. Edits is what inspired Heck to put together The Eephus League Magazine. And it’s not hard to see why, with Edits Coyle managed to create something even the so-called pros of the magazine publishing world can’t seem to make — a digital magazine that doesn’t suck.

What makes Edits — and its offspring like Eephus — remarkable is that it manages to feel like reading a print magazine even though you’re really just scrolling down a webpage. For example, there are what you might call “pages” in Coyle’s design, but they aren’t simple skeuomorphs like you’ll find in e-readers. Instead the “pages” just serve to move you through the content and keep articles separate even as they are all together on one page. Scrolling remains vertical; there’s no awkward “page flipping” actions. The Eephus League Magazine uses Coyle’s JavaScript, so moving through it feels just like browsing Edits, but Heck has made a few adjustments to fit Eephus‘s own layout and images.

In the end the experience of both magazines is different enough to catch your eye, but not so much so that it overwhelms the content. But don’t take our word for it, head over to Eephus and be sure to check out Edits Quarterly as well.

A webpage doesn’t have to look the same in every browser. In fact, a webpage shouldn’t look the same in every browser, according to former Yahoo developer and JavaScript guru, Nicolas Zakas.

Zakas, who spent five years as the front-end tech lead for the Yahoo homepage, recently spoke at the March BayJax Meetup group about what he calls Progressive Enhancement 2.0 — offering users the best possible experience given the capabilities of their device.

Not the same experience, mind you, but the best possible experience. That means progressively enhancing sites according to the device’s (browser’s) capabilities.

Progressive enhancement is perhaps best summed up by the famous Mitch Hedburg quip, “an escalator can never break, it can only become stairs.” In other words, if you’re building websites well they never break, even if you look at them in Lynx. The site may not look the same in Lynx as it does in, say Chrome, it may not function as smoothly, but the core content is still there and can still serve as a stairway that gets people where they want to go even when the enhanced ease of the escalator is absent.

More practically, progressive enhancement means starting with the least capable devices — an older phone, Lynx running on Windows 95 — and then adding more sophisticated features based on screen size, bandwidth and so on.

Zakas also takes on the common assumption that a web “page” is analogous to the printed page. In fact Zakas argues the web is more like television, which has a similar separation of content and device. In that analogy old browsers are like black and white TVs. No one expects a black and white TV to play HD content, but everyone would be disappointed if you served black and white content to an HD TV. Hence the need for progressive enhancement.

If you’re well versed in the history of the web the beginning of the video may be a bit slow, but stick with it. Also be sure to watch the questions at the end where Zakas addresses how to progressively enhance more application-like web pages.