Radio button group with no selection

Using Streamlit
1

Hi all. I need a radio button group with no selection – I cannot make an assumption about what my user will choose. I can’t figure out how to do this, or if it’s possible.

The default index for a radio button group is the first item. If index is supplied it is validated against the number of buttons. Is there a way to have a radio box unselected by default?

5 Likes
2

Hi @James_Cole, welcome to the Streamlit community!

We do a similar method in the Streamlit Hello demo, where we use st.selectbox() with the first value being -…we set that value as the default, and when the app starts, it shows the default intro page:


So maybe you could do something like that?

Best,
Randy

3

Thanks for the reply Randy!

As in the following radio buttons?
-
Yes
No
That would allow the user to make a decision, it’s true. But I would not be proud of the UX I was delivering. I’m happy to submit an issue explaining what I need and why?

4

Yeah, if it must be a radio button, then it would be pretty ugly. It’s less ugly if you use a selectbox, but if the requirement is firmly a radio button then that doesn’t help.

Please feel free to open an issue, but one thing about this is, I’m not sure this is a Streamlit issue but a radio button conceptual issue. Old radios with push buttons were always on something, and I think web designers carried that forward. Would be interesting to see what our front-end group has to say.

Best,
Randy

5

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:

  1. Require more clicks
  2. 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! :slightly_smiling_face:

2 Likes
6

The radio push button being on always on something makes little sense if you need to discriminate your app capabilities using the radio button. In Streamlit, the radio is not for form submission, but it can be used when you need to chose between possible app paths, with an entire configuration displayed for each one, and the options need to be visible beforehand. And selectbox hides these paths. If it is already selected, the app will load an entire section, which is bad for usability. I think it should never ever be selected by default here.

2 Likes
7

You can hide the first radio button option using a style, and ignore first option always

div[role="radiogroup"] >  :first-child{
           display: none !important;
}

Code can be found in https://github.com/rchamila/Streamlit-radio.git or you can use below

st.markdown(
    """ <style>
            div[role="radiogroup"] >  :first-child{
                display: none !important;
            }
        </style>
        """,
    unsafe_allow_html=True
)

But keep in mind that this will apply to all the radio button groups in your app.

6 Likes
8

Hi,

I agree about the benefit of a ‘no selection’ radio button. My use case is to provide the user a number of topics, with a selection of pages available under each. Ideally, in the sidebar, this would look like:

Topic 1

  • Page 1
  • Page 2

Topic 2

  • Page 3
  • Page 4

The user can select any of the pages (but never more than one). Perhaps there could be a feature as follows:

selection = st.radio_set(“description”, {‘Topic1’: [list of pages], ‘Topic2’: [list of pages]}).

It could return a tuple like: (Topic1, Page2)

3 Likes