This spring, the Orton Family Foundation decided to have us revise the site, to help address some functional concerns, adapt to feedback from users, and refresh the look and feel. (Under-the-hood, we also migrated from Zope to Pylons). A key part of the aesthetic for the new design was really pushing the book metaphor as much as possible. I wanted to share a couple of peeks into how we incorporated that mandate into the new design. (For another take on this project, check out this writeup).

For most pages, we ended up going with a very literal book metaphor:

For comparison, I’ve taken a shot of the original version.

We had a hard time making the homepage fit the open-book design, and ultimately opted for a very different layout:

The book metaphor carries over to the “stack” of almanacs, which are displayed edgewise. (For the sake of thoroughness, I’ve also posted the previous Community Almanac homepage).

Fun with Error Pages

Some of the most fun aspects of this project involved finding small ways to reinforce the book metaphor without being totally over the top, or working against the needs of an online application. Two of the pieces I’m particularly happy with are the error pages.

For the 404 (Not Found) page, we kicked around a couple of ideas, before hitting upon the idea of using the book image but with several pages torn out:

Once we’d come up with the design for the 404 page, the 500 (application error) page was a no-brainer:

Error pages in general don’t get a lot of design thought or attention, and these are probably the best error pages of any website I’ve gotten to work on. That’s not to say they’re the only interesting or cool element we’ve added to this relaunch – for bonus points, once the site launches this week, check out what happens when you turn the page.

In themselves, pieces like these are fairly minor. But nailing the details can help a good design become really great. We may not have been able to add every cool idea in this iteration, but I’m pretty proud of the work our team has done, and am excited to see it go live this week.

The crash reports looked like this:

Process:         Safari [700]
Path:            /Applications/Safari.app/Contents/MacOS/Safari
Identifier:      com.apple.Safari
Version:         3.2.3 (5525.28.3)
Build Info:      WebBrowser-55252803~5
Code Type:       X86 (Native)
Parent Process:  launchd [205]

Interval Since Last Report:          311 sec
Crashes Since Last Report:           1
Per-App Interval Since Last Report:  284 sec
Per-App Crashes Since Last Report:   1

Date/Time:       2009-05-26 09:04:32.111 -0500
OS Version:      Mac OS X 10.5.7 (9J61)
Report Version:  6
Anonymous UUID:  92C09E73-C6B0-4A8B-AA5F-46F13FF83479

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
Crashed Thread:  4

I tried everything I could find, including trashing my Safari .plist file, and multiple runs at repairing permissions with the Disk Utility.

I eventually noticed that there was an alert message on the Safari preferences pane below the [ ] Warn when visiting a fraudulent website option option, indicating a problem pulling updated data from Google. Unchecking this option immediately resolved the Safari crashes.

Additional digging after the fact turned up this thread on Apple’s forums. I was able to confirm that this was also my problem. I was able to cause Safari to crash again by re-enabling the fraudulent website option. However, once I deleted the SafeBrowsing.db file (mine was in /private/var/folders/Gh/Ghnj4FQ2EjeLtxPyNkIUVU+++TM/-Caches-/com.apple.Safari/), Safari would run without any problems.

So, if Safari starts crashing with EXC_BAD_ACCESS errors, your SafeBrowsing.db file may have gotten corrupted. Fortunately, the fix is just to delete the existing one – Safari will create a new one the next time it’s opened (though it’s always prudent to create a backup first, just in case).

Hope this saves someone else from tearing their hair out.

Tara’s first book, the Whuffie Factor, was published this past week. It’s focused on social marketing, more participatory and conversational than traditional mass marketing (which by its nature tends more toward monologue than conversation).

Cory Doctorow coined the word “Whuffie” as a term for social capital in his excellent sci-fi novel Down and Out in the Magic Kingdom. In Cory’s book, social capital has completely replaced traditional currency, and people who are well-esteemed by others have privileged access to material goods. The Whuffie Factor takes this concept and grounds it in contemporary reality. Social and traditional capital aren’t interchangeable (at least, not yet), but they are strongly correlated, and businesses ignore this fact at their own peril.

At its core, the Whuffie Factor is a guide to social media for businesspeople, walking the reader through some of the more interesting highlights and opportunities, while helping them avoid missteps like the recent Pizza Hut Twitter intern ruckus. The tone is friendly and helpful throughout, without being condescending – if you think of it as a Lonely Planet guide for Web 2.0, you wouldn’t be far off.

Tara provides clear steps and caveats for companies wishing to engage their customers (and potential customers) online. She also does a good job articulating the rationale behind different practices. There is never a point where the justification for something is reduced to blindly following what other companies have done or hand-waving generalizations. Even admonitions to “embrace the chaos” are carefully illustrated by numerous examples. For embracing chaos, examples include the Library of Congress opening up their photo archives to Flickr, JetBlue having an active and honest dialog with passengers via Twitter, and Tara’s own experiences facilitating a sometimes-contentious conference on Bay Area transportation issues.

We may have fallen a little off the scorchingly-fast “internet time” pace of the early internet, but things still move quickly enough that the challenges of creating a paper product relating to an online medium intrude, as with the discussion of ma.gnolia.com, which had a high-profile collapse earlier this year.

What we think of as traditional mass marketing may turn out to be a minor blip – an artifact of the interval where media had progressed far enough to have wide reach, but not far enough to provide feedback channels for people to become co-equal participants, rather than simple consumers.

When Tara tweeted offering to send folks an advance copy of her book the Whuffie Factor to review I responded right away, though I didn’t expect to be chosen.

• I’m not a business person
• Virtually nobody reads this site
• I’m strongly introverted an not an “influencer” offline, either

The fact that she sent me a copy in spite of those considerations shows me that Tara definitely practices what she preaches. That earns her a ton of Whuffie in my book.

Current State of Affairs

Web folks are a clever bunch, though. If browser support for CSS won’t give us a way to target a particular element, a common solution is to make classes do the heavy lifting for us. Going through files to add class="text" to every text input is an all-too-common experience for web designers.

Adding the classes allows us to target elements on all browsers, but is labor-intensive and potentially error-prone. Moreover, if your site includes content (like comments or blog posts) which will entered by users, you have no easy way to ensure those classes are added appropriately.

A Glimmer of Hope

jQuery is one of several great javascript frameworks which have burst onto the scene in the past year or so. One of the reasons jQuery has gotten a lot of attention from web designers is the way it allows you to select elements – in many cases, jQuery selectors are identical to CSS selectors. jQuery is also extremely extensible. If there’s functionality you need which isn’t provided by the core framework, you can easily add it via a plugin (or by extending jQuery directly).

In the course of a recent project, I used jQuery to add a first-child class to some <li> elements in our top navigation, to shore up IE6 CSS support without having to alter the markup. After seeing how easy jQuery made that, I realized it’s be possible to write a plugin allowing any browser supported by jQuery capable of supporting all CSS 2.1 selectors. So I wrote SuperSelectors. It goes through your site’s stylesheets, dynamically adding classes to elements so that even IE6 can bask in the glow of properly supporting CSS selectors like ul li:first-child li:nth-child(odd) a:hover.

Pencils out

Before we can start to determine which elements ought to have classes added, we’ll need a way to access each stylesheet being used by a given page. Fortunately, the document.styleSheets array does exactly what we want. Unfortunately, we have to incur a little bit of overhead here. Since browsers will silently excise rules they don’t understand, we have to re-request the CSS files via javascript, and parse those for matches.

Now, the fact that jQuery supports CSS selector syntax comes in really handy. We can pass the matching CSS rules directly to jQuery, and add classes appropriately. Then, any browser supported by jQuery can properly target elements, even useful-but-not-broadly-supported CSS rules like ul li:first. All we need to do to have classes added to match any of the rules in our CSS is include jQuery and the SuperSelectors plugin, and add the following javascript:

$(document).ready(function() {
  $(document).superSelectify();
});

This is a great start, but some of us are maintaining sites with established conventions for element classnames. Maybe you’re working on an educational site, and the child is already reserved for another context. No problem. SuperSelectors will allow custom classes to be passed in, while still providing sensible defaults. You can override any (or all) of the default classnames. If you need to alter the class attached to child elements to be child-element, your javascript would just change to be:

$(document).ready(function() {
  $(document).superSelectify({childClass: "child-element"});
});

Attribution needed

What about special cases which fall outside the normal advanced selectors? Maybe we need to have styles applied conditionally, based on attributes. For example, maybe the links in your file download list should have an icon based on the extension of the file they’re pointing to. CSS 2.1 allows us to target elements based on attribute values – we can even match against substrings within the attribute value, which is a perfect fit for finding the file extensions of our links. The number of potential choices for attribute selectors alone is more than we can reasonably build into a single plugin, but fortunately SuperSelectors supports arbitrary selectors through the additionalElementHash attribute. This can be done with or without overriding the default classnames. A setup which addressed the file-type requirement mentioned above would look like this:

$(document).ready(function() {
  $(document).superSelectify({additionalElementHash: {jpeg: 'a[href$=".jpg"]', pdf: 'a[href$=".pdf"]', doc: 'a[href$=".doc"]', gif: 'a[href$=".gif"]', xls: 'a[href$=".xls"]', png: 'a[href$=".png"]'}});
});

A little more effort than the no-argument invocation, but that will enable matching almost any elements you can think of – you’re only limited by jQuery’s selector support, which is one of the best out there.

Hovercraftiness

It’s probably time to acknowledge the elephant in the room – specifically, the fact that IE6 only supports the :hover pseudo-selector for anchor tags. Through the years, there have been a variety of approaches to add this in, including Peter Nederlof’s whatever:hover. This is all well and good, but it’d be nice to be able to have one-stop shopping for all our CSS needs. Fortunately, jQuery makes it easy for us to add this functionality into Super Selectors. Declare your :hover rules normally, add an equivalent rule using the hover class, and SuperSelectors will take care of adding / removing the classnames from elements on mouseover.

Faster, faster

Things are really shaping up nicely. Any browser which jQuery supports can now use virtually any legitimate CSS selector, but we can still do better. If we know which advanced selectors our site will need to support, it seems wasteful to have to re-request all those CSS files, and then scan them for matches. In fact, on slow connections, or with sufficiently-large amount of CSS, users could see a page without the added classes for a fraction of a second, similar to the old Flash of Unstyled Content bug.

SuperSelectors makes it simple to avoid the unnecessary request/parsing overhead and display properly-classed markup right away. You just need to pass in all your selectors via the manualSelectors attribute, as a comma-delimited list. As with everything else, it can be used solo or in combination with any other arguments.:

$(document).ready(function() {
  $(document).superSelectify({childClass: "child-element", manualSelectors: 'div.example > ul, ul.sample li:first, input[type="text"], input[type="password"]'}});
});

For complex CSS needs, this may require a fair amount of work. However, this approach saves us from having to re-request and parse all the CSS files in use. Consequently, it will be much faster – especially for sites with large (or large numbers of) CSS files. Check out the example.

One caveat

SuperSelectors does a lot to help enable better CSS selector support across browsers, but it can’t do everything for us. We still need rules in our CSS which use the classes SuperSelectors will add.

Because Internet Explorer will discard the entire rule if it doesn’t understand one of the selectors, we do have to do a little duplication in our CSS. That means that, instead of

div.example > ul,
div.example ul.child {
background: #0f0;
color: #f0f;
}

You should write:

div.example > ul {
background: #0f0;
color: #f0f;
}

div.example ul.child {
background: #0f0;
color: #f0f;
}

In Closing

The goal of SuperSelectors is to make it possible for all of us to start using CSS 2.1 selectors in our everyday work. It doesn’t have CSS3 support (yet), but SuperSelectors will automatically benefit as jQuery adds support for CSS3 selectors.

You can download SuperSelectors as a zip or tarball. Github also hosts the official SuperSelectors repository, if you’re interested in helping make SuperSelectors even better.

The HTML

<div class="expand">
<h2 id="expand-an-element" class="toggler">This will be clickable, once the javascript runs</h2>
<div class="togglee">
  <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed sapien. Phasellus nunc. Vestibulum consectetur tortor eu urna. Donec quam. Vivamus id neque a nisl iaculis vulputate.</p>
  <p>Multiple elements can be contained within the <code>togglee</code> parent.</p>
</div><!-- /.togglee -->
<h2 id="expand-this-element" class="toggler">Another toggler element</h2>
<div class="togglee">
  <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed sapien. Phasellus nunc. Vestibulum consectetur tortor eu urna. Donec quam. Vivamus id neque a nisl iaculis vulputate.</p>
</div><!-- /.togglee -->
</div><!-- /.expand -->

Note: the expand, toggler, and togglee elements aren’t limited to the example above – they can be any valid HTML element. The only assumptions are that the expand will be a parent, and that each toggler immediately precedes the associated togglee element.

The CSS

.expandable .toggler {
cursor: pointer;
}

.expandable .togglee {
display: none;
}

You can also apply styles to the toggler element by targeting the expanded class. This will only be added to togglers which are currently expanded, which allows you to provide visual cues about the fact that it’s an active interface element.

The javascript

$(document).ready(function(){
  $('.expand').addClass('expandable');
  $('.expandable .toggler').click(function() {
    var target =  $(this).next('.togglee');
    if (target.is(':hidden')) {
      var togglees = $('.togglee');
      for (i=0;i<togglees.length;i++){
        $(togglees[i]).slideUp().prev('.toggler').removeClass('expanded');
      }
      $(target).slideDown().prev('.toggler').addClass('expanded');
    }
  });
  var initialExpansion = "";
  if(document.location.hash) initialExpansion = $(unescape(document.location.hash));
  if(!(initialExpansion.length)) initialExpansion = $('.expandable .toggler:first');
  initialExpansion.addClass('expanded').next('.togglee').css("display","block");
});

We use document.location.hash to access the portion of the URL beginning at the hash sign (#). Then, if there are any elements with a corresponding id, we apply our expand logic there (falling through to showing the first panel if there isn’t a match).

This allows us to construct links like http://example.com/path/to/page#expand-this-element, and have that panel begin in an expanded state.

Use and enjoy. If you have feedback or improvements you’d like to see, note ‘em in the comments.

One of the challenges we’re working through is how to provide better ways to guide users through the ladder of engagement: to move from passively viewing the site, through providing feedback on content, all the way to being a leading participant and real resource for the Community Almanac.

It is difficult to hit that sweet spot, where the site manages foster the kind of behavior and interactions it wants to encourage, without making users feel like they’re being herded like cattle, or that they don’t have meaningful choices. LinkedIn does a good job of this with their progress bar, but that didn’t feel like a great fit for a more collaborative project like the Community Almanac. Earlier today I had an idea which seemed promising – since I’m not sure whether my idea is too radical for this project, I wanted to braindump it here.

In short, I wanted to hijack the metaphor of achievements used in the gaming arena (XBox Live and Steam are two of the best-known implementations). Here’s a screenshot of an achievement list for Team Fortress 2, a recent game available on Steam:

The unattained achievements scroll down off the page. This provides clear guidance to users about what they need to do to ‘advance’.

In the context of gaming, achievements are bound to behavior which the games want to foster, or which is challenging to complete – or in some cases, both. Achievements are a way for gamers to be rewarded for good gameplay, and to show off their accomplishments to others (for example, I know anyone who has attained the Little Rocket Man achievement in Half-Life 2 is far more patient than I am, for example.

Now, there’s nothing inherent in this approach which is bound to video games, which is why I think it has promise for the Community Almanac.

I could easily see us having achievements created for behavior we want to encourage in the almanac, like:

• Add a new page
• Give feedback on ten existing pages
• Email a page to a friend

The titles probably ought to be more playful, but the tasks are the sorts of ones I think are good candidates. We could even have achievements be based on helping others become involved, like “have someone you’ve invited to contribute add a new page”. In the longer term, it would also be nice tie a reputation system to these achievements – and if we highlight that reputation in the interface, it provides a nice way to give regular contributors warm fuzzies and recognition, as well as help orient new users and steer them in a positive direction.

If we tracked task completion within a session (even for not-logged-in users), this could be a way to draw users into creating an account. Presenting messaging to users indicating that by doing X they just earned achievement Y, congratulating them and presenting the option to save this progress by creating an account (or by logging in to their existing account), would be a friendly way to help users move up the ladder of engagement.

Hopefully I’ll manage to make a compelling case, and you’ll see achievements coming to the Community Almanac soon. If not, look for me trying to fit this in to other projects – I think there’s some real potential here.

The design for the new site includes two drop-down menus (for “About Us” and “Our Work”), and we went with an approach based on the classic Suckerfish menus. Pretty easy to implement, and looked great in our initial design passes. When I went to do some regression testing, I found that Opera was was badly misrendering the menus:

All other browsers were displaying the menus as-intended (even IE6, due to a quick little jQuery function to add the relevant classes on mouseover).

As I was playing with possible resolutions to the problem, I stumbled onto an odd fact. The problem only appeared when the nav was aligned to the right. Floating the nav to the right triggered the renderbug, as did positioning it to the right. Unfloated navs behaved correctly, as did ones which were floated or positioned left.

For launch, we went with a left-floated nav, but that prevents the nav from reliably being aligned with the right edge of the parent container (since font sizes can be adjusted independently of page zoom).

After launch, I did some digging to isolate the problem, and to write up a bug report for Opera. I also came up with a test case illustrating the issue.

The problem only manifests when the dropdown menus extend below the calculated bottom of the content within the <body> element. Since all the content on the TOPP site was floated, and floated elements are removed from the normal document flow, Opera effectively thought the pages were zero-height.

Somehow, floating or positioning the nav to the right is tripping up Opera’s redraw logic for the dropdown menus, if those dropdowns extend below the calculated bottom. Why right-floated or right-positioned elements trigger this renderbug, while left-floated or left-positioned elements behave correctly is still a bit of a mystery.

I’ve written up my test case and submitted a bug report to Opera. Opera unfortunately doesn’t have good transparency into their bug-tracking process, so I can’t link to my report, and folks can’t upvote the bug, but hopefully it’ll be fixed before too long.

­Problem Summary

An element needs to support partial transparency – either an img tag, or an element with the background-image property set via CSS.

Use When

The page still needs to support IE6, and has elements which should be transparent.

Solution

Use CSS transparency, with appropriate selectors.

Example

CSS

* html .pngfix {
zoom: 1;
behavior: expression((this.runtimeStyle.behavior="none")&&(this.pngSet?this.pngSet=true:(this.nodeName == "IMG" && this.src.toLowerCase().indexOf('.png')>-1 ? (this.runtimeStyle.backgroundImage = "none", this.runtimeStyle.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + this.src + "', sizingMethod='image')", this.src = "transparent.gif") : (this.origBg = this.origBg ? this.origBg : this.currentStyle.backgroundImage.toString().replace('url("','').replace('")',''), this.runtimeStyle.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + this.origBg + "', sizingMethod='" + (this.currentStyle.backgroundRepeat=='no-repeat' ? 'crop' : 'scale') +"')", this.runtimeStyle.backgroundImage = "none")),this.pngSet=true));
}

Note: this method is adapted from the approach documented at http://www.komodomedia.com/blog/2007/11/css-png-image-fix-for-ie/. It improves upon it by using zoom to trigger HasLayout in IE6, rather than relying on position: relative.

You can either add the “pngfix” class to all elements which need to support transparency, or add selectors in your CSS file to target your desired elements. Prefixing the selectors with * html ensures that only IE6 will process the rule, preventing more-capable browsers from trying to parse IE AlphaImageLoader idiosyncrasies.

Limitations

This approach will not support repeated background-images – Internet Explorer will stretch the background image to fit. This can still be useful if your background is a solid color and you’re just using transparency for an overlay effect. It will also still be suitable if your background-image is full-width and has no vertical variation (for example, if you’re using a background image to fake columns).

Due to limitations with the AlphaImageLoader functionality, this approach will not work at all for elements which need to have the background image positioned. If that’s behavior you need (and you have to support transparency for IE6), you should consider adding an extra element and positioning that instead.

Problem Summary

An element needs to be expanded to contain all child elements, one or more of which may be floated (and thus removed from the normal document flow). ­

Use When

The page contains floated elements w­hich should not extend beyond their parent element.

Solution

Use self-clearing floats.

Rationale

While the “use a float to contain a float” approach will ensure that all elements are appropriately contained, it can trigger other renderbugs which this approach avoids.

Example

CSS

.selfclear:after {
content: ".";
display: block;
height: 0;
clear: both;
visibility: hidden;
}

.selfclear {
display: inline-block; /* IE 7 */
}

.selfclear {
display: block;
}

* html .selfclear {
height: 1px; /* IE < 7 */
}

Note: this method builds upon the approach documented at http://positioniseverything.net/easyclearing.html.