Remembering previously entered value in ODK Collect

I know this topic is a bit old, but I wanted to drag it back because I still think it'd be very useful!

As I have chewed on this topic for the last few months, I think there are a couple of open questions that make it tricky to implement. I figured I should bring some of those out in the open and get a discussion started with the folks who wanted this feature.

  • Should this feature be enabled at the device level for all questions or something that a form designer enables on particular questions.
  • Is there a limit to how many things are remembered? If so, how does that get configured?
  • Is there a need to pre-load the auto-complete list?
  • How does one remove an item from this list?
  • Do deleted or cleared answers also appear on the list?
  • Does deleting the form that generated the item also delete it from the list?
  • Does this list appear immediately or as you start to type?

Should this feature be enabled at the device level for all questions or something that a form designer enables on particular questions.

I would lean toward the latter. Doing the former might be disruptive to existing users and could even lead to errors. Some questions you probably want people answering fresh from their head, not from an existing value.

Is there a limit to how many things are remembered? If so, how does that get configured?

Could be an option I guess. In our case we only need the last one.

Is there a need to pre-load the auto-complete list?

Not sure what this means.

How does one remove an item from this list?

This seems like it would be rarely needed. But I guess maybe you have little x's on each list item?

Do deleted or cleared answers also appear on the list?

I would say no.

Does deleting the form that generated the item also delete it from the list?

It might be interesting to be able to specify a unique identifier for a question and use that as the lookup key for these answers. That way if you have the same question (e.g. what is the village number) on multiple forms, you could re-use the value across both. If not provided then it would default to each question being treated separately.

If we did this, then the answer to the above is likely 'no'.

Does this list appear immediately or as you start to type?

I think this needs to be an option. Again, in our case, we want the immediate last value to be pre-loaded as the default. And in some cases we even want to increment it.

Also, by immediately, do you mean 'on focus'? Because in a field-list group it would be weird to show a bunch at once.

So some options might be:

  • lookup-key (string)
  • max-items (integer)
  • list-appear (on-focus, on-type, none)
  • pre-fill-last (true, increment, false)

Note that all the above reasoning applies to open text or number fields.

I note some of the above requests talk about basically re-sorting recently used values in a select1 or select question to the top of the list (right?). Perhaps lookup-key and max-items would apply in those cases but not the other two.

It also might be a good idea to track this as a separate feature request as it's rather different than the open text field case. Perhaps some of the same backend machinery could be used...

Hey everyone so after reading all the comments here this is an idea I have as to how the previously entered answers could be presented to the user.

  • I am displaying five answers as if that's the amount of previously selected answers that can be shown at a given time.

  • Each answer has a x (delete button) so that it can be removed if the user no longer wants to see it.

  • I am using a chips layout that derives from the material design specification for showing choices. It makes good use of the available space and it's also a common design pattern users have seen when using Gmail or other social apps.

  • In terms of behaviour, when an answer is entered the choices could collapse and when the user clears the input the choices reappear. That could also be a setting similar to how guidance hint has a collapsed/expanded mode.

  • Once the user begins to clear the answer it gets deselected and if they enter a new answer then when they fill it out another instance of the form it would be shown here as the most recent, and the oldest could be popped from the stack.

  • For field lists I think limiting it to the last option or the last two option might make the UI more functional.

  • I am gonna be working on a list variant of this design because I am not sure if it will handle longer answers well so will post two more mockups. One with a list design and another with chips that have longer answers.

Just some ideas! Let me know what you think!

With most of the ideas here, once we agree on a UI it's just for us to decide what will be standard in the feature and what can be an option in the settings menu eg. populating the field with most recent answer :slight_smile:

Hi @joeldean,

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

Mathieu

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.

1 Like

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.

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

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.

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.

@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.

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

Great. We are on it!

1 Like

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

1 Like

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?

2 Likes

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].

2 Likes

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.

The feature that @cooperka and @tomsmyth described in the roadmap is about to be released in Collect.

I'll try to summarize how I think of it and @cooperka/@tomsmyth, please jump in to correct and augment. The feature will make it possible to specify questions that should automatically be populated with the value that was in the filled form that was last saved. Here are some examples of what the feature enables:

  • use the feature for a "street" question in a form definition. The first time a surveyor opens the form, the street question's value will be blank. If the surveyor enters "Abbey Rd" as the street name and then saves the form, the next time the surveyor opens a blank form, the street question will have "Abbey Rd" set as the street name. The surveyor can then leave the street name as-is if he or she is still on the same street or change it if needed.
  • use the feature for a "earthquake date" question and questions in an "earthquake details" group in a form definition. The value of the last earthquake date saved and information about that earthquake is then available to other questions in the form. For example, a question could read "Would you like to enter data about the <value from last saved form> earthquake?" Based on that answer, a whole set of questions could be automatically populated or hidden.
  • use the feature for a "patient count" question in a form definition. The value of the last patient count saved could then be used to set the default. That is, the default value for "patient count" could be <value from last saved form> + 1.

These are just some examples of what can be done. The way to think of it is that any value from the last form that was saved can be pulled into the form design. This is deliberately the last filled form saved rather than the last filled form created because it means a user can open, review and save a form filled in the past to make it the "template" for the next new form created. For example, let's say I'm collecting data about natural disasters A and B. After I've filled one form about A, I can quickly fill out 10 more because when I open a blank form, the values about A will be pre-populated. Then, when I start filling out info about B, I can clear the defaults and fill out the info for B. If I then realize I need to fill out another form about A, I can open one of the original ones, save it, and then the next blank form I open will have values about A pre-populated.

(As a side note, @Xiphware, for the behavior to be consistent across clients, I would suggest that you keep track of the UUID of the row a value was last changed in and use the whole row as the last saved instance to be queried.)

The next step to make this easy to use is to agree on a way to use it in XLSForm. See XLSForm spec proposal: add column to default to previously-entered value for that discussion.

For those interested in the implementation details, there's also a conversation about the event that will trigger populating the defaults at Spec proposal: add first-load event to replace xforms-ready.

There are several different takes on remembering previously entered values that have been discussed in this thread. Some of them are a version of Enable Case Management/Preloading but others are interesting ideas that could be explored further. If your needs were not met by the feature that is shipping soon, consider creating a new feature request.

As another side note, this feature makes it possible to query one specific saved filled form. One way to think about case management is the ability to query any saved filled form and share saved forms across surveyors.

4 Likes

Hooray! Thanks everyone for all the work involved in this! Two years in the making!

Does this mean we can/should deprecate the ODK Counter app?

A post was split to a new topic: Should the remember last saved feature replace ODK Counter?