A digital service that lets the Bloomington community see where roads will close, before they close.

May–July 2015


When someone needs to close a road in Bloomington, they must send an application to the City’s Board of Public Works. Once an application is granted, the Board creates a record of the upcoming road closing, and employees are scheduled to facilitate the closing.

The problem

Prior to inRoads, the City of Bloomington published the schedule of road closings to a mailing list, every Friday at 3:00pm. The email also included sidewalk closings, parking space reservations, and noise permits.

Producing this schedule was a time-consuming task, requiring several hours of manual text entry each week. Even when the email highlighted a closing that might impact a commute, it was hard to notice, because the email was so dense.

Additionally, nearby State Route 37 was scheduled for an overhaul into a full-fledged Interstate, causing a severe spike of road closings to track. The local newspaper, The Herald-Times, compiled the data into a map, which it published every Monday morning. This made it easier to understand how road closings will impact commutes, but it only showed the area near downtown, not the surrounding area.

Commuters can look up traffic information from apps like Google Maps, or Waze, but these apps only showed information crowdsourced by their community of users, after the closing happened. Our team had access to data that could show where road closings happen, beforehand. We wanted to make that data available to our community, in a way that helps them.

My role

Part of a small, multi-disciplinary team. Our team consisted of the Lead Developer, the team manager, the department director, and myself — all of whom participated in whiteboarding sessions and discussions about functional requirements.

UX designer and front-end developer. I created wireframes in Photoshop. Additionally, I wrote HTML and CSS in collaboration with the team’s Lead Developer. During development, I applied typography, and color standards from a broader design language to this application’s UI. I made a small contribution to the JavaScript in this project, but most of of the JavaScript was written by the Lead Developer.

Design strategy

Data visualization. Road closing data is very geographic in nature, so the team decided to present this data on a map. To help manage the sheer volume of data, we implemented a filtering UI, that lets users choose how much or how little data to see.

Leverage automation to streamline repetitive tasks. The Lead Developer and I conducted in-person interviews with the person who created the weekly road closings email. When she demonstrated her workflow to us, we saw one of her biggest pain points was manually re-formatting text when she copied it from one email window, and pasted it into a new email window. She shared that this process completely took over her Fridays, every week. The team and I wanted to help our colleague take back at least a part of her Fridays.

Soft-launch the new design language. Prior to inRoads, we had begun design and development of a redesign of the City’s website, which included new typography, a color palette, and branding treatments that hadn’t been released to the public. However, the team wanted inRoads to represent our path forward, so we debuted the new design language with this project.


Wireframe, review, iterate, polish in-browser. Development on this application had started before I joined the team, so we weren’t creating the visuals from scratch. Map visuals were already being provided by the OpenLayers library, but the overall visual layout of the UI left room for improvement. Functional requirements included:

  • List of upcoming road closings.
  • UI for filtering road closings by date.
  • UI for filtering road closings by type.
  • Ability to toggle between an interactive map of closings, and a text-only list.
  • Links to data feeds generated by the app, like iCal, JSON, and XML.
  • Feedback link.

Unconventional wireframes for unconventional constraints. For this project, I needed wireframes to accomplish a very specific task: To facilitate a stakeholder discussion about visual hierarchy. The stakeholders were especially interested in how to toggle between displaying the map, and the text-only listing. I focused these wireframes on details pertaining to this question.

Development on this application had started before I joined the team. One element from the existing application we were confident needed to stay was the map, so I started with a screenshot of the map, and designed a wireframe around the edges of the map.

The text inside the listing wasn’t a topic up for discussion, because this functionality had already been developed. Because the text wasn’t part of what I needed to work through with the stakeholders, I represented the text as rectangles. Although more conventional wireframes are strictly grayscale, I used colors to help facilitate the conversation about visual hierarchy. To avoid getting into a distracting conversation about which colors to use, I only used colors from a palette that had already been established in the online brand guidelines for all City of Bloomington web projects.

I had recently seen the F8 conference session about Facebook’s design process, and one of the takeaways that surprised me was that Facebook’s design team considers Photoshop to be a low-fidelity mockup tool. Hearing this made me curious about trying something different: Creating low-fidelity or mixed-fidelity deliverables in Photoshop.

As you can see below, several options for the map/schedule toggle were discussed.

inRoads production thumbnail inRoads production thumbnail inRoads production thumbnail inRoads production thumbnail

The stakeholders and I concluded to place tabs for toggling between the map and schedule view in a panel above the listings and the map. This way, we could preserve the filtering functionality, and persist filter selections across both the map and schedule view.

With the stakeholder discussion about visual hierarchy finished, we all agreed high fidelity comps in Photoshop were not necessary. Front-end code proved to be the most helpful format for high fidelity deliverables, given the constraints of the small team size and limited time available to the project.

inRoads map screenshot

inRoads schedule view screenshot

Creating a public-facing maps UI. The visual centerpiece of the UI was a map powered by OpenLayers. The main screen showed a listing of road closings on the left, and a map of closings in the main workspace. The immediate question became: How can we establish a visual relationship between a selected items on the left, and the corresponding road closing on the map?

Depending on third-party software meant some key design decisions were constrained by functionality in the OpenLayers API. To avoid investing time in designing an unattainable UI, I asked the Lead Developer questions about the OpenLayers API, and I checked out the documentation to look for ideas I knew we could build. Checking the docs led me to discover functionality to control both line-width, and line opacity, two visual attributes that I could use to signify different states.

inRoads schedule view screenshot

Creating a primitive drawing tool. The team lacked the data necessary to automatically generate a visual depiction of the road closing on a map. In order to present road closings in a visual way, our colleague who had previously compiled and re-formatted text into an email would have to create a drawing on a map. The drawing tool needed to be simple: fast to use, easy to train for.

inRoads production thumbnail

Our Lead Developer chose a JavaScript library called OpenLayers, to provide functionality to handle map rendering and basic drawing capabilities. To demonstrate the library, he built a proof-of-concept UI. Users could center on the location where they wanted to draw by dragging, and start drawing a new line by clicking on the map. In using the interface, I found I frequently started drawing a line by accident, because all clicks on the map started drawing a new line. It felt as though the UI presumed the user already knew they wanted to draw a line, even before the user had time to consider their action. I suggested we remedy this by following conventions similar to other drawing software, in which a drawing tool isn’t turned on until a user chooses that tool. The suggestion was well-received, and implemented into the UI.

The user base for this UI was minuscule—initially only one person, but it grew to include a few other users, ultimately totaling less than ten—so we deliberately minimized the effort invested this administrative UI. We reused HTML/CSS patterns from the more polished public-facing side of the app where applicable.

The Responsive Web Design challenge. At first, the team thought inRoads displayed too much data to fit on a small screen, so we chose to develop the first iteration for desktops only.

After we launched our first public test release, our department director received feedback via Twitter that our UI, optimized for desktops only, was extremely difficult to use on a phone. The feedback included a screenshot. We took that feedback to heart, and asked: “Can this UI be made responsive?” The Lead Developer estimated it would take significantly more time than we had left for the project. However, as I thought about the HTML structure of the UI, I imagined where each part of the UI would move to, on smaller devices. My estimate was low enough that we still had time to try.

I quickly sketched out the UI states we needed on 3x5 note cards, which I chose for their similar size to the form factor of smartphones.

Notecards used to visualize how a Responsive Web Design could work.

I brought the note cards to a team meeting, and gave my pitch, explaining how each state led to the next. The desktop UI mostly featured three columns: One for filtering results, one for listing results, and one for visualizing results on a map. Without major rewrites to the HTML, I could hide the filtering panel off-canvas, revealing it with a touchable icon. This presumed that in a mobile context, users are too on-the-go to be interested in road closings for future dates—when looking at their phone, they want information that is relevant in the moment. When a user saw a street name they were familiar with, they could tap the listing, and see a detail view that contained both a map, and a description of the event.

Critically, my pitch also included a strategy for implementing this new interaction by leveraging functionality that was already present in the codebase, minimizing requirements for new code. This was received well, so I dove into my favorite text editor, and produced a rough iteration of the application with a responsive UI. At the next meeting, the team agreed that this responsive UI redesign was the right direction, and that we felt confident enough about the redesign to spend some additional time for polish, just in time to ship.

inRoads mobile view inRoads mobile view with filters


You can visit inRoads in production. You can also try it out on your phone, to see the Responsive Web Design in action.

A victory for Fridays. Our colleague who used to create the weekly road closings email by hand shared with us that inRoads’ administrative UI minimized the time and energy to assemble the data for the weekly email. Before, she didn’t start assembling the email until Friday morning. With inRoads, she can enter the data for a road closing as soon as it is forwarded to her, allowing her to gradually build the list in small increments throughout the week. The weekly email is now published to a Google Group mailing list, automatically, by a cron job and PHP script set up by our Lead Developer. Our colleague shared with us that she barely even has to think about it, now.

Code For America Technology Award. Our team was honored by Code For America, for exemplifying how governments can share data with the public. Not only did the team make our road closings data available as an interactive map, we made the data available by web service APIs that other developers can incorporate into their own software. This way, our community isn’t locked into only seeing road closings in the City’s software. The City’s data can benefit our community by appearing in the apps they already use.

What I learned

4-dimensional design doesn’t require magic HTML. Smartphone screens give designers a lot less space to work with on the X and Y axis, but we can deliver a usable experience if we think more about incorporating time, the “T axis,” into our designs. If we structure both our UI patterns and our HTML in a way that reflects the nature of the interaction, we can repurpose the same UI fragments on devices with different form factors.

Don’t limit testing to desktop-based browsers. Despite efforts to eliminate browser quirks in the last decade, some browsers are still quirky. We know iOS users expect a best-in-class experience on their devices. Unfortunately, in 2015, Safari on iOS was well behind its competitors in its implementation of web standards, especially in the push to eliminate CSS vendor prefixes. Eliminate the guesswork by testing your UI on devices your end users depend on every day.