Calendar

Every year we need a different calendar and there are many different types that we see around us. To stay motivated and actually use them, we need them to be aesthetically pleasing. Some people prefer to print them on paper while others prefer to use software. Both have their advantages and disadvantages, so we can’t say that there is a right or wrong way to plan, as long as we balance between having no plans and overplanning. We also need to make sure that our plans stay flexible enough even when the need for change arises. This isn’t always easy and it requires that we are aware of our current rhythm, so we could anticipate whether we will be able to move synchronously with the time.

Calendars can show country-specific holidays and weekends, but this restricts their usefulness and is something to be avoided. They need to consider the needs of as many people as possible. Placing holidays that people don’t recognize and identify with will just drive them away. Any additional assumption about how a calendar will be used would further limit the circle of people who might benefit from it.

Before we create the calendar, we need to consider the view in which we’ll present it. Whether we show only a single day, but with all the fidelity a person might need to plan their minutes, whether we show a week of time so a person could think in blocks of available working hours, whether we show a whole month or even a year is a design choice, one that will most certainly depend on the personal preference and the biases of the creator. Choosing a “smaller” view means that we divide a calendar in many parts that will require user actions to get a combined feeling (think in terms of a sliding window). In many cases this works, but in many it doesn’t. Any time the user has to click without altering the calendar data can be seen as a waste. Once the number of actions exceeds a particular threshold, we could say that the calendar has become unusable. Good design ensures that the minimum number of interactions occur and that the user has always a good understanding of what they change. Having more content in one screen would minimize the number of interactions needed, but will at the same time increase the cognitive burden on the viewer. Using a combined approach, where we let users choose their view is an option that could balance the advantages and disadvantages of all available views. But constant switching between them can be distracting and time-consuming, which will stand in the way of regular work. If we want to minimize it and enable direct data manipulation, the yearly view may be our best choice. Since most people tend to plan only short-term up to a week or two, a yearly view can give everyone a better sense that there’s much more to life than today and tomorrow. It is uncomfortable and forces us to think of what the best way would be to fill all these days. It is about long-term thinking and the feelings of control and responsibility.

A useful property of a calendar is the emotional feeling that the passing of each additional day can trigger in us. Not all calendars can show well how our plans get “eaten” by an animation of approaching time in a way that we feel internally motivated to be faster in our plans and execution (and avoid living aimlessly). Such a progress indicator of time reveals how quickly the elapsed time can overpower the remaining one. Seeing how we are robbed of daily opportunities and how fast our life is getting “grayed out” might be inconvenient for many of us, but it is much better to confront this truth early rather than to stay indifferent.

Using a calendar shouldn’t take much time when we want to save it. Maybe it doesn’t even need a login form. If a person needs 15 seconds to login and then 30 seconds to type the today’s plan, then the login form takes 33% of the combined time, which is unacceptable. Many such products already exist, which is why we need to rethink how others will use our work. It always pays to make things as simple as possible.

Visibility is important for calendars (“out of sight, out of mind”). Something which isn’t seen, is less likely to be used. Having something in physical form around us can act as a constant reminder, which is why we need the option to print content, even when infrequently. Even a calendar that is intended for frequent use will face the competition of million other sites that will scream for attention. With best intentions and an inviting product, we still can’t be sure that people will be willing to come back again.

How the data is stored and retrieved will determine the usefulness of a calendar to a large extent. The data has to be easily accessible and modifiable at the same time. If it needs to be stored after each modification, this can quickly distract from it. We could transparently auto-save it on the user’s machine at frequent intervals avoiding additional actions beyond editing date contents. But then, we would rely on JavaScript and the user may have it disabled, in which case no data will be stored. We could store everything in a database, but then its maintanence could soon become a high cost factor and we’ll need a way to identify the user (possibly a login form) to decide which data to retrieve. We could also try to generate a file out of all entered data and ask the user to store it on his/her machine by also offering a way to import it back to the calendar only when needed. This could allow the calendar data to be transferred across multiple machines without the need for authentication (but for data transfer), which can be convenient. Import/export aren’t likely to be used very frequently relative to the time required for editing the data and the fact that the calendar is most useful when it stays open.

Although the calendar is a planning tool, it can’t replace our ability to plan. Even with plans and a good sense for the clock, we may still be unable to meet those plans. But even if our initial plans may fail, we may eventually get better over time.

I have tried to create a very simple calendar with some of the above options. Here are two screenshots—of the whole screen and a small slice of it:

Since the calendar shows an yearly view, it is better to view it on a big, high resolution screen (no mobile device support). It should be usable with both keyboard and mouse. Data is saved periodically to the browser at 5min intervals if JavaScript is enabled. The data export option could act as a complement if this isn’t the case. <Ctrl> lets you select multiple dates and manipulate them together. While this duplicates the data (which isn’t good), it doesn’t require additional logic to combine dates into larger box entities. A small problem you may notice is that the textareas don’t expand to fill the whole table cell height. This means that right now the textarea size is suboptimal. There are other problems too, but it would be nice, if possible, to get some feedback first before working on improvements.

bit.ly/OFiJ27