0

I am using a html5 native datepicker which does almost everything what I need, which includes

  • Assisted keyboard operability (it jumps from month to date to year without having user enter the separator),
  • localization (different languages are supported as per system language),
  • auto-correction of dates (if user enter month as 13, it auto corrects it to 12)
  • date-picker display is also keyboard operable (I can navigate from one month to another and one date to another via keyboard)
  • browser support is good (almost all latest versions of most known browsers supports it)
  • shows rolling date picker on mobile device browsers.

But concern however is that

  • Date format is not configurable programmatically, so application cannot control date format
  • It responds only to system date format which is not readable by the application (it is a browser based application)
  • User can select the date-format but since it doesn't affect the native datepicker format, so only display-format (labels) can use it. Format selection is not a user-level feature, it is done at organization level.

As a result, there is an inconsistency in date-display format and date-entry format. User cribs about it due to this inconsistency.

I can think of two approaches to deal with this issue

  • find out a new date-picker that gives me all these features and replace my current native datepicker based implementation with that new one. This is an expensive option since a lot of time has already gone in it. Our final option is to develop our own plugin.
  • (More preferably) Somehow communicate the user that this native datepicker can repond to system date format so that user can change the system date format. (what is the best way to communicate this to the user?)

Keeping in mind that this feature will be heavily used while doing data-entry and has high frequency of usage - Which approach is better? or How can I provide a graceful alternate to date format consistency?

1

The system date format is how the user is used to seeing dates displayed. Particularly with the American and European date format differences it can get very confusing.

What you could do is pick a date format that is both unmistakable and easy to type (data entry people will normally prefer to type the date rather than use a calendar control). I would suggest putting the year first, then the month, then the day. Something like this:

<4 digit year> / <2 digit month> / <2 digit day>
  • Franchesca, date format selection has to be done by the organization based on their on contracts with their customers and laws of their respective countries. Check this en.wikipedia.org/wiki/Date_format_by_country We need to support different date formats which is not programmatically controllable from the app. Thanks for your input though. – gurvinder372 Jan 6 '16 at 10:27
  • @gurvinder372 Isn't that your answer then? Just detect the country of the user and look up what the agreed format should be in your db. – Franchesca Jan 6 '16 at 10:52
  • Franchesca, only issues with it is that - User can still select another date format which native date picker is not able to respond to. My only reason to share that link with you was to make my point that - Application cannot fix dateformat for the user. – gurvinder372 Jan 6 '16 at 10:57
  • 1
    @gurvinder372 It might be useful to approach this as a technical problem, rather than a usability problem. If the native control is what is limiting you here, then you might get a better answer by phrasing this as a technical question on StackOverflow. For example, you could ask how to implement a datepicker that does exactly what you want and see if you get something helpful in response. – Franchesca Jan 6 '16 at 11:54
  • 1
    @gurvinder372 The best solution for usability is definitely to not use this control. – Franchesca Jan 6 '16 at 11:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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