A Proposal for Playful Interactive Persuasion: The "Employees' Commute Calculator" (ECC) – Appendix (2): Ideas for a More Advanced Version

By Gerd Waloszek, SAP User Experience, SAP AG – December 20, 2011 • Original article

In this, the second part of my article about the "Employees' Commute Calculator" (ECC), I present ideas for a more advanced and hopefully more playful version. I would like to begin, however, by looking more closely at the requirements for the calculator, particularly with respect to offering greater flexibility in the way in which the data is collected and manipulated. I will then propose application modules that constitute the tools with which employees perform the various subtasks in the calculator. Here, I will also describe how these modules are represented in the simple version of the EEC, the E2C2, which I presented in the first part of the article. Finally, I will sketch a prototype of the EEC that represents these modules as rooms and is thus based on the room metaphor, which Kai Krause once explored in his regrettably short-lived Soap photo editing application.

 

Collecting Requirements for the ECC

To enable the ECC to answer questions such as, "How much carbon dioxide (CO2) will I save if I use my bicycle 75% of the time when commuting to work?" it has to be supplied with data about employees' personal commuting behavior as well as with general data:

  • Personal data (or estimates):
    • Employees might enter this data interactively, for example, using a map for defining routes or a calendar for defining how and when they commute – which is the more playful variant.
    • Or they enter this data into a simple form (as they do when using the E2C2 in part 1 of the article).
    • Examples are: distance from home in both directions; average fuel consumption and CO2 emission of their car(s); estimated car usage in days.
  • General data (or estimates):
    • This data should be provided by the ECC as a service to users. It might be retrieved dynamically from the company network or the Internet, or simply be "hard-wired" into the application (I discussed the update issue in part 1 of the article).
    • Examples are: CO2 emissions of power stations per kWh, CO2 emissions of means of public transportation like buses, trains, and trams.

The ECC will work with both precise data and estimates, because technically, there is no difference between the two. The tool might, however, offer an option for employees to flag results as estimates.

Further requirements comprise aspects that employees would be interested in exploring and how results might be presented to users. The table below lists initial ideas for these requirements, that is, the required data, the aspects that employees might want to explore, and – very crudely – how the results might be presented:

 

Parameters Specific parameters Comments
Means of transportation: consumption, emissions, costs
  • Fuel/electricity consumption
  • CO2 emissions
  • Fuel/electricity costs

Data:

  • Fuel consumption and CO2 emissions data for cars can be found in the vehicle specifications or on car manufacturers' Websites.
  • Energy consumption and emission data for other means of transportation can be found on the Internet or calculated from that data. Often, however, this data shows strong variations that are hard to resolve.
  • Costs depend on many factors and can be difficult to calculate.

Missing data should be provided by the ECC (hard-wired or retrieved from the company network or Internet).

Options that do not involve transportation like home office or that do not involve energy or fuel consumption like riding a bike or walking should be included.

Presentation:

  • Simple: This data can be entered into a simple form.
  • More complex: Each means of transportation is treated as an object with a "picture" and a property sheet for entering and storing the data.
Itineraries

Itineraries, a term that I will use throughout this appendix, consist of a combination of

  • Means of transportation
  • Routes or route sections

In the simplest case, a route is assigned to one means of transportation, such as a car (as in the E2C2). Alternative routes between the employee's home and the company can differ in means of transportation and distance. Employees may also use several means of transportation in the course of one route, for example: a bus to get to the train, the train itself, a bicycle for the remaining route. The concept of itineraries covers all these complexities and combines routes or route sections with means of transportation.

Users should be able to assign a symbol to itineraries and save them with names so that they can be recalled easily for later explorations.

Distance
  • Distance from home to the workplace for various means of transportation or combinations thereof

The distance may vary depending on the respective means of transportation or combinations thereof. It may also be different for both directions.

Presentation:

  • Simple: This data can be entered into a simple form (based on the employees' experience and/or publicly available data).
  • Detailed: This part of the application could be presented in the form of an interactive map.
Time schedule
  • Number of working days, including home office (taking account of vacations, illness, and so on)
  • Number of usage days for the different means of transportation

Presentation:

  • Simple: This data can be entered into a simple form (based on the employees' experience).
  • Detailed: This part of the application could be presented in the form of an interactive calendar (it might have a connection to a company calendar that takes account of personal and public holidays, illnesses, and other days off when calculating the actual number of working days).
Exploration
  • Compare different commute scenarios (car only, bicycle only, mixed usage, ...)
  • These scenarios can include forecasts for different usage patterns in order to optimize the usage of means of transportation

The tool should be easy to use and support exploration. For example, it should be far easier to use than a spreadsheet application (which might constitute the "back-end" of the prototype of such a calculator).

Results should be presented in real-time to stimulate exploration.

Users should be able to store simulations under a name and to compare these textually and graphically (two and more).
Presentation of results
  • Tabular
  • Graphical
  • Textual
 Traditional presentation modes comprise tables, charts, and textual descriptions. However, a more dynamic graphical presentation would be nice.


The ECC Modules

Considering the requirements that I have collected so far, it seems appropriate to compose the ECC of several modules between which employees can navigate:

  1. Module for defining (selecting) various means of transportation and for entering their environmental parameters
  2. Module for describing routes and itineraries for commuting to work
    Because the routes may differ for both directions as well as for different means of transportation, several routes usually need to be defined in this module.
    Furthermore, by assigning means of transportation to routes or route sections employees define so-called "itineraries" in this module.
  3. Module for assembling commute scenarios
     By defining a time schedule for a certain period of time (month, year) and assigning itineraries to them, employees assemble commute scenarios: A commute scenario describes when and how an employee commutes to work.
  4. Module for performing simulations on the basis of commute scenarios
    Here, employees simulate the environmental effects (and other effects like fuel/electricity consumption, cost, time effort) of commute scenarios by playing around with them one at a time.
  5. Module for comparing and presenting the results of simulations of selected commute scenarios
    Here, employees compare several commute scenarios as to their environmental effects (and other effects like fuel/electricity consumption, cost, time effort, ...).

All in all, the ECC does not look like a trivial application. For comparison, I would like to return briefly to the E2C2 that I sketch in part 1 of the article and explain how it relates to the modules proposed here:

  • Screen 1, "Enter Data for Transportation Means" takes over the function of the first two modules. Itineraries are defined by simply assigning a distance to a means of transportation – complex routes cannot be defined in the E2C2.
  • Screen 2, "Enter Time Schedules and Simulate Effects of Commute Scenarios" fulfills the functions of modules 3 and 4.
  • Screen 3, "Compare Commute Scenarios" is a simple implementation of the fifth module.

Next, I will sketch a proposal for an ECC that is more closely based on these modules.

 

Sketch of a More Advanced Prototype Based on the Room Metaphor and Using a Map and a Calendar

The route for a more flexible and playful version of the ECC that I would like to pursue here is to make use of the room metaphor – in the same way as Kai Krause pioneered this approach in the Soap photo editing application (see Figures 1 and 2). In this version of the ECC, each of the modules described above is implemented as a room that has a specific purpose. The "rooms" version of the ECC would be implemented as a desktop application first. Later, one might attempt to transfer the concept to a mobile app, although this might prove difficult due to the packed screens.

Lobby in Soap      Presentation room in Soap

Figure 1-2: Overview of rooms and presentation room in Kai Kraus's Soap photo editing application

Overview of the Rooms

Figure 3 provides an overview of the ECC's rooms:

ECC: Employees Commute Calculator
Vehicle
Room
Simulation
Room

Presentation
Room

Map
Room
Calendar
Room
Start in the vehicle room, go clockwise through the rooms and finally go to the presentation room. You can also switch between rooms at will.

Figure 3: Overview of the ECC's rooms

In the following, I will briefly describe the purpose of each room and present a schematic sketch of it.

Please note that, in contrast to the E2C2 prototype, the rough sketches presented below are initial ideas only and are not backed up by functional prototypes. Note also that I include instructions on the screens (rooms) to help readers understand what employees are supposed to do in a room. The final screens should, of course, dispense with instructions. Last but not least, in the final versions of the screens, employees might arrange objects in the rooms more freely, not as rigidly as in these sketches based on HTML tables.

Note: The sketches that I present as images below can also be seen in their original, non-functional HTML version.

(1) Vehicle Room

Employees start in the vehicle room. On the left, they can see predefined means of transportation that they might want to consider in their simulations and comparisons. On the right, they collect the ones that they really want to consider. They do so by dragging the appropriate avatars or names from the left-hand to the right-hand column.

Employees can add new means of transportation that are a better match for their commute situation to the list on the left by copying and modifying existing ones or by creating new ones from scratch. For example, they might want to clone a new car from a "default" car and supply it with the specifications of their own car. They can assign "avatars" (photos, pictures, or symbols of their choice) to means of transportation and give them a name (predefined means of transportation come with ready-made avatars that employees can change). Later, they use the avatars in the map room, where they assign them to routes or route sections to define so-called "itineraries".

Employees may also need to add data to a means of transportation to be able to run simulations. They do so by dragging an avatar to the center, where a property sheet appears for this purpose. Employees can do this with avatars on either side, but they only need to do it for those means of transportation that they want to consider and that are listed on the right (changes are also applied to the "originals" on the left). Missing values have to be provided by the EEC (either retrieved from external sources or "wired in")

Figure 4 presents a very rough sketch of how the vehicle room might look. For the sake of simplicity, I have used simple street-sign icons for the avatars.

Vehicle room

Figure 4: Schematic sketch of the vehicle room

(2) Map Room

Next, employees move to the map room, which offers an interactive map (similar to Google maps) that allows them to define itineraries in a two-step process:

  1. Routes: First, employees define routes using the interactive map or, if applicable, route sections that are connected to routes. If the return route differs from the route to work, they need to do this for both routes. They define routes by marking the start and end points of a route and, if applicable, points where they switch their means of transportation. The map calculates the respective distances and automatically enters it into the form on the right.
  2. Itineraries: Then, employees assign means of transportation to route sections or routes (again, for both routes if necessary) by dragging avatars that are listed on the left onto the routes or route sections. This way, they assemble itineraries, which can be given names and avatars of their own and used again in the calendar room (in the sketch below, I will mainly use names).

As an alternative, employees can enter distances into a form that is also updated according to the interactions with the map. When using the form, employees can assign means of transportation to routes or route sections by dragging avatars onto the respective fields.

Employees name and save itineraries for use in the calendar room.

Map room

Figure 5: Schematic sketch of the map room

(3) Calendar Room

In the calendar room, employees define commute scenarios that describe their actual and potential commute behavior. As in the map room, they either do this the drag-and-drop way and assign itineraries to time data using a calendar, which automatically counts the days, or they define scenarios using a form and enter the number of days that each itinerary is used.

The interactive calendar should offer flexible options for defining the number of days that an itinerary is used. For example, employees might select a certain period of time first and exclude specific days or weeks afterwards.

Commute scenarios are the ultimate entities needed for simulations and comparisons. Employees name scenarios and store them for use in the simulation room, where they can modify them and play around with them.

Calendar room

Figure 6: Schematic sketch of the calendar room

(4) Simulation Room

In the simulation room, employees play around with commute scenarios that they select from a list (left column), modify time schedules, and exchange itineraries (not shown), until they are satisfied with the results. They can store interesting variations of scenarios for comparisons with alternative commute scenarios and to tidy them up in the presentation room.

Employees can also select an "anchor" scenario, for example, a worst case scenario, to serve as a standard of comparison for other scenarios. This idea is taken from the E2C2 prototype in part 1 of this article. In my own case, the "anchor" would be using my current car all the time. This allows me to contrast using it exclusively with other potential scenarios and to compute and compare the respective savings.

In both cases – "selected" as well as "anchor" scenarios – employees can add further scenarios to the list if available and also remove them from the list. In the center is a simulation panel, in which they can modify a scenario and run simulations with it. As my ideas for this room are still very vague, this part of the simulation room has been "borrowed" from the E2C2 and serves as a placeholder only. Employees can save modified scenarios (with an "add to list" option) and also save simulation results for use in the presentation room.

Simulation room

Figure 7: Schematic sketch of the simulation room

(5) Presentation Room

In the presentation room, employees compare selected commute scenarios with respect to their environmental impact (mainly CO2 emissions) and possibly other parameters such as fuel and energy consumption. They can present comparison results using tables and different chart types. More dynamic presentation styles are conceivable, particularly ones that allow employees to change parameters without leaving the room.

Furthermore, employees can prepare and tidy up data for printing, saving, or sharing in this room. This data includes commute scenarios, means of transportation , routes, and – in particular – comparisons between different commute scenarios.

Again, the ideas for this room are still very vague, as shown in Figure 8, which also "borrows" placeholders from the E2C2 prototype presented in part 1 of this article.

Presentation room

Figure 8: Schematic sketch of the presentation room

 

Afterword

I have left many details open in this coarse sketch of an ECC. Nevertheless, it is easy to see that this is far more complex than the E2C2. I will not go into further details here, though, because that would definitely exceed the scope of this already long second part of the article.

This design exercise was also an interesting experience for me and, once again, the journey from the initial ideas to the sketches presented here was a long one.

Of course, one question still remains: Would employees prefer the simple E2C2 or the "rooms" version of the ECC? I can answer this question only for myself: I prefer the E2C2 because it is simpler and delivers initial results faster – I am not a "playboy"...

 

top top