Thanks again for your help Randy.
This is for an optional feedback mechanism. Selects are appropriate where there are many options, but here, with just two, a select would:
- Require more clicks
- Somewhat conceal what the select is actually for by having the options hidden
So I think a radio button is more appropriate.
I’m afraid it is not correct that a radio button group must always have a selection. HTML allows a group without a selection. It is usually better to have a default but there are circumstances where it’s not appropriate (like mine). There’s a lot of detail on the UX issues around radio buttons on the Nielsen Norman Group website.
At the moment we’re asking ourselves if Streamlit is flexible enough to be the primary interface for some simple user-facing tools. Plotly’s Dash provides a python facade over HTML (e.g.
html.Div), and in a sense that’s what Streamlit does too. For me, as an engineer who does a lot of UI/UX work, the ideal would be to have everything that is available in HTML also available in Streamlit (I know that’s a big ask). An idiosyncratic or more restrictive API means if I’m designing an interface I’ll always be wondering if Streamlit is capable of supporting it – the more transparent the API the less friction. I totally appreciate that tradeoffs have to be made. We all really like Streamlit and very much want it to support our goals. We’re looking forward to CSS/grids/flexbox etc!