Category: Computers & Technology - Page 39

Practical responsive web design, part one

I’ve been wanting to write this post for a while, but I’ve been too busy writing code instead. Plus, the techniques are evolving and changing so fast, that by the time I finish a project, the way I built it is already obsolete.

Now, with the Breaking Development Conference in town and a few recent responsive site launches under my belt, it seemed like a good time to write up a summary of what I’ve learned, what I’m doing, and where I think all of this is going.

First, a quick aside. I didn’t attend the conference. I would have liked to, but as an independent developer I never seem able to justify the standard $500-per-day rate most conferences charge. That doesn’t mean the conferences don’t have value; they’re just not for me.

Before we begin

There are a few caveats I want to lay down before I start talking about responsive web design:

This stuff is changing… fast. Anything I write here may become foolishly out of date by the time I hit the “Publish” button. Responsive web design is a work in progress, and there are no rules (yet).

What I’m doing may not be “by the book,” proper-name Responsive Web Design. The book is great, and there are “experts” who have much deeper knowledge of these strategies than I do. But as I said above, there are no rules (yet). I want to describe the practical techniques I am employing on actual live web projects, under often less-than-ideal circumstances.

Every website is different. The company is different. Its audience is different. The content and style and context where it will be viewed are different. The balance between showing off fancy new features on high-resolution tablet displays and supporting corporate IT departments that are still straggling with Windows XP and Internet Explorer 6 will vary. In short, what I am doing may not work for you. But I hope it can give you some ideas that will.

A practical baseline

My goal with responsive design is to get the biggest “bang for my (client’s) buck.” I recently read a about a study that found almost 4,000 different Android devices in a site’s access logs, with many of them only appearing in the logs once. It is not possible to account for all of these variations. And, after its primary goal of providing an optimal user experience across a variety of devices, not needing to account for each of them individually is the second biggest purpose of responsive design. (That’s also, arguably, its biggest practical benefit.) By building on a fluid, flexible structure from the beginning, a site will look good regardless of slight variations in its presentation.

But I’m not starting from scratch. I work with a number of designers who deliver their work to me in a variety of formats (usually Adobe software). They’re tremendously talented, but they don’t all have a full working knowledge of fluid grids and all of the other considerations that go into responsive web design. So my job is largely to translate these “traditional” web designs into something that works, more or less, with a responsive approach.

I’m targeting three basic screen types: computer (desktop or laptop, including iPad in horizontal orientation), tablet (primarily iPad in vertical orientation, but also smaller tablets like the Kindle Fire or the Nook Color), and smartphone (primarily iPhone, but also Android and Windows Phone). Additionally, I am trying to balance a Mobile First approach with support for Internet Explorer 7 and 8. (I am fortunate to be in a position not to need to worry much about IE6 anymore, and IE9 plays well with CSS3 media queries.) In some cases I am also targeting “very large” computer displays, those with a horizontal resolution of 1280 or above, with a scaled-up layout.

So, instead of accounting for 4,000+ different screens, I’m aiming at 3 (or 4) general screen categories. I am also accounting for two basic browser categories: IE 7 and 8, and everything else. (Yes, if you approach it in the right way, it’s really that simple. Almost.)

Fixed, yet flexible

With this “practical baseline” in mind, and working primarily with traditional fixed-width web designs as a starting point, I’ve established break points (widths at which the layout changes significantly) at around 700 pixels (varying by site between 640 and 720); at 960 pixels for the “standard” computer (and horizontal iPad) layouts; and, for the “very large” displays, at 1200 pixels. This allows for a traditional fixed-width web design approach to be used, rather than accounting for a completely fluid layout across all screen sizes. It may sound like a cop-out, but I find it to be a very helpful way to get things done when collaborating with designers who are not living and breathing this stuff the way I do every day.

For screens below my “around 700” threshold, I drop into a fully-fluid, single-column layout targeted at the smartphone user experience. In these cases there may be other significant changes to the layout, such as collapsing content blocks into expandable buttons, allowing users to quickly see what’s on the page without having to scroll endlessly. (This is not a radical invention of my own… it’s more-or-less how the mobile version of Wikipedia functions.)

In part two, I will get into the details of how I built out a pair of recent websites, including a few code examples, to show how the HTML and CSS fit together, and how I balance the seemingly incompatible worlds of mobile-first and IE8.

Social media case study #001: @Mike_FTW and Twitter jackassery

I don’t know Mike Monteiro personally. Apparently I do know someone else who does, but that’s irrelevant here. This post is not about Mike Monteiro, the flesh-and-blood human being, owner of Mule Design Studio and author of Design Is a Job. This post is about @Mike_FTW (NSFW, depending on where you W), Mike Monteiro’s Twitter persona.

In case you’re curious but afraid to click that last link, allow me to explain, as the imagery is critical to my understanding of what @Mike_FTW is all about. The background image on Mike’s Twitter page is a topless photo of Bea Arthur, circa early 1970s. It is a rather plain-looking photo, neither sexualized nor grotesque. It’s almost like a school portrait, actually, except for the fact that she’s not wearing anything.

It may seem a little odd that I should fixate so much on this photo in trying to understand what @Mike_FTW is all about, but I think it’s key. It’s like a surgeon general’s warning for his Twitter feed. It’s provocative, confusing to some, but ultimately benign. But what is it really saying? If Mike were simply trying to (pardon my word choice) titillate, he certainly would have chosen a sexier photo. If he were trying to scare people off, he’d have gone with one more extreme.

I think there’s something much more deliberate, more considered, about this choice of photo. Because while it may ultimately be benign, it’s not without meaning. Bea Arthur, especially in the early 1970s, was a major public face for feminism with her TV show Maude. She chose to have this photo taken and made public. I don’t know all of the circumstances surrounding it, but what it says to me is, “Get over it. They’re just boobs.” It’s a challenge to both ends of the morality spectrum to lighten up, loosen up, toughen up, and wise up. And I think that’s really what Mike Monteiro’s mission is with @Mike_FTW.

@Mike_FTW is almost always abrasive, coarse, and rude, but with an underlying ethos that isn’t too hard to pick up on if you’re paying attention. A couple of recent stunts have cast this in a clear light.

Mike Monteiro: Splenda yoga mom

On May 21-22, @Mike_FTW temporarily changed tone, posting a series of tweets with a cloyingly banal new persona he dubbed “Splenda yoga mom”. It confused and outraged some of his followers, not unlike the “straight” episode of Sealab 2021. Eventually he came clean, explaining in a succinct set of tweets how this stuff works:

But it’s more than that. Because he didn’t just pull a stunt to piss off his followers by confounding their unjustified expectations of how he should behave on Twitter. He wrapped the stunt in a successful effort to make a real, positive difference in the world by drumming up thousands of dollars in donations to SmallCanBeBig.org.

What is the value of a tweet?

Yesterday, this happened: Atlanta-based web developer John Graham wrote a blog post, never intended for a wide audience (as most blogs, this one included, rightly should not be) about why he stopped listening to John Gruber’s The Talk Show podcast, and why he unfollowed @Mike_FTW. The post did not offer any great insight, nor was it particularly interesting to anyone beyond the author himself. But there’s no indication that he ever intended it to be, except for one thing: he included “@Mike_FTW” in his tweet about the post. Monteiro picked up the ball Graham had gently placed at his feet, and ran with it.

This time the stunt was to get @johnegraham2 1000 Twitter followers in a day, and get them all to unfollow him en masse a day later. Again the stunt worked… and again it raised over $1000 for SmallCanBeBig.org. In his blog post, John Graham said “The problem for me is that I don’t find him funny and therefore there doesn’t seem to be any value in his tweets.” Humor is subjective, of course, but raising over $1000 to help a family in need in a matter of hours isn’t. A lot of people may not agree with Mike Monteiro’s tactics (if they even understand them), but it’s hard to argue they’re ineffective.

So what’s your point?

What can we really learn from @Mike_FTW, the Twitter alter-ego of Mike Monteiro? How much of it is Mike, and how much is an act? Unless you know Mike personally, that question is impossible to answer. Likewise his motivations to do what he does, the way that he does, are a bit of a mystery. Still, there are some lessons here for how to use social media effectively, something that isn’t lost on @Mike_FTW. After the first stunt, he tweeted in his typically humble fashion:

And THAT, you social media strategy wonk douchebags, is how it’s done.

— Mike Monteiro (@Mike_FTW) May 22, 2012

And, yesterday:

I feel like I am getting the hang of this social media thing. Those webinars practically pay for themselves.

— Mike Monteiro (@Mike_FTW) May 30, 2012

Meanwhile, John Graham, the butt of the joke, responded on his blog and SmallCanBeBig.org showed their appreciation:

$1200+ raised for 3 families (rent, mortgage, utilities for parents with kids facing cancer) @Mike_FTW @johnegraham2 Jokes aside – amazing.

— SmallCanBeBig.org (@SmallCanBeBig) May 31, 2012

What do I learn about social media strategy from Mike Monteiro? First off, don’t think about “social media strategy”. If that’s your focus, you’re doomed to failure. Engagement on social media may be superficial, but it’s real. If you’re doing it to “build your brand” or “extend your reach” or some such nonsense, give up. You have to do it because you want to. You have to mean it. Even if you’re taking on an obnoxious persona that will enrage as many people as it delights, make it meaningful.

Second, be interesting. That doesn’t mean being a “great guy” who’s boring to follow. Don’t play it safe. Take chances. Be distinctive. Be funny, weird, rude, unpredictable. Social media is entertainment as much as anything else, and if you don’t entertain people, they won’t stick around.

Third, or maybe second-and-a-half, have a distinct voice. Remember, the people who only know you through social media only know you through social media. The persona you create doesn’t have to be you, but it has to be someone.

And finally, have fun. I don’t think there’s any doubt that Mike Monteiro has fun with @Mike_FTW. And he certainly has fun poking people who take themselves too seriously.

Update: Mike Monteiro has clarified that the background image on his Twitter page is a painting, not a photo, which is why it hasn’t been banned by Twitter. This fact may alter the veracity and implications of my statement that Bea Arthur posed for and approved the image, but I think the larger message is still relevant. They’re still just boobs.

Also, contrary to all obvious indications, I did not deliberately craft this post in a way to fish for a response, retweet, or acknowledgment from Mike Monteiro. But, perhaps, @Mike_FTW is another story.

Update #2: I neglected to mention this in the original post above, but I think it’s worth at least noting: the situation that seems to have pushed Mike Monteiro over the edge in the case of both of these “stunts” (my word) is the vitriolic reaction many people have had to John Gruber taking The Talk Show to Mike’s Mule Radio Syndicate. It’s not directly relevant to the point I was trying to make here, but it’s probably helpful to provide some context. Mike may be acting like a jerk on Twitter, but it’s nothing compared to some of the reactions he gets.

My (just-discovered) workaround to the WebKit letter-spacing bug

Update (5/29/2012): Upon working further with the project that formed the basis of this post, I discovered that my solution did not work, or at least, no longer worked. It’s not uncommon as I get deeper into a project with a large CSS file that there are subtle, inadvertent effects of the various CSS properties that get added along the way. Looking back now, I can’t determine for sure whether my solution did once work with the simpler version of the site, and something else I added later counteracted it, or if I was just too eager about a solution to realize it never quite worked in the first place. As a result, I had considered deleting this post entirely, but I have decided to leave it live, to further the discussion of the topic, or at the very least to serve as a monument to my challenges.

WebKit, the rendering engine “under the hood” in both Safari and Chrome, has a known issue handling the CSS letter-spacing property at certain small increments, and at certain font sizes.

Specifically, if defining letter-spacing in increments smaller than 1px or 0.1em, it seems to just ignore the property altogether… except at larger-than-default sizes.

I typically use em or % these days to define text sizes in CSS. So in my situation, I’ve found that my letter-spacing: 0.05em works if I also specify font-size: 125% (or larger), but if I have font-size set to 100% or less, the letter-spacing gets ignored.

Typically, after loading reset.css, I set a baseline font size for the document with body { font-size: 100%; } (or some size… actually it’s usually 80% but these days I’ve been leaning towards larger type).

I decided to play around with this a bit to see if I could resolve the letter-spacing issue, and I found a nice, easy solution that works at least for the particular site I’m currently testing it on. Your experience may vary, depending on how your HTML is structured and how complex your design is.

Here’s the solution:

body {
  font-size: 125%;
  letter-spacing: 0.05em;
  line-height: 1.3em;
}

body>* {
  font-size: 85%;
  line-height: 1.3em;
}

You may want to adjust the exact values of font-size to suit your needs. (And, yes, I’m aware that mathematically 125% and 85% don’t cancel each other out, but they’re close enough for my purposes.) It’s important to include the line-height property in body>* to define your target line height; otherwise your lines will be too far apart. Set it to whatever your ideal value is. (I usually prefer line-height: 1.5em personally, but for larger type, as on the site I’m currently working on, it gets too spaced-out.)

So what’s going on here? Well, strangely, it seems WebKit can actually render smaller type with line-spacing less than 1px or 0.1em just fine, but it won’t unless somewhere in the “cascade” the type has been defined as being a certain amount larger than 100%. I don’t get it, but until the bug (which it seems clearly to be after all of this) gets fixed, at least this seems to be a reasonably clean workaround.

It’s very important that you use body>* and not just body *. If you don’t know why, well… try it out and see. (The upshot: we’re applying a uniform scaling-down across the board on all elements directly under body, which is practically the same as just defining our target font size directly on body itself, but with the benefit of working around the letter-spacing bug.)

Note: I have only tested this using em as the unit of measure for letter-spacing. I’m aware of the issue with px as well, but I’m not sure this solution will work for that. But… really… just use em instead!

How are open source CMSes like Microsoft enterprise software?

Aside from the fact that both topics would put the average blog reader to sleep before the end of the first…

OK, now that they’re asleep, let’s talk. Throughout most of my career, open source software and Microsoft’s (or, really, any software behemoth’s) enterprise “solutions” have seemed diametrically opposed. But the more I think about the situation, I begin to find some startling similarities, at least in their implementation (and reasons for said implementation), if not in their actual structure and licensing.

If you’re the one person (besides me) who’s spent any significant amount of time reading this blog, you probably know two things: 1) I don’t like Microsoft, and 2) I don’t like Drupal. So these are the objects of my scorn in today’s post as well, although the problems I’m describing can be generalized, I think, to the broader sectors of the software industry that they represent.

When I worked in the corporate world, I resented Microsoft’s dominance across the board from operating systems to desktop software to enterprise systems. It just seemed that most of their tools weren’t really that good, and eventually I began to realize that the reason they were successful was that Microsoft’s customers were not the end users, but rather the IT managers who made purchasing decisions. These decisions were largely based on their own knowledge and experience with Microsoft’s software (to the detriment of other, possibly superior options), but also (I believe cynically) to preserve their own jobs and those of their staffs. Microsoft’s systems require(d?) constant maintenance and support. Not only did this mean bigger IT staffs on the corporate payroll, but it meant lots of highly paid “consulting” firms whose sole job was to promote and then support the sales and implementation of Microsoft products.

In the indie developer world, where I now reside, the culture and software platforms are different, but perhaps not as different as they seem. Apple’s computers dominate the desktops in small studios, and the tabletops in coffeehouses where freelancers can frequently be spotted hunched over their MacBooks hard at work while sipping lattes and meeting (usually a little too loudly) with clients. And open source software dominates at the server level.

But just like Microsoft’s platforms, I think most open source software just isn’t really very good. And the problem, once again, is the customer (or… well… whatever you call the person who makes the decisions when selecting a free product). It seems that the end user experience is rarely given much priority when most open source software is being designed and developed. Part of the problem is a lack of direct contact between the development teams and those end users (or, to be honest, even between the geographically scattered members of the development teams themselves). Devs don’t really know what end users want or need. They only know what they want or need, along with what’s been submitted to their bug trackers.

It’s not that these devs are bad people, or bad at what they do. There’s just a disconnect between coder and user, and as a result the goal of building good software isn’t met.

So, why do independent developers still use tools that are not really the best for their clients? Again, cynically, I wonder sometimes if job security isn’t a factor. It’s a lot easier to build something that works, but that requires indefinite, ongoing attention and support, than to build something that is flawless, that you can hand off to your client and never touch again. It’s easier… and it provides built-in job security.

Now, I’m not perfect, and I’m not above all of this. There is no such thing as flawless software, and I have ongoing support contracts with some of my bigger clients. But I’m proud to say that’s mostly because I’m constantly building new sites for them, or building functional enhancements onto the sites they already have, rather than doing endless bug fixes and technical support because the tools I’ve sold them are too confusing or simply don’t work right. Sure, the bug fixes and tech support do happen. But the tools — primarily WordPress and cms34, my own CMS — are built much more with the end user in mind, and have managed to avoid the pitfalls that mean a guaranteed job for me at the expense of a mediocre user experience for my clients.

That’s harder, and riskier. But it’s better. I’m delivering a higher quality product to the clients, and I’m keeping my own work interesting and moving forward.

On instruction vs. understanding

I’ve assembled a lot of IKEA furniture in my life, and along the way I’ve learned a few things, such as:

Every piece of IKEA furniture comes with an identical Allen wrench, which you will only ever use to assemble that piece of furniture, and which will forever after gather dust in a drawer in your basement with all of the other identical Allen wrenches you’ve acquired at IKEA.
A lot of stuff that looks like wood is actually a woodgrain pattern printed on plastic-coated paper, wrapped around a block of glued-together sawdust.
Every piece of IKEA furniture will take two hours to assemble, no matter how large or small, or how many separate pieces it contains.
Assembly might take slightly less time if you possess a Ph.D in archaeology with a special emphasis in either Egyptian or Mayan hieroglyphics.
You will almost always realize 2/3 of the way through the process that you are doing it backwards.
It never gets any easier.

Those universal hieroglyphic assembly instructions are, along with the ubiquitous Allen wrench and product names featuring umlauts or o’s with slashes through them, the most easily mocked symbol of IKEA. The pictures are often inscrutable, and the overall impression overwhelming. More than once I have felt compelled simply to curl up in the corner of the room and weep silently.

But written assembly instructions (from other companies, of course) are often far, far worse. If I can’t make sense of a diagram showing exactly how the parts fit together, how am I possibly supposed to understand written instructions along the lines of “insert the ball socket assembly into the reverse threaded wall mount bracket and affix with the supplied 8mm Torx screws and self-locking bushings”? (OK, I just made that up, but it sounds real, doesn’t it? Wait, what are you doing over there in the corner?)

And therein lies the problem: there is a great mental chasm between instructions and understanding. It doesn’t matter what form the instructions take: written, visual, verbal, semaphore. Whether you approach them in an unthinking, just-get-it-done, “paint by numbers” fashion, or you attempt to read and absorb them all before beginning, instructions can only communicate so much.

Recently I attempted to assemble and install a curtain wire system from IKEA, for the purpose of hanging posters from bulldog clips at the new Room 34 studio. The instructions supplied with the curtain wire were some of the most panic-inducing I’ve ever seen from IKEA, and that’s saying something.

The first two times I tried to put this thing together, I just gave up. Then I decided not even to bother with the instructions. Instead, I closely examined the various parts, until I came to my own understanding of how they fit together, and how it all attached to the wall. From that point, I was able to refer back to the instructions in a new way, as a reminder of my own thought processes, rather than as a bizarre alien communication from some distant Hömwørld.

I’ve been in IKEA’s shoes, though. Not literally. I don’t think they sell shoes, although I have seen fuzzy slippers there in a big wire bin for 99 cents a pair. But I have had to prepare instructions myself, and to lead training sessions where I attempt to communicate to my clients how to use web applications I have developed for them. It’s a challenge.

How much information is too much; how much is too little? What is the right information to convey, and what can they do without? Is it better to provide a broad foundation of knowledge or a targeted “cheat sheet” of most commonly used tasks? How do I stop instructing people and help them to understand?

I don’t have the answers. I’m still exploring. In my own experience, it’s direct, hands-on activities that are directly applicable to solving real-world problems that best allow me to develop my own unique understanding of how a system works. But it can be incredibly difficult and time-consuming as an instructor to develop suitable training materials and create an environment where that type of learning can take place.