Closed wraseman closed 5 years ago
Sounds good to me! I think the functionality is more apparent with that name.
While I'm at it, I think I'll also change hideAxes()
to partitionAxes()
. This way, there is no overlap/confusion with hideAxis()
from parcoords, and it's no longer implied that the method is specifically meant to hide different axes. Rather, the method lays out which axes will be shown in each chart. Thoughts?
How about we keep hideAxes()
and showAxes()
but we add specifyAxes()
?
The default behavior would be that specifyAxes()
is set to all without even calling it. Among axes that are specified, the user would be able to hide or show axes from there. For instance, if the user wants to create a chart with axes A, B, C, D, E, and F divided among two charts they would do this.
// Chart 1 gets A, B, and C; Chart 2 gets D, E, F
ps.specifyAxes({
0: ["A", "B", "C"],
1: ["D", "E", "F"]
});
// on button click code: hide "A" from Chart 1 and "D" from Chart 2
ps.hideAxes( {
0: ["A"],
1: ["D"]
})
// on button click code: error, cannot hide axis that isn't specified...
ps.hideAxes( {
0: ["D"], // this axis does not belong to Chart 1
1: ["A"] // this axis does not belong to Chart 2
})
To me, the distinction is that specifyAxes
is generally meant to be hardcoded (if the dataset is known beforehand), whereas hide/show is almost exclusively useful for dynamic interaction. Also, I feel like the word "specify" is more intuitive than "partition".
Thoughts?
Haha I actually forgot we had the showAxes()
function too. I see what you're saying in the sense that this might make more sense to the user initially. In a way, this might be seen as over-defining the system, because specifyAxes()
would essentially do the same thing as hideAxes()
, but with the effect of showing only the partition instead of hiding it. However, I agree that it's a worthwhile addition from an intuitive standpoint, and makes sense from a general usage perspective.
That said, I'd like to use setAxesLayout(layout)
instead of specifyAxes(partition)
, where layout
takes the place of the original partition
object. How do you feel about this naming convention?
I like it! Let's go ahead with setAxesLayout(layout)
. I also agree with your thought about over-defining the system. Let's remove hideAxes()
and showAxes()
entirely. The user could almost as easily achieve both of their functionalities using setAxesLayout(layout)
.
I almost recommended that, but removed the suggestion at the last second because hideAxes
and showAxes
are actually very intuitive and convenient for implementing in an interactive scenario. I'll start with making this new function and let's see how things feel before removing them.
Sounds good to me.
These changes are implemented, but the parcoords bug referenced in #14 breaks setAxesLayout
as well.
@joshhjacobson, let's change .aggregateScore() to .weightedSum(). The literature around that method uses the term "weighted sum model" or "weighted sum method".