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! 😏

[Eagle3386]

@devmount you've probably missed that notification, so may I ask if above's proposal is sufficient for implementation or if I can be of any help towards getting this (IMHO) improvement done? 😃

[devmount]

Thank you for the kind reminder 😅

I'm desperately trying to convince you of the proposed icon change here as they're that much beautiful ... You see: I'm pushing hard to earn a mention in your release notes. ... I definitely have to make a mark on ThirdStats - no matter how long or much it takes! 😏

Always a pleasure to read those comments of yours, making me smile everytime 😂

As much as I like your approach, not being able to see at first glance how to reset the filter decreases usability and unifying the two buttons into one makes things more complicated than adding value (IMHO).

I imagine a reset button that's the same for every filter field (currently for folder selection and date range, in future also for contact selection), leaving no doubt for the user how to reset any filter to default state.

Same for the apply button - I think it's best to have the same for every filter field. Currently only the date range filter needs an apply button, since all other filters are select fields which apply the filtering on select.

So what I'll take and implement from our valuable discussion to this point is:

• [ ] prefill date range filter fields with border dates (date of earliest email and today)
• [ ] highlight date range input font color, if it differs from border dates
• [ ] adding date pickers for both date input fields

[Eagle3386]

Thank you for the kind reminder 😅

My pleasure. As always. 😎🥳

Always a pleasure to read those comments of yours, making me smile everytime 😂

Again: my pleasure. Honestly! 🤜🏻

As much as I like your approach, not being able to see at first glance how to reset the filter decreases usability and unifying the two buttons into one makes things more complicated than adding value (IMHO).

While I do agree with the former part of that paragraph, I refuse to accept the latter. I love the 1 button target here & while I insist on not being stubborn, I still find the 2 button solution, well, "visually ugly" - with all respect due to the awesome UI & its effects that can be noticed everywhere else while using your extension. So, let me try & play a bit more with this issue. Maybe I got another approach in a couple of days. We get there, trust me. (Damn, that still sound's a bit desperate too much.. 😅🙈)

I imagine a reset button that's the same for every filter field (currently for folder selection and date range, in future also for contact selection), leaving no doubt for the user how to reset any filter to default state.

So, you prefer an "1 static icon for several, different reset action" approach over its "1 action, 1 icon visualizing the actual action" counterpart? While that truly simplifies everything, I'd like to make a point here and suggest to reconsider this. For example, resetting a date range is completely different to resetting an extension's options: the former doesn't set everything back to factory defaults, but instead to the widest possible range, while the latter completely destroys any customized option. The latter also means the user has, depending on his view, either the option to start from scratch without messing up again or the option to remove any private data (as in resetting a smartphone prior to selling it).

Same for the apply button - I think it's best to have the same for every filter field. Currently only the date range filter needs an apply button, since all other filters are select fields which apply the filtering on select.

I have to disagree due to your own extension's options page which clearly states:

Options are automatically saved.

So applying should happen automatically as otherwise, the user must exactly think those additionally thought you try to avoid in the first place.

So what I'll take and implement from our valuable discussion to this point is:

• [X] prefill date range filter fields with border dates (date of earliest email and today)

Thanks a lot! 🥳

• [X] highlight date range input font color, if it differs from border dates

Yes, yes, yes! 😍

• [X] adding date pickers for both date input fields

Awesome. Just awesome! 🤩❤️

[devmount]

I love the 1 button target here & while I insist on not being stubborn, I still find the 2 button solution, well, "visually ugly"

I agree, I don't like the 2 button solution either, but it's clear. And especially on form elements, I have to prefer clear over pretty (since the latter is always a matter of taste too...)

So, let me try & play a bit more with this issue. Maybe I got another approach in a couple of days.

Of course! I'm looking forward to your ideas! This really helps a lot 💪🏻

resetting a date range is completely different to resetting an extension's options

I totally see your point here, and while I agree with your example, we're talking about filter fields only - not about a filter field and an option (which are way more different). So in my opinion it's totally okay for multiple filter fields to have the same apply and reset button.

Options are automatically saved.

So applying should happen automatically as otherwise, the user must exactly think those additionally thought you try to avoid in the first place.

I agree again! That's why I implemented e.g. the folders filter to apply directly on changing the select field. But with the date range filter (and possible future filters) it's different and more difficult, as I want to prevent unwanted processing.

When the three mentioned points landed, let's see how we can further improve the filter area.

[Eagle3386]

I agree, I don't like the 2 button solution either, but it's clear. And especially on form elements, I have to prefer clear over pretty (since the latter is always a matter of taste too...)

While reading your mentioning in #273, I came up with yet another idea.. 😅

Of course! I'm looking forward to your ideas! This really helps a lot 💪🏻

Well, here's my next SPOC attempt:

• minimum & maximum date input offer a picker, but allow for quick YYYY-MM-DD input (yes, I do remember your desire for fast key typing 😏)
• initial states are always earliest/latest mail, hence Apply/Reset unavailable
• entering/selecting an earliest date waits for input of a latest date, e. g. 1 s, then Apply starts automatically
• • renders Apply button redundant, yet processing is postponed while user still adjusts range(s)
• • already common in search engines with auto-complete support as suggestions update upon changed input
• Reset is enabled after filtering finishing, preventing accidental/excessive processing requests as a bonus
• • recommendation: range inputs should be disabled while processing, too
• after Reset, date range controls are back to their initial states
• changing earliest/latest date instead of clicking Reset works exactly like entering/selecting for the first time

I totally see your point here, and while I agree with your example, we're talking about filter fields only - not about a filter field and an option (which are way more different). So in my opinion it's totally okay for multiple filter fields to have the same apply and reset button.

I agree with your 1 apply/reset button for multiple fields opinion, but - as already stated - love to see both buttons merged into 1 as they, at least from my POV, simply act as kinda toggle towards activating/deactivating the range filter.

I agree again! That's why I implemented e.g. the folders filter to apply directly on changing the select field. But with the date range filter (and possible future filters) it's different and more difficult, as I want to prevent unwanted processing.

Of course, hence taken into consideration for my newest attempt above. 😎

When the three mentioned points landed, let's see how we can further improve the filter area.

Looking forward to! 🥳

[koobs]

Cross-referencing my notes on filter UX from #376

• No 'date selection control'. Manual string format entry
• Cant just type '2020' (or 2020-01) or 'now' or leave From or To empty (to imply 'all the way to the end').

[devmount]

Thanks @koobs. I updated the description with a summarized task list.