NeurodataWithoutBorders
Suggested improvements to DOB calendar selector
All three recent user test users tried to enter a subject's age of birth using the calendar popup and looked for a "Submit" button. Failing that, they tried pressing Enter. That closed the dialog and did not enter anything. That's pretty frustrating if you just spent some time clicking to find a particular date. (The way to select it is apparently to click outside the calendar which is not intuitive.)
- Can we add an Enter button at the bottom?
- Can we get rid of the time selector? I don't know of any lab that would store the time of birth except maybe for invertebrate subjects, but for them, age is probably counted differently anyway.
- The table does not make clear that if you have entered age, you do not need to enter DOB. The info box says it can be supplied instead of 'age', but people still try to add it. One user tried to add it despite obviously reading it, but maybe they were just testing it out. It is possible to enter an inconsistent age and DOB, and it seems very easy to do that accidentally. Maybe if age is entered, DOB should be grayed out, and vice versa?
Feel free to split this into separate issues if that makes more sense.
Did you actually confirm that the subject date of birth did not make it into the NWB file? There was an issue fixed a little while ago about the display but the actual values were still there under the hood
subject's age of birth
Assuming you mean date of birth here - was there a reason they didn't just do age?
Can we get rid of the time selector? I don't know of any lab that would store the time of birth except maybe for invertebrate subjects, but for them, age is probably counted differently anyway.
It's been seen before. They don't have to use it if they don't want to (default to 0:0:0)
The table does not make clear that if you have entered age, you do not need to enter DOB. The info box says it can be supplied instead of 'age', but people still try to add it. One user tried to add it despite obviously reading it, but maybe they were just testing it out. It is possible to enter an inconsistent age and DOB, and it seems very easy to do that accidentally. Maybe if age is entered, DOB should be grayed out, and vice versa?
Or pre-form input to determine which one they want to specify
- Since this is the HTML date selector itself, we cannot add additional styling or other behaviors to it
- We can get rid of the time, which nicely submits the value as soon as you click it. HandsOnTable actually has their own Date selector, though it doesn't support time. @CodyCBakerPhD Let me know which approach (using Date only or using Date-Time but not specifying time) you'd like to move forward with.
- I agree, a pre-form input would be the best way to ensure that there are no conflicting values here—since we would only render one of them following the user's selection. Ensuring that each are only editable if the other is blank across all Tables, Forms, etc. would be a large task, though not impossible, with minimal additional benefits. On the other hand, finishing the pre-form workflow lets us update how users will interact with the GUIDE as a whole across many different inputs.
- Is it possible to have 2 selectors, one for date (with no time popup) and one for time? If not, then we should include time selector for those that want it and proceed to (3) to simply choice (I assume most would just set age)
Two selectors under what condition? We can for different cells—but not the same one.
Two selectors under what condition? We can for different cells—but not the same one.
As in, make two cells, one for date (date selector, required if date of birth is the mode), one for time (time selector, optional), then glue together similar to experimenter name
Ah, I see. I could make a pop-up form cell—though this is currently implemented for my SimpleTable port of HandsOnTable rather than the HOT version itself.
Following up on our conversation yesterday, here are some key takeaways about our approach to this issue:
- Allow for manually changing the date-time as a string input
- Check out component libraries to see if we can find one that optionally allows time
@rly @CodyCBakerPhD Anything else you wanted to add?
(with 1. this would just be the + shift on the string, but anything compatible with Python tzinfo to inject direct to datetime is the current programmatic way)
Check out component libraries to see if we can find one that optionally allows time
Since most use cases do not involve setting time, I would say the default UI should have no time specified (once we update PyNWB to accept this).
I noticed one such UX design fort his earlier when scheduling a recurring zoom meeting, which requires a date and a time
However, instead of having these be a single component, it has separate components/form fields for each part. We might just want to simplify like that
I noticed this one recently; it shows up in Google docs when you use a meeting template
I think it looks really good - no idea where to find the component though
This could be fairly easily made as a custom component, since it just requires a few input boxes that trigger the native web Date / Time managers.
Is this still high-priority? While easy, it'll take a good amount of work to refine.
If you can at least get a draft showing how to start and where it would be done, we can use that as a template to continue later
I imagine this can be done very unit-test like in terms of just making a component that looks and does these things