Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add date input review proposal #113

Closed
wants to merge 1 commit into from
Closed

Add date input review proposal #113

wants to merge 1 commit into from

Conversation

notlee
Copy link
Contributor

@notlee notlee commented Feb 18, 2021

👋

👉 View the proposal here.

👇 leave comments and any more examples below

@notlee notlee requested a review from a team as a code owner February 18, 2021 12:50
@github-actions github-actions bot added the meta Relates to an Origami meta label Feb 18, 2021
@notlee
Copy link
Contributor Author

notlee commented Feb 18, 2021

This is really a proposal to make a proposal, maybe less of a proposal and more: origami do some work. I think this is the most appropriate place still since it pertains to new date input components/patterns.

@notlee
Copy link
Contributor Author

notlee commented Feb 18, 2021

It should be accepted at the point we are ready to write guidelines and or identified components to build

@josh-wade-ft
Copy link

Questions:

  • Is our custom one that's in Spark accessible?
  • If so, can we reuse on ft.com?
  • Is a dropdown style more accessible that a free text field, or vice versa?

Thoughts on different types:

  1. Dropdown- there is a case to use a dropdown style, for example when it comes to card details or any type of form that require a month or year only input.
  2. Custom picker - as you've mentioned, there is good case for this when the user does not know the exact date they want to select (providing visual calendar context for them).
  3. Native - sounds risky for accessibility and browser support.
  4. Free text- Works well in all aspects when the user is likely to know the exact date and/or when only once date input is required (eg. DDMMYYYY)

@notlee
Copy link
Contributor Author

notlee commented Mar 3, 2021

Is our custom one that's in Spark accessible?
If so, can we reuse on ft.com?

I haven't tested it but we could certainly look at wrapping it, or similar third party picker, up as an Origami component if it does meet our needs.

Is a dropdown style more accessible that a free text field, or vice versa?

No I don't think so, provided it is labelled right and grouped with a fieldset.

Free text- Works well in all aspects when the user is likely to know the exact date and/or when only once date input is required (eg. DDMMYYYY)

When you mention free text are you talking about the o-forms style date input with 3 text inputs for day/month/year or a single free-form text input?
Screenshot 2021-03-03 at 16 44 16

@josh-wade-ft
Copy link

josh-wade-ft commented Mar 5, 2021

I haven't tested it but we could certainly look at wrapping it, or similar third party picker, up as an Origami component if it does meet our needs.

I think it's worth investigating, as pickers do have their place in form UX

When you mention free text are you talking about the o-forms style date input with 3 text inputs for day/month/year or a single free-form text input?

Yes the o-forms style!

@notlee
Copy link
Contributor Author

notlee commented Sep 17, 2021

Moved to issue: #248

@notlee notlee closed this Sep 17, 2021
@JakeChampion JakeChampion deleted the date-input-review branch December 23, 2021 16:35
notlee added a commit that referenced this pull request May 11, 2022
Auto merge dependabot dev dependency PRs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta Relates to an Origami meta
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants