MDatePickerView – Quick and Easy iOS Date Picker | Hacker News Reader

MDatePickerView – Quick and Easy iOS Date Picker

github.com

96 pointsmattliuis58 comments

Looks nice overall, but I'm not a fan. It has nothing to do with the implementation itself... just the fact that I view the consistency of the iOS UI toolkit as being more important than fancy looks.

It's a good thing (tm) that no matter which app I open up, the date picker looks the same, and works the same. This is the nice thing about native apps. So I wish we would stop reinventing wheels like this (once again, no offence intended to the author – this is a more of general critique).

None offense was taken, in fact, I'd really like to hear more advice, which got me more motivated. So thanks!

Native apps have built custom UIKit controls since the launch of the app store.

That being said, there is a standard component for this in the Cocoa Touch SDK: https://developer.apple.com/documentation/uikit/uidatepicker

...yeah, that’s the whole point of the comment chain.

Point was that nobody has considered it perfect from day one.

The standard control could use improvements (hm, I'd probably vote for a dictation button that lets me say "next Wednesday" instead of doing math), and we need handsome alternatives like this to nudge it forward. Because user familiarity is critical, I'd prefer to see an implementation that adds functionality with minimal changes to the way we all robotically enter a date/time/whatever. A subclass, if possible.

My portfolio is filled with regrets where I chose something interesting over something obvious.

I think it looks terrific. I really like the notion of trying horizontal vs vertical scrolling.

Plus, I'm a big fan of reinventing the wheel. The final chapter of date pickers has not been written, IMHO, and am grateful for these types of experiments. I can easily imagine a "cover flow" inspired picker being great for certain use cases, like buying tickets.

Per @yoz-y down thread, I agree with need for text input. I like Fantastical's approach. Had hoped it'd become more common.

I have to say I don't really like the iOS date picker. Especially since you're "whipping around" 3 or more wheels (year, month, day, time etc.) in close proximity, it feels very imprecise.

I'd love it if there were also some + and - buttons so I could easily add one month, one year etc.

Fair enough, but it's the standard control. I know how to use it and I expect to see it when I have to set a date in an app.

If only the iOS date picker wasn't so fiddly and annoying to use.

Also, in the calendar app, when creating an event, i carefully select the date and time, and then i scroll down to set an alarm - and about half the time, the date picker takes my scroll so i lose the date i just entered. So annoying.

Instead of this format,

    Col.topAnchor.constraint(equalTo: topAnchor, constant: 0).isActive = true           
    Col.bottomAnchor.constraint(equalTo: bottomAnchor, constant: 0).isActive = true
    Col.leftAnchor.constraint(equalTo: leftAnchor, constant: 0).isActive = true
    Col.rightAnchor.constraint(equalTo: rightAnchor, constant: 0).isActive = true

I prefer:

NSLayoutConstraint.activate([

    Col.topAnchor.constraint(equalTo: topAnchor, constant: 0), 
    Col.bottomAnchor.constraint(equalTo: bottomAnchor, constant: 0),  
    Col.leftAnchor.constraint(equalTo: leftAnchor, constant: 0),      
    Col.rightAnchor.constraint(equalTo: rightAnchor, constant: 0),

])

GitHub example with better readability:

https://github.com/melling/ios_topics/tree/master/ButtonCent...

Not only is this easier to read (IMO), but it is typically "more efficient than activating each constraint individually": https://developer.apple.com/documentation/uikit/nslayoutcons...

I definitely would try this out, it’s nice to hear some advice too. Thanks!

It is easier to read but harder to debug. If you activate all constraints at the same time and something goes wrong you end up with an exception at activateConstraints. Then you would have to figure out which constraint is the cause of the exception. If you activate the constraints one by one then you will get much more helpful exceptions.

The rule that I followed was:

Use activateConstraints if you actually have a performance problem and otherwise activate constraints one by one.

However since this is a framework this rule may not apply because you don't know how it will be used.

Why not just use a wrapper function taking in an array that activates one-by-one in debug and as a group in release builds?

Great idea IMO and wouldn't be difficult to whip up - fighting urge to add to this my native iOS projects right now...

Hacker News ate your formatting. Perhaps you could revisit it and clean it up a little?

Enforcing the `NSLayoutConstraint.activate(_:)` API for this in my codebase has saved so much debugging of stupid errors.

All it takes is forgetting to add `.isActive = true` to a single constraint and nothing will work, and it can be so difficult to spot.

This is not optimal UX, for me. For this one,I soon as the date is far from the starting date, you have to click/swipe an insane amount of time.

I’d love a Windows 7-style calendar date picker for iOS such that it takes the place of the soft-keyboard with a 1-tap button for each day, and zoom-out to select months and years (perhaps with pinch-to-zoom?) - that way there’s no O(n) scrolling.

Windows 10’s Time picker is the absolute worst - clearly designed for touch-based devices it’s horribly inappropriate for mouse+keyboard devices: scrolling with the mousewheel is much slower than it should be, and there isn’t even direct numeric entry from the keyboard, it’s maddening.

Congrats! You have created a really polished looking date picker. While it may not work for everyone, don’t let that diminish your success.

Going from concept to polished completion and publication is a big success!

This has nothing to do with the author's work but what kind of world are we living in where we have a need for more and more polished date pickers?

One where we enter dates through touch interfaces very often?

I mean I find it surprising that we still haven't found or generally agreed upon an optimal UI for date picking.

IMO at least part of it is that not all date picking contexts are the same. Sometimes I want to do something tomorrow, sometimes it's three months in the future, sometimes it's two years in the past. It's difficult to make a single UI control to cover all of those bases.

agreed. sometimes I'm trying to select a date in comparison with other dates and other info (what else is already happening on that date, etc). Sometimes I'm trying to see a range of possible dates, sometimes I'm flexible, sometimes I'm not.

The idea of various use cases don't seem to get enough play in UI component design, imo (or maybe I'm just not reading the right bits?). I'd like there to be some "this component is designed for these use cases - A & B. if you desire use case C, look at component X." and so on.

Please just let me type the damn date! I know when I was born, which bank statement I'm looking for, when I want to fly; don't make me hunt for it.

No, play this date-picker mini-game right now, or YOU SHALL NOT PASS

Can you type in a year? My main problem with almost all date pickers is that choosing a date from a few years back is frustrating.

It doesn't look like it, unfortunately.

"M" is a rather short namespace prefix. Apple recommends using three letter ones: https://developer.apple.com/library/archive/documentation/Co...

It isn’t a namespace, it’s a type-name prefix - Apple has no excuses for not having first-class namespaces in Swift.

It's fine for Swift; classes are namespaced by the module they're in. The problem is that it's exposed to Objective-C, and while the runtime class name will differ because it will be mangled, I believe this can still cause source code-level incompatibility with the unmangled names.

It looks visually nice but lacks some basic date picking concepts that are better seen in other implementations. Notably web frameworks. An issue with this layout is that it is really bad at weeks in the month. (A common date concept) What if you want the second Friday of a month? (Assuming the user is not a date or math-savy person, obviously software should assist all users) Either you'll have to find the first friday and then scroll to the second or guess the second date based on time range of the second friday. A month view solves this pretty well. A greatly executed date picker example is the Angular Material date picker; which in its lack of sheen, shows fantastic function. https://material.angular.io/components/datepicker/overview The Start at function where you can pick Year then month then day is really slick however.

OP, this is a gorgeous date picker with some clever ideas. Great work! As others have noted, clever ideas do mean there’s a learning curve which is not ideal for something like a date picker. However, if this were in an app I use very regularly, I personally wouldn’t mind the initial learning curve for a more efficient input.

I see a lot of requests in this thread for just typing the date. I agree that natural language input like Fantastical is the best experience. I built an open-source NLP date parsing library[1] so I have a lot of interest in this, but even I’ll admit the reason it’s not more common is that internationalization is extremely difficult when dealing with user input. There are 100 ways an English speaker might enter a date, and 20000 ways an international user might. Depending on your user base, it’s often easier to just use a fixed input space.

1: https://github.com/neilgupta/Sherlock

Looks great! Would be nice to have an option to click on year and type it instead of scrolling. Also, it would be great to be able to swipe from January to December (possibly without changing a year) and same with dates. My birthday is on the 26th of November, so it will take ages for me to scroll in one direction. I want try to use your project one day.

They don't do this in the native one either, but I feel strongly that a date picker should always give the user the ability to see a full calendar grid. It's way easier for use cases like "the third Wednesday in June"... and really also easier than swping left or right through dates to get to the one you want.

iOS Developer here. Personally, I am not a fan mostly because I find vertical scrolling/swiping to be much better as faster than horizontal scrolling in your case. The default iOS pickers use the vertical way and I find it to be much better UX.

Design wise, yours does look much nicer though so kudos to that!

Thanks! I'm still trying to be both master at UI/UX.

Would it be possible to explain why one can't simply type a date?

Different countries transposing the month and day might have something to do with it.

Don't think this is entirely a valid argument - use current regional settings.

Forcing the user to use a tighltly packed scrolling control with inertia is not a good idea. Yes, it might look cool in a demo, but - i think - it's a terrible user experience.

(Try it, enter a date a month and a half in the future)

My phone knows I'm en-us. And it knows to show me dates in the mm/dd/yy format. Other users have their phone display the dates in dd/mm/yy or even yyyy-mm-dd.

If the phone knows how to display it, then it should know what to expect when accepting text entries.

This is a great effort, but, as others said - if it was used in an app it would probably piss me off, as I very highly value the consistency of native controls.

Also - this doesn’t solve the biggest issue with the native date picker - just let me type the damn date already.

Is it just me or does the preview gif in the github rendered readme drop a few frames during the animation? I hope that's just the gif, not the library.

Looks great, and probably works best for selecting dates close to some defined date (today, start date, etc).

Is there similar datepicker for Flutter?

Title should have mentioned that it is iOS only.

ok, thank

That's non-optimal UX imho.

I can't understand why it's so hard to get a decent datepicker in general.

You should only:

* Tap on years and months to select one

* Tap on your preferred day

* Being able (programming side) to select a range

* Being able to input your date inside a preformatted text field that can validate it

Windows from 7 to 10 nailed it, period. So bad that's for desktop-only users.

>Windows from 7 to 10 nailed it

Where in Windows 10? Surely not the clock at the bottom-right, in the task-bar? That's probably the bit of UI I hate the most (and on Win10 that's a long list).

Not sure what's better or worse about this that te default iOS datepicker.

I appreciate your all advice, I’m gonna update in the next version.

Looks nice :) shouldn't the post submission be a Show HN?

Am I missing something? Shouldn't this be a Show HN?

This isn't quick. At least not from a UX perspective (judging by the recordings). I don't like that.

Please provide some sort of keyboard for input.

I prefer the native date picker over this implementation, but it also doesn't provide keyboard input.

So, everything is in swift now.

Every iOS developer makes a cool widget, view or library. But doesn't write any tests.

iOS dev community doesn't write tests as does Ruby community, which makes me really really sad.

Reply on news.ycombinator.com