Extensions are represented by icons or icons with labels in the top bar. Users can interact with them by clicking to add information to the file view, clicking to go to the external documentation or read labels to learn about the file.
The usability of the Action Items Bar has a high impact on users since the currently implemented version does not scale well when working with many items. It also has a high impact on the company's goal of getting more people to use and build the extensions.
This issue also is high-urgency since we're adding more extensions to the registry, and we foresee people enabling more of them. If we don't refactor the existing solution now, we're facing the possibility of producing more Design Debt when adding on top of the existing solution.
The Impact-effort matrix used to prioritise Design Debt issues.
I've differentiated three functional spaces that we could use for extensions: top horizontal, bottom horizontal and vertical. Each of those spaces has its pros and cons in relation to the needs of the extension action items.
Low-fidelity mockup of horizontal & vertical spaces dedicated for extensions.
I've decided to perform the first usability testing as a hallway test. I invited 6 engineers working at Sourcegraph to got through the prototype with me. I asked them to use extensions of different types, manage active extensions and get specific information about the file.
Results
✅ No problems using two spaces (vertical & horizontal). Testers described the distinction between action items and static data as intuitive and aligned with the patterns from their IDEs
👎 Puzzle icon is not intuitive for collapsing the panel
👎 Testers were confused about the horizontal bar disappearing when there is no data to display
👎 Testers signalised that they would like to see all the action items, even if they are inactive. Displaying them in the contextual menu causes unnecessary friction.
👎 2/6 testers didn't notice the horizontal bar
The second round of usability testing included the same tasks as the first iteration and was divided into two phases:
Results
✅ No problems using two spaces (vertical & horizontal). Testers described the distinction between action items and static data as intuitive and aligned with the patterns from their IDEs
✅ All the participants knew how to collapse and open the vertical bar
✅ No problems with understanding which action items are inactive
🤔 10/11 testers noticed the horizontal bar and recognised its function
1/3 of a browser
From our usage data we know that many of our users prefer to keep Sourcegraph at 1/3 width of their browser.
Scrollable bars (a lot of extensions)
Both vertical and horizontal can handle overflowing content. Users can use scroll the action items or text labels using arrows.
I needed to adjust the solution for the diff view. I've decided to place file-specific horizontal bar below the path so that all the information about the file are in one place. Action items are a global element - they influence all the files in the diff.
Sourcegraph provides integration for the most popular code hosts - GitHub and GitLab. Extensions need to be adopted to interfaces of those applications without disrupting the flow and users' habits. They also need to be adjusted when it comes to style and behaviour.
I've decided to place them in the header, together with the file information. This place is the most predicable for the users. During the usability testing, I've incorporated a task of switching from the vertical action items bar to horizontal placement in the header. This flow caused no confusion for the users when moving between the products.
Sourcegraph extensions in GitHub's interface
Sourcegraph extensions in GitLab's interface
KPIs & metrics
Impact on company goals
Improving the usability of extensions action items and static data connected with them supports the company objective of popularising the extensions and showing their value to the users. New placement also supports the plans for more customers to develop their custom extensions.
