Add support for combination of minimal and autocomplete appearances

[lognaturel]

• @seadowg facilitates design studio with @grzesiek2010 and @lognaturel to clarify need and design decisions to make
• @seadowg makes higher-fidelity mockup to evaluate usability and feasibility
• share mockup and implementation plan on the forum
• update issue with mockup, edge cases, etc

[seadowg]

Ok here's a first pass for the select one flow: https://www.figma.com/proto/Dxe1UF9reRdLYy8o5jishW/Minimal-automcomplete-select?node-id=12%3A1&viewport=-189%2C360%2C0.5426362752914429&scaling=scale-down

Let me know what you think! Sharing here initially and then I think we can do forum.

[lognaturel]

first pass for the select one flow

So fancy! I think that the full screen dialog with the search bar at the top looks good. What pushed you in that direction over a regular dialog?J

Small thing but with all of the question types that involve a button for capturing/editing values, the current value shows up below the button. This is to ensure that the button is available even if the selected choice is long.

[seadowg]

So fancy! I think that the full screen dialog with the search bar at the top looks good. What pushed you in that direction over a regular dialog?

Just that I couldn't find examples of "search" in a modal dialog. Felt like it would be good to keep search where someone might expect it.

Small thing but with all of the question types that involve a button for capturing/editing values, the current value shows up below the button. Small thing but with all of the question types that involve a button for capturing/editing values, the current value shows up below the button.

Hmm interesting. Move it below then? I guess it's good for the action to be the most prominent thing and it keeps it consistent.

[seadowg]

Ok here's a second route (that came up during a discussion between @lognaturel and I) where we use a text field: https://www.figma.com/proto/Dxe1UF9reRdLYy8o5jishW/Minimal-automcomplete-select?node-id=24%3A1774&viewport=826%2C271%2C0.500446617603302&scaling=min-zoom

[getodk-bot]

Hello @seadowg, you have been unassigned from this issue because you have not updated this issue or any referenced pull requests for over 15 days.

You can reclaim this issue or claim any other issue by commenting @getodk-bot claim on that issue.

Thanks for your contributions, and hope to see you again soon!

[seadowg]

How are we feeling about this different versions @grzesiek2010 / @lognaturel?

[grzesiek2010]

The version with EditText seems strange at first glance because I'm used to buttons in such widgets. As you said it was a conversation between you and @lognaturel so maybe you can share some details about your thinking?
Would that EditText represent the same EditText used for filtering options or maybe display selected options inside?

[seadowg]

@grzesiek2010 we were thinking about it more like a search field with autocomplete. Similar to the search bar on Android/iOS home screens. This route definitely makes the assumption you have a lot of options (that typing to find is easier than scrolling) but I think that feels safe for this.

[lognaturel]

Sorry about the delay.

I'm liking the edit text because like @seadowg says, it feels more like a search field with autocomplete. The other thing I like about it is that it would consume less vertical space and there isn't the question of where the selected value should go in relation to the button. I also think that we could and should phase out the buttons as they currently exist for most widgets as they're not very visually appealing and take up a lot of space.

[seadowg]

Happy for me to go ahead with posting on the forum? Was thinking of replying to one of the posts and then linking in the others.

[lognaturel]

Sounds great! I think it should go on the feature thread and yes, linking to the other posts and tagging participants in those threads sounds great.