Remembering previously entered value in ODK Collect

#21

Hi @joeldean,

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

Mathieu

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

1 Like
#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.

split this topic #24

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

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

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

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

#28

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

#29

Great. We are on it!

1 Like
#30

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

1 Like
#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?

2 Likes
#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].

2 Likes
#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.

#34

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.

3 Likes
XLSForm spec proposal: add syntax to make it easy to use a value from the last saved instance
#35

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?

split this topic #36

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

closed #37