activateDroppedTab: Give us your thoughts!

[raplemie]

Feature description

When a widget drag interaction finishes, the dragged tab, or the active tab of the dropped widget when dragging a group of tab, will become the active tab in the target widget.

The basis for this request was to facilitate navigation and reduce clicks to enable a widget that was just interacted with.

Note

Initially released in 4.9.0
Removed in 5.0.0 (activate dropped tab behavior is enabled by default)

Before	After

Why is it a preview?

• The interaction might need improvement and we prefer validating it before forcing it.
• We want to determine if the new behavior should be the default and only option, or rather if it should be an "opt-in" and require related API to be enabled.
• Should there be different behavior depending on the source state of the dragged widget ?

What then?

We would like the community to chime in on any issues they are facing when using this feature, and discuss how we can resolve these. We'd also like to know if there is a particular API that would be useful with this feature, additional options to be considererd, modified or additional behavior or any other ideas or opinions on the subject.

Basically, feel free to add coment on usefulness and how this feature should be officially supported!

[DanAbney]

Generally speaking, I think the tab being interacted with is likely to be of most interest to the user (at the time of the interaction) so it seems logical to activate the tab when the drag interaction is finished (after)... However, we also allow users to drag non active tabs.

I wonder if this makes sense...

• If the UI is visible before the interaction, then it should be visible afterwards
  IE: if the tab being dragged was the active one of original group, then it becomes the active one in the destination.
• If the UI is not visible before the interaction, then its safe for it to remain so afterward.
  IE: if the tab being dragged is not the active tab of original group, then it can remain inactive at the destination.

[GerardasB]

Good point, this does make sense and is applicable only when a single non-active tab is being dragged (a whole widget can be dragged as well, which will always contain an active tab).

[DanAbney]

Interesting! (I didn't know you could do that ... cool)
So I understand the terms (and may have been using them wrong)...
It seems like a widget isn't a single UI contained inside a given tab, but rather the container itself ... is this correct?
if so, what is each thing called (aside from their proper name)

That said ... in this case the weighting is a little different; its not as clear that the user's interest is on the active tab of the dragging widget, although it could easily be the case. Its harder to predict the prevailing active tab. I suppose until we learn more, we could handle that the same way ... activate the moving widget's previously active tab in the destination.

Now that I see the widget tabs combining, I wonder if we should use some animation, on drop, to show where the tabs will land (slide tabs over showing the new destination) ... just thinking out loud.

[GerardasB]

Yes, that interaction is not as straightforward as simply dragging a widget tab.

With the new docs (WIP) we have decided to use the following terminology:

• Widget - corresponds to a widget tab in the UI
• Widget container - displays multiple widget tabs

Currently, we display the blue outline that indicates where the widget tab(s) is added when dropped. My main concern with sliding the tabs is overflow case - when there is limited space.
I.e. https://itwin.github.io/appui/storybook/iframe.html?globals=resizer:true&args=&id=frontstage-frontstageprovider--widget-container&viewMode=story

Widget:

• Start dragging Widget 1 tab
• Hover Widget 3 (Widget 3 tab is highlighted, the final tab order if dropped 1, 3, 4, 5)
• Hover Widget 5 (Widget 5 tab is highlighted, the final tab order if dropped 3, 4, 1, 5)
• Hover the title bar area (you might want to resize the right panel) after Widget 5 (a highlighted rectangle is rendered after tabs, the final tab order if dropped 3, 4, 5, 1)
• Hover the middle drop target (fully-painted rectangle) in the right panel (a highlighted rectangle is rendered after tabs, the final tab order if dropped 3, 4, 5, 1)

Widget container:

• Resize the floating widget (make it wider)
• Start dragging the floating widget by it's title-bar
• Hover Widget 4 (Widget 4 tab is highlighted, the final tab order if dropped 3, 1, 2, 4, 5)