Skip to content

Design issue and merge request list item (row) and board card

Propose a consistent design for issue and merge request (MR) list items (row) and board cards, considering the following:

  • Prior research and data gathering
  • Define responsive views
  • Define different states based on the object's status
  • Tooltips may be needed, so the content of these should also be defined.

Research

- https://gitlab.com/gitlab-org/ux-research/issues/27: - 1 user said they would like to see an issue’s due date from the board view. This is a feature which is available within Trello. - 1 user said they would like to see time tracking. He stated that Redmine allows you to customise issues and chose what issue information you wish to display. - On the issues list view, 1 user would like to see absolute rather than relative timestamps. This has previously been mentioned by other users during usability testing but was in relation to MRs (#21 (closed)). - 1 user explained that he doesn't use the issues list view, it's way too convoluted and doesn't add any value to his workflow. He much prefers the board view as he can see at a glance where everything is up to. - 1 user expressed frustration at assigning and removing labels. A typical issue has 80-100 labels assigned to it. It's very difficult for them to select the right labels from the dropdown menu and it isn't intuitive how to remove a label. Pivotal Tracker was able to effectively handle issues with a high number of labels. - ux-research#39 (closed) - Issue and merge request attributes (1 year: 2017-05-04 to 2018-05-03) and usage of filters (1 week: 2018-04-27 to 2018-05-03): https://docs.google.com/spreadsheets/d/1IOWwm0erJpcmTCZTf9mIXo2h3g3WA_2VdylX5-Xgahk/edit?usp=sharing - Screenshots of how the competition display tasks/issues and pull requests: https://drive.google.com/drive/folders/1W225_FKYIZZH5ybAZg8m_fw9ZZEpO4MU?usp=sharing

Proposal

🔍 Design specs with the most up-to-date solution and implementation notes

Note that the issue list design spec has multiple implementation notes that also apply to other states and designs.

Implementation priorities

This list tries to balance smallest development effort vs biggest user experience gains, while also taking into account the learnability and habituation period that users need to go through:

  1. Issue in epic or related issue (design spec): https://gitlab.com/gitlab-org/gitlab-ee/issues/6086
  2. Related merge request (design spec): https://gitlab.com/gitlab-org/gitlab-ce/issues/47007
  3. Issue card (design spec): https://gitlab.com/gitlab-org/gitlab-ce/issues/47008
  4. Issue list (design spec): https://gitlab.com/gitlab-org/gitlab-ce/issues/47009
  5. Merge request list (design spec): https://gitlab.com/gitlab-org/gitlab-ce/issues/47010

Difficulties

  • At the time this was worked on, Looker didn't have all database tables populated, so only some issue data was able to be analyzed. No assignees, merge request, labels, or epics data was available.
  • No easy access logs to understand the top filters used on issues and merge requests lists. Had to rely on @andrewn to run the queries (thanks 🙇).
Edited by Victor Wu