Sidebar Overflow Menus

[edschema]

Design

Figma link

Section	Subsection	Unit	Components

Spec

For Sections and subsections: overflow menu from the sidebar have the following options. Library referenced objects have the options designated [library]

• Duplicate
• Move Up / Down
• [library] View in Library
• [library] Unlink from Library
• Delete

Units on the course outline page have:

• Duplicate
• Copy to Clipboard
• Copy Location ID
• Move Up / Down
• [library] View in Library
• [library] Unlink from Library
• Delete

Unit sidebars accessed from a Unit page have the same overflow options as above minus Move Up / Down

Components have:

• Duplicate
• Copy to Clipboard
• Move
• [library] View in Library
• [library] Unlink from Library
• Delete

View in Library opens the library browse page in a new tab with the upstream object selected.
If a user selects delete or unlink from library, user sees the confirmation dialog currently available for those actions
Unlink is inactive for non-reference level library objects as is currently implemented
For components, move opens the move modal currently implemented for components from a unit page

[bradenmacdonald]

@marcotuts @crathbun428 @ChrisChV

I'm just testing the PR now and it seems very strange that the new menu in the sidebar:

and the existing menu on the unit itself:

are completely different. Is there a reason we don't just re-use the same menu for both?

[bradenmacdonald]

I'm just testing the PR for this now, and I also noticed that when you duplicate or paste a unit, the new unit appears "selected" for a few seconds, and it's confusing because it looks like two different units are selected. After a few seconds, the selection fades away and only one is selected, but I think the "new unit highlight" should be visually different from the "selected unit" state to avoid this confusion. Flagging now for follow-up; I don't want to block the PR.

(Temporary state: first is "selected", second is "new" but both basically look "selected")

[ChrisChV]

Hi @jmakowski1123 @marcotuts @crathbun428 This is ready for AC testing in the sandbox

[crathbun428]

@ChrisChV - I tested this and it looked good to me aside from the behavior noted in Braden's second comment above. I also don't want to hold this work up for this fix, but if we have the bandwidth to make these two items not look the same, it would be a good tweak to make (if we have the bandwidth to). It's a great catch.

To Braden's first comment about the overflow menu we're testing in this ticket and the current kebab menu on items in the course outline page... the options listed there are currently a mix between the configuration settings we now show/allow users to set/view/edit in the settings portion of the sidebar AND in the functions we show in the overflow menu. I hear the point about making them the same, but making them the same would remove the configuration and tagging functions users currently are used to setting from the kebab menu... it does seem though that there are at least two different places now to do a good number of things in studio (specifically for the kebab menu versus the functions we allow users to complete in the sidebar).

Since I'm coming into this project at the tail end of this project, I'd be curious to know if we had/have a plan or thinking around what we plan on doing with this kebab menu long term. Is it helpful for users to retain the kebab as is or to streamline and reduce the number of places we allow users to perform the same function? @edschema - would you be the right person to ask this question? Or Marco or Jenna?

[crathbun428]

@ChrisChV and @bradenmacdonald - I wanted to circle back about Braden's first comment about the overflow menu we're testing in this ticket and the current kebab menu on items in the course outline page... it is true that it might feel weird to users that the overflow menu in the sidebar and the old kebab menu on the outline page aren't the same, but the current kebab menu has both some configuration/tagging functions in there as well as the functions we show in the overflow menu. I checked in with @jmakowski1123 on this to confirm my thinking, and for now, it makes sense to keep what we currently have in the new overflow menu and in the historic menu today so that users used to using the historic menu don't feel super lost with this release. We do agree, though, that we'll want to make sure we're reducing the number of places we allow users to do the same thing to cut down on visual noise/redundancies. I'm going to capture a quick placeholder ticket to represent this work for the future in our backlog for a later time so we don't forget about this conversation. Please let me know if you have any follow-up questions.