magmax/python-inquirer

Avoid using O/X for checkboxes for the default theme

denilsonsa opened this issue · 2 comments

Hello, this is a suggestion to make the default theme for checkboxes less ambiguous and more clear.

Screenshot showing the current default theme

Currently, we have Checkbox.selected_icon = "X" and Checkbox.unselected_icon = "o". However, this is not intuitive and can be quite confusing sometimes. If you consider the Japanese language (1, 2), the cross means NO and the circle means YES. Thus, if I have a checkbox displayed with either X or o, I could conclude X are the negation (or unmarked), while o are the selected.

What if you're not Japanese, or you don't know their language? Well, most people are familiar with video-games, and in many games the same symbols are used (across many consoles). Even the PlayStation controller included the cross and the circle as buttons, originally with the meaning of NO and YES.

The Inquirer.js project avoids that issue by using unicode characters: circle and circleFilled.


Thus, I would suggest replacing the Checkbox.unselected_icon with a plain underscore/underline symbol _. It's a symbol available anywhere on any encoding; and it looks empty, looks like a placeholder.

Screenshot showing the first theme suggestion (although by mistake I also changed the "X" to lowercase "x"

Alternatively, we could use '[ ]' and '[x]' as a three-character symbol. It looks good and very clear, but I'm afraid the additional 2 columns required for this look could impact some existing projects/users.

Screenshot showing the second theme suggestion

Hello, I see where you are comming from with this.

In generell this is exacly what themes are for. As usergroups affected by this require full unicode characters anyway, using GreenPassion or a custom them will be an obvious, uproblematic fix.

However, I like the idea of using [ ]/[x] as it matches Github/markdown and is indeed more clear. I also don't think three charactes should cause a problem. What do you think @staticdev?

Huh, I think now someone needs to update the screenshots from the documentation:

For consistency, it could be good to have the setup of the screenshots documented: which terminal, which font, which sub-pixel font rendering setting.