Date-Picker filter for dashboard view not updating filtering date

I have a simple dashboard view that has a detail view with a single date-picker field that updates a column used to filter a table view in the same dashboard.  The idea is that you select a date in the pate-picker at the top of the view and the slice displayed in the table filters for that date.  I've used this approach with ref and enum drop-downs to filter other dashboards.  I gather it is a common pattern.

The date column is a quick edit column in the detail view.

All this works fine except that the the update is not written to the filtering date column until the user navigates away from the date-picker control (by tapping or clicking outside the control).

By contrast, if I use a ref or enum column instead of a date, the ref/enum drop-down control updates the filter immediately without the need to navigate away from the control.

This behaviour seems intrinsic to the the date-picker control and is not significantly impacted by cross-cutting concerns such as Settings/Performance/Delayed sync.  I'm pretty certain that my testing has narrowed the issue down to the behaviour of the date-picker control.

Users find the lack of immediate re-filtering of the table after changing the date filter disconcerting.  Is there a way around this issue?

Solved Solved
0 4 163
  • UX
1 ACCEPTED SOLUTION


@Matt_Apptif wrote:

All this works fine except that the the update is not written to the filtering date column until the user navigates away from the date-picker control (by tapping or clicking outside the control).


Correct.  The same occurs when entering text.  This is by design.  There is no other way to signal to the app that a user is DONE editing the Date.  It would be much worse if the app INCORRECTLY assumed the user was done and the UI constantly was flipping data with every NEW assumption the Date entry was done.

I think the biggest issue is that users forget that they need to click away - even I do after 8 years of building apps.  The control could have an explicit "Done" button on it but that it's still an extra click the user needs to make.  You could have your own "Done", or maybe "Apply Filter" button, but the user then needs to click something every time. to get the filtering to activate. 

The only way to make this better is to show a dropdown of Dates to pick.   This only makes sense if you have a much smaller list of Dates possible for filtering than all of the Calendar Dates.

There just isn't any better way around this.

I hope this helps!

View solution in original post

4 REPLIES 4


@Matt_Apptif wrote:

All this works fine except that the the update is not written to the filtering date column until the user navigates away from the date-picker control (by tapping or clicking outside the control).


Correct.  The same occurs when entering text.  This is by design.  There is no other way to signal to the app that a user is DONE editing the Date.  It would be much worse if the app INCORRECTLY assumed the user was done and the UI constantly was flipping data with every NEW assumption the Date entry was done.

I think the biggest issue is that users forget that they need to click away - even I do after 8 years of building apps.  The control could have an explicit "Done" button on it but that it's still an extra click the user needs to make.  You could have your own "Done", or maybe "Apply Filter" button, but the user then needs to click something every time. to get the filtering to activate. 

The only way to make this better is to show a dropdown of Dates to pick.   This only makes sense if you have a much smaller list of Dates possible for filtering than all of the Calendar Dates.

There just isn't any better way around this.

I hope this helps!

Thanks very much @WillowMobileSys .  Even though text entry works this way I wonder if the date picker is a bit different.  On device, it is presented as a modal that closes when a date is picked or on "backdrop click".  That makes me wonder if the closing of the modal either way is a reasonable criteria for being done with the input.  I'd be happy if it filtered the date when the modal closed.  Your apply filter button is a good idea and I'll investigate that now.  Thanks again.

A no-op action at least encourages the user to tap away from the control. (No-Op, empty group action explained here Click Table View row item, but do nothing )

On a device, it is the devices' date picker used.  And yes it is a modal dialog, so the act of closing it signals "done".  

The browser input controls, I believe, are from a 3rd party.  So AppSheet only has the ability to surface what that control provider made available.  Maybe there is some sort of "done" indicator they can make available.  We can only ask.

Until then we either live with it or create alternatives.

Top Labels in this Space