Allow user to change color sliders in a preset

[Robert Leach]

If the user clicks to drag a color slider, say in the red/green color preset, let them move it. Preset colors should be able to be selected & saved (automatically & transparently with a data file and) as a user favorite specific to the app. Do it using a select list similar to the way printer presets are presented in Mac OS X (see attached image). In this case, there would be no radio buttons at all.

Also, I think that the user should be able to change the color of an existing slider (and the ends of the color spectrum - like via fixed sliders on the ends that look different or are positioned differently from the others). The min/max "sliders" would also be color- & value- editable.

I would imagine an interface that looks something like the image I attached (created with a graphics program). Note, I also added a little square showing the missing data color on the button. I also added what I think the data value edit dialog could look like too.

[Robert Leach]

This is the same/similar feature that Michael requested.

[Robert Leach]

I edited this item's description based on our meeting and ideas I had.

[Robert Leach]

You might want to somehow visually indicate that the sliders on the bottom are fixed, like with a chain link icon or something - or make them so that a single-click brings up the data value dialog.

Probably could leave the default movable sliders above them at the top, or perhaps change the fixed sliders' positions to the left & right sides of the spectrum (not on top or bottom) like this:

[Anastasia Baryshnikova]

Yeah, I totally agree and like the suggested interface very much. Makes total sense to make the Min/Max values to be color editable and value editable exactly in the same way as the other handles.

If I understand you correctly, you're also suggesting to unify the Min/Max values with the end-of-spectrum handles. That is a great idea! Cytoscape makes you set them separately and that's such a waste of space. We should do it like this (and I think that's what you're saying too): the left-most and the right-most handles set the last colors in the spectrum; every value before the left-most and after the right-most handle is set to the color of the corresponding handle.

In terms of looks of the min/max handles, let's flip the triangles the other way around: looking to the left for the first one and to the right for the last one.

[Anastasia Baryshnikova]

This is a screenshot of how Cytoscape does it. We can do so much better!

[Robert Leach]

Issue #38 was marked as a duplicate of this issue.

[Christopher Keil]

Thanks for the screenshots and suggestions. I agree with everything and will implement it as such. I keep you guys posted. Once this is out, I think we have a solid color picker interface going.

[Robert Leach]

I just realized that there are a couple details I did not address with this idea:

1. Changing the min/max "fixed" sliders should either not allow you to change the color or if their color is changed, it should affect the color of the nearest real slider. The former would probably be a more intuitive solution, leading to less confusion. So this would mean that the current dialog we have for editing slider data values would essentially be what we would need for the min/max edit.

2. When we save user/app-level color presets, we should probably still assign default slider positions instead of use what was saved with the data that was used when creating them. The number and color of sliders would be the same however. We will probably have to put some more thought into default slider positions if the saved preset includes a number of sliders other than 3.

3. Also, I should clarify that the printer preset image I attached isn't necessarily how I think we should do things. It shows 4 selections: default, last used, save as preset, and show presets. At a minimum, we should have Red/Green (our "default"), and "save current settings as preset". We can add "show presets" (which would allow them to delete saved presets) at a later time. I don't think we need "last used".

[Anastasia Baryshnikova]

Can you explain (1) a little more? Why should we prevent people from changing simultaneously the max value and the color associated with it?

[Robert Leach]

Well, maybe I'm wrong. Let me think it out here with the current default:

I was thinking last night about logistics - implementing the new feature. Currently, in the default scheme, we have 3 sliders. Each one has an assigned color: red, black, & green. If the user changes the color of the "min" "fixed" "slider" to say, blue, does that change the color of the red slider on top to blue, do we create a new movable blue slider on top starting at the min, or do we simply leave the position of the blue color origin fixed at the min?

I don't necessarily think we should not allow the min/max "fixed sliders" to be color-editable. I just think that it's not completely thought out as to what should happen if the user changes its color. If we change the color of the nearest slider, the user might be surprised at the result. If we add a new blue slider when they change the min, they would also probably be somewhat confused. If we add a fourth blue color without the ability to adjust it, I think the user might also consider that unexpected and non-intuitive. I think that not allowing color changing of the min/max would be the least surprising thing we could do. I think that it might be the most logical, however I don't think it would be the most intuitive, because then those "fixed sliders" wouldn't necessarily be red & green.

Which avenue makes the most intuitive sense to you when dealing with fixed slider color?:

1. No ability to change the color (the appearance of the fixed slider would be the color of the nearest movable slider)
2. Add a 4th color with no corresponding movable slider
3. Change the color of the nearest slider to correspond
4. Add a new movable slider at the new data limit

Another thing we haven't considered: what if the user adjusts the min to a value greater than one of the sliders' values. Do we delete or adjust that slider's position? These are the annoying minutiae of coding that programmers have to account for.

[Robert Leach]

Refining/collecting thoughts on color adjustments. This includes a suggestion from the comments of issue #51 "Draw attention to the ability to type in values for sliders in color selector":

And I would think that option 2 from the previous comment (Add a 4th color with no corresponding movable slider) is the way Anastasia would like to go with the fixed "sliders" at the min/max.

[Anastasia Baryshnikova]

Here's what I think:

• The suggested values should only appear when you're setting the handle values (i.e., when you double click on the handle).
• If double click brings up the "edit handle" menu, we don't need "Edit selected"
• The 2 main buttons should be: "Add color" and "Remove selected color"
• The min/max handles should look the other way.
• The presents drop down should be at the top (it's the first thing you select)

[Robert Leach]

And this one incorporates an idea from issue #172 "Improve color guessing when first loading a data matrix". Plus, I changed the title of the window, depending on whether it's new or edit:

[Robert Leach]

I agree except for the second point. I agree that an "edit selected" button is not necessary, though I added it as a resolution to issue #51 "Draw attention to the ability to type in values for sliders in color selector". I'm open to other ideas. If not a button, how do you think we can call attention to the fact that the sliders can be edited via double-click? I know that when I first saw the interface, I didn't know you could enter exact values for the sliders by double-clicking them. I'm not sure how I found that out, but I don't think I found it out on my own.

[Robert Leach]

So you're suggesting something more like this:

Along with the new/edit color slider dialogs above.

[Anastasia Baryshnikova]

Yep. Also:

• I'd write: "Move, add or edit sliders to adjust color scheme"
• Do we really have to write "Min" and "Max" under the 2 extreme handles? Wouldn't it be obvious that they define the color from that point (-1 or 1) on
• The buttons should say "Add color" and "Remove selected color" (and "Edit selected color", I see your point from the comment above)
• The Missing data button seems kinda out of place there.. maybe it's best to align it to the left instead? or center, just like the other buttons?

[Robert Leach]

I still think that we have not addressed issue #51 with our color dialog layout. As I had mentioned before, when I first encountered the dialog, I had no idea I could double-click a slider and edit the value. Even though an "Edit Selected" seems redundant, it would definitely call attention to the fact that a user can edit a slider. Either that, or the text above could say that you can double-click the sliders.

Regarding the behavior of the presets, I just looked to see how my print menu does it. It appears to actually save my changes automatically in the current preset. I.e. the next time I bring up the print interface, I select my preset "Toner save mode" and the changes I made during the last print are still there, even if I cancel & dismiss the window. So here's what I think we should do.

Preset menu options:

Red/Green (this would be red/green/black) Yellow/Blue (this would be Yellow/Blue/white) show presets... (This would allow deletion of saved presets) save as new preset... (This would bring up a window asking you to name the preset, and it would get the values of the current color preset)

These would be saved with the data always so that users can share their data and other users would see the same thing. But I think it would also be nice for certain presets to be available to different data sets. I don't know how we should do that however. If we did like the printer presets, the presets would all change with a change for each data set and I don't think that's what we want. Perhaps we do need another menu option:

last used (preset used in that last file that was opened)

at the application level. Also, in the "show presets" window, there could be a reset button or a red/green button and blue/yellow button.

[Christopher Keil]

The saving of a custom preset needs to be a separate issue if it doesn't already exist. We talked about this in the meeting and that's a thing for alpha03.

The way to go here is to leave the Red/Green and Yellow/Blue presets untouched in the stored Preferences. The user can still edit them normally but it will be saved as a new preset and always stored under the name "last used" unless the user explicitly clicks a button to save it with a custom name.

This way it won't be confusing with disabled editing functions and at the same time we can always let the user snap back to the 2 default settings. "Custom" will be replaced by "last used".

Regarding #51, I have implemented an "edit selected" button. I think that's good.

[Christopher Keil]

The actual issue has been resolved. For some reason a discussion about the whole UI has taken place in this comment section.

The resolution does not concern some of the other features discussed here.

[Robert Leach]

OK. I'm cool with that. We can test it out and see if users will have any confusion over it.

[Christopher Keil]

Sounds good.

[Robert Leach]

Merged to master.

[Robert Leach]

Removing milestone: Color settings (automated comment)