Hi H2XH2X wrote: ↑Fri Nov 01, 2019 7:17 amVery sorry for chiming in so late, but did you consider background shading also as a way to indicate checked / not checked?Jaymos wrote: ↑Mon Oct 28, 2019 8:45 amWalter's suggestion pixel playing paid off. I fixed the pixel spacing and Dani completed the radio buttons and added check boxes as well.
The underlining idea did not work on the DM42, but the compressing of the words did work and saved some pixels to make space for the radio buttons on the sides.
Distinguishing between radio buttons and checkboxes may still be an issue (albeit perhaps difficult anyway given the small size), as well as conveying that the option is checkable in the first place - but might the latter be self evident based on the option?
Anyway, how would one convey which radio buttons belong together in a group?
Yes I considered it, but I did not want to create confusion as the menu softkey buttons already are inverted.
I experimented with solid underlining and also with halftone underlining (every second pixel in a three pixel thick line, in chess board style).
The halftoning (shading) is not very visible on the DM42. This experience also made it clear that making inverted text usng halftoning will also not work.
I do not intend making it clear which radio buttons belong in a group. I do not want to add more clutter to that area. Grouping must make it clear.
As example, I laid out the following screen to have the groups sort of stick together:
I grouped top left as a 2x2 cluster of options for menu control (in progress, that functionality not working yet).
I grouped top right to be the 3x1 cluster of options for the single shift button control.
I group bottom right as 3x1 RadioButtons for the default entry setting.
And I stuck eRPN which does not relate to any of those, and is a square check box, in the middle on the primary keys.
Grouping is not always possible especially in a full screen, but comments on readability will certainly be considered.