The Systems and Applications Group at the City of Bloomington’s ITS Department develops and maintains in-house web applications to assist City staffers with day-to-day tasks. The four-person team has shipped dozens of applications, helping with a broad range of tasks, like inventory tracking, problem reports, road project management, a database of public board chairpersons, the City’s internal staff directory, and more.
Challenges to be addressed
As you can see below, these internal applications presented several opportunities for UI polish.
Readability. As you can see in the second screen shot, these applications were full-screen page layouts. When paragraphs stretch from the far left of a desktop browser viewport all the way over to the right, text becomes very difficult to read. Additionally, in the second example, there is a set of left-hand table header cells with a light gray background and medium-gray text. Color choices like this don’t provide enough contrast for optimal readability.
Inconsistent widths. Many pages in these applications included a mix of tabular data, and paragraphs. None of these elements had defined widths. Different tables on the same page naturally rendered out at different widths. This made it unclear how different sections of a page were related to each other.
Visual hierarchy and whitespace. A copy of
reset.css from 2007 set margins for most HTML elements, including paragraphs and list items, to zero. Margins and padding were used sparingly in these applications’ stylesheets, so the layouts mostly inherited the no-margin no-padding styling from
reset.css. The resulting lack of whitespace made it a challenge to understand the visual hierarchy of page layouts.
Typography. Typography treatments were inconsistent, and the font choices felt dated.
Branding and identity. Bloomington is a small, but vibrant city. Many residents and City staffers live there because they love the city. Our colleagues used these applications every day, so I wanted to test a theory that adding branding that evokes civic pride could potentially improve employee morale.
Part of a small, experienced, multidisciplinary team. The Systems and Applications Group included four individuals: myself, a PHP developer, a Java developer, and our team manager. Everyone on the team had over 10 years of experience with creating websites and applications. I was the only member of the team with the Adobe Creative Cloud suite of applications, but in an effort to make development more agile, design ideation was not owned by any one individual. Every member of the team participated in drawing sketches on whiteboards, ideating, and iterating design ideas.
CSS and reference HTML. I wrote and maintained UI documentation, including most of the CSS, as well as reference HTML that could be used by both the PHP developer and Java developer.
Design research. I led the effort to look at the design work of other teams, and evaluate their design processes.
Design pattern advocacy. I led the effort to look for common use cases across our applications, match reusable design patterns to these use cases, and implement patterns as reusable components.
What I delivered
Creating deliverables for different technology stacks. The team manager and I together decided that my code deliverables should be equally helpful to both the PHP developer and the Java developer. I was to deliver static HTML, that the two backend developers could convert into UI components in their respective technology stacks, as they saw fit. I offered to work with each developer’s templating engines, directly, but the was a concern doing so would stretch me too thin. I had no objection to this, since it meant I got to allocate more time to design.
First UI facelift. One of the most-used applications at City Hall was the internal staff directory. One common reason for this was because this application included official staff mug shots, which have been taken during the City’s new employee orientation for decades. When an employee from one department scheduled a meeting with an employee from another department, they used this application to look up the other person’s face, so they had some idea of who to look for when they walked over to the other department’s office.
This application was already built. Before I started working on it, it looked much like the screen shots at the beginning of this case study. My assignment was to make it look more pleasing, while minimizing the impact to the HTML and PHP code.
My first step was to create a workspace area with a maximum width, to keep layout elements closer together, and improve readability of body copy. This created extra space in the background, behind the main workspace area. For the background, I chose a photograph that included landmarks that anyone in City Hall would recognize. The dome next to the search bar is the Monroe County Courthouse, which sits in the center of the city square in downtown Bloomington. On even larger viewports, the red sign for the historic Von Lee Theater was visible. I blurred the photo to prevent it from stealing too much attention from the main workspace, but I verified with colleagues outside of the ITS Department that they could still recognize the landmarks.
Additionally, I used some relatively simple CSS to make the staff mug shot look more like a printed photograph. This added no complexity to the HTML, and helped the photo stand out more on the page.
Feedback to this re-skin. Every staffer who spoke with me, or other ITS Department team members, had glowing remarks. One person said, in a meeting, “I usually don’t like what you guys do, but I like this. This is good!”
Moving on from the first application, to a reusable pattern library
A brand, and a code namespace. When in-house code needs to work cleanly with third-party libraries, I’ve often found it helpful for in-house code to have a namespace. Because we encourage other cities to use our software, I didn’t want the namespace to be too exclusive to Bloomington, itself. When I researched the history of City Hall itself, I found out that the building used to be a furniture factory—at one point, it was part one of the largest furniture manufacturing facilities in the world. Our building was Showers Brothers Furniture Factory No. 1. I chose to use this historical reference as a base for branding, giving the project a catchy name, providing a namespace of
fn1 to help our code operate better with third-party code—all without developing nomenclature that would preclude other cities from adopting our software.
It was critical that this branding research not interfere with day-to-day work, so I researched and drew this logo in my spare time, at home.
A centralized stylesheet to reduce CSS duplication. Because this small team built and maintained so many different applications, I felt it was important to serve Factory No. 1’s CSS from one central folder, essentially making it a style API. I did some additional research on other municipal IT teams, to see how they handle some of the unusual challenges that emerge from such a small team building so many applications. Like other third-party dependencies, I saw CSS-based pattern libraries distributed by a release number, to help ensure old applications that depend on old releases of the pattern library don’t break after new releases ship.
Default styling for common use cases. These applications made heavy use of input forms, and tabular data. My goal was to redesign them to make them both easier to use, and more visually appealing.
Tabular data. For tabular data, I drew inspiration from research I had seen elsewhere to use color, and strategically increase the padding inside table cells. This extra padding ensured readability, without adding the visual clutter of cell borders, which often increase the cognitive load of reading the table.
To help users scan an individual row of tabular data, I used the
:hover pseudo-class to highlight the entire row of data the mouse was hovering over (see below). Additionally, to help the UI feel less cluttered, action buttons nested in tabular data had reduced opacity, until the user hovers over the corresponding table row.
Previous applications had often placed several action links in every row of tabular data. In most cases, these links included both frequently-used, and infrequently-used links, side-by-side. This is generally a contentious topic in design circles: Every week, new articles are published on Medium advocating for making hard decisions to cut features, or move links to a different location. As a first step toward that line of thinking, I advocated for an overflow menu that we could embed inside of tabular data. This way, we could embed high-traffic links directly in the table row, and place lower-traffic links in the overflow menu.
Simple web forms. These applications also frequently made use of simple web forms. I supplied some styling and documented reference HTML that used background colors to help convey which form elements were meant to be seen as part of one group of elements. Using a light gray background behind form elements helps the input elements pop on the page, helping to draw attention to the area where the user will enter keystrokes.
Responsive form input. Additionally, the team had never shipped a UI utilizing Responsive Web Deign. I made these form elements change their layout on mobile-sized viewports, to demonstrate to the team that RWD is something that we can do, not next month, not next week, but right now. This was especially valuable, because some new projects were intended to be used by City staffers on their City-issued smartphones, and mobile functionality was becoming an essential feature. On a smartphone, screen real estate is limited, but text fields need to be big enough to easily target with a finger. Using a mobile-first approach, I set the stylesheet to layout form inputs with small labels and taller text inputs, as shown below, by default. Next, I enhanced these patterns to display as in the screen shot above on larger viewports.
Reducing dependence on tabular data. Before I joined the team, the PHP and Java developer both had a habit of displaying most data pulled from the MySQL database as tabular data. In some cases, they displayed the values from every column of the table, even the ID field. I asked questions, like:
- What problem does this page need to solve for the user?
- Out of all the columns in the DB, which are relevant to solving that problem?
Additionally, there were cases where only one row from the DB was relevant to a page. I suggested that instead of rendering a table with only a table header and one row of data, we could render these values as
<dl> elements. This opened us up to more options for displaying data, like using different font sizes to establish priority in a visual hierarchy, or hiding the
<dt> element from sighted users, in cases where the purpose of the field is clear enough not to need a visual label.
Reducing overhead responsively. An unexpected challenge arose, from one of a visually impaired developer on our team. His workstation was constantly set to high-contrast inverted color, and a low screen resolution, making fonts render much larger. This also eliminated background graphics from the page. In these conditions, the layout for the header produced an excessive amount of empty space at the top of the screen. To alleviate this, I reduced the size of the main header, compared to the staff directory application we redesigned first. Additionally, I used media queries to further reduce the amount of space at the top of the layout for viewports less than 40rem tall. Below, you can see the site header inside a typical desktop viewport, followed by how it looks inside a shorter viewport.
Updates to the design process
During my employment at this job, I watched a Google I/O video about Google Ventures’ Design Sprint process, and brought it to our manager’s attention, to see if there were ideas we wanted to borrow from. Additionally, I attended a UX Book Club meetup at the IA Collaborative, in Chicago, and brought home some inspired ideas from my tour of their office space.
Using different levels of fidelity for different stages of production. Before I joined the team, I doubt they used mockups for these internal applications. It was fairly common for developers to lead whiteboarding sessions with stakeholders, but a designer was not always involved. When I suggested to our team manager that wireframes with Google Slides could open up participation in the design process to the entire team, and that working in low fidelity could help me push out early iterations in less time, he agreed it was worth trying out.
Saving notes from design review sessions. At the beginning of my tenure, designs were presented on a laptop screen, and notes were typed into a text document. After I visited the IA Collaborative, I suggested we try conducting design review sessions with printouts, so that notes could be written contextually, right on the design, or on post-it notes placed onto the design. Taking notes in this visually contextual way helped ensure they didn’t get lost. Scribbling notes or drawings on top of a printout proved to be a faster way to suggest design changes. Although there are digital tools, like InVision, that also offer similar design review experiences, this process seemed like a good first step for testing and validating changes to the process, without committing to recurring subscription fees.
Recommended next steps
Before and after. The team was impressed by how much I helped improve the look and feel of these applications. The difference between before and after is undeniable:
That said, I think there is still plenty of room for improvement. Here are some suggestions I would pursue, if I were still working with this team.
Further refinements to headings and containers. A disproportionate amount of attention was given to the elements that mattered most to the developers, like forms, and tables. I think there is still a lot more room for improvement to how headings look. Especially at the top of the page, headings need less whitespace.
Explore the possibilities of grid systems. I received a lot of pushback against the idea of grid-based design. One developer insisted I only need to implement what’s in the mockup. When I mentioned most mockups I create adhere to a grid system, he asked why not just leave the grids in Photoshop and only implement the minimum relevant layout in code? This was a big uphill battle. On my other big project, the City’s website redesign, employing grids helped me ship more layouts in less time, while maintaining consistent visual rhythm. A grid doesn’t need to dictate literally every element in a layout, but it should still provide a foundation for visual rhythm.
Further reduce dependence on tabular data. In addition to the issues outlined above, Tabular data also poses a handful of challenges to Responsive Web Design. There are some ways it can be done well, but there are also some antipatterns to avoid, like inconvenient or confusing horizontal scrolling on a small viewport. One of the biggest visual shortcomings of tabular data, is that it treats every column with equal importance, even though some columns are more helpful to the use case than others. Equalizing every column makes each columns’ contextual relevance more difficult for users to decipher. Depending less on displaying information in a table opens a team up to laying out the database fields in a more use case-driven way. As an example, here are wireframes of the same data displayed in a table (Figure A), and in a more context-driven listing (Figure B).
Change can be very challenging for a team that has done its work the same way for many years. In a year and a half, I pushed the limits of what this team thought it could do, and I hope my successor can push the team’s design work even further!