search

corona-warn-app / cwa-wishlist

Central repository to collect community feature requests and improvements. The CWA development ends on May 31, 2023. You still can warn other users until April 30, 2023. More information:
https://coronawarn.app/en/faq/#ramp_down
Apache License 2.0
105 stars 14 forks source link

Provide both timestamps for risk calculation by EnsExposureDetection and by PtExposureDetection #497

Open vaubaehn opened 3 years ago

vaubaehn commented 3 years ago

Current Implementation

Since CWA version 2.0 there are two different approaches to calculate the infection risk of the user: Either by checking for exposures using the (bluetooth-based) Exposure Notification System (ENS), or by checking for exposures using CWA's Presence Tracing (PT; aka Event Registration; QR code-based check ins). But up to CWA version 2.1.2, there is only one timestamp shown on the risk card in main screen, that represents the time, when CWA provided Diagnosis Keys to the ENS for exposure matching. There is no information yet, when exposures were checked with PT. Thus, the timestamp on the risk card is misleading. To handle this problem. for the Android version, there is a recent PR (https://github.com/corona-warn-app/cwa-app-android/pull/3051), that will change the timestamp to the time, when the last risk calculation was performed, either by ENS exposure detection or by PT exposure detection. The fix is planned for CWA v. 2.2. I suppose there will be a similar PR for iOS, or it's already implemented.

Expected Problems

There may be situations, when one of the two approaches to check for exposures is not working correctly. For example, I experienced problems with ENS exposure checks lately (see https://github.com/corona-warn-app/cwa-app-android/issues/2880 and https://github.com/corona-warn-app/cwa-app-android/issues/2881). In such a case, with the planned PR https://github.com/corona-warn-app/cwa-app-android/pull/3051, the risk card may stay 'green' and the timestamp on the risk card will always reflect the last PT exposure check. Thus, the user will not easily be able to understand/to verify, whether the ENS exposure detection worked correctly (unless user checks inside Google's/Apple's ENS UI - but the the timestamp on the risk card and the green status may be confusing at least). Same problem might occur the other way round, when there should be a problem with Presence Tracing - only the successful ENS checks will be reflected by the timestamp. @harambasicluka encouraged me (https://github.com/corona-warn-app/cwa-app-android/pull/3051#issuecomment-831304778), to open an issue for this here.

Suggested Enhancement

Personally, I think it's ok to have only one single timestamp on risk card, that reflects the last risk calculation (either ENS or PT). But there should be an easy access to both ENS and PT risk calculation timestamps, to enable the user to track whether both risk calculations perform successful. These seperate timestamps could be added to the App Information screen, below the CWA version number and the ENS version number (Android only), for example:

Last risk calculations
Exposure Notification System: Today, 02:13 .
Presence Tracing:             Today, 15:34 .

(For sure, better formatted ;) Or these information could be moved to a sub-menu (like 'App statistics' or similar), but I'd definitely prefer the main App Information screen for fast access.

Expected Benefits

Users will easily be able to verify if both risk calculations work. In this way, users (and devs!) may find out more easy, whether there is a problem with ENS- or PT-based risk calculation (and then subsequently enable Debug Logging from CWA 2.2 on...). If there is no problem at all, then informational needs of some users may be fulfilled ("oh, see, app works!").

Thank you for your considerations!

Internal Tracking-ID: EXPOSUREAPP-7218

Ein-Tim commented 3 years ago

@vaubaehn

I agree with you that this would be useful but maybe showing two timestamps on the main risk card is a bit confusing for normal users. To move it to the App information screen is a good idea, but I guess not many users will find this there (the most don't even know that they can find the version number there).

Wouldn't it be possible to only show two timestamps if they aren't the same (or very close together)? One could imagine that two timestamps will be shown if f.e. the bluetooth based risk calculation worked at 19:00h, but the last risk calculation for PT failed at this time (let's say the last successfully risk check for PT was at 15:00h). Only then the app will show 2 timestamps.

Also it's important to inform the user what to do if he/she experiences this, so a link to the FAQ, etc. would be necessary (:

vaubaehn commented 3 years ago

@Ein-Tim

To move it to the App information screen is a good idea, but I guess not many users will find this there (the most don't even know that they can find the version number there).

I don't think this is a problem at all - because the information is mostly relevant for debugging. I had some concrete problems lately, where it is very useful to know. When (hopefully not) other users come here to report an issue that could be related, we could guide the users to provide these timestamps to us.

Wouldn't it be possible to only show two timestamps if they aren't the same (or very close together)? One could imagine that two timestamps will be shown if f.e. the bluetooth based risk calculation worked at 19:00h, but the last risk calculation for PT failed at this time (let's say the last successfully risk check for PT was at 15:00h). Only then the app will show 2 timestamps.

I think that's possible theoretically, but much more complicated to implement (adding additional logic). Plainly printing the timestamps in app info fragment is fair enough, imho. Also, it may get really confusing, I think, when suddenly two different timestamps appear...

Also it's important to inform the user what to do if he/she experiences this, so a link to the FAQ, etc. would be necessary (:

I think this is a little bit overfeatured... Help in that issue is what we are here for, isn't it? ;)

I'll add your issue to the event-registration overview.

Thanks, but this may be only "half-related" ;)

Ein-Tim commented 3 years ago

@vaubaehn

I don't think this is a problem at all - because the information is mostly relevant for debugging. I had some concrete problems lately, where it is very useful to know.

Okay, I understand your point. Are these things covered by the logging feature coming in version 2.2 (I haven't had any time to look at it yet - sorry for the question)?

When (hopefully not) other users come here to report an issue that could be related, we could guide the users to provide these timestamps to us.

True, but the user has to somehow find out that something went wrong, if problems with PtExposureDetection appear but the user continues to see the normal risk card without any indication that something isn't working and the app behaves normally, he/she won't find out that something's wrong and thus not open an issue here.

I think that's possible theoretically, but much more complicated to implement (adding additional logic). Plainly printing the timestamps in app info fragment is fair enough, imho. Also, it may get really confusing, I think, when suddenly two different timestamps appear...

I think this is a little bit overfeatured... Help in that issue is what we are here for, isn't it? ;)

Agreed 👍

vaubaehn commented 3 years ago

@Ein-Tim

I don't think this is a problem at all - because the information is mostly relevant for debugging. I had some concrete problems lately, where it is very useful to know.

Okay, I understand your point. Are these things covered by the logging feature coming in version 2.2 (I haven't had any time to look at it yet - sorry for the question)?

They should be covered by the Debug Log feature, but for simple verifications it's hard to always enable logging and then find the relevant points inside the long logs. For example my use case: ENS was/is not reliably checking for exposures, same diagnosis keys were provided several times for checking. When there was a successful check (ENS did something and sent an intent back to CWA, even it was the same package like the day/some hours before CWA could provide diagnosis keys to ENS, and ENS took them over successfully), it was reflected in the timestamp on the risk card. If I want to verify exposure checks after the PR gets merged, I indeed would need to enable Debug Logging and try to find the timestamps there. If it's just about the ENS issue, it would be much more of ease, to only look to the timestamp that may be provided in app information fragment in the future. If there is a problem (outdated timestamp compared to expected timestamp), then it would make sense to enable debug logging, to get more insight, where is the problem...

When (hopefully not) other users come here to report an issue that could be related, we could guide the users to provide these timestamps to us.

True, but the user has to somehow find out that something went wrong, if problems with PtExposureDetection appear but the user continues to see the normal risk card without and the app behaves normally, he/she won't find out that something's wrong and thus not open an issue here.

With the planned implementation for CWA 2.2 (PR https://github.com/corona-warn-app/cwa-app-android/pull/3051) this seems to be the case in any way! This is why I try to mitigate future (invisible) problems with this enhancement request!

Ein-Tim commented 3 years ago

@vaubaehn I think it's too late for me today, now I understand what you mean! I fully support this feature, thanks for your explanations! 🙂

vaubaehn commented 3 years ago

@Ein-Tim No problem :) The enhancement request here is a kind of band-aid also. Better solution would be a good error handling in general, like some devs began thinking about it here: https://github.com/corona-warn-app/cwa-app-android/pull/2995#discussion_r622277201 Best option would probably be to show a warning card in main screen, when there is a repeating problem of risk calculation (either no download possible, or the workers are just not working, or whatever...) But I guess it will take a long time, until the aforementioned ideas (warning cards) are implemented...