Closed mtwestra closed 9 years ago
This document shows a polished version of basic monitoring features user actions. https://www.dropbox.com/s/6hq3ip2jswb1cef/Monitoring_feature_Polished_version.pdf
Version 0.0.6
The special 'registration' form can only be filled in once per record, as it has the ability to create new records. We disable it after first use in a record, because field testing has shown that it is easy for enumerators to be confused and to start filling in the registration form multiple times, causing the creation of multiple records.
However, sometimes it will be necessary to update the information collected in a registration form. In this case, what can be done is this: a) Create a copy of the registration survey, and call it, for example 'update registration', 'update waterpoint', or whatever. b) When a copy of a survey is made, the questions in the new survey are linked to the old 'source' questions. c) When the survey is send to the device, it will have access to the values filled in in the original registration form. So when the 'update registration' form is selected, the phone will ask the enumerator if he wants to prefill the fields with the values from the original 'registration' survey.
Not done yet:
I like the functionality, the crashing (see below) kept me from further testing but here are my initial thoughts -
It kept crashing when I was working on an update to an original record. An error message popped up saying 'The application Field Survey (process com.gallatinsystems.survey.device)has stopped unexpectedly. Please try again'. A strange thing is when I looked at responses under my record the update was saved 'December 31, 1969 19:00. I felt like Marty McFly.
Would it be worth having a set point registration survey that is automatically generated when you create a new monitored group - these will be standard identifiers. When you press + on the apk it automatically takes you to this survey and does not bring up the list, i.e. it knows you want to start a new record. In the same train of thought, this survey will then not need to be displayed in the list when you click on a record, just the ones you should be updating, removing the need for it to be greyed out.
Instead of having an identical survey to be able to update the core identifiers of a point (this seems to duplicate work in the survey creation phase), could it work that there is an edit option in the APK. When looking at the records a long click could pop up with an edit option? This information is rarely going to be needed to be updated so I feel like this would not be front and center providing confusion but is easily accessible if required.
This setup will increase the need for more survey groups. You will only really want the surveys in a group that will be used for a given point. i.e. this group of surveys will be required to collect the relevant information for this POI. At the moment these group are used more broadly, i.e. all the surveys that are used in a country's operations. Is it possible to have another level in here to help with this, i.e. Survey Groups, Monitoring Group (and have monitoring enabled at this level), and then surveys?
Let me know if you need clarifications on my ramblings
thanks for your comments!
Some additional thoughts on points you raise:
1) Could you give as much details as possible about what you were doing, and had done before, when the error message popped up? Please include details on survey group / survey that you were filling in.
2) On having a set point registration which pops up automatically: we have discussed this case, and actually had it implemented for a while. However, we found that this causes confusion, as the inital survey is never seen, and the workflow is then different depending on which survey you fill in. So having compared these two workflows, we decided on the present system of having a single workflow, and making explicit which survey can be filled in when.
3) This part of the workflow is hard to get right, so we'll wait for some more comments to see if the present system works or if we need to consider something like your proposal.
4) I see what you mean, and I agree that we might need a 3rd level. We'll ask Loïc for ideas on this.
On Feb 6, 2014, at 00:32, henryjewell notifications@github.com wrote:
I like the functionality, the crashing (see below) kept me from further testing but here are my initial thoughts -
It kept crashing when I was working on an update to an original record. An error message popped up saying 'The application Field Survey (process com.gallatinsystems.survey.device)has stopped unexpectedly. Please try again'. A strange thing is when I looked at responses under my record the update was saved 'December 31, 1969 19:00. I felt like Marty McFly.
Would it be worth having a set point registration survey that is automatically generated when you create a new monitored group - these will be standard identifiers. When you press + on the apk it automatically takes you to this survey and does not bring up the list, i.e. it knows you want to start a new record. In the same train of thought, this survey will then not need to be displayed in the list when you click on a record, just the ones you should be updating, removing the need for it to be greyed out.
Instead of having an identical survey to be able to update the core identifiers of a point (this seems to duplicate work in the survey creation phase), could it work that there is an edit option in the APK. When looking at the records a long click could pop up with an edit option? This information is rarely going to be needed to be updated so I feel like this would not be front and center providing confusion but is easily accessible if required.
This setup will increase the need for more survey groups. You will only really want the surveys in a group that will be used for a given point. i.e. this group of surveys will be required to collect the relevant information for this POI. At the moment these group are used more broadly, i.e. all the surveys that are used in a country's operations. Is it possible to have another level in here to help with this, i.e. Survey Groups, Monitoring Group (and have monitoring enabled at this level), and then surveys?
Let me know if you need clarifications on my ramblings
— Reply to this email directly or view it on GitHub.
Addressing comments above -
1) In 'Watermeters Monrovia' I created a new record called 'hj' and submitted it. Worked as expected. Then I went to the 'update customer information' survey and filled it out but every time I went to submit this it crashed. It updated the information in the record list, the record is now called 'bob'. When i checked the transmission history, this is when the strange date came up. To see this, go to 'watermeters monrovia' select the record 'bob', select 'update customer information' and try to submit it.
2) How is the initial survey never seen? When you create a new monitored group, the standard base point creation survey can automatically be created on the dashboard. You do not see it on the apk until you go to fill it out anyway. This can work if the point creation survey is the same for every point. I realize that this could be a person or a water point or anything else in between but the questions are still trying to capture the same information, name, type, GPS, photo, etc. Basically what is this point and how can i find it again (this could also be editable on the dashboard as the user can see the structure there). Thus you just need one survey and not the duplicate to update it. This also removes the need for the user to manual select which survey does the creation of new points as it will be automated.
3) agree
4) agree
1) @ichinaski Perhaps something is amiss with the prefilling of previous info for linked questions?
2) The information collected in the 'registration' survey is highly dependent on the type of survey - there is no real standard for that. In many cases, the current use flow is that people have already collected information using a survey, and they now want to use the information collected using that survey to act as the 'registration survey'. That means that retroactively, a survey must be designated as being the registration survey.
New mockup for dashboard: https://www.dropbox.com/s/tgo69bcyehla6p5/Mon-Dashv2-2.pdf
Would it be possible to view both the new and the old surveys side by side when taking data for the latter? This way there is immediately an intuitive sense for data comparison that could be advantageous.
you mean on the device? or on the dashboard? Could you sketch how you think that should look like in the dashboard?
On 12 Mar 2014, at 17:51, Kendra Terry notifications@github.com wrote:
Would it be possible to view both the new and the old surveys side by side when taking data for the latter? This way there is immediately an intuitive sense for data comparison that could be advantageous.
— Reply to this email directly or view it on GitHub.
Was thinking on both the device and the dashboard, but now am re-seeing it. Maybe an easier way to accomplish this - and perhaps you have already done this - is to have the baseline existing values in the survey responses when you pull up the "Update waterpoint" and then essentially override the previous data with new values?
That is how it works now on the device - you can prefil answers with answers from a previous survey
On 12 Mar 2014, at 18:44, Kendra Terry notifications@github.com wrote:
Was thinking on both the device and the dashboard, but now am re-seeing it. Maybe an easier way to accomplish this - and perhaps you have already done this - is to have the baseline existing values in the survey responses when you pull up the "Update waterpoint" and then essentially override the previous data with new values?
— Reply to this email directly or view it on GitHub.
In manage Users, when editing a user (by long-clicking username) I get the following blank screen. It's clickable though.
This seems related to the new Text Color we set (white), overriding the default one. As the background happens to be white in this Android version in the menu, the text cannot be seen. Will look into this. Thanks for the bug hunting!
ah yes, of course :-)
On 17 Apr 2014, at 10:28, Iñigo notifications@github.com wrote:
This seems related to the new Text Color we set (white), overriding the default one. As the background happens to be white in this Android version in the menu, the text cannot be seen. Will look into this. Thanks for the bug hunting!
— Reply to this email directly or view it on GitHub.
On long-pressing the the survey, the Delete Survey and Resend Survey options are missing from the dialog. Also there are no menu options for Resend All and Delete All
There should be a way to delete records from phone. Everytime the user clicks on the +, a record is generated. Now if the enumerator leaves the app, and comes back, there is no indication that an empty record already exists. So he clicks on the + icon.
This way empty records will stack up
Is the distance shown calculated from my current location ?
An enumerator may only be interested in the data in his region. So it will be a good feature to be able to sync records with a certain radius.
UPDATE Mark Westra: The issue is how to restrict the records that are downloaded. This is quite hard to determine, because the enumerator might sync points at a different location as the actual work. For example, when syncing the phone in the capital or in the office, and then go out for field work. The approach we took at the moment is simply try to sync everything, as because this is all just text, the amount of data should be quite small. If this leads to problems, we will need to think about a selection mechanisms along the lines you describe.
There is no Manage User button hereon this page. Maybe we can change the message or add the Manage User button on this page
Record name is initially when synced is "Unknown" .After opening the record , "Unknown" is replaced by the actual name
As part of the testing of the monitoring features, I used the survey group "Akvo Global Water Points" and collected 2 data points. Both close to each other and in the office, so the geo locations are not perfect. I submitted the static (register water point) as well as the dynamic data (current water point status). After this, I changes the current water point status’ for both points.
In general, the app seems to work very nicely.
Adding a new record was easy.
Viewing previously collected records is easy as well, as is looking them up on the map (which was working great and will be very helpful!), and changing data, if required.
Splitting surveys up into a static and dynamic part should not be a problem.
Some small points:
UPDATE @mtwestra - I will investigate this.
UPDATE @mtwestra - we tried this also, but could not reproduce the problem. Perhaps a transient issue.
@joycarpediem, regarding the lack of Resend All and Delete Survey:
Aiming at simplifying the transmission of data, the sync process is now smarter than before, and knows the exact status of each item within a particular survey (data & images). The sync process takes care of uploading anything that is not synced yet, for all surveys. This means that users don't have to manually send surveys anymore, as a synced survey does not need to be resent. Each time the sync process runs, it will handle any unsynced survey.
Survey deletion is still possible, but only for non submitted surveys. A submitted survey is likely to be exported (and possibly synced), thus its removal would not be safe.
The deletion of Records has the same problem mentioned above: we cannot safely delete data that is likely to be synced. A possible solution in case of accidental mistakes could be to allow the removal of Records containing no submitted surveys. This, in essence, means that the record itself will not be synced yet, and it could be deleted.
We have to be extremely careful with data deletion, which although useful if used correctly, it can be a very dangerous power if granted freely.
Hi, 2 more small questions:
UPDATE @mtwestra - There are two places where you can see the data: the Inspect Data subtab on the Data tab, which has the behaviour you describe, but also the Monitoring subtab on the Data tab, which orders the forms per record.
UPDATE @mtwestra - In the 'Inspect Data' subtab, you can search for deviceId, or submitter name.
On Record deletion, in a chat with @mtwestra we discussed the following approach:
The same approach can be applied to survey responses, detecting the lack of interaction with newly created surveys:
On Users management:
As a (temporary) measure until we address users with a login approach, we could also add the 'Manage Users' option to the Survey Group (or Record) screen, so users can activate the current user just before answering a survey (and thus not having to exit the Survey Group screen to log in).
The device will detect if when leaving a newly created Record no response has been created (no interaction happened further than creating the Record), and will prompt the user with a dialog, requesting if she wants to delete the Record.
If a user clicks NEW on a program, and doesn't interact with the newly created thing, navigates away, it shouldn't prompt to delete something he/she has not finished, e.g. create a new contact, or a new event on the calendar on an Android device.
@iperdomo, yes, we were debating this point, which we wanted to discuss with Loïc tomorrow also. The options are:
1) when a user clicks the plus icon (NEW), a record is created. When a user leaves the record, the record is automatically deleted 2) when a user clicks the plus icon (NEW), a record is created. When a user leaves the record, the user gets a message such as 'do you want to discard this record?'
mark
On 22 Apr 2014, at 12:50, Iván Perdomo notifications@github.com wrote:
The device will detect if when leaving a newly created Record no response has been created (no interaction happened further than creating the Record), and will prompt the user with a dialog, requesting if she wants to delete the Record.
If a user clicks NEW on a program, and doesn't interact with the newly created thing, navigates away, it shouldn't prompt to delete something he/she has not finished, e.g. create a new contact, or a new event on the calendar on an Android device.
— Reply to this email directly or view it on GitHub.
Decisions: 1) when a user enters a survey and leaves it empty, the survey is automatically deleted, and not saved 2) when a user is in a record without any saved surveys, and leaves the record, the record is automatically deleted 3) when a user is in the home screen showing the list of survey groups, and clicks on a survey group, and has no user selected, a dialog is shown asking the user to select a valid user first, using the icon at the top. 4) The 'save and start new' functionality will be changed to just 'save for later completion'.
Regarding points 1 and 2, I think we should at least display a Toast (no interaction required) when deleting empty Records/Responses, with a subtle message 'Record discarded' / 'Response discarded'.
What do you think?
I don't think that is necessary - if we show to many things to users, they will simply start to ignore more.
On 24 Apr 2014, at 11:41, Iñigo notifications@github.com wrote:
Regarding points 1 and 2, I think we should at least display a Toast (no interaction required) when deleting empty Records/Responses, with a subtle message 'Record discarded' / 'Response discarded'.
What do you think?
— Reply to this email directly or view it on GitHub.
And perhaps a less visible feature: 'auto-save' each 5 mins for example.
A Toast can safely be ignored (unlike a dialog, it requires no interaction). It is the least minimum feedback we can give to the user after taking an action on her behalf. After all, we are automatically deleting an item they explicitly created.
I still don't think this is necessary - in the same way editors / FLOW dashboard doesn't notify the user when something is discarded
Ok I am with Mark here, this is not necessary.
On 24 Apr, 2014, at 12:53, Mark Westra notifications@github.com wrote:
I don't think that is necessary - if we show to many things to users, they will simply start to ignore more.
On 24 Apr 2014, at 11:41, Iñigo notifications@github.com wrote:
Regarding points 1 and 2, I think we should at least display a Toast (no interaction required) when deleting empty Records/Responses, with a subtle message 'Record discarded' / 'Response discarded'.
What do you think?
— Reply to this email directly or view it on GitHub.
— Reply to this email directly or view it on GitHub.
Tested 1.14.5 and it works very nicely indeed
One comment: as the context menu of the survey view is now a list, so we have more space, I still would want to change the 'save' text to something more descriptive. Perhaps 'Save and finish later'
@mtwestra based on your comment in
The Monitoring tab, doesn't show any data until the user picks a Survey Group (a.k.a Project) and hits the find button.
@ichinaski comments on 1.15.4: no comments! Looks great!
Let's focus on testing and making sure the data transmission happens reliably, including the image retries etc.
We will support two types of exports:
In both cases, the report will not be used for data cleaning, only for export. So the questionIds will not be part of the exported data.
Type 1 proposal, with two alternatives:
Type 2 proposal:
Comments by Emeline: In general, as I said earlier, the training went well and the app was used easily. As for the reports, we didn't work much on it but I think that if we get time in the coming weeks, we will have a closer look because we didn't find it easy to work with. In the raw report, it was not easy to identify a point with the various updates associated... We should be able to make some suggestions. The fact that they were able to use the same survey for monitoring or create a new one was good, and it really opens up a full range of opportunity in monitoring (for example, the program manager was excited that after he would get the first results, he could always define another set of question for a specific situation on which he would need more data/knowledge meaning he would have a new survey that would be ask only if there are some specificity he is interested in on the point.)
Here are the remarks we notice during the use of the point functionality. On the dashboard: We had the problem I already mentioned that the data cleaning we did on the dashboard didn't work. All the data we changed from the dashboard are still shown with older value when we sync the phones for example. Some more filtering might be needed on the dash board to differentiate data which has been updated and those which have not.
On the app: It seems that the screen goes off during the use of the app, even if the option 'keep screen on during survey input' is on. The "next button" is not shown at the end of a group of questions like it was on the 'normal' app. So now, to go to the next group of questions, the only way is to choose the next tab. But we think it helps the people who don't know how to manage well to have another option to see what is next. We wonder if the save option should still show. We saw it is saved automatically, but for those who were used to the other version, it might be good to leave the option 'save' so they feel more comfortable to leave their survey. Am not sure of that thought, it might be just a matter of habit. When entering a survey, you can see the points under data points (where you have the option to order by data/status/distance). you can also see the points on the map. For some strange reason, when you enter into 'map" tab and come back to the data points tab, the option to order disappear.
On the app:
It seems that the screen goes off during the use of the app, even if the option 'keep screen on during survey input' is on.
My bad. I still need to port this functionality to the new version.
The "next button" is not shown at the end of a group of questions like it was on the 'normal' app. So now, to go to the next group of questions, the only way is to choose the next tab. But we think it helps the people who don't know how to manage well to have another option to see what is next.
Although doable, I'm not sure myself about that button being necessary... The whole app is now based on tabs navigation. My feeling is that we need to explain how this works, if it's not clear enough. But once a user knows how to handle switching tabs, it work exactly the same in every single screen. You can in fact, either swipe or tap the tab title. An extra 3rd method in just the question tabs could be confusing towards the rest of the screens, imho. I wonder what @loicsans thinks?
We wonder if the save option should still show. We saw it is saved automatically, but for those who were used to the other version, it might be good to leave the option 'save' so they feel more comfortable to leave their survey. Am not sure of that thought, it might be just a matter of habit.
I don't personally like the idea of a button that does nothing but cause confusion. If a save button is present, everybody will be using it, as it implies you need to manually save the forms. I think we need to be clear explaining all forms are saved automatically. An extra, confusing, useless (in practice) button, will simply add some unnecessary complexity to the UX.
When entering a survey, you can see the points under data points (where you have the option to order by data/status/distance). you can also see the points on the map. For some strange reason, when you enter into 'map" tab and come back to the data points tab, the option to order disappear.
I cannot reproduce this myself in the latest version: 1.15.6. Is there any pattern this bug follows?
@ichinaski, comments below, mark
On 27 Jun 2014, at 11:48, Iñigo notifications@github.com wrote:
On the app:
It seems that the screen goes off during the use of the app, even if the option 'keep screen on during survey input' is on.
My bad. I still need to port this functionality to the new version
OK The "next button" is not shown at the end of a group of questions like it was on the 'normal' app. So now, to go to the next group of questions, the only way is to choose the next tab. But we think it helps the people who don't know how to manage well to have another option to see what is next.
Although doable, I'm not sure myself about that button being necessary... The whole app is now based on tabs navigation. My feeling is that we need to explain how this works, if it's not clear enough. But once a user knows how to handle switching tabs, it work exactly the same in every single screen. You can in fact, either swipe or tap the tab title. An extra 3rd method in just the question tabs could be confusing towards the rest of the screens, imho. I wonder what @loicsans thinks?
I think we need the 'Next' button as well, as otherwise it will be too big a change. I think in going through question lists, it is quite natural to have a 'next' button, like you have in interfaces where you are guided through a workflow. In future, if we have the system where we can show single questions, we should also have a 'next' button, and a possibility to swipe.
We wonder if the save option should still show. We saw it is saved automatically, but for those who were used to the other version, it might be good to leave the option 'save' so they feel more comfortable to leave their survey. Am not sure of that thought, it might be just a matter of habit.
I don't personally like the idea of a button that does nothing but cause confusion. If a save button is present, everybody will be using it, as it implies you need to manually save the forms. I think we need to be clear explaining all forms are saved automatically. An extra, confusing, useless (in practice) button, will simply add some unnecessary complexity to the UX.
I agree, let's leave this out. It should be part of the training, and then an enumerator can simply try this out, and see that it is saved, so he/she will know for later. When entering a survey, you can see the points under data points (where you have the option to order by data/status/distance). you can also see the points on the map. For some strange reason, when you enter into 'map" tab and come back to the data points tab, the option to order disappear.
I cannot reproduce this myself in the latest version: 1.15.6. Is there any pattern this bug follows?
I also can't reproduce this on my device. perhaps you could try it out on a 3.2 emulator? — Reply to this email directly or view it on GitHub.
I think we need the 'Next' button as well, as otherwise it will be too big a change. I think in going through question lists, it is quite natural to have a 'next' button, like you have in interfaces where you are guided through a workflow. In future, if we have the system where we can show single questions, we should also have a 'next' button, and a possibility to swipe.
Ok. Will include this button.
I also can't reproduce this on my device. perhaps you could try it out on a 3.2 emulator?
Looks like the bug appears when tapping the tab, not when swiping them. Although this only happens in some Android versions, fixing it should not be a big deal.
@ichinaski, when tapping I also can't reproduce it, so indeed perhaps dependent on android versions.
On 27 Jun 2014, at 12:11, Iñigo notifications@github.com wrote:
I think we need the 'Next' button as well, as otherwise it will be too big a change. I think in going through question lists, it is quite natural to have a 'next' button, like you have in interfaces where you are guided through a workflow. In future, if we have the system where we can show single questions, we should also have a 'next' button, and a possibility to swipe.
Ok. Will include this button.
I also can't reproduce this on my device. perhaps you could try it out on a 3.2 emulator?
Looks like the bug appears when tapping the tab, not when swiping them. Although this only happens in some Android versions, fixing it should not be a big deal.
— Reply to this email directly or view it on GitHub.
Approach:
AkvoFLOW/ / forms / data, containing /images and /zips / inbox stacktrace => internal app folder
/forms
is exclusively managed by the app, so I'd suggest to also move it to the internal directories. In essence, we just need two folders, one for data output (exported data), and one for data input (bootstrap).
Agreed, mark
On 9 Jul 2014, at 17:11, Iñigo notifications@github.com wrote:
AkvoFLOW/ / forms / data, containing /images and /zips / inbox stacktrace => internal app folder
/forms is exclusively managed by the app, so I'd suggest to also move it to the internal directories. In essence, we just need two folders, one for data output (exported data), and one for data input (bootstrap).
— Reply to this email directly or view it on GitHub.
As discussed with @iperdomo and @joycarpediem in the FLOW chat, one key feature that seems to be missing is the lack of counts for locally collected data. Some organizations use this data to evaluate the work a particular enumerator is performing. As having global counts can be a little bit misleading, my proposal is to include the total number of Data Points for a particular Project: That is, once you enter the Project and get the Data Point list, you would also get a number of Data Points somewhere in the header/top part of the screen.
In the mid/long term, as @mtwestra has suggested other times, it'll be nice to have a whole section of the app dedicated to statistics.
Sounds good. However, usually, what is needed by enumerators / field managers is a count per day, because that is often a number that is kept track of to determine the daily amount of work. Perhaps both figures: 'total' and 'collected today'?
How about an 'i' icon at the top of the project screen, which, when pressed, shows a number of statistics such as 'total', 'collected today', 'collected this week' (counting from monday)? mark
On 18 Jul 2014, at 18:13, Iñigo notifications@github.com wrote:
As discussed with @iperdomo and @joycarpediem in the FLOW chat, one key feature that seems to be missing is the lack of counts for locally collected data. Some organizations use this data to evaluate the work a particular enumerator is performing. As having global counts can be a little bit misleading, my proposal is to include the total number of Data Points for a particular Project: That is, once you enter the Project and get the Data Point list, you would also get a number of Data Points somewhere in the header/top part of the screen.
In the mid/long term, as @mtwestra has suggested other times, it'll be nice to have a whole section of the app dedicated to statistics.
— Reply to this email directly or view it on GitHub.
How about an 'i' icon at the top of the project screen, which, when pressed, shows a number of statistics such as 'total', 'collected today', 'collected this week' (counting from monday)?
Ok with me. That can be easily embedded in a dialog (pop-up).
Changes of monitoring feature interactions:
1) the ability to sync data should be handled differently:
2) the monitoring checkbox should remain. It will determine the ability if multiple forms can be added to the project or not
3) The '+' icon on the form tab should be greyed out when the monitoring checkbox is not checked.
4) when the monitoring checkbox is checked, a popup should appear explaining that you can now add multiple forms to the project. In addition, we need to make clear that one form is the registration form.
Overview
Monitoring features will enabe users to download data on existing points on their phones, and add information to these points This feature introduces the concept of a 'monitored entity', which has a identity and can be tracked over time. Multiple different surveys can contribute data to a single entity.
This can be visualised by comparing it with record files containing paper forms: one of the forms creates the record file, and other forms can be added to the record file. A special form may also exist which archives or closes the record file. The enumerator has access to a certain set of record files, including the forms contained in them.
Documents
Github issues: https://github.com/akvo/akvo-flow/issues/276 https://github.com/akvo/akvo-flow-mobile/issues/32
Latest functional design document: https://github.com/akvo/akvo-product-design/blob/master/FLOW/Features/1-MonitoringFeatures/FunctionalDesign/MonitoringFeatures.md
Latest technical design document: https://github.com/akvo/akvo-product-design/blob/master/FLOW/Features/1-MonitoringFeatures/TechnicalDesign/MonitoringFeatures.md