Hacker News new | past | comments | ask | show | jobs | submit login

Almost every date picker I've used is terrible. If you are reading this and are responsible for adding a datepicker, please, please, please do at least the following:

1. There should be a textbox allowing me to type a human-readable date/time (e.g. "monday 5pm" or "july 7, 2015").

2. The textbox should be selected and ready to type into as soon as the datepicker is opened

3. There should be a short list of previously-typed dates because often, for a given date in the UI, the same date is used multiple times in quick succession

4. There should be a typical month view with days of the week visible, in case I'm on mobile

5. The current date should be highlighted on the month view.

6. I should be able to pick the month and the year in at most two taps each (i.e. dropdown for each), no matter how far back in time I need to go.

Shameless plug: we recently implemented an exceptional date picker on momentcrm.com because of how frustrated we were with the default browser experience.




In my web apps, I make dates text boxes that can handle inputs like “next Thursday”, “Monday at 5p”, etc by running the inputs through https://github.com/mojombo/chronic

I like the idea of inputs being able to make sense of as wide of a variety or formats as possible.

For number inputs I’d like to build into Rails something that can handle basic math expressions. For example, a person can enter “120 / 2” in an input and get 60. This is useful for expense apps where you need to expense half of something.

If folks are interested, I can open source these bits. I’d like to expand them as much as possible to handle an even wider variety of inputs.


So you do you handle every language or just English. Can I write 来週の木曜日? or "hier" etc...


That's a cool library. I note that WolframAlpha handles this type of stuff readily. Does anyone ever bundle Wolfram products into theirs to handle natural language type things? I'm not immediately sure of the licensing framework, but it would seem nice to be able to do that.

Edit: It seems that WolframAlpha does have an HTTP API.

https://products.wolframalpha.com/api/documentation

I'm curious if anyone has used it. It costs but it could save an immense amount of time.


Embedding wolframalpha is probably overkill, when all you need is simply a small arithmetic expression parser and to understand expressions like "next month" or "2 days ago", which even tools like GNU date support.


Hat tip that you mention GNU date. I am surprised each time I use that feature and it manages to produce the date that I wanted.


For dates, probably, but I was more curious about other natural language use cases.


Chronic is an awesome date library, agreed.


In your (1) case, how do you handle input that is m/d/y vs d/m/y - there are cases where cannot identify which convention has been used.


> there are cases where cannot identify which convention has been used

You could always just ask them. "I'm sorry but we had trouble parsing your date. Please indicate the correct date:

_ Saturday the 12th of March, 2032

_ Wednesday the 3rd of December, 2032

_ Neither, let me choose again.


how about placeholder="mm/dd/yy" or placeholder="dd/mm/yy"?


>> Almost every date picker I've used is terrible.

If you think date pickers are bad, you'll love time pickers, e.g. https://vuetifyjs.com/en/components/time-pickers/


I quite like the iOS time picker, but agree the analogue clock style that I think Android popularised is awful. The iOS one also gives a number keypad if you tap the wheels so you can enter that way if you prefer. It’s a shame they don’t do anything similar for dates.


I've never see the analog style clock one before, wow that is garbage. I'm not a fan of the iOS style time 'reels' either, but like you say, at least it opens a keypad if you click on them.


To break down why this picker is bad, here are several UX snags I immediately ran into.

1) It was not obvious how to set minutes, and I spent several seconds trying to get the hour hand to go in between hours.

2) When I let go and it snapped to minutes, it was not obvious to me how to go back and change the hour I had just input incorrectly. Then after I input minutes I expected it to jump back to hours but it didn’t. This is especially bad if your first interaction is a single touch rather than a press and hold, as it will jump with a wrong input and no obvious way to go back before you can even process how the interface works.

3) I have to look at different areas at the same time to select a time. My finger is trying to scroll a circle (where btw my finger covers the number), but I have to look above to see what the input is.

4) The above was even trickier in the minutes inputs, since there were not markings for sub-5 minutes.

5) It was not obvious that the top bar was clickable as an input area to select am/pm, especially since clicking the top bar would not otherwise allow you to input the time.

6) It’s not obvious with the switch to minutes / seconds that the units have switched. Need some representation of this on the clock face itself.

Some major ticks on all inputs and minor ticks that pop up on the minutes input would help a lot with 1, 4, and 6. Could be subtle markings, but would help quite a bit imo. But really this didn’t need to be anything other than a simple text input.


Those aren't so bad, they're reasonably intuitive to anyone who knows how to read an analog clock, and though they're easily fat fingered, you do one click for hour, one for minute and AM/PM in the non 24h versions. Imagine a scrolling time picker where you couldn't scroll the hours, only the minutes. That's what common date pickers are like.


I'm still perplexed that this isnt how every website works.

The absolute worst are date pickers that grey out unbookable dates to look like past dates and default to one week from now, leading me to believe, if I'm not careful, that Im booking a ticket for today.

Seemingly no website that lets you book things has sensible date UX.


Some of these are really great ideas! But I think they should be relegated to an external library or perhaps a web component. The issue here is this is the HTML datepicker. The picker itself isn't well-defined but things like being able to type in human-readable data/time and having it interpret that would likely conflict with the HTML standards already defined and be extremely difficult to define further. Not to mention you could only really do something like that on desktop and the issues pointed out in the post are dealing with mobile date pickers


Very nice site. I was clicking around trying to find a sample of your date-picker and noticed that the "Free Courses" link is not working properly. I believe it is treated as a relative link as it takes me to:

https://www.momentcrm.com/https://academy.momentcrm.com/


Also, I’ve repeatedly come across date fields that force me to enter the month in two digits, i.e. 01 for January. What’s up with that?


That's the default in Germany (and Europe?). Writing out the month is somewhat rare, although it does happen.


I think GP meant that it's two digits instead of one (you have to type 01, not 1).


I’ve seen that, but I’m ok with it. I just assume it’s much easier to parse/check the entry if there’s a full 8 digits (mmddyyyy).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: