JMP Live 19: Latest Enhancements in Communicating Discoveries (2025-US-30MP-2582)

All right. Hello, my name is Eric Hill. I am the manager of the JMP Live development team here at JMP. I am about to show you a bunch of things that are new in JMP Live 19 for JMP Live. That's what you've tuned in for. I'm going to start with a control chart. Here's the washer's sample data from JMP. I'm going to run the P chart, control chart.

You can see that there are a couple of out-of-control points here. I'm going to publish this to JMP Live. Publish reports to JMP Live. That's the right report. I'm publishing a new report. I have to find a place to put it, so I'm going to put in the control chart triage space or folder. The title looks good. I want to publish new data. The data is not out on JMP Live yet. Okay, there we are. There it is.

Now, in earlier versions of JMP Live, you could publish control charts, and we would notify pretty much anyone who could see a control chart. If you publish a control chart that had active warnings, it would let people know, give them notifications, so they would be aware that this happened, so they could see it.

But after that, there wasn't a whole lot you could do with it. You couldn't turn it off. You couldn't say it was okay, it was managed now. Don't tell me about this anymore. That was pretty much the end of the story. In JMP Live 19, we set out to really complete completely revamp that whole process, allowing you to not just see your control chart warnings, but manage them and work on them and then resolve them all within JMP Live.

To show that, one of the things I can do is just point at one of these out of control points and click on it. That gives me a panel over on the left that gives me more details about the point, tells me what proportion is defective, what row it's on, what test it failed. This failed the one point beyond 3 Sigma test.

Then there are some areas where I can add information so that other people who see this control chart will know what's going on with it. But the most important thing I can do is assign it to someone whose job I believe it is to research it and figure out what the cause or the resolution of it is and then document that here.

I know that Chang Hua is responsible for this process. I think she's the best person to research this control chart warning and figure out what's going on. I'm just going to save that change. It's the only change I'm going to make. Now, I have another browser here that has Chang Hua logged into it. This is her session.

You'll notice that up here in her notifications, she has an active notification now. I click on that, and it says that she has been assigned a control chart warning by Eric Hill. All she has to do is click on that warning or on that notification. That will bring her right back to the very same place where I assigned her to the control chart warning. Now she can begin the research process.

The first thing she might do is let people know that she is on the case here. She can move this from being in the open state to being in the investigating state. That just lets everybody know, "Hey, somebody's looking into this." Then she can add some notes about what she's going to do. In those notes, she can mention people if she needs other people to be drawn into this investigation.

Let's say that Chang writes, "Hey, Joseph Carlson, send me the details on the regulator failure last week." Ms. Chang thinks this might have something to do with that. She wants to get those details from Joseph. When I save this, a couple of things are going to happen. First of all, the state is going to get changed to investigating.

Then Joseph, since he was at mentioned, is going to get an email and a notification within JMP Live, letting him know that Chang has requested some information from him so that he can provide it to her, either directly here or offline.

I'm just going to click Save here. Something else that you may notice happened is this control chart warning used to be a red circle, and now it's an orange diamond because to that it's under investigation, as opposed to this one over here, which is still open. Nobody's looking into that one. Somebody might want to do that.

If you hover over the point, you can see all kinds of information about what's going on, who's assigned to it, what the status is, any notes that have occurred. A great way to just very easily take a look at what's going on in there.

Now, let's suppose that Joseph gets Chang the information she needs, and she concludes that this was caused by the regulator failure. Chang can come back in here later and say, "This was the regulator failure," and then she can mark this addressed and save it so that now it's a green square. Again, more clearly indicates no need to worry about this one anymore. We know what's going on.

Now, the control chart itself still has an exclamation point over here in the warnings in this little side panel here because there's still an unresolved control chart warning. Somebody is going to need to go take care of that one, too.

Let's just imagine that Chang goes ahead and assigns herself to this one as well and marks it addressed and says same issue here. She's going to save this change. Now both control chart warnings are showing green, squares.

Then now that everything's resolved over in this left panel, and anywhere you see this control chart in JMP Live is going to now show a green checkmark indicating that there's nothing wrong here in this control chart. It's all good. Nobody needs to worry about it anymore.

This is the control chart triage process that's new in JMP Log 19. There is another full talk on this process that goes into more detail being given by Michael Goff. If this is something that interests you, you may want to look up Michael Goff's contribution as well, his presentation, and take a look at that.

All right, a related topic that's in the quality and process control space along with control chart warnings is some work we have done on process screening. Just close up some of these other things here. I'm going to open up the semiconductor capability sample data table and run the process screening script that's in there, which produces this table of all these different processes that are documented in this table and what their status is. Then I can do things like add the goal plot to this and add the Process Performance Graph.

Now, if I published this report in JMP Live 18, let's see what that would have looked like. I'm going to go back to the browser here and up top. This is that exact same report that I just created, published in JMP Live 18 instead of 19. What do you get here? Well, if I click on things, it's not real alive. Nothing much is happening. I can scroll down, and I will find the goal plot and the Process Performance Graph down here.

But if I click on any points In the goal plot, nothing happens. I don't get any interactivity. Nothing else gets selected, doesn't get selected over in the other graph. Nothing that you expect from JMP is happening in JMP Live 18.

Let's publish to JMP Live 19 and see if it's gotten any better. Back to JMP, File, Publish, Reports to JMP Live. That's the report. I'm publishing a new report. I'm going to publish it to the Process Screening folder. The title seems fine. I don't need to add a description. Let's keep going. Again, I want I don't want new data to be published. I don't want to find other data that's already on JMP Live. It might not be the same data. Then I will publish.

Takes a few seconds, but it's done. From this Publish Results dialog, I can once again click Open to open it over in JMP Live in my browser. There it is. Looks It's about the same, but let's click on, say, NPN9 here, and it does get selected, and the control chart for the NPN9 process gets displayed over here on the right-hand side.

Maybe I want to compare this control chart to the NPN6 process. I can multi-select that and compare that. I'll try also the PNP just to get three of them over there. I can select as many processes as I want in the graph, and I can see their individual control charts on the right-hand side, compare them and see if there's anything between them that looks similar Those sorts of things.

Now, what about the goal plot and the process performance graph? Well, I don't have to scroll down to the bottom and have all this stuff scroll off to see that. We've put those into separate tabs in the same report here. If I click on goal plot, I will see the goal plot, and still my control charts are here for those three. You can see the darker dots are those three points. You can see two of them are in the goal plot section. They're doing okay. This one, other one is way out here.

But if I click in here, I can select a different set of points to take a look at. Let's take these four or five processes. I guess there's four of them. I can grab those, and then I can see those control charts, and again, compare those and try to understand why none of these are meeting the goal, that thing.

Similarly, if I head over to the Process Performance Graph, I can see those four points down here that I selected in the goal plot. If I don't care to look at those anymore, I can click off and then click some points over here. Let's just click that one. I can see the control chart for that point.

A much more interactive experience with Process Screening in JMP Live 19. If you like Process Screening, if you use Process Screening, you may want to check out what JMP Live 19 can do for you to distribute your Process Screening throughout your organization and have it be interactive as you've seen here.

Those are some heavy hitters in what's new in JMP Live 19. Let's just talk a little bit about some general usability or user interface things that we've done. One area that's gotten some attention is the home window. Let's go back to JMP Live 18 again and look at the Home window in JMP Live 18.

It's not real well-defined. It just shows you a list of all the posts you have access to in descending order by when they were last updated. You get the most recent posts first and least recently updated posts are further down, but not really a lot else.

JMP Live 19 is a lot more defined. We have a recently viewed section because if you looked at something yesterday, you come back today, you may be in a conversation about it. You may want to get right back to that, so you can continue looking at it.

Keeping things you've recently viewed available is very important. This shows you the first six, but you can click View All and see everything you've seen and just in descending order of when you looked at it. We repeat your bookmarks in this section. Bookmarks has its own little page up here, and also it can be accessed from here, but we throw some of those onto the main dashboard screen just so you can see those.

Again, with our emphasis on control chart warnings, we have a whole section on control chart warnings that shows all posts that have control chart warnings that you can see. I'm going to click View All for this one because it's somewhat interesting.

Because of that, those three states of control charts, needs attention under investigation, fully addressed. This page allows you to filter posts with control chart warnings based on what state they're in.

If I don't care about the fully addressed ones or the ones that are under investigation, I just want to see control charts that nobody's looking at, so I can see what needs work. Which control charts nobody's paying attention to, so I can restrict my view to that and easily go into these and then assign control chart warnings, those things. Just to help you take care of that.

Down at the bottom is the recently updated section, and that's really the same set of things you saw in JMP Live 18. That's really the only thing you saw there, that same set of posts is down here. One nice thing is you can restrict that. This is looking at it for all spaces on JMP Live. There may be a lot of spaces that you have access to that you don't really care about. If you want, you can just view posts from your favorite spaces.

I don't happen to have any posts in any of my favorite spaces. Maybe I need some more favorite spaces. How do I do that? Another area that we put some work into is Spaces. In JMP Live 18, if you went to the Spaces tab up top of JMP Live, all you got was a directory of all the spaces. That's really all you could see from there.

In JMP Live 19, when you click on the Spaces drop-down, you see your favorite spaces, your recently visited spaces, and then if you click View All Spaces, you'll go back to that same directory we had in JMP Live 18.

How do you favorite a space? Right from here, I can go right over here and click the star. Now what's new in JMP Live is a favorite space of mine. Now I get posts down here in the Favorite Spaces section. I can be confident that in the spaces list to the left of my dashboard, what's new JMP Live 19 is going to always be over here because I've favorited the space.

This section here shows you spaces that you've favorited as well as other spaces that you've recently visited. This section down here will change over time as you visit different spaces.

All right, that is the high points of what we've done to the home window or the story of your dashboard in JMP Live. Next time, I'm going to jump into a series of a bunch of sections on ways we've changed refreshable data. One of the great highlights of JMP Live is the ability to, once you've published data to JMP Live, you can go visit that data and set up a refresh script, a JSL refresh script, so that you can refresh that data from, say, a database or a file on disk or whatever it is whenever you need to.

Then once you refresh the data, then any reports that depend on that data will also regenerate automatically. It's a great way to keep your JMP Live site, live, active, current. We've made a series of improvements to refresh scripts and what you can do with those in JMP Live 19.

Let's start with linked data. Here's a folder that has four reports in it and also four data tables. You can see from the little circle, the little recycle-looking circle, that these are all refreshable data tables. That's what that symbol means.

We've got US cities, we've got Texas cities, we've got North Carolina cities, and we've got California cities. Looks like these three would contain maybe a subset of what's in this Postgres, the US cities from Postgres. Let's take a look at the US cities one first. Here's the data, and then if I go to settings, I can look at its refresh script.

Here's a refresh script for the US city's demographic data. It looks like it's a query builder query that's going against an RDS database, it's a PostgreSQL database on Amazon. It's going out to Amazon and fetching a bunch of data for all 50 US states. It's got a bunch of columns in here. Then after it retrieves the data, it's got a postquery script that computes the percentages of females, males, and veterans for each record, for each city, really, in each state.

That's a fairly complicated query. It's having to go out to RDS to get data. That sounds good. But I've got these other data tables, Texas, North Carolina, and California, that are really just subsets of this US cities table.

I'd rather not, for these other tables have to go out to Postgres to RDS and retrieve the data from there when I'm already retrieving the data from RDS down here, and I'm doing some things, making some calculated columns, I'm doing some work. I don't want to duplicate that work for these other tables that I need.

What I'd like to do is for these other tables, start with whatever data is in here and then just subset it based the state. In JMP Live 19, you can do that.

Let's take Texas for an example. Here's Texas. Let's look at the settings for that. For Texas, what I've been able to do is add something called a referenceable data table. It's a long word, but really it means a linked data table. So you can go in to add, and you can find other data on your JMP Live system here, and you can select something and save it, and that adds it to your list of referenceable data tables.

Any table in this list from JMP Live can be referenced up here in your refresh script. You could have one approach. You could have three or four tables out there that you want to combine into one, for example, for this table.

That'd be one thing you might want to do. In this case, I really just want to take that US cities one, get rid of the one I don't really need, and I set it based on the state that I care about. That's what I've done up here. In my refresh script, it doesn't do any query builder things or anything. It just says, "Hey, take the US cities from Postgres table and filter it based on, 'State Code is Texas,'" and that's it. That's all it has to do.

It doesn't have to go to RDS or anything. I've got a very similar refresh script in the North Carolina and California tables. What that means...

Let's go back to the folder that contains all these. What that means, if I go to the US cities from Postgres table and refresh it, and I'm going to go back to the link data. Whenever that finish is refreshing, these other tables that depend on it are also going to refresh because all they are is dependent on this one. Every time this refreshes, these other three are going to refresh.

The veteran by state, that depends on this original data table, so that's going to regenerate. Then these three reports that depend on these other three tables are also going to regenerate.

Let me get rid of that. Just by refreshing the US cities from Postgres, all these other data tables and reports are going to either refresh or regenerate once the new data from this refresh is available. It's one click, one refresh, and I've updated a whole folder full of data and reports.

A couple of simpler little things that we've done. I'll show you real quick. If I go to this Veterans by State report, one thing you'll notice is when you have data that's refreshable, like the data for this table is refreshable. It is that US City's table, and it has a schedule. It refreshes every Friday at 08:00 AM, and that's three days from now.

We've always shown you for a data table, when it's going to refresh, we show you without having to dig into here in the schedule, we show you what the next refresh event is going to be. It's going to be in three days because you could have three or four different schedules in here. Trying to figure out which one is going to fire next might not be that easy.

Up here we tell you, "The next time this refreshes, it's going to be in three days." Well, that's the data table. What about the report itself? That's really what you care about is the report that uses this data.

Well, now we will look at all those schedules and figure out which data is going to refresh first. And that means that immediately after that, the report is going to generate. Now, if you're just looking at a report, you can look up at the top and know that this report is going to regenerate in three days because that's when the next data it depends on is going to refresh.

It's just a simpler way to look at a report and understand when it's going to update again. Speaking of refresh schedules, let's go back there to the refresh schedule. Let's create a new refresh schedule, an additional refresh schedule. Let's suppose we wanted to start at 08:00 AM.

I wanted to repeat, now, when you go drop down the repeat drop-down, in JMP Live 18, the smallest number in here was five minutes. The most frequently you could reschedule something to run, to repeat, was every five minutes.

In JMP Live, we felt like that was a little restrictive. In JMP Live 19, there's a custom option where you can put any number of seconds down to 10 seconds. If this data is updating so quickly that you really need it to update every 10 seconds, you can do that. In this case, I'm going to say, let's say 30 seconds. Half a minute, I could say 120 to do two minutes.

Just makes it very flexible to precisely calculate when your refresh script is going to be scheduled to run. Cancel this. I don't really need it. Just a couple of other smaller things we've done with refresh.

Now, we've been talking about refresh schedules and using JSL to create them, but we know that a lot of people know Python better than they know JSL. In JMP 18, JMP became a lot better at using Python, running scripts that are written in Python.

In JMP Live 19, we have brought that to JMP Live. I'm going to go to this earthquakes table here. This is a table of earthquake information. It has a refresh. It has some data called All Day, which has a refresh script.

If you look down here, if you know JSL very well, you're going to be thinking, "This doesn't look like JSL at all." of course, it's not. It's Python. We now have a language selector for your refresh script. You can select JSL or Python. If you pick Python, you can just put a Python script in here.

Let's walk through that a little bit because it does have a couple of things you have to do. Of course, we're importing some libraries, and these are libraries that... These are Python libraries that JMP provides to make it easier to use Python with JMP. There's two and there's a third one right here, JMP Utils. JMP Utils allows you to install Python libraries that you need.

In this case, I'm going to install the Pandas library so that I can use Pandas data frames in my refresh script. I install that and then import it. Then I use a Pandas data frame to read some CSV off of a website and store that in a data frame. Then I subset it so I get magnitude greater than two-earthquakes only. I don't want those little piddly ones that don't really mean much.

I grab that, subset, and then, in order for this to get back to JMP and into JMP Live, it ultimately has to be a JMP data table. But JMP provides a utility to take a data frame and turn it back into a JMP data table. All you have to do is call from data frame out of the JMP Python library, and it will create a data table. This is the syntax you use in Python to return that to JMP as the result of your refresh script.

A few complications, but it allows you, if you're comfortable with Python, to stay in Python. I'm just going to run that. I'm just going to refresh this table, and you will see that the Python script is able to refresh the data successfully.

It takes just a few more seconds here... And there it goes. All right, it successfully ran. I can confirm that by going to the history and seeing that It refreshed successfully. Then, if I go back and, of course, look at the report, I don't think it really changed much because I did this an hour or two ago. I don't think earthquakes have changed all that much in the last couple of hours, but that's what the map looks like with the refreshed data.

If you like Python, you can use Python for your refresh scripts in JMP Live.

Here's another data table that has a refresh script, and I'm just going to run it and let's see what happens, and then I'll tell you what's going on. I run this refresh script. We'll see if it works. Of course, you could probably tell by that introduction that it's not going to work. It's failing.

I believe in 19, this is new, when a refresh script fails, to prevent you from having to go to history to figure out why it failed, we put the error message about the failure right here in the same panel with the refresh script. You don't have to go anywhere. You can look at it and see what went wrong.

It looks like we tried to include something called ADDIN_HOME, com.jmp.unitconversion. That means that this refresh script expects a certain JMP add-in to be available, so it can use some code from that add-in. How are we going to get add-ins available to our refresh scripts in JMP Live? Well, you can do it. It's a two-step process, but here's what you do.

First of all, you're going to have an administrator, go to the administrative settings for JMP Live. If you scroll down a bit, here is a set of add-ins that an administrator has said, "These four add-ins are ones we are willing to let you include in your refresh script. They've been vetted. We've looked into them. They're safe. Everything's okay."

All you have to do is upload the zip file for the add-in, and we store that in JMP Live, and then when a refresh script uses one of those add-ins, we will install that add-in on the instance of JMP Live that your refresh script is running on, run your refresh script, and then when it's done, of course, the JMP session gets torn down after every refresh script runs and restart it again.

When it restarts, it won't have that added anymore. It only lives in your JMP session for as long as your refresh script is running. That prevents add-ins added by one person from affecting refresh scripts of someone else. There could be collisions, so we want to prevent that as much as possible.

That's step one. An administrator has to say, "Yes, it's okay to put, say, the unit conversion add-in to use that in your refresh script." That's been done. If I go back to my other browser, I can go down. If I keep scrolling down, there's an assigned add-in section in the refresh script area. I can click assign, and notice I get that same list of four blessed add-ins that I can pick from to allow to run in for my refresh script.

I'm going to choose unit conversion and save it. It shows up down here. Now when I refresh this data, it should take just 20 seconds or so. It should succeed because the add-in will be available, and it will be able to find this file it's trying to include here.

There it goes. I don't see an error over there, and the error message went away. I go to history. Data was refreshed. It appears to have been successful. It's all good.

If you have add-ins that you need to run in your refresh scripts, you have the ability to do that. One thing that could be important there is data connectors that JMP Live is producing, and then other people can produce, those are distributed as add-ins. If you need to use data connectors, now that you can put add-ins into refresh scripts, you can do that here. You can install those add-ins and use them in your refresh scripts.

All right, so that concludes the section on refresh scripts. What about report scripts, the scripts in JMP Live that regenerate the reports after the data updates. Have we done anything with those?

Turns out we have. One of my favorite features of JMP Live 19. Here is a contour plot of the Iris data. It looks okay, except I think I would like to see if there's additional contours in the data. This looks like it was only done with one level of contours. I would like to maybe do two or three levels and see if I can pull out more contours in the data.

How can I do that? Well, the script that regenerates this table has always been published to JMP Live whenever you publish a report. But up until JMP Live 19, it's been read-only. There's nothing you could do. You couldn't change it. If you wanted to change the number of contours used in this contour plot, you'd have to go back to JMP, find the original script that you ran, rerun it with a different value for contours, and then republish it over top of this one to get the new value.

That was a bit cumbersome, so we decided we would allow you now in JMP Live 19, this looks a lot like the data table refresh script panel, but it's the report regeneration script panel. I can open that up and just change the number of levels from one to three and save it. Once you save it, the regenerate report button, since the script is now different, will enable.

I can click regenerate report and test out that the change I made actually does what I wanted it to do. It looks like it does. I'm getting now three contours instead of just one. I can tell that with these guys. That's what I want this to look like. I'm done, and now I've been able to update that without having to go back to JMP.

Another use case I use frequently for this, here is a diamonds data report. This is priced by carat weight over here. Then I've got data filters on color and clarity. But if I remember right, there are actually four Cs involved in diamonds. There's carat weight, color, clarity, and cut. Where is cut? Well, if I look at the data, it does include the cut.

It's just whoever made this report did not include it in the script, in the data filter before they published it. Well, thank goodness we can modify the script now. I can go to the script. Let's make it big again. I can find the data filter here in the script and just add Cut. Pull and Cut. Save that. Again, It's going to regenerate. We'll enable. Click on that.

There's the updated report, and there at the bottom is Cut. I can say I only want to see excellent cut. I can't afford ideal cut, but excellent. I really want an excellent quality diamond, so I can select that, and now I can filter based on that criteria in addition to the others.

Really helpful feature is the ability to just edit the refresh script. If it's not exactly what you want, tweak it and get it to be exactly what you want it to be.

All right, one last topic, and that is JSL. I don't know if you are aware, but there's various things you can do with JMP Live from scripting. You can publish reports to JMP Live in a script. You can update data. You can do various things in JSL with JMP Live.

Let me go back to JMP here and okay out of this dialog box. Here is a script that would have worked in JMP Live 18. Here it is right here:

I've got a cheese manufacturing company, cheese production company, and I've got three plants. I've got a Houston plant, a Manchester plant, and a Shanghai plant. This script right here is going to run a report, a capability report for each plant, and then publish those to JMP Live, so I can see if there's any difference in my plants in terms of their process capability.

They all share one spec limit file that lives on JMP Live. That's a nice place to centralize your spec limits is put them in a file on JMP Live, and then everyone can refer to the same file, and then you can have consistency across different plants.

That's the script I have. Let's see where that's going to deposit its results. If I go back to JMP Live, and go to this guy here.... Here is a folder in JMP Live. It's a folder called Pads in JSL, and it's got folders for Houston, Manchester, and Shanghai, each of my plants.

How am I going to tell JMP... How am I going to identify these folders in my script for JMP? Well, you might think I could just call them out by name. In JMP Live 18, though, you could not do that. In order to put something in a folder, you would have to visit the folder and grab its ID, which you can find up here in the title bar, or you could have gone to the details here and copied it out of here and then taken it over to JMP and put it in there.

That's a little bit of work. It doesn't document the script very well because I've got these IDs in my script. I mean, it works, but you've got to put these IDs in the script. In this case, I'm mapping the plant name. I'm using what's natural, which is the name of the plant to generate everything.

But then when I get down to JMP Live, I've got to map the name of the plant to an ID, so I know what folder to put it in. I can't really tell from looking at this script where it lives. What's the parent folder of this? Hard to tell.

This would certainly work in JMP Live 18 and JMP Live 19. Everything we've done in 19 is compatible still with 18. But in 18, I might do things slightly differently.

Let's bring up a second script. Here's another way you might approach it in JMP Live 19. In JMP Live 19, you can use paths and the names of folders just like you would in a file system in Windows or on the Mac. You can navigate your file system much as you would in other places.

If you look back, the name of this folder, the space is named, What's New, JMP Live 19, and the folder is 07paths in JSL. If I go back to JMP, that's exactly what I see here.

I'm telling JMP, I make a connection to JMP Live, and to get the base folder for all these publishes, I just tell the live connection to get me a folder that has this path. What's new in JMP Live 19, just like I see it in JMP Live. It's self-documenting. Now that's in my script.

Then when I loop through my different manufacturing plants and I want to get the subfolder to put a report in, I just say, get me, from the base folder, get me the subfolder that the same name as the plant, Houston, Manchester, or Shanghai, and then publish the content to that folder.

It's just a little more well-documented, it's clearer, and you can remember the names of your plants. You're never going to remember those IDs, so you have to refer back to JMP Live a lot less using paths and names than you do when you're trying to use IDs.

You're always going back and forth, grabbing an ID and bringing it back and putting it in your script. It just makes the scripting process a little bit more smooth. I'm just going to run this JSL script, and it will create three different capability plots and publish them to JMP Live in the appropriate folder.

If I go to See New Posts, there's Houston's Capability File, there's Manchester's, and here is Shanghai's. So they're regenerating for some reason, but they're all there.

Just a slightly, I believe, a little bit more user-friendly way to script JMP Live from JMP using paths and names instead of having to use IDs.

All right, well, that is the end of my presentation on what's new in JMP Live 19. Again, my name is Eric Hill. My email address is eric.hill@jmp.com.

If you have any questions about the material I've presented here, please don't hesitate to reach out to me and I can answer any questions or point you in the right direction.