Standardised period selection directive

[sfount]

There are many places in our application that require the user to choose a starting date and an end date. Currently every single module does this in a different way. This is bad for three reasons:

• Confusing for the end user who has to learn many different ways to do the same thing
• Rewriting the same component many times is a waste of developer time
• Some of the modules use selections that do not do validity checks and break if the screen is small, it is hard to test every single version of this component.

This is an example of the sales records page - because the window is small the date selection is completely broken.

Another example of this type of selection in the application is in many of the reports - whilst this works very well it is implemented differently in different reports.

I propose that we create a directive that allows a simple way of choosing two dates for reporting/ viewing records/ dashboard etc. The directive could show the dates currently selected very clearly and then allow the user to configure the dates using a modal (This would allow the component to work on any sized screen).

This is a (very simple) mockup of how the directive could show the user the currently selected dates

The user can then press settings to carefully choose dates

I propose the directive lets the user either select their own dates, or provides common dates used throughout BHIMA

• Periods for this fiscal year
• Previous fiscal years
• Common date selections (day, week, month, year)

All of these options will result in a start date - end date format, however it helps the user see what dates they might use for reports and dashboards.

What does everyone think? @IMA-WorldHealth/local-contributors @IMA-WorldHealth/remote-contributors. If this is something you think is important we can discuss what features this should have a when we should start developing this directive.

[jniles]

I am in agreement with everything stated above.

This would be a feature I would be interested in using as soon as possible. A good portion of my last attempt at dashboards (#626) and my current work with the Stock Dashboard (#624) is spent thinking about and parsing dates. This feature would let me simply focus on the logic and rendering of the dashboard itself.

Another benefit of having two dates is that we will have the same database API for most data routes. For many routes, we've had to use a switch statement to flip between CURDATE() and CURDATE() - {{ param }}. With this feature, we'll be able to simplify server logic to simply templating in a BETWEEN statement.

If we are planning on creating a lot of dashboards and reports, I say this feature comes before them.

[jmcameron]

This sounds like a great idea, however I am not sure I understood the proposal completely. If you don't mind me sticking my oar in the waters, a few questions:

• What is the "Month" item, why is it a link, and what happens when you click it
• Why aren't the start date and end date items links that bring up a calendar widget? If you know what start/end dates you want, this is easiest
• Why make the "other options" be a "settings" gear? Maybe it should be "Other options" or something else more meaningful? When I see a gear, I think of actual options/settings, not alternate ways of inputting dates. I like the dialog once you open it.

[sfount]

@jmcameron thanks for the feedback! Ideally I could have put together a mockup for each of the directive screens but I haven't yet had time. I will edit for clarity soon.

1. The month item is just a label (not intended as link - oops!) that describes what category of date period you chose. There is actually no need for this however it may help add context to the selection (instead of the user having to interpret the meaning of the start and end date)
2. That feature is included in this proposal, however the screen shown in the mockup provides a number of discrete options to speed up and simplify the standard use case. If you would like to specify your own start date and end date you could have two calendar widgets (either by choosing 'Specify Dates' or through the custom tab - I haven't fully specified that process in this idea proposal)
3. I completely agree! I'm not sure what icon would be used here, maybe a calendar icon but it could be anything (any suggestions welcome).

I'll update the mockups shortly!

[jmcameron]

It seems to me that you will almost always want the ability to click on either date and update it via a calendar widget. So it seems like it should be available by default. I can imagine a scenario where you want something to report in one week (one year). Then the easiest process would be to use the "Select Other" widget to select to the next week/year, then update the end date by using the calendar widget to fix the end date (back off one day). The use case is a bit lame, but I think you get the idea. Also, you're trying to build up a consistent interface on all pages, so why not make the select either end date by calendar widget the same on all pages?

Maybe "Select Period" instead of the gear? May need some A/B testing to figure this out!

[jniles]

@jmcameron, I think this feature is geared more for dashboards and reports, where you will want to see larger, predefined groupings by default. In my mind, this takes a lot of the work out of complex date logic by allowing the user to see time slices they don't necessarily have to pick out of a calendar. For example, an accountant will want to see fiscal periods, and might not remember exactly the start and end date.

For that reason, I actually think if we are going to be using this were a user needs a calendar, this is the wrong feature for that page -- we should present a calendar. But for a large number of our dashboards and reports, picking any two random dates will take the report completely out of context, and we probably want to limit that. Does that make sense?

[jmcameron]

Sounds good--yes that makes sense (eg, to limit options for some reports). I probably spoke without adequate context. So take my comments accordingly. But it may be useful to add an option for the directive that will enable the calendar start/end date selection capability.

[jniles]

Your comments are very much appreciated :). Yeah, whoever tackles this should definitely push a prototype that we can review together and see what cases it fits best!

[DedrickEnc]

By reading the three reasons invoked by Steven, I agree completely. We should have this directive.