Hey, everybody. Thank you for joining my poster session to learn more about one of my favorite topics. I'm Shannon Conners, Director of JMP Development Operations. Today I'd like to tell you about how you can generate and share data to help us improve JMP.

But first, just a very few brief words about my DevOps group. We're involved in planning, infrastructure testing, and all those production tasks that support JMP feature development, bug fixes, and security releases. We support all the in various release cycles.

But enough about me. Let's talk about you for a while. If you're watching this recorded video online, then you're most likely a frequent JMP user like me. If so, then you may have noticed that sometimes JMP will prompt you to send some information back to us. There's two main times when this may happen. Number one is if you have the misfortune to encounter a JMP access violation or software crash. Two, if you install JMP, it will prompt you to send us anonymous usage statistics. We commonly call this telemetry. We ask you to opt in to sending this information because we respect your privacy. You can set your privacy settings in your JMP preferences unless, of course, your organization has already set them up for you.

First, we'll talk about crashes. JMP customers, they're very creative. We all know you have access to lots of different data sources, many different industries, so it's possible you can encounter a JMP crash we've never seen before in testing. We built crash detection features into JMP, and they'll notice when the software stops working on you. Then the next time when you restart, JMP will prompt you to send details to us.

Over the years, we built up an internal system that receives, stores, and matches up these incoming crashes to known problems. This system will help us quickly identify when a crash is novel and needs a lot further investigation, or if we already know about it and may be able to give a customer guidance on when to expect a fix or if one is already available. In addition storing customer crashes, the system also handles reports for internally discovered crashes that are found by SCs or tech support or testers or anyone else that works for us.

Let's talk a little bit about how this works. You may see this dialog with a red X indicating JMP is going to shut down. I know we all hate to see this dialog, but you will see it. When you click Okay, then JMP is going to restart. Then you will see this JMP quit unexpectedly, and it's got a blank section for adding text. You'll notice that Send Reports Anonymously is checked, and Check for Recent Problems is also checked in this window when it comes up.

First of all, please don't click Cancel here. If you do, we won't ever even know that you crashed. I realized you might look at this window and feel nervous about what JMP is sending back to us, but please rest assured, JMP is not sending your open table scripts or other details like that. JMP is just sending whatever comments you enter in the blank section of the window, basic install and checker information about your system on Windows, so like OS or a list of installed drivers or software: things that we can use and help troubleshooting issues.

Finally, JMP is sending these crash files that detail the code path that was active when the software stopped working. Like other crash files that operating systems or software products will generate, these files are really not human-readable, and they're really only useful to development when debugging your particular issue.

If you simply accept the defaults that you see in this window, and you click Send Report to JMP to submit your crash anonymously, JMP will upload your files to our waiting server. Submitting anonymously will add your crash to our database, but please understand it's often not possible to completely diagnose and replicate your issue from crash files alone. Replicating your problem with interactive actions or a JSL script is really the gold standard, both when debugging a crash as a developer or verifying any fix we make to address it as a tester.

I really encourage you to uncheck the Anonymous box and provide your e-mail address. That will allow you to open up a new tech support case, and you can work through your problem with them. Working directly with our tech support team until they can replicate your issue will really maximize the chances of understanding and resolving that problem in a future version.

Now, if you don't know what you did, or you didn't really have time to work through a case with someone, you can always submit anonymously. But if you do, please just try to include some text in the box with whatever details you can remember about what you were doing when JMP crashed. If we can replicate your crash, whether it's reported to tech support with your e-mail or anonymously, then we always create a new bug report that tracks the issue. If we can't replicate it, then the crash just will remain in our system until some new information comes in to help us get to a test case.

I wanted to talk a little bit about the crash window where previously I asked you to share details about what you were doing when JMP stopped working. The first screenshot is the default view of this crash dialog. There's no e-mail address, like I mentioned, no customer details provided. I labeled this least useful because while this does add your crash to our database, this anonymous crash submitted with no information has really literally the smallest chance of being replicated and resolved in a future version.

In the second window, a customer submitted anonymously, but you can see they did include a very helpful comment about an action they took before the crash, and that actually provided enough information where we could get around to replicating it. But because they didn't provide an e-mail, we could not get back to them with information about the resolution that, yeah, we were able to rep your crash. Now we have a bug report and hope to fix it in the future.

The third window is an example where someone submitted anonymously, but they pretty much gave enough information where we could enter an investigation report for a developer, and he was able to create a JMP script to replicate that problem and create a fix right away.

The final window is an example. Someone provided an e-mail address and a script. That's super useful because then we can run that script in multiple versions and be able to tell when it started happening, when it stopped happening. I realize not everyone has time to create a script to replicate your problem, but if you happen to have one that you can share, that will often help us get to a case much more quickly, which is very, very helpful.

I wanted to say a few very brief words about how we receive and work with your files. The basic idea is crash files get downloaded from the server. We add symbols back into the files, which is just a technical term for processing the crash stack. We load that information into a database, and then we do that comparison to say, "This new crash doesn't match up with anything we've ever seen before." We surface the information in tech support cases when it's something a customer submitted with an e-mail or in the JMP Crash web page, which is an internal web page we have for investigating anonymous and named crashes.

Telemetry has a very similar pipeline. Here, since there's no customer to work with because all telemetry is submitted anonymously, we can summarize the data. We get it into a database, we summarize it, we publish it to JMP Live. Developers who really want to dig deeper into the data and really understand platform usage or feature usage can download the data directly and browse it with this telemetry add-in that was created by developer Evan McCorkle.

Interestingly, we find about 10 % of customers who authorize 18 are opting into sharing their telemetry. Though telemetry is not completely comprehensive for all JMP usage, we are getting a really good sampling of what customers are trying to do with the software, which is extremely helpful information as we go forward into future versions of JMP.

In summary, just wanted to point out that you really can help shed light on issues that go wrong with JMP, whether this is a crashy report or a bug that you e-mail directly into support@jmp.com. We really appreciate the details that you provide about what you were doing when you encountered a problem with JMP. We really do look at this information and technical support works to replicate those problems. If it's a beta version of the software, our testers work to replicate those issues, and we do want to solve them.

You can also now, in JMP 18, contribute to sharing telemetry information that really helps us understand usage patterns and understand how people move through the software and their workflows. That is extremely helpful, and we hope that you participate. Finally, I just wanted to impress upon everybody that internal people at JMP really do use the software to help improve JMP software.

We're like you. We use JMP, we use JSL, we interact with databases, we clean up our data, we process it, we write scripts, and we have ways to create interactive graphics and publish results to JMP Live. That's one of the things that I really love about both the crash pipeline and the telemetry pipeline in the sense that we're really using JMP to improve JMP. I just think that's awesome.

Thank you very much for listening to my talk. If you're at Discovery, please do stop at my poster session because I'd love to talk to you in person. Thank you very much.