Monitoring features

[mtwestra]

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:
akvo/akvo-flow#276
akvo/akvo-flow-mobile#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

[loicsans]

This document shows a polished version of basic monitoring features user actions.
https://www.dropbox.com/s/6hq3ip2jswb1cef/Monitoring_feature_Polished_version.pdf

[mtwestra]

Version 0.0.6

Principles

1. All surveys that belong to a certain monitor project are collected inside a survey group
2. One survey has a special role of 'registration form'. This one can create new records. This survey is selected using a dropdown in the survey group overview.
3. Data is never deleted, only added to. That means that a user cannot delete items from his phone, and cannot change previous values. You can think of this as 'facts'. Facts are immutable - if I said in 2011 that this pump was working, that fact is still true in 2013. However, I can supply a new fact, saying that in 2013 this pump is broken.
4. This also means the best workflow is to not try to use original surveys to update information, but to use 'update surveys'.
5. Phone users don't have access to remote data if the survey has not been explicitly assigned to them. This is a security measure - not everybody should be able to access remote data. For water pumps this might not be such an issue, but with client data this is important.

FLOW App

1. When the app is opened, it will show a list of survey groups. There are two types of survey groups: regular survey groups which just group surveys, and monitoring survey groups, which contain records and surveys.
2. When a regular survey group is chosen, the workflow is unchanged

Existing records

1. When a monitoring survey group is chosen, a page will be shown with all the known records for that monitoring group. This can be empty if the phone has not synced records yet. Records can be synced by clicking on the menu icon (the three dots), and selecting 'sync records'.
2. In the same menu, the order of records can be changed - order by date and order by distance are available.
3. For each record, the display name, identifier, last modified date and distance are shown
4. A specific record can be found by searching on the display name, or the identifier. At the moment, the search term needs to start at the beginning of the name.

New Record

1. A new record can be created by clicking the '+' icon.
2. When a new record is created, only the registration form can be selected. This is needed to capture the identifying information for the record.
3. When the registration from has been completed and submitted, it is disabled for that survey. It can only be filled in once.
4. After the registration form has been completed, the other surveys are now available for completion.
5. When inside a record there are previous answers for a certain survey, the phone will prompt the user if he wants to prefill the fields with the previous values.

Special case - updating registration information

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.

Dashboard

1. Under the 'Data' tab, the dashboard now has an additional 'Monitoring' tab. There, you can select the survey group that contains the monitoring project, and you will see a table with the records within that project. The table shows 'identifier', 'display name', and 'last update'. The identifier is a unique identifier of the record. The display name is derived from answers to questions in the 'registration' form. The setting 'display in record list on device' on free text questions determines if answers to that question become part of the display name.
2. When you click 'view details' you will see the survey responses that are part of a single record. For each submitted survey response, the survey, submitter, device, and collection data are displayed.
3. When you click 'view details' on a survey response, you will see the individual answers given to the questions in that response. These items are not editable yet.
4. We are not quite happy with the user interface yet, and will experiment some more to find a better presentation. Any ideas on that are welcome.

Not done yet:

• export the data to Excel.
• edit capability in table
• have a 'latest' view of the data, only displying the latest values on questions.

How to test this version

1. Test instance: flowaglimmerofhope.appspot.com/admin
2. Use the Watermeters Monrovia test survey
3. Be sure to assign the surveys to your phone using the dashboard, instead of manually downloading them

Changing the registration information for the customer

1. I have created a copy of the 'register customer' survey, and called it 'Update customer information'. As described above, this couples the questions between the two surveys
2. Send this to your phone using an assignment
3. Inside a record, open this survey
4. You will be asked if you want to prefil from a previous survey, which in this case is the 'register Customer' survey. If you click 'yes', the values will be prefilled and new values can be supplied.
5. submit the survey.
6. the information will now show up in the dashboard under that record. What we still need to do is improve the user interface so it is clear what is the 'latest' information. To reiterate - we never change information in the datastore, just add new facts.

[henryjewell]

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

[mtwestra]

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.

[henryjewell]

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

[mtwestra]

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.

[mtwestra]

New mockup for dashboard: https://www.dropbox.com/s/tgo69bcyehla6p5/Mon-Dashv2-2.pdf

[kendragmterry]

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.

[mtwestra]

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.

[kendragmterry]

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?

[mtwestra]

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.

[ghost]

In manage Users, when editing a user (by long-clicking username) I get the following blank screen. It's clickable though.

[ichinaski]

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!

[mtwestra]

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.

[joycarpediem]

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

[joycarpediem]

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

[joycarpediem]

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.

[joycarpediem]

There is no Manage User button hereon this page.
Maybe we can change the message or add the Manage User button on this page

[joycarpediem]

Record name is initially when synced is "Unknown" .After opening the record , "Unknown" is replaced by the actual name

[adank]

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:

• I was not able to create a bootstrap file of the surveys. Assigning the survey to the devise did work. (but looking at the text above, this seems to be a known problem. I assume this will be fixed in the near future)

UPDATE @mtwestra - I will investigate this.

• I was not able to download the raw data. I got the message “Error generating report, try again in few minutes”. So I don’t yet know what the combines data over different rounds looks like in excell. For the text above, I understand that this is still under development. Looking forward to seeing that in the near future…

UPDATE @mtwestra - we tried this also, but could not reproduce the problem. Perhaps a transient issue.

[ichinaski]

@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.

[adank]

Hi, 2 more small questions:

• In the data tab of the instance, the data on 1 water point is given as 2 different records: one for 'register water point' and one for the 'current water point status' survey. The 'current water point status' data does not have info on which source it is referring to, as that is all in the 'register water point' data survey. This could make it difficult for someone checking the data coming it, to check the 'current water point status' data, as it is not clear which point it is referring to. Is it possible to present the 2 together somehow, or to make clear to which point the 'current water point status' data belongs to?

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.

• For someone checking the data collectors using a phone, it would be useful to be able to filter out the data from the data collectors he or she is supervising only. We assume this should be possible by using the search option in the app, but this does not seem to be working. Can that be right? or would there be another way for the data collector supervisor to check the data coming in from certain data collectors?

UPDATE @mtwestra - In the 'Inspect Data' subtab, you can search for deviceId, or submitter name.

[ichinaski]

On Record deletion, in a chat with @mtwestra we discussed the following approach:

• 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.
• Records can also be deleted in the Record list, but this only applies to Records with no responses. If the Record trying to be deleted contains any response, a warning will be displayed, asking to first remove (non-submitted) surveys from the record.
• If the Record contains synced/submitted data, it cannot be deleted.

The same approach can be applied to survey responses, detecting the lack of interaction with newly created surveys:

• If the user attempts to exit a new survey without responses, the app will ask if she wants to remove that response.

[ichinaski]

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).

[siemvaessen]

And perhaps a less visible feature: 'auto-save' each 5 mins for example.

[ichinaski]

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.

[mtwestra]

I still don't think this is necessary - in the same way editors / FLOW dashboard doesn't notify the user when something is discarded

[loicsans]

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.

[mtwestra]

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'

[iperdomo]

@mtwestra based on your comment in

• issue 4

The Monitoring tab, doesn't show any data until the user picks a Survey Group (a.k.a Project) and hits the find button.

[mtwestra]

@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.

[mtwestra]

Reports

We will support two types of exports:

1. latest data for all data points
2. all data for all data points

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:

[mtwestra]

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.

[ichinaski]

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?

[mtwestra]

@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.

[ichinaski]

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.

[mtwestra]

@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.

[ichinaski]

FLOW app redesign - Outstanding issues

• Media Files Synchronisation (Media files synchonization akvo-flow-mobile#96): With the monitoring features enabled, we should enable the possibility of loading remote images.
• Replace remaining icons from the old app: Will catch up with @loicsans on this issue.
• Implement 'Project' concept in the dashboard: The current APK approach to display 'Projects' is a hack and will lead to confusions, given the inconsistencies between the dashboard and app. The whole workflow should be as clear as possible.
• [Suggestion] The 'Settings' screen should be simplified, allowing admin users not to enter the '12345' auth code time and again. This could for now be implemented with the inclusion of an 'admin' flag on each user, letting the app recognize an authenticated user, which will introduce the auth code just once (when signing in).
• Decide when to merge the redesign branch into develop, and use this version as the default FLOW app. This is a delicate issue, as releasing this version could potentially mean that many users will need some re-training.
• Dark theme for the app?
• Documentation status?

[mtwestra]

Approach:

1. treat points above as enhancements
2. create help files in read the docs
3. create transition-help-file: old versus new.
4. new instances: use new workflow.
5. Introduce a new folder structure:
   AkvoFLOW/
   / forms
   / data, containing /images and /zips
   / inbox
   stacktrace => internal app folder
   Get rid of sharding
6. Final work: merge feature branch to develop, and code review. Ini will ask Stellan.
7. Deploy new version with version number: 2.0.0. on 16th of July.

[ichinaski]

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).

[mtwestra]

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.

[ichinaski]

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.

[mtwestra]

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.

[ichinaski]

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).

[mtwestra]

Changes of monitoring feature interactions:

1. the ability to sync data should be handled differently:

   • if a user / device can sync data of a particular project or not should be a setting on the assignment
   • data should be downloadable for all projects, not only monitoring ones.

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.