JMP Wish List

What inspired this wish list request?  When making a graph (e.g. using graph builder), any saved spec limits can be shown as reference lines. The default is a light blue, thin line which is often too thin to see easily (especially when copying graphs for a presentation). On a per graph basis the thickness/colour etc can be changed (by using the axis settings) but this takes a long time for many graphs (for example if many control charts are made). When saving a script the changes are saved, but they then no longer update if the spec limits are changed later. Any new graphs also have to be edited manually each time.     What is the improvement you would like to see?  Allow a platform wide preference for spec limit reference lines (colour/thickness etc). This could be saved as part of the new "platform presets" or as an install-wide preference?   Why is this idea important?  This would make the spec limit feature more useful and let graphs be easier to understand visually.   ... View more

What inspired this wish list request?    When I use Graph Builder, I prefer to use the Marker Drawing Mode = "Outlined".  There is no way to set this as a preference.     What is the improvement you would like to see?    Add a Marker Drawing Mode preference for Graph Builder.    Why is this idea important?  Every time I use Graph Builder I have to manually right click the graph to select the Marker Drawing mode I prefer.     ... View more

What inspired this Wish List Request? Deploying models to operations is a critical aspect of manufacturing continuous improvement.  The simulator gives operations the ability to understand how process variation will affect the critical response variables and optimize a response plan before adjusting the process.  Being able to deliver this in JMP Live would enable the deployment of these models with greater ease and to a larger audience to make data driven decisions.   Please describe the new or improved feature or solution you would like to see.   Enabling the JMP Live report consumer to modify the input distributions then click on the Simulate button in JMP Live and see the response histograms and statistics (defect rate, mean, SD) update.     Why is this idea important?  For customers using JMPLive for SPC, this will reduce the time between SPC signal and machine adjustment by allowing support personnel to instantly pivot from control charts to optimization options without moving between software tools or needing to transfer raw data from SPC tool to analysis tool.  Presumably this will also reduce scrap and equipment downtime by returning equipment to target state ASAP.  There are many enterprise level SPC tools available in the industry that have the same functionality of JMPLive, so there is no immediate driving force to change to JMPLive if a company has already invested in another SPC tool.   However, no other SPC tool, and really very few desktop tools, have the simulation capability of JMP.  If JMPLive could provide not only the INITIAL control signal through SPC but seamlessly allow an engineer to optimize input adjustments in the same tool then there is a true differentiator between JMPLive for SPC and other SPC tools.       ... View more

There is no way to set the decimals with 2 number in the presetting or by default. I have to choose it manually each time run tabulate function. ... View more

What inspired this wish list request?    Please see attached file.   What is the improvement you would like to see?    Please see attached file.   Why is this idea important?    Please see attached file. ... View more

R package has a library called OB analytics Can this be replicated? Will be of great utility for research in market microstructure theories ... View more

What inspired this wish list request?  Having to write my own tooling on top of existing JMP platforms to make sure JMP functions fast. In this case, calculations which can potentially take a long time (MSA) and users might have to go back-and-forth between different columns and it will trigger re-calculations.   What is the improvement you would like to see?  Implement cache for column switcher which would be utilized if there has been no changes to data. For example, in the following script if you change columns and come back to columns which you have already visited, JMP will recalculate the values which will take time. I would like to JMP to have some sort of memory of the already calculate columns which it would use if there has been no changes to warrant new calculation. Also, give an option to "pre-calculate" all columns in column switcher.   Names Default To Here(1); dt = Open("$SAMPLE_DATA/Semiconductor Capability.jmp"); dist = dt << Distribution( Continuous Distribution( Column(:NPN1), Always use column properties(1), Process Capability(0), Fit Normal(Goodness of Fit(1)) ), Histograms Only, Column Switcher( :NPN1, {:NPN1, :PNP1, :PNP2, :NPN2, :PNP3, :IVP1, :PNP4, :NPN3, :IVP2, :NPN4, :SIT1, :INM1, :INM2, :VPM1, :VPM2, :VPM3, :PMS1, :SNM1, :SPM1, :NPN5, :EP2, :ZD6, :PBA, :PLG, :CAP, :PBA3, :PLG2, :PNP5, :NPN6, :PNP6, :PNP7, :NPN7, :PNP8, :IVP3, :IVP4, :IVP5, :IVP6, :PNP9, :NPN8, :NPN9, :IVP7, :NPN10, :N_1, :PBA1, :WPR1, :B10, :PLY10, :VBE210, :VTN210, :VTP210, :SIT2, :SIT3, :INV2, :INV3, :INV4, :INV5, :FST1, :FST2, :RES1, :RES2, :PNM1, :PPM1, :FNM1, :FPM1, :FST3, :FST4, :RES3, :RES4, :A1, :B1, :A2N, :A2P, :A2P1, :IVP8, :IVP9, :DE_H1, :NF_H1, :ESM1, :ESM2, :ESP1, :YFU1, :VPM4, :PBA2, :PBB1, :LYA1, :LYB1, :DEM1, :DEP1, :NFM1, :PLY1, :VDP1, :VDP2, :SNW1, :RSP2, :PLY2, :RSP1, :VDP3, :PBL1, :PLG1, :VDP4, :SPW1, :VIA1, :INM3, :VPM5, :VPM6, :INM4, :VPM7, :M1_M1, :M2_M2, :P1_P1, :E2A1, :E2B1, :NPN11, :IVP10, :PNP10, :INM5, :VPM8, :VPM9, :INM6, :VPM10, :N2A1, :N2B1, :NM_L1, :P2A1, :P2B1, :PM_L1, :P1, :M1} ) ); Very quickly made example, but it is able to demonstrate how much snappier this is. Note: if you enable pre_calculate the script will be quite slow as the fitting isn't too fast in JMP but there is of course reward in the end, as can very quickly go through all reports after (let analysis run, go get a glass of water, come back and have a snappy way of viewing results)   Names Default To Here(1); dt = Open("$SAMPLE_DATA/Semiconductor Capability.jmp"); numcols = dt << Get Column Names("Numeric", "String"); pre_calculate = 0; aa_memory = Associative Array(numcols, Repeat({Empty()}, N Items(numcols))); nw = New Window("", H List Box( lb = List Box(numcols, << Set Max Selected(1)), dist_collector = V List Box() ) ); lb << Set Function(Function({this}, sel = this << get selected; If(N Items(sel) == 0, return(0); , sel = sel[1]; ); If(Is Empty(aa_memory[sel]), dist_collector << Append( aa_memory[sel] = V List Box(dt << Distribution( Continuous Distribution( Column(Eval(sel)), Always use column properties(1), Process Capability(0), Fit Normal(Goodness of Fit(1)) ), Histograms Only ); )); ); objs = Filter Each({obj}, aa_memory << get values, !Is Empty(obj) & obj != aa_memory[sel]; ); objs << Visibility("Collapse"); aa_memory[sel] << Visibility("Visible"); wait(0); )); If(pre_calculate, nw << Show Window(0); For(i = 1, i <= N Items(aa_memory), i++, lb << Set Selected(i, 1, run script(1)); ); nw << Show Window(1); , lb << Set Selected(1, 1, run script(1)); ); wait(0);       Why is this idea important?  Makes it easier to swap between different columns when using column switcher without having to wait for JMP to re-calculate everything. ... View more

What inspired this wish list request?  I recently had a team of new JMP users incorrectly evaluating the output of their Gage R&R analysis because it was unclear which row represented the total % Tolerance for the study.  There are several rows labeled as Gauge R&R or % Gauge R&R, but it is unclear what each row represents, particularly for people that are newly trained on Gauge R&R in general and on using JMP.   What is the improvement you would like to see?  Move the Gauge R&R row to the top of the AIAG Gauge R&R Results table.  This is the first stop in evaluating the results. Call this row "Total Gauge R&R" (or similar) In the Summary and Gauge R&R Statistics table, call the % Gauge R&R row something like "% Study Variation" or similar to support the RR/TV calculation. Perhaps move this row to the AIAG Gauge R&R Results table also.  Since it's in the same area as the spec limits/tolerance (and the precision/tolerance ratio), it is easy to assume this is the % Tolerance value for new users   Why is this idea important?  This would help people that are new to Gage R&R analysis understand the different quantities and what they represent.   ... View more

What inspired this wish list request?  The measurement stdev is used in other calculations (such as tolerance analysis, as a bound for equivalence testing, etc.) and it would be easier for new users to understand the values in the Gage R&R analysis if the stdev column is visible by default.  Otherwise they have to either back-calculate from the 6*Stdev value, or turn on the column by right-clicking and choosing the Std Dev column (and then going to File/Preferences to save it as a default setting...this isn't saved under Red Triangle/Platform Preferences).  The Stdev column is on by default in the EMP Gauge R&R Results table already (in JMP18).   What is the improvement you would like to see?  In the AIAG Gauge R&R Results table, include the Std Dev column as a default output column.   Why is this idea important?   The measurement stdev is used in other calculations (such as tolerance analysis, as a bound for equivalence testing, etc.) and it would be easier for new users to understand the values in the Gage R&R analysis if the stdev column is visible by default.     ... View more

What inspired this wish list request?    For shelf-life estimation, Stability Analysis in the Degradation Platform commonly uses the different intercepts different slopes (DIDS) fixed-batch effects model to reflect inequality among batch slopes.    Therefore, it is important to improve the default method for estimating shelf life based on the DIDS model so that it is optimal.    Currently, the JMP Stability Analysis provides an inferior method (Individual MSE) as the default and a superior method (Pooled MSE) as an option.  The two methods differ only in the variability estimate (i.e., mean square error (MSE)) utilized.  In forming the confidence band about each batch, the default method forms the MSE using data variability from only an individual batch while the optional method constructs the MSE using data variability pooled across all batches.  Table 1 shows the comparative inferiority of the default Individual MSE method and the superiority of the optional Pooled MSE method.  The default method does not follow the current ICH stability guidance (see also Table 2), but clings to using methodology in an outdated stability program based regulatory guidance withdrawn by FDA.  Since it does not take advantage of a standard assumption of equal variance for the DIDS analysis of covariance (ANCOVA) fixed effects model, the default method forms relatively shorter estimates of shelf life (see also Figure 1).  Because JMP is designed with scientists and engineers in mind, many users are likely to depend on the default procedure to serve them best.  However, in this situation, the default Individual MSE method relatively speaking hinders users from achieving the goal of establishing their desired shelf life.  Finally, the default Individual MSE method for the DIDS model represents a disconnect with the overall excellent standard of JMP tools and in this instance, a lag behind their competitors who have based their stability analysis methodology on ICH Q1E and good statistical practice.                     What is the improvement you would like to see?      Only when descriptive data summaries / graphs suggest that the data have unequal variability about the individual batch regression lines, should the Individual MSE method be used.  In that case, the method could be easily specified in JMP by using batch as a By Variable on the Stability Tab.       Why is this idea important?    Summary of Importance:    Increased access to and ease of usage of improved statistical methodology to better meet the needs of users.   In the development of a pharmaceutical product, stability studies are time consuming, resource intensive, and very costly.  Establishment of the desired shelf life is a critical milestone - even a “Go, No-Go” decision.  Often the stability data analysis must be done in a compressed timeframe.  It’s imperative to do the best data analysis that conforms to regulatory guidelines, quickly and easily, to maximize the opportunity to establish the desired shelf life.  For the estimation of shelf life for the DIDS fixed-effects model, improving the default method to the Pooled MSE method will meet the needs and expectations of users and better position JMP compared to its competitors. ' Additional References 2024 JMP® 18 Reliability and Survival Methods. Cary, NC: JMP Statistical Discovery LLC 2025 JMP® Online Help.  JMP Statistical Discovery LLC, Cary, NC ICH Q1E Evaluation of Stability Data (June 2004)   ... View more

What inspired this wish list request?    Having to scroll through long code to find a specific line of code that generated an error when reformatting the code or when running the code.   What is the improvement you would like to see?    JSL Script Editor added functionality: When writing JSL code, it would be great to have a functionality where you can right click within the editor window and have the option to "go to line" and enter a line number. This would be helpful when debugging, or when "reformatting" the script and an error is thrown that says you're missing a ";" or ",", or something. This is particularly helpful when working with code that is many hundreds to thousands of lines long -- it beats scrolling and scrolling through code. I appreciate the the right-click > Advanced option for collapsing or expanding Expressions and Functions.   Why is this idea important?    Saves time and improves the functionality of the JSL Editor.   ... View more

What inspired this wish list request? Current issue: In the current implementation of JMP’s Fit Curve and Nonlinear platforms, the confidence intervals (CIs) for parameter estimates are fixed at a 95% confidence level. This limitation restricts users from aligning their statistical outputs with regulatory or methodological requirements that call for different confidence levels, such as 90%.   Example use case: In the paper “Parallelism in Practice: Approaches to Parallelism in Bioassays” (Fleetwood et al., 2015), an equivalence test is used to assess parallelism by comparing the confidence interval of the slope difference to a pre-specified equivalence interval. The authors explicitly use a 90% confidence interval for this purpose. Since JMP only provides 95% CIs by default, users cannot directly replicate or validate this approach within JMP, limiting its utility for equivalence-based parallelism testing. The approach is also detailed HERE. What is the improvement you would like to see? Proposed enhancement: Add in option to adjust the alpha level within the platforms.    Why is this idea important? Value to users: Regulatory alignment: Many bioassay and equivalence testing guidelines (e.g., USP <1034>) recommend or require 90% CIs.     ... View more

What inspired this wish list request? In the webinar "Pinpointing Problem Sources in Complex Manufacturing Processes", the platform "Process History Explorer" was showcased for several examples. A common task was to add the local data filter, or make a report table into a table and generate typical graphs. It seems it would be useful to automate some of these items are make them available with a hotspot menu, etc. Any graph that users would most likely generate would be useful to already have the menu be able to generate them.   Pinpointing Problem Sources in Complex Manufacturing Processes   What is the improvement you would like to see?  1. When launching the Process History Explorer menu options such as "Levels with Lowest Yield", "Level and Time Filter with Lowest Yield", and "Waiting Time Analysis", does it make sense to have a Local Data Filter already populated with those column selections? Further enhancement might be to add the Local Data Filter columns in the order of impact on "yield", "waiting time", etc. 2. When needing to right-click over a table in a report to make a new table to generate graphs, could this be automated and let it automatically make into a table? And would it be possible to show the most likely graphs generated, as either scripts or a hotspot drop down menu? 3. Or instead of making the new table, let the report table have a hotspot menu that would generate typical graphs of the analysis. This might be similar concept to Process Screening, where if you select rows in the table, you can right-click and "Show charts for selected", etc. Basically making the report table more interactive.   See webinar for examples of type of typical analysis. Pinpointing Problem Sources in Complex Manufacturing Processes     Why is this idea important? To make using the Process History Explorer easier to use and automate typical analysis performed on this type of data. Since it is looking for signals in the process, make it easier for user to visualize and drill-down.     ... View more

☐ cool new feature ☐ could help many users! ☑ removes something that can act as a „bug“ ☐ nice to have ☐ nobody needs it   What inspired this wish list request?  see: Disable "Update Table" script?  After an Excel import, JMP automatically adds a "Update Table" script. This script can be used to update the JMP data with new data from the input data.   Unfortunately, with the update, many properties of the JMP data are lost.   What is the improvement you would like to see?  a) Add an option in the preferences which disables the generation of the update script b) provide an "Update Script" which Updates the data table: universal "update" button for imported data. Join, Concat and Update  - add new data - keep current formatting and properties   Why is this idea important?  users can delete all their formatting, table properties, column properties ... buy an innocent click on      Update Table     ... View more

What inspired this wish list request? (The Problem) Finding a specific tag in a project with many tags is a major bottleneck. Users have to manually hunt through complex folder trees to find what they need because there is no search function. Use Case: Imagine you need to find a tag related to "Outlier Analysis." You have to waste time clicking through dozens of folders until you find it. This process is slow, frustrating, and discourages the use of tags for large-scale organization.     What is the improvement you would like to see? (The Solution) Transform the tag system into a fast and intelligent tool with two key improvements: A Powerful Search Bar: Instantly find any tag by searching its name or its description. No more manual hunting. Tag Templates from Data Tables: Allow users to load a standardized list of tags directly from a JMP data table. A team could maintain a master tag list in a simple data table (with columns for Tag Name, Description, Group, etc.) and load it into any project. This makes creating and sharing tag sets incredibly simple and scriptable.   Why is this idea important? (The Impact) This is a game-changing improvement that makes the entire tagging feature more valuable. Saves Massive Amounts of Time: Instantly find what you need instead of searching manually. Boosts Productivity: Turns tagging from a chore into a powerful workflow tool. Enables Large Projects: Unlocks the full potential of tags for complex, real-world projects where they are needed most. Ensures Perfect Consistency: Using data tables as templates makes teamwork seamless and allows for scriptable, version-controlled organization. In short, this is an essential upgrade that makes JMP's tagging system truly powerful and user-friendly.   ... View more

What inspired this wish list request?  The motivation for this request comes from the requirement from regulatory agencies like FDA to obtain confidence intervals using the Clopper-Pearson (C-P) "exact" method or other methods like the Score (Wilson) Method with continuity correction that could properly handle small sample sizes. For example, it is common to calculate CI for subgroups in a study, some with small sample sizes where using such calculation methods become particularly important. That said, the C-P method is considered (too) conservative so it would make sense to apply less conservative yet acceptable calculation methods like the Score method with continuity correction or other similar methods. The request for having CI by C-P echos similar requests already on the wish list. Clopper Pearson Confidence Interval for One Proportion as an Option in Distribution Platform Confidence Intervals for SMALL sample sizes using Clopper Pearson Beta Quantile Confidence interval for proportions in Contingency Analysis   What is the improvement you would like to see?  I wish this platform would have suggest several options for CI calculations to choose from or maybe apply several methods and show all results in a table.   Why is this idea important?  Currently, the Distribution platform offers only the Score method with no continuity correction, which is less acceptable in some areas. This leaves no other choice but making manual calculations when wanting to have CI using other methods. The distribution analysis serves a basic step for many other analyses, which makes these additions even more important.         ... View more

What inspired this wish list request?      What is the improvement you would like to see?      Why is this idea important?      ... View more

What inspired this wish list request? JMP 18 and 19EA were crashing when attempting to connect ODBC to Snowflake (see case number below). Very little in any logs / tracing explained the error. It turns out my snowflake driver was older. 1) I didn't know there were new drivers availeable and 2) I didn't know that JMP wouldn't work with the older driver.   What is the improvement you would like to see? I would like a cleaner error -- not a fatal crash -- and some form of messaging to indicate to the user of the issue or possible fixes.   Why is this idea important? Any solvable error that results in a fatal crash of JMP is important to fix :)   Ideally, the fix would be clean enough to recognize driver versions and note which is the minmum to use. I realize that may be tough given the plethora of drivers / versions out there. So the miniumum wish would be a non-fatal crash of something going wrong and a suggested check of driver version updates.     ... View more

The idea of "synchronizing summary statistics" came up in the discussions of Col N Categories (:green_heart: ) .  With the introduction of Col N Unique() in JMP19, the original wish got the status "Yes, Stay Tuned". -> hard to track the additional ideas. So, I decided to submit the idea of "synchronize summary statistics" as a separate wish. The disadvantage: counting starts again @ 0 Kudos : (   ☑ cool new feature ☑ could help many users! ☐ removes a „bug“ ☐ nice to have ☐ nobody needs it   #myTop10_2025     What inspired this wish list request?  via Distribution and Header Statistics, users have access to many statistical calculations which are not available via Tables/summary and Tabulate ?!   What is the improvement you would like to see?  please synchronize the different platforms: - Tables-Summary - Tabulate - Header Statistics - new column formula right click menu - JSL aggregation function  - Summary Statistics in Graph Builder every aggregation function which is available via Header Statistics could/should be available via the other "platforms" as well.   Why is this idea important?  Many users use Tables/summary and Tabulate  -  they should provide all the necessary calculations! more wishes submitted by     Available now via Tables/summary: Available now via Tabulate: Maybe available with a next version of JMP :backhand_index_pointing_down: ?  ... View more