Create mockup that shows how newly synced cases are shown in register view

[cafootitt]

Based on a call that Ona team had with Indo team, @rowo will create a mockup that shows what we discussed in terms of marking newly-synced records in the register view.

@mib-iqbal When would you like to have this by?

[mib-iqbal]

We still testing the sync feature, but it would be nice if this available at the middle of august.

[cafootitt]

Ok, thanks iqbal.

[rowo]

@cagulas @mib-iqbal Do you have notes from the call? I know we discussed a few options — wondering if those need to be documented anywhere or if they are documented anywhere so I can think through the app states.

Otherwise, I do remember we talked about row indicators to tell you if a case is new. I like simple row highlights that are dismissed when the row is tapped (going to detail view) or an action is taking on the row. I don't think an explicit message is needed (like a flag/message), but maybe the field team can give their opinion.

Also, since data is coming from outside, is there going to be "last synced" information somewhere?

Any of these colors could work. You could test them with a few people from the field. Check what they think it means, what they think it does when you click it, etc.

Blue row highlight (#edf7fb):

Yellow row highlight (#fdfadd):

Green row highlight (#e2fee6):

[cafootitt]

@rowo I can't find any notes that I took from the call, but we decided that it wasn't necessary to have a flag or some permanent marker for denoting new records and that we should follow an approach like with email, where new conversations are bolded to alert the user that a conversation is new, then it becomes unbolded when the user opens the email, so in this case, what you have proposed matches what we discussed. I'm partial to the yellow, but all three options are fine, and Indo team should proceed with whatever is best based on user feedback.

I'm making a few assumptions here, including that the default sort is ignored when there's a new record, so that any newly synced records always appear at the top of the register list (probably in alphabetical order, or whatever the usual default sort is) when the health worker first opens the register, and then when she taps on the new record and goes to the detail view, the record will be 'marked as read' and when she goes back to the register listing, the record will be unhighlighted and appear in the register list according to the sort settings.

[ranazahroh]

Hi all, sorry just able to check this out. Thanks for working on this! Just to confirm, the highlighted row is the data which is synced from the other worker app, am I right? Highlight is actually a good idea instead of flags on the client's picture so it won't clash with the high risk flag.

It would be useful also if the highlighted record would be unhighlighted once the worker tap the detail view. However, we would want to have somewhere (perhaps the last synced info (when, from where) which the worker can know whether they have registered the data or it is synced from the other worker.

We are thinking to have this last synced info in the detail view once the worker click the client's picture. Do you think we need special UI also for this?

I do like the yellow one somehow, but we will do the field survey on the highlight color preference from the health workers themselves.

[cafootitt]

Just to confirm, the highlighted row is the data which is synced from the other worker app, am I right? Yes, that is correct.

It would be useful also if the highlighted record would be unhighlighted once the worker tap the detail view. Yes, that's the idea.

However, we would want to have somewhere (perhaps the last synced info (when, from where) which the worker can know whether they have registered the data or it is synced from the other worker. Just to clarify, the app will continue to receive updates from the other health worker's app and not just a one-time sync? If so, then yes, it might be useful to show last synced status and from where it was synced. But if that's the case, wouldn't the other records in the tablet (that the health worker registered herself) also be getting updates that are synced from another health worker's app?

[mib-iqbal]

Just to clarify, the app will continue to receive updates from the other health worker's app and not just a one-time sync? If so, then yes, it might be useful to show last synced status and from where it was synced. But if that's the case, wouldn't the other records in the tablet (that the health worker registered herself) also be getting updates that are synced from another health worker's app?

yes, the health workers app will get continue update from other workers. the scenario will looks like this

maybe @ranazahroh can add more info about this

[cafootitt]

Ok, so essentially, the health worker is interested in two pieces of information that might need to be displayed in the detail view of each patient in OpenSRP:

1. Who did the initial registration of the patient; and
2. When was data last synced for this patient.

For number 2 above, data syncing would be happening from multiple health workers, correct? So is it important to show when data was last synced from each type of health worker individually or just in general, when was data last synced from any other health worker?

Is this syncing from other health workers actually separate from the overall OpenSRP server sync that appears on the home screen of OpenSRP?

[ranazahroh]

Actually the health workers only need to know who did the initial registration, but our science team thinks that it would be useful for them to know when the data was last synced from each type of health worker individually. It would be also easier for the health workers to track any unusual data which will appear on the app.

Is this syncing from other health workers actually separate from the overall OpenSRP server sync that appears on the home screen of OpenSRP?

I am not sure about this question, can you explain about this more?

[cafootitt]

Ok, the scope of this is a little more than I initially thought. It will be good to discuss this with @rowo on next Monday's team call.

First, by showing last synced by each type of health worker, what does this actually entail? Does this mean showing the last sync from a particular health worker (i.e., the health worker's name?) or showing last time synced from the type of health worker only, (i.e., vaksinator, bidan, etc.)?

Second, it wouldn't show which data came from which health worker, so how would showing the last sync from each type of health worker help them track any unusual data, since they wouldn't actually be able to track from which health worker specific data originated?

Can you explain a bit more why the science team would like to see last synced from each type of health worker?

What I meant by overall OpenSRP sync is on the home screen where you see the sync button in the top right corner. Would this sync also check for updates from the other health workers? And if so, last synced would always be the same for each type of health worker, so what you might be implying is that science team would like to see last sync where new data from that health worker was synced, which sounds a little complicated to me.

[rowo]

I finally read through this. We can discuss in a call. Number 2 from https://github.com/OpenSRP/opensrp-client/issues/246#issuecomment-236523675 I would say is a separate issue even if technically they might be similar. This issue initially only covered calling out when a new case is added to the register.

[ranazahroh]

Hi All, sorry just managed to reply this. Regarding Carolyn's reply, 'showing last synced by each type of health worker' means to show the last time synced from the type of health worker only, (i.e., vaksinator, bidan, etc.) since Bidan will be able to know the vaccinator/nutritionist name right away (they work in the same location).

They need to know who did the initial registration and later on they would be able to distinguish whether the data coming is from vaccinator/nutritionist, since the data which vaccinator and nutritionist gather is different. The reason it would be useful for them to know the time where the last data pulled from which vaccinator/nutritionist is just as a record for them to clarify the following thing when they first saw the data; If the Nutritionist records the abnormal weight/height a child, they could check the last synced date to know the posyandu time of this data recording and they can follow this up with the Nutritionist right away.

However this is just an idea for the additional function and we can go with only initial registration detail for the first deployment.

I have a question, this color highlight, will this appear one time once the initial registration done, or also when the visits registration are done the highlight will re-appear?

Moreover, the survey of mockups colors has been done and it reveals that 77% of Bidans prefers green color!

[rowo]

@ranazahroh That might be up to you guys. It can work for both if bidans understand it. What's the difference between those situations (initial registration vs. visits registration)?

+1 green

[ranazahroh]

Hi all, apologies for the late response! We managed to get the following requests and confirmations from the health workers:

1. The green highlight should appear every time the data sync of the first registration form and visit form occur
2. The green highlight supposed to disappear when the health workers open the detail view of the client
3. The health workers would need to have the following details listed on every client synced to their app; the health workers who did the initial registration of the client and the time of the last sync data happened and from which health worker this is synced (we are planning to place this details on detail view)

Please do let me know if you have any question.

[cafootitt]

Sounds good.

Can you share a mockup of what this will look like before it's implemented?

To me, it sounds like there will be a space for initial registration that will be filled in once and thereafter remain the same, then there will be two additional spaces (one to show the last synced data from vaccinator and one to show the last synced data from nutritionist). This will just be a date and time and that's all. This is for bidan app.

Then for vaccinator app, same thing, only the last synced data will show from bidan and nutritionist, and similarly for nutritionist, last synced data will be from bidan and vaccinator.

The last synced date and time will only be updated when new data from either the vaccinator or nutritionist has been synced to the app, correct? In other words, if the app syncs to the server, but there is no new data from the vaccinator and nutritionist to sync, the date and time of last sync will not be updated, correct?

Is my above understanding correct?

[ranazahroh]

Yes @cagulas , all of your comments are correct! Siti has been delegated to create the mock-up, we will share it with you once done.

Moreover, to answer Roger's question, the initial registration is when you first register the client, the visit registration is when you submit the visit forms every time that particular client visits the health worker.

Please do let me know if this is clear.

Additionally, @rowo would it be possible for you to let us know the color code of the green highlight on one of the notification mock-ups you have created? Also, are you using Balsamiq to create the mockup? or using any other studios?

[cafootitt]

Color code for the green highlight (copied from Roger's comment above): #e2fee6

Balsamiq mockups are great.

https://smartregister.atlassian.net/wiki/display/PK/Setting+up+Balsamiq+Mockups+for+Desktop

[ranazahroh]

Thanks Carolyn! Just realized that the color codes are there. We'll be uploading the mock-up once done.