Enrich UX for date range filter

[Eagle3386]

Is your feature request related to a problem? Please describe.
As kinda "follow-up" for #161, I'd like to request the UX enrichment of the aforementioned filter controls.

Describe the solution you'd like

1. Adopt modern HTML5 date input controls by switching both filter input controls to the date type which in turn removes any need for input fixing/parsing, because we're Firefox-based & therefore any input type supported there is supported by Thunderbird, too.
2. Change the preceding label to Date period or, better yet, Date range since that reflects its actual functionality probably better than the current label's, hour-based filtering, suggestion.

Describe alternatives you've considered
Using the current implementation is good, but as always: the more UI & UX comfort for the users, the happier they are & the better the reviews are. 😉😅

---

Edit (2022-06-12): Here are the currently open tasks I agree with summarized

• Date input fields provide a date picker. Only dates between the earliest message and today are selectable. Manual entry of dates is still possible.
• Possibility to type '2020' to automatically insert range from '2020-01-01' to '2020-12-31'
• Possibility to type '2020-01' to automatically insert range from '2020-01-01' to '2020-01-31'
• Possibility to type 'now' to automatically insert the current date
• Leave From empty to imply 'all messages from the earliest message on'.
• Leave To empty to imply 'all messages until today'.
• Prefill date range filter fields with border dates (date of earliest message and today)
• Indication, if date input differs from border dates (e.g. highlight date range input field)

[Eagle3386]

I've went "all in" & adopted the changes myself via 2 seperate PR.
Since I've never worked with Vue.JS, please notify me of any possible improvements - initializing the Date object for max/min values twice is probably a good example.. 😉

[devmount]

Hi Martin,
thank you for these suggestions.

1. I actually used input elements of type date at first. But I decided against it because of the following two reasons:
   • I found the calendar popups to be a bit buggy - especially on Thunderbirds default dark theme (coloring is really confusing there)
   • Picking a date in the calendar popup takes more time than typing 6 digits, especially for older dates. Try typing 180101 > TAB > 191231 > ENTER. Now try the same with picking these dates in a calendar popup. You'll feel the difference... I know that this takes a little time to practice though.
2. Totally with you, thanks.

Alternative for 1.: It's of course possible to implement both solutions, make the calendar popups the default input method (as most users are used to it) and provide an add-on option "advanced input mode" for people like me, who prefer typing dates. What do you think?

I've went "all in" & adopted the changes myself via 2 seperate PR.

Thanks for this 👍🏻 But please always await feedback on your issues first and let yourself be assigned to it before implementing something that may be rejected. It would be a pity for your time.

[Eagle3386]

Hi Martin,

Hey Andreas,

thank you for these suggestions.

my pleasure - as always in this repo of yours! 😎

1. I actually used input elements of type date at first. But I decided against it because of the following two reasons:
   * I found the calendar popups to be a bit buggy - especially on Thunderbirds default dark theme (coloring is really confusing there)
   * Picking a date in the calendar popup takes more time than typing 6 digits, especially for older dates. Try typing `180101` > TAB > `191231` > ENTER. Now try the same with picking these dates in a calendar popup. You'll feel the difference... I know that this takes a little time to practice though.

Thought a bit longer about it, please see below for the outcome.

2. Totally with you, thanks.

Awesome, thanks! 🤩👍🏻

Alternative for 1.: It's of course possible to implement both solutions, make the calendar popups the default input method (as most users are used to it) and provide an add-on option "advanced input mode" for people like me, who prefer typing dates. What do you think?

1. I was that eager about developing something useful for Thunderbird, I modified the files right in GitHub's Web IDE - which is why I didn't notice that coloring issue you're referring to.. 🙈😅
2. That "speed input" was triggering a longer UI/UX thinking process inside my head - in fact, I even dreamed about several ideas last night.. 🙈😅
3. Switching between both input methods (picker & textbox) is obviously doable, but is it really the best solution? I highly doubted that, even after several rounds of thinking - which led me to rethink about the whole workflow..
4. Instead of allowing 2 input methods, there should be only one, usable as fast as possible, for any type of user - which is why I'd like to propose this UI/UX change:

• fill both inputs with default values, i. e. date of the earliest mail & today's date
• since most users probably won't change all values (year, month & day) at once, requires way fewer user actions for range modification
• furthermore, the currently active date range is immediately visible to the users, right from the get-go, making both, its functionality & usability, even easier discoverable 😍

In case there's a UI issue with using the date picker, it should be reported to Mozilla - working around bugs is our daily business as developers, but avoiding to use a component just because it's buggy while at the same time still actively developed (instead of abandoned code) seems to go against the principal of developing software in the first place, right? 😉

Thanks for this 👍🏻 But please always await feedback on your issues first and let yourself be assigned to it before implementing something that may be rejected. It would be a pity for your time.

See 1. above for why it happened. I promise to await feedback next time - already proven by this comment 😉😎

[devmount]

my pleasure - as always in this repo of yours! 😎

😊

1. I see - well PRs should be locally tested at least once to ensure against regressions. But I like this eagerness of yours 😎
2. Wow you're really into this issue 😂
3. & 4. Thank you for your suggested solution. I agree that it would be much better to provide the default values here (earliest date + today) making the date input fields required to be filled. If someone empties a date field and clicks outside of it, it will be filled with the default value again.

In addition to this, what do you think about adding a calendar button next to the corresponding date field to optionally open the date picker of TB? Something like this:

See 1. above for why it happened. I promise to await feedback next time - already proven by this comment 😉😎

😂 👍🏻

[Eagle3386]

1. I see - well PRs should be locally tested at least once to ensure against regressions. But I like this eagerness of yours 😎

Thanks a lot & thanks for bearing with me! 😉

2. Wow you're really into this issue 😂

Absolutely - especially since ThirdStats is already on the path for being even more awesome than GMail Meter could ever be! 😍🥳

3. & 4. Thank you for your suggested solution. I agree that it would be much better to provide the default values here (earliest date + today) making the date input fields required to be filled. If someone empties a date field and clicks outside of it, it will be filled with the default value again.

Awesome! 🤩👏🏻

In addition to this, what do you think about adding a calendar button next to the corresponding date field to optionally open the date picker of TB? Something like this:

I do like the idea, but the concept art could be improved:

• Make the calendar input styling more like a button:
  
• Remove ✔ button (submission/validation should start upon change commit of start/end, no additional click(s) needed)
• Exchange reset button's icon as it looks more like "cancel" or "delete" than "reset" or "revert".

[devmount]

In case there's a UI issue with using the date picker, it should be reported to Mozilla

Of course you're right. I will test the datepicker again in TB 85 and see, if this was already fixed.

Make the calendar input styling more like a button

To make clear it's actually clickable - agreed 👍🏻

Remove ✔ button [...]

I wouldn't do this. Every change in the date fields would directly start a new processing. Especially for larger date ranges this could take some time. Imagine someone wanted to change both date fields. After changing one field, they would have to wait until processing finishes to change the other. This would be kind of annoying. Having an Apply-Button gives more freedom to make changes without unwanted triggering of processing.

Exchange reset button's icon as it looks more like "cancel" or "delete" than "reset" or "revert".

I think the X is quite common to clear a filter. Do you recommend something? I'm using tablericons for ThirdStats. Maybe one of these:

[Eagle3386]

Of course you're right. I will test the datepicker again in TB 85 and see, if this was already fixed.

Awesome! Let me know, if I can be of any (further) help! 😎

To make clear it's actually clickable - agreed 👍🏻

Awesome²! 😉 Though, I feel a bit sad that my PR is now mostly obsolete which in turn reduces my contributions to your awesome project which a lot, from my point of view at least. 🙁

I wouldn't do this. Every change in the date fields would directly start a new processing. Especially for larger date ranges this could take some time. Imagine someone wanted to change both date fields. After changing one field, they would have to wait until processing finishes to change the other. This would be kind of annoying. Having an Apply-Button gives more freedom to make changes without unwanted triggering of processing.

I see... Let me think about this for a second...

Coming from a C# background, I know off cancellation tokens which can be passed to tasks which - upon reception - immediately cancel themselves. Does Vue.JS offer something similar? If so, my suggested button removal wouldn't hurt anymore, because further changes would simply cancel prior executions & re-execute then.
However, if unsupported, I agree with your choice being the best possible - for now as I do love reduced, yet powerful, UI & maybe Vue.JS supports task cancellation at a later time.. 😉

I think the X is quite common to clear a filter. Do you recommend something? I'm using tablericons for ThirdStats. Maybe one of these:

Well, whenever it comes to filtering, I always have that "Y"-shaped icon for enabling & the same icon, but with a 50% smaller, red "X" overlay in its lower-right corner for disabling in mind.. 😅
That being said (& with the aforementioned discussion about removing the revert icon), I'd like to propose unifying both buttons into one, using either Tabler Icons's

• filter & filter-off or
• viewport-narrow & viewport-wide
  for representation of "unfiltered", i. e. "oldest & today", & "filtered to custom range".
  IMHO, especially the latter pair really visualizes the control's meaning of narrowing/widening the possible date range, doesn't it? 😎

Really looking forward to read your thoughts!

Until then, stay healthy & have a good one! 🥳

[devmount]

Awesome! Let me know, if I can be of any (further) help! 😎

Will do, thanks!

which in turn reduces my contributions to your awesome project which a lot

You already did quite a lot by filing reports and requests and sharing all your good, detailed thoughts, ideas and feedback. I don't see how one obsolete PR could diminish that.

Does Vue.JS offer something similar?

Afaik there's no such functionality.

I'd like to propose unifying both buttons into one

How exactly do you imagine that? Can you sketch it maybe? I like your interpretation of the viewport icons, I'll definitely try those out and post some screenshots here. We can then decide, which looks best.

Thank you, stay well too!

[Eagle3386]

Will provide sketch tomorrow, time for 🛏 now.. 😅

[Eagle3386]

@devmount Sorry for being that late, but both, day job & private engagements, took away all spare time up to now.. :(
Though, I managed to create sort of an UI sketch:

Maybe both button icons should be exchanged with each other as normally, such icons show what happens after being clicked instead of what has happened, i. e. prior to clicking them.
But in this particular case, i. e. with reduced UI, brighter digit colors & even brighter button icon color, to me it seemed best to rather reflect the current than the possible future state.. 😉😎

[devmount]

Sorry for being that late

No reason to be sorry for - we all have a life next to OSS 😅

Many thanks for your sketch! 👏🏻 I like the idea a lot but see the following problems:

• While the shrink&expand buttons look great here, they are quite unfamiliar in this context. I'm afraid people will be confused, especially (like you already mentioned) because you don't know, if they represent the current or next state. This could be solved by a tooltip popping up on mouse over, but I'd rather stick to more conventional icons here
• Now that you removed the "clear filter" button: If the user has set an active state, how do they reset to the default state vs. how do they apply changes to the currently active dates? I don't see how apply and reset functionality is possible with only one single button.

I love the concept of highlighting value and button icon color in active state, that clearly shows, when a custom date range is set or when the default dates are set.

[Eagle3386]

No reason to be sorry for - we all have a life next to OSS 😅

😅👍🏻

Many thanks for your sketch! 👏🏻

My pleasure. 🥳🤘🏻

I like the idea a lot but see the following problems:

• While the shrink&expand buttons look great here, they are quite unfamiliar in this context. I'm afraid people will be confused, especially (like you already mentioned) because you don't know, if they represent the current or next state. This could be solved by a tooltip popping up on mouse over, but I'd rather stick to more conventional icons here

I'm desperately trying to convince you of the proposed icon change here as they're that much beautiful (for me at least 😅), so I'd like you to consider this real-world scenario:

• Brand new user enters the page, minimum/maximum date & button are at their defaults.
• Upon input of either date, the button's icon switches to the narrowing one
• Upon button click, the icon color becomes the ThirdStats's purple color (or whatever color you may like), maybe even a color animation to ThirdStats's bluish color back & fourth until stats finished filtering (you're into user entertainment just like me, I'm 100% sure 😎)

• Now that you removed the "clear filter" button: If the user has set an active state, how do they reset to the default state vs. how do they apply changes to the currently active dates? I don't see how apply and reset functionality is possible with only one single button.

• Refining the filter(s) leaves the narrow icon untouched, but does run the color animation each time while filtering is in progress.
• Reset is done via clicking the narrow icon button, turning it into the wide icon, again maybe with the color animation (possibly even in reversed direction for even more contextual guidance)

I love the concept of highlighting value and button icon color in active state, that clearly shows, when a custom date range is set or when the default dates are set.

There. You. Go. & thanks for that "hint" - it was the spark I've needed to come up with above's scenario.
You see: I'm pushing hard to earn a mention in your release notes.

And yes, that's simply because the added "nerdyness" wasn't listed in 1.3.0's changelog (as expected for any geek/nerd feature - wouldn't be that much fun otherwise, right? 😉). But since you also didn't hint at it & using ThirdStats even for my work's collective mail account (with >10 years of support tickets! 🥳) means that much joy for me, I definitely have to make a mark on ThirdStats - no matter how long or much it takes! 😏