question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

UX/UI issue for 'Who can manage view access' inactive dropdowns

See original GitHub issue

Feature Description

Bug bash issue: https://app.asana.com/0/1202258919887896/1202406665934847 please refer to Asana issue for background

When you have a secondary admin user and went back to the Dashboard sharing & permissions screen, the Who can manage view access dropdown is inactive for PageSpeed and Idea Hub. Looking at the AC this is expected but could we not have a scenario where an admin does not want to share these modules with all admins? If this isn’t a scenario, then should we hide these dropdown’s to avoid confusion? I feel this needs discussing.

image.png

These are what are referred to as “Shared ownership modules” which are different than others because they don’t involve a specific “owned” entity on the service side, the ownership is more of a detail related to sharing (only owned modules can be shared with others). For these, ownership is set when the roles are changed which can be managed by all authenticated admins which is why the dropdowns for these are disabled.

Maybe it’s worth having some kind of tooltip or other message there indicating why these can’t be changed? I don’t think it’s obvious to users that these modules are any different from the others.


Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

  • Replace the disabled dropdown with plain text that reads: “Any admin signed in with Google” (this is the new wording, see: #5374). Because this can never be interacted with, removal of the <select> tag will clarify the usage for users by never setting up the expectation that this setting can be changed.
  • After the text added above, add a tooltip to “shared ownership” modules shared with all admins that reads: This service requires general access to Google APIs rather than access to a specific user-owned property/entity, so view access is manageable by any admin signed in with Google.
  • This text + tooltip should be similar to the text + tooltip used when the module is owned by another user, eg:
CleanShot 2022-06-20 at 22 02 08

Implementation Brief

  • In assets/js/components/dashboard-sharing/DashboardSharingSettings/Module.js:
    • locate the <Select /> component responsible for showing the view access options.
    • Inside .googlesitekit-dashboard-sharing-settings__column--manage, prior to showing the <Select /> component, start a new paragraph for the plain text. This should only show up if sharedOwnershipModule is true.
    • Make a copy of the existing .googlesitekit-dashboard-sharing-settings__note paragraph as indicated in the last part of the AC to compose this plain text. Simply replace the text of the paragraph (and the tooltip inside) to match what’s included in the AC.
    • Update the condition for displaying the <Select />: it should only show up when sharedOwnershipModule is false and hasOwnedModule is true.

Test Coverage

  • No new tests required.
  • Update VRT images if applicable.

QA Brief

  • Enable dashboardSharing flag from the tester plugin.
  • Go to Site Kit Dashboard.
  • Open the Dashboard Sharing settings modal.
  • Ensure that the “Who can manage view access” column for shared ownership modules (e.g. PageSpeed and Idea Hub) doesn’t have the dropdown. It should instead have plain text with a tooltip as described in the AC.

Changelog entry

  • Display a message with tooltip instead of disabled Dashboard Sharing view management dropdown.

Issue Analytics

  • State:closed
  • Created a year ago
  • Comments:8 (1 by maintainers)

github_iconTop GitHub Comments

1reaction
bethanylangcommented, Jun 21, 2022

@aaemnnosttv Like this even more, thank you!

1reaction
aaemnnosttvcommented, Jun 21, 2022

@bethanylang I’ve revised the language a bit, would you please take another look?

Read more comments on GitHub >

github_iconTop Results From Across the Web

Dropdowns: Design Guidelines - Nielsen Norman Group
Dropdown boxes and menus are overused and clunky but can be useful for revealing a list of options or commands.
Read more >
Frustrating Design Patterns: Disabled Buttons
In this article, we'll look into common usability issues with disabled buttons, how to fix these issues and when disabling buttons actually ...
Read more >
UI cheat sheet: dropdown field - UX Collective
When asking users to input their date of birth, use a dropdown calendar. Bonus points: Make sure that the only way that they...
Read more >
Drop-Down Usability: When You Should (and Shouldn't) Use ...
In General, Avoid Drop-Downs When There Are More Than 10 or Fewer Than 5 Options · 1) Lack of Overview. Seeing more than...
Read more >
Filter UX Design Patterns - Analysis & Best Practices
The intermediate option here is to apply the filters one at a time. If you let the user finalize their selection within, say...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found