Improved project lists UI: Discovery
Problem to solve
Our project lists and group lists share a similar design approach. Both of these are used throughout GitLab in different contexts, e. g. dashboards, groups, users.
The current shown information is rather generic and text-heavy. There is an opportunity to improve the information architecture and structure of the project and activity representation individually, to show the relevant information in a more readable, efficient and delightful way.
Project list | Group list |
---|---|
Proposal
In ~Discussion, we are working on improving the display of issue and merge request lists, see meta issue gitlab-design#83 (closed) and
Let's explore improvements for displaying projects and groups as well!
As these are core elements in the GitLab UI, the initial approach should be UX research driven to learn which information are most relevant, less important, missing, in the different contexts.
To prepare this, we have to list where projects and groups are shown within GitLab, ideally, define how important they are (usage) and consider planned redesigns. The designs should be consistent with the issue/MR list and activity feed redesign, where applicable.
Further details
- Projects
- Dashboard
- Group page
- User profile
- Groups
- Dashboard
- Group page
- User profile
What does success look like, and how can we measure that?
Feedback and output of related UX research ux-research#76 (closed) is implemented.
Results of UX Research: https://drive.google.com/open?id=1RqxVv_9_3pRWVHw8Ad7vSiMQ9JoQrSLd.
Links / references
Existing issues regarding improvements:
- https://gitlab.com/gitlab-org/gitlab-ce/issues/48321
- https://gitlab.com/gitlab-org/gitlab-ce/issues/28153
- …
Solution
Based on feedback from UX research (ux-research#76 (closed)), users want to see more of the relevant information in the project lists. What is relevant may vary depending on the use case. The following statement by Job explains very well what the lists are used for today—getting to a particular project.
I think lists of projects and groups are not intrinsically useful. They are a means to an end, being to navigate to where you need to go. I think that most of that can be better / faster through something like a quick action menu (like Spotlight on Mac) or a great navigation on the topnav (like we have now, but I think it needs a lot of love).
This should be done in a better and more convenient way so the results of this exploration are mostly focused on the 'explore' use case. We asked the users how they explore projects and what information is relevant when they do. They want us to show how popular and active the projects are. They also wanted us to clean up the interface, improve the IA, visual hierarchy and use the horizontal space better.
Explore page with proposed redesign
This redesign also includes improvements from gitlab-org/gitlab-ce#47407 and gitlab-org/gitlab-ce#51955 to better show the big picture thinking behind it.
Your projects | Explore projects |
---|---|
Changes:
- Increased font size for titles (h2)
- group is regular font weight, project name is bold
- we can hide the group info when the list is prefiltered by group or username info when prefilled by username (showing projects by a particular user only—profile page example below)
- visibility and license (or user role when not in Explore) info is now to the right of the title as icons only
- added 'Star' button to the far right of the project row
- added info about fork, MRs, issues, dominant programming language
- avatar size increased to 64px
- project description styled as secondary text in compact version to increase the contrast between the title and paragraph (this is something that came through UX research)
Suggested improvements:
- switch to infinite scroll and eliminate pagination. It's a much better experience (especially on mobile) and encourages users to explore without obstructions (switching to the next page)
Compact version
Because the newly proposed solution uses up more space than the currently live one, we need a compact version for cases when we don't have as much room to work with. We can't show all the same information in the compact version but we can still change the information shown depending on the use case. Examples:
The following is an example of how a compact version of projects list would look like in real life:
Tablet & mobile designs
Lists come in compact mode by default on tablets and mobile phones as there's not as much room.
On mobile phone screens we move away from the two-column layout which helps to clean and simplify the interface. Showing different information based on the use case (Your projects vs Explore) can be seen here.
Your projects | Explore |
---|---|