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

use native input types (on mobile) #228

Open
Haroenv opened this issue Aug 29, 2016 · 14 comments
Open

use native input types (on mobile) #228

Haroenv opened this issue Aug 29, 2016 · 14 comments

Comments

@Haroenv
Copy link
Member

Haroenv commented Aug 29, 2016

In smaller screens the custom inputs don't really work, since they're too small. However an <input type="date"> and <input type="time> are well supported and will offer a better experience on small screens.

@pietercolpaert
Copy link
Member

@xavez what's your opinion?

@Haroenv Can we have a demo implementation of that in hyperRail to see how that would work?

@xavez
Copy link
Member

xavez commented Aug 30, 2016

I think this should definitely change, but I don’t know enough about angular to do it myself. Ideally, the following happens:

  • Check for support of date input type with modernizr or vanilla JS
  • Use native date input type if it is supported
  • Load JS and CSS for a date picker if they are not supported

Concerning the time input, I think a custom implementation is probably the most user friendly. I’ve implemented this once:

@Haroenv
Copy link
Member Author

Haroenv commented Aug 30, 2016

I like how the time input works on iOS though, it's just one input to open vs two. Screenshot for reference:

@xavez
Copy link
Member

xavez commented Aug 30, 2016

@Haroenv correct, actually, I was mistaken in my comment, the same principle applies there: check for support, otherwise go with custom implementation

@Haroenv
Copy link
Member Author

Haroenv commented Aug 30, 2016

Progressive enhancement would consider desktop chrome as having support for input type=date though, I'm not sure if that's what we want ...

@xavez
Copy link
Member

xavez commented Aug 30, 2016

It’s an improvement over the current situation in any case. We don’t need to come up with the perfect design – we can iterate on it later I think.

@pietercolpaert do you have usage statistics for irail.be? Browser, Browser Version & Device?

@pietercolpaert
Copy link
Member

Fiddle which enables/disables when input type date is supported/unsupported: http://jsfiddle.net/2AaFk/1/ → I think on a desktop chrome, the input field looks horrible. It looks "okay-ish" on firefox. Is there a way to style this in a nicer way?

Analytics for browsers and whether or not on a mobile phone

screenshot from 2016-08-30 12-18-41

@Haroenv
Copy link
Member Author

Haroenv commented Aug 30, 2016

I think we should only use the native input method for Android and iOS, since the desktop implementations look pretty bad IMO.

The okay-ish on FF isn't the native field, but jQuery UI, which is used in that fiddle as a fallback.

@xavez
Copy link
Member

xavez commented Aug 30, 2016

You can check for touch events and load the appropriate stuff then.

But like I said, anything is better than the current implementation.

@xavez
Copy link
Member

xavez commented Aug 31, 2016

Who knows how to make this work in Angular? I can make the "prototype" code, but I have no idea how to bind the input to the actual search action.

@pietercolpaert
Copy link
Member

@xavez it's pretty straightforward. I have made a mock-up in this branch: https://github.com/iRail/hyperRail/tree/fix-228

What I had to change: development...fix-228

@xavez
Copy link
Member

xavez commented Aug 31, 2016

Oh cool. Guess I’m not needed for this then ;) 👍

@pietercolpaert
Copy link
Member

@xavez how do you mean? I implemented this for you to experiment with UX ;) Right now the UX in this branch on both phone and desktop is bad, yet maybe it's possible to make it better?

@xavez
Copy link
Member

xavez commented Sep 1, 2016

Great, I’ll have a look!

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

No branches or pull requests

3 participants