@bmartinezcalvo @Sarai-WMDE @Volker_E as far as I know we don't have an established approach here (please let me know if we do). If we indeed do not have an established pattern, and this topic ends up being something you all focus on at some point in the future, please see the "Context on decision" section above.

Hey Alex! Thanks for collecting all this valuable information and moving forward with a consolidated approach. The DST hasn't established a pattern for collapse/expand arrow behavior in different contexts yet, that's right. We'll observe the information included in the "Context on decision" when tackling the definition of the Accordion component (as part of our collaboration with Abstract Wikipedia). Hopefully, global recommendations will be derived from this task.

We have even started to explore bringing these interactions even closer together, by flipping the direction of the arrow on the dropdown handles when the dropdown is open.

Just for the record, when we approached this problem in the context of the Select component, we finally decided not to flip the handle arrow icon for the reasons stated in this comment. This should be factored in and kept in mind during our exploration.

Also from me thanks for collecting these examples.
The main difference that I see, and it's visible in the screenshots above, is the > indicator is most often used in a tree like structure, when there's a parent - child logical hierarchy. The children then get expanded while being indented.
While on mobile web it's about one section to be expanded and collapsed.

In comparison we also use other metaphors for the parent child hierarchy, for example on the Design Style Guide.

ok thanks @Sarai-WMDE & @Volker_E

In T314341#8123141, @Volker_E wrote:

The main difference that I see, and it's visible in the screenshots above, is the > indicator is most often used in a tree like structure, when there's a parent - child logical hierarchy. The children then get expanded while being indented.

ok, would you prefer that we leave it as is then? I'm fine with either option...

I couldn't put my finger on it and was trying to avoid making decisions on the fly. But after reflecting on Volker's comment, I think that it makes sense to keep applying the original pattern (side arrow while collapsed, down arrow while expanded) to the tree like structure, instead of emulating the section expansion pattern. (Curiously, this distinction is also made in the example from Gmail). We'll later see which of the patterns better suits the mentioned accordion component.

On a separate note, we should still try to solve the inconsistency between dropdown elements:

Do we agree to avoid flipping the indicator, or does this need further discussion? Although this is a common pattern (the arrow indicates the current function of the trigger). We previously decided to keep a static dropdown arrow in the context of the system (e.g. with the Select component) to mainly avoid grabbing the users' attention when their focus should be in the new context: the menu. Also, because dropdown menus are impermanent: they close on select or on click anywhere else, so a closing indicator might not be essential in this context.

Sorry for the delay in answer here. I know this task is declined now but I add my thoughts on it.

To define the behaviors of the arrows I think we need to differentiate between different components/elements in the system, in which the arrows will behave differently:

1. Select component:

In this component we decided not to rotate the arrow when the menu is displayed since in some cases the menu appears from bottom and the rotated arrow here would be weird.

2. Triggers:

They are built with dropdwon-buttons and they rotate the arrow when the menu is displayed. We need to analyze this case to decide if we want to apply the same behavior as in the select component.

3. Accordions:

We need to define this component and as @Sarai-WMDE commented it's possible that we define it with the collaboration with @aminalhazwani for Abstract Wikipedia (Amin, I ping you here for context if you need to understand the arrow behavior in other components if you finally define the accordion). In accordions the common behavior is to use + - or ⌄ ⌃ to display and collapse the info hidden in the accordion.

4. Menus with info trees:

Here as @Volker_E commented the most common behavior is to use the side arrow when the menu it's collapsed and the arrow down ⌄ when the subsections in the menu are displayed (current behavior in our menus).

Although we've decided to continue with the same behavior of arrows in this left menu (which seems logical to me being the most common behavior in this type of info trees) we could improve some things:

1. We could discuss about the arrow icon. What if we use another icon bigger or solid to highlight the action of opening and closing the tree?
2. I think level1 and level2 in the menu should be more contrasted, not only indenting the level2 but also differentiating both levels with different text weights.

Hey @alexhollender_WMF! Here to share a decision on behalf of the DS team: dropdown triggers (Select, ButtonDropdown) should use fixed handle icons.

The main reason is, after all, simplicity: unlike the fixed tree structures and accordions, dropdown elements can be used in a variety of contexts and positions in a layout, and are not immune to scroll. In some scenarios (e.g. based on the user's scroll position), it might be necessary to flip the vertical direction of menus (open them upwards) in order to keep them above the fold. Keeping the indicator uniformly pointing down will save us the need to implement extra (potentially distracting) transitions to cover all the scenarios (e.g. changing the orientation of the handle icon based on the mentioned scroll position instead of on a user action). From a system perspective, this is a more fitting standard solution at the moment.

@Sarai-WMDE @bmartinezcalvo sounds good, and thanks so much for going the extra distance to articulate this reasoning — it's super clear and concrete:

dropdown elements can be used in a variety of contexts and positions in a layout, and are not immune to scroll. In some scenarios (e.g. based on the user's scroll position), it might be necessary to flip the vertical direction of menus (open them upwards) in order to keep them in above the fold. Keeping the indicator uniformly pointing down will save us the need to implement extra (potentially distracting) transitions to cover all the scenarios (e.g. changing the orientation of the handle icon based on the mentioned scroll position instead of on a user action).

I've created T314669: [Visual refinements] Do not flip arrows on menu handles to revert the flipping of the arrows.

That's awesome to hear! Thanks so much for creating the task, Alex 🙏🏻