BlockScience Labs - Subway Map

Winter/Spring 22 Industry Project

Introduction

Our client for this project was BlockScience Labs (BSCI Labs). BlockScience Labs is a software development company that provides tools to create and manage data science workflows. Their platform seeks to empower their clients to make data-driven decisions. Users can make and experiment with data models of complex systems and make use of a growing library of models. They strive to make the Data Science pipeline stronger, easier, and faster.

The Subway Map is a user interface on the BlockScience Labs platform that would help users visualize the changes made to their Github repository. Users are required to connect a Github repository to their projects on the platform, but they would have varying levels of experience with using git and Github. Thus, the Subway Map will improve the user experience of the platform by helping users understand the components of their repositories.

The Team

Jeffrey Zang (Project Manager)
Brooke Bahn (Designer)
Michelle Huang (Designer)
Shirley Lee (Designer)
Steve Chen (Developer)
Sam Mohan (Developer)
Ethan He (Developer)

Timeframe

Jan–May 2021 | 15 weeks

Tools

Design: Figma, Notion
Development: React, Redux, PostgreSQL, Octokit, Git, GitHub

The Project

Design

This is the original design BlockScience Labs handed us at the beginning of the project. Before designing, we conducted exploratory research to understand how Git users handle repository version control data. Then we went through each section of the interface — the left, center, and right pane — creating wireframes and running them through usability testing.

Iterations

A/B Testing: In the earlier stages of designing for the center pane, we offered BlockScience Labs two different design options for both the search bar and filtering features. Then we ran A/B testing to isolate and measure the impact of each option. In total, we presented users with 4 screens, each having a unique combination of the design options.

Version 1: Dynamic Search Bar + Live filtering

This first version combines a dynamic search bar, which incorporates query terms and sorting into one field, with live filtering of results, which removes non-matching lines from the interface.

Version 2: Dynamic Search Bar + Highlighted results

This second version combines a dynamic search bar, which incorporates query terms and sorting into one field, with highlighted results, which behave a lot like Ctrl+F on a webpage.

Version 3: Dropdown Sort + Live filtering

This third version combines a search bar with a separate field for query terms and a separate dropdown for sorting, with live filtering of results, which removes non-matching lines from the interface.

Version 4: Dropdown Sort + Highlighted results

This fourth version combines a search bar with a separate field for query terms and a separate dropdown for sorting, with highlighted results, which behaves a lot like Ctrl+F on a webpage.

Final Designs

Navigation Pane

We added a drop-down menu for users to manually select how many branches are shown at once. A pagination system was also added so users can orient themselves within the broader repository.

Commit Pane (also search + filter bar)

4 out of 5 users in usability tests preferred the separated search bar and sorting dropdown, so we used this version in our final designs. In tests, users mentioned a hybrid of live filtering and highlighting results would be most useful. Live filtering now has better feedback: matching keywords are highlighted within commit messages and matching users’ profile pictures are highlighted for greater result visibility.

Version Properties Pane

In the final design, the right pane is collapsable in and out of the right side of the screen, allowing for expanded screen space for commits in the center pane. It also now has an empty state; when the user doesn’t have a commit selected in the center pane, the right pane prompts the user to select one.

Development

The Subway Map application consists of 4 components: the navigation pane, the commit pane, the version properties pane, and the search & filter-by-time bar. Additionally, it interfaces with a user database to retrieve a GitHub Token, which it then passes to the GitHub API to get the branch and commit data of a specified GitHub repository.

Navigation Pane

The Navigation Pane encapsulates a set of pages where on each page, a list of branches for the selected repository is found.

• When a user clicks on a branch, a dropdown lists all of its commits in the form of versions.
• When a user clicks on a version, the Commits Pane isolates that particular commit and displays it to the user in addition to populating the details of the commit in the Version Properties Pane.

Commit Pane

Commit Pane houses the entire list of commits of the elected repository.

• Each row of a commit displays, the commit message and created date of the commit. By default, the commits are sorted in the order retrieved from GitHub.
• For longer commit messages, they are cut off at a certain point with ellipses. Conversely, the shorter messages are displayed as long as they do not go past a certain limit.
• When a user clicks on a commit, the details are populated in the Version Properties Pane.

Version Properties Pane

The Version Properties pane, as aforementioned, is populated with the details of a commit or version.

• The pane is initially collapsed, but comes into view when a commit is selected in either the Commit Pane or a version from the Navigation Pane.
• It contains the iteration number (version), branch name, created date, creator, and summary (allows the user to view the entire commit message).

Search and Filter-By-Time Bar

The Search and Filter Bar contains two subcomponents that allow for searching and filtering of the commit messages.

• Search, specifically, allows users to type in keywords that stack (if more than one) to filter the commit messages.
• Keywords in the commit messages.
• If the keyword is a name, messages are filtered down to messages created by the author and the messages that contain the author’s name.
• Filter-By-Time allows users to filter all commit messages from oldest to newest or newest to oldest. By default, they are sorted in the order they are retrieved from GitHub.

Redux Implementation

Our project uses Redux to manage state. Although passing down state from parent to child components is easy and widely used, the opposite flow of data — from child to parent — is not encouraged.

• Repo Commits — The GitHub API is used to get all commits of a certain repository. This information is then passed to redux.
• Filter Parameters — Should a user add filter parameters via the search bar, the inputted value is stored in redux. The filter parameters are then pulled from redux into the commit pane to live filter the commits
• Selected Commit — Should a user select a commit, its metadata is passed to redux for the top and right panes. The top and right panes use this metadata to display their respective data

GitHub API

The GitHub REST API was called using a dependency called Octokit to pull in the commits of a certain repository

• Get All Branches of a Repository
• Use Branches to get all commits for each branch
• Concatenate all the branch commits into one object

Takeaways & Challenges

Cross-Functional Teamwork and Communication

BSCI Labs incorporated us into a real-life workspace, in which designers and developers collaborate cross-functionally to make a final product. By involving every member, from designers, developers, project mentors, clients, and other stakeholders, in each step of our process, we were each introduced to perspectives we hadn’t considered before and learned the value of clear communication in a cross-functional workspace.

Learning from and Embracing Failure

Throughout this cohort, we encountered many impasses — some of which we were able to clear and others where we had to pivot. As a team, we are proud that say that we worked together to solve many of the issues we encountered during this 16-week cohort. One challenge, however, taught us how to learn from and embrace failure. The dependency we researched for the GitHub graph portion of our project had limited functionality, taking up much of the second half of the term. Although this was a failure, we learned from this experience that not all paths result in success. There will be stumbling blocks along the way before a functional project can be delivered for production.

AGILE Development

One of the most important lessons BlockScience Labs drilled into us during this cohort is the idea of developing fast to deliver a minimum viable product (MVP). The AGILE Development process — develop, deliver, and iterate — is an important process in the software development world. Essentially, the AGILE development process focuses on seeing if there is product-market fit and iterating upon the MVP should it solve a problem and provide value to customers.

Thank you BlockScience Labs for giving us the opportunity to work with you!