UX10 - Thoughts on next generation user interface
Please feel free to comment on the scope of this work, this is a collaborative process across all areas of the organisation, customers and the community.
Objectives
This project is aimed at improving the general user interface of GitLab over time through a series of releases up to 10.0.
The scope should be restricted to the overall application layout, as opposed to feature specific areas of concern. This should include:
- Overall information architecture & hierarchy
- Cross-feature navigational elements
- Overall visual style, including typography
Define problem set
Phase 1 of this initiative should outline an agreed upon set of problems and should set a scope for improvement. This exercise should be run by the UX team as a formal exercise by talking to existing customers, new customers and consider internal opinion and existing known issues and build upon the great work already completed.
Initial thoughts
Please find below some initial thoughts by @mydigitalself, having recently switched over from GitHub to GitLab. This is not meant to be a comprehensive review of the application but serves to illustrate some examples of areas and problems for consideration and is intended to stimulate additional discussion and areas for consideration.
1. Information architecture, heirarchy & navigation
- The grey top-level navigation block includes both global functions, as well as navigation elements for the currently selected project or view with little visual guides to separate the two, in particular due to the background colour being the same.
- Some global actions appear to be hidden or hard to find, such as creating a new project or group.
- The left menu contains "personal" items relating to the current user, effectively
My Projects
My Activity
My Groups
My Issues
etc... - I don't even know why Koding is there or what it does?
- The contrast of the primary navigation is signficantly reduced by the choice of grey inactive state on the text links. The grey background exacerbates this further and the combination in fact fails both WCAG AA and AAA accessibility compliance.
- Ordering of primary navigation should also be investigated, most commonly used interface elements should appear first.
- There are a series of secondary action elements on the project page that have considerably more affordance than both the primary and tertiary navigation elements.
- Tertiary navigation is also very subtle, changes completely on subsequent pages and is cluttered through the display of metadata (files size, commits, branches, tags) that may not be of immediate relevance.
2. Overall visual style
- The overall application still looks a lot like GitHub. Whilst familiarity is certainly important from a switching perspective, what can be done to give GitLab a visual feel of its own, without compromising on familiarity.
- Typography could do with some additional consideration, in particular markdown header hierarchy, line and paragraph spacing.
Related issues
Feel free to add any historical issues on this here.
Design exploration
The design exploration phase of this project should be unbounded, yet time-boxed. This will allow for radical and innovate thinking to set a future direction for the user interface.
We will then need to marry that vision with a realistic approach to delivering the next generation interface over an iterative period where every release moves us a step closer to our vision, as opposed to a REDESIGN ALL THE THINGS mega-release mentality.
We also need to be sympathetic and respect our users as change can be discomforting and reduce their productivity, which is paramount to developers.
Paper prototypes & sketches
To follow
Wireframes
To follow
Visual design
To follow
Execution plan
The execution plan should lay out a logical sequence of improvements over a series of releases. It should also include methods by which to validate change with our users, both through quantitative and qualitative mechanisms.