Data point list styling: date

[valllllll2000]

Background

Currently we display the datapoint modified date: "Last modified x minutes/hours/weeks ago", see:

@Kiarii's proposal:

I would also like to propose an improvement on how we show the modified time; atm we are presenting as a primary element of the list and repeating the “Last modified:” for each datapoint which i think does not add extra value.. I think just showing the day is enough and it also enables us to get rid of the “ago” which we are atm also repeating for each list item.. what are your thoughts

Here is a screenshot of how it could look like:

Questions and Thoughts

Position the date on the right, in my opinion is a very good idea.

As for the formatting, if it's today will we show today or Mar 9? Wouldn't it still be useful to show more details for today, ie 10 minutes ago or a second ago? How would it benefit the user, less information?

[Kiarii]

@valllllll2000 these are some valid questions,

I think we could for changes made today use time (with 24hr notation) e.g. 10:12, 18:27, or so.. and then change to dates e.g. Mar 9, once the last modified time is yesterday and so on..

This way, i think we can keep the timestamp short and also exact; e.g. instead of 10 mins ago, we say 10:02. I also think with the 10:02 Alphonso can precisely tell when a modification was made to a datapoint - which i think is the idea..

[valllllll2000]

[janagombitova]

It is a great change in terms of making the screen cleaner. But I have two comments/issues with it:

• Consistency - in the designs we have two ways of showing the order of days and months and this can be confusing. As we use the 24h format which is commonly used in combination with the order DD-MM-YYYY we should use the order consistently so: 16 Mar, 26 Dec 2018.
• Looking information - What about data points created the same day in the past. How will I know the difference and do I need to know? So how will I know which data point was modified earlier in the case of: one would be 19 Mar 2018 - 13:45 and another 19 Mar 2018 - 17:5. Do I need to know this difference?

[janagombitova]

To be able to push out the change of design but not loose information we give to users we can keep the change of date layout and format but standardise it to (also what Lumen is using):

• 14 Jan 2020 - 10:45
• 19 Mar 2019 - 18:36
• etc

and then see if we can simplify it more with another iteration

[valllllll2000]

[valllllll2000]

@janagombitova I have just realized maybe it would be best to let the formatting be according to the language. Here is an example side by side of I use the default for US English and French What do you think?

[janagombitova]

I think that is very smart!

[valllllll2000]

@janagombitova After using the app I have noticed that we put the date next to the datapoint name (top right), and sometimes that name is very long:

I wonder if it wouldn't make more sense to put the date at the right/bottom or right middle, see below:

[janagombitova]

The middle looks best to me. Good catch

[janagombitova]

I am reopening this issue as I think we need to reconsider the design once more. We made the change using a short data point name. But in practice the names are long (consisting of more answers). The changes now result in a lot of white space and less data points visible in the screen as one takes up a lot of vertical space.

@Kiarii and @valllllll2000 what do you think?

[valllllll2000]

That does not look nice at all, I would in this case suggest putting the date at the bottom on the same level as status which is usually short, see for example:

[janagombitova]

Putting the date down is also a way to go, but then I wonder why not keep it in line with the rest...

Do we have three different font sizes? Maybe we can make the ID, status and date the same size - small and decrease the font of the name too. How about also limiting the spacing a bit between lines to save space?

And third thought, I know we spoke about it before and said we should keep the time stamp, so you know which point came sooner. But after looking at some other apps, I think we could remove it for older points (from yesterday onwards). What do you think?

[Kiarii]

• We cannot support arbitrarily long DP display names on the datapoint list screen. Else we end up with datapoint names spanning more than two lines. These have to be truncated at some point. I would suggest we settle for two lines - truncating the rest and showing DP display name in full in the DP profile screen, wherein we could even consider providing a location stamp when location/gps info is available for a DP

• DP profile screen sketch with a a location stamp when location/gps info is available for a DP

• We are also over using and even duplicating (in DP Form and History tabs) DP data and time stamps. On the DP list screen, we do not need to use the two. We should use one or the other on the DP list screen but not the two - it sort of defeats the purpose..

• To take more space for the DP name, we can reduce the size of the DP status icon. Which calls into question why we are layering two icons as one while in the History tab we ditch duplicity. On a side note, we should simplify the Submit status icon - atm we use two icons - clock and wifi - one should suffice..

• We should also consider the necessity of showing DP id on the DP list screen - does Alphonso actually refer to DP Id (using a print out or some other way) when in the field? - Would it suffice to show this on the DP profile screen?

• We should also aim to ditch the duplication of DP status info - atm we use both text and icons, we should aim to use one, or a combination if necessary in order to reduce the amt of content on the screen while making it scannable and easy on the eye.. e.g. putting the time/date stamp and the status together clears up the screen space on the left to accommodate more text for the DP display name and still keeps the status clear and scannable

[janagombitova]

That is one long list of suggestions :) I made a summary of straightforward changes and then a list of what we still need to discuss clarify. I suggest we have a meeting with the three of us to talk them through.

Changes

• [ ] Decrease and unify font size
• [ ] Turnicate DP name if longer than 2 lines
• [ ] Show time stamp for DPs created/updated today and show only date for the rest
• [ ] Reduce size of DP status icon
• [ ] Simplify DP status icon - @Kiarii are you suggesting to use what we use in the History view? So a green tick for Uploaded, orange disk icon for saved, and for submitted the wifi or the clock (in the transmission history there is different arrow like icon that we use and call queued, by the way)
• [ ] Do not show DP ID in the list (if we move to the DP screen) - I think this is worth the experiment and to see if we hear back from users that they miss seeing this value in the list

To discuss:

• Show DP display name in full in the DP profile screen - How will this work for non-monitoring DP where once you click on the point you see the submission?
• Show DP location stamp in DP screen when location/gps info is available for a DP. Should this be clickable to view on the map?
• Moving the status icon to the left and removing the text description.

[valllllll2000]

• [ ] Do not show DP ID in the list (if we move to the DP screen) - I think this is worth the experiment and to see if we hear back from users that they miss seeing this value in the list

The datapoint id is one of the fields that can be searched, do we really want to remove it?

[valllllll2000]

• Show DP location stamp in DP screen when location/gps info is available for a DP. Should this be clickable to view on the map?

Sounds good, currently we show distance from current location and it is also used the datapoints by distance.

• Moving the status icon to the left and removing the text description.

But the status icon is already on the left? Do you mean top left?

[janagombitova]

Today, Valeria, Kiarii and I met to discuss the proposed changes and how to go about therm There are the decisions we made:

• On DP IDs - we will take the risk and hide it. We do not know if people use it so we will see if they do based on their reaction to the change.
• With search, we need to reveal the ID when searching and hide when Al is not searching
• Moving the DP ID to the "data point screen" will be handled in a separate issue as we need to detail out where to show it (a data point profile) for monitoring and non-monitoring data points.
• DP icons, we move to the right, under the date. Keep the colours as today, Kiarii to provide new icons (draft, you submitted = it is saved on the device = it has not been sent to Flow yet but the app is trying to do so if there is a network, uploaded/downloaded = received by Flow) and we use them in the other lists (History, Transmission history) as well
• If you have DP location enabled (and you have the location available) we show the location of the DP in the list. We considered make it clickable, but that would be hard and would mean to make the list longer what we do not want. We will see how to add the location to the data point profile. For now we leave the DP location (distance) as it is today

[valllllll2000]

Here is how it could look:

[Kiarii]

already the list is noticeably cleaner :) small observation:

• '.' instead of '/' in the date stamp, it makes it more legible.
• with the distance we could also lessen the amt of info we provide. In place of "Distance: 3.893.14 km" we could just say "3.9 km" ("0.5km", "0.1 km") - assuming that it is self explanatory to Alphonso what the distance stamp means; with his every move, the distances update.
• In addition it might not be necessary to be precise down to a cm.. However if we want to provide some precision in terms of meters, we could for distances below a km say "900 m", "5 m", "1 m"

[Kiarii]

After some deliberation and experimenting with icons for the datapoint states, I am tentative concluding that..

• There is a difference between an action and a state - perhaps not as noticeable - but from my experiments - attempting to use an into-cloud and into-device icons for uploading/downloading is a no, no as these imply an action more than a state.. Draft is perhaps unique in this case; the pencil icon can imply both status: draft and action: edit - which I think is practical for our case

• A “submitted” datapoint is in a state of either waiting to sync or syncing - for which I find a time icon or spinner being more indicative of the status (a background / server action) even respectively.. Atm when downloading Datapoints we do not indicate “downloading” but if we were to do that then a spinner would work both ways; downloading/uploading, and a timer in case of pending a connection, when downloading terminates in case of a connection outage.. I have come to assume that the time and spinner icons are more meaningful than a check icon - which typically indicates that content in question has been uploaded to the server (and is waiting to be pushed to a receiving device) while in our case it is not.

• For synced, lets keep the (single) check icon, and proceed from there.. I am reluctant to use a double check icon since that is typical of indicating state-workflow that differs with ours

• This would mean that for the 3 states that we have - draft, (submitted i.e.) pending sync and synced, we can represent them as illustrated - which is an incremental improvement and not an overhaul change. We keep the check and timer icons more or less as they were used..

• It also means that since the 3 states and respective icons are distinct from each other, we do not need to re-code them (redundantly) by color..

[janagombitova]

@Kiarii just one question: Why not use the spinner for the submitted state then? It indicates the 'progress' of uploading (if happening or not due to connection, but Flow keeps on trying). Plus as an extra plus point for the spinner, looking at the screens it is hard to see at first glance the difference from the circular time and circular tick.

[valllllll2000]

@Kiarii just one question: Why not use the spinner for the submitted state then? It indicates the 'progress' of uploading (if happening or not due to connection, but Flow keeps on trying). Plus as an extra plus point for the spinner, looking at the screens it is hard to see at first glance the difference from the circular time and circular tick.

I like the "time" icon for "pending" state because we don't know if it will be uploaded or not or when. The spinner really means something is happening now and it may be not the case. We do show "uploading" notification when datapoints are being uploaded. But I do agree the icons are too much a alike at first I though we only had 2 states. Maybe the tick should not have a circle in it?

Also another thought: I can create a prototype with both black and white and colored versions and see how it looks so we compare

[janagombitova]

@valllllll2000 ok then. Let's use the time. And a prototype with 2 options sounds perfect 👍

[valllllll2000]

[janagombitova]

I like the 1st colourful one. But curious to hear @Kiarii 's thoughts

[valllllll2000]

New example taking into account Kiarii's recommendations

• use 18dp images
• 54% opacity black outline icons from https://material.io/resources/icons
• align icon at the bottom right

[janagombitova]

It is looking promising. My only note is that we agreed not to move to black-n-white icons to not implement too many changes and to not loose the "quickly scan to see the status of my submissions" feeling the colours provide.

[valllllll2000]

Here is an example of colored icons (with 54% opacity)

[valllllll2000]

and full opacity color

[valllllll2000]

the date stamp should take a smaller font size - since it is an element of a secondary or tertiary importance in the datapoint component - when it is of the same size as the datapoint, it competes for prominence with the name which is the primary element.. (this is also the case with apps such as messaging and chat apps)

[Kiarii]

All datapoints are equal but some are more equal than others; the inequalities

• Some datapoint names may only span one line
• Some datapoints may not have a distance stamp

In which case, the alignment of datapoint elements appear as being visually unbalanced;

Given this inequalities, keeping the status icon on the left makes more sense, since the elements of a datapoint are located in visually balanced manner e.g.

NB [for later] For surveys without a location or geoshape question - it makes no sense to provide the MAP Tab as an alt view to the datapoints

About the color coding, am still reluctant to keep it given that :

• green for synced makes most sense, even though it is a redundant coding - the check by itself indicates that everything is right or done for a dp
• orange if it implies a warning or sth that the user needs to do shdnt apply to the clock icon - as syncing is a device/app task.
• the icons are distinctive by themselves in which a double coding by color adds another layer of cognitive effort to discern not one but two codes..

[janagombitova]

@Kiarii I hear your concerns about the colour coding, but I am going to use my power of veto this time and say, we keep the colours. We are changing enough already in the screen. If this change is taken positively and users get used to it, then we can again reopen the discussion on taking away the colours for the icons.

[valllllll2000]

Latest screenshot with the requested changes

[Kiarii]

Notes for more improvement:

• For the check icon lets try a green: 00AB34
• Align the status icon to middle of the first line of the dp name. The size of the icons, i will comment after test driving the emerging visual hierarchy..
• The distance and time stamps are secondary to the datapoint name. If the dp name is 16px, lets see how the component looks as a whole with distance as 14 and time as 12.
• Dp name line height: 24, dist stamp line height: 20
• datapoint name and accompanying metadata stamps take black (000000) as the font color with alphas of 87 and 54% respectively
• the list component height shd differ - we have at least 3 cases given that the dp component can comprise: 1 line (no distance stamp), 2 lines (either dp = 1 line, and dist = 1 line, or dp = 2 lines and there no distance) and 3 lines (dp = 2 lines, dist = 1 line) - I need to test what we have on a device to see if and what improvements are needed..

[valllllll2000]

Notes for more improvement:

• For the check icon lets try a green: 00AB34

Done

• Align the status icon to middle of the first line of the dp name. The size of the icons, i will comment after test driving the emerging visual hierarchy..

OK

• The distance and time stamps are secondary to the datapoint name. If the dp name is 16px, lets see how the component looks as a whole with distance as 14 and time as 12.

Done, we used sp instead of pixels so its 16sp, 14sp and 12sp

• Dp name line height: 24, dist stamp line height: 20

I don't understand what this refers to, maybe a screenshot could help, does it mean the height of the textview?

• datapoint name and accompanying metadata stamps take black (000000) as the font color with alphas of 87 and 54% respectively

What is those metadata stamps? For now what I did is datapoint name text color #DE000000 (the first 2 refer to alpha) and distance and time #8A000000 not sure it's what you meant

[Kiarii]

• with the alpha I meant opacity of 87 and 54%
• Line height dictates the space between lines in a paragraph (more or less) https://material.io/design/typography/understanding-typography.html#readability. We need to experiment to find a suitable visual balance..

[valllllll2000]

[valllllll2000]

New version after Kiarii's recommendation:

[valllllll2000]

There seems to be a visual defect in some cases where location is missing:

1) The space is empty when the distance is missing, there should be only one line in this case 2) For some reason only 1 of the 2 points is displayed, reloading the app corrects the issue

Another issue, I forgot to implement: "

With search, we need to reveal the ID when searching and hide when Al is not searching

"