cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Choose Language Hide Translation Bar

Manual axis labels are 'mixed up' when plotting multiple columns

What inspired this wish list request? 

 

The problem occurs in the following situation: When you plot various parameters/columns and rename one or more axis labels, the renamed axis label is tied to the position of the parameter on the graph and not to the parameter itself. For example, you can plot columns A, B, and C on the y-axis. Then rename the axis label of column A from "A" to "New label A". If you now insert a new column D above A, the axis labels will be: "New Label A", "A", "B", "C". So "D" will be directly labeled "New Label A", but in reality we only wanted to rename "A" to "New Label A". In some cases, this behavior can cause a lot of confusion.

 

What is the improvement you would like to see? 

 

When an axis label is changed, the change should be associated with the parameter/column, not just the chart position. Sometimes you want to change the order of the parameters in the chart and of course the change of the axis label should also change its positions accordingly.

 

Why is this idea important? 

 

This problem seems to be a bug and should be fixed since the behavior of JMP is unexpected. Wrong labels can cause a lot of confusion.

15 Comments
hogi
Level XII

I could reproduce this issue with Jmp 17.

Just run the code and try to drag the variable "height" on the Y axis. When you drag it below "weight_", everything is fine.

But when you drag "height"  on top of the Y axis,  it will be labelled "weight_" (!!)

 

This issue seems to be related to Graph builder: bug when dragging subplots  

Something which could make sense on plumbing layer, but looks strange on porcelain level (= user point of view).

 

It seems to be quite complicated to fix the issue. 

If it's too complicated  to fix the erroneous connection on the plumbing layer, I think it would be better to remove such mal-functioning "tubes":  revert axis labels to the original state

either
1) automatically when axes are added, dragged or removed - or at least :

2) via a menu item in the GUI - here is the wish: revert manually changed labels 

 

Wrong axis labels ... one of those things that you don't notice on your own while preparing the plots  - but colleagues/customers will do when you present the data!

 

 

hogi_0-1676646235801.png

 

Names Default to Here(1);
dt = Open( "$SAMPLE_DATA/Big Class.jmp" );
Graph Builder(
	Variables( X( :sex ), Y( :weight ), Overlay( :sex ) ),
	Elements( Points( X, Y )),
	SendToReport( Dispatch( {}, "Y title", TextEditBox, {Set Text( "weight_" )} ) )
)

 

hogi
Level XII

Same issue after removing a column from a Plot.

In the blow example, after removing the age information, Jmp thinks that "M" and "F" are different ages of the students.

 

Just imagine having 7 different values plotted on the y axis.

Then you can be sure that at least one of the axes has the wrong label.

Hard to find, huge impact!

 

Ultra-dangerous!!
Will this issue be fixed in  v17.2?

 

 

 

Names Default to Here(1);
dt = Open( "$SAMPLE_DATA/Big Class.jmp" );
dt << Graph Builder(
	Size( 451, 455 ),
	Show Control Panel( 0 ),
	Summary Statistic( "Median" ),
	Graph Spacing( 4 ),
	Variables( X( :sex ), Y( :age ), Y( :sex ), Overlay( :sex ) ),
	Elements(
		Position( 1, 1 ),
		Points( X, Y, Legend( 1 ) ),
		Smoother( X, Y, Legend( 2 ) )
	),
	Elements( Position( 1, 2 ), Points( X, Y, Legend( 7 ) ) ),
	SendToReport(
		Dispatch( {}, "Y title", TextEditBox, {Set Text( "the age" )} ),
		Dispatch( {}, "Y 1 title", TextEditBox, {Set Text( "the sex" )} )
	)
)
	
hogi
Level XII

... and will it be fixed in Jm18?

What do we have to do to get it fixed?

hogi
Level XII

response from Jmp support:

bug can be reproduced at their side: TS-00053509

 

Let's hope that Jmp Dev. team finds a solution to fix it.

hogi
Level XII

Today I had the issue in a meeting.

 

I was using Jmp to show a live analysis and had to show 2 columns next to each other on the x axis.

So I dragged the second column onto the x axis.

 

Then we were puzzled by the fact that both plots had almost identical labels on the x axis - we went forth and back several times and thought about an issue with the computer memory.

then I remembered this bug - and indeed: the first label on the x axis was manually edited - and when dragging the second column onto the x axis, the command was suddenly applied to the new subplot.

How embarrassing. I hope this issue will be fixed soon ...

 

So (note to myself):

Till this issue is fixed in Jmp , if you dared to edit an axis label: DON'T drag additional columns onto the axes

(especially: NOT to the left of an X axis with edited label, NOR on top of an edited label)

mia_stephens
Staff
Status changed to: Investigating
 

@hogi Thanks very much for your feedback here. This issue has been appropriately captured internally by JMP Technical Support and Product Mgmt., we definitely understand the concern and are in the process of investigating. We welcome your new feature requests on the JMP Wishlist, but please direct any suspected bug behavior like this to support@jmp.com going forward, and we will do our best to get right on it! 

 

Cheers - @PatrickGiuliano (JMP Technical Support)

hogi
Level XII

Hi @PatrickGiuliano , besides many feature requests from me - this one actually is from  @Lars 

 

I just thought that this topic was related to one of my requests:Graph builder: bug when dragging subplots .

But it seems that the marker/color settings of Graph Builder are actually exactly the settings which behave fine :

- if subplots are added or moved, some routine in the background calculates the changes and applies the marker & color settings correctly to the shifted subplots:
 https://community.jmp.com/t5/JMP-Wish-List/Graph-builder-bug-when-dragging-subplots/idc-p/680739/hig... 

 

hogi
Level XII

till the issue is fixed in a future release of JMP, one can use some JSL to revert the axis labels:
🙏 Graph Builder: revert changed axis labels 

 

mia_stephens
Staff
Status changed to: Yes, Stay Tuned!