The most appropriate answer is "it depends", I reckon.
First of all, I'd say there isn't one most appropriate date for the events like graduation (which can be anywhere between this year and past centuries if we take the deceased into consideration) or birth date (idem).
I'd rather ask - can you afford setting a default year for each instance of the date ...
Native controls usually provide a better user experience (more familiar to the user, better platform specific feature support, etc.), but as you noted that varies across platforms.
A few things to keep in mind are:
How and where will this program be used?
If the program is going to be used in a work environment (like order picking in a warehouse) where ...
This might be a bit philosophical. People that don't make many mistakes may hate it because it slows them down, but error-prone folks may appreciate it.
Here's how to decide: would a mistake have (serious) negative repercussions? If not, don't do it.
However, if a mistake deletes a user from a database or something else that is bad, then it would be good ...
NN's suggestion of splitting up the month and date looks like the proper way to do it. Open text fields are prone to so much error, the root cause of all bad data. With open text fields, one needs all sorts of validations to make sure that the value is acceptable. With dropdowns for month and date, these issues will be completely eliminated. For filling in ...
From what you've described, it doesn't sound like there's much point to selecting a start date that is before the current data, as it'll result in the same effect as not selecting a start date at all.
If no start date is provided then the content is already active
So I would assume that the same would happen if they select a start date in the past.
I am writing this opinion considering you are only talking about mobile.
For mobile, if your modal popup covers complete screen then it would be a new screen for user. So the interaction would look like hierarchical drill down. In this case calendar on popup (for user its new sceen) should be ok.
In case of web, if your date picker covers full screen, then ...
Calum, I see two challenges with nested modals:
Users may lose track of where they are, and
Backtracking through multiple modals is tedious.
I've seen quite a few designs that go two, maybe three, modal dialogs deep, and they worked reasonably well, because those modals were highly focused.
For example, here's a screenshot of macOS's Siri preferences ...
Yes, this isn't good practise.
It's depends of type system (for example IOS or Android have other design & implementation for time features)
Important to use generic data selector, which can be implemented everywhere in the smallest amount of time.
The possibility I see is use UI collapse instead pop-up.
You can check the archives page for an older version of the specification: https://material.io/archive/guidelines/components/pickers.html#pickers-date-pickers
Date/Time pickers do not seem to be in the current version of the guides.
Here are my thoughts.
Drop-down: Terrible option almost every time and especially in this case. People do not think about dates as a list, calendar idiom is ingrained in our brains and designers can benefit from it. When users pick the date, they consider not only date, they consider the day of the week, is it this week, next week or the week after that. In ...
You could also simply leave the placeholder to be "Choose a date..." if it's a required field, or "Anytime" if it's not a required field.
Alternatively, if the date picker shows the date after picking, then showing the format (mm/dd/yyyy) might be helpful to outline that the user could possible enter in the date rather than interact with the picker.
I would imagine it's mainly down to lack of consistent support across browsers, mainly Firefox and IE11 (which doesn't work at all). That coupled with the fact you are unable to style it in any useful way so it has the tendency to appear out of place and a bit ugly.
Also the datepicker part is not accessible for keyboard users, so if accessibility matters ...
It looks like it's best to start with a milestone as a starting point.
A workflow, might be the following:
Picking a milestone screen.
On the next screen, the date of selected milestone should be specified by a user.
Then, as shown in the first screen provided in the question, the due date picked. Perhaps, with a slight alteration that is described below.
I don't have any hard research as to what works best, but Google Analytics uses the same shape, but gives an outline for today. You'll see clear contrast. Nevermind the date range label above: I just modified the calender itself.
You'll also see some datepickers using a differing color underline to indicate today. This allows you show both the selection and ...
Seems a fairly simple issue, you could go with icons or text or both, as long as the meaning is clear.
Ignore the blue 'today' that's Balsamiq's and I'm not sure how to get rid of it.
Updated from original question due to comment
Simply make it clear, if the calendar is a date picker that closes, ensure you populate a label or textbox to show the ...
If clicking on the center number in the price field(and on the due field as well) allows the user to type in the number manually, then you're good.
You could also consider the vertical wheel view/picker as I have come across it more often than the horizontal one.
Forget my comment above, bin it and go with the user typing the year on a numeric pad for mobile, no onscreen required for desktop, obviously.
Drop-downs for super lengthy items are a poor user experience.
Putting myself in the user's shoes, I would advise that the current year would be highlighted, where to go up would show years in advance, while scrolling down would be years that have past.
This way, the most current (or most common) year is easiest to find.