Horizontal bars (on vertical arrays)

[cashaffer]

It should be possible to have vars on vertical array (which makes the bars horizontal).

[vkaravir]

True. And like you suggested in an email, the direction and layout should be separated. Here's what I suggest:

• layout option controls the layout and valid values are array and bar
• direction(??) controls the direction of the array. It should be able to "rotate" the array into any direction using this option. See image below for an example. Suggestions for the name of this option? Suggestions for the values for the different directions?
  

The same option could be enabled for all the structures. Then it would be possible to have, for example, linked lists go left-to-right, top-to-bottom, bottom-to-top, and right-to-left. Sound useful? And more importantly, does this sound like it would solve your current need as well?

[vkaravir]

Another thing: should it be possible to have control whether the array indexing starts from top or bottom/left or right?

[cashaffer]

Yes, this all sounds good! And yes, it should be possible to index either top to bottom, or bottom to top.

"direction" seems like a reasonable name to me, if you are restricting things to left vs. right and up vs. down.

However, when you say "rotate the array into any direction" did you literally mean "any"? As in, giving an angle and letting the element rotate? I think there is a good version of this concept, and a version that is not viable. The issue has to do with the orientation of the labels with respect to the data structure. What you show above looks ideal, in that for a bar array, there are four basic arrangements. So this is not "any" rotation.

Independent from this, it would be nice if any collection of graphical objects could be rotated. So for example, I might want to take the upward-growing bar graph in your first image on the left above, and turn it 45 degrees clockwise (labels and all).

[vkaravir]

However, when you say "rotate the array into any direction" did you literally mean "any"? As in, giving an angle and letting the element rotate? I think there is a good version of this concept, and a version that is not viable. The issue has to do with the orientation of the labels with respect to the data structure. What you show above looks ideal, in that for a bar array, there are four basic arrangements. So this is not "any" rotation.

I did mean any of the directions in the images. Here's what I'm thinking for the value of direction. It should consist of three parts:

• horizontal/vertical which controls whether the bars/indices are placed next to or on top of each other
• left/right which controls where indexing starts in horizontal arrays (indices next to each other) or alignment and index label position in vertical arrays (indices on top of each other)
• top/bottom which controls alignment and index label position in horizontal arrays (indices next to each other) or where indexing starts in vertical arrays (indices on top of each other)

So, for example, vertical right top would give an array like the 3rd from left in the image above. The last image would be horizontal left top. Default value (image on left) would be vertical left bottom.
Does this make sense?

Independent from this, it would be nice if any collection of graphical objects could be rotated. So for example, I might want to take the upward-growing bar graph in your first image on the left above, and turn it 45 degrees clockwise (labels and all).

This is already possible already with arr.css("transform", "rotate(45deg)"). It will break, for example, the .bounds() function of the structures. Given the length of the current TODO list, I'd like to see a sensible use case for this before trying to fix the bounds issue.

[cashaffer]

It is a little confusing in that the second and third parameters appear to swap meaning, depending on the value of the first parameter. I can live with that, though it would be nice if that didn't happen.

A bigger problem is this: If I understand you, the second/third parameter (depending on the value of the first) is attempting to control label placement with respect to the associated bar. The problem here is that I can think of several possibilities for label placement. (Note, these are not "index labels" as I would interpret that term, they are the array values. The indices relate to the position in the array, and appear separately. I will use the term "value labels" below to separate the two.)

Let's just consider the default layout, where the bars are vertical, and the indexing starts on the left. Where do the value labels go? The default is within the bar, at the bottom. But I could imagine that any of these alternatives might be viable: (1) Under the bar (that is where the index labels typically go). (2) Inside the bar, but at the top (or even the middle?). (3) Above the bar. I can accept an argument that none of those choices make much sense except at the inside/bottom (unless the value labels replace the index labels, and appear below the bars). But if you make that argument, what is the point of the third parameter? In all four of your images, the value labels appear inside the bar at the relative "base".

Given the length of the current TODO list, I'd like to see a sensible use case for this before trying to fix the bounds issue.

Fair enough. :)

[vkaravir]

It is a little confusing in that the second and third parameters appear to swap meaning, depending on the value of the first parameter. I can live with that, though it would be nice if that didn't happen.

That's true. Actually, the direction of the indexing could be specified with the existing indexed option. Currently it is expected to be a boolean with a default value of false. However, it could well take values top, bottom, left, and rightto specify where the indexing starts. The direction option would then be used to specify only the vertical/horizontal layout and the alignment of the value and index labels. Would this make it more intuitive?

As for the different possible positions of the value labels, I'd prefer JSAV placing the values inside the bars like it now positions them. If a more specific positioning is required, AV developers can change that position with CSS.

And I really did mean that the the direction option would control both array value labels and index labels position. For example, for the default array layout, setting direction to horizontal top would position the index labels above the elements instead of below like it does by default. For the bar layout, it would align the values to the top as well as place index labels above the bars.

[cashaffer]

Would this make it more intuitive?

I'm having trouble seeing the degrees of freedom. Once I decide to have bars that grow downwards (your right-most figure), what options are there about positioning the array values and array indices? Don't the values (if they appear) have to be inside at the top of the bars? And if the array indices appear, don't they have to be above the bars? The only choice is whether they go left to right, or right to left, correct?

Assuming that I have this right, then for the array indices, whether they appear is independent of whether they go left to right or right to left in the rightmost figure. So you can't replace the boolean in the indexed option with directions. Regardless of that, which values are legal for the direction option is still going to be dependent on the direction of the bars. But that seems better than switching the meaning for two parameters.

This is surprisingly difficult!

[vkaravir]

Assuming that I have this right, then for the array indices, whether they appear is independent of whether they go left to right or right to left in the rightmost figure. So you can't replace the boolean in the indexed option with directions.

You're absolutely right, how could I miss that? So there needs to be yet another option for the order of the indices. That could simply be a boolean flag indicating whether to use the default index direction or to reverse it. Those seem like the only choices that make sense. Anyway, I suggest we open another issue for that feature and here focus on the horizontal bar array which, I'm assuming, is needed soon.

If the layout and direction options now make sense I'll go ahead and implement those.

[cashaffer]

Sounds good.