SURF Design System: redesign SBS header

[arnoutt]

Note: with header, I mean everything from the top of the page until the tables where the organisations/COs/members are listed, including the table header itself (the tabs).

Regarding the orange part of the header:

• The username chevron (user-info component) must be redesigned to conform to SDS (should contain first + last name as well as the url of the organisation the user is logged in with)
• The mouse over / hover style is not in line with the SDS
• There should be a separator before the logout option

Regarding the object-header part (the gray area of the header):

• Breadcrumb nav. should be made in line with SDS
• The SDS has a different style of filling the header with titles/descriptions/properties, make sure SRAM conforms to it
• The tab nav (table header) looks different in SRAM than in the SDS

Note1: likely, the object-header part will need some discussion, as probably not all properties will fit straight away.

Note2: possibly, we would like to get rid of the 2nd chevron menu, as it is not an existing element in the SDS. We should discuss that too.

[FlorisFokkinga]

Use the header with metadata-list, which is now available in the SDS: https://design.surf.nl/#object-header

[FlorisFokkinga]

Specifieke gevallen oplossen.

[FlorisFokkinga]

ORG

CO

Service

[FlorisFokkinga]

Org

• Keep title and description above the metadata-list.
• Organisation domains
  • abc.nl
  • abcuniversiteit.nl
• Users from these domains
  • can {request|create} collaborations

CO for admins

• Keep title and description above the metadata-list.
• Expires
  • March 16, 2023
• Membership request
  • Copy link ⎘
• Member list
  • {Visible|Hidden}

CO for members

• Members
  • 3 members
  • 2 groups
• Organised by
  • <admin 1 name>
  • <admin 2 name>
  • and 2 others
• More information
  • Website
• Expires
  • March 16, 2023
• Membership
  • Active (i)

Service

• Keep title and description above the metadata-list.
• Access
  • Login
  • Website
• Policies
  • Privacy policy
  • Acceptable use policy
• Adminstrative contact
  • john@example.org
  • mary@example.org
  • suzan@example.org
• Support contact
  • support.mailservice@example.com
• Policy compliance
  • Sirtfi, CoCo and R&S

[oharsta]

@FlorisFokkinga Is this story ready? Or do we need to resolve the matter of not-enough-space?

[FlorisFokkinga]

We'll have to make a few decisions about what to show and how to show it.

[FlorisFokkinga]

I think we can put multple (more or less similar) links in a cell, and also list an array of values for an attribute in a cell.
I've edit the bulleted list to contain five columns at most.

Lets's limit this to 4 lines per cell, for example:

• Name
• Value 1
• Value 2
• Value 3

And if more values,

• Name
• Value 1
• Value 2
• Two more values

I suppose for email addresses, the 'two more values' should be a mailto-link.

[arnoutt]

One minor adjustment to the mockup Floris made: the vertical lines should not be longer than the actual content. So in the mockup above, the first 2 vertical grey lines should be shorter.

[FlorisFokkinga]

• Limit to 5 wide
• Limit to 2 high if possible, 3 is permissable
• Don't allow user input
• Move the rest to a new 'about' tab
• Consider a service login button on the service about tab

[FlorisFokkinga]

Org

• Keep title and description above the metadata-list.
• Organisation domains
  • abc.nl
  • abcuniversiteit.nl
• Users from these domains
  • can {request|create} collaborations

Keeping the organisation domains in the header, violates the hight limit and allows user input. For organisational domains, this seems the best option. Ususally there's only one and it's too little information to offload to a tab.

CO for admins

• Keep title and description above the metadata-list.
• Expires
  • March 16, 2023
• Membership request
  • Copy link ⎘
• Member list
  • {Visible|Hidden}

CO for members

• Members
  • 3 members
• Groups
  • 2 groups
• More information
  • Website
• Expires (hide if no date is set)
  • March 16, 2023
• Your membership
  • Active (i)

Tab 'About'

Always show the admin's names and email addresses under the 'Members (#)' header, even if 'Disclose member information' and/or 'Disclose email information' are disabled.

Service

• Keep title and description above the metadata-list.
• Access
  • Login
  • Website
• Policies
  • Privacy policy
  • Acceptable use policy
• Policy compliance
  • Sirtfi, CoCo and R&S

Tab 'Contact'

Create a tab 'Contact', which is not shown for users that can see the 'Details' and 'Admins' tab (service admins and platform admins). On that tab, display text as heades and simply list the email addresses:

• Support for end user
  • support.mailservice@example.com
• Adminstrative email address
  • john@example.org
  • mary@example.org
  • suzan@example.org

[FlorisFokkinga]

Extreme cases

Organisation

CO

CO as member

Service

Service as member (of a connected CO)

I think it generally works well enough.

[FlorisFokkinga]

@oharsta, the new service about tab needs some padding to the left of its contents.

[arnoutt]

I'm not really happy with it and would like to ask the UX-expert to propose a new design. If that is going to take a while I'm OK with releasing it like this, but would really prefer to have a new/better design.

[oharsta]

@FlorisFokkinga Assigned this to you for follow-up (or not).

[baszoetekouw]

We're releasing the current design in v22. Followup in #623