26

When UX Designers tell you: "We need a custom Datepicker"

Comments
  • 4
    When? 😔
  • 9
  • 10
    you answer: No. YOU, WANT a custom datepicker. And YOU are free to design AND CODE it. Or we can be like normal reasonable people and use normal reasonable one.
  • 3
    Say no to date pickers. Just require users to be able to read _and_ write.
  • 14
    If a date picker doesn't let me type into it then it's an awful date picker. Having to scroll down to click my birth year got REALLY annoying by the time I turned 30.
  • 8
    Can't we just use the native html / UI kit ones please? People already suffered making them, why must more blood be spilled?
  • 4
    @Midnight-shcode

    Designer: Oh, come on! It’s very simple!
    (Shows a jpg of his crappy design where you can see how a month looks like.)
  • 3
    @ars1 Surely the easiest, best way to offer a datepicker, by far. By very, very far.
  • 1
    And I need you to learn how to code. Seems like neither of us will be getting what we need today.
  • 1
    @ars1 The browser-integrated date pickers had internationalization issues last time i evaluated them. Ended up just using a text field. I supported the common formats our users know from their daily life - and it worked well.
  • 3
    @Oktokolo They are really pretty good these days. The only real confusion possible is between such dates as 07/09 and 09/07, but I run a UK club sports fixtures site and there's never a problem, despite nearly all browsers originating in the US. One exception, Safari had no kind of datepicker last time I looked, so I just show the expected format in the label for the input "Date (DD/MM/YYYY)" .
  • 1
    @Lensflare cool, so you're halfway done. now just do the other half, calculating which days and dates are supposed to show up for each month from xy years in the past up to 2000 years in the future, correctly displaying them on all devices and screen sizes, correctly responding to clicks on all devices, correctly updating based on the manually entered text input, correctly parsing at least the main text input format, ideally more of them, correctly responding to standard system-wide keyboard controls for all operating systems... as i said, you're halfway done. as you said, it's easy. so don't stop now, and finish it, i believe in you, you can finish it up in a few hours ;)
  • 6
    I quote now a customer...

    It needs to look like an agenda blog.

    2 sides, with pre-cut holes like a collage block.

    Monday to Friday, Saturday and Sunday _must_ be one day.

    Saturday and Sunday must be same bg color, Monday to Friday each the same except for vacation days.

    Vacation days need to have 17 colors:

    1 color for each federal state in Germany, 1 color for international

    ...

    I could go on - but this description is _THE BEGINNING_ of the custom datepicker of hell

    If you question how it got it's name ...

    Lemme repeat: Beginning. This is just a short summary of one of the myriad of insane conditions the datepicker should have.

    Many good souls were annihilated during it's implementation - RIP
  • 1
    @IntrusionCM Welcome back, skeumorphism! We‘ve been missing you.
  • 2
    @IntrusionCM Yep, would totally give em a plain text input.
  • 1
    @IntrusionCM the datepicker alone is an application 😄

    in the end all I want is a text input that explicitly requires the format, hate the scrolling
  • 4
    @DarkSwan text input is one of the most missing things in UX.

    When I can't tab and just enter a fucking date I get angry.

    Plus points when the UX starts correcting stuff and rewrites the inputs while writing .... And you suddenly end up with an entirely different thing.

    -.-
  • 0
    @ars1 that would be too easy. And since most dev don't know html5 standard elements, everything "needs" to be rebuild.
  • 0
    @Oktokolo recheck html5 input type=date in all browsers.

    <input type="date">
  • 0
    @max19931 Why? Did they change it to respect the page's locale?
Add Comment