Remembering previously entered value in ODK Collect

What is the general goal of the feature?
I would like to see ODK Collect remember the previously entered value for a form/question combination. I'm imagining this feature could be implemented as some kind of auto-complete for text fields or as an explicit store and recall that is specified in the form design for other fields. @tomsmyth and mentioned something similar on this Github issue.

What are some example use cases for this feature?
I've been part of campaigns where enumerators are entering the same piece of data into a form over and over again. This is not data like their username or phone number, but rather a village name

What can you contribute to making this feature a reality?
I will help design the feature, participate in discussions about how to add this to the spec, and test implementations of it.

This is super interesting. We were going to do an external app for this but if we can do it in ODK, better to spend our resources that way. What is the way forward here?

that will be a great feature

It would be helpful to get a series of use cases and some UI sketches. @Vincent_Mkandawire, if you could describe what you have in mind, that would be super helpful. What kind of question you would want it for? Do you imagine getting suggestions across all previous answers or just the latest? How do you imagine the form designer would specify which fields have this functionality?

@tomsmyth, I think that in your specific case of needing an incrementing value, there are a lot of advantages to using an external app. It would be able to keep a mapping between instanceID and the counter, would allow manual reset and things like that. I imagine the autocomplete feature @yanokwa describes as being more useful for text fields.

1 Like

I work in humanitarian research where we conduct alot of research. So as mentioned, we sometimes want to speed up the data entry process by suggestions from already entered data from previous forms. For instance auto-filling suggestion of some recurring variables like district, village etc.

Good morning,

In my case (and for other french users I know), we use ODK to map species stations on field. Even if we propose a complete species list (external data into csv file), it would be very helpfull to have in the head of the list, the last entered values, to avoid to have to type the first chars of the species to find it again in the whole list.

1 Like


we have exactly the same needs as those evoked by @mathieubossaert.

We are also very interested by this feature. Like @mathieubossaert and @pailletm we use ODK to map wild species. one form = one species station with other informations (watcher, weather, natural habitat, day of observation, etc.) wich don't change at every form, so if we could have the previously entered value for these questions it will be great !

1 Like

@CRoy @Vincent_Mkandawire are your fields select fields (one or multiple) as @mathieubossaert described or open text fields?

usually they are select one fields

@LN, it might be select fields, open text fields, date, etc.

Would a reasonable approach be that

  1. When the user saves an instance, either finalised or not, they can mark it as a template.

  2. This then creates a duplicate of the saved instance but recorded as type "template". Templates would never be submitted to the server. The reason to create a duplicate of the real instance is so that the template can be retained after results are submitted and deleted.

  3. If the user then clicks on a new button "start template" they will select from the available templates. This will then create a new instance, using a copy of the template instance and open it for editing just as it would if the user had selected a saved instance for editing.

1 Like

@Neil_Penman I love the feature you are suggesting and there's a work in progress pull request at that does something very similar. It allows users to make a copy of a full instance. We haven't shipped it because it's not clear how the feature should behave. Can you take a look at the pull request see if that implementation would satisfy your needs?

@tomsmyth @Vincent_Mkandawire @mathieubossaert @pailletm @CRoy Does the approach that Neil is suggesting of templating a saved form satisfy your needs? It's different than the historical auto-complete that I was suggesting, but we need user feedback before we can decide.

Good morning and thanks for your interest.

I think that Neil's approach is interesting but does not satisfy our "need". What I have in mind is the possibility, for example in a repeat (so in only one instance) to first show the previous value I choose in a given choices list.
On the field, it should run like this :

  • I start a form
  • I choose a study
  • I choose a protocole
    • I create a 1st geopointpoint
      • I choose in a liste the 1st species i saw there
      • I chosse the second one
    • I create a 2nd geopoint
      • I choose in a list the 1st species i saw there and here I want Collect to first list the species I saw before in the instance
      • I chosse the second one
    • Last geopoint
  • End of the instance
1 Like

Another scenario description from @mariolrosado in

I have to fill in my forms whenever I add the same information to each form filling, in my situation
I collect the geographic coordinate of several energy poles from the local power company.

One of the information I always have to inform in a field that I call CSC Code (this code is composed of sequences of letters and numbers), and repeats every street, avenue, etc ā€¦
Whenever I collect data from a street post, the code will be repeated, if the collection happens to be from another street, the code should change.

Another field I always need to report to each collection is the name of the street on which this collected point is located. Then each street will be repeated in the field filling several times, until the collection is made on the next street.

I need to create a rule that always keeps in the fill field the previous value collected, until I want to enter new data. (Important that this information remain in the field, of a new form even sending the previous form to server).

@yanokwa I think it could technically work but it seems like a bit of a clunky/surprising interaction for our use case. I don't think many people would, on their own, think to create a template as a way of reusing a value for a single field (team name).

I think a way to load the previous entered value (your original suggestion) would be preferable to this for our case. Or custom form metadata -- either would work OK I think. But for the other use cases showing up here it seems like previous entered value would be the more widely applicable solution.

One note: I would rather have the ability to specify that the previously entered value be loaded as a default right off the bat, instead of making the user tap on the field and pick from a list of suggestions every time. Both would be cool to have as options I guess. But in our use case it's more likely to be enter once, reuse like 100 times.

Thanks for keeping this discussion moving!

1 Like


I work in an ecology lab where we do a lot of tracking of species on stations. Researchers who go to the field want to access the last entered value for two reasons: to increase the speed of input because the values of the fields are not subject to change but especially to be on that they are on the right station.

In a study carried out in my laboratory, it was noted: A need that has often been expressed and which seems important is to be able to consult a history, notably data from previous field missions, be it a few days before, or those of recent years.

For this reason, it was not possible to retain the ODK product and we had to develop our own solution based on QGIS (see .pdf). We solved our problem of access to the last entered value to the detriment of all the other functionalities.


1 Like

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: