The premise is that I’m posting somewhat interesting and original photos of Brooklyn and beyond at least once a week (for an indefinite amount of time, but at least 52 weeks).

city of steeples, from 52photos.tumblr.com

I’ve finally decided to create a space to not only showcase random photos I take while I’m out and about, but to give me a reason to take the photos in the first place. This is part of a larger effort to develop my creativity this year; I’m looking forward to adding more content as I go (hopefully not all of these will be from my phone camera)!

For the purposes of this post, let’s imagine we have a product review that can receive a letter grade rating (“A”, “B”, “C”, “D”, or “F”). The designers decided to have a bit of fun with this one and mocked up the rating area so that all grades are visible and grey. The grade letter rating of the product gets highlighted in this list with a color specific to the grade. This is something CSS by itself should handle, but let’s assume that for this post that we only receive the grade rating via javascript.

Here’s what the markup looks like:

<ul id="grade">
	<li id="A">A</li>
	<li id="B">B</li>
	<li id="C">C</li>
	<li id="D">D</li>
	<li id="F">F</li>
</ul>

One approach to writing a javascript function to handle this would be to check which grade is being highlighted, and set a “color” variable accordingly:

function highlightGrade(sGrade) {
    var element = document.getElementById(sGrade);
    var color;

    if (sGrade === "A") {
        color = '#009933';
    } else if (sGrade === "B") {
        color = '#009933';
    } else if (sGrade === "C") {
        color = '#ff9933';
    } else if (sGrade === "D") {
        color = '#cc0000';
    } else if (sGrade === "F") {
        color = '#cc0000';
    };

    element.style.backgroundColor = color;
}

The problem with the above example is that the color for each grade rating is hard coded within the function. Suppose that later on, someone decides to add an “C+” rating (or an “E”, for that matter). Better yet, imagine that the colors all change as well. You’d have to edit the original function and add/remove conditions to it as needed. While it isn’t hard to do so in this specific example, this is not a good coding habit to have – as complexity increases, functions get bloated and hard to maintain, and the possibility of reuse is thrown by the wayside.

This is where the idea of property maps come in – by storing all the possibilities for grade colors in an object rather than conditions in the function, we create a maintainable configuration outside the moving parts of the function:

/**
* "colors" is our property map
*/
var colors = {
    "A" : '#009933',
    "B" : '#009933',
    "C" : '#ff9933',
    "D" : '#cc0000',
    "F" : '#cc0000'
};

function highlightGrade(sGrade) {
    var element = document.getElementById(sGrade);

    element.style.backgroundColor = colors[sGrade];
};

Further Abstraction

As long as we’re considering abstraction, let’s think about the reusability of this function. We may have other elements we may want to highlight with conditional colors…

function highlightElementByCondition(sElementId, sCondition, oMap) {
    var element = document.getElementById(sElementId);

    element.style.backgroundColor = oMap[sCondition];
};

//calling it to highlight a letter grade (element, condition, map)
highlightElementByCondition(myId, myGradeLetter, {
    // property map
    "A"     : '#009933',
    "B"     : '#009933',
    "C"     : '#ff9933',
    "D"     : '#cc0000',
    "F"     : '#cc0000'
});

Of course, there are two sides to every design pattern – as always, it comes down to a judgement call. Are the conditions for a function unusually complicated? Will the conditions be likely to change? Does your function have wider applications than the specific problem you’re trying to solve?

If you make a habit of asking these questions while writing code, your coworkers and/or clients may thank you later.

The state of the web has changed considerably since people first started overriding default link styles. We have fluid layouts, frameworks, progressive enhancement, AJAX, accessibility standards, cloud applications, and the rumored death of flash in favor of standards-based development, but for some reason many websites still fail to give their users a way to see which links they’ve visited already. As usual, the devil is in the details.

A Webpage Is Just an Interface

We know that visited links can show us where we’ve been, but in the context of the page, it can also show us where we haven’t been (yes, this is important). Consider the success of reader applications like Google Reader. It gives the user a list of posts to read from RSS feeds, and allows the user to mark things as “read”, taking them off the main page of the application.

The interesting thing is that we have a mechanism for doing this on any webpage with just one CSS selector. While the web has benefited greatly from translating print design best practices to interaction design, we often forget the nature of the web as being an interactive medium (and we forget why our users visit websites in the first place). A website is just a human-computer interface for delivering content. The more that people realize this, the less we’ll all fret over each little pixel and underline.

Example: Visited Links as a Visual Checklist on nytimes.com

Using The New York Times website as an example, we can add a really simple CSS rule or two that leverages visited links to create a sort of “visual checklist” for what I have or haven’t read. Here’s a segment of their website, without any of the links visited:

The New York Times was smart enough to add a visited link style, although it’s subtle (most likely to preserve design consistency):

If we shift our thinking from visual design to interface design, this may not be the easiest way to discern visited from non-visited links. I’ll start by adding a simple CSS rule to clearly mark the link as visited:

a:visited {
    background: pink;
    font-weight: normal;
    color: #000;
    opacity: 0.3;
}

This is better, but the associated image is taking up space when we don’t really need it. Because images are often wrapped in links, we can again make use of the visited pseudo selector for images as well:

a:visited img { display: none; }

Note that in the above example, the next headline is brought into view. While I would argue that There is No Fold, bringing unseen content into view while fading seen content into the background noise is certainly a good thing.

Read All Over

It may seem trivial at a single link level, but the effect can be significant on a page full of headlines, links, and images. Here’s the before and after on the home page:

Before:

After:

But It’s So Ugly!

Ok, so my example may not be beautiful, but from an interaction standpoint I think it merits some exploration. Imagine that if this idea gains popularity, we’d see some design conventions eventually emerge just as we have with so many other things over the last 10 years. I don’t expect they would involve a pink background, but sometimes designers can surprise us.

Calculation and planning only get you so far; it’s time to begin creating again. If there’s anything I’ve learned over the last 6 months, it’s that I am my own worst client. It’s been an incredible relief to let go of certain expectations for my site, and get down to business writing content. Wish me luck.