Shortly after upgrading to Safari 4, the latest version of Apple’s web browser, I took a look at a site that I’ve been working on and noticed that the layout was off. The site looked fine for the most part, but some elements—specifically some navigational links—had been left unstyled by the site’s style sheet.

Normally, style sheet info is an “all or nothing” deal. Either your style sheet works or it doesn’t. And if it doesn’t, it’s usually because of something simple, like the style sheet’s URL being incorrectly specified. But that obviously wasn’t the case here, because part of the style sheet was working.

Furthermore, the site looked perfectly fine in Firefox, and I couldn’t remember the site ever having this issue in Safari 3. So obviously, my thoughts turned to Safari 4 as the culprit. I immediately began dreading the hours spent trawling through discussion forums and mailing lists to try and learn if style sheets were being handled differently in Safari 4. All manner of worst case scenarios were tumbling around in my imagination when, in a moment of clarity, I decided to validate my style sheet.

Sure enough, the style sheet had a few errors. Most of them were fairly straightforward, like improper values being specified for an attribute. But one error stood out to me: one of the hex color values was invalid because it contained hidden characters.

That’s when it dawned on me. When making my (X)HTML/CSS mockups, I often use of DigitalColor Meter, an OS X utility that shows you the color value of any pixel on the screen. It’s a very handy utility for web developers because it lets you get a color from your layout without having to load a mockup in Photoshop just so you can use Photoshop’s Eyedropper tool. Instead, you fire up DigitalColor Meter, hover over the area containing the color you need, press Command-Shift-C, go to your HTML editor, press Command-V, and presto—you’ve got your hex value.

It’s a pretty slick shortcut, but I’d forgotten that—for whatever reason—hidden characters are inserted into the hex value when you paste it into your HTML editor. Take a look at this screenshot taken of a recently pasted hex value in BBEdit with the “Show Invisibles” option turned on.

As you can see, there are additional characters after the “96”, “C2”, and “51”. I usually remember to remove such characters, but in this instance, I had missed one. Other browsers ignored the hidden character when they loaded the style sheet but Safari 4 choked on it; when it loaded the style sheet, any info after the hidden character was simply ignored. (I’ll let the reader decide if this is a good thing or not. But personally, I tend to think that it is a good thing when a web browser forces me to make sure that my code is neat and tidy.)

So for today’s lesson, repeat after me: Always validate your style sheet(s) and if you’re using DigitalColor Meter, make sure you clean out any hidden characters if/when you paste hex values from it into your HTML editor.

When it comes to building a website on ExpressionEngine, I do my best to use as much of the platform’s built-in functionality as possible. In other words, I don’t like to go about installing third party add-ons willy-nilly. After all, the more add-ons I install, the more I have remember when it comes time to perform updates.

In addition, I’ve found that implementing and relying on too many add-ons can sometimes lock you into a particular method for developing and managing a website, which might be problematic down the road if/when you do a redesign. On the other hand, relying more on EE’s built-in capabilities can sometimes result in a more flexible website, meaning future redesigns are less time-consuming. (Although let’s face it: all redesigns are time-consuming in their own way.)

That being said, there are a number of EE add-ons that have become almost indispensable to me, that have become de facto parts of my EE toolkit. That’s not to say that I use all of them on every website that I develop—you always need to evaluate each website’s unique requirements so as to know which add-ons to install, and just as importantly, which add-ons to not install.

However, each of the add-ons listed below makes various facets of EE-based website development a little easier and the EE-powered sites that I develop cooler, more user-friendly (for both clients and their customers), and just more solid all around.

Continue reading…

I’m working on a website project where I wanted to implement some tooltips. Normally, I don’t care for the things—I find them more a nuisance than anything else, or a shameless attempt at injecting a little whizbang—but in the particular case, I was willing to give them a shot. My JavaScript library of choice is the might jQuery, so I went looking for a plugin that I could drop into my site and quickly configure.

A quick Google search revealed several potential solutions, and I quickly latched onto SimpleTip. After all, I needed something simple and easy, so it sounded like the logical choice. After fiddling around with SimpleTip for a little while, though, I finally noticed that great big banner announcing qTip, SimpleTip’s successor.

In terms of features and functionality, qTip is on the other end of the spectrum. Among its features are customizable styles and positioning, visual effects, dynamic (read: AJAX) content (including a nifty translation method), and even multi-level tooltips (i.e., tooltips for tooltips)—check out the demos and documentation for examples.

At the same time, however, all of this functionality doesn’t come at the cost of simplicity or ease of use. qTip is very easy to install and configure, almost surprisingly so given all that it can do. In fact, it’s almost too easy: I’ve probably spent way too much time fiddling with qTip simply because it’s so easy to do some really cool things with it.

Some of you may not know this, but I’m actually the vice president of a corporation (Red Bicycle, Inc., in case you’re curious). Unfortunately, this doesn’t mean that I get to ride around in limos or receive any Federal bailout funds. But it does mean that I get to launch a brand new website.

Now, admittedly, this website should’ve been launched about a year ago, but various factors—including my own obsessive-compulsiveness—caused the delay. Which led to some urgency to have something online since Opus no longer houses my portfolio. You see, for a long time, I’ve had nothing to send to prospective clients and interested parties except a list of links via e-mail. Which is certainly functional, but it’s kind of sad when a web designer doesn’t have a website where he can show off his kung fu.

But the final straw came when I mentioned to Renae that I was tinkering around with some new ideas for Opus. She, in good wifely fashion, put her foot down and insisted that I finish and launch the corporate website before pulling off yet another Opus redesign. Which was very wise of her. And so here it is, the official Red Bicycle website.

Now, if you’ll excuse me, I need to get cracking on that new Opus design…

I’m currently in the midst of a flurry of activity as I try to get as many things done as possible before we leave for Japan next week. Most of them are work-related—getting projects to a good stopping point, writing documentation so others can pick up where I left off, etc.—but there are several “personal” projects that I’m also in the process wrapping up.

At the top of the “personal” list is the website for Redeemer, the church plant that Renae, Simon, and I are a part of. When we—myself and others in the church—started working on the website, we had pretty grandiose ideas. But honestly, we bit off quite a bit more than we could chew, and as such, the website kept getting delayed. So a few weeks ago, we decided to just take a step back, move everything that we’d been working on with regards to the website to the back burner, and start from a clean slate—just so we’d finally have something other than a “coming soon” page.

And so I’m very pleased to say that the Redeemer website—or at least the first version of it—is now live. In the coming weeks and months, we’ll be fleshing it out a bit more, but for the time being, what you’ll see is an extremely condensed, streamlined version of the site.

The first thing you’ll probably notice is that the website is just one single page. I’ve been wanting to do a single page website for awhile now, as I find the approach comes with a few interesting challenges of its own.

It requires a slightly different way at approaching the design because each pixel means so much more. You can’t just assume that this graphic or that piece of content can be moved to another page because there is no other page. You have to use the space more efficiently—you can’t just cram everything you want onto the page because that will quickly lead to a page that’s far too much in terms of filesize, bandwidth usage, scrolling, etc. You’re forced to strip away all of the inessential stuff, in terms of both the content and design, so that the final product isn’t too cumbersome and find different ways of presenting the content.

For example, I’m using a slightly modified form of the jQuery UI‘s tab functionality to display the ministries. Clicking on the ministries menu will display each of the ministries in the same space, allowing the user to quickly cycle through the content. In essence, you’re condensing a whole section’s worth of content into a single space.

Of course, there are trade-offs. If someone wanted to a bookmark a particular ministry’s “page”, it’s possible but a little more involved than simply hitting Ctrl-D or Command-D in their browser. And the scrolling isn’t perfect. If someone has a big monitor and/or expanded their browser window, than scrolling down to the “Get Connected” section might be cut-off due to the amount of space available for scrolling (try scrolling down the website with your browser window set to different heights to see what I’m talking about).

But there are always going to be trade-offs, that’s just the nature of web design. And you always have to evaluate which trade-offs are acceptable to make in order to reach your final goals, be they getting a website launched quickly, building the foundation for future website growth, getting information out there in a timely and efficient fashion, or some combination thereof.

And of course, the website is running on ExpressionEngine. For example, the photos in the upper-right corner are managed by the photo gallery module. The list of ministries is coming out of its own weblog, and the other pieces of the website are individual entries in their own weblog as well. Which, IMHO, is yet another testament to EE’s flexibility.

Darren Hughes recently launched version 11 of his blog, Long Pauses—which, in and of itself, is reason enough to celebrate (put simply, it’s a great blog, especially if you’re the slightest bit a cinephile). But what I find particularly interesting is how Hughes has blended together disparate resources for this new version, including Blogger (here, I thought he was using Movable Type all this time), Tumblr, and Twitter.

I’ve always been a fairly simple fellow, and that has translated to the systems I use for web-publishing, whether for myself or for clients. Specifically, I’ve always liked to keep the number of systems used to a bare minimum—which is one of the reasons why I ultimately went with ExpressionEngine and its fairly open-ended, chameleon-like architecture (it can become almost anything I want it to be).

However, the past few years have seen a rise in the number of systems available for people to publish content and personal info onto the Web. These include hosted blogging apps (Blogger, Wordpress), tumblelog apps (Tumblr), micro-blogging apps (Twitter, the soon-to-be-dead Pownce), media-sharing apps (Flickr, YouTube), and of course, social networking sites (Facebook, Virb, MySpace). And, being the web geek that I am, I want to try them all out and see what cool things I can make out of them.

But so far, I’ve been somewhat hesitant to really use these other systems, due in equal parts to lack of need, lack of time and energy, and perception. Put simply, I don’t have a real need to use any of them, due in large part to my current preferred platform (and of course, necessity is the mother of invention… and implementation). Also, I have a hard enough time updating Opus and keeping tabs on the forums I frequent, much less updating my Flickr and Facebook pages (and I’ve yet to publish anything to my YouTube account, despite having hours of concert footage lying around).

And finally, so many of these systems have struck me, perhaps wrongly, as fairly superfluous, and not conducive to real, substantial conversation, whatever that might be (Twitter being the prime example). But as I’ve been exposed to these non-Opus systems more and more, and slowly found myself using them (specifically Facebook), I have found myself trying to figure out ways to integrate them into some type of unified workflow for publishing online.

With that in mind, I found this portion of Hughes’ announcement particularly interesting:

The variety of communications tools would be overwhelming but for the fact that my friends and I are engaged in what is essentially a single, extended conversation. It’s all come to feel perfectly natural. I suppose some tools (forums, long-form blogs) are more suitable for, say, serious debate than others, while Twitter is obviously more immediate and superficial. And Facebook—wonderful, addictive Facebook—is so damn good at social networking that it’s changed the way I use the Internet (despite my long-held resistance to it). Perhaps we could draw an analogy between these tools and the various types of conversations we have with local friends when we go out together for a long dinner, sit side-by-side at a book club meeting, or run into each other at the grocery store.

And therein, perhaps, lies the rub: this confluence of tools has been created and shaped by an already existing use. Hughes and his friends are simply using the tools at hand to facilitate what is already happening between them organically, as opposed to picking the tools and then trying to build the interactions (which sounds absurd, but believe me, it happens—and fails—all the time).

All of which reminds me of this 37signals-esque mantra: “it’s not about the tools”. This is something that I continually need to remind myself of, that I’m much better served trying to figure out the interactions that are already taking place and then picking and shaping the technology I use to fit them, which is a much more organic and enjoyable process than building something and hoping someone joins in.

Tinkering with new technology is fine—which is why I have (relatively unused) accounts on Virb, MySpace, Tumblr, WordPress, etc.—but going beyond that becomes a waste of time and energy, and distracts from the principle goal: publishing honest, thoughtful, and solid content.

I know I’m not the only one chomping at the bit to get theirs hands on ExpressionEngine 2.0, so any news about the new version and what it contains is welcome. So I was very excited to read the most recent entry in the EE blog, which chronicles two big changes/updates for EE 2.0.

First, the term “weblog”, which is used to describe the generic containers of data that make up an EE site, will be replaced with “channel”. This is a great idea, especially now that “weblog” has so much baggage with it. Because of its current usage, I think a lot of people assume that EE is only a blogging platform, when in fact, it’s much more—or at least, it can be much more.

And second, EllisLab is putting together one great big “example site” that will show off what is possible with EE, as well as serve as a learning resource (which will join all of the other great educational resources for EE).

I’m particularly excited about this, in part, because of a conversation I recently had with a co-worker, during which we discussed ways to make EE, and its capabilities, more concrete for clients. Explaining web technology in general to non-geeks is challenging, but it can be especially daunting to fully explain something as open-ended and flexible as EE. So I’m very glad that EllisLab is doing something about this, and with Erskine Design at the reins, I know it’s going to be something good.

So, while it’s not exactly the announcement we’ve all been waiting for—i.e., a release date—it’s still exciting EE 2.0 news.

Oh, and here’s some related trivia: Change.gov is running on EE.

Like many designers, I’m a big fan of whitespace. Where some folks might see emptiness and nothingness, I see atmosphere and elegance. When used properly, whitespace can add so much to a design, by spacing out the various elements and giving them room to breathe and do what they need to do—which results in a design that is more pleasing to the eye, easier to understand and navigate, and less overwhelming, even if that registers only on a subconscious level.

I’m also a sucker for good typography: for the pleasing arrangement of letters and the spaces between them, for the right use of right typefaces for the right jobs, for the use of type in lieu of “normal” design elements to communicate in ways beyond the actual words used.

Unfortunately, while it’s fairly easy to manipulate and master whitespace in web design, typography is trickier. Much of that is due to the limitations of the medium; at best, CSS gives designers only the most rudimentary typographic control. We’re basically limited to things such as font size, font weight, style, line-height, and letter-spacing.

Future versions of CSS promise more typographic control, but widespread support is still a ways off. So we’re basically stuck with rudimentary typography on websites, that is unless we want to use images for everything. (But there are so many things wrong with that approach, I won’t list them here.)

So what does all of this have to do with Astheria, Kyle Meyer’s website? Well, put simply, his site shows a stunning mastery of both whitespace and typography.

The whitespace is pretty obvious. Meyer gives the elements on his site—headlines, entry text, logo—plenty of room to breathe. And while there a few inconsistencies in his design’s grid, the grid layout nevertheless is so sharp, you could slice bread with it. His design isn’t centered, but between the gracious whitespace on the left and the very subtle background on the right, you’d never know it. Everything is nicely framed, but the framing and layout aren’t obvious or heavyhanded.

The only place where things get a little awkward is the Archives page (see above). The archives are sorted by month and year, and the spacing between the individual headlines represents the amount of time elapsed between their postings. Which sounds really cool in theory, but visually, it’s unbalanced and uneven, and a little odd compared to how rigid and composed everything else in the layout is.

As far as typography goes, he uses the ultra-big lettering that’s become something of the rage these days, but the mixing and matching of weights keeps the larger headlines from being overbearing. Furthermore, subheadlines keep the entries balanced. And a judicious use of color—I’m not normally a fan of pink, but it works well here—adds just enough of a splash to keep the white and grey from becoming too mundane.

Meyer writes a lot about typography and design—his articles on portfolio designs were especially convicting for me—and so it’s obvious that he practices what he preaches. All in all, this is a design that I love looking at, but what’s more, it challenges me to make sure that my designs are as elegant and refined as possible—be it in the whitespace, typography, or anything else.