nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Preference vs Add-in

IkjuShin

Hi Folks,
I got a question from the biggest customer in Korea.
Not sure who to discuss with, so I am writing here.

Situation
1) JMP users change the Default of Preferences according to their preferences.
2) They use add-ins a lot to use for common analysis of multiple employees
3) Sometimes, add-ins do not work properly due to differences in personal preference settings.

Their Needs
1) Please let Add-in(Script) take precedence over personal preference.
2) Or, is there any way to check the difference with personal preference settings when installing Add-ins?

Looking forward to sharing your ideas.
Ikju

Accepted answers

All comments

ChristianBille

Hi Ikju

I have had company’s use the preference manager to align employees preferences. This will not solve step 1 in your situation but it will ensure that the preferences are setup correctly for the Add-ins.

Here is a link to the preference manager: Preferences Manager (with import/export)

Hope it helps.

Best

Christian

ian_jmp

I haven't seen the Preference Manager up close, but it must rely on the fact that (via JSL) it's easy to get all the preferences, persist them (in the current session, or to disk), and then reinstate them. So in more 'corporate', multi-user settings, exploiting this is definitely a best practice to help make sure things don't break.

So you could put this burden on all the scripts that are in the add-in, and then the users don't even know what's happening and can have any preferences they like. Implementing this would just require that those who write add-ins use a template that has a small block of code at the start and at the end of each script. Additionally, you can set things up so that the script editor automatically starts up with this template code.

ChristianBille

Thats a cool idea Ian. It would proberply be the same script that could be added to the start and end of each Add-In making this a one time assignment.

to Ikju: If you can get your customers to post the question on how to achive Ians idea, I am certain a helpful someone would answer him there.

ian_jmp

Not sure about this, unfortunately: 'It would probably be the same script that could be added to the start and end of each Add-In making this a one time assignment'. If the add-in had, say two menu options (scripts), a user could use one, do something else, then use another. So I think it has to be at the script level. But the 'template' idea helps out here.

Mark_Bailey

Our JMP training for scripting identifies many steps of 'defensive scripting' including identifying dependence on preferences. Then the script should save preferences, modify them to suit its needs, and then restore.

It is more work for the person writing the script, but actually not much more. The user is happy and the editor is happy. Win-win!

DonMcCormack

I feel that the approach suggested by Ian would make more sense than using company wide preferences. Where I have seen the later implemented, I have heard frustration from regular JMP users who want to use their own preferences.

Jeff_Perkinson

The Ignore Platform Preferences() option in platform launches should cause the platform to launch with the default options.

From the Scripting Index:

Names Default To Here( 1 );
dt = Open( "$SAMPLE_DATA/Big Class.jmp" );
dt << Bivariate(
	Ignore Platform Preferences( 1 ),
	Y( :height ),
	X( :weight ),
	Action(
		Distribution(
			Y( :height, :weight ),
			Histograms Only
		)
	)
);

IkjuShin

Thank you all
I agree with Ian's idea. Preference Manager add-in introduced by Christian also seems to be useful. The 'Ignore Platform Preferences' that Jeff pointed out may be useful.

Add-ins are very useful, but sometimes problems seem to arise when only passively using add-ins made by others.