Monitor Module "Last"

[QISPSK]

The last 6 days/6 weeks/6 months on monitor module should include today/this week/this month.

Since we want to keep “last” consistent with how DHIS2 uses “last”, can we change this to “previous” or some other word so as not to generate confusion?

[ifoche]

I just want to clarify. This change is very easy to do, but I think that this will probably lead us to a refactor on the periods the app is working with, that may make you re-think everything and take more time, and that's why I used complexity med label. Let me explain why: We currently have 3 places where we ask for a period to the user:

• The login, when we ask for the amount of data the user want to download
• The sent surveys list, where we added this new filter
• The monitoring table, where we asked for the 6m/6w/6d filtering

So if we want to make the user understand what (s)he's seeing, we need to harmonise them in some way. Because if you download last 3 months, and that gives you data that is partially represented in the 4th previous month on the monitoring table...maybe that can be a bit confusing.

In DHIS2 "this" periods include current period and "last" periods doesn't include current period, as you already know, so "last 6 months" doesn't take current month into account. Until this release, when we said "last 6 months" in the app, we were meaning exactly 6 months from now...so if we're Apr 20, we were meaning from October 21 to today. But DHIS2 would mean from October 1, to March 31.

What is currently implemented tries to keep consistency with monitoring filters & login data download options in one hand, and with DHIS2 behaviour in the other. The filters are the following: Present in DHIS2:

• This week
• This month
• Last week
• Last month
• Last 6 months

Present in monitoring & login:

• Last 6 days
• Last 6 weeks
• Last 6 months

Currently, Last 6 days & last 6 weeks is taking current period into account, because otherwise there wouldn't exist any way to represent in monitoring the data entered today. For the rest, we followed the DHIS2 behaviour so anything that can be asked in DHIS2 is directly comparable.

I like your idea of changing those "last" periods by "previous" on monitoring, but then for me, it would make sense to do the same on login screen, and maybe not only change "last" by "previous", but include "previous" and keep also "last", so the user has a way to ask for numbers that can compare against a DHIS2 server on monitoring table. What do you think? does it make sense?

[QISPSK]

@ifoche Thanks for the explanation above! We had a longer discussion about what we want "last" to mean and have come to the consensus that it should indeed include the current period. We don't, however, want to cause confusion between DHIS2 and the app and would propose changing "last" to "latest" (i.e., Latest 6 months/weeks/days). This filter would be universal across the login, monitoring, and sent screens.

The selections for each screen would then be:

Login:

• Latest 6 days
• Latest 6 weeks
• Latest 6 months
• No data

Monitoring:

• Latest 6 days
• Latest 6 weeks
• Latest 6 months

Sent:

• Today
• This week
• Last week
• This month
• Last month
• Latest 6 days
• Latest 6 weeks
• Latest 6 months

The logic behind the expanded options for the sent screen is to give both the provider and the visiting officer more fine-grain control over the sent screen in case they are looking for errors in individual surveys.

I think in v1.4 we will need to consider how to revamp the monitor module to allow more dynamic filtering options so that it can match DHIS2 while still being useful for providers, but we can consider options for this down the road.

Thoughts?

[ifoche]

@QISPSK sure, that make sense if it make sense for users, and you're the one in the best situation to know that, so we will do it as you said if you move it to the ready column.

So just to confirm, we would be: 1) using the current period for login. That means changing last to latest too 2) using the current period for monitoring. That means changing last to latest too 3) not using the current period for Last week/month, that will only show the week/month before the current week/month, but using the current period for latest 6 days/weeks/months (is that ok or last week/month are typos?)

Then we need to decide what does "include current period" means exactly. Let me explain. If we say "Latest 6 days" and it's 22:35 on Tuesday 25, we can interpret: 1) From 00:00 Wednesday 19 to 23:59 Tuesday 25 2) From 22:36 Wednesday 19 to now

What option would better fit your expectations? Thanks!

[QISPSK]

@ifoche You are correct, "Last" is not a typo above. We want to keep "Last week" for providers and "Last month" for officers who will be doing data validation in the field. Items with "Last" should not include the current period and should match the functionality found in DHIS2.

As for what we mean by "include the current period," I'm not sure I understand the differences between the option choices presented. It would be nice if it could follow the logic of how DHIS2 uses "This" for periods, however it would just stretch further back. So if a pull on DHIS2 for "This month" is done at 15:49 April 26, I would assume (though I can't confirm this) that DHIS2 would pull data from 00:00 April 1st to 15:49 April 26.

For "Latest 6 months," we would want something similar. Pulls would include the current month plus the last five months. For example, if a "Latest 6 months" pull started at 15:49 April 26th, we would want to see data from 00:00 November 1st to 15:49 April 26th. If that pull was instead done at 00:01 May 1st, the range would move up to 00:00 December 1st to 00:01 May 1st.

Does that make sense? If not, or if that is too complex, let us know and we can work out a different solution.

[ifoche]

@QISPSK that makes sense. We will include that and create a new release for next monday