-
Notifications
You must be signed in to change notification settings - Fork 1
Attachment component spec #1
Comments
Anatomy:
States:
|
@bcalvery updated per your 1st and 3rd suggestions - that makes more sense! For more actions, i agree it should be flexible. should we call it simply "more actions" for now? then maybe we can decide later if it's a button, icon button, or other component..? |
Probably call it a button or icon-button for now, that can probably also handle a menu. |
Naming conventionsIn order to create utilities for accessibility, styles, and state management it would be ideal if the atomical parts were single words, if possible. The same goes for the states. This way, they map nicely to APIs and objects. The optional identifiers also seem very helpful. Perhaps we move anatomy to a table instead?
These single word names will allow us to more easily use them in APIs and also reuse them across components. Actions
Agree entirely. Propose we merge 4 and 5 into a single generic atomical part called "actions". The term "actions" is a common name for this intent, as seen in the "more actions" title when hovering on the ellipsis in Slack. It is also generic and reusable so it will scale well across many components that have buttons. We only need to codify that the anatomy exists. It can be left to the component implementer what actions are available, what they look like, and what they do. In the Gmail example, there is a single action that looks like an X icon and removes the attachment. The Slack example has three actions, download, share, and an ellipsis for "more actions" which opens a context menu. StatesI would agree a failed state is warranted. I imagine in the failed state an implementation might include a "retry" action that would trigger the "loading" state again. Does this mean there are only "loading", "complete", and "failed" states? Is there a separate "retry" state as well? I originally thought that we would create specifications only for the component name and its anatomy, however, it seems we should also document its state flow here as well. The anatomy will even vary depending on the state. Example, progress does not exist in the complete state. Actions contains a retry action in the failed state, etc. |
PR up in microsoft/fluent-ui-react#220 |
Application Usages
Gmail
Microsoft Teams
Outlook
Slack
End User
How would the end user describe the UI they are looking at?
Intuition tells us an "Attachment" or "File Attachment" given the current UI and button names around the workflow. A poll was not conducted for this conclusion.
What actions is the end user taking when using this UI?
In all cases thus far the user is attaching a file to some sort of message, whether an email or a chat message.
Style Guides, Design Guides, and Frameworks
How is this component represented in style guides, design guides, and frameworks?
http://styleguides.io/examples
http://styleguides.io/tools
Professional Jargon
Anatomy
States
The text was updated successfully, but these errors were encountered: