Skip to content

Explore organization experience options

Goal

The goal of this issue is to explore ways of presenting a "workspace" concept to users to achieve the goal of creating a better experience for organizations to manage their GitLab experience. This is focused on the UX perspective and not the engineering implementation.

These are not solutions, but rather directions we could head in for the purpose of exploring the pros and cons of each. They do not necessarily need to be viewed in isolation. There could be parts and pieces of each that we can take and apply to the final solution.

Options

Workspace as a top-level object
Create an object that sits at the top that is distinct from the groups/projects in its UI and features.
  • 📺 Walkthrough video
  • Move the admin panel capabilities to this object
  • Allows settings to be defined and applied to all groups, subgroups, and projects in an "instance"
  • View data (issues, members, activity, etc) across all groups, subgroups, and projects in an "instance"
  • Could include namespace functionality
  • Similar to the Organizations propsal
  • Access:
    • To allow a broader audience for instance-level features additional access would need to be expanded compared to the current admin settings and require management.
    • Members should not inherit down into groups preventing admin from showing up in every group
  • Could be built as a namespace or separate object depending on if it is easier to build exceptions in a namespace or just a new object.

Problems statements:

  • Engineering efficiency - Depends on how it is built
  • Access/Permissions to features - Solves Access to instance-level features and gives some more control to permission
  • Feature parity - Solves parity, improves but does not solve feature level availability
  • Hierarchy - Does not solve
  • Navigation - Solves overview

Drawbacks:

  • Users may want similar functionality at other levels
  • Adds an additional mental model
  • Require additional navigation
Workspace as screens
Create screens/views to access admin panel capabilities.
  • 📺 Walkthrough video
  • Groups stay as the organizational method and everything rolls up to a top-level group
  • Allows settings to be defined and applied to all groups, subgroups, and projects in an "instance"
  • View data (issues, members, activity, etc) across all groups, subgroups, and projects in an "instance"
  • Access to screens through navigational elements and in context
  • Access to screens would need a control mechanism but could be populated by the assets themselves

Problems statements:

  • Engineering efficiency - Depends on how it is built
  • Access/Permissions to features - Solves Access to instance-level features and gives some more control to permission
  • Feature parity - Solves parity, improves but does not solve feature level availability
  • Hierarchy - Does not solve
  • Navigation - Solves overview

Drawbacks:

  • Views not anchored to a context may be confusing
  • Require additional navigation
Workspace as top-level groups
Root level or top-level namespaces are the workspaces
  • 📺 Walkthrough video
  • Groups stay as the organizational method and everything rolls up to a top-level group
  • Move the admin panel capabilities to namespaces
  • The root group allows settings to be defined and applied to all groups, subgroups, and projects
  • The root group allows viewing data (issues, members, activity, etc) across all groups, subgroups, and projects
  • Accessed in normal namespace (group) navigation
  • Could have an additional direct navigational element

Problems statements:

  • Engineering efficiency - Solves this
  • Access/Permissions to features - Solves Access to instance-level features and gives some more control to permission
  • Feature parity - Solves parity, solves feature level availability
  • Hierarchy - Does not solve
  • Navigation - Could solve overview but would require navigation improvements

Drawbacks:

  • No control of user namespaces
  • Adds an additional mental model for admins
  • Would need to solve for admins/every user inherited to every group
Workspace as a container for horizontal aggregation
Create a new type of container that is used to aggregate items outside of the tree structure.
  • 📺 Walkthrough video
  • Include changes outlined in Workspace as top-level groups
  • Projects could be added to a workspace and given reporter access level
  • Build tools for bulk editing where permissions still live in individual group/project
  • This would allow you to set up views for your perspective or workflow

Problems statements:

  • Engineering efficiency - Solves this, but add another thing to build
  • Access/Permissions to features - Solves Access to instance-level features and gives some more control to permission
  • Feature parity - Solves parity, solves feature level availability
  • Hierarchy - Solves this
  • Navigation - Could solve overview but would require navigation improvements

Drawbacks:

  • No control of user namespaces
  • Access would require an additional setup/maintained
  • Adds an additional mental model
  • Requires additional navigation
  • Namespaces would also benefit from this functionally
Workspace as a feature for horizontal aggregation
Similar to Workspace as a container for horizontal aggregation, rather than creating a new object, create the functionality as a feature of namespaces.
  • 📺 Walkthrough video
  • Include changes outlined in Workspace as top-level groups
  • Include changes outlined in Workspace as a container for horizontal aggregation
  • Solves for access requiring additional setup/maintained
  • Removes additional mental model
Workspace as improved groups
Root level or top-level namespaces are the workspaces, but with some additional improvements to groups.

Include everything from Workspace as top-level groups:

  • Groups stay as the organizational method and everything rolls up to a top-level group
  • Move the admin panel capabilities to namespaces
  • The root group allows settings to be defined and applied to all groups, subgroups, and projects
  • The root group allows viewing data (issues, members, activity, etc) across all groups, subgroups, and projects
  • Accessed in normal namespace (group) navigation
  • Could have an additional direct navigational element

Additional group improvements:

  • Improve the current sharing mechanism
    • Add clarity between direct vs shared permissions
    • Currently sharing is only focused on adding members to projects
    • Allow asset sharing across namespaces
  • Make a clear distinction between consuming and producing UIs for groups and projects respectively
  • Improve navigation/wayfinding between namespaces
    • Fix changes in context when navigating between groups and projects.
    • Improve the ability for a user to orient themselves to where in the organization they are

Problems statements:

  • Engineering efficiency - Solves this
  • Access/Permissions to features - Solves this
  • Feature parity - Solves this
  • Hierarchy - Solves this
  • Navigation - Solves this, does not solve overview of their workspace

Drawbacks:

  • No control of user namespaces
  • Would need to solve for admins/every user inherited to every group
Workspace as improved groups and create an admin view
Root level or top-level namespaces are the workspaces, that include additional improvements to groups, and create an admin view for settings and overview.

Include everything from Workspace as top-level groups:

  • Groups stay as the organizational method and everything rolls up to a top-level group
  • Move the admin panel capabilities to namespaces
  • The root group allows settings to be defined and applied to all groups, subgroups, and projects
  • The root group allows viewing data (issues, members, activity, etc) across all groups, subgroups, and projects
  • Accessed in normal namespace (group) navigation
  • Could have an additional direct navigational element

Additional group improvements:

  • Improve the current sharing mechanism
    • Add clarity between direct vs shared permissions
    • Currently sharing is only focused on adding members to projects
    • Allow asset sharing across namespaces
      • Possible solution gitlab-org/gitlab/-/issues/228562
  • Make a clear distinction between consuming and producing UIs for groups and projects respectively
  • Improve navigation/wayfinding between namespaces
    • Fix changes in context when navigating between groups and projects.
    • Improve the ability for a user to orient themselves to where in the organization they are

Admin view:

  • Setting that applies to every group including user namespace
  • Summary view of usage data
  • Only admins can access
  • Membership does not inherit to subgroups

Problems statements:

  • Engineering efficiency - Solves this
  • Access/Permissions to features - Solves this
  • Feature parity - Solves this
  • Hierarchy - Solves this
  • Navigation - Solves this, does not solve overview of their workspace

Drawbacks:

  • Possible additional engineering effort
Edited by Mike Nichols