Stop me if you’ve heard this one before.

“Responsive design is bad for performance.”

“User agent detection is bad. Don’t segment the web.”

“Hybrid apps don’t work as well as native apps.”

“CSS preprocessors shouldn’t be used because they create bloated CSS.”

If you create for the web you’ve no doubt heard at least a couple of these statements. They’re flung around with alarming frequency.

There is a fundamental problem with this line of thinking: it places the blame on the technique instead of the way the technique was implemented. Generalizing in this way discredits the validity of an approach based on poor execution, and that’s a very harmful way of thinking.

With any of the examples above, the technology itself wasn’t the problem. CSS preprocessors, PhoneGap, user agent detection, responsive design—these are tools. They are neither inherently bad or good. Their quality depends on the way you wield them.

I’m not a carpenter. If you asked me to build a table you would end up with a lopsided, three-legged abomination. That’s not because of the hammer, or the saw, or the drill—that’s because I suck at using them. Give the same equipment to a carpenter and you get something beautiful.

It’s no different with our own tools.

When someone builds a 4MB responsive site, blame the implementation. There is no reason why a responsive design can’t perform well. If you take the time to carefully build from a base experience up, only loading assets as needed and using patterns like the anchor include pattern to keep things light along the way, a responsive site can look beautiful and load quickly.

When someone builds a site and uses server-side detection to exclude some browsers or devices from the experience, blame the implementation. There’s nothing evil about user agent detection. You don’t have to use it to segment experiences. In fact, it’s quite handy as a compliment to feature detection. Consider that some devices can make phone calls, and that those devices don’t all agree on the same protocol. Start with a smart default. Use server-side detection to try to determine which protocol should be used. If a value is reported use that. You’re enhancing the experience where you can and offering something usable where you can’t. There’s nothing wrong with that.

The same goes for using hybrid applications, CSS preprocessors, text editors or any number of tools. They’re only as good as the person using them. If you get to know them, identify their strengths and weaknesses and use them when appropriate, they can be really powerful and helpful additions to your toolbox.

It’s all too easy to cling to the one or two tools we’re most comfortable with and discount the rest. Luca Passani hammered (no pun intended) this home in a recent post. He was discussing the oft-mentioned responsive web design (RWD) vs server-side detection debate and came to a very sound conclusion:

In this context, isn’t the discussion between RWD and {device-detection} a direct corollary of the old “when all you have is a hammer, every problem looks like a nail”? and of course, doesn’t this apply also the other way around, with backend developers favoring a solution to device fragmentation that leverages the tools they know best?

Experiment with techniques before you condemn them. Find out for yourself if the tool is really where the blame should be placed.

Building great experiences on the web isn’t getting any easier. We need all the tools we can get. Don’t discredit them simply because someone uses them poorly.

"It wasn’t what I was expecting, but it ended up being just what I needed."

When one of the people who attended Breaking Development in Dallas, told me that on the last day of the event, I couldn’t help but smile. Single-track events are awesome, but they’re always a little nerve-wrecking as well. How do you balance code and design, pragmatic and conceptual? Each of those discussions has to happen to move the discussion forward, but balancing can be a challenge.

Sometimes the single track thing can scare people off. If you’re a designer, do you really want to sit through a bunch of talks about code? If you’re a developer working at a large corporation, do you really care about conceptual looks at what mobile could become? On paper these discussions sometimes feel like they’re going to be something that might not apply.

It’s often said that one of the great things about single-track events is you avoid the feeling of "missing out" which often comes with multi-track events. That’s certainly true, but the real beauty of single-track events is that it forces discussions to come together. Rubbing two stones together creates a spark. Similarly, allowing these discussions to take place together generates ideas that would not have been there otherwise. It also lets you avoid the feeling of "missing out" that often comes from multi-track events.

There are conferences that give you all of one thing: lots of live coding, all design, or all high-level inspiration talks. Breaking Development tries to blend them. There are talks that arm you with information that you can take back to your company and apply tomorrow, but there are also talks that you take with you and slowly digest over the next few months, forcing you to think bigger.

This was certainly true of Dallas. We had phenomenal case study presentations from people like Tom Maslen of the BBC and Christopher Bennage of Microsoft. Lyza Danger Gardner talked a lot about the real-world challenges she’s faced building for mobile. Brad Frost and Ronan Cremin gave pragmatic looks at responsive design and server-side detection. Chris Coyier took everyone on a whirlwind tour of the tools and workflow he uses when building sites. Karen McGrane hammered home the importance of careful consideration of your content. Belen Barros Pena dissected different mobile OS’s like a frog, revealing that fragmentation isn’t quite as bad as it may seem. Scott Jenson, Jonathan Stark and Luke Wroblewski all took a look forward at the incredible potential of the web, and what we need to do to fulfill that potential. It was a great blend of perspectives.

One of the great things about conferences is that blend, that tension between how do I get things done today and what will I be able to do tomorrow. Day to day work and pressing deadlines have a way of forcing us to put our heads down, and in some cases, forces us to lose some of the excitement we get from thinking about the potential of working on this incredible platform. But a good conference with great attendees recharges the batteries. It gets you excited again to work on the web while also arming you with the information you need to do awesome work at your company.

Judging by some of the responses we got, it seems the blend works:

"@bdconf was truly inspiring and amazing! I am all prepped up to do something new!! — Sonali Agrawal

#bdconf is definitely the best conference of its ilk. Fantastic speakers, collective of design/dev/4ward thinking talent all in 1 room — Paul McManus

Kudos to @bdconf and all of the speakers for a fantastic 3 days. Wickedly smart and wildly entertaining — didn’t want it to end — Melissa O’Kane

Thx @bdconf! Incredible speakers. Great conversations. Optimistic energy. More pumped than ever to be designing for the web! — Jon Troutman

Every time I get a review sheet for each speaker, I wonder why are there other options than "Mind Blown"?… — Dillon Curry

My last night at #bdconf full of great conversation and good laughs. Rest assured, I’ll be back! — Jennifer Robbins

Love that I keep taking a step back, questioning my own methods and thought process. What a fantastic conference #bdconf — Kat Archibald

I mentioned great attendees, and that can’t be understated. One attendee, who had attended Breaking Development in the past, pointed out on the first night that it was the side conversations (like the one we were having at the time with a bunch of other attendees) that brought him back. The presentations were just icing on the cake.

The presentations have to be good, of course, but he was right: it is the hallway discussions that transform a good conference into a great one and a great conference into an inspiring and incredible experience. We’ve always had that kind of atmosphere at Breaking Development. The people who attend are passionate and eager to share challenges and solutions alike. We’ve seen people up until all ends of the night at every event we’ve done.

If it’s possible, Dallas took it to another level. Right from the beginning, people were sharing stories, asking questions and offering advice. Dallas re-emphasized something we’ve believed from the beginning: Breaking Development isn’t a conference so much as it is an ongoing discussion. It’s been fun to watch that discussion move forward, step by step, with each new event.

We’re headed back to Orlando in April, with a stellar lineup of speakers and we’re sure to have more incredible conversations. Here’s hoping you can come out next time and help us keep the discussion going!

Yesterday we released the very first episode of the Breaking Development Podcast. I’m super excited about this! Much like the conference, the podcast will focus on web design and development for mobile and beyond. It’s primarily going to be interview based, but we’ll probably also shake it up every once and awhile and do something a little different.

A podcast seemed like a really fun idea. It’s an awesome time to be working on the web, and there are so many fascinating discussions to be had. The way I see it, the best case scenario is that people will like the show, listen, and keep coming back for more. The worst case scenario is people won’t like it, but I’ll be able to use it as an excuse to talk to super smart people on a regular basis about topics that interest me. I really don’t see a downside here.

The first episode features two guests: Erik Runyon from the University of Notre Dame and Dave Olsen from West Virgina University. They’ve both been doing some awesome responsive work for their respective universities. We talked a lot about why and how they’ve implemented responsive design on their sites, how they’re both using RESS, whether user agent detection is evil, designing in the browser and lots of other good stuff.

Give it a listen and let me know what you think. If you enjoy it, a kind word on iTunes would be incredibly helpful. Solid reviews on iTunes are one of the best ways to help others find out about the podcast.

And stay tuned—we already have several more shows lined up with some awesome guests and topics. If you’ve got any suggestions, drop me a line!

Jeremy Keith just wrote a post about mobile navigation icons wherein he talks about the “three lines” icon that Andy Clarke also advocated when he explored the topic earlier.

Theoretically, it would be easy to create the icon using Unicode symbols. For instance, you could create the icon by using the following HTML:

<a>&#9776; Menu </a>

Unfortunately, as Jeremy points out, many mobile devices fail to handle it correctly. Android and Blackberry devices, for example, don’t display the icon as intended.

I recently wanted to use the icon, and ran into this same issue. Inspired by Nicolas Gallagher’s post on pure CSS generated icons, I was able to get the icon to render nicely in about 10 minutes of CSS wrangling. So, if you’re dead set on rendering the icon without using an image, here’s how you can render it in CSS:

<li id="menu"><a href="#">Menu</a></li>

li {
    list-style-type: none;
}
#menu{
    position: relative;
}
#menu a{
    padding-left: 20px;
}
#menu a:before {
    content: "";
    position: absolute;
    top: 30%;
    left:0px;
    width:12px;
    height:2px;
    border-top: 6px double #000;
    border-bottom: 2px solid #000;
}

The above will render the icon to the left of the Menu link. (As someone pointed out on Twitter yesterday, Stu Robson did something very similar.) This is great, but we still have the problem of scalability. If the font-size is 16px, you’re sitting pretty. If it’s any larger or smaller, the icon will become disproportionate. Converting to ems makes for a more flexible solution.

li{
    list-style-type: none;
}
#menu{
    position: relative;
}
#menu a{
    padding-left: 1.25em; /* 20px/16px */
}
#menu a:before {
    content: "";
    position: absolute;
    top: 30%;
    left:0px;
    width:.75em; /* 12px/16px */
    height:.125em; /* 2px/16px */
    border-top: .375em double #000; /* 6px/16px */
    border-bottom: .125em solid #000; /* 2px / 16px */
}​​​​​​​​​​​​​​​​​​​​​​​​​​​

If you want to be extra safe, you can wrap those styles inside of a media query as Roger Johanson has suggested. This should ensure that the styles are only applied to devices that can support generated content.

Is it a hack? Oh, absolutely. And several people were quick to point that out on Twitter. The result though, is the same: the trigram icon rendered without the use of images. The only difference? It’s supported much better.

If you see anyway to improve on it, feel free to fork the Gist.