Some professors have an malicious desire to assign group projects.

The inevidable problem with assigning group projects is aligning everyone's schedules for meetups. Attempts at finding reasonable meeting times are thwarted by someone's late night lacross practice or choir concert. This can easily degenerate into a verbal game of battleship. We need not be concerned about a group of three, but at five or six this becomes an serious issue.

Why not tackle this problem as an excuse to design a data visualization?

Every data visualization should begin with a question to answer. Succinctly, what times are people available?

But this question is more involved than it sounds. Do we want to know what times people are available, or unavailable? Do we want to find a time that everyone is available, or is a time that works for the majority okay? (If we want the former, our visualiation becomes binary.)

And then there's the use case where the group may need to find several hours of consecuitive time to meet, if possible.

Candidate Solution

So here's my solution, whipped up using HTML 5 canvas. (The live demonstration will generate random schedule values, unlike the static image below.)

This table combines everyone's schedules into one place, and uses both hue and size to represent availability. I chose to use circles instead of squares as the data points in hopes to convey a halftone effect. To further this concept, I use a larger size and a dark hue to represent high unavailability. A possible consequence of this double encoding is that the user may have difficulty distinguishing between “complete availability” and “a single unavailability” due to the small size and faint hue.

Perfect? Not at all. But it is certainly an improvement over the traditional and tiring alternative.

This porfolio has undergone several major revisions since its conception. The first involved the addition of a blog (and was inspired by a chocolate bar). For this latest revision, rather than creating a design around a theme or feature, I decided it would be better to create a design that would answer the question that all users should have when they visit this website for the first time. Perspective employers should be able to easily glean what this portfolio is all about.

"Categorification"

The centerpiece of the design is a categories (or topics, tags, subjects) section that appears on the right of the layout. A user is encouraged to navigate blog entries by a category that they find of interest. My mockup, made in Inkscape, shows the intent:

Categories are put into a hierarchical list form. Major categories are more prominently displayed, while their sub categories use a smaller font and weaker color for de-emphasis. This way, a user can quickly see the prevelant categories.

Major categories are sorted by popularity. (How we define popularity is another issue.) Order is a powerful tool because allows us to encode another dimension from our data and it helps drive what the user deem most important or pays more attention to. This is how economic price discrimination often works on airline websites selling tickets; putting the expensive and easier to get to tickets on top and putting the cheap (and harder to get to) tickets below.

Using Sparklines

I annotated each major category with a sparkline, a minerature data visualization that helps provide an overall gist, to show a category's popularity over time in juxtaposition with other categories (small multiples). This has proved to be a challenge, and remains to be implemented on this live blog.

Using sparklines poses two problems:

1. Determining the best data visualization. In my mockup, I used histograms. But perhaps line graphs provide for a better, simpler visualization.
2. Directionality of axes. We have made an assumption about the user's intuition. It may be more intuitive for a user to read the visualization from right-to-left.

(And then you have to worry about the time-popularity information will come from to generate these visualizations!)

Placements

The placement of the main section navigation bar was of much deliberation. To avoid competition with categorical navigation, the section navigation and the categorical navigation are placed along the x and y axes, respectively. This 2D positioning effectively makes a distinction between the two dimensions.

Potential Drawbacks

Hierarchical categories forces categories to artificially belong to a category. But does "Software Engineering" fall under "Design" or "Software Development"? Does "Data Visualization" really belong under "User Experience"? When are new major categories created instead of being sub categorized? What if a blog entry falls under several different categories? A user may intuitively expect a particular sub category to belong to one category, but fail to find it because of these sort of issues.

I encounter this situation all too often: The user is presented with two buttons where one has a focused (default) state and the other has a normal state. The difficulty is knowing which button is currently selected. This is not a problem if the user has a pointing device (i.e. a mouse) to help differentiate between the two. But this design poses a problem if it is interfaced with the directional pad of a controller. Moving focus between the two buttons with the d-pad will not reveal which button is being selected.

Fabricated Examples

Which button is currently being selected?

A pointer makes the button state much more obvious:

But this example does not necessarily need a pointer to make button state distinction less ambiguous:

Note how the above figure introduces a context which allows the user to deduce which the selected button is.

Of course, creating an interface that relies on context must be carefully thought out. For example, the loading screen of Battlefield Bad Company 2 (PC version) contains a single button for toggling whether the player wants to join a squad. It has a orange-yellow background color when selected and a white background when not. A player who has navigated through the rest of the BFBC2 game menus would know that orange-yellow dictates active and white dictates inactive. But if a friend is handed over the controls at the loading screen, this contextual information becomes void. They will have trouble correlating which color denotes which toggle state. And then, some players are forgetful.

Before the mainstream advancement to 3D games it was not uncommon to find games featuring the isometric perspective (a type of axonometric projection). Objects will appear the same size regardless of how far away they are, but it gives a perception of depth despite being 2-dimensional. Some refer to isometry as 2.5-dimension or pseudo-3D for this reason.

While the isometric perspective provides for an interesting art style and gameplay, it presents us with a few challenges. This came up when I was working on a video game that had no 3d backbone. In this particular world, players are able to explore a multitude of heights in an isometric environment.

Isometric Drawing Order

Drawing order of tiles and entities becomes important when working with isometry. When done incorrectly tiles or entities will be clipped by others. To ensure that they overlap correctly the game objects need to be drawn top-down. This is to say that rows of tiles in the back of the map (farthest from you) should be drawn before the tiles closer to you. (This TIGSource forum thread discusses some further potential clipping problems with isometric draw order.)

Isometry and Players

With isometric games that employ multiple layers, identifying the different layers may prove difficult for players. This situation worsens when tiles of different layers match up visually where a tile could belong to any two layers. The player may become frustrated that a path is unreachable even though it looks reachable. In the example below, how can the player tell what level their character is standing? Can the character move down or will it collide with a tile?

A solution would be to brighten the tiles of each layer. Consequently, this simulates a lighting effect. In the example above, you should notice a subtle increase color variance between the layers. Our character is standing on a tile which is slightly darker than the tiles in front of it. (This effect is very subtle.)

We can also outline the edges of tiles that have no neighbors in that direction. This proves to be a much more powerful solution. In the code used for the above example, we set it up so that each isometric tile knows its immediate neighboring tiles in every direction. With something like this already in place, it should be relatively cheap to determine which edges need outlining so that the edge is more obvious. Note that edges facing us do not really need outlining since these edges and their sides are already facing us.

Tile outlining can look awkward when we introduce ramp tiles. Ramps are essentially distorted rectangles where two nodes join with the bottom layer and the other two join with the layer the ramp leads to.

The problem lies with the distortion of the ramp. Ramps facing the player appear vertically elongated, and ramps facing away from the player are vertically squished. An outline x pixels thick will appear thicker for ramps facing the player and thinner for those that are not.

What happens if a character is completely covered by the map? Some games overcome this by showing an outline of the character sprite in such situations. Of course, in many cases outlining is more involved than taking the difference the character sprite silhouette and a larger one. For complex shapes, the technique described will not generate a uniform outline thickness. Alternatively the character sprite could be inverted to indicate the same thing.

This second solution does not sound like much of a solution: We could chose to ignore this problem completely. Level designs should reflect this decision so that this situation is impossible to create. Even if players could see their own characters, should we really burden players to interact with parts of the level environment they cannot see?