How can data visualizations themselves become an interface? Which operators can be used to edit data records in a visually appealing way? The aim of the project was to conceive, design and prototype visualization interfaces on the basis of different data sets.
In this course we have dealt with the usable representation of Google data in order to develop an alternative interface to the many interlocking Google services.
The "Google Calendar" was regarded as the basis, which with its multitude of data from the past, present and future offers an optimal basis for displaying links between people, places, to-dos and more. However, these links are not present in the current Google display or remain hidden in the tabular visualization.
How might we
How can a display look like that connects the data from different Google services such as Mail, Docs, Sheets, Drive, Contacts, Tasks, Calendar and exposes their correlations to interact with them?
How can the visible and invisible tables in Google Calendar be resolved to reveal the networks they contain?
Analysis of Google Calendars
The first step was to break the calendar down into its individual parts and ask ourselves, what the future of a calendar could actually look like.
It was noticed that every view - whether month, week, day or list - always resembles a static table. The current tool already offers links, but they only become visible after interaction with an event or when creating an event.
It is noticeable that the individual appointments are also only a simple representation of different entities of a table. Currently, an entry in Google Calendar consists of seven entities:
However, the links between these entities are particularly interesting. An example of this is the route, which automatically results from two consecutive dates. Or the linked persons who work on the same file in the past or in the future.
You can also add Google Drive files and tasks manually and automatically import appointments into emails. However, the information architecture of the calendar will probably become considerably more complex in the future, so that the calendar in tabular form will no longer be up to date.
The user is increasingly relieved of the work of maintaining his own calendar, which is why the already existing links and networks are supplemented by many more and in the next step automatically interlocked. However, the question remains whether these will also be displayed in the interface.
Translated with www.DeepL.com/Translator
Mapping our calendar
To find out the operators needed for our visualization, Marius recorded every interaction with the calendar for a month. The thesis was that we found new interactions that we would otherwise have overlooked when using the calendar on a daily basis.
Within the month of May the calendar was called 45 times. 37.7 % of that were new appointments being created and 28 % of the time, the calendar was opened to check its data. For 15 % Marius used the calendar to change the times of appointments. The remaining 20 % are split into deleting an appointment, changing a location or changing a title.
Although the result was disappointing, it made it clear that the dispute about the operators was too early at that time. Nevertheless, we had a foundation that helped us make conceptual decisions during the visualization process.
In order to pair the obtained operators with real data, a mind map with one month from Marius’ calendar was created. The respective titles of the dates, their time, the persons involved and corresponding documents were mapped here. This visualization was the basis on which we created the later screens.
So we summarize the problem with current calendars: they are able to inform clearly about upcoming appointments. But the most interesting data is the links that can be drawn between appointments. So a daily routine consisting of title & time is functional, but does not offer efficient daily planning.
We want to solve the problem of the inefficient calendar in connection with other Google services. To this end, information that is already in the dark in commercially available views should be brought to light and thus offer added value.
Simply reinventing time. The representation of time and how time should run has led to the most intense discussions. We agreed that there should be three consecutive areas. On the left the past, in the middle an active area for the present and on the right a planning area for everything indefinable in the future. Freely floating entities ensure that the interface is loosened up and that the elements can be connected with each other over all times if required.
“Oh, that’s another table ...” Alternatively we developed a stricter wireframe using a grid that chronologically displays all events in the horizontal. How long an event lasts doesn’t matter in this version. In the vertical, each event is divided into the seven entities, which allows a simple comparison between the individual units. With the design, we—again—returned to a table, which is why we distanced ourselves from this representation and initially followed the freer approach.
Display data ≠ Read data. During the digital implementation, however, new rules had to be introduced to allow a certain readability for the freely floating data. So-called streams divide all data into categories - in this case “study”, “campus garden”, “private”. Entities that belong together are also joined together to form units. At this point, however, the result showed that this visualization generated too much redundant information, which meant that links were not clearly recognizable.
Wordcloud? Eventcloud! In order to solve this problem, we neglected the typographic elements on both sides in order to direct our attention to the middle and thus to the present. On the positive side, it can be emphasized that the generated data cloud makes the "now" area more visible and also the important links can be identified more elegantly. However, the representation has lost readability due to the separation of the entities from each other. It is not directly visible which event is currently important with which parameters.
Google Streams becomes a Dashboard. After these—and countless other iterations—we had the feeling to be running in circles. We introduced certain representations, discarded them afterwards and then used them again, because the new iterations didn’t work and only created new problems. To escape this dead end, we took our previous designs and dissolved them into their components to get an overview of our elements.
We then compared the results with our target definition. We looked at the most important network forms in separate windows and compared them in a common interface. The three areas that emerged made it clear to us that we demanded too much from a single interface. Too much free space leads to poor readability and too strict design rules prevent the display of links.
Back to the roots. Through this knowledge gain we focused on developing a new form of design. We came across one of the first wireframes, which seemed too grid-heavy and combined it with the "streams"-iterations. It was also important to us to reduce the entities to be displayed to a minimum. With the introduction of a map— which represents the entire day—each day even receives an easily identifiable overview.
Of course the focus on the representation of networks is still missing until now, but with the last iteration we have made an important step.
The whole project had a certain conflict of goals: the goal of the course was an operationalized data visualization. Our additional claim was to design this visualization as an everyday tool. The idea at the beginning was to replace the Google Calendar and to improve the integration of other Google services.
Through the focus on user-centered design, however, the focus has repeatedly shifted away from the actually interesting characteristics of our visualization, mainly the uncovered links between different entities. In addition, we were quickly intimidated by the edge cases that destroyed our systematic ideas. Although we were always pursuing new approaches, they often got stuck in the digital implementation after the first iteration. Interaction problems with the interface designs or the data made progress more difficult, so we first went for a solution to the interface problem than to try to design suitable representation possibilities for data. Here we have room for improvement.
The linking of the location-data worked better. In a usability and data visualization context, we were able to find a suitable solution that met our initial target description well. However, we could have extended this detailed elaboration of the connections to other entities as well, for example to the processing of documents and the persons associated with them.
Apart from that, we noticed a certain “David versus Goliath” mentality in the visual design of the interface — there is a good reason that most calendar tools offer very similar views; they are simply the most suitable for an efficient use of a calendar. This, coupled with the integration of new services, is a more complex task than we thought.
Many iterations cause frustration, but should not intimidate. The frequent changes of direction during the course of the course were frustrating — if we were able to solve a visual problem with elaborate methods and detailed sketching, many new problems occurred after implementing it. It would have helped to start from zero more often and not just go back two steps. So we stayed true to the first visual ideas, but we turned a lot of loops unnecessarily.
To perceive the indeterminacy in the design process as an opportunity. To get the methods learned in our previous studies out of our heads is not that easy - we have found it very difficult to get away from user-centered design and focus on free data visualization. Often we tried to solve interface problems with systematic—and thus restrictive—methods. The right approach would have been to approach the topic of data visualization with a new and freer direction. In short: work more agile in the future.
Especially with operationalized data visualizations, usability is not limited. A frequent point of discussion was the unclear boundary we wanted to draw between data visualization and calendar tool. Difficult was, that there should be a usability in the everyday handling of the calendar and the data should still be visible in the background in the visualization. A clear decision, early in the process, would have made a simpler design possible.
Focus on the most current appointment. The current or the next appointment is always in the center. The individual entities of the appointment are visually separated.
The timeline is the heart of Google Streams. Time runs from right to left, past events disappear on the left behind the current event. In the Timeline, zooming and moving at a different time is possible.
Places and routes are the most interesting link. By integrating the route from the current to the next appointment, a more precise daily planning is made possible in addition to the display of the location of all appointments.
Google Streams, in all its glory. For all events that do not have an exact time, there is the "Sometimes" section. ToDos, persons, ... are listed there. They don’t have an exact time, but move into the user’s field of vision when they are due.
Google Streams lives from interactivity. The data we want to display with Google Streams is complex. Through a given—but interactive—view we offer a focus that can be set by the user himself. The video shows the most important possible interactions.