App UI redesign

[mtwestra]

Overview

The aim is to create a new visual design for the FLOW App. As its starting point, this project will take the Monitoring-feature enabled FLOW app, version 1.14.5 or higher.

We know that there are a number of features that we will add to the FLOW app in the near future, such as:

• User login
• difference between enumerator / field manager
• additional statistics screens that help the workflow of enumerator / field manager.

These new functionalities will not yet be part of this redesign: the goal will be to first redesign the existing functionality.

Part of this issue is to refactor the app in a way that allows the visual redesign to be implemented.

Links to documents

• https://github.com/akvo/akvo-product-design/blob/master/FLOW/Features/4-AppUiRedesign/FunctionDesign.md
• https://github.com/akvo/akvo-product-design/blob/master/FLOW/Features/4-AppUiRedesign/VisualDesign.md
• https://github.com/akvo/akvo-product-design/blob/master/FLOW/Features/4-AppUiRedesign/TechnicalDesign.md

[mtwestra]

Current design docs: https://www.dropbox.com/s/yt4jukynr53pkqr/flow-APK-redesign_v3.5.pdf
and https://www.dropbox.com/s/2jou5yon7fqo5f1/Monitoring_feature_Polished_version.pdf

[siemvaessen]

Nice!

[mtwestra]

After testing the first design with Charlotte and Anna-Marthe, they proposed some changes to the design: https://www.dropbox.com/s/z0a523mns3h1ebe/8may-design.pdf

[mtwestra]

two alternatives for the 'create new data point': https://www.dropbox.com/s/46p7ylwk7ehrp33/8may-redesign-v2-alternatives.pdf

[mtwestra]

and two alternatives for 'enter existing point': https://www.dropbox.com/s/6dqb5fg9s7t3ze6/8may-redesign-v2a-alternatives.pdf

[mtwestra]

New design by Loïc: https://www.dropbox.com/s/tsjs4cld6azevc2/FORM_WORKFLOW_V1.0.pdf

[mtwestra]

Looks great @loicsans!

I have put my comments in here: https://www.dropbox.com/s/wl6fvymama15kps/FORM_WORKFLOW_V1.0.MTW.pdf

[mtwestra]

@ichinaski, comments on 1.15.1:
I think we need to get a bit further in putting in all the details of the new design, as the present state is confusing.

• One thing I note is that having different icons for the forms (registration versus normal) is confusing - one is enough I think.
• the filled-in form in a regular data point should show up as green as well, with the 'completed' text

[ichinaski]

As mentioned earlier, there's something that just doesn't click with the current workflow... I find it quite confusing. On regards to the points mentioned above:

1. In my opinion, having the same icon and color is going to make the confusion bigger, as there will be no hint on the Project being monitored or not until you reach the last screen in the navigation tree. And this is indeed the screen I find most confusing, as sometimes you can fill in several forms (monitored project), sometimes you can't (regular project).

2. Agreed.

[mtwestra]

Let's first implement the design Loïc is making (I have made some comments this morning), because I think we can't judge the workflow on the current state of the app.

I think the amount of forms you can fill in is simply a given for a particular project.

[mtwestra]

@ichinaski, 1.15.1 comments:

First of all, I think it's great!
Some things:

1. The initial icon in the project list of multiple surveys is not very suitable I think, as regular projects will only have a single form.
2. An important point of the design is to show the datapoint icon in the datapoint list, and when inside a datapoint, to show a small datapoint icon, instead of the 'data point' text.
3. we will need a single icon for the forms, without the current difference between registration and normal forms. This is especially important when there is only a single form - it is confusing if there is another icon there.
4. The top-right map icon in a datapoint should use the internal map application. At the moment it hands over to an external map app.

[mtwestra]

New design by Loïc: https://www.dropbox.com/s/u9yeodtufs004tn/FORM_WORKFLOW_V1.5.pdf

[mtwestra]

Comments:

Looks great!

1. One small thing - I think we agreed that it would be nice to have a small icon instead of the 'data point' text, to show that you are inside a data point
2. The map icon in the top right hand corner will disappear, as Iñigo will create an additional tab there showing the map.

[ichinaski]

I've got a particular concern with the latest design.

The data point modified date seems to be correlated with the status ("Saved on 14/3/14", "Synced on 23/1/14", etc). However, remember that both the status and the modification date are properties inherited from the forms in the data point.

Until the inclusion of the status, the modification date was referring to the latest activity (whatever the status for that form was) in a particular point. This was meant to quickly search for recently used records, either to save or submit surveys. Each time a form was modified, its data point modification date was updated too.

On the other hand. the data point status is used to display to worst case scenario for any form inside the data point. That is, if some forms are synced and some saved, the status is saved.

If we use the "Synced on 12/3/14" approach, as shown in the design document, we'll lose the ability of ordering the records by latest modification date, as the date used in the data point will be the one associated with the status.

[mtwestra]

In my opinion, the icon style should reflect a call to action: 'this is green, so I can ignore it', 'this needs to be synced', 'this needs to be completed'.

I think the additional information shown should reflect only the form data, so when the last change to any of the forms was made. In that way, ordering can be done by 'latest activity'. In that case, it would only show 'changed:12-2-2014, 13:22'

Does that make sense?

[mtwestra]

In addition, when you long-click, the transmission history is shown, right?

[ichinaski]

I think the additional information shown should reflect only the form data, so when the last change to any of the forms was made. In that way, ordering can be done by 'latest activity'. In that case, it would only show 'changed:12-2-2014, 13:22'

This is indeed, the same approach we had before with the Last Modification detail, isn't it? I think we need to somehow differentiate between the status and modification date.

In addition, when you long-click, the transmission history is shown, right?

Not really. Transmission history can be seen per form, displaying the individual file statuses within it, not per data point. Would it make more sense to display it at the record level instead? Or both in the record and forms?

[mtwestra]

status vs modification: yes, I would say: status is about what a user needs to do, modification date is useful to find things back.

On transmission history: I think that is fine per form, otherwise it will become clutered

[ichinaski]

Agreed

[mtwestra]

@ichinaski, comments on 1.15.2:

1. the blue icons at the top are a bit thing and low-contrast, hard to see in bright light
2. When I am in a regular project, and I have no data points, it says 'you don't have any records, please sync ....'. But I can't sync there. So it should be: "You don't have any datapoints yet. Click on 'create new data point' to get started"
3. In a monitoring project, the same text should be changed to refer to data points, instead of records
4. the green icon for 'ready to upload' should have a different color, as the green hints that everything is alright. Perhaps it should be orange, or at least not the nice green color.
5. When you go to the map view within a datapoint, the map should center on that point
6. the popup 'prefill responses with previous values of the same questions', with the 'cancel' and 'OK' button should be changed to "Pre fill form with previous answers?", with a 'No' and 'Yes' button. Cancel implies that the user breaks off the whole thing, which is not the case.

In fact, I think we should probably turn this into an option: 'prefill forms previous answers': 'never', 'always', 'prompt user'. But I will discuss that here.
7) As all the forms look the same now, I don't think there is a need for an additional popup when a previously filled in 'registration' form is clicked. I think we can delete that popup completely, because as far as the enumerator is concerned, all forms can be changed in a monitoring group.
8) the 'last modified' is not always shown on data points in the list, for some reason.

[loicsans]

Working on new icons for 1) and 4)

[mtwestra]

@ichinaski, comments on 1.15.3:

1. When there is a 'saved form', the user needs a better way to see it, as now it ends up at the bottom when the geolocation has not been set yet. Perhaps we should move them to the top always?
2. When no location is available, don't compute a distance: now the use 0,0
3. don't show 'choose response' in a normal survey group, as there is only one response available
4. don't show 'failed-0' in the notification bar if the count is zero, only show it if there are actual failed uploads
5. don't say 'Any new responses will override previous values', as we keep old ones as well. Perhaps 'Any new responses will be used as the most recent values' ?

[mtwestra]

@ichinaski, comments on 1.15.3:

1. When there is a 'saved form', the user needs a better way to see it, as now it ends up at the bottom when the geolocation has not been set yet. Perhaps we should move them to the top always?
2. When no location is available, don't compute a distance: now the use 0,0
3. don't show 'choose response' in a normal survey group, as there is only one response available
4. don't show 'failed-0' in the notification bar if the count is zero, only show it if there are actual failed uploads
5. don't say 'Any new responses will override previous values', as we keep old ones as well. Perhaps 'Any new responses will be used as the most recent values' ?

@iperdomo, a comment on the dashboard:
I think on the monitoring tab, we should not start with showing all recently updated datapoints, as this is confusion. The user should first select a survey group, and click 'find'

[mtwestra]

@ichinaski, comments on 1.15.3:

1. When there is a 'saved form', the user needs a better way to see it, as now it ends up at the bottom when the geolocation has not been set yet. Perhaps we should move them to the top always?
2. When no location is available, don't compute a distance: now the use 0,0
3. don't show 'choose response' in a normal survey group, as there is only one response available
4. don't show 'failed-0' in the notification bar if the count is zero, only show it if there are actual failed uploads
5. don't say 'Any new responses will override previous values', as we keep old ones as well. Perhaps 'Any new responses will be used as the most recent values' ?

@iperdomo, a comment on the dashboard:
I think on the monitoring tab, we should not start with showing all recently updated datapoints, as this is confusion. The user should first select a survey group, and click 'find'

[mtwestra]

@ichinaski, comments on 1.15.3:

1. When there is a 'saved form', the user needs a better way to see it, as now it ends up at the bottom when the geolocation has not been set yet. Perhaps we should move them to the top always?
2. When no location is available, don't compute a distance: now the use 0,0
3. don't show 'choose response' in a normal survey group, as there is only one response available
4. don't show 'failed-0' in the notification bar if the count is zero, only show it if there are actual failed uploads
5. don't say 'Any new responses will override previous values', as we keep old ones as well. Perhaps 'Any new responses will be used as the most recent values' ?

@iperdomo, a comment on the dashboard:
I think on the monitoring tab, we should not start with showing all recently updated datapoints, as this is confusion. The user should first select a survey group, and click 'find'

[mtwestra]

@ichinaski, comments on 1.15.3:

1. When there is a 'saved form', the user needs a better way to see it, as now it ends up at the bottom when the geolocation has not been set yet. Perhaps we should move them to the top always?
2. When no location is available, don't compute a distance: now the use 0,0
3. don't show 'choose response' in a normal survey group, as there is only one response available
4. don't show 'failed-0' in the notification bar if the count is zero, only show it if there are actual failed uploads
5. don't say 'Any new responses will override previous values', as we keep old ones as well. Perhaps 'Any new responses will be used as the most recent values' ?

@iperdomo, a comment on the dashboard:
I think on the monitoring tab, we should not start with showing all recently updated datapoints, as this is confusion. The user should first select a survey group, and click 'find'

[mtwestra]

@ichinaski, comments on 1.15.3:

1. When there is a 'saved form', the user needs a better way to see it, as now it ends up at the bottom when the geolocation has not been set yet. Perhaps we should move them to the top always?
2. When no location is available, don't compute a distance: now the use 0,0
3. don't show 'choose response' in a normal survey group, as there is only one response available
4. don't show 'failed-0' in the notification bar if the count is zero, only show it if there are actual failed uploads
5. don't say 'Any new responses will override previous values', as we keep old ones as well. Perhaps 'Any new responses will be used as the most recent values' ?

@iperdomo, a comment on the dashboard:
I think on the monitoring tab, we should not start with showing all recently updated datapoints, as this is confusion. The user should first select a survey group, and click 'find'

[mtwestra]

@ichinaski, comments on 1.15.3:

1. When there is a 'saved form', the user needs a better way to see it, as now it ends up at the bottom when the geolocation has not been set yet. Perhaps we should move them to the top always?
2. When no location is available, don't compute a distance: now the use 0,0
3. don't show 'choose response' in a normal survey group, as there is only one response available
4. don't show 'failed-0' in the notification bar if the count is zero, only show it if there are actual failed uploads
5. don't say 'Any new responses will override previous values', as we keep old ones as well. Perhaps 'Any new responses will be used as the most recent values' ?

@iperdomo, a comment on the dashboard:
I think on the monitoring tab, we should not start with showing all recently updated datapoints, as this is confusion. The user should first select a survey group, and click 'find'

[mtwestra]

@ichinaski, comments on 1.15.3:

1. When there is a 'saved form', the user needs a better way to see it, as now it ends up at the bottom when the geolocation has not been set yet. Perhaps we should move them to the top always?
2. When no location is available, don't compute a distance: now the use 0,0
3. don't show 'choose response' in a normal survey group, as there is only one response available
4. don't show 'failed-0' in the notification bar if the count is zero, only show it if there are actual failed uploads
5. don't say 'Any new responses will override previous values', as we keep old ones as well. Perhaps 'Any new responses will be used as the most recent values' ?

@iperdomo, a comment on the dashboard:
I think on the monitoring tab, we should not start with showing all recently updated datapoints, as this is confusion. The user should first select a survey group, and click 'find'

[ichinaski]

@mtwestra,

When there is a 'saved form', the user needs a better way to see it, as now it ends up at the bottom when the geolocation has not been set yet. Perhaps we should move them to the top always?

Do you mean the data point, or the form (within a data point)? If you mean the data point, I think the best solution would be to add additional ordering criteria (i.e. 'by status', sorting the data points by their inherited status: saved > exported > synced). If we move the saved ones to the top in the 'by date' sorting, the ordering is not very accurate, thus could be confusing.

When no location is available, don't compute a distance: now the use 0,0

I had this issue in mind as well. The current approach is just a quick way of skipping null values. If we allow null values for a data point's location, this might affect somehow the dashboard (I have no idea, just wanted to double check that). Also, how should we order those records by distance?

don't show 'choose response' in a normal survey group, as there is only one response available

I intentionally added that intermediate pop-up to ensure consistency, but as you say, it is redundant in regular projects. I wonder if the best solution is to either resume the existing form, or just disable the form in the 'forms' tab, as if an exiting, saved form is available, it can be reached through the 'history' tab, avoiding multiple ways of doing the same action. What do you think?

don't show 'failed-0' in the notification bar if the count is zero, only show it if there are actual failed uploads

Easy to change, but it adds consistency and the confidence that everything is okay, imho.

don't say 'Any new responses will override previous values', as we keep old ones as well. Perhaps 'Any new responses will be used as the most recent values' ?

Ok.

[mtwestra]

@ichinaski,

1. Agreed on adding the 'sort by status' as you propopse
2. I think we should simply put in null values, it will not affect the server. Of course, data should not be submitted without a geolocation, so it will be mainly be saved forms. The point is, 0,0 is a real point, and will show up on a map as faulty data. I think it is better not to show it on a map when there is no location data. On how to order it by distance: I guess they should come last?
3. good point. let's leave it as it is, to keep consistency.
4. Perhaps change it to 'succesfully uploaded: xxx', which should be clear enough. If there are failed uploads, we can do 'succesfully uploaded: xxx, failed uploads: yyy'. But if we show failed uploads, the user should also know what to do. Should we add a message there?

One additional point: the current way of displaying a notification for a new version of the app in the notification bar is not clear enough, I think. The text 'click here to download the new version' is very small - I watched a user use it and have no clue what was expected of them. I think we should again consider a popup at some point in the workflow, to alert the user of a new version available. For example, when the first screen or one of the data point lists are shown. Comments welcome...

[mtwestra]

@ichinaski,
The current implementation of the popup button which is shown when the user can choose between completing an existing partially filled form or starting a new form is confusing: The user sees an item and a button, and almost automatically clicks on the button. I think the difference needs to be made clearer, perhaps involve Loïc?

[mtwestra]

@ichinaski On keyboard behaviour:

1. show a 'done' button which dismisses the keyboard, instead of the 'next' button. (in fact, I think this is already the case in the redesigned app)
2. If focus is lost on a text or number question, the keyboard could disappear, with the exception of when we move to a next text question.

An additional remark: the scrolling / keyboard behaviour in the redesigned app is a bit confusing - the 'done' button is replaced by a 'newline' button.

[ichinaski]

@mtwestra, on 'New Version Available':

the current way of displaying a notification for a new version of the app in the notification bar is not clear enough, I think. The text 'click here to download the new version' is very small - I watched a user use it and have no clue what was expected of them. I think we should again consider a popup at some point in the workflow, to alert the user of a new version available.

Perhaps we could use the same approach we have when notifying of such download: If the user ignores the Notification, show a dialog (pop-up) the next time you open the app. However, note that the pop-up approach could potentially be rather intrusive, as you might be deliberately postponing the download until you reach a reliable network, hence showing a pop-up with each usage of the app whilst collecting data might be a bit annoying...

[ichinaski]

@mtwestra on 'Keyboard Behaviour':

1. show a 'done' button which dismisses the keyboard, instead of the 'next' button. (in fact, I think this is already the case in the redesigned app)
2. If focus is lost on a text or number question, the keyboard could disappear, with the exception of when we move to a next text question.

That should work fine, yes. This is not implemented in the new version yet, though. Should we directly implement it the redesign? I don't think this is an urgent bug to be ported back...

An additional remark: the scrolling / keyboard behaviour in the redesigned app is a bit confusing - the 'done' button is replaced by a 'newline' button.

Yep. This is the same problem the focusability of the UI elements introduces. As the keyboard is not automatically dismissed, it gets weirdly adapted to the focusable, non-editable elements (i.e. question titles). This odd behaviour will go away with the implementation of the 'Done' button approach.

[ichinaski]

@mtwestra, on 'Failed Text':

Perhaps change it to 'succesfully uploaded: xxx', which should be clear enough. If there are failed uploads, we can do 'succesfully uploaded: xxx, failed uploads: yyy'. But if we show failed uploads, the user should also know what to do. Should we add a message there?

For the time being, I've just removed the 'failed' text, as your original suggestion said. Regarding 'what to do' if something goes wrong: We could 'tap to retry' on the notification itself, allowing the user to immediately trigger the sync process again.

[mtwestra]

@ichinaski,

Yes, I think it is a good idea to do it as a popup when you open the app. It is important that people update, so I am not too worried about the intrusiveness. Perhaps we can add a 'remind me later' option, which will surpress popups for that day?
mark

On 27 May 2014, at 07:54, Iñigo notifications@github.com wrote:

@mtwestra, on 'New Version Available':

the current way of displaying a notification for a new version of the app in the notification bar is not clear enough, I think. The text 'click here to download the new version' is very small - I watched a user use it and have no clue what was expected of them. I think we should again consider a popup at some point in the workflow, to alert the user of a new version available.

Perhaps we could use the same approach we have when notifying of such download: If the user ignores the Notification, show a dialog (pop-up) the next time you open the app. However, note that the pop-up approach could potentially be rather intrusive, as you might be deliberately postponing the download until you reach a reliable network, hence showing a pop-up with each usage of the app whilst collecting data might be a bit annoying...

—
Reply to this email directly or view it on GitHub.

[mtwestra]

@ichinaski,

1. Yes, it is enough to do it in the redesign.
2. Ok, good to hear!

On 27 May 2014, at 08:02, Iñigo notifications@github.com wrote:

@mtwestra on 'Keyboard Behaviour':

1. show a 'done' button which dismisses the keyboard, instead of the 'next' button. (in fact, I think this is already the case in the redesigned app)
2. If focus is lost on a text or number question, the keyboard could disappear, with the exception of when we move to a next text question.

That should work fine, yes. This is not implemented in the new version yet, though. Should we directly implement it the redesign? I don't think this is an urgent bug to be ported back...

An additional remark: the scrolling / keyboard behaviour in the redesigned app is a bit confusing - the 'done' button is replaced by a 'newline' button.

Yep. This is the same problem the focusability of the UI elements introduces. As the keyboard is not automatically dismissed, it gets weirdly adapted to the focusable, non-editable elements (i.e. question titles). This odd behaviour will go away with the implementation of the 'Done' button approach.

—
Reply to this email directly or view it on GitHub.

[mtwestra]

@ichinaski
Not sure that that is the right place to put app functionality, I think it will need to be somewhere in the app itself. Perhaps in the home screen? Let's discuss next week
mark

On 27 May 2014, at 10:07, Iñigo notifications@github.com wrote:

@mtwestra, on 'Failed Text':

Perhaps change it to 'succesfully uploaded: xxx', which should be clear enough. If there are failed uploads, we can do 'succesfully uploaded: xxx, failed uploads: yyy'. But if we show failed uploads, the user should also know what to do. Should we add a message there?

For the time being, I've just removed the 'failed' text, as your original suggestion said. Regarding 'what to do' if something goes wrong: We could 'tap to retry' on the notification itself, allowing the user to immediately trigger the sync process again.

—
Reply to this email directly or view it on GitHub.