Improve context menu discoverability

[grigasp]

Can you give more details on why you think that's needed? Or give some example where it's implemented? I looked at several components in multiple applications and don't see this feature anywhere. Or maybe I just misunderstand what you're asking...

I haven't seen any examples of this in our apps either, might not have looked enough.

I found the "entry point" for our context menus a little hard to find. I noticed in google drive the other day they always show an ellipses for an entry point to their context menu. And on hover they show actions you can take like favorite and etc.

Here's the property grid right now with just the copy properties:

idk how users will know they will be able to copy the cell value unless they accidentally right click on the row

If you look at teams when you hover over a contacts profile and then proceed to hover over some information it'll show an icon to copy which i think is more intuitive

I dont necessarily think we need to extract the copy to outside the context menu, just think the entry point (rather than right clicking) showing an ellipses on hover would be better UX

Originally posted by @aruniverse in https://github.com/iTwin/viewer-components-react/issues/549#issuecomment-1631755816

[grigasp]

Just to make it clear, the suggestion applies both - to properties in property grid and to nodes in tree component.

I believe accessing context menu through a right click (or a long-press on touch devices) is a common workflow that doesn't necessarily need addition cues and that's probably why many applications don't provide any (e.g. Windows File Explorer, VSCode Explorer).

However, I also agree that does improve both - discoverability and usability on touch devices, so it's definitely worth considering.

My concerns:

• Should ellipsis be displayed always or only on hover?

  • always - won't UI look too busy?
  • on hover - there's no hover on touch devices, so the change won't help there in neither discoverability nor usability.

• Should we show the ellipsis if the context menu is empty? Probably not, which means we'll have situations where some items have ellipsis and some - not.

• Nodes in tree component can have a number of action buttons (buttons rendered to the right of the node). The ellipsis would be rendered just like an additional action button there. I'm worried that too many action buttons could reduce space for the label too much. Need a plan to solve that.

[DanAbney]

Hello Grigas, I am responding to this per your (e-mail) request.

The quick answer... Yes, adding affordance that a context menu is present usually will improve discoverability.

Typically a contextual menu, as you likely know, does two things: Brings commands closer to the subject, usually making certain actions faster. Organizes options that are specific to the subject (context) so the user only has to be concerned about commands that are possible to the subject they are interested in).

ideally, contextual commands/menu should not be the only way to perform the action.

A few details about our users... They appreciate context menus (when they work well). They DO right click on things, although I am concerned they are learning not to, since context menus aren't overly present in our (more recent) web UI concepts (compared to desktop concepts).

Because of this, I do not recommend to completely remove right-click entry point for context menus. I don't think you are suggesting that.

Specific to your questions:

I do not recommend to have single actions (yet), but instead, contain everything in a single contextual menu, using (...) icon is fine. If you have an idea of commands users frequently use, you can consider adding them in front of the menu (like Google Drive desktop does), but I would make sure they are truly frequent by the user (research may be needed). Also consider space; Google Drive on desktop has room but Google Drive on phone (app) does not try to do that.

For tree...same as above, but I am not sure what commands are being considered (there isn't a contextual menu at the moment).

RE: Always or on hover? This is a bit trickier to answer because of the reasons you note. In google drive (desktop) they sort of do a little of both, they always show the menu entry point (vertical dots) AND add frequent commands on hover. On Mobile (app) they simply only show the menu always.

They get away with not making the UI too busy, IMO, because a. its not already busy and b. their data isn't overly dense. Note: If we could detect the form factor (mobile or desktop), this would be much easier to solve and better for the users.

For now, I recommend to show it only on hover for both Model Tree and properties.

RE: If menu is empty should we show the ellipsis? Generally speaking, no, but what is causing a menu to not have actions? If its temporary for the user, then it would be better to show the menu with disabled actions, to avoid UI stability issues ("sometimes its there and sometimes it isn't and I don't know why!"), but if the actions may never show up (perhaps its role based, etc.) then not showing it all is better.

That said, if this could happen on objects that seem similar otherwise (such as two separate nodes in a tree) where it would be challenging for the user to understand why they are different / why the menu shows for some but not others, we may need to explore this deeper.

RE: running out space for the label in the model tree ... yes, that is a concern and a reason against putting any connivence controls on the tree nodes. I would need to know more about the commands proposed to help evaluate if its worth taking space from the node names which seems to already be at a premium. Maybe for now, using right-click is the only way to open the context menu, and should consider also putting these commands in a top menu / toolbar inside the widget.