One of the most common mistakes I see in web development is not adequately testing sites for a variety of viewport sizes. It’s more than just incorrect rendering on mobile devices, or looking bad on large screens. Issues with small browser windows are often overlooked in the course of building a site.

I notice this almost daily in my development environment, where I work with two 960px windows side-by-side. In so many sites I visit, I know if I see a scrollbar on the bottom of the page, I’m likely to see a min-width error when I scroll to the right.

During yesterday’s discussion of the Stop Online Piracy Act, House representative Steve King had this to tweet:

We are debating the Stop Online Piracy Act and Shiela Jackson has so bored me that I’m killing time by surfing the Internet.

Heckuva job, Stevie.

Peter-Paul Koch, of QuirksMode, posted earlier this week about Siri and its potential to drive web accessibility. He envisions a horrible-but-possible future for the web, where digital assistants mindlessly reel off the contents of poorly constructed websites. Where I feel Koch misses the mark is in imagining that the future of interacting with the web will be limited by existing paradigms such as browsers and screen readers.

I think that, with rare exception, having Siri read long-form streams of content to a user is a less-than-desirable interface¹. One of its greatest strengths is its conversational style of interaction, providing a back-and-forth dialog that proves exceptionally effective. If Siri is in the middle of reciting a long passage of text, there’s only one option for responding: interrupt it.

Last Friday, Bearded celebrated its third anniversary. It’s been a wild ride, and we’re all looking forward to what the future holds. To mark the occasion, we’ve launched a brand new website with a fabulous responsive design.

Our previous site, launched in November 2009, served us well over the years. But the web has become a more diverse place since then, with screens coming in increasingly varied sizes and touch-based devices more prevalent than ever. Obviously, it was time for a new approach. Enter responsive web design, the idea that a single design can be made to meet the needs of all your users without removing content or building a second layout.

Google’s recent focus on bringing a clean, uniform appearance to their web platform was a breath of fresh air from a company that has previously ignored design. Google+ was the first volley, with the rest of the product family being gradually updated to match. This was all great news: the most widely used web products were going to get better with a renewed focus on usable, beautiful experiences.

Clearly beggars can’t be choosers. What Google has finally given us is a mess. Rather than re-imagine how users interact with Gmail or Reader, the entire suite of applications has simply been whitewashed with a muddled skin of black, grey and red.

As the new iPhone starts landing in customers’ lucky hands, everyone is making the connection between Siri and the 1987 Knowledge Navigator concept. It’s the stuff of science fiction, teasing us with the possibility that we could create a world smart enough to understand our needs. I can’t begin to express how delightful it is to watch technology catch up to our dreams, one step at a time: we now live on the Starship Enterprise.

Kyle Baxter calls Siri the future of the web, and I’m pretty sure he’s right. Rather than teaching ourselves to think like a computer, we’re beginning to teach the computer to respond to the way we think. Making information easily available from recognized sources¹ and returning definitive answers democratizes knowledge in a whole new way.

I was recently asked how great open source projects can have great design. It sounds like a complicated problem: designers and developers live in two worlds that rarely meet. What can we do to bring better design to our ideas?

As a developer, the desire to work on open source projects comes from a drive to share a particular idea or do some good via code. In doing so, I’m achieving my personal goals, and it feels great.

But how do I convince someone else to work towards my lofty and worthwhile dreams? For free? The same way we convince other developers to work on open source with us: ask for help. There’s a perception that designers aren’t interested in contributing to open software projects, which is wholly false. Any time I’ve wanted help with a project, I’ve had no trouble finding great designers ready to step up for a good cause.

There’s a funny contradiction amongst developers. It’s a mark of pride to work the longest hours, drink the most caffeine, eat at your desk and sleep the least. Essentially, whoever can endure the most punishment gets to be king of the hill. Obviously I’m being hyperbolic, but it’s fascinating that we respect each other’s ability to disregard personal wellness.

My first computer was a Macintosh Plus. My father, a musician, bought it to use as a digital sequencer for creating new compositions. Sitting in his lap at just two years old, I watched in awe as he created incredible new sounds from a plastic keyboard. Playing games on it, I desperately wanted to create new and exciting adventures of my own. That small, gray box with a small, gray screen inspired a sense of wonder and joy that remains with me every time I touch a computer to this day.

Steve Jobs changed my life. He changed the way we interact with the world, and nearly every computer, phone and device today bears his mark in some way, large or small. President Obama expressed it powerfully in his statement this evening:

Steve was fond of saying that he lived every day like it was his last.  Because he did, he transformed our lives, redefined entire industries, and achieved one of the rarest feats in human history: he changed the way each of us sees the world.

Thank you, Steve. For inspiring us all to think differently, and create insanely great things every day.

We’ve been building Briquette at Bearded¹ on and off since December 2010. When beginning the project, we chose to use MacRuby as a way to make the project more accessible to our developers that weren’t familiar with Objective-C, and to explore a possible future of native Mac OS X (and iOS) development.

For building new Mac apps, I would recommend MacRuby without hesitation. It delivers on the promise of bringing the best aspects of Ruby to native, desktop app development. Abstracting away from Objective-C’s sometimes-too-verbose syntax is often a joy, and it’s useful to have access to the complete library of both Cocoa frameworks and Ruby gems². It’s a young framework that’s getting better by the day, and the good has consistently outweighed the bad.

But there are drawbacks, especially when using Xcode heavily. I want to touch on some areas that I feel have often been ignored, or covered inadequately, and pour a little cold water on the heads of anyone starting a MacRuby project. But just a little.