auro-button: floating button
leeejune opened this issue · 7 comments
Feature request
Create a floating button that lives on top of all content on a page.
Example use cases of this would be:
- back to top
- add to cart
Blueprint
Dev review completed with @blackfalcon and @jordanjones243
Next steps are to create dev plans.
@leeejune I believe that there were unanswered questions about how this new feature is supposed to work between a mobile experience and a desktop experience and a few other questions before we can start planning out development.
Why do we need two different styles for a similar concept?
What is the expectation for how this button will work on the page going between a desktop experience and a mobile experience?
Why do we need two different styles for a similar concept?
@blackfalcon It's the same reason for why we have the round shape on our regular button. It is meant to differentiate the floating button from the original buttons we have.
What is the expectation for how this button will work on the page going between a desktop experience and a mobile experience?
This example has been added to the blueprint. The button will wrap the content and be placed in a corner instead of being fluid. Fluid buttons will not be fluid on desktop.
I was also imagining the mobile vs desktop experience to be a more implementor's choice type of thing; for example, a certain experience might have the floating button only on mobile. Or maybe the button is on both screen sizes. These are the options I pictured the implementor having:
- fluid vs wrap content
- placement on screen (corner/center of screen)
- appearance on desktop/mobile (only appearing on mobile for some experiences)
- transition from text floating button to icon floating button (static or animated)
... mobile vs desktop experience to be a more implementor's choice type of thing
That's fine, but we need to define these things and have ways for users to do these things. We can't simply say 'choose your own adventure' as that will lead to a lot of confusion and designers/devs trying to do things that simply aren't possible.
@blackfalcon I understand. I'd like to clarify by distinguishing between Desktop and Mobile experiences. The only difference between the two is that mobile would/could have fluid sizing. We can also keep the fluid option on Desktop if not having it creates unnecessary complexity.
| Property | Desktop | Mobile |
|---|---|---|
| Type | Icon button, text button | Icon button, text button |
| Behavior | Transitional, static | Transitional, static |
| Sizing | Custom width, hug contents | Custom width, hug contents, fluid |
I think there was some confusion around the "appearance on desktop/mobile (only appearing on mobile for some experiences)" option I mentioned above. This is just referring to media queries and responsive design–some elements only appearing when more screen estate is available. I wasn't sure whether this option would be engraved into the component or if it'd be dealt by the implementor.