Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Eliminate minute and second from footprint #99

Open
BaNazari opened this issue May 3, 2020 · 10 comments
Open

Eliminate minute and second from footprint #99

BaNazari opened this issue May 3, 2020 · 10 comments

Comments

@BaNazari
Copy link
Collaborator

BaNazari commented May 3, 2020

Most of people can not remember the exact time of their presence in a place. We force them to input minute and second and we use this exact amounts in "check my footprint" section. I think it is better (and safer) to only take time entry as hour and then add a safety factor or constant minus duration, so it covers for example from half an hour before real entry.

@marleymarl
Copy link
Owner

I agree on the seconds but disagree on the minutes. Per hour is not precise enough.

@heldersepu
Copy link
Collaborator

I agree with the seconds that is not really needed but minutes even if not precise do help...
Will send a fix for the seconds shortly

@BaNazari
Copy link
Collaborator Author

BaNazari commented May 3, 2020

How about a "half-hour" unit? Or quarter? I think it's more compatible with how human remembers his actions. Also this we the process of time matching would be more "correct", as both patient and "check my footprint user" enter data within time boxes which are closer to what really has happened. I mean in a situation that the patient has entered 2:35 and the ordinary user wants to check 2:30, it is not safe to tell the user that you were not in contact. People can not be taken as a source of truth for minutes of their presence ...
And also, presence is not a "moment", it is a duration. We take it as a point in time.
Time box entry helps the both issues.

@heldersepu
Copy link
Collaborator

The situation you present:

patient has entered 2:35 and the ordinary user wants to check 2:30

We will not asses risk by matching the time to a precise minute, there will be time boundaries, like a margin or error in math, safer to report false positives than miss a potential contact.

@heldersepu
Copy link
Collaborator

heldersepu commented May 3, 2020

Since we are dealing with a virus a margin or error could be half life on solid surfaces, so the example you presented

patient has entered 2:35

We could flag anyone near the same location as:

  • a high risk from 1:35 to 6:35
  • a medium risk from 6:35 to 8:35
  • a low risk from 8:35 to 10:35

@heldersepu
Copy link
Collaborator

heldersepu commented May 3, 2020

Now from a technical perspective the TimePicker does have an interval option minuteStep

Here is how that looks like in action:
Screenshot from 2020-05-03 16-38-10

The selection has less items on the list, but end user is not limited instead of selecting we can still type a precise minute if desired.

You can try it here:
https://codesandbox.io/s/interval-option-ant-design-demo-hsrpx?file=/index.js

Maybe we want to do that minuteStep ... not much work for me either way

@BaNazari
Copy link
Collaborator Author

BaNazari commented May 4, 2020

"We could flag anyone near the same location as:

a high risk from 1:35 to 6:35
a medium risk from 6:35 to 8:35
a low risk from 8:35 to 10:35"

=> Makes sense, more precise steps will be extracted from real data if needed.

"The selection has less items on the list, but end user is not limited instead of selecting we can still type a precise minute if desired."

=>With those constants I think we can leave the numbers to the user memory and focus on our estimation model. But I think time entry as a point does not work at least for most situations. People do not appear and disappear, they stay somewhere for a while. I suggest ant Range Picker.

@marleymarl
Copy link
Owner

I agree with @heldersepu - let's make it precise as possible given UX constraints (it was annonying to grab seconds) and then leave it up to the data processing layer to decide how to build rules for time ranges when using the data that has been stored.

@BaNazari
Copy link
Collaborator Author

BaNazari commented May 4, 2020

@marleymarl I agreed with him as well in last comment. I suggested using time ranges for another reason (people "spend time" in places).

@marleymarl
Copy link
Owner

That's an interesting concept adding ranges for each point. In essence it creates two points, one at the beginning and one at the end. There is a trade-off between additional accuracy and additional user load. I guess we can try it as an option and see how it works in practice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants