Getting a New Perspective: Moving from Vision to Perspective

With the addition of the Perspective Module to the Ignition platform, it is now easier than ever to access critical data. However, with the level and complexity of existing Vision projects currently deployed around the world it can be a daunting task to make the switch from Vision to Perspective. During this presentation we hope to share some of the pros, cons and even some tricks for making the change as seamless as possible. We will also discuss how to manage these changes over larger enterprises. All questions are welcomed.

Video Transcript:

00:00
Tyler: Hey, everybody. Welcome to Ignition Community Live. This is our presentation on New Perspective: Moving from Vision to Perspective.

00:11
JC: Good morning from JC Harrison. I'm the director of Systems Engineering at Roeslein & Associates. We've been using Ignition since 2010, and we're happy to present this, and hope everybody learns something from it.

00:22
Tyler: I'm Tyler Huffman, I've been with Roeslein for about six or seven months now. I've been working with Perspective pretty much since I started. I started on Ignition 8, so all of my experience is coming directly from learning Perspective, rather than from moving from Vision to Perspective.

00:41
Phil: Hello my name is Phil Bourner, I've been with Roeslein for a little over four years now. Started with Ignition back in 7.8, so I was doing Vision for a while, and now recently, I've pretty much just been focused on Perspective, with the 8.0 release.

00:57
Roy: Hey guys, my name is Roy. I'm the engineering manager over in Europe. I've been working with Roeslein for about eight years now, and Ignition from quite an older version, maybe eight years as well. So quite a bit of experience mainly with the Vision side, to be fair, only just started doing Perspective like most people as well. Oh yeah, looking forward to hearing what Phil and Tyler have to say for us.

01:24
Tyler: Alright, awesome. Moving on to today's topic, Phil, if you wanna take it.

01:29
Phil: So, for today's topic, we're gonna be going over a bunch of things that we've learned from first developing in Vision, and then developing in Perspective, and how our things changed, how our mindsets have to change. So first off, we wanna give an overview of how we can do a rapid development of a screen in Vision compared to Perspective and the kinda things you need to take into account when you do that. Second are component usage containers in Perspective. If anybody out there has used Perspective much, will know that containers are a huge deal, and they're not so much in Vision. So just go over how we have incorporated those, along with some property configurations to deal with things like extension functions, changing and other things. Then Tyler is gonna talk to you about some mobile functionality and what to consider when designing a screen for desktop mode to also make it translate well to a mobile version of the same screen, to make sure that the data is still there in a readable format. Then finally, we're gonna talk about some useful features that we found in Perspective that we really like to use that maybe weren't as... Either not used at all or not used as much in Vision.

02:50
Phil: So first off, the screen design. I have a model back when I was making a Vision screen of "make it work, then make it pretty." So when I get to talk to the customer and maybe they want a new screen that wasn't part of the original plan, first, we try to talk to them and find out what exactly they wanna show. And then I usually would just drag stuff on the screen, as you can see on the picture below, and just make a button, get the data that we would wanna show on the screen, and then once the data is coming in proper, then we would build the screen to make it look more like an actual live production project screen. But now in Perspective, as I was just talking about earlier with containers, it's shifted more to a "make it pretty, then make it work" kind of development, because if you throw everything on the screen and get it working and then move everything around, put it in containers, delete containers, you're gonna have to redo all your reference passing and stuff, and that can be very time-consuming. So it's a lot more efficient to plan out your screen ahead of time, and then move on from there.

04:00
Phil: So, this is a Vision screen that we have in a project running 7.9, just one of our typical screens, we have the same screen in Perspective. The main difference between screens is when we get them done and we show them to the customer: ‘How do you like it? What do you wanna change?’ On the previous screen, division screen, if they wanted stuff moved around, it was a two-second change, move stuff around, hit Save, and there you go. Whereas on the Perspective screen, one of the examples is the Retrieve Data button, actually used to be below the end date. And when they requested to move it up so we could make the bar chart bigger, we ended up throwing it in a flex container and then having to rebind all the passing in that button for all the tables in the chart, which is a lot more... Well, I shouldn't say a lot, a little more time-consuming than in Vision. But I think overall, the look is a lot cleaner, which is one of the main reasons we've switched.

05:00
Tyler: If you've worked with Vision, you know that when you're designing a screen, you're pretty much only gonna be using just one container when you're building your screens, unless it's for specific cases, that one being the root container. And you can see here in the project hierarchy, that we have just the view, the root container, and then all of the components just added on to the root container. This makes it really easy to move things around and restructure the entire page without having to change any references because everything is still gonna be in the same base container.

05:37
Tyler: But when you move over to Perspective, it all changes up a little bit. The coordinate container is not commonly used, at least in our applications. We generally will start with some flex containers because it allows your components to scale and move along with whatever side screen you're looking at, whereas Vision's a bit more static. So when using flex containers, in order to align everything, you're gonna want to nest flex containers into other flex containers, and it ends up giving you a really clean look at the cost of a little bit of development time, because if you have to move components from one flex container to a different one, it's gonna change any other component's reference to that one.

06:23
Tyler: So, for example, here in our Vision screen, we developed this entire screen and we got it looking how the customer wanted. And then after we developed it, they wanted this part number table added in. And we said, "Sure, why not? That's no problem." We added it in, got it all working. That was very simple, very quick. All we had to do is get the table in and get the data right. In Perspective, we would have had to add in another flex container here and divide this whole flex container into two so that we could put another table here.

07:05
Tyler: And while that's not that much more difficult, any references to this table would need to be updated. So this graph, for example, is pulling data from this table. We would need to go into the binding and change that. The button that writes to this table, we would need to go into the script and change that as well. This screen, it wouldn't have been that much harder to do that. But with more complicated screens, it can get a bit more hectic to try and track everything down. Another thing to pay attention to here is just the general flow of the screen. We've talked about using flex containers in respective projects. But what it ends up looking like is we've got our main root container here that includes everything in it, then we have three flex containers here. One for the header, one for the upper part, with all the drop-downs, data entry fields and the table, and one below for the graph. And this upper one is divided into two along this line, split up into the table and all the data entry fields, then this flex container here is also divided into two, and then we have new flex containers building along. We have a new flex container for each line as well. That allows everything to keep lined up and make it look really nice as a final project.

08:38
Tyler: Moving on to another screen that we designed in Vision, this is a good example of making it work first. When you look at it, you see that it's working, it definitely gets the job done, but it could look a little bit better. At first glance, it just looks a little busy with the excess of borders and the abundance of neon yellows and greens. And combine all this with the black background and you get a screen that can be a little bit tough to look at. However, it is functional and there's no major reason why we would need to go back and change this. Now, if you're migrating your project from Vision to Perspective, you have a golden opportunity to take a look at the screens that you built in Vision and decide what needs to be updated. Because, since you're gonna be pulling pretty much the same data for both screens, you can spend maybe a little bit more time developing the look of it. And that's what we did here. We're getting pretty much the same data in, but we decided to get rid of the neon yellows, get rid of a lot of the borders, make everything look a little bit more open and not go with as dark of a black on the screen. And the final product ends up looking easy to look at. A little bit less busy, and I think in general, it just looks a lot better.

10:04
Phil: Another thing that we, just changing from Vision to Perspective, is we used a lot of extension functions on stuff like the bar chart you can see down there to dynamically change colors of bars, add a target line, even control the look and feel of the numeric labels. And in Perspective, what we found through a lot of trial and error and reading the forums, is that all this functionality can be actually achieved through the properties that are already listed in the property panel for these components. So controlling your bar colors now, there's just derived data from the field's property. And what we do when we build out our data, our array, we add a component or a value called color, and then just you do the calculations to figure out what color it should be beforehand and then set a hex code into that field. And then we can tell the derived fields from data to look at the color, the name property color from our data, and it will automatically fill it in. Another thing seen in the other picture there on the right is a coloring table cell based on the value in that cell.

11:27
Phil: So go over on the data with the lash average. You can see there's a style and a value. So I didn't even ... when I was first doing this, I didn't know if this was possible, but you can put a style on every cell in your table and have it look however you want. So that's neat, and we no longer need to have all the extension functions with codes on them, which a lot of times in Vision would also require an advanced knowledge of the JFreeCharts and stuff like that to change all the options and properties. So we no longer need that, which is great. This is just an example of a screen that had a lot of extension functions, JFreeChart code to make all the colors and the labels look how we wanted. There's a tool tip, so we didn't get the picture off here, that are formatted based on which chart you're hovering over to give you names and additional data that a normal tooltip wouldn't. And then the next slide, our Perspective screen, which you can see is pretty much the same, done without extension functions. The only major change here is that our target line is no longer just a horizontal line that we add in with code. It's an actual separate series on the chart that we just set to be a line render and give it a constant value when we build out our data sets.

12:54
Tyler: One completely new aspect of Perspective design is the addition of more functionality for any one of your products. This will come with its own set of unique challenges, completely separate from anything that you may have dealt with previously. And here, we thought it would be a good idea to discuss some of the practices that we have adopted when building our applications for use on some mobile platforms. One thing to pay attention to when you're designing a screen for a mobile platform is space. Obviously, that's the first thing that may come to mind because you're gonna have less horizontal space available. So really each piece of real estate on that screen is gonna have a much higher value. This is where you need to look at your screens and you need to decide, ‘What information do I really need on here? What components do I need to keep, and which ones should go?’ Because the way that people are gonna be using this are just pulling it up on their phone on the fly, and you wanna make sure that they have all the information that they're gonna need to see whenever they need to see it. And you generally get the best results from just talking with the people who are actually gonna be using this, see what they like from the desktop views, and then you can add them into the mobile views.

14:10
Tyler: In terms of UI, it's important to remember that people won't be using this mobile app with a stylus, so you're gonna wanna keep your buttons small, you're gonna wanna use scrolling and not require a lot of inputs on things that may be hard to click because people are just gonna use their thumbs to navigate through this. So keep that in mind when you're building it out. And also people generally just prefer scrolling over some smaller components, so we personally like to build out our mobile screens vertically, just so you can scroll through and grab all the information that you need. It makes it a lot easier and it goes a long way with the customer, whenever they end up using those mobile apps. And finally scalability. Different phones and different tablets are gonna have different base resolutions, and this can cause some issues if you don't account for some of the smaller ones in particular. Like if you build your screens to work with a 640p resolution and something's using 540p, it's gonna be a bit of an issue because some of your components are gonna look squished.

15:24
Tyler: What we would recommend is building out your screens for the smallest phone resolution that you can think of, at least horizontally. Once again, they should be able to scroll through it fine, so vertically, that's not a problem. But building out your screens for the smallest phone resolution that you think people will be using, and then allowing the components to grow so that they can scale up to larger phones and tablets. So just an example of building vertically, you can see here on the screen, it's nice and spread out, all the information's available just on the base screen, you can take a look at it and get whatever you need to see from it, but when you move over to a vertical ... or to a mobile screen, obviously you're not gonna put both of these columns here side by side because people would have to scroll sideways through that, or we'd have to use maybe the carousel component for that. And yeah, people just prefer scrolling up and down, so we just stash components on top of each other, and it's simple, but it works.

16:32
Tyler: I wanted to discuss, when talking about designing mobile views, try to avoid as much as possible when you're building out these views, overstyling. It can be a little bit tough because with Perspective, you have this great style-selector tool with a lot of options that you can customize your screens to look exactly how you like, and people can go crazy with it, at first, I know I definitely did. You can make some screens that look pretty cool, but a lot of it's just very unnecessary. So when you're looking on these screens, you see it's all built out in grayscale, very easy to look at, nothing's in your face, except for this one part right here, because this is probably the most important thing that you'll be seeing on this screen. And this is a benefit of not overstyling your views, because you can draw somebody's eye to a specific part by using just a little bit of color. And that point is even more important on a mobile view, because once again, somebody is gonna just be using this on the fly, they're gonna open up their phone, go to the view, and they wanna grab the information that they need and then put their phone back in their pocket.

17:50
Tyler: So here I kept everything grayscale and just use the color to tell them the machine state. So it's green because it's running, it'd be yellow if it was in standby, and red if it was faulted. It's just a really easy way to draw somebody's eye to important pieces of data. Finally, talking about the removal component, so moving to a mobile view. This could be a bit more of a difficult decision that needs to be made when designing a screen we use on a mobile platform. You need to decide which components are available on the desktop, which components that are available on the desktop need to be cut for sake of space for the mobile view. It's a little difficult because you spend time developing all these cool components and functions that you're excited for people to use and stuff like that, but when it comes time to build the mobile view, you realize that you can't fit all of it, reasonably you can't fit all of it on a mobile view. So this is when you need to take a look at your screens from the perspective of an operator, somebody who's gonna actually be using these, and you need to decide what information needs to stay on these screens and what can go.

19:07
Tyler: For example, here I spent a decent amount of time building out all of this information, writing the scripts for it, and we have this nice Pareto chart that shows the time that it was in each state for each hour. And it wouldn't really make sense. And when moving over to the mobile view, if I had kept that Pareto chart in there, it would have squished all the other components to the side, so. And it wouldn't really make sense to build it out vertically and put that Pareto chart below the rest of these lines. So I decided, ‘You know what? We've got the event durations here, I can keep that, I can get rid of the Pareto chart and make sure everything still looks nice in the mobile view.’ These are just some things that I've found when developing my screens for desktop and mobile view that have helped me build better views for the operators to use.

20:07
Phil: Alright, so here are some of the useful tools that we've found when developing in Perspective, one of the message handlers, it was also in Vision, but we are using it a lot more now in Perspective. The main way we use it is to deal with pop-ups within a view. Beforehand, Vision has just a function where you can call a confirm box and it'll then automatically pass back whether you click Confirm or Cancel. Now, what we do is we open up a pop-up that we've made that has the same functionality, a confirm and a cancel button, but depending on what you put, what button you push, it will activate a message handler to send back the choice and run the proper script based on your choice.

20:54
Tyler: Yeah, another new function in Perspective is the addition of styled classes, this is just … these style classes are something that you can create, that you can easily apply to components throughout different pages. It's really useful for setting up things like backgrounds and the size of fonts throughout headers and stuff, and they can be a huge time-saver for the project, and it can also give it a bit of a sense of continuity because each of your screens are gonna look pretty similar. The important thing to make note of here is not to over-utilize them, for example, we generally don't set up font size on these... Font size or font style on these because it's most commonly over-written due to the sizing of different components on these views.

21:43
Phil: Finally, on this screen, we got the transforms, which is pretty much one of my favorite new features. But one of the main things that we like to do, or we like from it, is being able to see the output down at the bottom there, we have boxed in red, so we know that if we're gonna error out or not, we can fix it right away, first time through, get it working the way we want. Previous to that, what we had to do in Vision is create a custom property, make a property change script that only executed when that custom property changed. Essentially for testing, we forced the change to happen and then get the error message and go and fix wherever there's errors or bugs, and then when we were done, we'd have to push the output back to a secondary custom property so that we could then use it the way we wanted to. Here, all that is done in one quick, easy setup.

22:37
Tyler: Another thing that I've found personally pretty useful when building out screens in Perspective is property change scripts. At first, I wasn't using them a ton, but after a while, I thought of... I found some new ways to use it. And one of them being this custom property you see here called DB pull. This is something that you're gonna find on almost every one of my screens that I build out. I create this, I make it a Boolean property, and I put a change script on it. And from there, I write the entire script for the core functionality of that view, and it makes it really easy to call from anywhere else on the screen. So if any of these properties change, you can see the little change script icon here, they're gonna trigger this DB pull function, which will refresh the data on the page.

23:34
Tyler: This makes it really easy for troubleshooting your projects. If you go back a week later, you don't have to go through and click on all these different buttons and everything, you can just go into this change script, figure out what's going on, and fix it. And it also allows you to trigger refreshes on these pages whenever any global views or session properties change, like if you have a custom date range selector and it controls multiple different views, you can just send out a message whenever that changes and use a message handler to refresh this. And there's really so many more uses for change scripts that I'm not gonna be able to cover throughout the 30 or so more minutes we have here. It's a really nice function and I definitely recommend checking it out if you're starting to develop in Perspective.

24:32
Phil: One of the things, we've been working with the 8.0 Perspective Module since pretty early on in its life, and we've noticed some issues when we were trying to convert from Vision to Perspective that may have been fixed by now, but we found workarounds that are still working perfectly, so we're just gonna cover those in case you guys are seeing some of the same things in your projects. But the first one is on a table component in Perspective. We initially just bound the data set objects, like we would in Vision, to the data property, and it would display fine, however, we found that when we were pulling large time spans of data, several thousand rows in the data set would be turned. We'd get … the screen would become very unresponsive, like you'd click a drop-down and you'd see nothing. The other one we have are for loops and while loops. So a lot of the code, we were trying to just convert into Perspective and just change as little as possible, but we noticed that we had a lot of for loops in our scripts in Vision, and it never really caused an issue.

25:45
Phil: But when we put it into Perspective, we noticed that it was taking considerably longer to execute those scripts. So what we ended up having to do is optimize our database queries and try to do more within a for loop than we were before. So if we needed to do a loop, we'd do a couple things at a time instead of just one thing at a time, move on to the next. And along those lines, the name, queries, nowadays Perspective, if you wanna bind something to a database query, you have to have a name query associated with what you wanna get, you can no longer just use a query builder and write it out, which we find is actually much more helpful because if we wanna change something across the whole project, we just change it in the name query, and it all comes through just like it normally would with the updates. And then finally, since Ignition 8 is still fairly new, they're pushing updates, minor revisions, pretty regularly. We suggest having a plan, if you're using third-party modules or anything like that, to refer any updates you do back to your last stable version. We had some instances where we would update to the newest minor revision, but that would break the third-party modules, so we'd have to go back. So we just keep that in mind when you're looking to update to the newest Ignition version.

27:13
Tyler: “Which do you prefer, Vision or Perspective, for overall flexibility?” Phil, I'm gonna let you take that one 'cause you have experience with both.

27:23
Phil: Right, so Vision, it's what I started with, and what I had my habits built around, good or bad, so it works. What I like about Perspective is it is more flexible in the long run. It's just learning everything new and stuff that I don't know about yet, 'cause I don't know what I don't know. I think overall, down the road, Perspective will be much better than Vision.

27:51
Tyler: Yeah, I agree. I think Perspective is a very, very flexible application. It can do quite a bit, and a lot of the components have functionalities that aren't really ... that you might not really be aware about, when you first start using it, that we've just had to search through on the forums and everything to find out, but it does have a bit of a learning curve, so if you have experience with Vision, Vision is definitely more flexible since you already know how to use it.

28:23
Tyler: “How much time does it usually take to recreate a Vision screen in Perspective?”
I would say it doesn't take that long, if you know how you already wanna format it. If you're gonna format it the exact same way, it's a pretty quick process. You just have to think about how you're gonna get the data in. You have these new tools like transforms, change scripts, and message handlers to work with, so it's more of a question of how you wanna approach things, that might take you a little bit longer. Overall, designing the screen shouldn't take that much longer. Maybe a few hours a day, once you know how to design everything.

29:07
Phil: “Can you explain more about how to use the array data on a table component?” So when I'm building one out, I think of it more as a list of dictionaries. You just build out a dictionary essentially with all the different entries, the fields you'd want, and you can just make it a list for each row. You can put in extra stuff that you would never use in your table, but then can reference elsewhere, and I've done that a lot. It's more useful than just showing data on a table, you can actually put other stuff in, like how we were talking with the bar color and stuff like that.

29:41
Tyler: “Are there any design challenges or strategies that you're still battling or hoping to learn more about?” A lot of the challenges that we run into are ... Since Perspective is so new, we do run into bugs occasionally, that we'll post on the forums, and generally Inductor is great about getting to those and fixing those if there are any big issues. In terms of challenges that we're battling that don't really involve bugs, I would say there aren't a ton, Phil, unless you can think of some. Perspective is, it's pretty well fleshed out. You can do a lot with it.

30:23
Phil: I think the main thing is, when I'm searching the forums on how to do something and see how people have done it, and it just never would have come across in my mind to do that stuff, like adding a style to an individual cell in a table to get the colors. So it's just trying to train my mind to work that way with all the properties and how to build out your data, to be flexible and work with everything that Perspective can offer.

30:53
Tyler: Yeah, I like that point you brought up about battling your mind there a little bit, because if you worked with Vision, moving to Perspective, you have to put a lot of your Vision knowledge by the wayside, because it is a very different module, it's gonna take a little bit time to learn. And thinking of how you might do something in Vision, it may not be the same in Perspective.

31:15
Phil: We've got a question here asking, "Any knowledge of a desktop application to host Perspective projects?" I'm assuming you're getting at, like, how they have the iPhone application and Android applications for running on mobile. Are you looking for a similar thing for desktop? 'Cause right now all we use is just the web browser, a normal web browser, to bring up our Perspective projects.

31:40
Tyler: We just hop into Chrome or Firefox and toss it up there, but no, we don't really know anything about a desktop application right now. Curious on that Drupal property with the property change script, why not do that as a custom method?

31:56
Phil: It's just, I think that's just a carry-over from how we designed our projects in the past, with the custom properties and property change scripts. So one of Tyler's first jobs, when he joined Roeslein, was to take our Vision screens and make them Perspective screens. So I think it just got carried over and we didn't update to using a custom method, but it is definitely something that can be done.

32:22
Tyler: Let's see, from Michael Bets: “What have you found to be the most difficult when converting from Vision to Perspective?” Getting used to flex containers was a big one, I think. When I first started using Perspective, my initial reaction was just to open up a coordinate container and try to line everything in there, and it ends up not looking too well, too great, and it's a big hassle to get everything looking right. When I was converting screens over from Vision to Perspective, just using all the new functions to try and get things in the right format for the screens was a bit more tough than I expected it to be, when I first started out. Phil, what would you say was most difficult when converting?

33:09
Phil: Well, when I first started, it was making sure the paths were right, 'cause referencing the objects was a lot different, but when we got the ability to ... that was pretty early on, in the beta early access. We got the ability to essentially just get a drop-down and link out that way, it got a lot easier, but making sure that I don't use any database queries where it's just hand-typed out in the scripts and then run, making sure I have the name queries, and them optimize them properly also was a big challenge.

33:41
Tyler: And limiting the use of for loops was a big one, because I feel also we used those pretty heavily throughout the Vision projects that I was converting over, trying to limit those in the new projects that I'm building can be a little bit difficult.

33:55
Phil: Question: “Tyler, about what mobile devices are people using the most?” Around here, it's pretty much just the phone, but you've dealt with a lot more in mobile projects than I have.

34:07
Tyler: Yeah, when I see people using these devices to access the project, I would say the iPad is pretty much the go-to for site managers and stuff, if people have it and they already use it, they're gonna be using the iPad, other than that, just your standard smartphone, your Samsung Galaxy's, your iPhones, those are pretty common. I would say for hybrid laptops, they'd probably be using the desktop views. Yeah, just standard mobile devices that most people have, your iPads and your iPhones, people are gonna mainly be using those.

34:44
Phil: Question, "If you could change one thing about Perspective to make it easier to use, what would it be?" I think for me, it'd have to be the deep select option, so when you get containers within containers within containers and you just have to double-click your way down or you can go through the window browser and path that way, but I'd like to see if there's some sort of way where it can detect that you're over a button, and when I click on the button, it automatically goes to that component. If I click in white space around the button, then maybe go to the flex container that is next level. That would be my one thing that I'd like.

35:23
Tyler: Yeah, it takes a while to drill down into those, especially when you have four flex containers before the button. Yeah, I agree that that would be something that I'd like to change about Perspective as well, because when you have so many flex containers on a view, it takes a while to drill down.

35:39
Phil: And we got a question about, “Any pointers for user management in Perspective, such as rosters, roles, et cetera?” The main way that we're using the users here is more of a generalized sense, so all our online supervisors have a supervisor login, it's just one supervisor login, team leaders have one, and then your plant staff, your plant manager, ops manager, engineering manager all have theirs. And so we set up roles that way. And then put limiting features, security zones based on those roles, you don't really do individual users ... can access certain things. So it's not really as fleshed out as you can get with the Ignition users. Are you guys doing it anyway different, Tyler, on your sites?

36:26
Tyler: No, yeah, we're pretty much just using the roles and zones.

36:31
Phil: So we just had a clarification on that last question, meaning they wanted to know about updating users in the runtime, so adding people, taking them away, changing. And I'd say no, we haven't done that since we use just a generalized login scheme right now, we have plans to go to use the customer's active directory, we just have not implemented it yet.

36:55
Tyler: We'd like to thank you guys for tuning in. We're really glad that we could share some of the stuff that we've learned throughout our time working with Perspective, and we hope you guys take some of these tips and put them into your own projects and hope it works out well for you.

37:13
Phil: Thank you, everybody, for tuning in. I hope we could have at least provided some help to you. If you have any questions, feel free to reach out.

37:20
Tyler: Yeah, definitely. Once again, thanks for tuning in. And hope you guys have a great rest of your day.