@media screen and (device-pixel-ratio: 1.5) and (device-width: 683px) and (orientation: landscape), screen and (device-pixel-ratio: 1.5) and (device-width: 400px) and (orientation: portrait) { /* css */ }

And that’s not even the whole thing, you still need vendor prefixes to get it to work. This brings me to my point.

This intense form of a media query is getting dangerously close to targeting a specific device, which defeats the entire point of responsive design. It’s all about setting breakpoints, but if your breakpoints get too granular, it’s no better than targeting an iPhone directly. We have starting points because you need to have starting points, something like 800px, 480px, 320px, right? Typical breakpoints for your media queries. We’re missing the mark a little with using them out of the box like that though.

Not to point blame at any boilerplates, I think they’re actually really great to get you started, but when you use them out of the box, you start to get in trouble. They’re meant to be customized. — and wow, at least change that pink highlight.

The intention of breakpoints is to identify points where your design gets a little messed up, let’s say at 600px wide your design gets too cramped. In that case your first breakpoint would be at 600px. It’s different for every design. If you follow that basic model, you don’t have to worry about what a reference pixel for a device is. If the resolution for a device is 800px and your breakpoint is at 600px, it will look at intended. Don’t worry so much, you’re already doing it right.

As some may know, I’ve been writing a JavaScript book and I’ve been studying a lot of the basic history of the Web. Since its early conception we (as a community) have been hacking things together to deal with a device market that is struggling to get its sea legs. Normally what happens is that we’ll have a period of instability followed by developers & designers scrambling to rethink what they do and hacking something together to make it 100%, then it will get standardized and all the work you did to take a project from 95% to 100% is seen as a pile of dirty hacks (anyone remember the war between JavaScript and jScript?).

Now we use something called feature detection, which is a million times better.

When you work in the browser vs. on the server there are certain things you can’t control and you need to manage bottlenecks in the process rather than forcing control over an uncontrollable situation. The devices will do what they’ll do and if you try and plan for them all you’ll:

1. Go insane
2. Go broke purchasing all the devices
3. Create so much extra code that it will be unmanageable
4. Bog down performance
5. Ruin your JavaScript
6. Get to a point where it’s more efficient to detect for a device and serve up new markup on the server (and nobody wants crap that again)

What the moral of the story? I don’t know, stop over-thinking everything. It’s great to explore new stuff, but even better when you can recognize when new stuff isn’t that much better than the old stuff.

Obviously, I highly recommend all those these books, as they’ve had a pretty large impact on me as a designer & a developer. The best part about them is that they’re all pretty easy reads, they’re not the kind of books you have to spend a week or 2 reading.

Does anyone else have books like this? Or do we all just read blogs now?

Getting your own iPhone app icon is easier than you’d think. I was recently working on a project where the client wanted to make sure that if a user added his site to their iPhone home screen, there would be a pleasing icon.

Apple used a lot of forward thinking when they implemented the apple-touch-icon. It’s treated very much the same way a favicon is treated. There are 2 ways to set your Apple icon.

• You can simply put a file called apple-touch-icon.png in your root directory
• You can put the icon where ever you’d like and link to it in your document head element

I’m one of those people who prefers to do a combination of both to make sure it gets set. I put apple-touch-icon.png in my root directory and also link to it with the following code.

Apple icon code

<link rel="apple-touch-icon" href="apple-touch-icon.png" />

That will make sure it gets set.

Icon specs

The great thing about this is that you don't need to dress up your icon to match the iPhone theme. The software will round your corners and add the nice glossy effect for you.

Like the favicon, the Apple touch icon has a size requirement. Your icon must be 45x45 pixels to properly fit. I haven't tried to do it any other way; my gut tells that it would either crop the icon or squish it down the size.

In action

This is the Apple icon for csskarma.com:

Note that the corners are not rounded and I didn't add the Apple gloss.

In bookmarking a site on the iPhone/iPod you can "Add to Home Screen". This makes the bookmark look much like and app with the shiny icon and whatnot.

Then your new Apple icon shows up on the home screen

A brilliant and easy bit of marketing for a site that anyone can jump on board with... you may want to dress yours up a bit more.

jQuery Seek Attention Plugin

The jQuery seek plugin is very cool. It goes along with the css psuedo class "target". It’ll highlight an area on the page onClick and ca bring a great pop to a page. Give this one a try, I could see this being very useful for those long FAQ lists.

Google’s android vs the iPhone

With the release of Google’s android phone, there are already comparisons to the iPhone. This video lays it out real nice and tells you what you have to look forward to with Android.

Avoiding the Pownce Effect

There seems to be more and more twitter–killer sites out there and, for the most part, they all fail. This article takes a look at why Twitter is so powerful and some things to avoid.

3 CSS classes you should all have

Let me save you some time: .left, .right and .clear. This is something most are already including, but I always think it’s helpful to see what others are doing.

I did some digging around after that and came across a short post on iPhoneAppr about how to auto-detect a browser based on the user agent (what is essentially the browser).

The HTTP User Agent

When you visit a web page, your user agent changes based on the media you’re using. So, right now, if you’re using Firefox 2 your user agent string looks something like this:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14)
Gecko/20080404 Firefox/2.0.0.14

and if you’re on an iPhone it will look something like this:

Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420.1 (KHTML, like
Gecko) Version/3.0 Mobile/4A102 Safari/419.3

As you can see, the user agent string has some key difference. The iPhone agent actually says "iPhone" in it. With this in mind we can use a neat little function built into PHP 5 called stripos to search the user agent and return some code (like code to send someone to a mobile version of a web site).

Let’s just get into it shall we? Here’s the PHP:

<?php
//setting the variables
ipod = stripos($_SERVER['HTTP_USER_AGENT'],"iPod");
$iphone = stripos($_SERVER['HTTP_USER_AGENT'],"iPhone");

//detecting device
if ($ipod == true || $iphone == true){
    echo "iPhone or iPod";
    } else {
    echo "Screen";
}
?>

Stripos is a function that takes 2 arguments. The first is what you want to search (the haystack) and the second is what you want to search for (the needle). If the needle is found in the haystack it will return "true", and if not, it will return false. An important thing to note about stripos is that it’s case insensitive[edit], so if you have some initial trouble, check your spacing and maybe try trim().

Trouble I had

In the PHP manual it says to use === when checking the value (which is for an exact match, true=true), but for some reason that didn’t work for me so I used == (match, but not exact so true=true & true=1 for boolean values). It’s usually just a spacing issue, but I’m not real sure this time. Feel free to tell me I’m wrong.

view live demo

I like this, it’s pretty easy, light, and useful if you just want an iPhone/iPod interface.

Here’s some things we can read up on in preparation of the new web.

The Web Beyond the Desktop

An article by David Shea written in April based on a presentation by him and John Allsopp at Web Directions North 2008 in Vancouver. David talks about how there is a movement beyond the desktop computer to mobile devices, Wii, PS3, and anything with web browsing capabilities. This is an important article and was my main arguement for getting a Wii in the office here… it didn’t work but my arguement was still valid.

Mobile Web Design

A book by Cameron Moll giving a great jumping-off point for anyone looking to get into mobile development and talks about the inevitable collision between web standards and the mobile web. Cameron provides a very well written introduction the the mobile web in a round 100 pages (which I love). It’s not long-winded like many books, it gets right to the point, and its not expensive… hightly recommend.

Putting 2.7 billion in context: Mobile phone users

An article by Tomi Ahonen highlighting the impact of mobile technologies in recent times. There’s a good follow up article by Tomi to this as well: When there is a mobile phone for half the planet: Understanding the biggest technology. Both these articles are pretty long, but very good and considered to be required reading for anyone diving into the mobile web.

WAI ARIA accessibility support

I first heard of WAI ARIA in an article on A List Apart called “Accessible Web 2.0 Applications with WAI-ARIA” and it seemed very interesting, but unsupported. Then in a talk by Derek Featherstone, I heard it mentioned again and it peaked my interest.WAI ARIA is a way to make all these cool Ajax apps more accessibile by describing the role of a certain area of the page (like giving your navigation a role of “navigation”). It also allows users to navigate by section of the web site rather than tabbing through all the links or using a skip menu.

Content Delivery for Mobile Devices

An article from dev.mobi on the best practices for serving up web content on a mobile device. Delivering content to mobile devices has been a very tricky subject. Developers who came into the mobile world were usually confronted with a new and unknown paradigm, where very little information could be found on how to determine devices’ capabilities and to deliver content to them (used a q tag for the first time right there).

I feel like this post was mobile-heavy, but it’s important to not forget about the basics of web standards while developing in these new buzzwords; and more basics like learning JavaScript and the XMLHttpRequest before you heavily use jQuery or Prototype. Reading Bulletproof Ajax helped me with that.

Anyway, I hope this gets some RSS feeds stirring. Thoughts? Comments? Complaints about my awful grammar?

with ease,
Tim

Anyway, I’ve been reading up on some user interface principles in the past few months and have been talking up designing for mobile devices. First, I was looking into Fitts’s Law (I’ve seen it spelled a few different ways, so I just chose one and went with it) which wasn’t meant to apply directly to the web, but is still very useful in relation to link size, deceleration, and general usability issues. Then reading up on some Mediatyping on Mezzoblue. And I started dumping all that stuff into the research section of CSSKarma, mainly so I could keep track of it, but also to try and centralize some of the happenings on the web and show some of the better resources I’ve come across, but that haven’t made it to the lab yet.

I’ve been speaking pretty frequently about mobile design/development and there’s one particular aspect of it that seems to escape a designer’s mind in almost every conversation: a finger, while far more accurate than a mouse, is around 10 times larger. Very often, you get something like this:

I have no idea who’s finger that is, got it from Google images.

This seems like common sense, but you’d be surprised how many times people have trouble hitting a small link on their mobile device because it doesn’t translate from the regular web browser well. It’s true that the iPhone/iPod touch have that cool zooming feature, but it’s still kind of a pain for browsing a site. Fitts’s Law, as part of it applies to link size (target area) is very useful where it basically says that increasing the size of a small object will improve hit accuracy, but only to a point (increasing the size of a large object will not necessarily increase accuracy).

I really recommend reading up on Fitts’s Law. It’s pretty useful, especially in a time where the future of web design is moving towards mobile devices (can the future move?).

General handheld style media: media=”handheld”

iPhone/iPod Touch style media: media=”only screen and (max-device-width: 480px)”

Just some stuff to remember while you’re designing for the mobile web

with ease,

Tim