Some recent listings are highlighted below.

Full-time (International)

• South London Web Designer at Down2Earth
• Stockholm Java-utvecklare at Unikum - Unikt lärande AB
• Rotterdam Senior Interactive Designer at Studio Dumbar

Full-time (U.S.)

• Anywhere CSS Zen Master at SmugMug
• Work from home Code Mechanic at EllisLab, Inc.
• Cupertino, CA iCal Software Engineer at Apple Inc.
• Cupertino, CA UI Engineer at Apple Inc.
• Los Angeles, CA Web Designer / Client-Side Developer at Casting Networks, Inc
• Los Angeles, CA User Interface Engineer at Synctree
• Palo Alto, CA Graphic Designer at Facebook
• Redwood Shores, CA Visual Designer / Production Designer at Navigenics
• Jacksonville, FL Multimedia Design at City of Jacksonville
• Laurel, MD Web Project Manager at LMD
• Brentwood, TN--Near Nashville Flash Expert Wanted at DaveRamsey.com, Top 5,000 US ranked website
• Chattanooga, TN E-Commerce / Social Networking Developer at MNDCreative, LLC
• Brooklyn, NY Interaction Designer at HUGE
• New York, NY Web Designer at Polar News Company
• Provo, Utah Web Developer at BYU - Harold B. Lee Library
• Bellevue, WA Social Application User Experience & User Interaction Designer at Livemocha

Freelance

• FLEX Developer at TEKsystems
• Senior Web Developer at Liquid Digital Media
• Social job site needs web designer with emphasis on User Experience at BizFavors

Speaking of freelance listings, the very same day the gentleman stopped me in the hall, I received this email from Katrina McKinnon of Motive Media (Australia):

I posted a freelance position on your site yesterday for 75 bucks. Within these few hours I have received a hundred or so responses -- a few of them exceptional, most of them good and only a few absolute duds. That's quite possibly the best 75 I've spent for a while. Thanks for making the service you made. I appreciate it.

Post a job or find one at Authentic Jobs.

At a former company, we delivered web-based marketing tools to distributors and consultants of network marketing companies. One of our biggest (and best) clients was Tupperware, purveyor of all things plastic. We were in the midst of a major upgrade to the software they licensed from us, and I figured the best way to understand our/their users was to become one of them.

So, with the permission of the company, I became a part-time Tupperware rep. I sold product online, I attended a really wacky rally with women screaming wildly about Tupperware as adrenaline-infusing tunes such as "We Will Rock You" boomed loudly from on-stage speakers, and I even handled a return from a mildly disgruntled customer who found me merely because I was the nearest rep in town.

In the end, I can honestly say I understood the user much better than before -- even as embarrassing as it may have been for me. (Though I happily admit I safely escaped holding any Tupperware parties at home.)

You? Can you top that?

Typography and typefaces, without a doubt, are two of the most fascinating aspects of visual design. Great designers can execute great designs with typefaces and nothing else, if required, and certainly if preferred. Design legends Saul Bass and Paula Scher have proved this many times over, and they comprise only a fraction of a very long list of luminaries who can wield type brilliantly.

Examples of great design using little more than typography are virtually numberless. Some of the favorites I've spotted recently include designs by John Arnor G. Lom, Coudal Partners, and NB:Studio, linked respectively:

But of all the work I've seen recently, few have captured my attention as much as that of Veer's Type City Prints. "Each portrays an urban facet, illustrated character by character with a typeface that evokes the image itself," Veer's website explains. "Illustrations are letterpressed onto archival, acid-free paper using brass dies mounted type high."

Absolutely stunning.

Inspired by Veer's work, I had the privilege of creating a Type City-esque design of my own for an in-house poster contest. Designed in tribute to one of the buildings that adorn the organization's headquarters (and one of the most compelling edifices in the state), the entire design was created solely with characters from the Bickham Script Pro and Engravers MT typefaces.

I'll speak more about the design soon, but for now I wanted to share a few things learned during my first attempt to design with type characters. Luckily, in the course of my project, I was fortunate enough to correspond with Veer's Justin Lafontaine, the talented designer behind the Type City Prints. (Correction: Christina Huber's artwork is also featured in the set. Thanks Anders!) Below is shared knowledge from our experiences.

1. Use characters from the subject's description. What better starting point and technique for conveying meaning than to use characters from the name of the building, location, object, or person? "The first thing I did was spell out the phrase, such as locations for the buildings, and copied it a few times at varying sizes in both upper and lowercase," Justin explains. "This gives you a really good palette to start from which you can quickly grab different sizes depending on what you need." (Regrettably, I learned about this tip only after I had made substantial progress, and therefore my design uses random characters and lacks that extra bit of meaning I could have given it.)

2. Take advantage of symmetry for both speed and beauty. For objects or buildings that are symmetrical, use symmetry to your advantage for creating the design with less effort. As Justin describes, "I usually built one side, then flipped it to complete the building." As a result, symmetry also enhances the aesthetics of your work. "The symmetry in these can be pretty beautiful."

3. Scale the characters to convey perspective. Justin: "In lots of them I used the scale of the characters to give the illusion of perspective, like larger characters closer to you, and smaller as they become further away. That helped a lot!"

4. Repeat sections whenever possible. This is probably the most important tip. You'll find sections of the piece which you've meticulously built can be copied and pasted elsewhere in the design, and the duplicated section isn't really perceptible without closer inspection. This is a real time saver. "All you need to do is some minor swapping, and it looks like a totally new texture," Justin adds.

5. Don't attempt this in one sitting. I take it back -- this is the most important tip. Not only is type character designing extremely time consuming, it's also monotonous work that requires a constant zoom in, zoom out dance to get things right. My design required a total of about 16 hours to complete. That's just two full-time days worth of work, but don't even attempt to do it two days back to back. Spread it out over a couple weeks to allow adequate time for correction, detailing, and simply to give yourself a break. (Mine was spread over three weeks.)

In retrospect, type character designing isn't for the faint of heart, but it's extremely gratifying if executed well. (A big thanks to Justin Lafontaine for sharing his advice!)

Swissmiss

If my header image is any indication, it should come as no surprise that I'm a fan of all things Swiss. (This is in part due to my being one-quarter Swiss, three-quarters Whoknowswhat.) However, selection for new partners isn't based on personal preference but instead quality of content. And Tina Roth Eisenberg's site has it in spades, with multiple daily postings covering an eclectic range of interestingness.

SimpleBits

Credentialed Dan Cederholm needs little introduction. Author, speaker, and occasional dodgeball superstar, I couldn't be happier to have Dan join the team.

The Big Noob

Proprietors of all things geek (and great design), Brad Smith, Ryan Sims, and Keegan Jones render it honorable for one to be labeled "Noob". Welcome aboard, guys.

This is the fourth and final article in the four-part series, "The Highly Extensible CSS Interface". Markup and images for this article:

• View the full demo
• Download demo.zip (all files)

Finally, we've arrived. This concluding article provides the full demo, as well as a bookmarkable site that gives you quick access to all resources mentioned throughout the series.

Additionally, what follows below are 8 benchmarks to measure the extensibility of your site or app. I certainly don't advocate that every site or app must comply with all of these benchmarks, but I do recommend trying to comply as best as possible with each of these when applicable to your project.

1. Translation

When I sat down to author this article, translation of all things was the first to come to mind. I suppose that's because it's been on my mind not only at work but increasingly as I realize just how global our economy is becoming.

Perhaps the easiest way to test for translation is to send your prototype through Google Translate. Here's what the demo looks like translated to Chinese (Simplified). Fortunately, a fringe benefit of bulletproofing is that elements containing text are inherently capable of accommodating changes to the length of the text that occur as a result of translation.

However, bulletproofing alone isn't always enough, as we must make smart choices about what will be image text and will not be as we design the layout. In the demo, only one phrase in the entire interface is image text -- the logo. The rest is HTML text. This was done specifically to make translation as easy possible, sparing ourselves from having to create a set of graphics with translated image text for every language our fictitious app may be translated into.

In the end, you'll have to decide on image text vs. HTML text based on the translation needs of your site or app, on how much typographic control needs to be retained through imagery and how much can be relegated to browser rendering, and so forth.

2. Text Resizing

This benchmark is fairly straightforward: Make it work for low-vision users, whose default text size may be different than yours. A general recommendation is to accommodate up to two sizes larger. You can also accommodate text sizes smaller than the default, but my opinion is that if a user chooses to go smaller than default, he or she accepts that things may not be legible anyway.

Testing for text resizing is pretty easy: Command/Ctrl + (in most browsers), and then analyze how elements containing text accommodate changes in text size. And if you'd like to explore an interesting technique for having the entire interface resize (not just text elements), check out Jon Tan's Em & Elastic Layouts with CSS.

3. Resolution Dependence

I've talked about resolution dependence extensively throughout the series, so I won't elaborate further other than to suggest you check out Richard Rutter's list of resolution dependence techniques, which he refers to as variable fixed width layout.

4. Images Disabled

This one's an easy step to overlook. Be sure to test how your layout renders in the absence of images, not only for reasons of accessibility but also to be sure background images have a supporting background color. In the example above, the Featured Member section is created with dark background images and white text. If I'd forgotten to add a dark background color, even though it's not visible when background images are present, I'd leave users with white text on white background when images are disabled.

5. Styling & Scripts Disabled

Disabling styling and scripts tells us if we've separated presentation and structure properly, which yields a variety of benefits, not the least of which are accessibility and alternate device rendering (e.g. mobile).

As Dan Mall pointed out in Part II, the goal as it pertains to scripting is unobtrusive JavaScript, or the separation of JavaScript from the markup and CSS layers.

Two Firefox plugins for not only easily disabling images, styles, and scripts but also for inspecting and manipulating markup on the fly are the Web Developer Toolbar and Firebug. I recommend you install both. Additionally, there's the IE Developer Toolbar (IE 6 and 7) and Safari Web Inspector.

6. Color Contrast

When you consider roughly 8% of the male population is color blind, you quickly realize a significant chunk of your user audience may have difficulty using your site if color contrast isn't properly tested. (As an interesting aside, I've had at least one color-blind designer on my team for nearly the entire length of my career.)

The utility I prefer to use for quickly assessing how color-blind users will see my interface is Color Oracle. It's free, very lightweight, and allows you to test color blindness in any software or window on your machine. Also give Pabini Gabriel-Petit's thorough article a read: Ensuring Accessibility for People With Color-Deficient Vision.

7. Rebranding

Those of you who develop software that is licensed to other companies who in turn rebrand your software as their own will know what I'm talking about here. Inherent in the practice of web standards -- and the practice of extensibility -- is the ability to "reskin" an interface fairly easily.

To see what I mean, uncomment the following line of code in the demo to see a simple rebranding of the interface:

<link rel="stylesheet" href="css/branding.css" type="text/css" />

Again, this rebranding is rather minimal, but the point here is that by properly separating structure and presentation, changing the skin of an interface is relatively easy. Of course, you can really reskin the same markup by changing the CSS rather wildly, as demonstrated by the css Zen Garden project. My example pales in comparison, but hopefully you get the point.

8. Mobile

Lastly, I'd be remiss to skip mobile when speaking of extensibility. Regrettably, this demo is not a stellar example of mobile extensibility, as I've not had time to create a mobile-friendly version of the interface. I got lucky with iPhone (picture above) only because of the resolution dependence built into the interface, which works surprisingly well on iPhone. But if I had the time, I'd explore options for mobile adaptation, context, and all the other stuff you can read about in my book.

Signing Off

And so the series comes to a close. Before leaving, it's worth stating these benchmarks are not all-inclusive. There exist other benchmarks that may be considered, but the ones I've presented here I feel summarize extensibility fairly well.

Thanks for participating in the series, either as innocent bystander or active participant. This is your last chance to call me out on anything that's wonky or misleading, so please do so. Otherwise, happy extensibilitying.

This is the third article in the four-part series, "The Highly Extensible CSS Interface". Markup and images for this article:

• View the demo
• Download ajax.zip

This third article documents the underlying components of Ajax, examines a few examples of Ajax in the demo, and wraps up with a shout-out to resolution dependence.

Before we begin...

I repeat the disclaimers from last time: One, this interface is optimized for any browser that supports standards exceptionally well. Sorry, no IE6 support. I'm relying on you to make concessions on your own for IE6, thereby allowing this series to focus on what's possible with browsers that support standards exceptionally well without being bogged down in the mire of those that do not. (Again, consider conditional comments for IE6 concessions.)

Two, there are a few known “bugs” in the interface for which small inconsistencies will be seen from browser to browser. These will be documented as comments in the final markup (to be provided in Part IV). For this article, be aware that IE7 ignores the negative absolute positioning on the right corner image for the Latest Community Activity and Community Snapshot headings. I welcome any suggestions for fixing this.

Lastly, another hat tip to Aaron Barker who wrote a lot of custom jQuery and Ajax scripting for this demo.

Ajax

What was penned a couple years ago as a preface to describing Ajax design terminology is still relevant today:

The line between "desktop UI" and "web UI" is gradually blurring. Love it or loathe it, "Ajax", which originally referred to Asynchronous JavaScript + XML, has somehow become the catch-all term for describing "desktop-like" interaction on the web; more accurately, GUI interaction as seen previously only in native applications running in an operating system environment.

When I first spoke about Ajax in a workshop 18 months ago, few raised their hands when asked if they had experience developing sites and apps that employed Ajax. If asked that same question today, it's likely half of that same audience would raise their hands. Indeed, love it or loathe it, Ajax has weaved its way into high-profile sites and weekend projects alike as the de facto standard for producing rich interactivity on the web. (It's worth noting, however, Ajax's position as king of the hill is increasingly challenged by emerging technologies such as Adobe Flex and Microsoft Silverlight.)

Ajax implementation typically includes at least three components: 1) asynchronous server communication, which is most commonly accomplished via XMLHttpRequest, 2) manipulation of the Document Object Model (DOM) for dynamic display and interaction, and 3) JavaScript to bind everything together. The 'x' in Ajax refers to XML, but Ajax can also also be accomplished with (X)HTML, the result of which is often termed AHAH.

Asynchronicity is the key component of Ajax -- or any rich internet technology, for that matter -- as it provides that "native app" feel within the web environment. Instead of the traditional request/response model that fetches an entire page with a full trip to the server, asynchronicity means we fetch data for only a select portion of the page, e.g. username availability when registering an account, "without interfering with the display and behavior of the existing page" (Wikipedia).

In the demo interface, we fake asynchronous server communication with a little JavaScript and by fetching data from a few static PHP pages:

• activity.php for the Latest Community Activity section, which functions like Digg Spy with the help of jQuery Spy
• ajaxStuff.php for mimicking the Ajax request for the bio's edit-in-place feature in Part II (adds a spinner image and a one-second delay to mimic server retrieval)
• search.php and jquery.autocomplete.js for the search field auto-complete (Part II)
• project.js for the Community Snapshot and Latest Community Activity sections, edit in place, and overall scripting wizardry

Faking asynchronicity merely allows you to download the code samples and open the interface on any machine running PHP, without requiring true server communication.

As an example of how these components come together, let's have a look at the Community Snapshot. For starters, we begin with markup: A div encloses the map as a background image, and styling sets the containing block to relative positioning:

<div id="map"></div>

#map {

  position: relative;

  margin: 0 auto;

  width: 277px;

  height: 155px;

  background: url(../img/map.gif) no-repeat center center;

  }

It's important that the positioning be set to relative as this will allow the "n members online" boxes that fade in and out to be positioned absolutely according to the map's containing div. To accomplish this effect, we use a list item with several elements and CSS properties:

<li class="l1" id="map1">
  <p><strong>North America:</strong> <span>n</span> members online</p>
</li>

#map li p {

  padding: 5px 0;

  line-height: 100% important;

  font-weight: bold;

  background: url(../img/maploc-bg.png) no-repeat;

  }

#map li strong {

  display: block;

  float: left;

  text-indent: -9999px;

  }

.l1 {

  background: url(../img/maploc-btm-left.png) no-repeat bottom;

  }	

Let's break down each of these:

• <p></p> - This is the wrapper for our content. While it'd be nice to keep our markup as lean as possible with just the li, in this instance we need to add an extra element to aid with extensibility (text resizing/translation) by breaking the box image into two, which I'll describe in a minute. A paragraph seems the most semantic solution rather than a meaningless div.
• <strong>North America:</strong> - Notice that for sighted users, the region text ("North America") isn't shown in the yellow boxes that fade in. In the spirit of extensibility, we're considering sightless and alternate device users for whom the list item's location relative to the map isn't visible. Therefore, the idea here is that the location is provided in text rather than in geographical reference. So, we're effectively "throwing" the text off the page using the text-indent property and a negative margin great enough to put the text outside the visible area of even the widest screen. display: none would accomplish the same, but some screen readers will ignore any text hidden with display: none. Of course, it's questionable whether a screen reader would even pick up this text, as DOM refreshing isn't always rendered properly by screen readers. (Note: The span element is a hook for jQuery to insert the number dynamically.)
• class="l1" - We construct each yellow box with two images (top, bottom) specifically to allow for text resizing and translation. The top, maploc-bg.png, is much taller than needed for the default text. This is to accommodate a larger font size or an increased character count caused by translated text. The bottom, maploc-btm-left.png or maploc-btm-right.png, creates a nifty comment bubble thing and aligns to the bottom of the paragraph element. Depending on the box's position on the map, class="l1" requests -left.png whereas class="l2" requests -right.png. Admittedly, class="l1", which is short for "location 1", is not the most semantic selector declaration, but it's arguably better than class="left" should the positioning be something other than left or right in the future. (Remember class="arial red 10" in Part I?)

Finally, markup that isn't shown here but is shown in the demo, we set the absolute positioning of each list item:

<li class="l1" style="position: absolute; top: 10px; left: 20px;">

Recall that we set the position of #map to relative. Any element that is a child of #map, in this case li, will be positioned relative to the containing block of #map rather than the body or other parent element. Therefore, this list item is positioned 10px from the top and 20px from the left of #map. (Note: I've set this style inline for the sake of instruction. Ideally, you'd want to dynamically insert the positioning as each yellow box is generated.)

Once the markup is in place, we begin adding scripting that allows for Ajax magic to make a graceful entrance. Ironically, the Community Snapshot section isn't a good demonstration of Ajax components because we're totally faking things here by randomly creating "members online" numbers rather than pulling them from a database. Let's shift our focus instead to the Latest Community Activity section to wrap up the discussion. But before we do, throw your mind back to Part II and take a look at the jQuery scripting we've added to fade the yellow boxes in/out:

function nextSnapshot(){
  ...
  $("#"+curID).hide("slow");
  ...
  $("#map"+curNum).show("slow");
  ...
  }

Look familiar?

So, the Latest Community Activity section is a better representation of Ajax as it fetches data asynchronously from a secondary source, activity.php, our pseudo database. As is the auto-complete for search (Part II), which fetches data asynchronously from search.php, another pseudo database. In both cases, we manipulate the DOM either by replacing elements in the document tree or by adding new ones. Finally, JavaScript in project.js and other files inside the /scripts directory bind everything together, rounding out the three components mentioned earlier.

I indicated in the series opener that a primary objective of this third article was the demonstration of judicious Ajax usage. While some of the interactivity demonstrated here could be discounted merely as eye candy, be aware the demo interface for this series was in fact derived from an actual project, the likes of which I'll mention at the conclusion of the series. Some of the ideas shown here are based on actual prototype UI features, the sum of which aimed to improve the flow and speed of the interface, while others aimed to provide a very real glimpse into what was happening at that moment within a given community. Thankfully, my former client and good friend has been kind enough to allow me to repurpose certain elements for educational purposes, for which I'm appreciative and hope you are, too.

Additional Ajax reading:

• Ajaxian.com
• Peachpit: How to use AJAX
• SWiK: Useful places to use AJAX
• DHTML Site: Ajax Tutorials and Scripts
• Dr. Web: AJAX, DHTML, and JavaScript libraries
• Thinking and Making: Best Practices: Implementing JavaScript for rich internet applications

Resolution Dependence & Miscellany

This third article is much lengthier than I anticipated, so I'll try and wrap things up quickly. I can't conclude without revisiting resolution dependence mentioned in Parts I and II, as the interface in this demo tricks out the content based on browser width. Resize your browser and watch how the arrangement of Latest Community Activity and Community Snapshot completely changes to adapt to the available screen real estate. Values that allow for this adaptation are contained in 1024.css, and re-read Part I to understand how resolution dependence works.

There's also a couple child and adjacent selectors at play, and these are documented as comments in the HTML page and screen.css.

Finally, Mark James' Silk Icon Set is used throughout the interface, but there are many other icon sets you should consider purchasing for your project.

Done. Please pick apart the markup, code, UI, my grammar, you name it. I'm all ears.

"Padded lampposts are being trialled ... in Brick Lane [London] after it was found to have the highest number of 'walking and texting' injuries in the country." Update: It was a publicity stunt...

Dave Shea has hand-crafted a mobile device detection script that includes iPhone and TV browser sniffing, among many other common devices. Available for public consumption.

MobileSafari is now the #1 mobile browser in the U.S. and #2 in the UK, claims Ireland-based StatCounter. (thanks, Clifton)

Google's visual inventory problem. "It's simple. As consumers shift to mobile devices, interface screens get smaller -- leaving less visible room for ads. Google, and other advertisers, run out of visual inventory."

Mobile Web Development by Nirav Mehta. I’m curious to see how the content compares to mine. I've got a copy on order.

dotMobi's DeviceAtlas, a comprehensive database of mobile device information. "Everything you ever wanted to know about every handset on the planet."

Abilene Christian University will be supplying all incoming freshmen an iPhone or iPod touch this fall. "Freshmen will use an iPhone or iPod touch to receive homework alerts, answer in-class surveys and quizzes, get directions to their professors' offices, and check their meal and account balances." Seems a little overly ambitious even from the perspective of a mobile zealot (ahem, me), but I applaud the initiative nonetheless. Related: acu.mobi.

Mobile applications, RIP. "The business of making native apps for mobile devices is dying, crushed by a fragmented market and restrictive business practices. The problems are so bad that the mobile web, despite its many technical drawbacks, is now a better way to deliver new functionality to mobiles." This was written prior to the iPhone SDK release, and the author acknowledges the impact it would soon have. That said, I have to agree with most of the arguments Michael Mace makes. (It should be noted Mace is former Chief Competitive Officer and VP of Product Planning at Palm.)

Sitepoint: Designing for the Mobile Web. If you've read any of my stuff this will no doubt be a review for you. In fact, much of the article's content seems strikingly similar to mine (series or book).

PEW Internet & America Life Project has published a report on Mobile Access to Data and Information (PDF) in the U.S. Among many other notable statistics is one I find pleasantly surprising: 9% of Blacks and 10% of Hispanics access mobile web content on a typical day, compared to 7% of whites.

The Nokia N82 promises sightless users the ability to "snap a picture of a menu, book, printed receipt or business card. Software on the phone processes the words on those items and reads the text aloud in a synthesized voice. The device can even let a blind person know if paper currency is a $5 or a $20 bill." Wow.

This is a good time to pause and put in a plug for An Event Apart New Orleans, April 24–25. Join Jeffrey Zeldman, Eric Meyer, Jason Santa Maria, Aaron Gustafson, Jeff Veen, Dave Shea, Andy Clarke, Brian Oberkirch, Aarron Walter, Stephanie Sullivan, Robert Hoekman Jr., and myself for two full days of banter and enlightenment. (I'll be presenting a reprise of Good vs. Great Design. Use code AEAMOLL and you'll save $50 off the purchase price.)

For me, this particular conference is important for two reasons: One, after three years of speaking at nearly two dozen conferences nationally and internationally, I've scaled back my speaking in 2008 considerably. AEA New Orleans is one of just two major events I've chosen to speak at this year.

Two, the location couldn't be better for a gathering of individuals who share a special concern for the needs and wants of others. By "others" we typically mean "users," but for this event I hope we broaden that label to include members of the New Orleans community, as well.

Got any ideas for how I, and possibly the other speakers, and possibly even the attendees, might give back to the community during our stay?

This is the second article in the four-part series, "The Highly Extensible CSS Interface". Markup and images for this article:

• View the demo
• Download selectors-jquery.zip

This second article provides an opportunity to dive deeper into markup and even a little scripting with the intent of educating the less experienced designer/coder, while furthering the knowledge of more experienced readers in the audience.

Before we begin...

Disclaimers! Of course. There are two. One, this interface is optimized for any browser that recognizes a reasonable number of the common CSS2 and CSS3 selectors supported among most browsers today. Yes, I'm speaking to you, IE6. You may kindly excuse yourself from this party. As I mentioned in a comment in Part I, I want us to explore newly supported selectors without inhibiting ourselves with IE6. All of you reading this are smart enough to make concessions on your own for IE6 as your audiences and projects demand. (For starters, consider conditional comments.)

Two, there are a few known "bugs" in the interface for which small inconsistencies will be seen from browser to browser. I'm okay with this and I hope you are, too. I've left these bugs in place because 1) I didn't have sufficient time to polish the interface perfectly when this was first created (nor since), and 2) I'm hoping you'll consider this a challenge to recommend ways to fix the bugs, thereby improving the final interface.

Moving right along, let's begin.

Selectors

So what about these newly supported CSS2 and CSS3 selectors I keep mentioning? Well, by "newly supported" I specifically mean IE7 (and now IE8), as Firefox 2.x or newer and Safari 2.x or newer have supported them for some time. Among the most notable are probably min-width and max-width, attribute selectors, adjacent sibling selector, child selector, and alpha-transparency in PNG images.

Lest you're confused which selectors are which, download a copy of this Selectors Cheat Sheet:

If you're at SXSW or An Event Apart New Orleans, come grab me for a finely printed copy free of charge.

I've made comments throughout the markup and CSS calling out selector examples in this and subsequent code downloads, but I'll take time here to point out just one of them.

The attribute selector eliminates the need to add a class or ID to an element by referencing any attribute used in the element as a hook: type=, title=, src=, etc. This comes in handy in a variety of situations, but probably the most useful is with forms. Styling elements in the CSS with input {} leads to all elements within the form being styled, when in most cases you're targeting text fields only, the submit button only, and so forth. You're then relegated to adding superfluous classes and IDs to do so.

The search field and button, shown in the first image at the top of this article, serve as our attribute selector example:

<form id="search" action="">
  <input type="text" name="search" id="search-query" title="Search" />
  <input type="image" name="submit" src="img/search.png" />
</form>

Here we'd like to modify the input image (search.png) so its vertical alignment is even with the input text field. Normally this would require adding a selector hook, but notice the absence of a class or ID selector within <input type="image">. This is because we can target the image using the type attribute, and we do so like this:

input[type="image"] {
  vertical-align: middle;
  }

Any input element containing the attribute type="image" will be vertically aligned in the middle. In this case, it's the search button. (Note: The search field requires an ID for the autocomplete plug-in. One could argue we skip the attribute selector altogether and just add the vertical alignment to the search field, as it already has an ID hook. But keep in mind I'm demonstrating possible uses for attribute selectors.)

The attribute selector is one of several CSS2 and CSS3 selectors to be explored, and the brevity of this article doesn't provide freedom to explore them all. Consider perusing "Newly Supported CSS Selectors in IE7" by John Gallant and Holly Bergevin, as well as this selectors example and accompanying slides (included in the .zip) in which you can uncomment styles in the HTML head one at a time and view the effect they have on the content.

jQuery

Back in December 2005, I predicted the following:

I've been able to get by the last few years with my measly JavaScript skills, you know where you just copy and paste existing scripts? Yeah, those skills. That'll change in 2006. The traditional role of "web designer/developer" will add JS/DOM to the existing XHTML/CSS mix. Those of us with sorry skills will expect to see a copy of Jeremy Keith's DOM Scripting under the tree this Christmas.

I was a year or two early with my prediction, but by now it's safe to say we're required to know at least a minimal amount of scripting as a designer or front-end coder. For those of us reluctant to fully embrace the art of writing JavaScript, say hello to jQuery.

Karl Swedberg and Jonathan Chaffer's very useful Learning jQuery describes jQuery as a "general-purpose abstraction layer for common web scripting." I like to think of it as "JavaScript for scripting noobs like me." jQuery enables you to do the following:

• Traverse the DOM
• Modify the appearance of a page
• Dynamically alter the content of a page

And it allows you to do all this without writing lines and lines of JavaScript.

Let's pick apart a sample from the demo to understand the components of jQuery. We'll use the "Dismiss" button in the yellow disclaimer bar at the top of our demo.

Here's the code we add to the button's anchor tag:

$('#alert').slideUp('slow');

And here's a description of each component:

• $() - The basic jQuery construct (or function) that's used to select parts of the document. In this example, we're selecting an element with the ID of alert.
• .slideUp - A jQuery method, one of many. Methods are essentially a shortcut for lots of JavaScript. It's pretty obvious the method slideUp makes the element we're targeting (#alert) slide up.
• ('slow') - A pre-defined string that defines how the method functions. In this case, it tells the element to slide up slowly.

This code can be added either inline or in a separate .js file (or dynamically), the latter being the more optimal method. But here's the real kicker: I didn't have to come up with any of the code above on my own. The construct, method, and string came pre-built with jQuery. I just had to know I wanted the element to slide up slowly, and then I looked up the appropriate references in the jQuery library that corresponded with the animation and movement I was seeking. Boom. Done.

It's worth noting jQuery isn't merely a cheap tactic for adding bells and whistles to an interface, though unwise use of it can thwart its intended utility much like any technology. Rather, jQuery is intended to be a really easy way to add useful interactivity to a site or app. In fact, jQuery is used throughout the interface in this and subsequent demos: jQuery autocomplete plug-in for the search field, the bio's edit-in-place feature, and the slide up/down animation when clicking Your Toolbox. See project.js and jquery.autocomplete.js in the scripts folder included in the download. (Special thanks to Aaron Barker who wrote a lot of custom jQuery and Ajax scripting for this interface!)

Additional jQuery reading:

• Official jQuery site
• Visual jQuery (a list of jQuery methods)
• Digital Web Magazine: jQuery Crash Course
• Simon Willison: jQuery for JavaScript programmers
• Web Designer Wall: jQuery Tutorials for Designers
• Noupe: 50+ Amazing jQuery Tutorials

Extensibility

We couldn't close this article without highlighting the series' theme, that of adaptable interfaces. This article's demo demonstrates the power of text extensibility throughout the interface. Try increasing the text size (Command/Ctrl + in some browsers), and give it a pass through Google Translate by translating the interface to another language such as Chinese. I plugged Dan Cederholm's Bulletproof Web Design book in the series announcement, and I'll plug it again here: Many of the underlying techniques for "bulletproof" text shown in this interface are covered in Dan's book.

Pay particular attention to the Your Toolbox button. I won't take time here to break down the markup used for the button, but you can view a button sample and accompanying slides that describe how things work. (These files are also included in the .zip.)

Also demonstrated in this article is resolution dependence, a continuation from Part I. Notice how the width of the search field changes as the browser width expands and contracts. This is done to allow additional space for all text as the width contracts, while increasing the field size for those with larger resolutions. The next article will expose several tricks for resolution dependence that dramatically alter the content and presentation. (Search field width and other resolution-dependent values are specified in /css/1024.css.)

Whew, that was more than enough to cover in one article! Suzanne and I are headed to Austin tomorrow and will hopefully meet some of you in person, and we'll return to the series next week with Part III.

Oblige me, if you will, and allow me to ask you a few questions. It's related to the Extensible CSS series but also to another topic I'm dealing with.

1) How is your current role defined: Designer, Coder, or both? Freelancer or part of a team?

2) Do you agree with the statement I've made on occasion, that those who can code as well as they design will always have an edge over those who do only one? (See #3.) Or do you believe it's better for designers and coders to specialize in one role?

3) Is it more "productive" -- a team can take on more projects, get projects done faster, or however you define productive -- to have a single team of designers/coders or one team of each? In which scenario are the resulting user experiences produced "better" (however you define better)?

Feel free to briefly answer any or all of the above questions.

This is the first article in the four-part series, "The Highly Extensible CSS Interface". Markup and images for this article:

• View the demo
• Download foundation.zip

Throughout the duration of this series, we'll be speaking extensively about markup -- XHTML, CSS, and a little scripting. Marking up a website is akin to speaking Spanish. There's more than one way say something, and there's certainly more than one way to code something. (¿Puerco, cochino, cual es?)

As you plumb through my code, I'm hopeful you'll see things that you might code differently or even improve upon. Or put more plainly, I expect you to call me out on things that deserve refinement or just plain suck. After all, we collectively better ourselves as a community by exchanging ideas and opinions for approaches to problem solving, and markup practices are certainly no exception. Fair enough?

Meaningful, Lightweight

When drafting markup, the factors I consider most important are that it be as 1) meaningful and as 2) lightweight as possible.

When we say "meaningful" we mean the HTML elements and selector names we choose appropriately represent the content in such a way that if we were to experience the web with all styling removed, the hierarchy and structure of the content would still make sense. Long gone are the days of spacer gifs and repeated br elements (with which some of you reading this may not even have experience), replaced with elements which logically, or semantically, represent the content:

• An ordered list of top-selling items (ol)
• The principal heading on a page (h1)
• A quotation from a happy customer (blockquote and cite)

This approach requires that we remove presentational information from our thinking, a concept described comprehensively by Andy Clarke in his remarkable book, Transcending CSS. I still vividly recall my early experiences with CSS as we coded a rather large-scale web application, thinking we were cleverly creating a series of presentational class names that allowed us to mark up content with elegant clarity such as this:

<p class="arial red 10">

…only to endure a painful day of reckoning when the application required a redesign, whose 500 templates were to become anything but red Arial 10px type. I can has do-over?

When we say "lightweight" we mean marking up our content with the fewest parts possible for all things markup -- elements, attributes, and values for HTML; selectors, properties, and values for CSS. For example,

<a href=""><span class="icon">Map</span></a>

is minimized as

<a href="" class="icon">Map</a>

Also,

border-width: 1px; border-style: solid; border-color: #000;

becomes

border: 1px solid #000;

You'll see numerous examples of meaningful and lightweight markup throughout the series, few of which I'll pause to explicitly explain. So take time on your own to make note of these. (And again, call me out when you see things that can be more meaningful and lightweight.)

Finally, because the theme of this series is extensibility -- designing and coding in such a way that the interface is as adaptable as possible -- the beauty of a meaningful approach is that it inherently helps set the stage for creating an extensible interface.

Let's examine the demo example by diving into some of the foundational code.

reset.css

When I first began coding CSS-styled sites several years ago, it was common to declare a few "global" styles at the top of the master style sheet: body, a img, h1,h2,h3,h4,h5,h6 etc. What was done back then as a means of overriding the default styles of any given browser eventually evolved into today's practice of using a "reset" style sheet, typically named reset.css.

As stated by the team at Yahoo, a reset style sheet "removes and neutralizes the inconsistent default styling of HTML elements, creating a level playing field across A-grade browsers…." If CSS frameworks such as Yahoo Grids or Blueprint are your thing, each of these come equipped with a reset style sheet built in. Alternatively, you can roll your own or use one written by others in the community.

I personally prefer Eric Meyer's Reset CSS, and this is the reset style sheet used in the demo for the series. (Note: The demo CSS was written before Eric's January 2008 version of Reset CSS and therefore uses the May 2007 version. I've not gone back to update the CSS to adopt his latest version. Notes about the subtle differences can be found here.)

I use a single style sheet, master.css, to "import" any number of style sheets for a site. I declare the reset style sheet first, thereby allowing any style sheets that come after to override the reset styles as needed:

@import url("reset.css");
@import url("screen.css");
@import ...

All styles for screen display are then listed in screen.css.

Resolution Dependence

Herein begins one of the first components of extensibility: An interface that adapts to different display sizes (or browser widths). Perhaps the easiest way to accomplish this is to create a fully fluid layout (width: 100%;), which can accommodate virtually any display or browser width. However, fluid layouts create wide, illegible line lengths on larger displays, among many other issues.

However, to reap the extensibility benefits of a fluid layout while accounting for issues such as line length, we need only to set limits for the maximum and minimum width of our layout. I first demonstrated this technique in the fictitious Tuscany Luxury Resorts layout created for CSS Mastery. Expand and contract your browser's width, and watch how the layout expands and contracts but stops at 740px and 1200px. This is accomplished using the max-width and min-width properties.

Because IE7 wasn't publicly available when this site was created more than two years ago, and because IE6 ignores the max-width and min-width properties, the markup required a nasty hack to target IE and force it to replicate max/min-width using a JavaScript extension.

Welcome to 2008. Although IE7 market share isn't dominant enough to write off IE6 entirely just yet, we can at least begin to explore interfaces that leverage the many CSS2 and CSS3 properties now supported by IE7. And of course, these newly supported properties include max-width and min-width -- no need for nasty JS hacks.

We'll talk more about resolution dependence in Part II, but for now we'll add a few lines of markup and a couple scripts to start the process. To do so, we'll use Cameron Adams's excellent Resolution Dependent Layout technique. First, we reference two scripts in the HTML <head>:

<script type="text/javascript" src="scripts/event_listeners.js"></script>
<script type="text/javascript" src="scripts/resolution.js"></script>

Second, we add an alternate style sheet which the above scripts will import as the browser width expands and contracts beyond 1200px and 750px, respectively:

<link rel="alternate stylesheet" href="css/1024.css" type="text/css" title="1024 x 768" />

Notice that this style sheet is added to the <head> rather than being referenced by master.css.

Also take note that you can do the max/min-width thing without the need for Cameron Adams's scripts. However, we'll leverage his technique extensively to do some pretty sweet tricks with the content and navigation elements in Part II Parts II & III. But for that, you'll have to wait another week. Peace out, yo.

It's been nearly three years since publishing a series of articles on this site. I've got an irresistible yearning to publish anew.

Introducing "The Highly Extensible CSS Interface," a four-part series of how-to's and savvy conversation to be published in the coming weeks, with the first article debuting this week. The phrase "highly extensible" is in reference to designing and coding interfaces that are flexible enough to adapt in ways the designer or developer may not foresee when handing off coded templates, while still retaining the overall aesthetic integrity of the layout. I hope you come to discover extensibility as being broader than just "bulletproofing," though bulletproofing is certainly a significant part of it.

Here’s what to expect:

• Part One: The Foundation
  This first article will briefly discuss the importance of producing visually rich interfaces with semantic, accessible, and portable markup underneath. We'll then dive into code with a reset stylesheet and structure for a resolution-dependent layout.
• Part Two: CSS Selectors & jQuery
  Shifting to a more intermediate discussion of code, this second article will present examples that demonstrate how to take advantage of the now-supported CSS2 and CSS3 properties previously ignored by Internet Explorer, such as min/max-width, child and adjacent sibling selectors, and others. We'll also take a look at jQuery, a lightweight scripting library for enhancing UI elements.
• Part Three: Adding Ajax Interactivity
  The third article will lightly cover Ajax implementation and its role within the interface. This won't be a highly technical discussion that covers such things as XMLHttpRequest, but rather a demonstration of a few ways to leverage Ajax judiciously.
• Part Four: Testing for Extensibility
  Lastly, the final article will look back at the chunks of code presented in the three previous articles to assess how they combine to produce a completed interface. We'll then subject the interface to a series of "extensibility tests" such as translation, text resizing and browser width resizing, the addition of new content, and so forth.

Code samples will be available for viewing and downloading with each article. Much of the discussion will be based on material and a demo interface created for a recent workshop, the likes of which you can preview by clicking this screen capture:

See you back here in a couple days.

I'll be publishing something substantial here on an unrelated topic next week and therefore don't have adequate time to do a full write-up right now, but I promised I'd share a few things I learned from the experience. Herein I keep the promise -- unedited, unspellchecked.

• Unless you're a text-savvy teen, texting is an absolute pain with a numeric keypad, even with T9 (predictive text) enabled. My texting activity dropped significantly the last week. QWERTY keypads -- iPhone or otherwise -- are a necessity in my book.
• No music. None of my other phones are set up to do music, mostly because it's a pain to do so. I lugged around my video iPod as a replacement and it was apparent having a phone that also doubled as an iPod -- a veritable iPod and not a ROKR gadget -- was rather convenient.
• iPhone's screen performs really well in direct sunlight. A couple of my other devices were hardly discernable in direct sunlight.
• The ability to lock or sleep the phone with one button (the top one on iPhone) is really convenient. Most others require at least two keypad clicks, and it's usually a cryptic combination to try and remember.
• I didn't actually miss the browsing experience as much as I expected I would, perhaps because most of my phones are set up with Opera Mini, and a number of the sites I visit with a handset are mobile-optimized anyway. I did, however, do considerably less browsing, which may very well contradict what I just wrote.
• Surprisingly, I found that having all menu options available from the home screen is incredibly helpful. Most phones require you to click a "menu" button to see these options, and even on some phones the menu option is not always intuitive. Further, having a screen large enough to accommodate text labels beneath icons is really helpful.
• Two big takeaways: One, the week-long experience was clearly a reminder that handset manufacturers have spent far too much time on hardware research and development, and far too little time on software & UI research and development.
• And two, and I shamelessly admit this, the "cool factor" or whatever you might call it is unbeatable with an iPhone. There's nothing better than being in public, having white iPod earphones on, and suddenly taking a call only to see the other passengers on lightrail wonder why you're speaking to yourself. I occasionally slip the iPhone out of my pocket to end the call, even though this unnecessary, merely to ratify that I am indeed a sane, and unabashed, consumer.
• Finally, while the overall experience was much less satisfactory compared to the iPhone, I was reminded that most consumers throughout the world carry handsets just like those I carried. This is a two-edged sword for someone who's both a consumer and a content provider. Consumers can expect the bar to be raised for all phone manufacturers since iPhone's inception, which excites content providers, but in the meantime these content providers must cater to a broad spectrum of devices.

Experiment concluded. iPhone utility unequivocally verified.

So, I've had my XO laptop for nearly two months now. Over this period, I've used a few apps, browsed the web occasionally, and watched my sons (ages 2-7) use it. This article is an attempt to compile a coherent, albeit brief, report about the overall experience -- form factor, interface, data input, and so forth. Let's begin with the good.

The Good

It's as intriguing as an iPhone. And by that I mean, whenever I pull it out, it seems to draw a crowd. Those who've heard of it are excited to see it. Those who haven't assume I'm carrying a Fisher Price toy but quickly show interest once they discover I'm toting a full-featured laptop.

The camera is quality. For a $200 device, the embedded camera, which functions as photo camera and video camera, is really impressive. I haven't exported any pictures yet, but the clarity and response time seem better than even embedded iSight cameras.

The Measure Activity app is a hit with kids. Measure Activity is an app that, among other features, provides a visual display of audio waveforms via mic input. This usually results in kids screaming as loud as they can to see as large a wave as possible. One evening I found myself teaching the boys about things such as amplitude and pitch by having them make a variety of sounds and seeing the resulting waveforms on screen.

The OLPC effort is truly laudable. I applaud Nicholas Negroponte and his vision of bringing educational tools to developing countries. Even if the XO doesn't stick, he's raised the bar of approaching and delivering higher learning for developing countries. As the Economist puts it,

Ultimately the OLPC initiative will be remembered less for what it produced than the products it spawned. The initiative is like running the four-minute mile: no one could do it, until someone actually did it. Then many people did.

Shifting to the less laudable, I present the not-so-good.

The Not-So-Good

Fitts' law is often ignored. I need not delve into a discussion about Fitts' Law, as I assume many of you are aware of its assertions. What's disheartening about the XO is that scrollbars, checkboxes, and a few other UI elements are terribly small and difficult to target with a trackpad mouse -- small fingers or big. Consider the browser scrollbar, easily less than half the relative width of scrollbars in Windows or OS X:

The only saving grace in the example above is that the scrollbar is always pinned against the right side of the screen, effectively increasing the virtual width substantially. However, the height isn't much larger, and it's still a difficult target.

More input mechanisms than necessary. Three trackpads and two mouse buttons? For children who've never used a laptop, no less? I can't understand this decision. The OLPC wiki describes the dual-mode potential of the trackpad, but the only part functional out of the box is the middle portion.

Further, there's no tactile feedback around the edges of the middle trackpad, and I find myself often leaving the center area to the left or right and wondering why the mouse no longer works -- until I glance down and see I've left the middle area. A subtle raised line on either side perceivable by touch would be enough to correct this.

As for the two mouse buttons, this is a fallacy attributable only to the experienced PC users who developed the hardware and software. Observe as my four-year-old son uses the XO for the first time and attempts first to use the trackpad as a giant button, second to click the left and right mouse buttons until discovering the correct one:

Did you catch me being thrown off by the two buttons, as well? The MacBook's single-button trackpad would have been the obvious model to follow here.

Whose idea was "hot corners"? Seriously, this was a downright terrible decision. Hot corners, or activating UI functions when moving the mouse into one of the four corners of the screen, interrupts the current screen display and presents new options to the user. Mac users will recognize this feature if they've activated screen corners for Exposé.

For experienced users, hot corners can benefit workflow greatly. However, for inexperienced users, it can disrupt workflow substantially. We've seen this as non-Mac user candidates have come in for interviews and we've lent them one of our Macs for presenting work, only to watch them stumble repeatedly whenever they inadvertently hit a screen corner. (We usually have to disable Exposé because of this.)

Watch the video above again. Around 1:07, while the camera is on Isaac's face, he activates a hot corner and the dock-like menu shows up at the bottom of the screen. He then struggles to return to the application he's in. You'll then see me struggle with it, as well.

Ajax chokes the browser. I can't access Ajax / JS-heavy sites such as Netvibes on my XO, as it usually kills the browser. This isn't a problem of the device per se, but rather of the content provider. It's a reminder to consider the limitations of the device requesting the content when developing web experiences for non-desktop machines. (Think mobile here, too.)

Conclusion

There's been plenty of acclaim and disdain in the press regarding the OLPC effort, and I don't know enough yet about the device or the organization to warrant taking sides. However, I share the woes of many who've not received their XO, having ordered a second shortly after the first and it still hasn't arrived. Thus, before we can overly concern ourselves with user experience, let's hope these devices are reaching the audience for which they were intended.

Yesterday I announced I was giving up iPhone for a week, returning to a less feature- and experience-rich phone to see what I miss out on. Today I've got the Sony Ericsson K750, one of eight phones I own (pictured second from the top above).

I'll post a report sometime next week when it's over. In the meantime, anyone know where I can get an iPhone patch -- you know, one of those sticky things you put on your arm? I fear I'll begin trembling soon.

In other news, Nokia and Sony Ericsson are releasing devices that appear to be targeting would-be iPhone buyers, the Nokia N96 and Sony Ericsson XPERIA X1. Early Android prototypes are beginning to surface, Texas Instruments is testing in-device phone projectors in its labs, Best Buy is among the most recent of U.S. retailers to release a mobile version of its site, and so on and so forth.

Is 2008 finally the year of mobile, specifically mobile media? (Better begin studying if so.)

15 Feb: For the next few days I'm switching to the Toshiba 903T, a handset that was sold primarily in Japan after its release in 2005.

18 Feb: Today I'm pocketing the Nokia 6680.

19 Feb: Back to the Sony Ericsson K750 today.

22 Feb: The debriefing.