Feat: Setup + Document date and time input in a Flutter App

[nelsonic]

As noted by @panoramix360 in dwyl/mvp#140 (comment)
the MVP currently has text input for updating the timer.start and timer.stop:

Todo

• Follow the instructions in the core Material library to implement the DatePicker and TimePicker widgets and allow a person to interact with a DateTime object.

Note: The data does not need to be persisted to a "backend"; just on the device is fine. 📱
But if you want to get creative / use your imagination and make it a "guess the date game", that's fine too. 💭

• Once we've figured out the "basics" of the Material UI widgets,
  explore a more intuitive and faster interface.
  Specifically we don't want a "Modal" (Dialog) for inputting the DateTime. We want the timers input to expand below the item the way it currently does in the MVP so no context is lost.

• Ensure the App is deployed via GitHub Pages as a PWA. 📱

Research

There are many options available, e.g: https://fluttergems.dev/date-time-picker

Please feel free to do more research into this but remember to capture all of it.
And don't get tooo carried away as this feature is meant to be simple. 👌

[nelsonic]

@LuchoTurtle please drop a comment in this thread when you are able to take a look at it. 🙏

[LuchoTurtle]

Just to understand correctly: I'm going to replicate a simple local todo app (the person creates todo items), where each one has a start datepicker and end datepicker, which they can edit. Adding a starting and stopping timer would add more complexity and would deviate from this repo's original purpose.

Is this correct? If so, I'll take this on after getting through other issues

[nelsonic]

No need for Todo items. Literally just display a single DateTime on a page and allow them to update it. 📆 ⌚
This is a UI/UX quest and our objective is just to study the interface for inputting/updating the data. 📱

[LuchoTurtle]

Ok, I'll do that and showcase the values of the DateTime below (like JSON.stringify) just people can see the value change overtime.

[nelsonic]

Cool. What I was saying above about making it a Game that people play to "Guess the Date"
e.g: https://guess-the-date.com/party is way beyond the scope / our needs:

But we can drop a hint to hit in the end of the tutorial. 👍

[nelsonic]

@LuchoTurtle is there enough detail in this issue for you to start work on it tomorrow? 🧑‍💻 📆 🤞

[LuchoTurtle]

@nelsonic As discussed on standup, I'll be finishing dwyl/dart_cid#6 (comment) since it was already in-progress last time I picked it up. After this, the package should have less "activity" since it should be "complete", in a sense.
I'll work on this issue after I'm done 👌

[nelsonic]

Cool. Agree with finishing the work you started to free your mind from it. 😉
But this issue/quest is definitely more product-focussed. 📱 👌
Thanks. 🙏

[LuchoTurtle]

From my research and having looked at the link you've provided (https://fluttergems.dev/date-time-picker/), it seems that 99% of these date and time pickers use modals, which is funny, since in most cases, changing date and time are often found in inline editing scenarios.

An issue has been opened flutter/flutter#76053 regarding this issue. Some people wanted to use the default Material Date and TimePicker widgets without a dialogue. It's been argued that it goes against "Material guidelines", so it seems it's gotten stale ever since.

There are a few candidates (e.g. https://morioh.com/a/f191fd917990/flutter-date-pickers-without-dialog). However, most use a ton of space and just print out the calendar, which is not desirable in our scenario: we don't want a calendar to be shown to the person, it takes too much real estate.

To fulfil the requirement of "No Modals 🚫", though, I have a question regarding mobile devices. Quite literally all of the pickers I've found make use of the "modal" or "pop-up" from native Android and iPhone.

Does this make sense on mobile devices? Should we go for the native approach or still be reluctant to use modals/dialogues/popups in mobile apps? Should we just avoid these in the web version?

I understand the value of not using modals. They can't be bookmarked or shared as links; they can't be opened in new tabs; they don't work well with the Back button. These are issues that occur on browsers but not necessarily on mobile apps. I get that changing the context is still an issue but given the screen constraint, does it make sense?

I can continue searching but I haven't found well-supported projects that properly do inline date and timer editing. The only viable route that I'm aware of is using a TextField with form validation which follows a strict format.

[nelsonic]

@LuchoTurtle as discussed on our Standup call this morning, 📞
our objective with this tutorial is to have something we can use in our App ASAP. 🏁
Yes, sadly, the "standard" (Material UI) Flutter widgets are Modal. 🙄
We can "setup" the project with these widgets to get up-and-running as quick as possible.
But then immediately inform the reader that while these are widely used in practice,
they are are poor UX and we've seen older people get confused/frustrated with Modals in the past.
So we prefer an "inline" approach every time.
Buuuutttt ... if we are forced to use Modal to get the first version shipped, we will.

Thank you for your research and linking to the issues it's good context for anyone else reading this in the future. 👌

[LuchoTurtle]

@nelsonic yes, I understand what you are saying. I understand that using modals, especially in web browsers, is a no-go.
I was just wondering about pop-ups like those found in native iPhones. For example:

Are these a problem? Because even if we were to go through inlining, a keyboard would be shown as well in the same area of the popup. So why not show the popup like this instead?
Hence why I was wondering if there was a clear difference between web browsers and mobile apps.

Thanks for answering 👌

[nelsonic]

Sadly, 20-something hipster designers in San Francisco have made Modals normal...
The iPhone has plenty of horrible UX and poor in-app feature discovery. There was a thread on this just yesterday: https://news.ycombinator.com/item?id=36846520

The "scrolling" input for dates and times is not great interface design,
but being Native it means people are already familiar with it.
Which means we can (reluctantly) use it and people will understand it.

We need to maintain a consistent interface across devices and experiences.
As soon as the Flutter App has feature-parity with the MVP it will become the App and we will no longer need the MVP.

[LuchoTurtle]

I've created a draft PR #2 which will address this issue.
I've already have implemented and documented a demo with both timePicker, datePicker separately and together, as well.
I've tried finding solutions that would be inlining and I couldn't found what I was looking for. It seems likely that the only way to go is to use a TextField that is formatted and is validated as the person inputs, following a given regex.
This is peculiar, because using Material's pickers have an "input mode":

Which does exactly what we want to do: a TextField-like input where one can type the wanted date and get instant feedback (except that we don't want a modal).

I might have to take a look into the source code on this one 🤔

[LuchoTurtle]

Time also has an input mode, which is fully typable.

From flutter/flutter#76053, I wish they offered an option to not use this as a modal.

[nelsonic]

Can the time input be 24h instead of “AM/PM” to reduce clutter?

[LuchoTurtle]

Can the time input be 24h instead of “AM/PM” to reduce clutter?

I think we can, using MediaQuery we can force military time via localization.

[LuchoTurtle]

I'll probably reduce the scope of this to just demoing Flutter Material and Cupertino components, with possibility to keep track of changes, and testing them.
The reason is that there is no discernable way of actually not easily using a Modal that doesn't take me less than a handful of hours of research, scouring through source code and trying to replicate this behaviour "modal-less" (see https://stackoverflow.com/questions/69513759/can-i-possibly-always-display-the-this-timepicker-widget).
We're not alone on this (flutter/flutter#76053).

[nelsonic]

Today I had to book an Uber car. The interface for scheduling pickup uses Cupertino but it's not a modal/dialog:

Most likely it's a Swift / Objective C.