BART.go streamlines the BART experience, distilling the interactions involved in planning a BART trip to the bare minimum. Novice and expert BART riders alike benefit from the application’s minimal cognitive requirements, providing the detailed trip planning information a novice rider needs, while providing the means for expert riders to interact solely with real-time information that can directly delay their trip. Users need only indicate their destination station; the application plans the rest of the trip. Through a minimalistic interface, the watch UI helps pace users, keeping them informed of their ETA to the station in relation to the train’s ETA.
Putting our Heads TogetherThe Brainstorming Process
Our team initially brainstormed over fifty ideas for smartwatch-based applications. Of these ideas, we identified our fourteen favorites. After careful deliberation, we decided on creating an application for pacing BART riders, which was an application that was mocked up by one of our team members for the initial design assignment. We benefited from already having some user feedback; armed with the knowledge that both novice and expert BART riders felt that their interactions with existing BART applications and resources were cumbersome, we continually focused on simplifying our application’s flow. Our vision was to create an application where a user could open the application and have all the information they could possibly need in a minimal number of interactions. It is for this reason that we ultimately ask the user only one question: “Where do you want to go?” We quickly realized that the app can take care of the rest, determining where the user is starting from, how the user should get there, how much the user has to pay, what train the user should get on, if the user has to transfer, and so on and so forth.
From Paper to Pixels
Intermediate and Final Design Iteration
In the spirit of our vision, we sought an intuitive, minimalistic, and watch-centric user experience. As our key interaction, a majority of our early iterations focused on transforming this notion into a tangible design. Almost immediately, we decided visual cues were a must, and so thought of creating a scale or gauge such as the one shown below.
However, upon realizing a strictly linear gauge was rather constricted by the Moto 360’s screen width, we instead developed a curved version to better capitalize upon its circular shape. From there, we mocked up several potential display scenarios, from purely pacing to service advisories, as demonstrated below.
With these proof-of-concept mockups in hand, we felt prepared to graduate to digital prototypes.
Within this domain, our UI underwent three major iterations, as demonstrated by a representative wire-frame + mobile UI + wear UI set per column:
To highlight each iteration:
Our first revision (a prototype in Framer.js) was largely an endeavor simply to fit all station-selection mechanisms we wished to include at the time—namely two station lists—a full list, and a customizable “favorites” list. Similarly, on the wear side, we wished to fit our coveted gauge, along with a few other indicators, such as numeric readings, background color, and icons. However, in both situations, we quickly learned that usability suffered drastically due to over-crowding and a lack of visual hierarchy.
As such, our second revision, we opted for a far more “vanilla” Android experience. By incorporating increased padding and menu tabs on mobile, to removing clunky iconography on wear, we were certain we had made a step in the right direction—our app was at least approachable, at first glance.
However, under scrutiny, finer details still contributed to a less-than-ideal experience. Our first attempt at abstraction left several facts--such as what tab the user was currently on, or what marker represented who—somewhat ambiguous. As such, in our final iteration, we introduced new indicators in an unobtrusive manner, from tab text and underline highlighting to tick + circle gauge markers.
For a more detailed enumeration of the issues within each iteration, and their corresponding solutions, refer to the following table:
Competitive Analysis
In our competitive analysis, we found many similar applications that cater to regular commuters. However, we didn’t find any applications that take advantage smartwatches. Nevertheless, we then selected the three mobile apps that best represented our competitors: Embark iBART, Easy BART, and Swyft.
After analyzing each app, we found that competing applications target BART users in general, and that all three require that the user select their starting and ending stations before being given some subset of information, including BART Maps, train schedules, fare information, and real-time advisories. Yet all applications require multiple steps and cognitive effort to select a start and end location and (for novice users) to find and attempt to parse relevant information to their trip.
Furthermore, the apps fail to provide the crucial piece of information of how fast the user would have to walk to catch the next train, which is what would set us apart from them. It would be a feature that none of our competitors have. As such, our competitive analysis confirmed that we needed to focus on making a good pacing interface that would help BART riders to save their time walking to the station, while providing every other piece of information that our competitors already provide.
Finally, we decided that our app would simplify the flow of the interaction by eliminating “select your departure station” step, since it is far more intuitive to just navigate the users to their nearest BART station. However, one of the three apps, Swyft, did feature the novel idea of allowing user to directly select a target BART station on map; rather liking this, we chose to implement this in our own design.
Meet Alicia and PeterPersonas
Based on our user studies, we created two sets of personas, representing the two target groups (novice and expert BART riders) that were identified from our interviews.
The first persona, Alicia, is a daily commuter who rides BART to and from work. She’s intimately familiar with the BART system, and prioritizes getting to her destination on time and minimizing the time she spends waiting for trains. Unfortunately, for her to utilize real-time information, Alicia has to navigate to multiple different pages on the BART website. She opens one page and selects her departure station and then has to parse a table of train ETAs to find the train or trains she can catch to get to work, and has to open another page to see if there are any service advisories in effect. The fact that she has to open two webpages and then parse the pages themselves to find the information she’s looking for means that she often skips checking the real time information when leaving to catch a train.
The second persona, Peter, is a tourist in the Bay Area who prioritizes getting to his destination as efficiently as possible so he can make the most of his vacation. Since he’s unfamiliar with the BART system, he often resorts to using Google Maps (or even a paper map) to find the nearest BART station and walk to the station. When purchasing a ticket, he’s annoyed that he must first turn around to look at the signs around the station to remember what station he’s in, then consult the map again to determine what station he’s getting off at, and finally attempt to reference a graffiti covered sticker on the ticket machine to determine how much his trip is going to cost. He then uses the in-station maps to try to determine what train or trains he should take, ultimately asking the station agent or other expert riders in the station what train he should catch to get to his destination. Peter is so overwhelmed by the plethora of information he’s processing, his cognitive processor is overloaded, and he makes no use of any real time information until he’s standing on the platform and looking at the electronic signs in the station.
So You’re Walking to BART…Scenarios
- Although you’ve never ridden BART before, you wish to take it to visit a friend who lives in the Bay Area. However, you know your friend’s address, but not the name of the BART station nearest to her. Luckily, BART.go’s map navigation tab allows you to select stations through an interactive map. So, you merely locate your friend’s address on the map, and tap the nearest station marker. From there, the app informs you of what train to take, leaving you all set for your visit.
- You’re on your way to work, and you notice that the difference between your ETA and the train’s ETA is increasing. You slow down a little, since there’s no point in waiting at the station for an extra twelve minutes. A few blocks away from the station, your watch vibrates and a notification that all trains are being held at North Berkeley station due to a disabled train. Instead of going to the station and getting stuck on the platform, you call your boss to let her know you’re running late because of a BART delay, and go to a cafe to grab a bite to eat and catch up on email while the delay clears.
- You’re on your way to an event with your friends, but unfortunately they haven’t planned your trip well and no one knows how to get to the BART station, or even which train you have to take to get to the event on time, and the event starts soon. Fortunately, you do know you have to get off at Coliseum station, so you select Coliseum as your destination station, enable turn-by-turn navigation, and tell your friends that they’re going to need to want to purchase a ticket for $10.80. You see that your ETA is eleven minutes and that a Fremont train is coming in thirteen minutes, so you tell your friends to hustle as you make your way to the station. You and your friends quickly buy your tickets, get on the train as it arrives at the station, and get to the event, right on time.
- You’re pacing your walk to the BART station and are five minutes away from the station, but your train won’t be arriving for another fifteen minutes. Seeing that you have time to spare, you stop by a nearby cafe to buy a drink. You sits down and enjoy your latte, when your watch suddenly vibrates, showing him that your ETA is only three minutes ahead of the train. This spurs you to leave the cafe, and you arrive at the BART station just on time.
- You want to take BART from Coliseum to Montgomery Street. The next train shows up as an SFO train, which arrives in ten minutes. However, the pacing gauge reveals that you can only possibly catch it if you sprint all the way there. Luckily, the timeline’s extra tick marks inform you that there is also a Millbrae train arriving in twenty minutes, which will take you to the same destination. You swipe down to set that train as your reference point and walk leisurely to catch that train instead.
- You commute to work daily with BART and are very familiar with the Bay Area, but you rarely ever ride to other stations. You dislike having to scroll through the entire list of stations, and the map selection isn’t much faster. Thankfully, after adding just two stations to your favorites, you can select them quickly and easily every time you ride BART. With these valuable seconds saved, you continue to use BART.Go for the pacing and advisory features alone.
User Studies, Details, and Findings
Many of our changes across the multiple iterations of our design came from our findings during user studies. Based on the complaints users had about the bart website, we also designed our mobile interface to be as simple and intuitive as possible. Users disliked the cluttered list in the early mobile prototype, so we drastically increased the spacing between items in later versions. We also added the map selection feature as an alternative for users who expressed dissatisfaction at having to scroll through a big list. That aside, we intended to make the pacing interaction the core of our app because all users acknowledged the usefulness of such a tool, also noting that they currently don’t know of any alternatives or competitors to the watch interface. Although all users were intrigued by it, none of them could figure out how to interpret it without ample explanation. This was mainly due to the fact that the train icon appeared mobile in early iterations, so we redesigned it to appear as a static tick mark instead. Most users responded positively to the changing background colors, so we chose the boldest colors we could while keeping them comfortable to look at.
All Polished UpFinal Design Across Representative Tasks
Mobile
On the mobile side, there exist three representative tasks: flexible destination selection, station favoriting, and redirection to the watch interaction.
In our first task, destination selection, the user need be concerned only with their destination station (as the app automatically determines the origin station); this fact is reflected in the existence of a strictly destination-oriented help-text. The user can make their selection through one of three channels: a Favorites list, an All Stations list, or an interactive map, as show in elements (i), (ii), and (iii), respectively, in the image below:
The user can switch with ease between the available selection methods, with nothing more than the tap of a tab at the top. The map view, distinct from the other list representations, enables the user to engage in a more spatially-oriented selection process, due to station specific markers.
Our second representative task is favoriting management. Intended for frequent commuters, this task enables experienced users to customize the displayable stations under the Favorites tab. From the Favorites tab, one is able to deselect favorites by tapping the star icon. On the other hand, from the All Stations tab, one is able to deselect and select favorites by tapping on a lit or unlit star, respectively.
Lastly, our third major task is directing users to the watch upon confirming their trip selection. That is, after selecting a station, one is taken to a “post-selection” page presenting trip highlights, as demonstrated below:
Upon viewing said details, and optionally checking the turn-by-turn directions toggle, the user either confirms their selection (by hitting the “START!” button), or can navigate via the “back” button to choose a different station. Then, upon confirmation, the user is brought to a simple page, shown below, which cleanly explicitly conveys to intent to continue the experience on the watch.
Wear
On the wear side, there are three representative tasks: viewing advisory alerts, viewing navigation directions, and pacing. Since the advisory alert interface and the navigation interface are both very simple and to some extent “standard” in its interaction with the user, we will mainly focus on our unique pacing interface in this section.
Nevertheless, to introduce them briefly: our final design of advisory alert and navigation interfaces are as follows:
When there is a new BART advisory, the advisory alert interface automatically appears, occupying the entire screen and vibrating to notify the user. The navigation interface is a swipeable list of navigation directions, so that the user can view navigation instructions step by step.
The final design of the pacing interface — an interface that can only be found in our app — on the watch looks like this:
As can be seen, we preserved our initial design of a curved timeline with the arrival time of the train that the user wants to catch in the center, and the user’s estimated arrival time calculated by the user’s instantaneous speed moves along this timeline in real time.
This design aims to provide the user with a quick visual reference of how s/he is doing relative to the train s/he wants to catch: if the user’s dot is on the left side of the timeline, then the user is doing well; otherwise the user must hurry up or to catch a different train instead. However, in this final design, all the trains are marked as a tick mark on the timeline, since tick mark implies that they are “stationary” (so the trains’ arrival times would not move along the timeline). This rationale we learned from our latest user study: when we represented the trains with the same shape as the user’s icon’s shape, users tended to get the false impression that the timeline represented a racing activity between him/her and the train. We have also included other trains heading to the same destination on the timeline, in which they are represented by secondary smaller faded tick marks, so that the user can also get a quick visual understanding of his/her arrival time relative to other trains. If the user swipe up or down, the timeline would adjust as if to rotate, the central tick mark representing the reference train becomes that of the previous or next train.
In our final design, we also utilized the entire background color to signal to the user a rough idea of how one is doing: red, yellow, and green indicate running late, being just in time, and arriving well before the train, respectively. By using the entire background, the color indicator is difficult to overlook; that is, at any point in time, there is only one color on the interface, making the meaning of the color more direct and intuitive than in our previous designs. In addition, we took care to use colors with sufficient contrast, so white text was sufficiently readable and easier on one’s eyes, as compared to our previous iterations.
Lastly, we preserved the numeric display of time at the bottom of the screen, so that the user has the comfort of a more precise comparison if such is desired.
What’s a Little Implementation?
Technical Challenges
Quite a bit, actually. In developing our app, we encountered two notable software challenges: the sheer number of necessary API call (along with the appropriate data handling thereof), as well as the pacing display’s gauge.
Regarding, the former, an end-to-end experience in our app requires a total of eight distinct API calls, six of which are to the BART API. This is due to the wide span of BART-related data incorporated into our app, from generating trips to calculating fares to retrieving service advisories. In the spirit of DRY coding, each API call is designated its own XML parser which inherits from a base parser class. From there, we make the distinction between data persistent over the course of a single app execution (i.e. list of stations; train routes; what train or series of trains get a passenger from one particular station to another; fare) and real-time data (i.e. train arrival times; advisories), and proceed to propagate this through the hierarchy of our custom classes.
The remaining two API calls interface with Google’s Maps Directions API and Maps Android API--to generate turn-by-turn walking directions to the station, and an interactive map, respectively. To elaborate on the latter, the interactive map not only possesses station-specific markers which display trip highlights (eg. fare) with a single tap (an ordinary marker interaction), but also launch the station’s post-selection page with a long tap (an unusual marker interaction). This long-tap feature, as it is not a built-in functionality of markers, instead requires a custom Draggable configuration to simulate long-tap listening.
Lastly, regarding the pacing gauge, the challenge lay in constructing and displaying the geometry in a manner that is extensible and flexible. While development over the past months has been exclusively on the Moto 360—meaning it would have been rather straightforward to hard-code placement coordinates based on the assumption of a fixed screen size—we instead opted for a display with parameters relative to the screen’s width. Only then, with this relative spatial framework established, could we proceed with the necessary geometric calculations.
At This Point of Culmination…Summary
One cannot help but make the intrepid inquiry: did we succeed? Have we truly streamlined the user experience down to the essentials in meaningful, useful way? Such answers are tricky to define on an absolute scale, but it is without question that our accomplishments have developed an experience which brings the user far closer to this goal than any other extant BART app. Succinctly put, the user benefits from the power of real-time data, without having to interface with its complexity. As was a key tenet during our app’s conception, one need only answer a single, beautifully simple question:
“Where do you want to go?”
And BART.go will get you there. Where and when.
Comments