## Problem to solve ### Summary In order to add polish and make our issue lists more lovable, we should redesign the issue list and make it look more modern. ### Job Story Context: https://jtbd.info/5-tips-for-writing-a-job-story-7c9092911fc9 #### Situation _When I'm looking at issues on the issues list..._ #### Motivation _I want to quickly find the relevant issue(s) that I'm looking for..._ #### Expected Outcome _So that I can quickly collaborate on and/or triage the issue(s)_ ## Intended users Every single GitLab role/persona ## Further details As the Issues list view is one of the most widely trafficked part of the product, making it more usable is a win. The question we need to answer as part of the implementation process is ensuring that the changes we do end up with have some sort of validation that this is a positive step in the right direction. ## Proposal Make the issue list prettier:  gitlab-ce~9594407 since GitLabbers are heavy users of issues. ### Design - **The label collapsing behavior is out of scope. Labels are always expanded.** - Implement designs from https://gitlab.com/gitlab-org/gitlab-design/issues/83 for all project issue lists, group issue lists, and dashboard issue lists. - [Breakpoint `>1200px`](https://gitlab-org.gitlab.io/gitlab-design/hosted/pedro/%2383-issue-mr-rows-cards-spec-previews/#artboard1) - [Breakpoint `>992px`](https://gitlab-org.gitlab.io/gitlab-design/hosted/pedro/%2383-issue-mr-rows-cards-spec-previews/#artboard4) - [Breakpoint `>768px`](https://gitlab-org.gitlab.io/gitlab-design/hosted/pedro/%2383-issue-mr-rows-cards-spec-previews/#artboard3) - [Breakpoint `>0px`](https://gitlab-org.gitlab.io/gitlab-design/hosted/pedro/%2383-issue-mr-rows-cards-spec-previews/#artboard2) - [Items, states, and tooltips](https://gitlab-org.gitlab.io/gitlab-design/hosted/pedro/%2383-issue-mr-rows-cards-spec-previews/#artboard0) - The list layout acts like a table. If there is no milestone or due date or assignee, the column is not shown. If a field is present on one of the issues, but not on another, it should be shown as “empty”. - Information to display: - Status (open/closed) - We've changed the closed issue status icon: a circle with a dash. We also need to change this icon in the [mobile view of a issue detail page](https://gitlab.com/gitlab-org/gitlab-ee/uploads/df70ece4c6ccb088b37093eae3310a2a/image.png). We believe this is the only additional place to change the icon but we should search the codebase for any other instances. - The “open issue” icon only appears in the “All” tab. The “closed issue” appears in the “Closed” and “All” tabs. - Confidentiality - Title (link to the issue) - Path and ID - Created timestamp - Author - Updated timestamp - Upvotes - Comments - Labels (**ignore the collapsed styling in the mock-up, the labels always appear expanded**) - Milestone - Due date - Weight - Estimate - Assignees ### Mobile From https://gitlab.com/gitlab-org/gitlab-ce/issues/47009#note_99058090: As for the mobile version, it's the same thing but we don't display the table header because, in that view, it's no longer a table with columns, it's just a list. All breakpoints have been considered and are available in the specs. ## Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? --> * This is intended to be cosmetic only, with no new actionable behaviors. ## Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements --> * We will need to update the docs every single place a screenshot from the old issue list is used. ## Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ --> * Update specs to include any new data we are exposing on the issue list as a result of the redesign ## What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> ### To Do * [ ] Connect with the original designer to get research, background, and context for the proposed changes. ### Success Metrics * [ ] Measure current issue list design performance / rendering for certain activities like initial paint, filter updates, etc. against new issue list UI. * [ ] Zero regressions in terms of usability. ### Acceptance Criteria * [ ] New issue list design provides some sort of measurable improvement in terms of usability (i.e. page speed optimization, accessibility...anything). * [ ] The new issue list design has quantitative data to back up the cost for the redesign (i.e. X improvements in Page Speed, significant boost in lovability...). * [ ] There are no regressions in terms of usability or page speed. ## Links / references * If any contributor would like to add links and/or references, please feel free to edit the description and add them to this list. <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->