Discovery: Constraints surrounding the settings experience
Problem to solve
As we begin to approach establishing a direction to address the challenges around settings, the UX team needs to better understand the technical limitations that have lead to the current experience.
Requests for investigation
Uncover what could be design constraints before we embark on solution ideation. Here are some questions we'd like to better understand:
Discovery
Trying to memorize the Information Architecture of our settings can be extremely challenging, which leads to users needing to hunt for what they need. Navigating to a new page to then search for something is quite cumbersome, so it would be nice to be able to just search for "Variables" and not have to memorize that it is under CI/CD which is arguably a confusing place to put it.
- Question: What would happen if all settings were listed in a single page?
- Question: Is it possible to index settings so that individual sections can be discoverable through search?
UI Patterns
There is an odd mix of ways users can submit their settings changes, but it's not clear why they are designed in such a fashion.
- Auto save on select (e.g. changing a theme color)
- Independent sections having dedicated Save changes button
- Some pages have a sticky footer with a single submit button (e.g. Update profile settings)
- Question: If consistency was our goal, is there an option that is not feasible to apply everywhere?
Seems like forms get constructed differently and it's unclear if that's due to a limitation in GlForm
. We'd like to bring improvements to the developer experience, or functionality, to make building forms easier for developers and more consistent in behaviour and experience for users.
-
Question: Are there glaring issues with
GlForm
or things that could be better? -
Question: Is
gitlab_ui_form_for
the HAML implementation ofGlForm
?
Technical
We assume some of the settings structure is being influenced by things behind the scenes.
- Question: How does our API inform how we must construct the UI if at all?
- Question: Are the accordions sections a work around to a performance limitation for response time?
Cascading settings has been created as a way to give bulk administration power to those that configure settings. It's unclear how well this would works if applied to all settings in order to create consistency. There is an ad-hoc working group that had been diving into the problems and patterns around cascading settings, and we are just trying to consider if this is a pattern we can proliferate or should keep to a minimum.
- Question: If we wanted to make all settings cascade, would that be possible?
For a long time, the settings area in groups and projects have been reserved for Owners
.
- Question: Would there be a risk to exposing settings more broadly in a read-only state? (e.g. I can't see push rules to a repo unless I am an owner, but I'm expected to follow them as a developer)
Findings
...