-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Radio Buttons (design and implement) #4
Comments
Perhaps we could use IconToggleNode (https://github.com/phetsims/color-vision/blob/master/js/common/view/IconToggleNode.js) in color-vision as a starting point. Right now this implementation only supports two options, but we could generalize it. |
@ariel-phet logged an issue about using a more standard approach in the Under Pressure sim, see phetsims/under-pressure#74. We should elevate the priority of this, start discussing in design meeting, creating and reviewing prototypes, so that we can get it worked out. |
Here is some potentially useful dialog on this topic: http://ux.stackexchange.com/questions/39080/buttons-instead-of-radio-buttons-or-a-dropdown |
We discussed this at a recent developer meeting, and we are hesitant to move forward with the “color vision” style radio buttons without further discussion. The color-vision buttons seem to suffer from problems that (a) the deselected button doesn’t look enabled and (b) the deselected button doesn’t look too much like a button and has a distracting dotted border and (c) how will this look and work against a light background. |
Here's the segmented radio button from the link @jbphet posted above. Perhaps this would work well for images (we would have to check), and one thing we like about this button is that it clearly "groups" them: |
We may also find some inspiration here: http://www.uiparade.com/ |
Other issues with the Color Vision radio buttons:
|
My first impression of http://www.uiparade.com/ is that the majority of the components use skeuomorphism. UI-design in general is going in the opposite direction, toward a flatter 'look' that shuns skeuomorphism. |
@samreid, Should I add highlight on mouseover and remove the hand icon when over the selected option in color-vision? |
In my opinion, not essential before publication of 1.0. But it's something that should be discussed as part of generalization+ reuse for other sims. |
I recommend that we also consider check boxes while considering redesign for radio buttons. Showing which button is selected for radio buttons overlaps somewhat with showing whether an option is selected or not, as done for checkboxes, and it would be good for us to investigate consistent UI paradigms. |
Regarding check boxes: it came up in a meeting today that CheckBoxes are not particularly attractive for many students. Not sure if another UI paradigm would solve that or not (or whether it must be solved). EDIT: Not attractive means the students do not use the checkboxes much |
Sam has asked me to work on this and create a component that resembles those used in Energy Skate Park Basics (that also highlights when you mouse over it). Assigning to myself. |
A note to @aaronsamuel137: Perhaps the implementation for the radio buttons should share much of the code for the standalone buttons (in sun/buttons/). They provide support for highlighting on mouseover, different rendering styles (flat vs 3d) and nice input listeners + models. If we do not reuse that code, we should probably make an effort to match it for consistency. |
I've gotten a good start on the RadioButtons. Let me know if they look like they are going in the right direction. Assigning to @samreid for suggestions, review, and next steps. Look at the buttons demo for an example usage. Since you mentioned modeling the look of the buttons off of both energy-skate-park-basics and also the code for the standalone buttons, I wasn't sure which to go for for the defaults. |
I started reviewing the RadioButtons.js implementation and I think it is a good step in the right direction. I like how well it integrates with the existing buttons library, and handles highlighting, presses, selection and the cursor. |
In the above commit, I created appearances more like the ones we are targeting for situations like Energy Skate Park: Basics and color vision. The next step will be to abstract over appearance, so that it is customizable (not sure exactly how to do that yet). |
I tried using the new radio buttons in Under Pressure and ran into a number of problems, see the above commit and http://www.colorado.edu/physics/phet/dev/html/under-pressure/1.1.0-dev.2/under-pressure_en.html |
As we discussed at yesterday's meeting, this still needs to be more thoroughly code reviewed. @pixelzoom will be taking a closer look. |
RadioButtonGroup is one type of radio button. So no, finishing #119 does not resolve this issue. I will review RadioButtonGroup, but there is much to be done on "radio buttons". |
No plans to work on this at the moment, others feel free. |
@pixelzoom please open a new issue describing any outstanding work to be done for radio buttons (if any). |
Outstanding work: • Are there other types of radio buttons that would be useful for PhET sims? That was the "design" part of this issue before it became the "implement RadioButtonGroup" issue. I see no evidence that the general design discussion was completed. • Do we need 3D vs flat look for radio buttons, as we have for other buttons? • Why don't radio buttons use the sun "button" framework? That was recommended by @samreid in #4 (comment) and didn't happen - why not? • We have RadioButtonGroup and VerticalAquaRadioButtonGroup. Do we really need different "Group" containers for different types of buttons? (See also #30). • Why are some radio buttons is sun/js/buttons/ while others are in sun/js/? • We currently have supertype ... And I could probably come up with more. Yes, radio buttons are usable. No, their implementation is not in a good final state. |
I'm inclined to turn each of the bullets from #4 (comment) into separate issues and close this one. All opposed? All in favor? |
Meeting consensus: let's make each a separate issue |
New issues noted above, closing. |
No description provided.
The text was updated successfully, but these errors were encountered: