Collect: Enumerator can add another repeated question while in one

[seadowg]

This feature was driven out by research here and is mocked up here.

Acceptance

• [x] Given I'm filling out birds.xml
  And I'm already adding an observation
  When I click the ➕ icon in the top right
  And I click "Add"
  Then I can fill out another observation

• [x] Given I'm filling out birds.xml
  And I'm already adding an observation
  When I click the ➕ icon in the top right
  And I click "Do not add"
  Then I return to where I was

• [x] Given I'm filling out birds.xml
  And I've already added 2 observations
  And I'm in the first observation
  When I click the ➕ icon in the top right
  Then I'm filling out a third observation

• [x] Given I'm filling out birds.xml
  And I'm already adding an observation
  When I click the ➕ icon in the top right
  And click "Add"
  Then an analytics event is sent ("AddRepeat", "Inline")

• [x] Given I'm filling out birds.xml
  And I'm already adding an observation
  When I click the ➕ icon in the top right
  And click "Do not add"
  Then an analytics event is sent ("AddRepeat", "InclineDecline")

• [x] Given I'm filling out birds.xml
  And I'm already adding an observation
  When I swipe top the end of the observation
  And I click "Add"
  Then an analytics event is sent ("AddRepeat", "Prompt")

• [x] Given I'm filling out birds.xml
  When I go to the observations hierarchy view
  When I click the ➕ icon in the top right
  Then an analytics event is sent ("AddRepeat", "Hierarchy")

[seadowg]

@lognaturel are you happy for this to go ahead?

[lognaturel]

I think there's some detail missing. Let's say there are 4 repeats and I'm at the beginning of the first instance. Do users expect adding a new second instance or fifth instance? Where would the button go relative to the other two top-level actions? Presumably it would be the right-most meaning that it could sometimes go into the overflow menu? Is the meaning of a + going to be clear to users?

Would be worth sharing an initial plan on the forum to get some feedback on that question, I think.

[seadowg]

@lognaturel yeah good questions.

Do users expect adding a new second instance or fifth instance?

Like with the ➕ in the hierarchy the new instance will always be the "last" one (so it would be a fifth in your example). The flow we heard about in research is adding partial details then adding another or having to add a new repeat in a hurry and I think both these work with that behaviour. I'll update the acceptance for this!

Where would the button go relative to the other two top-level actions?

No I've got it as left most (see the mockup) and I think we'd always want to show it.

Would be worth sharing an initial plan on the forum to get some feedback on that question, I think.

Yeah good idea. I'll post a link to this story in the research write up thread.

[lognaturel]

the new instance will always be the "last" one (so it would be a fifth in your example)

I'm getting a little ahead of things but just want to make sure I understand. The form controller would jump to the last instance repeat, show the dialog, and if the user tapped "Do not add" it would jump back to where it was?

No I've got it as left most (see the mockup) and I think we'd always want to show it.

Oops, missed the mockup, thanks. What happens on narrow screens? Would the three buttons always be shown or would one overflow? With what you have in the mockup, the jump button would overflow which seems problematic since it's also very useful for repeats.

[seadowg]

and if the user tapped "Do not add" it would jump back to where it was?

That would be nicest. For the acceptance I've gone with the current behaviour from the jump screen which is that you end up at the end of the form (the save and exit screen). I think we could look at making it jump back to where they were but I'd like to seperate that out. I'm making a (fairly safe I hope) assumption here that in pressing that button it's very unlikely you're not going to add a repeat (other than maybe the first time you press it).

What happens on narrow screens?

Yeah I'm gonna have a play with it. The buttons are currently set to alwaysShow but it looks like the form title gets truncated (ellipsized) so we're probbaly ok I think?

[seadowg]

@lognaturel I've updated the acceptance based on not showing a confirmation dialog when the user hits ➕. For others the thinking was that this introduced some weird flows when the user hit "Do not add".

[lognaturel]

Wait, hold up! I had suggested removing the dialog from the existing flow with + in the hierarchy view. What I feel strongly about is that if a user taps "Do not add", they should always remain exactly where they were when they tapped +. This is what is so strange about the hierarchy + case. You tap "do not add" and then you're after the last repeat that you wanted to add rather than back in the hierarchy view.

For this new + in the form filling experience, I could go either way. The dialog seems like a good idea because it feels natural within the form filling flow and it seems more likely that someone would tap it accidentally and would not know how to delete a repeat.

[seadowg]

@lognaturel woh sorry got our wires crossed there.

seems more likely that someone would tap it accidentally and would not know how to delete a repeat

Hmmmm I think that has me convinced we keep the dialog. I'll update the acceptance again. I reckon we have a different issue for changing the hierarchy button?

[seadowg]

@lognaturel I've added analytics acceptance. Seemed like a good idea to add analytics for all the routes to see how this ends up comparing to the other ways of adding repeats.

Also added an analytics event around if the user hits the ➕ and then "Do not add" ("InlineDecline"). If we see that being more popular than hitting "Add" then we know the feature isn't working...