Paste-y mobile component: Input

[waijeeho]

Hi! I'm Wai-Jee (formerly Frontline, now Aion) working with designers Chof Golan Kotter (Authy) & Jiyeon Kang (Conversations) to develop a mobile component UI library with the goals of:

• having mobile components that are visually consistent with Paste web
• having mobile components that meet the visual accessibility guidelines from Paste web

This is a cross-product designer effort in 2023, and a previous cross-product audit workshop was done in 2022.

We started with the Input component and wanted to get feedback on its visual / UX design and any relevant accessibility feedback you can provide, based on your web expertise. Links to the Input component design:

• Figma page for the Input component
• Prototype and Figma page for the Input stress test, mocked up on an iOS device

Couple of things to note about the current designs that we can discuss during the office hour:


• We’re recommending that we use the default system font on each platform for core content and controls, so there are component variants for iOS / Android that has a default OS font.
• We’re recommending the base font-size for mobile be larger than it currently is on Console, so the Input font size is slightly bigger than Console web.
• Using the Input component, we’d be looking to base the designs of our ‘Select’ component and other more specialized Input fields (ex. Special input for phone number, TOTP codes) , because we’d imagine these would need to be similar visually.
• This mobile UI library will include conversational UI for mobile, based on the web designs, that Conversations UI kit would / could inherit in the future.

Here's additional background for mobile component:

• WIP Mobile accessibility guidelines contributors are me and Tony Ip (formerly Frontline, now Aion) Feb 2023
• Figjam for the cross-product mobile audit workshop in 2022
• Airtable mobile component list, put together based on the above workshop

[serifluous]

Thanks for sharing, @waijeeho !

Here's some reading we referenced when we designed the original Paste Input (and had considered floating labels, too): http://mds.is/still-floating-labels/

Not trying to dissuading you from floating labels, but we decided against them on web because they wouldn't accommodate long labels (which there are a lot of in Twilio products) and it would make it harder to scan which fields are filled out, especially in complex forms. Native mobile might be a bit different, though, if you're fairly confident that those concerns would be less of an issue on our mobile apps and on smaller screen sizes.

Looking forward to chatting more in office hours!

[waijeeho]

Thank you for sharing this article @serifluous, there were a lot of aspects of floating labels that were new + helpful to consider!

Ability to support long input labels wasn't explicitly discussed with the small cross-product designer group. When I think about it, I haven't come across usage of a super long label between our use cases yet. We decided to try the floating label route to save on vertical height in a mobile context, but still wanted to make sure it could still scale out to more complex forms (combined with controls like switches and selects).

Like you mentioned, I think being in a mobile context but also leaning towards more consumer app-like experiences might have something to do with having generally shorter labels. Long labels are still worth raising with the group anyways, so I'll do that. Thank you! Talk to you soon!

[serifluous]

Here's another research post we've referenced from Material's team when we've thought about floating labels that also goes into accessibility/color contrast requirements: https://medium.com/google-design/the-evolution-of-material-designs-text-fields-603688b3fe03 We can chat more about this tomorrow, too.

[waijeeho]

Summarizing my takeaways from office hours. Posting this in GH to make sure I understood everything correctly, so please feel free to add or correct anything! Thanks for the time.

Feedback:

• Accessibility considerations (in addition to general WCAG guidance where text and background have proper contrast ratio)
  • Ensure input field appears tappable —four-sided border helps with that. (the Material team's article that @serifluous shared in the previous thread goes into detail about this, really helpful)
  • Ensure a minimum 3:1 contrast for border and background (also in the Material team's article)
• Consistency with Paste
  • The input with four-sided border and floating label looks fairly consistent with Paste web (yay! 👏 )
  • There were questions but no objections around our recommendation to use system fonts instead of Twilio Sans in the content / controls of the mobile library.

Questions:

• Q: (After I mentioned that some accessibility practices in the doc linked above may not be prioritized) Why would accessibility elements not be prioritized?
  • I started (confusingly) talking about mobile product work that is parallel to the mobile design library initiative. With regards to engineer and designer resources, as our product teams implement mobile designs using this library, our product team may need to deprioritize accessibility considerations as we go.
• Q: What's the rationale for using system fonts for content / controls on mobile vs. using Twilio Sans?
  • While looking at accessibility best practices articles out there, there's general guidance to use default system fonts for content and controller elements on mobile. Going this route means we lose the Twilio personality through core experience, but makes the UI consistent with rest of the OS and allows us to inherit fonts that are optimized to be readable.
  • We've worked on designs to compare Twilio Sans, SF and Roboto in body / controller contexts. Compared to system fonts, Twilio Sans adds more visual texture to denser bodies of content, and it can be distracting.
  • We're planning on using Twilio Sans outside of core content/controllers, where injecting more Twilio flavor makes sense (e.g. sign in, splash pages, display headings).

Next steps:

• Add error / status icons as an additional suffix icon variant within an Input
  • We removed the prefix icon next to the error text in our mobile Input error states. We previously got feedback from @loreina about icons in Paste web's helper / error text being important for users who need visual cues other than the color of text to understand status.
• Add a focus and hover state back to mobile
  • We initially thought those states were web specific. After talking to @loreina, we learned that those are both valid states on mobile!
• Develop a Select (aka Picker) component based on the Input component
• Develop some use-case specific Inputs (ex. Phone number field, TOTP code field)

[SiTaggart]

our product team may need to deprioritize accessibility considerations as we go

Just a couple of points on this:

1. It's worth noting our CTO views product accessibility as a mandatory product requirement, essentially the cost of doing business.
2. I'm not sure purposely excluding users of assistive technology or users with disabilities aligns with Twilio's magic values and stance of being an anti oppression company.

[waijeeho]

Appreciate the callout @SiTaggart. I wanted to clarify that the Aion mobile team is not deprioritizing every front-end accessibility aspect. There are foundational design considerations like tap sizes and contrast that we will be looking to implement on the component level.

As the product team will need to balance building mobile UI components along with product features, we’re calling out that nailing accessibility will be an iterative process. Our team is actively committed to making a highly accessible product, and that’s something that will take time to achieve as we all gain expertise in the subject.

We’re in the process of defining the accessibility standards and accompanying timelines the product is looking to meet, but will keep folks on Paste apprised of updates.

[serifluous]

Here's the office hours recording: https://www.loom.com/share/1aceaa25998749b88688b650dfee102d. The password is posted in the #help-design-system channel. Thanks for coming to office hours!

[waijeeho]

Thanks for sharing the recording @serifluous!