Skip to content
This repository has been archived by the owner on Apr 9, 2024. It is now read-only.

User feedback from Mozambique 2019

Jump to bottom
tineml edited this page May 24, 2019 · 3 revisions

Richard:

#1

A general thought about the system. We currently have our volunteers texting the system when they are running low on credit. I then maintain this in a separate excel sheet, and text them back with recharge code. I wonder if this could/should be implemented in the system. Maybe volunteers could text "9999" (or "$"!)and then they would pop up in the system saying "you need to text this person a recharge code". It could even be done within the system, with the eagle texting back the recharge code (automatically!) if we "fed" the system with a bunch of recharge codes beforehand.

#2

one more thought: when we register data collectors, we should also register the network they use (ie telenor, movitel, vodacom). because different areas of different countries have better coverages with different providers. so when we text them a recharge code, we need to make sure we are texting them the code from the correct telecom provider

#3

A. the column titles "Males ≥ 5" and "Females ≥ 5" are bad because they contain "≥". This is bad because:

  1. People who are not so math-happy might not understand ,, ≥
  2. ≥ is going to break some programs if we send the data to other people who want to feed it into their own systems

Proposal 1: "Males_5_to_100", "Females_5_to_100", "Males_0_to_4", "Females_0_to_4"??

Proposal 2: "Males_5_and_older", "Females_5_and_older", "Males_0_to_4", "Females_0_to_4"??

B. Column names shouldn't have any spaces in them. They should be replaced with underscores instead

#4

the front end needs to be light* we have great internet here in mozambique (literally, the IT guys are doing an amazing job) but once you get away from base camp there can be issues. so literally every KB counts. @karolikl this makes me think that maybe we should have an (additional) analytics page that is just tables, so that we can try to make the page load as small as possible. not for right now, but thoughts for the future.

it would be great if there was the option to load a super light analytics page that only contained HTML tables, no images, no frameworks... not sure if that is possible? (agreed by Jakob that it is possible and that we should have light versions of key pages. + this comment from Jakob: We definitely also need to work on things like caching and pre-loading to help with the practical use.

#5

The file names of the excel export are not very friendly to automatic sorting on my computer. It would be better if it had: YYMMDD in front of it. e.g. "190502-case-reports-2019-May-02.xlsx"

#6

We need five more columns:

  • "days old" (i.e. 0 for data received on the day of the export). Agreed not needed in excel.

  • "date" (i.e. no time) (should have been fixed)

  • "year-week"

  • "week"

  • "Total"

  • total females, total males -total 0-4 or under 5, total five and older

it would probably also be smart to call the columns "isoyear-isoweek", "isoweek", "isoyear", instead of yearweek, week, year, as "iso*" is very clear. (ISO used by WHO, epi used by CDC)

#7

Possibility to edit data? long discussion about this. To be discussed further, but for now we do not want to open up for editing. Alternative: add that text is separated from the sms report, so if someone add text in the report, text is taken out and report is accepted if the rest is correct.

#8

technical challenge: the SMS eagle is set to the wrong time-zone and no one knows how to change it. one ORP sent a message in at 11pm, but due to the wrong time-zone it got registered as 1am this morning, so now we have no cases for that ORP yesterday, and double the amount of cases for today. According to the excel sheet, it came in at 23:33 last night. according to the website, it came in at 1:33am today. so the timezones are not consistent between the website and excel export. (edited)

How it is supposed to work, is that the SMSEagle should be set to UTC, so that the same time gets reported in the system. But as you say, I’m not sure how/if we convert that to the local timezone on the website and for the excel export.

Tine: important that the platform show the correct time the volunteer sent the report.

Contributing

Clone this wiki locally