Tag: Web Development - Page 15 - UNDERDOG of PERFECTION

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.

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.

The :first-child conundrum

Update (April 24, 2024): Yeah, this is a really old post. :first-of-type has existed for years now. Maybe it even existed when I wrote this in 2012, but I wasn’t aware of it.

I like to think I’m a pretty adept CSS developer. I may not have written the book, but I have a solid understanding of CSS and can do some sophisticated things with it.

But one place I always get snagged with CSS is in using the :first-child pseudoclass. The idea behind :first-child is that you can apply different styles to the first child element inside a parent element than for the rest of the instances of that child element inside the same parent.

A way I end up wanting to use it a lot is to give the first child different margins than the rest. Maybe most of them need margin-top: 2em; for instance, but I want the first one to be flush to the top of the parent by using margin-top: 0; to override the default margin.

The full CSS might end up looking like this:

div>h2 { margin-top: 2em; }
div>h2:first-child { margin-top: 0; }

And then that would be put together with some HTML like this:

<div id=”content”>

<h2>First header</h2>
<p>This is the first paragraph!</p>

<h2>Second header</h2>
<p>And, surprise! This is the second paragraph!</p>

</div>

So far, so good. The problem is, what if you stick something else into the <div> before the first <h2> that isn’t another <h2>? Say, something like this:

<div id=”content”>

<div class=”floating_sidebar”>This should be floating to
the right of the content.</div>

<h2>First header</h2>
<p>This is the first paragraph!</p>

<h2>Second header</h2>
<p>And, surprise! This is the second paragraph!</p>

</div>

You may have guessed at this point that I’m not describing a hypothetical situation here. This is a stripped-down version of exactly what I’m building right now. The problem is, now the first <h2> is no longer the first child element of the parent <div> overall, so the :first-child CSS gets ignored.

True, it’s not the first child element, altogether, inside the parent. But it is the first <h2> child inside the parent. I can understand how, in other circumstances — say, if the inserted <div> wasn’t a float — you’d want the h2:first-child not to apply here. But in general it seems to me that if you’re specifying a tag with your :first-child, it should only matter that it’s the first tag of that type under the parent, even if there are other different tags before it.

I guess the real solution here would be to create another pseudo-class that does what I want. Now I just need to convince the standards folks and the browser makers to do that.

Note: The sample HTML was kind of a mess when I originally posted this. That’s what happens when you write a blog post in a hurry before rushing out the door for a meeting. It has now been corrected, and I made some other edits for clarity while I was at it.

How not to do the Internet: a case study in bad web UX

My Subaru dealership’s website(s)

My Subaru Outback is due for service. Time to schedule an appointment. This is the kind of thing I just love to do online. No human interaction necessary!

Unfortunately, my dealership (who shall remain nameless, although I am happy to tell you that their shoddy website experience, which I am about to detail for you, was delivered by auto dealership web development behemoth Dealer.com) has not made the online scheduling option easy. And by “not easy,” I mean “practically impossible.”

First of all, for no good reason, the scheduling interface is built 100% in Flash. I’m pretty sure this scheduling system predates the iPhone, and Flash was at the time a de facto standard, but I’ve been building web applications since 1999 and there was never a time when it made sense to build a system like this in Flash. I deliberately don’t have Flash installed, except the version built into Chrome, so I couldn’t even load it in my browser of choice (Safari). Strike one.

I don’t think so.

Switching over to Chrome, I was able to go through most of the appointment scheduling process, picking the service I needed done, etc., until I got to the point of actually scheduling it, where I was stuck in an endless loop of picking days that were marked “available” on a little calendar overlay, only to get an error message stating “Not available due to shop capacity.” Over and over.

All but giving up, I spotted a curious item at the bottom of the page:

Ooh, this looks promising! Except… wait. How can clicking a link on my computer download an app to my smartphone? Maybe I should visit this site on my iPhone and then tap the link. Except… wait again. This part of the interface is in Flash, so I wouldn’t even see the link on my iPhone. So, what happens if I click it, anyway?

Are you kidding me? We are now at a place where I am interacting with a Flash-based web app on my computer, having it send to my phone an SMS message containing a link to the dealership’s mobile website. I’d even prefer a QR code over this convoluted mess. Strike two.

This is not how you do the Internet.

So I just decided to go over to my iPhone and try loading their website directly. It “smartly” (using the term loosely) redirected automatically to a separate iPhone-optimized version of the site, which I can only assume must be the mobile site the SMS would have linked to. (That is a reasonable assumption, right? We shall see.)

Here’s what I found when I navigated through the iPhone-optimized site to the service department’s page:

That “Service” button calls the service department. The “Contact Us” button is a link to a general-purpose email form. There are no other options.

“The mobile site will let you create, modify, and cancel appointments.” That’s what the SMS form promised. I decided (solely for the purpose of this blog post at this point) to fill out that form, but have the link emailed to me rather than sent as an SMS message. Not surprisingly, the email ended up in my junk folder. Also not surprisingly, the link goes to a different site than the version my iPhone was automatically redirected to when I tried to load the dealership’s main website. (So this is three separate websites they have now.)

I loaded this other mobile site on my iPhone, and it works!

Except, no, wait… it doesn’t:

Except, no, wait again… despite that weird error message, it actually does work:

(How many “except waits” is that now?)

But since it apparently only lets you edit existing appointments, not make new ones, I guess it really doesn’t work, after all. Also, don’t ask me why the iPhone version of the site doesn’t even have a link over to this version, but I guess ultimately it doesn’t matter anyway. Strike three. And four, five and six. In fact, let’s just call the game. And I’ll call the dealership.

Conclusions

What have we learned here? Aside from the fact that I am willing to spend far more time writing a blog rant about this problem than I am just calling to schedule an appointment over the phone, I hope I have impressed the value of web standards. If this site’s interface had been built in simple HTML and JavaScript, instead of Flash, which I can tell you is 100% possible — there is absolutely nothing in the interface functionally, and not even really anything in terms of the design or interaction, that could not have been done with HTML, CSS and JavaScript, even several years ago — then it would have worked fine in Safari without Flash, and it would work on my iPhone.

There has always been a lot of temptation to use Flash to do things that couldn’t be done with web standards, especially when the standards weren’t up to Flash’s capabilities. But succumbing to that temptation led to two trends that were profoundly harmful to the open web, and the effects of which we are — and I am literally — still experiencing today.

Bad UX as standard practice

First, since the sky is the limit when designing Flash interfaces, it created a feedback loop where designers took excessive liberties in experimenting with how basic interface elements like scrollbars and buttons should look and function. Then, project stakeholders who didn’t have the requisite background to make informed UX design decisions made demands that further pushed how these elements look and function. And since Flash had so few constraints on interface design, designers could accommodate those expectations, and the situation spiraled out of control.

This problem is not exclusive to Flash, of course. These days CSS and JavaScript offer tremendous potential for messing with standard UX conventions, and I’ve gotten myself into trouble with this on occasion. Customized scrollbars, fixed-position content, etc. Always remember, just because you can do something doesn’t mean you should. Things in the future will change in ways you can’t anticipate. Those changes are likely to accommodate existing standards, but not your customizations, no matter how brilliant they may be.

Flash as an industry

Second, as Flash grew in popularity it created an entire industry of Flash developers. Suddenly you had people whose livelihood depended upon building interfaces in Flash, regardless of whether or not Flash was really the right tool for the job. And as someone who has always favored open web standards, my perspective is that Flash is only the right tool for the job when it’s the only tool for the job. Even if standards couldn’t do something in quite as… ah-hem… “flashy” a way, if they could do it at all they should be chosen over Flash. I recognize this is a bit subjective, but one thing I can say about it with objectivity is that favoring web standards over Flash for a system like the one I’m describing here would almost certainly have obviated all of the problems I encountered this morning.

A metaphorical lesson to all technology workers: when your only tool is a hammer, every problem looks like a nail. Diversify your toolbox. It will serve your clients better by ensuring that you’re using the best tool for the job, not just the tool you know best. And it will serve your career better by not limiting your job options.

Future-proofing the web

There’s an even bigger reason now that having built this kind of system then using web standards instead of Flash would’ve been a good idea. If this site’s forms had been built with semantic HTML, it would be a comparatively trivial task to build new CSS with responsive web design techniques, allowing a single site to deliver the complete user experience on any device, rather than having to pay for and build three separate, wholly inconsistent, and all inadequate websites. By supporting and adhering to standards in the past, we could (and did) build websites that still work fine today. And by continuing to adhere to standards today, we can build websites that will still work fine tomorrow, even if we don’t really know what tomorrow’s devices will look like, or how we will interact with them.