Introduction of widgets to Avni

[vinayvenu]

Context

As part of a different implementations, there was the need to change the widget type of a SingleSelect option to an autocomplete. This was introduced with a logic mentioning that any singleselect with more than 10 items will show up as an autocomplete.

When it comes to using this feature in the general context of Avni, there are a few challenges

1. Depending on the usage, field workers might now know all the options beforehand, so even with bigger option lists, they still might need to have the full list visible
2. In some cases, this still can be done for some form fields but not others. Even configuration of a default for an organisation might not be sufficient flexibility to cover frequent usecases

Additionally, if we introduce the concepts of widgets in Avni, it will lead to better visualisation, and therefore better choice to users. eg:

• Widgets can be used for different kind of datatypes. eg: A rating scale can either be a coded or a numeric
• A LMH scale can have a widget with smiley faces if required

Tech solution

We originally had the "type" field to cover this. Unfortunately, the meaning of this field has been overloaded to mean whether it has single or multiple answers. We cannot use this to identify our widget. Therefore, lets

• Introduce a new non-nullable field that defines the widget (lets call it widget). This can have a default value (called default).
• For SingleSelect fields, we can have two values - "default" and "Autocomplete"
• The Widget dropdown is introduced below the Type field (see image below)

• The Android client shows the right visualisations
• The Data Entry App shows the right visualisations based on the widget
• The widget is exported and imported when using the bundle export/import mechanism
• All existing concept APIs are modified to include the widget

Out of scope

• Introduction of a widget_config that can configure more details that might be necessary for a visualisation. This is not required for the current proposed change

[mahalakshme]

@vinayvenu can we have dropdown with autocomplete so that users know the values - hoping this will not affect the performance equally as the single select. - We can do this whenever the no of options exceed 10 instead of giving the option since we know that is not performance optimal and to keep things simple(we need not introduce widget to fix the performance issue with single select).

But the concepts of widgets seem to be a good idea for our product, we already have it I think for time - spinner,etc., at org level.

[vinayvenu]

@mahalakshme The existing implementation reuses the Address autocomplete control, which works fine imo.

[vinayvenu]

Also, as mentioned above, putting a blanket autocomplete, even with a drop-down style might be too much of a disruption for our users.

It will be hard to explain why two input controls, one with 9 and the next with 11 answers are shown differently.