Remembering previously entered value in ODK Collect


(Mathieubossaert) #21

Hi @joeldean,

it looks very useful and close to what my colleagues want.
Thanks for the work !

Mathieu


(Hélène Martin) #22

Nice to see a concrete UI proposal, @joeldean!

I think this layout will be strange with fields lists (all questions on one screen). These are becoming more common as device screens get bigger so it's important the UI work well in that context. I share your concern about long values. How are you imagining the 5 values to show would be picked? Last entered? I'm also wondering what happens if I type e.g. Maserati in your example. Would the choices filter down to "Mazda" when I typed in "Ma" and then disappear when I type an "s"? This is again where I'm concerned about field lists -- the questions below would move up and I think that interaction might be a bit confusing.

Have you considered the autocomplete recommendations from material design? I think autocomplete could be displayed on field focus and ordered by most recently used. It could then filter down as a user types.

This is similar to what gmail does for autocomplete. It uses chips for existing items.


(Joel Dean) #23

Thanks for the feedback! With this approach I wasn't planning on filtering the items at all. They would just all be displayed when the question comes into focus.

Yes the autocomplete can work as well. That was the inclination I had at first but went for this design due to it's ability to be visible as soon as the user sees the question but an autocomplete accomplishes this and makes longer questions and also fits well with field lists as they are only being displayed when the question is focused.


(Hélène Martin) #24

9 posts were split to a new topic: Repeat visit use case: pig farming


(Alexandre A De Oliveira) #25

Hi @joeldean,
How this project of "previously entered answer" is going. I am looking for something like it. I am doing a re-census of tagged trees in tropical forest and I would like to show what trees are already measured during the work.


(Joel Dean) #26

Hey @aleadalardo I haven't started implementing the feature as yet because a specification is still being designed for it.

  • Currently, based on the decision here we have agreed that we can utilize an autocomplete UI that drops down with previously used answers for selection.

  • Considerations are being put in place from a technical perspective as to how the suggestions will be stored so that they can be retrieved quickly and indexed appropriately according to the respective form instances.

  • Finalizing the core set of features that are required for the initial implementation based on the responses and suggestions that were stated previously.

Once all of these have been thoroughly inspected and construed then a detailed specification will be written to guide it's implementation.


(Tom Smyth) #27

@joeldean @yanokwa any updates here? Who is/was working on writing this up as a spec? We may have some interest in taking it up.


(Yaw Anokwa) #28

@tomsmyth We don't have a spec for this and it'd be awesome if you'd take it up!


(Tom Smyth) #29

Great. We are on it!


(Kevin Cooper) #30

Just submitted: https://github.com/opendatakit/roadmap/issues/30


(Dr. Gareth S. Bestor) #31

Whilst it might seem nitpicky at first, please bear with me... define "previously"? If I have multiple forms in flight which I am filling in (and we dont want to suddenly constrain form filling workflow to now be strictly sequential...), whats going to happen to these 'previous' values? Will they now, apparantely, be coming from different form instances?


(Kevin Cooper) #32

This is defined in the proposal under the Proposed implementation section. Quoting for convenience, though, being a proposal, it's subject to change:

The cache is updated whenever a form is saved. Any question in the form that is intended to be cached will be re-cached on save, whether or not that specific question has been edited since the last save.

And then:

When filling out a new form instance, the question value is loaded and set from the cache at a specific point in time, depending on which option is being considered [options described in proposal].


(Dr. Gareth S. Bestor) #33

Thanks for the clarification. Part of my confusion is that in our implementation there is no 'save' per se - you can jump in and out of multiple forms at any time (whenever you change any control/question in a form, its value is immediately stored in the DB). So the closest we have to 'save' is when you hit the "Submit" button to upload all completed forms (after which you cant change anything anyway). I'll have to think how best do this then: eg update cache whenever the specific question is changed in any currently undertaken instance of the form, or add an "Update cache" button, or... Waiting till submit time to update the cache is obviously too late.