Organizations UX Themes

UX Themes

Sharing

Terminology clash between invited and shared

  • This problem gets worse if we were to introduce sharing
  • 2 concepts adding members to give them access vs adding the content of an object to another object

Display

  • The layout of subgroups and shared groups vs members is difficult to understand

Teams

  • The concept of teams is possible today but is difficult to understand how to implement

  • Teams are a desirable way of injecting a set of users rather

Member vs Group

  • Inviting a member makes them a direct member
  • Inviting a group makes them inherited
  • This inconsistency becomes a problem when the group that did the inviting is then shared
    • The direct members are shared
    • The inherited are not
    • This makes it difficult to understand what will happen

Group/Project Access

Difficult to see who the Members are

  • Can not see members of shared groups
  • Members show a lot of inherited members that do not actually participate in the group/project
  • Filtering by direct can often be 0
  • Members do not aggregate up so it does not accurately inform billing
  • Could be solved with an Access vs membership model (complicated large change)
  • Could be improved with a participation component as a sort/filter

Lack of internal visibility

  • Scoped to instance not org so internal is not possible on .com
  • Requires overuse of private

Group/Project Page

Tabs and filters

  • Projects have confusing tabs
    • Double-tabs is a bad pattern
    • The interaction between the tabs is confusing
    • The tabs themselves are not the right groupings

Search and filter

  • Groups and projects pages use a non-standard search and filter pattern
  • Filters available are not meeting user needs

View combinations

  • Projects and groups are forced to be navigated separately, there may be an opportunity to combine these in a way that gives the user the necessary context to help determine tree structure.

Participation as a sort
The membership model and specifically the inheritance often result in users being presented with groups/projects that have little or no association. This could be solvable by changing the membership model but is likely a complicated solution. Providing a sort option possibly as the default that includes the user's participation is an effective way of presenting more relevant results to users. This could reduce the "I am lost feeling" users often describe.

Settings

Self-managed vs SaaS
There is a large set of settings available on self-managed that are not available to SaaS.

  • Each setting has a specific value and would need to be evaluated individually
  • To achieve parity between self-managed and SaaS, allowing both to use organizations as the primary management system would require all settings to be migrated.
  • Need to establish or likely formalize an existing pattern for settings that are set at the organizational level and how they impact group/project settings
  • Adding clarity to what settings are applied where would simplify compliance and administration.

Organization

✅ Organization Home

Description If a user were to navigate to an organization, they need to see something. Admins will likely see settings, but the non-admin users will likely not have access to settings so all they would be able to see are the assets contained by the organization. This could be limited to groups, groups/projects, but likely has added value, and if they can see additional views similar to your work section, but with the context of the organization rather than the user.

🚧 Organization in other parts of the product

Description Unless it is determined it is not possible to see items from more than one organization at a time (likely not a desirable experience), we will need to account for the presence of organizations in several places in the UI. This could be as metadata and/or as filters.

✅ Organization Navigation

Description We will need to include organizations in the navigation and provide a way of navigating between them.

✅ Access

DescriptionThis means those within the container will need some visibility of it, but will likely also need some level of access control. Our current membership model will not work for this because its inheritance would result in every user being in every group/project and essentially negating the membership model. We will either need a modified membership model or a user concept similar to instance admin. This model needs to include both levels of admin and non-admin.

We will also need a mechanism for granting access. This includes inviting members, inviting groups, user creation, and the associated controls to govern this behavior.

User management

DescriptionWe need to define the users. What a user is in regards to billing. How they are established (related to access) but also user creation and determining a mechanism to gain administrative control over a given user.

Billing

DescriptionAssuming organizations will become the only billable entity, we will need a place to display usage and manage settings.

Combining top-level groups

DescriptionMany "organizations" GitLab included have multiple top-level groups. Since they have independent billing and potentially different admins, combing them together in a single organization could be challenging. If we are unable to this, the separation introduced by Pods may be detrimental in that they will have multiple organizations. There are 2 paths to correct this: - Find a way to do this programmatically (likely not possible because or separate billing and admins) - Build a mechanism to move or associate top-level groups into a single organization.

Non organization

DescriptionWe need to account for the administration of items outside of any organization. Define interaction, inheritance, and user flow for accessing and managing.

Settings
We need to define an inheritance mechanism.

Edited by Mike Nichols