Thanks for creating this task @Volker_E! I wonder if we could resurrect or incorporate the task description from this task T210770:

Use case

Coming out of the work on the help panel (see T206717) was a need for a floating action button that is:

1. anchored to a fixed position
2. appears in front of *all content* on the screen.

Proposal:

Since the button should appear more prominently and clearly seen as 'above' all other content, it is proposed we could add a config option to make the primary button have rounded corners and a more prominent drop shadow.
Example:

(prototype here: http://reetssydney.github.io/prototypes/help-pane-v1/index.html)

This task is meant for a general discussion and collection of this pattern need and to decide if it

• should be implemented only context-specific or
• be part of the library and (in follow-up tasks) how to best implement it

Haha, sure. I don't forget it seems.

Discussed: Anne & Rita will do a timeboxed scoping session on this. We are approaching it as a separate component from T280330

@RHo I updated the task description to add a little bit more info, and a bunch of open questions. I think the first open question, about the scope of the Codex component, will be the most challenging to answer.

My initial thoughts: I think we should handle Z-index in the Codex component itself. It's not a FloatingButton unless it's floating, and we plan to set a standard Z-index scale in the Codex design tokens, so we should be able to set a value that will work in and out of MediaWiki.

In terms of placement, I think we may need to know more about potential use cases. Would this button always appear on the bottom right? I'm betting not, so we might want to make this configurable (e.g. a prop for placement with values like top-left, top-center, top-right, bottom-left.....etc.)

The thing I don't think we can handle inside Codex is the issue of conflicting FloatingButtons, as in the case of the GrowthExperiments button and the Vector width toggle. I think that sort of thing would need to be handled within MediaWiki. The real solution would be a system of registering FloatingButtons that can deal with multiple buttons, although I think the quick and dirty solution inside Vector (which hides the width toggle if the GrowthExperiments button is present) might be the best we can do with the resources we have.

I'd love to know your initial thoughts - please let me know what you think, or we can schedule a synchronous discussion sometime!

@RHo and I discussed the following open questions, decisions noted below:

Are any of the following are in scope for the Codex component itself? Or are they MediaWiki-specific?

• Z-index (i.e. should the component take care of placing itself on top of all other content? What happens >when there are multiple floating buttons?)
• X and Y placement (i.e. should we pre-define a location on top of the UI here? What happens when there are >multiple floating buttons?)

• Z-index should be covered here via Codex z-index tokens.
• We will offer at least one position option (starting with just bottom end, and potentially adding more options later).
• We could add styles to space multiple FloatingButtons added by the same app (like we do for multiple checkboxes or messages)
• We will not cover handling multiple FloatingButtons added by different apps/features in MediaWiki. This is outside the scope of the Codex component itself. We can, however, include guidelines for how to account for this (and inform people of this potential pitfall)

What states should the FloatingButton have?

See the states in the task description. It seems like these should work for FloatingButtons that show/hide a tool, and FloatingButtons that simply toggle between two states (like the width toggle)

Some FloatingButtons will trigger another element to appear, change state while that element is visible, then return to the default state when the element is dismissed. How will the FloatingButton and a potential parent/sibling component communicate? We are not building other floating tools as part of this task, but we should consider how to prepare FloatingButton in a way that will work with future components.

We can probably use a ToggleButton with v-model to handle this.

The IME keyboard toggle is a special case, I'm not convinced it falls into the floating toggle button category. It's always bound to an input element and sticks to it's bottom end position. The task description is already limiting the MVP to viewport bottom end, not a relative position.
I'd even conclude, that the IME keyboard toggle is an outdated and somewhat problematic UX pattern and should be reconsidered to be changed to an intra input action similar to the clear button. See also T301540.
In any case, it doesn't belong into the MVP scope.

In T278134#8617574, @Volker_E wrote:

The IME keyboard toggle is a special case, I'm not convinced it falls into the floating toggle button category. It's always bound to an input element and sticks to it's bottom end position. The task description is already limiting the MVP to viewport bottom end, not a relative position.
I'd even conclude, that the IME keyboard toggle is an outdated and somewhat problematic UX pattern and should be reconsidered to be changed to an intra input action similar to the clear button. See also T301540.
In any case, it doesn't belong into the MVP scope.

Apologies if unclear, but that was added intending to show a proposed use-case by @Pginer-WMF to provide a single floating action button instead (the mock pasted in the adjacent cell) in future for the input on the entire UI.