Please, Horse, Drink: A Desperate Bid to Make Engineers Use Their Data (2026-US-30MP-2961)

Hi, I'm Spencer Saunders, and this is my JMP Discovery 2026 presentation. Please, Horse, Drink: A Desperate Bid to Make Engineers Use Their Data. How did it start? We're not sure when the problem started, exactly. Have you looked at the data? We think maybe the inclination sensor could catch this. Okay, have you looked at the data? I checked last week's trend. I didn't see any change. Maybe it was the previous week. Have you looked at the data? If this is a familiar refrain to you, hopefully this is an interesting talk.

Engineers at my company weren't pulling data quickly or visualizing it effectively, at least some subset of the time. It's not like the whole org, but there were teams that maybe were new or otherwise, or had greater friction, or just had a lot of technical debt, and this was a refrain I had in meeting and meeting and meeting. Assumptions were being made, not really based on data. In the worst cases, it was an impediment to having an effective meeting. You want to have an idea, in the meeting look at the data, move forward, and leave that with real actions based on data and not on assumptions.

What did I do about it? I built a JMP script. No, this talk is more about the adoption of a tool and the support of it, not necessarily a particularly clever, not a particularly complicated, dedicated tool. It's the power of this JMP script that really importantly, as I learned, having a polished UI that caused it to be adopted to solve an organizational problem. It's about the tension between that adoption of the tool and the more people to use it, the more that you, as a scriptwriter, and I'm sure many people have been there, you end up supporting that tool, and it becomes a second job, IT help desk for everything you've made.

Last, this talk is about my personal journey growing in my JMP script usage, and it's a retrospective. There are a lot of hindsights and tips I'm giving, but it's not prescriptive. It's not a "Hey, if you're going to go do this, follow the steps I took," because certainly, second time around, I can do it better, and hopefully, you can as your first time after this.

How did we get here? How did I get here? I'm a career process engineer. I started out doing product and process dev at a couple of different organizations. My first major career role was at ON Semiconductor, as, again, a process engineer. Then now I'm at Tesla Motors, working at Gigafactory Nevada for the last 9 years now. At this point, I'm a staff process engineer. I'm over the whole Model 3/Y battery business unit as a technical lead.

As it relates to our journey here, when I started in semiconductors at that job, my use of pulling data into JMP was really a bunch of rigid web reports. It was enter timestamps, enter maybe an equipment name, get a CSV file, do that four or five times, throw them in Excel, get a VLOOKUP, now I have joined data, and then finally, I'm looking at it in JMP. I've been using JMP for 15 years now, and that was the start of learning to explore data, analyze data, become more efficient in JMP.

When I started at Giga, at the factory, it was a very different environment. There's a lot of flexibility in how you set things up. It's very much engineer-led. There's not an ivory tower, IT group setting up things, so there were a lot of databases that had no front end, none of that web reporting. It was you have to go query the database, and you got to query a couple of them, so you need to be able to do SQL, that scripting language that lets you query a database. That's great. You can customize exactly the data you need, the shape of the data, and then finally, it's in JMP.

When I started, it was you learn SQL or you just don't own the problems you're working on, because you can't get to your data. That worked. At the time, the engineering core was highly experienced. It was nobody's first job. Even though I didn't know SQL, many people didn't know SQL; there was a high density of that mentorship to onboard you, along with tutorials and all that.

Times have changed a little bit. Gigafactory 1 is now one of many. It's Gigafactory Nevada. As the organization has grown, there are more factories. People move on. Some of our part of our organization is much newer. It's recent college grad to 2 years of experience. Briefly, just to give you context, let's talk about what does querying data look like? What is the friction there? You've got a diagram of a production process at this factory. High level, you have a process name, you have production flows that a part goes through, and then all the steps it visits, tasks it completes, and those tasks have parameters and specifications. This is the data environment that a lot of factories have.

The friction on top of learning that SQL for these engineers is, "I want to go find my leak test data or something." I got to know the names. I got to go check the UI or do other database queries for what is the step's name? What is the task's name? Is it an underscore? Is it a hyphen? Is there no hyphen? Did somebody misspell or leave a space sometimes? Same for parameter names. You run that query, and then you wait, because some of these reporting databases where the organizational technical debt comes in, some of them are a lot slower than they were 9 years ago.

Back to our story. The straw that broke the camel or horse's back was yet another meeting. It was a corrective action meeting, and it was an issue that we had already had 2 months ago. In that meeting earlier, that question came up of: "Maybe I can find it with this inclination sensor." Repeat issue? Turns out in the 2 months, nobody had looked at that data. I was furious. I left this meeting just like, "I'm going to build." I've been thinking about these things. "I'm going to build a script. It's going to make it… they have to look at the data. I'm going to make them look at the data. You're not going to have to look anything up. You're not going to need to know SQL. It'll have little canned scripts that pop up the trend for you."

In the back of my mind, it was also about JMP adoption, because I still see people who had JMP licenses that were paying for using Excel or like Minitab. It was about that and keeping the engineer in JMP. Maybe I can make a full-featured start in JMP, get the data in JMP, explore the data in JMP. Script or utility. The win condition really was engineers in a meeting can say, "Hey, let's look at that data," pull it and show it within a couple of minutes. That all sounded great. I calmed down a little bit. This is where the doubts came in. It's like, well, SQL and database navigation are Tesla skills.

The complex and agile environment we have with, here's product data, here's test data over here, here's a cool idea some guy set up this vision system, and there's a new database for that. You can only really tame and own that by learning SQL, by learning how to query databases. It's like, am I going to hold their hands too much? Am I going to defer people learning this skill that I think is important?

The thought was, well, no. What is their core job? Their core job as process, equipment, test, quality engineers is not SQL. It's getting data, exploring data, and it's learning their process, learning their equipment through those relationships of various sets of data, building a mental model of what's going on. I reassessed, thinking back to my start with this thing in JMP at ON Semiconductor. Again, it's like I didn't have to know SQL. I got data handed to me in a janky web report, but nonetheless, it was given. Probably I should drop the SQL thing.

The last hesitation, which comes into a lot of what I did on this project, was previous helpful scripts maybe I'd made for myself. Then, "Oh, do you want this? Yeah, sure. Here you go," or even purpose-built for a couple of people's problem had limited adoption, which, if that's the scope of the script, is fine, but worse, frequent support. I spend a couple of hours writing a script, and then over the course of weeks or months, 2 years later, somebody's like, "Hey, you wrote this. Can you help me get it working?" That was the real workload that caused the hesitation here of big idea, but am I just going to become IT help desk?

We can see what failed before: heroic README comments of a huge paragraph, often a train of thought of, "I didn't make this for you; I made it for me, but if you really want it, here's how you can do stuff." I had been forced once to… I had a workflow with a bunch of scripts on transforming data for validations we were doing, and then suddenly my paternity leave came much earlier than expected, and so I tried to throw those all into a JMP journal with, again, instructions. It turned out when I came back, it took three engineers arguing over some parts that were broken to get it working, or if the user has to modify the script, go into the JMP script and change a variable name for their computer setup.

Again, you have friction that's causing adoption to lag, or what is not distributed properly, which I think in a lot of companies is difficult, because it's usually just, "Hey, I have this file. Here you go." You have this telephone line effect. If somebody modified the script, they gave it to another person who modified it, gave it to a third person, and now it was super broken. When it comes to me, I have to disentangle what these other people have done to this low-effort script I built.

What convinced me? What changed my mind? As we talked about, the benefits outweighed that drawback of support. Really, core of my job in my current role is to support engineers and create solutions for them on top of the other things that come with being part of a factory. I thought I might be able to mitigate some of those needs for support going through previous failures. Another thing was I've been putting off learning display boxes in JSL. Most of my scripts are just a script you run, and it does something. It's like, boy, it'd be nice if I had a little pop-up that had configurations, but it seems complicated.

There were other side projects that simply needed those UIs that I was never going to get around to building. JMP Discovery last year was great. I met a lot of people who were doing a lot of stuff in JSL. I got to talk to a part of JMP's dev team for JSL. They gave me helpful tips. Then, what was huge is internally, we had a new data warehouse, Edena, which is a fake name, but it's similar. It took these slow and aging MySQL databases, and it put it into a very fast-to-query ClickHouse database. This is not a talk about databases, so we won't go into that.

The point was suddenly data that took walk away, come back 15 minutes later, and finally your data is fetched, that was less than a minute. You can have 100,000 rows in a second or two. I saw this opportunity for… I had learned about this. It turns out it had been around for months, and nobody had told me. Co-promotion of my utility with this new data warehouse, where it's like, hey, this is way faster, even if you know SQL, my thing.

By the way, it's powered by this database that you all should be using independently. Sat down, talked through requirements. What is the minimum thing I need to build this script? I knew I didn't want to futz around with database connections. Everybody's using Windows, often for other things. The database connection has been set up in Windows through a thing called ODBC, which we're not really going to talk about. I wanted it to guide the user through the data. I didn't want them to look up parameter names. I wanted that hierarchy of process, flow, step, task, and parameter, at least for this execution system data, to be guided with a UI.

I wanted it to have a one-click, let's look at the data, so that people aren't in a meeting looking at a data table and then having to go in a Graph Builder and make something. For the JMP adoption, it just helps show, hey, you could be making these things, too. Options were going to be limited, though. The database has 60 fields, so we should be able to select which ones we want, and at that top-level process scope, there are a lot of those across the company, so you should be able to set just the 10 you care about.

Much as what I'm calling an opinionated default, it's what I think you should be doing, and we can expand on it later. Then something retrospectively I found is a lot of extra polish came from reading the Scripting Index and finding something. It's built on a lot of list boxes. I noticed, oh, there's a Set Tips message, which is hover text. Suddenly, step names, which are displayed as a bunch of numbers, you can hover over and see the name of that. Even if you're unfamiliar with most of what you're looking at in the database, the UI guides you, but a tip I have is don't have too many preconceptions.

I wanted these lists, which we'll see, I wanted them to have a little search box on top. I've seen that in JMP dialogs, but it turns out that only works for column list boxes and not normal list boxes. Don't too rigidly have preconceptions of the exact graphical user interface you want to build.

I sat down, and I built a Version 1, and I spent a lot of time playing with display boxes and lining stuff up. There are a lot of things you just have to practice in this giant nest of scripted boxes that form a UI, but this is what I came up with for V1. Honestly, the UI didn't change much for V2 that we'll see. It was really just a lot of other things.

We have our main box. It's execution data. It's the factory product data. Select a time range. There's little canned today, 7 days buttons. You have really basic options. Again, you can edit these high-level processes, and you can modify the queried fields in the database that you want. There's info, which is placeholder for this. This is all anonymized. None of this is real factory data or names, so you click on the processes, you click on the flow you want. These are maybe the three or four operation steps you want to select data for.

Here are the tasks that happen during those. You select the parameter, which is actually the data associated with the product we want, and you click the Go Get The Data button, and you get a table. A lot of work went into this, a lot of hard learning and getting through what worked to line up display boxes and get these panel boxes with spacer boxes correctly that this talk isn't really about, and it'd be hard to teach that. I think it's a lot of trial and error, but I've got tips. There were no great things about this. V1 was still this super long JMP script file. I put off learning add-ins, and I didn't want to have a folder people copied. I just wanted it to be a script.

There are a lot of janky things. Here's a PowerShell script that's hardcoded into this; then it runs to find database connections. Here's another huge text of this is my preferences file that it makes as a text file on the person's computer, and then when they save preferences, it saves to that text file. V1, again, is a generous name, because it turns out there was more bad and ugly than good when I did beta testing.

The good was great. The UI people really liked. They were like, "Oh, cool." Even long-time JMP users were impressed, which is nice. The data was incredibly fast to pull, again, powered by Edena, which wasn't my magic, but certainly pounced on it. A lot of bad, though. On other people's machines, that window Open Database Connection utility, a lot of errors. Big one was 64-bit JMP doesn't want to talk to 32-bit connections, so we need to fix that.

Install instructions were still just click the run script button. When people would move the file, they'd have it in their downloads, they'd run it, the user prefs were made in the downloads, and then they move it to their JMP folder, and they lost that preferences, because the script just was looking in the same directory. The database column names that were being pulled, they're good in the database, but they're horrendous to look at. They're terrible to look at in graphs. The ugly was one or two users out of 10 people I gave it to, they got an error, they didn't ask for help, and then they never tried it again, which is the antithesis of what we want for adoption.

Even uglier was this way I shot myself in the foot was I had an idea it was going to be part of a larger utility. There are other data sources that should have the same GUI, as well as there might be other utilities. I'm like, I'll be cute. Classic Spencer. The window was named SJP Execution Data Viewer. The cute thing is its Spencer's JMP Program as SJP, which JMP is John's Macintosh Program. I thought I was being cute.

Having to explain a joke makes it funnier, right? Having to explain a joke every single time someone asks, and everybody asked, makes it even funnier. Very quickly, this got removed from the front end. It's still inside the script, inside as a joke as my namespace, but that's where it belongs. It's hidden from everybody else. Let's stop and assess. I hadn't fully committed. There were a lot of options or things that were probably more than nice to have that were missing, simply because after building that one UI, I had hesitation to do more display box work, but practice makes perfect.

I had avoided making a JMP add-in, which we'll talk about. Instead, it was this giant JSL, and we had new additional requirements. We needed a cleaner install. We needed some file organization. Sounds like an add-in so that all those preferences aren't hardcoded in the script. The database connection automation needed maturity. I wanted to add another data source, because part of the good was, "Oh, wow, this is great for the execution system. Can you hook this up to the test database? Can you hook this up to XYZ?" Knowing that I was already doing V2, I wanted to future-proof it or at least rewrite a lot of the original code.

Add-ins. Can't really defend this, but in my head, I knew that the one thing about add-ins is you had this path variable for where the files for the add-in that needs to be in your script instead of just referencing the relative folders. Knowing that, again, it's not defensible; it's just a weird thing I did, I put off add-ins. I'm like, "Oh, that's going to be complex." It's weird, because it's the opposite of how I function normally. It's very much like clicking on buttons, right-click, see what options exist, try this, try that. It's how I learn a lot of things.

This was very contradictory. Of course, the silly thing is, add-ins are super simple. Add-ins are like no work at all. The Add-In Builder, you name it, and then the key part is just adding to the menu in the little add-ins bar, your script, say, run the script file, and that's it. It's basically just a zip file of files renamed JMP add-in, and you add those on the last tab. Now Application Builder is my new superstitious avoidance. I'm not touching that. I suspect that's incredibly complicated. It probably isn't.

Version 2. Let's add another data source. Oh, no. Looking at the code, here is how this box is built. I have five panel boxes. It's a cascade. You're selectively filtering into a smaller and smaller part of the factory until you get to the data that you want. This was built as this horrible nested thing of the first list box, when you click on something, deletes all the other boxes, re-adds them, with this box having the new list in it. Then this one does the same thing, and this one does the same thing. You see, these panel boxes and list boxes are nested. In fact, trying to use this again was terrible.

I spent a lot of time refactoring this to where this is now what you update to build a new UI. You have in the background this function that handles all of your list boxes, but on the UI building, you just name them 1, 2, 3, 4, ad infinitum, give it a title, and then this function handles it. It's a giant array of panel boxes with list boxes that then they understand that the one previous to it in the array has a relationship, and the on-change script is handled.

One thing I should note is all of these in this execution data are database queries. They're in that MySQL database, so that we get all of the live flow steps, all of the live tasks. Then it's that final pull that's in that data warehouse that's a columnar database, which is harder to do this query, just specific steps and specific tasks to get their names.

Here's another tip that I have. This was huge when I found this out. Some of this was at last Discovery conference when I was like, "Hey, is this a thing?" It's like, "Oh, yeah, you can do it everywhere." Here's a common example. I've made a window, and then I have a data table box or some other display box, and I want to modify all of its properties. I'd end up with, after my huge window, this is a small one, I'd have a whole bunch of messages that I would send to that to make it scrollable, change the width, change the height. The documentation doesn't disabuse you of this notion. This is normally how we do things in JSL.

It turns out after you're done with the parameters that are required for calling a display object, you can just comma-separate all of those messages, and it just works. Now those are where they're relevant within my huge tree of the window. It keeps the end of the script from being 50 lines of these messages. This was huge just for ability to read what I had written a month later and just keep track of what I was doing to the display boxes.

Version 2, we upgraded the return fields option, which we'll see in the demo. I added an About window, which was important, because it turns out I couldn't actually make everything work automatically. I needed some documentation. It links to the GitHub where the latest version of this script is stored. Now that I had an add-in, I had a file structure. I have my data sources, which are each of those UIs for each database or table within database; there's some documentation, there are the templates of my default preferences file, the template for new data sources that I can copy and modify.

Then doing development while it's built as an add-in is sometimes annoying, because I make a copy for the user's preferences of the default template, and I make a copy of this, and resetting it to the blank state to then package it as an add-in for V3, you have to figure out what to add or delete. I made this user folder that then doesn't exist in the package. At runtime, when a new preference or whatever is created, it just goes into that folder. When I want to package this again as an add-in, I just delete it, and then I have all of my other files.

Another thing, I needed to upgrade and add a window so you could see: are the database connections that I'm trying to find automatically working? That became a separate script. It eventually became its own add-in, and it uses the built-in Python with JMP these days instead of PowerShell. It error handles. It checks connections. Like I said, it descopes installing drivers for people. They should be able to Google that, or my GitHub documentation has that.

I had this window. As I had learned and become pickier about, I had a lot of… I'm like, "I could fix this. This text should be across the top." I really hated these pipes, these keyboard characters as my little separators between, here's the database, here are the ones we'll accept, and here's what happened. It sounded like a border box. We're going to go on a tangent, by the way.

Go to the border box in the Scripting Index, and it's got the sides parameter, and all the examples just have sides 15. It's like, what is that? From experience, I knew that that number changed. Is it left, top, bottom, right? Is it all of them that have a border? Jmp-to-jsl.com has a lot more stuff than any of these, so I'm like, "Okay, surely it'll have sides." Oh, great, it does have sides. This is helpful. It maps two settings.

Of course, I just start incrementing the number, 0 through 15, or the sides of the border box are on and off in different combinations; 16, nothing; 17, it's blue now. That's interesting, 32, nothing again; 33, oh, now the background is white, and we're back to black borders. Of course, these seemed like binary digits. Your 16s place, your 32s place. Got really deep in the weeds, and I built another UI. I built a script with a UI that allowed me to toggle each of the bits in the integer on or off, and I just spent a couple of hours playing detective of: does this bit change the border box? At the bottom, live updates.

Some people, probably a lot of people, maybe my boss, would say this is a waste of time. I call this a win, because I just made this GUI in an hour. Instead of that fear of, "Hey, display boxes, how do they work?" This just came out pretty freely. I'd made it through that barrier of, "How do I set up a display, a window in JMP?" Here you go. Here are, it turns out, everything I found for sides in border boxes. There are five sets of options. There's the black, the blue, there's a light gray, there's a dark gray, and there's a dark gray with shadows, and you can do black and white, and you can do bold of that border. I wrote a wrapper script so that I could use this in all of my GUIs.

Here's my refined graphical interface for ODBC helper with sides 258 of these nice, light gray divider lines that are the left side of a spacer box. Let's look at the UI. I have my add-ins. Again, these are all sanitized. There's no real data here or real connections for JMP Discovery. Here's our Data Viewer. Here's our new return fields list. You can turn on or off what database fields you want, and most importantly, you can rename them so that they're human-readable, and there's a very janky way to reorder them as they come into the table by changing these numbers. I haven't really figured out a drag-and-drop in JMP script in display boxes, but we've got that.

Yeah, we go. We select. Maybe we want to look at our pack assembly. Excuse me, we want to look at our main production flow. Maybe we want to look at leak test and fastening and how they relate. We can hover, and we can say 17 is a fastening step, 19,000 is my leak test; I want both of those. Just give me a Control+A, both of those tasks, and then give me the torque, and give me the leak rate, and go get the data. It's pretty fast. Of course, this is a canned file I already had, but again, it's just a couple of seconds normally if you have good internet at the factory.

We have all of our data here. Again, I didn't want to leave a user here. I have these canned scripts. The top one is really what I want them to be looking at immediately in the meeting, where it's, "Here's our time series data for our leak rate and for our torque." We can see it's by the equipment name. We can see, wow, Leak Tester 2 suddenly sucks, and Torque Gun 1 and Torque Gun 2 are pretty well-matched, but Torque Gun 2 seems to be hitting torque a little more precisely. You've got filters in this. It's all very JMP stuff that any experienced user knows. Again, I wanted to lead the engineer to this, to the water, and hopefully encourage them to drink deeper and learn JMP.

Another thing that was very useful was you can very quickly split the numeric parameters. Now I can see by serial I have each parameter in a column if I want to do X by Y or modeling. Then the last basic thing was you get a table of just, here are all of the tasks and parameters, and how many rows you have, and then what we pulled. This is very simple, but when you pull hundreds of parameters, this becomes a really good navigation bar, because you can very quickly select, "I just want to see this task," and pull that into a data view.

Again, not the most complicated script in the world, but the GUI and the polish was part of getting real adoption. Put it in a JMP add-in package and ship it. Immediately, I thought it was done. "Hey, installed it, and nothing happened. I don't know if it worked." It turns out a lot of users don't use add-ins. When you install an add-in, it just quietly goes into this add-in bar with nothing else, and so this had to get fixed. It turns out the add-ins menu, you have this startup script where when the add-in starts, which includes install, you can run a script, so I added a little pop-up box that says, "Hey, it's installed. Find it in the add-ins menu."

Then, typical me, while I was doing dev, it's like, "Oh, this pops up every single time JMP starts. That's super annoying." I stole this from a software developer friend of mine. The concept is like, yeah, just put a file in the folder that you delete after the first time, and then when you run that welcome box, it just doesn't show up if the file is deleted. We have welcomed that once, that the first time you install it, pops up the window, the script runs, pops up the window, and then it deletes that file, and you never see the "Find the script in the add-ins menu" box again.

Actually deployed it. We have an internal GitHub, which is where the source code and then the packaged add-in lives. Then the Markdown file for that, there is the, "Here's how to set up a data source on your Windows machine. Here's troubleshooting." Released it. Success? At least one horse, a couple of horses, drank. Users are asking, instead of "How do I fix this? Can you help me deal with this error?" it's more like, "Hey, this is great. Can you add this? Can I have this option? I'd really like to see this." Those are directed towards a Jira ticketing system for me to keep track of, and really, it's once in a blue moon that I really go and update those, but those are nice to have.

How it's going, like Edena, that data warehouse, that usage went way up. People started discovering it, probably not only through this, but this was one way to where I started to have influence with that team. It was running on virtual CPUs, and they 10Xed the amount when I was like, "Hey, a bunch of people are using this thing that I built; it's now taking 5 minutes." As well as more data is being put into that, because I have a user base that says, "We want this tester data in there. We want this field reliability data in there." I'm getting that in weeks for limited release or, "Hey, we can have that next quarter," which is great.

Other projects are enabled, but most importantly for me, I now have a template both in my knowledge of JSL and the surrounding ecology of what worked, what did not work for supporting this thing and making it not a help desk job, that I can package future add-ins, both growing this utility as well as others, and have them live at this site scale, at this factory scale, or between factories at that size.

Go ahead, Horse, Drink. You still can't make them, but it's not been a struggle. I've seen people use this in meetings, which was the win condition. Takeaways: the GUI, I think, drove a lot of the adoption. Previous scripts of mine were more complicated, arguably more useful, but adoption lagged, or again, it became a support nightmare to where I just stopped promoting the thing. I stopped giving it out. Sugar water is better than plain water. The barrier to entry on display boxes was not as long as I expected it. It was a high barrier to entry in terms of you just have to get in there and start making that nested structure of window, H list, V list, list boxes, panel boxes.

Once I guess you've done that a couple of times, and with some of the tips I learned along the way, again, the messages in the constructor, incredible, now it's second nature. GitHub or whatever is official for you at your organization really beats handing off a script manually to people, as well as now the same place they get it, you have an FAQ, so you don't have to answer those things originally. Then, yeah, developing an add-in from the get-go is the way to do it.

That's the talk. I really want to thank Nick Vacca and Mark Zwald for encouraging me to do this, as well as supporting my organization with JMP. Thanks to Paul Munn and Derek Weber, who helped me along the way, gave me feedback, and are just great work pros. JSL Dev Team, especially last year at Discovery, was really helpful. Then the JSL website is a real improvement to the Scripting Index and the Scripting Guide. Here's some contact info if you'd like to talk to me. Thanks. Cool.

All right.

Like 35 minutes. I didn't really improve on that, but I'm happy with it.

I thought it was really good, and I think it seems like the more a person does a presentation, you'll just naturally speed up, too.

Yeah.

You might find when you're doing it again. I thought it was really good.

Thank you.

I will just take the files and stop the recording once we drop off. I'll get the files; I'll upload them for Kirsten and whoever's going to edit them. Then, if you don't mind, just registering for Discovery Summit and getting your headshot, and I can't remember what the third thing was.

PDF.

Upload, yeah. Now that you've got your presentation files, if you don't mind just uploading that. Like I said, if you have any trouble, well, you can email me, but I'll probably ask Kirsten for help. If you want to cut out the middleman and email Kirsten, but I know she's happy to help, and she's the expert on this. It was a great presentation. Thank you so much for doing this, and thank you for being so committed to attending and sharing your knowledge with users, especially in light of the fact that maybe you're going to have to pay for some of this out of pocket.

No worries. It's effectively a vacation, so it's not a big deal. Thanks for putting up with the three or four reschedules.

Oh, no, not a problem at all.

It's been a disaster of a month, but yeah. All good now.

It's a new month, so maybe a little bit better.

There you go. Thank you.

You have a great day. Thank you. Bye. I appreciate it.

Bye.