“When is my next bus home?”

Developing a personalized Garmin smartwatch app for travel info (part I)

I want to be better at using public transport. One of the main hurdles is that I do not take the bus or train frequently enough to remember the bus and train schedule. In my commute, I have a few combinations of options and connections depending on the time of day. On top of that, the schedule tend to change frequent enough for me to lose a sense of when the bus or train runs in relation to the next connection etc.

I figured that I could build a small app to help me leave my office or home in time to catch the right connection at the right time.

This post is the first one in a series. I hope to go through some of the stages I recommend to my students when they develop application as part of their project in the course on Experimental Systems Development course at Aarhus University. Typically, we send the students out to do design ethnography[1] or contextual inquiry to identify relevant challenges to work on. In this example I’m designing something for myself, so we can skip that step. In this post I will work my way downwards from scenarios to identifying high-level requirements and modules. This will inform early prototyping activities and the first collection of user-stories, which I will discuss in an upcoming post.

Now, back to my application. I have a few design requirements:

• Personalizable: I need to be able to filter line info and timeslots. I don’t want to deal with all the lines in my city nor all the hours of the relevant lines. I need to know “when the next bus to my preferred destination leaves”.
• Situated: The application need to consider contextual parameters such as week, time of day, location and maybe even factor in delays.
• Fast interaction: Given it’s about transit and quick decision, interacting with the app should be fast and simple. It should offer decisions support, but not overcomplicate things.

A couple of scenarios to get us started

I’m using a scenario-based approach to design[3], where the first goal is to develop a scenario that describes the current situation. Secondly, we will generate a couple of future scenarios. These scenarios will help us anchor the design in the present and address concrete needs, and explore future solutions that allow us identify and make early decisions on design features, technologies, critical prototypes and bootstrapping user-stories.

Henrik (that’s me) is a 40-some white male who work as a researcher at a Computer Science department in the city. He lives in suberbia outside the city with his family. Every morning, Henrik get up around 6, do a short run, and then shower and eats. He helps his family get ready and some days he walks the dog. He usually leave for work between 8 and 9 in the morning (except when he is teaching early) and leaves for home around 16. He wants to commute more often, as a flexible option and to lower his CO2 footprint. However, planning the commute and experiences with frequent delays and lost connections make him chose the comforts of his car over public transport.

That gives us a bit of information on the context, the user and the challenge. Here are two future scenarios:

Henrik is getting ready in the morning. His smartwatch notifies him that the bus for work is leaving in 15 minutes, so he has to walk in 5 minutes to catch it. He snoozes the notification. 4 minutes later the notification goes off again. Henrik decides that he is not ready yet, so he press next on the smart watch app. 10 minutes later, his Garmin smartwatch notifices him that the train is leaving in 15 minutes, so he has to walk in 5 minutes to catch it. He accepts the notification and pack the last things in his back. 5 minutes later he leaves for the train.

Henrik is at work. He promised his familty that he would be home by 17. Around 16 his watch notifies him that a train is leaving in 20 minutes, so he has to walk in 5 minutes to catch it. He presses `next’ and the watch shows that a bus is leaving in 30 minutes. He presses ‘accept’ on his smartwatch. 10 minutes later the smartwatch reminds him that he needs to walk within 5 minutes to catch the bus. On the way to the bus, the watch notifies him that the bus is 5 minutes delayed.

These scenarios allow us to discuss and think about the design before we make too many decisions about the solution. Scenarios are excellent for early internal and external feedback. We can discuss them in our design team, with users, clients, developers and other stakeholders. We can invite users into the process and ask them to inform or co-write scenarios. Scenarios can be acted out and explored through embodied and contextual design methods, and we can develop scenarios as sketches, story-boards and even short movies to help illustrate the future use. If future users recognize their situation in the current scenario and agree that the future scenario is a compelling solution, then we have a good stakeholder alignment and can proceed.

Identifying high-level requirements¹

1. The application is running on a Garmin smartwatch.

2. The application ‘knows’ something about the bus departures relative to the location of the user and the destination.

3. The application ‘knows’ something about the walking distance and time relative to the location fo the user and the location of the stop.

4. The application need to support a couple of simple interactions: snooze, next, and accept.

5. The application ‘knows’ something about the delay of the bus in real time.

6. The application ‘knows’ something about the user’s typical departures and destinations (and transit connections).

These are mixes of high level design features (it needs to be a smartwatch application), requirements (integrate location, transit data etc.) and specific interaction design features (snooze notification). We can break it down even further:

1. Garmin smartwatch application
   • Need to access the user location
   • Notification support
   • Simple user interaction
2. Transit information
   • Lines / routes
   • Destinations (stops)
   • Depature times
   • Delay time |
3. Geographical information
   • User location
   • Transit information
   • Walking distance
4. User profile or setting
   • Destination preferences

I added the last point on geographical information (a map service), because the application need to combine geographical information, e.g. “the user location relative to the stop”. If we identify additional features in the scenarios or write new scenarios, we can return to this step or do it again isolated for the new feature. The lists above is enough to move to the next step. At this point we would skip to a feasibility study if the project contain too many unknowns or high-risk aspect that might mean stopping the project. I see nothing on the list above that shy me away from moving forward².

A bit of early software architecture

The requirement list above is not complete and a bit abstract. And the list format is not telling about the relationship between the design features of the application. We need a bit more detail before we can start writing code. While UX folks might start developing user journeys or interface sketches, or even better user stories, we need to do some high-level sketching of the software architecture to figure out the building blocks of our application, where the user interacts with the system, critical parts that needs to be prototyped and figured out etc. All this would happen anyways as a consequence of the obvious user story “the user wants to define frequently used transit routes based on location and time of day”. And likely, a lot of this will happen either in parallel with close coordination or in a series of design meetings in the release planning part of the agile process[2].

When sketching high-level architecture, I’ve started using the C4 Model approach as a way to visualise the relationship between requirements, application design and software architecture³. For this application, it makes sense to sketch out the context and container level because the application draw on a couple of external services.

Sketching out the context includes the people (actors, roles, personas etc.) and the software systems that build up the application and and the context. This include additional systems the users and future system interacts with.The container diagram are the neccesary building blocks that provides the services that the system would offer. This level focus on high-level technologies and seperated deployable units such as a service, database, web-application etc. Containers can then be further decomposed into a component (modules) design for each container and subsequently into the familiar code-level diagrams from the UML family⁴

The diagrams can move from sketches (that is how I use them right now) to documentation that reflects how the actual system work. While some of the diagrams do show stuff that a sequence diagram would also capture once we know how everything will work, context and container diagrams provide a better way of sketching rough ideas and what we currently know about the application than traditional UML (in my opinion).

Context diagram

The context diagram allow us to focus on the user and application, and the other systems that they interact with as part of the use.

Figure 1: System Context Garmin GTFS Notification App.

The above figure give a high level overview of how the user will interact with the various parts of the application and how the application will interact with other systems it depends on. A bit of research reveal that Garmin use their Connect IQ application (for Android and iOS) to distribute smartwatch applications. When installed on the watch, the Connect IQ shows the application on your smartphone and provide ways of configuring the application. This way, the user avoid having to do the personalization on a small device like a smartwatch and can leverage the larger display, better input and network connection of their smartphone.

The requirements also tell us that we need some external services. One for getting all the information on public transit and one for estimating time and distance from the user location to the nearest stop. We can get the public transit data from the Danish provider of General Transit Feed Specification (GTFS) data RejsePlanen. For walking time and distance estimation, we can use on of several distance API providers:

• Google Distance API
• Graphhopper API
• OpenRouteservice API
• Other OSM based services

Which one will likely be determined depending on pricing and developer usability, i.e. how easy it is to integrate the API.

Container diagram

Container diagrams show the different independent units (e.g. a separate processes) that executes code or stores data⁵. If we zoom in one level, we get more details about the bits and pieces that needs to be developed in the applications. We are still not dealing with neither components (e.g. a location-based service component) or the actual implemented code.

Figure 2: Container View Garmin GTFS Notification App.

Most of these will need to be implemented, but there are a lot of things that needs to be prototyped first. For instance, I have introduced a Webapplication for configuring the different rules that wil trigger the notification in the scenarios in section Section 1. This is because I don’t know yet if Garmin Connect support more complex configurations of the smartwatch app and if the kind of configurations make sense without a dedicated interaction design and application.

Summary

Ok, so now we know a bit more about the application idea from the beginning of the notes. We know what it should do following out scenarios. We know a lot more about the requirements. And we have a rough overview of some of the relationship with other systems from the context diagram and a bit about the inner workings from our container diagram. All in a couple of nights work.

The two next posts will look at identifying prototypes that can inform our design decisions and how to write user-stories from the scenarios. Stay tuned.

References

1.

David Benyon, Phil Turner, and Susan Turner. 2005. Designing interactive systems: People, activities, contexts, technologies. Pearson Education.

2.

Hugh Beyer. 2010. User-centered agile methods. Morgan & Claypool Publishers. https://doi.org/10.2200/S00286ED1V01Y201002HCI010

3.

Mary Beth Rossen and John M. Carroll. 2007. Scenario-based design. 1032–1050.

Footnotes

1. I have not found a good consistent way to represent requirements. [3] put them in a table, others do elaborate documentation with list of R0-Rn requirements. This is something I want to read up on, but haven’t had the time or need yet.

2. Perhaps aside for the transit information, but I know from other projects that there is a public API for GTFS data in Denmark

3. There is a tool for creating these visualizations under Structurizer. I export mine to GraphViz for this post.

4. See the website and videos for details and examples.

5. I’m still trying to find a balance between what to disclose at this level and what to leave out. For instance, the database might end up being a key/value store on the smartphone and then more a component than a container.