WebDev Links Of Interest, Issue 1

I keep finding amazingly good blog posts or links of interest that I end up bookmarking for my own uses, but I end up having to tell people on a case-by-case basis why one article is good for one reason or another. I end up bookmarking on my Delicious account and sharing blog articles I like via my Google Reader account, but it’s becoming increasingly obvious that this isn’t enough.

So instead, I’m going to write a weekly (hopefully) article on links I’ve come across and why they’re cool. So, without further ado, here’s the first installment of Links Of Interest.

Object-Oriented CSS

I came across a link from Ajaxian, which talks about Nicole Sullivan’s work on Object Oriented CSS. Here’s an excerpt:

How do you scale CSS for millions of visitors or thousands of pages? Nicole first presented Object Oriented CSS at Web Directions North in Denver. Since then, the response has been overwhelming. OOCSS allows you to write fast, maintainable, standards-based front end code. It adds much needed predictability to CSS so that even beginners can participate in writing beautiful websites.

The idea is intriguing. I’m curious to see how it can be applied to mobile iPhone development. The important thing though is that most people get web development wrong. Either JavaScript, CSS, semantic markup, or all of the above. I even know people who still do their layout with tables!

Typically when you consistently find a problem with development across a series of projects, the problem is most likely you, or at least the way you’re doing things. Take a step back and re-think the problem, and re-educate yourself on best practices.

There have been articles across a number of respectible web development blogs talking about writing reusable code, and defining client-side logic in classes (even when you think you might never re-use that application logic again). But I’ve never seen that principle applied to CSS. I definitely recommend reading more on this topic.

Juicer: JavaScript and CSS Packaging

YUICompressor, and its friends, are great methods for compressing CSS and Javascript, but my biggest wins you can possibly make in optimizing the size of your script or style content is simply to not include the things you don’t need. This is why I perked up when I saw a post on Ajaxian on a project called Juicer, which is a tool to package JavaScript and CSS while applying best practices as it does its work.

When developers start a project, they’ll go to the site for their tool of choice. For me, I first go to MooTools and download a kitchen-sink build of MooTools-core and -more, and as I develop I’ll use more and more features of it.

However, when it comes time to ship, I need to scale back what my MooTools build includes since probably 75% of it won’t be needed by my project. But the question is, which 75%? This is mostly a trial-and-error process which is made all the more difficult to deal with because I’m used to Perl and CPAN resolving dependancies almost flawlessly.

So my hope is that Juicer can help me solve some of these problems, and I can use it at build-time so I not only can resolve dependancies and build the proper Perl modules to deploy my webapps, but that it can trim down my JavaScript libraries to include only the features I need.

QFocuser

This seems like quite a simple script, but it solves an important problem. In a nutshell, it creates a way of handling focus and blur events for fields and other sorts of widgets so you can make your web applications accessible. Ajaxian gives a little summary of QFocuser, but I had thought that this could be quite powerful for reasons other than accessibility.

At my day job, we style our text fields specially when they are disabled, selected, or just regular plain fields. Most of our legacy code manages this manually, by setting attributes and CSS properties independantly, and many places gets it wrong. I’ve been implementing some changes in our framework to eliminate this problem, and largely involved implementing much of what QFocuser does, but in a more specific way.

I’m curious to see how I can apply it here, and use it as a generic mechanism to make our UI behave more consistently.

Internet Marketer’s Checklist

Over at SEOmoz there’s this great post, titled “The Internet Marketer’s Checklist For Determining If a Business Idea is Worth Pursuing“. The title is a mouthful, but it’s a great discussion of the things that will make an online application succeed or fail. As programmers and technical types, we often lose site of the actual goal of doing what we do: building stuff that people will use.

I’m a terrible example of your average user. I use the keyboard primarily for navigation, even on my Mac (Quicksilver FTW!), I use the command-line almost exclusively. Most users wouldn’t be caught dead using their computers that way. This extends to other areas as well. Applications that would appeal to us techies won’t appeal to the nontechnical, teen-with-flashy-website crowd.

I’m fortunate that my wife not only is very technically savvy, but still is in touch with her non-technical roots, and has a psychology degree and her lab experience to know how people think. I use her as my litmus test to see if an idea is worth pursuing. But beyond knowing if someone will be able to relate to a website, this checklist looks like a great way seeing end-to-end if a site would be understood, would be marketable, and if it would actually stand a chance of being used by the general public.