3

My application is using the Material UI style, and I need to provide a date picker to the users.

I have two options:

  1. Use the native date picker when the browser supports it (e.g. on Edge, Chrome), and a JavaScript implementation as fallback for the other browsers.
  2. Always use the same JavaScript implementation for every browser.

What bothers me about solution 1 is that I don't have control on the level of usability of the date pickers of each different browser. In addition, there won't be consistency between the different browsers.

On the other hand, especially on mobile platforms the use of a native date picker might be preferable for performance reasons, power, and integration with the operating system interface. Take as an example the date picker on Google Chrome for Android.

Which of the two options is best from a UX perspective?

Improve this question
4
  • 1
    The native date pickers are generic and not optimal for every situation. They do perform well when it comes to the huge differences between desktop and mobile, but only to a certain extent. This article goes into a lot of depth on the different kind of interfaces you could opt for: smashingmagazine.com/2017/07/designing-perfect-date-time-picker
    – Liam Hammett
    Jul 17, 2017 at 9:42
  • @I'mLiam that's a very nice article!
    – danieleds
    Jul 17, 2017 at 12:23
  • It depends on the use case. Some native datepickers are poor at respecting any limits you may have on the date (e.g. a Date-of-Birth picker with a minimum age of 18). It'll also depend on your users' devices - do you know what the majority of your users use?
    – jezmck
    Aug 16, 2017 at 10:31
  • Why don't you simply detect clients and load the js version in desktop only?
    – Devin
    Aug 16, 2017 at 14:16

1 Answer 1

Reset to default
4

Generally it is best not to force styling from one system to the other.

There is a reason each OS has a particular styleguide when creating products for their platform. It creates a unified scheme that the users are comfortable with and know how to use.

Essentially, you need to consider the UX that your users are already used to in their native device and the behaviour they have come to expect from it.

Following graceful degradation you can consider having an "ideal" design for the devices / operating systems that can support it and from there on allow each OS to apply the native styling as per its guidelines without breaking the functionality or forcing your own styling.

Here is a very interesting quote I found on the matter:

Don’t Mimic UI Elements and Typeface From Other Platforms As you build your app for Android/iOS, don’t carry over themed UI elements from other platforms and don’t mimic their specific behaviors. Because if you replicate elements from one platform to another, you risk compromising the user experience and conversion.

Input fields, check boxes, switches and other functional components should give a native feel. You should use the native components as much as possible, so that people know how to use them, and trust your app with their sensitive data or payment details.

Especially when it comes to Apple apps, you also run the risk of your app being rejected from not feeling "native enough".

A single code base doesn’t mean that the app should look and feel exactly the same on all platforms. Your users will not care at all about the underlying cross-platform technology. They just want the app to behave as expected; they want to feel “at home.”

Here are a couple of articles that expand more on the matter (and where the above quotes were taken from):

https://www.smashingmagazine.com/2014/10/providing-a-native-experience-with-web-technologies/

http://babich.biz/mobile-ux-design-what-not-to-do/

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.