Usability issue in the settings: green / red buttons #284

privacytoolsIO opened this Issue Apr 6, 2015 · 13 comments


None yet

9 participants


hi guys,

first of all thanks for the dev of searx, we're currently setting it up here:

but I've noticed two usability issues in the preferences menu:

  1. it's confusing that "allow" is colored red and "block" is colored green. it would improvie the usability in my opinion to do it the other way around.
  2. Some people are red-green color blind:

thanks again for your great work!


Trim commented Apr 6, 2015


About these buttons, I'm always sticked with them because I never remind if they are switch to new state or if they display the actual state. So each time I want to modify these settings I have to do a search to confirm that was blocked/allowed.

Indeed, the red color means "not permitted" or "locked off" for me (as an European user) and the green the opposite. So here I have a meaning of "Allow" with the text and "not permitted" with the button color.

I think the use of a switch will be more clear, because we don't use colors with different meaning depending on the user context (and it will be better for red-green color blind) and it can show the current state and the fact we can change it in the same widget.

Thanks for the good work !

twelph commented Apr 6, 2015

That's a really nice switch! My vote is for that.


You have my vote, too. Btw, iOS / Yosemite is also using a switch and they spend a lot of money and thoughts in usability.

pointhi commented Apr 6, 2015

I think that switches would be great, but probably we have to add nojs support. The main functionality of searx should always work without javascript.

potato commented Apr 6, 2015

+1 to 'main functionality of searx should always work without javascript'
besides I think the current button behaviour is logical too: the color of the button represents the current state of the given setting, the text on the button represents the action that will happen when the user clicks it.
the color is just a visual aid, for the red-green color blind the message is still clear imho

"when you click me, I will allow you anything. or will I?" (Engine Button The First, 2013)

stef commented Apr 6, 2015

<3 guys! (re: "The main functionality of searx should always work without javascript.")


Maybe it's too high tech, and we should go back to the origin : what do you think about a simple checkbox ?

stef commented Apr 6, 2015

what you call "too high tech", others call backdoor or increased attack surface.

but to not only sarcasm around, i think individual themes can solve this however they like, actually i'd really like a simple theme like okhins original, couldn't imagine it with anything else but checkboxes.


@potato "besides I think the current button behaviour is logical too"
Yes, nobody said it's not logical. But the main rule of usability is "don't make me think" everything should be intuitive. The button represents the current state, but the label says the exact opposit.

Trim commented Apr 6, 2015

Ok, I understand the idea to not have javascript. In that case, I'll prefer to have a table like this:

Engine Enabled
Google [x]
Bing [ ]

(with [ ] and [x] replaced respectively by an inactive and an active checkbox)

The big issue for me, is that, actually, we don't know if the color represents the same thing than the text. Indeed, it's very uncommon to see one widget giving us 2 completely different pieces of information.


Agreed. That's the trouble with this kind of widget. I hate the iOS checkboxes for the same reason : I never know if it's on or off.


@Trim: Are you planning to still use the switch and the checkboxes for noscript users? That would be a good compromise if you ask me. Btw, I just saw that Google is also using radio buttons / checkboxes and it works fine.

Trim commented Apr 7, 2015

@privacytoolsIO sorry, for the confusion, I've never developed any thing inside this project, I'm just using searx on my server and providing ways to improve the settings page ;)

@dalf dalf added the ui label May 3, 2015
@dalf dalf added this to the version 0.9.0 milestone May 27, 2015
@asciimoo asciimoo closed this in 49403db Aug 9, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment