Feature request: Button interface for value map widgets

[she-weeds]

I've tried to see if this has been brought up at all for qfield or qgis and haven't really found anything, so apologies if it's a repeat.

Is it feasible/possible for there to be a button UI (similar to Option Row in ROAM) for simple list widgets like Value Map in QField?

For rapid assessments with short lists, we find that being able to select a value with a button (all options immediately visible, one press) is much faster than selecting a value from a dropdown list (requires two separate presses, not all options immediately visible).

Of course the mobile interface adds extra limitations in terms of space, but I think there is merit in having buttons for short lists (3-5 values).

I understand QField's forms are based off QGIS widget/form settings; is it fair to assume that requesting buttons in QField will require upstream amendments in QGIS? What would be the best channels through which to get this implemented?

[lp-dj]

+1

This is a missing feature that I am also often asked about by colleagues for whom I configure QField projects.

I just think out loud:

I would think that even significantly more than 3-5 entries could be possible if needed.

Just think about the calendar widget. I guess this is a good example that even in a small space many values can be accommodated without losing usability.

If necessary, you have to use meaningful abbreviations for the values in longer lists as a user of the widget. And possibly categories through which you can scroll, comparable to the months and years in the calendar. And it would be worth considering whether the grid size (x & y dimension) is automatically determined or also freely configurable?

So, I could imagine that a freely configurable calendar-like widget which is always displayed in the attribute form and does not appear only at the push of a button could already be enough? What do you think?

The question remains, where such a feature would have to be triggered most effectively. ;)

[she-weeds]

Certainly the use of the Value/Description setup of the Value Map widget would be useful to create abbreviations for use as button text.

I would think though once you get into scrolling territory you almost might as well use the existing drop down list UI with search function? One of the reasons I would be grateful to see button UI implemented is because several colleagues want to avoid scrolling as much as possible - it can be finicky on smaller screens or in rapid assessments.

[m-kuhn]

That would be a great enhancement, I think it could be triggered via a new "radio button" option that would also be available for qgis.

[she-weeds]

It's definitely been puzzling - radio buttons are one of the most basic form UIs out there but QGIS has been limited to boolean checkboxes and dropdown lists this whole time. If there's a project or group out there working on buttons I'd love to support them personally. Surely it can't be too complicated to implement, compared to the tremendous overhaul of annotations done in the most recent release.

[m-kuhn]

If the demand for this is high enough I'm sure someone will contact developers and ask for a quote. If this is such a basic functionality it cannot be too complicated to find a sponsor for that.

[lp-dj]

Certainly the use of the Value/Description setup of the Value Map widget would be useful to create abbreviations for use as button text.

I would think though once you get into scrolling territory you almost might as well use the existing drop down list UI with search function? One of the reasons I would be grateful to see button UI implemented is because several colleagues want to avoid scrolling as much as possible - it can be finicky on smaller screens or in rapid assessments.

Yes you are right @she-weeds. Personally, I would agree that you can just as well use the drop-down list with search function before you provide a new scrollable widget.

However, I also know colleagues who would like to avoid typing at least as much as scrolling ;)

Hence my idea with the categories as a compromise to allow targeted scrolling and thus shorten the process of scrolling a bit.

But I'm also undecided what I would prefer myself. I think it's a tradeoff between ease of use and greater functionality in some situations.

Probably the radio buttons suggested by @m-kuhn would fit better into the operating concept of QField.

[jpnunn]

Hi I guess this is still not possible? This would be really useful for the ornithology team who have to quickly guess every 15 sec the height of bird (tricky I imagine!). Having 3-6 horizontal radiobuttons for each height band of the bird (and a duplicate field for each 15 second estimate) would really help the process and also allow them to visualize the height of the bird a better than drop down list as they scroll down the page.