Skip to content
This repository has been archived by the owner on Sep 6, 2019. It is now read-only.

Attachment component spec #1

Open
levithomason opened this issue Aug 21, 2018 · 5 comments
Open

Attachment component spec #1

levithomason opened this issue Aug 21, 2018 · 5 comments

Comments

@levithomason
Copy link
Member

levithomason commented Aug 21, 2018

Application Usages

Gmail

image

image

Microsoft Teams

image

image

Outlook

image

Slack

image

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

  • GitHub (Primer)
  • Google (Material)
  • Khan Academy
  • Microsoft
  • TODO link more well known and respected guides and frameworks

Professional Jargon

Company Design Engineering Management
Amazon
Microsoft Chiclet
Netflix

Anatomy

  1. File name
  2. File meta data (optional)
  3. Icon (optional)
  4. More actions icon/button
  5. Cancel icon button
  6. Progress indicator

image

image

States

  1. Loading in progress
  2. Loading complete
@bcalvery
Copy link

Anatomy:

  • Should the "Close" icon/button actually be a "cancel" icon/button?
  • Should the "More actions" button be flexible - i.e. not definitively a single button that opens a menu, but array of actions/buttons that might have some built in overflow/collapse capability? Would that actually be a separate component?
  • Should Progress bar actually be "progress indicator"? -i.e. it could be a progress bar and or numerical percentage, or even time?

States:

  • Should there be a failed/retry state?

@codepretty
Copy link

@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..?

@bcalvery
Copy link

Probably call it a button or icon-button for now, that can probably also handle a menu.
What about the failed/retry state?

@levithomason
Copy link
Member Author

Naming conventions

In 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?

Part Optional
filename
description true
icon true
actions
progress

These single word names will allow us to more easily use them in APIs and also reuse them across components.

Actions

Should the "More actions" button be flexible - i.e. not definitively a single button that opens a menu, but array of actions/buttons

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.

States

I 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.

@levithomason levithomason changed the title [WIP] File Attachment component File Attachment component Sep 12, 2018
@levithomason levithomason changed the title File Attachment component Attachment component spec Sep 12, 2018
@levithomason
Copy link
Member Author

PR up in microsoft/fluent-ui-react#220

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants