As the internship project wrapped up, another exciting thing happened in the office this past week: the deployment of the new mobile application. Both the design and tech teams celebrated the successful launch of the new design onto the Utility Dive mobile site. Once the site seems stable and if no large issues arise, then the tech team will deploy it across the other industries. While I was not an integral part of the redesign, I was able to provide user feedback and help with the test of the site across platforms.
With both of these exciting projects coming to a close, I had to start making moves on the data visualization tool (which I introduced in the Internal User Testing post). I left off with the next steps for the internal data tool being to determine the requirements and prioritize them so that I could start implementing them. The first thing I did was take all five user interviews and list out all of the desired features and sort them into front-end or back-end. The front-end issues were the ones that I thought I could address before the end of the internship. I then further divided them into either a priority or reach goal. This allowed for me to show which goals the users had brought up that were good ideas, but were maybe not quite as feasible. I then added all of the goals (both priority and reach) to GitHub as individual issues. I began with around twenty issues but this number fluctuated as I learned more about Shiny applications and R.
Challenge and Approach
My challenge was to take all of the front-end issues and solve them using my HTML/CSS experience, along with learning how to solve them if it were a Shiny specific design issue. The issues I solved can be broken down into two categories: visual and accessibility adjustments. The main focus for the visual challenge was to incorporate an external CSS sheet so that I could have easier access to the design styles. I ended up using the ported SASS for Bootstrap since the Shiny apps are built on top of Bootstrap and Bootstrap is initially built with LESS. Once I had the SASS files I created a custom file to override the Bootstrap styles when necessary. While this is more extensive than just attaching a CSS file, it allows for easier customization in the future.
The visual issues involved not only adding a stylesheet but also figuring out how to responsively size the graphs and tables. I also addressed the complaints concerning the visual hierarchy of the tables versus the graphs and reorganized accordingly. The accessibility adjustments consisted of helping make the tables easier to use as well as indicating when the application was loading. To improve the tables I added default sorting from descending order, changed the labels to be semantic rather than the variable names, and made the sorting arrows more visible. To confront the loading issue (the user couldn’t tell when the page is loading), I added an overlay that appears whenever the application is either initially loading or recalculating. Overall, all of these small changes made a very large difference in the user experience.
The main visual improvements were the addition of a stylesheet as well as making the graphs and tables responsive. As you can see in the first screenshot, the graph extended past the edge of the screen.
I also updated the Dives page to better reflect the users priorities. Rather than having a table that showed only one data point I instead called out specific values.
With the addition of a loading screen, the user no longer has to wonder if the application has frozen or if it is just still calculating the results they requested.
As for the tables, the most apparent adjustment is the styles. There are also improvements in the sorting capabilities with clear column names and easy to find sort features as well as the removal of the non-intuitive bottom search feature.
I also added a legend for the graphs to help the user know what each line represents. In the left column I added helper text for the y-axis dropdown and added delete (x) indicators on the multi-select filter.