Perceptions of Time

Stuart Sierra (ss2806)

A Good Time

I have tried many computer-based calendars, but I always fell back on pen and paper. Google Calendar was the first calendar application that I actually used.

Much of the utility of Google Calendar (hereafter GCal) stems from the simple fact of its being a web application. I have a Macintosh laptop at home, Linux and Windows desktops at work, and a cell phone running Android OS. Having one calendar with the same information regardless of where I am or what device I am using finally makes it as ubiquitous as my old paper day-planner.

But I think there are a number of subtle design decisions that GCal got right that make it superior to other computer calendars.

What does a calendar represent? Not events; that's the mistake of most computer calendars, because events have characteristics that are easy to store in a database, such as time, duration, and place.

A calendar represents time. All of it. Although a scientist (or a programmer) might view time as a single, continuous stream — as computers do, counting the number of seconds since January 1, 1970 — our conventional view divides time into more manageable chunks.

In order to keep track of those chunks of time, we arrange them spatially. Next week is not adjacent to this week, it is “below” on the calendar.

I will focus on GCal’s weekly view here, because it is the one I use most often and the one I find most visually interesting.

Sensation. When I first open GCal, I see my week. Unscheduled time is white, scheduled events are colored. Immediately, the ratio of dark to light space on the screen tells me how busy my schedule is. The current day is tinted yellow, so I know where I am in the week; if there is no yellow band, I know that I am not looking at the current week.

One thing I cannot see immediately is what portion of the day I'm looking at, since the screen is not large enough to show an entire 24-hour period. It would be helpful to have a subtle color shift between A.M. and P.M., so that I have an immediate visual reference point. Instead, I have to read the hour markers on the left edge to know where I am in the day.

Distinction. As my eyes focus on the page, I see a grid separating the days of the week and the hours of the day. The grid is very subtle, as it should be: the hours of the day are not important divisions in themselves, they only serve as markers to guide the placement for events. Half-hour markers are even more subtle.

Segmentation. As my eye begins to resolve shapes, I see a colored block for each scheduled event. These blocks have some subtle features to aid recognition: 1) the top (start) of each event is a darker color; 2) the bottom (end) of the event has a short double bar as a terminator; 3) the corners of the block are slightly rounded; and 4) the border of the block is darker than the interior. All these features make it easier to see each block as a separate unit, even when they are quite close together.

Even better, each block is placed so that it does not overlap the grid lines dividing the hours of the day. And each block does not completely fill the horizontal space allotted to its column. This prevents a crowded schedule from becoming a solid mass of color; events and days remain distinct.

Recognition. This is a tough one. What does a scheduled event look like? On a physical calendar, it might be just a written word, or a scribbled circle, or even a brightly-colored sticker.

I will suggest, however, that the most accessible metaphor for events — or at least the easiest one to draw on a screen — is a post-it note attached to a paper calendar. GCal’s event blocks are not a perfect representation, but they’re not bad. We talk of scheduling “blocks of time,” and GCal draws blocks on the screen. Which leads us to...

Interpretation. Assume that at this point, I can begin to read text. I know that each block represents an event. The most important characteristic of an event (assuming I want to arrive on time) is when it starts. I might also want to know when it ends. The placement of blocks on an hourly grid is not precise enough to recognize times down to the minute, so GCal sensibly prints the start and end times at the top of each event block. The notation is abbreviated, such as “8p” for eight o’clock, just as I would write in a notebook.

Association. The next question I have about an block is “what?” I know when the event is happening, but I want to connect it with something I know is happening in the real world. When the block is large enough, GCal prints the event description on the block. When it’s too small; the start time and the event description appear in the block header. This can be seen in the “5:30p - chat” example above. Here, GCal is doing the best it can: computer screens (inexcusably) lack the display resolution of paper, so it tries to include as much critical information as possible.

Comprehension. There are two basic tasks associated with a calendar. The first is a query — “Where am I supposed to be next?” — and the second is to schedule a new event. GCal makes it easy to answer the first question, even without switching to the “Agenda” view that shows upcoming events in a list. In addition to highlighting the current day, a thin red line indicates the current time, providing a visual indicator of how “far away” the next scheduled event is.

But the best part of GCal’s event blocks is their behavior. Changing my schedule is as easy as arranging post-its on a sheet of paper. Events can be dragged to a new time, even a new day. The duration of an event can be changed by dragging the “handle” at the bottom of an event block. By clicking on an empty space on the calendar, I can type in a new event immediately. This is the chief advantage GCal has over other computer calendars: it is based, wherever possible, not on typing data into forms but on moving objects in a visual environment.

A Bad Time

The second interface I will discuss is also a kind of calendar, but with a different purpose.

This is the “browser” view of the room reservation system at Columbia Law School, where I work. The purpose of this view is to help find an available room for an event or meeting. The browser shows which rooms are in use on a single day at the law school.

Sensation. At first glance, the interface is very confusing: a mass of pale yellow against a white background. I cannot perceive any structure or pattern to the colored areas.

Distinction. The first feature I can make out is the rectangular grid. While it is suitably lightly colored, it still dominates most of the page. The lack of any variation in the sizes of the blocks makes it impossible to tell whether I should be reading the chart by rows (left to right) or columns (top to bottom). Furthermore, most of the vertical lines are obscured by the yellow reservation blocks, making it hard to follow them down the page.

Segmentation. The browser is particular weak in this area. Because there are no borders or other distinguishing features at the edges of each yellow block, nearby blocks blur together both vertically and horizontally. Furthermore, the pale yellow color used for the blocks does not stand out against a white background, making it hard to distinguish blocks from the page even when they are isolated.

Recognition. As I said earlier, it is difficult to imagine a representation of time that is not abstract. For an hourly view of a single day, the paper day planner is the best-known representation. In those planners, hours are almost always arranged vertically, from top to bottom. The room browser interface reverses that convention, putting time on the horizontal axis. Perhaps this would be familiar to an engineer or an operations planner, used to thinking of time as a linear stream of parallel processes, but it is probably alien to the secretaries and school administrators who have to use this system.

Interpretation. Once I have figured out that the horizontal axis represents time, I can begin to make more sense of the display. The yellow blocks are obviously scheduled events. But other than that, I don't know anything about them. They have no distinguishing features to separate, for example, classes from meetings, or weekly events from one-time events.

There is a lot of text, but most of it is useless — law school classes all have a course number beginning “LAW-”, which is all I can see. To find out what a given block actually represents, I need to hover the mouse over it to see a popup. Unfortunately, that popup is almost the same color as the event blocks, and does not even make clear which block I clicked on.

Association. A wider screen gives a slightly better view, but still only provides the most rudimentary information about an event, usually a course number. I would much rather know the name of the professor teaching the course, so I can connect that to professors I know and gauge how amenable they might to rescheduling a class.

The interface also fails to provide me with any information, other than seating capacity, about the rooms I am looking at. If I want to see the seating arrangement, media capabilities, or lighting of a particular room, I have to leave my office and go look at it to find out. The “filter” options in the upper-right corner are useless: they only filter by date, building, and (uselessly) time zone. I cannot search, for example, for a seminar-style room or a lecture-style room, unless I already happen to know which rooms are which.

Comprehension. Finally, this interface fails at the task it was designed for: helping the user find available space to schedule an event. A typical query for this system might be “Find a seminar room for thirty people, around lunchtime, on a Thursday, in March.” Answering that query using this interface will require: 1) figuring out which rooms are appropriate for a lunchtime seminar by visiting them in person; 2) finding the dates of each Thursday in March by consulting another calendar; 3) opening a room reservation browser for each of those dates; and 4) scanning the appropriate rows of the table to find an available time slot.

In effect, to use this system I must become the (visual) query engine. The interface only presents data, not answers. Once I have my answer, I can forget about clicking on the calendar to schedule my event. That requires an entirely separate form, which must be approved by a human administrator, a delay that can take several days.