Speakers

Jaco Markwat

Team Lead

Element8

Laura Strydom

Customer Success Engineer

Element8

Tristan McKechnie

Engineer

Advansys

Join us for practical insights on how to ensure success with the Ignition Perspective Module. Whether you're starting your first Ignition Perspective project or want to understand how to best approach your next project, this is the session for you. We’ll cover Perspective’s powerful features, server sizing and architecture design and how to set goals for your design and layout, with considerations for best practice implementations, to achieve faster development.

Transcript:
00:00 
Jaco Markwat: Good morning and welcome to the 10th Annual Ignition Community Conference, or ICC X, which is also Xplore and Xperience. Welcome to this virtual session. We are recording, or playing, or sharing here from Johannesburg in South Africa. And the topic for the session is “How to Best Plan Your Perspective Project.” My name is Jaco. I'm the Team Lead here at Element8. I'm joined by Laura.

00:26
Laura Strydom: Hi guys. My name is Laura Strydom, and I'm the Success Engineer here at Element8.

00:31 
Jaco: And we’re excited this morning to also host Tristan McKechnie. Tristan is a System Integrator with Advansys, Gold Certified System Integrator. Tristan, welcome. Thank you for joining us.

00:42
Tristan McKechnie: Thank you for having me.

00:43
Jaco: We look forward to some very practical and valuable insights. So, what we are gonna be covering today is we'll give you a quick introduction to why we feel that this is a relevant topic. We are going to talk through a little bit of Tristan's picks. In other words, looking at the Perspective feature set, Tristan's topics in terms of planning and design, when you typically approach projects, and what you consider to be the most important features, Tristan. We're going to share a practical planning checklist or link to a practical planning checklist as soon as we're done with this presentation. But for now, around the areas of design and layout, security and role management, and data and scripting, Tristan will share, in your experience, what you found to be the most valuable and time-saving when we put together these projects or design these projects.

01:35
Jaco: And then, of course, we'll have an opportunity at the end to cover some Q&A and any relevant questions that anybody may have, watching. Alright. Introduction. So when we talk about Ignition Perspective as opposed to Ignition Vision, it really is a very different visualization module. And the way that we approach the design and planning is very different.

01:58
Laura: Needs to be completely different.
02:00

Jaco: It has to be. It demands to be completely different.

02:02 
Jaco: For sure. And when you design Perspective, you could absolutely right out of the box, very quickly and easily, which is one of the key features, the ease of use and the design ease use, right out of the box, start building very quickly and easily. But having a plan of attack would really help you to, as we mentioned earlier, not only use Ignition to its full perspective, sorry, to its full capacity, but also save you valuable time, especially when you get closer to going live, as part of your project when time is then no longer available. So maybe to kick it off, we will be, importantly, before we get into the details of the features versus checklists in planning, part of the presentation, we do wanna quickly talk about server sizing and architecture.

02:51
Laura: And actually how important it is.

02:53 
Jaco: Yeah. And typically, when you start planning and designing, sorry, when you start with designing your project, server sizing and architecture is something you would've done already a little bit. So we're gonna touch on that, and then we are gonna look at the areas of design and layout, security and role management, and data and scripting. Happy with that?

03:10 
Tristan: Yeah, I'm happy.

03:11
Jaco: Is that what you typically do?

03:13 
Tristan: Step by step, exactly.

03:17
Jaco: So, before we jump into that, Tristan, could you maybe give us an idea of, so you design in Perspective, that's your preferred module or preferred visualization?

03:27
Tristan: Yeah, so maybe from some background from my side, I joined Advansys, which is the local SI here in South Africa, in 2020, beginning of 2020. I had no experience in automation whatsoever. Didn't even know what Ignition was or any other SCADA factors for that matter, but immediately fell in love with it and how easy it is to actually build something that's powerful, functional, scalable, and it's just so easy. So I think today, what we're gonna unpack is some of the things that I've learned over the past two years that will help you kickstart your project on a better note than I would've at the beginning of my career.

04:10
Jaco: And I'm sure most of us will probably find it... For those of you that are watching, some of you have never even opened the designer, or worked with Perspective, and some of you may have done that already with a couple of projects or a couple of attempts. So, your insight and your practical experience, and feedback would be valuable. So when we look at server sizing and architecture, so the first thing to note on Ignition is that it runs very light. We are very often… People who share the system server requirements and demands as far as hardware and software goes are usually quite surprised in terms of how light their requirements are. But a very important thing to note is that yes, there is a system, a server sizing guide, an infrastructure guide available, which you've referred to that guide as your bible.

05:04
Tristan: Yeah. One of the first things a client always asks is, what hardware am I gonna need to... What am I gonna run my Ignition on? And in the beginning, it was really hard to thumbsuck a number for them. Because for us, Ignition was very new, and we didn't know exactly what its capabilities were at that stage. But then we found this server sizing guide, and it's literally the first thing that I open whenever I start a project, just to point me in the right direction and give the clients an answer to the question that they'll definitely have for you.

05:38
Jaco: So, when you open the guide, for those of you that have never seen the guide, when you open the guide, one of the very first things mentioned in the guide is that the server sizing, and the associated performance of that server, very much depend on a couple of factors which we've listed over here. So there would be some of them, perhaps obvious, and some of them are not so obvious. The number of device connections. Remember, device connections are actual PLC connections. It could also be SQL databases that you're connecting to and pulling information into, the types of PLCs, multiple tag providers. You're not limited with Ignition in terms of the number of connections you can create. The number of tags, very, very important, very crucial. When we are talking about the historizing of tags, as well as the resolution that we historize them at, all of those are very, very important considerations.

06:34 
Tristan: I think that the key thing about how all these things tie together, though, is tag changes per second. So, the number of tags will inherently increase the number of tag changes a second that the gateway has to handle. However, if you can optimize the rate at which you do your tag polling or how often all these tags are changing, you can greatly increase the performance of your gateway while still having tens of thousands of tags on a single gateway. And I think that's something people tend to forget about. You might have a hundred tags, but they all change so quickly that your gateway can't handle it compared to one that's optimized for that.

07:14
Jaco: And when we're talking about architecture specifically, I think architecture is very well known, or at least the Ignition architecture is very well known in terms of, first of all, being server-based. And then, second of all, potentially a hub-and-spoke kind of architecture with some redundancy. But I think the one, the lesser known or the lesser deployed one is probably the sort of front-end back-end, node-sharing architecture.

07:40
Laura: Like having a gateway for your front-end clients and then one for your IoT devices, for example.

07:47
Tristan: Yeah. We're busy implementing one of those on our projects currently. And the reason we ended up going for it, it's because you're in a situation where you might not have that many device connections and tags, but you do have hundreds of clients. So in order to offset that, you make sure that you keep all your tags in one place, that there's one single place where your front-end can fetch the tags from, keeping them in the back-end, but then you have two or more beefier front-end gateways that handle the client load itself rather than just the tags. So I think once you start going to the scale of architecture, it's when your client requirements are more than the device requirements that you have.

08:30 
Jaco: Cool. And, of course, when we're talking about clients, we are referring to concurrent visualization clients.

08:34
Tristan: Yeah, Perspective clients. Yeah.

08:35
Jaco: Which are, of course, unlimited as well.

08:37
Jaco: Cool. So again, there is a server sizing and architecture guide, Tristan's bible, his departure point for any new project. We will make sure to give you a snapshot view or a link towards the end of that presentation. Alright. So the Perspective features there. There's a fairly long list of Perspective features which seems to grow with every new release, version release. And when we're talking about features, we're not only talking about functions or usability features from a client point of view but very specifically from a design point of view. So when we design in Ignition, there are some features that are phenomenal to enable quick design, time-saving, and also quality. So, we call this Tristan's topics. Any reason why we did that, Tristan? I know these top three that you focus on most. Can you maybe explain to us why?

09:33 
Tristan: Yeah, so I think the main thing behind these three points… So I was trying to decide on the three main concepts used in Perspective that you need to iron out before you actually start your project, the reason for that being it's so hard, and it's so much effort to go back three months down the line. You realize you've made a small error, and now you have to go back and fix it everywhere. Whereas, if you think about these things just for a few days before you actually start your project, you'll end up saving yourself a lot of time, and it just gives you that platform from which you can really design a robust solution. I think… Let me talk about these three points sort of together. Where I wanna start with this, how I used to start with projects, and how I start with projects now, and why these three are so important to this way that I approach my projects nowadays.

10:30
Tristan: In the beginning, since Perspective was just so easy to use, I would get a requirement from a client, and now I'd say, “Okay, I need to do this. I'll build this view to do that, now they need me to do this, I'm gonna build a view for that. Now they need me to do this, I'm gonna build a view for that.” And three months down the line, you now have 10 different views, all with their own style classes perhaps, but they don't really talk to each other. You don't really plan that.

10:54
Jaco: Yeah.

10:54
Tristan: You get to a point where you realize you've used three of the same embedded views on all three of your views, but you made three separate ones for each of them. Small things like that. Now every time you need to make a change, you have to go back to every single one of those views instead of just one.

11:11
Tristan: So from that, we get to my first point, which I put at the bottom and sort of links to containers, is the embedded views. So before you even start with the project, the first thing that you do in Ignition is you create a view and it gives you an option. There's five different containers. Now, they are extremely important because they sort of determine what your view is going to look like, how it's going to behave in the front-end.

11:38
Laura: How it's gonna scale, how it's going to adapt, etcetera.

11:42
Tristan: Exactly. And depending on your client, you know what sort of screen that they're going to be requiring. Is this thing gonna be able to be usable on my phone? Is it just gonna be an HMI? Is it gonna be some oke in his office on his laptop screen? These things you need to know beforehand so that you know which kind of containers you need to be using. Now, I'm not going to go into detail about the containers themselves. I just wanted to put this point there to say it's important to think about them because you can't go back and change a container after the fact.

12:13
Jaco: Yep. Yeah. Yeah.

12:14
Tristan: It's the most annoying thing on the planet. On the embedded views point, the reason I put that there is back to the whole time-saving idea. At the end of the day, you want to meet your client's requirements in the deadline that they have given you, but you also need to make sure that you give them a proper solution. Now, at the end of the day, you're gonna make sure you meet their functionality requirements, however near as possible, but the amount and effort required can be greatly reduced if you just think about how the views are gonna fit into each other. So the first thing that I do on every project is before you even open Ignition, you just start drawing the views that you're gonna need. I don't know there's a way for this, apparently, it's wireframes.

13:03
Jaco: Yes.

13:03 
Tristan: But you literally, on an A4 piece of paper, start drawing all the different views that you need to do. In an ideal world, you would do this with your client, discuss how exactly they want a button where one functionality needs to be required, how the person's… How the user's going to navigate the project. That's an extremely important first step.

13:26
Jaco: Do you find that they often have a very good view of that or no specific idea at all, and that's sort of left to you to design, or come out?

13:34 
Tristan: So it definitely depends on the clients. First prize is that the client actually hires a UX or UI design team to give you a PDF document showing you exactly what they want. And that's really nice because it will include the exact colors you need. The exact fonts.

13:51
Jaco: Okay.

13:51 
Laura: So it's like the themes and style...

13:52
Tristan: Exactly.

13:53
Laura: Included as well.

13:54 
Tristan: Pretty much given to you from the offset, which allows you to plan a lot easier compared to other clients who they sort of know what functionality they want, but they don't really know what it wants to look like. In those cases, I still recommend floating the idea of sitting with them, regardless of how long it takes to really just, with a pen and paper, look at what you want the overall UI to feel like. The main benefits for this are you now get a better view of what kind of views are going to be required in your Ignition project. And once you have that, then you realize, hang on, I use this export button on five of the different views that we've just drawn up. Instead of me making five export buttons, I'm going to create one export button, you've now eliminated five extra views that you wouldn't, that you just don't need to create anymore.

14:50
Jaco: Yeah.

14:51 
Tristan: And not only have you saved the time on building that view, but if you ever need to make changes to that, you only need to make it to that view, and all of a sudden, your entire project has got that update in it. Once you're done with these wireframes, then you can start get cracking on your themes and styles, as well as the actual layout of all your views.

15:11
Laura: So this kind of goes hand in hand with pretty much our checklists, right?

15:18 
Jaco: Correct, yes, it does.

15:18
Laura: Having...

15:19
Jaco: Yeah. So the checklist that has been developed actually by Inductive Automation, which is another one of the key documents that any new developer or any new designer would find very valuable, is planned... Sorry, is designed specifically around those three areas of design and layout, security and role management, and data and scripting. So when we look at that checklist around the areas of design and layout, you mentioned wireframes as quite an important aspect of understanding what it is that we actually have to build for, as opposed to just starting to build something. How often is mobile... I would imagine mobile is a consideration?

16:06 
Tristan: Yeah, so I think most of the time, once you tell a client, listen, Ignition can do mobile stuff, they're like, great, let's just do it. They don't necessarily have exactly in mind what they would want that mobile to look like, but they have expressed interest that, in the future, it may become a requirement. And in those cases, you still want to plan your project so that it can be mobile-compliant when the need does arise. You don't want to go back to your project and just redesign everything because now, all of a sudden, it needs to be put on a screen. So it's always best to first identify if it will ever be a requirement, and even if it's a thought, just put it as part of your project. It's not going to change anything in the grand scheme of things. It will just give you that flexibility to immediately switch it to mobile because you did that planning at the beginning of your project.

17:00
Jaco: Cool. Anything else under design and layout?

17:05
Laura: Yeah, I'm thinking now about… I know you mentioned it's also very important to have graphic design standards in the sense of, like you mentioned, creating a button that's being used everywhere. So it makes sense to have all your buttons look the same, to have the same typography throughout. So it kind of goes hand in hand with the styles and themes, but how important have you realized that is? I mean, I'm talking also about specifically, like I know certain people like to have certain types of symbols, certain colors, bringing in their own symbols. No.

17:39
Tristan: So customers can be very pedantic, and rightfully so, about their symbols, their colors, their... What they want things to look like. And that's why it's so important to just get that done in the beginning so that any new view that gets made, regardless of who's making it, has access to the same set of styles, the same set of symbols that the client has requested to be part of it. So I think the two key aspects of that are firstly the style classes themselves because those house the color palette of the business that you're creating this project for, making sure that those colors are in the styles. And even if those colors change, as long as you've built the styles around them, it allows them to change their mind if they want to, but at least you have that starting point. And the reason that's so important is when you get to a point where multiple people are working on a project, you don't want them all referencing slightly different colors that, "Oh, that's sort of yellow, but it's not the exact right yellow." And now you have to go back to your project, and you need to slowly and meticulously find where you used the slightly incorrect yellow.

18:49
Tristan: Whereas if you had just decided on all your styles in the beginning, everyone uses those styles, it creates a consistent UI throughout the project that you don't need to worry about. And once that's out of your mind, and you don't even need to worry about it, you can spend your time getting the actual functionality that's required into your project without having to worry about the UI look and feel because that's already been thought about.

19:17
Jaco: There's also a big… A big aspect of this is, let's call it familiarity. So very often a business would have a very well-defined corporate identity, which includes things like colors, logos, icons, style, style guides. And why that is important is because, typically, every application within that enterprise or that business would aim to incorporate that to create that consistent look and feel.

19:41
Jaco: So if you have something as crucial as your Perspective screen that is used by an operator, or a supervisor, or a manager, whichever role in the organization, that consistent look and feel also aids to, “Hey, this is something we understand. This is something we know, something that we're familiar with.” If it looks completely different, there is the risk of not feeling comfortable with that application as you would with any other application.

20:06
Laura: Yeah. That's usually the start into the sense of where they would come back and say, “No, we reject this because our operators don't like it.” And that's also why I love the Perspective branding. That's brand new.

20:17
Jaco: That's new. That was added fairly recently, is the custom branding options.

20:22
Laura: So that's also cool like enabling that styling and scheming and everything throughout the whole gateway, throughout all of your projects, which is cool. Yeah.

20:31 
Jaco: Yeah.

20:31 
Tristan: I think another really underestimated part of it is that depending on how big the client is, you also get to a point where it's not just that first project you did with them. It leads to multiple new projects. And you want those new projects to also have the same look and feel as that original one that you went with, to form part of that corporate identity that they now have. And if you didn't figure out your classes, and your symbols, and your fonts, and everything in that first project properly, all of a sudden, you get to your next new project, and it's square one all over again.

21:07
Jaco: All over again.

21:09
Tristan: And it's just unnecessary effort that is easily avoidable if you had just spent the extra few days planning this sort of thing.

21:15
Jaco: Cool. Should we go to security and role management?

21:18 
Laura: Yes.

21:18
Tristan: We have to.

21:24
Jaco: So security and role management. So typically when we think about security, we think around, alright, who do we need to give access? What do we use to provide access to them? What are their identity? So there's a couple of things. Identity providers.

21:37
Laura: Security zones.

21:39
Jaco: Security zones, user types, and associated access or views.

21:45
Laura: User groups.

21:45
Jaco: Is that typically provided to you on a list or how is that typically defined or built in the project?

21:53
Tristan: So, for most of our projects, the security is more defined by who can access what on the PLC.

22:01
Jaco: Okay.

22:01 
Laura: That's interesting.

22:02
Tristan: So most of the time you have, in a typical project, you would have an operator and an engineer. Engineers are the ones that are allowed to change set points and things like that. The operator can turn the motor on and turn it off. Things like that. And most of the time, that's where our security lies, on the tags themselves. So you create the security levels, you would create one for engineer, you would create one for operator, and then in your UDTs, you would make sure that that security has been applied to those tags so that when someone tries to change a tag that they're not supposed to be having access to, it actually gets blocked.

22:42 
Laura: I like that. I like the fact to add the security to the UDTs themselves.

22:45
Jaco: Yeah.

22:46
Laura: 'Cause not a lot of people think about that. They're like, “Oh, these tags need to be, have security on it.” And they don't think about what can happen in the future. And if you add additional motors, additional tags, to have that automatically added to that as well.

23:00
Jaco: And if UDT provides you, sorry, user-defined types, if it provides you with that kind of ease of use or extensibility, why not add the security view to that? Yeah.

23:10 
Tristan: No, exactly. And I think at the end of the day, the bottom level of any SCADA is those user-defined functions, your tags, your UDTs. And once you have the security in place there, even if you forget to add security to a view in Perspective, it's not gonna break anything because you know that right at the bottom level, someone's not gonna be able to change something they're not supposed to be able to change. Yeah, I think that's... No one really likes to talk about security, but it is just so important because if you don't do it in the beginning, you're gonna have to go back and you're gonna have to add it and spend the time to do that, when it could have easily been avoided.

23:49
Laura: Yeah.

23:49 
Jaco: Absolutely. There is also a very useful security hardening guide. So we're not security experts. I think in our world, security experts are… It's a specialist area or a specialist field. We're not security specialists. There is a security hardening guide that is also very useful, that we can make available.

24:10
Tristan: I can tell you from personal experience that, as somebody who studied mechanical engineering, security is seen as more of an IT thing. And it was this abstract concept. I had no idea how these things were even implemented. The word would just terrify me. And when you start seeing the word “security zone,” “security level,” I mean, what on earth do those words mean? But that hardening guide just is a comprehensive… I think it's like 30, 40 pages, but it really goes through all the detail and explains it perfectly.

24:41
Laura: Step by step.

24:42 
Tristan: Using that in conjunction with the manual, which is also my bible because that...

24:49
Jaco: So security from your side when designing would be an understanding of... Would it be Active Directory authentication for example?

25:00
Tristan: Yeah.

25:00
Jaco: Or addition, adding...

25:03
Tristan: So I know that Ignition allows you to have identity providers, external to...

25:09
Jaco: A few… So, yeah.

25:11
Tristan: Yeah. In South Africa, it's not really a thing. Most of the time, an IT department of the client has put in place an AD, and you just access the AD, and you use that for your security. I would say 90% of the time, that's how we do it. Otherwise, it would be a small internal one to Ignition itself. I think those are the two main ways we actually go about it.

25:34
Laura: And it's cool 'cause it's also like very user friendly to set up.

25:37
Jaco: It is.

25:37 
Tristan: Yeah.

25:38
Jaco: Yeah, 100%.

25:38
Tristan: And for someone who doesn't like IT, I don't need to worry about anything. I just connect to AD, there are all my roles. It's all done.

25:49 
Jaco: 100%, and probably… Not that either party is sitting on the other side of the fence, but I think we'll leave the specialist areas to the specialists where it counts, leave the engineering and the PLC and the PLC work and the designing to us and let them handle the security. But I think Ignition is incredibly flexible and accommodating for and inclusive of the number of identity providers and authentication methods.

26:13
Laura: Yeah. They provide the needed security for your Perspective projects or your over-web application.

26:19
Jaco: Cool. We're gonna talk about data and scripting. Laura, maybe explain to us… What does that mean? Scripting is of course... I think a lot of people have a love-hate relationship with scripting.

26:32
Laura: True, true.

26:33 
Jaco: Especially with the Ignition that provides for an incredible amount of power.

26:37 
Laura: Yeah. Added functionality.

26:39
Jaco: And added functionality.

26:40
Laura: That you know Ignition can provide you with. And I think a lot of people think, “Oh crap, now I need to be a coder, I need to be a software developer. I can't do anything 'cause I can't code.” And it's not true at all. As you guys probably know, you can code in Python in Ignition, and because Ignition is written in the Java environment, it allows you to include the Java libraries and script in Java as well. I do not recommend jumping into the Java side.

27:08
Jaco: Tristan, have you?

27:11 
Tristan: I have. I must say it's quite a different world, but I have.

27:14 
Laura: Would you prefer Python rather?

27:17
Tristan: Oh, 100%. I think the only time I've ever needed to use Java is because they have encryption-type libraries that Python don't have. Yeah.

27:26 
Jaco: But it does make it very powerful.

27:29
Laura: Oh yeah. Like I said, you can do things you never imagined.

27:32
Jaco: Yeah. But it's certainly not that of an intermediate. It's more of an advanced…

27:40 
Tristan: Yeah. So my view on scripting is that in my mind, Perspective can do literally anything because I have access to scripting. The trick actually becomes, since scripting is so resource intensive, you need to be careful when you use it.

27:55
Tristan: So even though I know that I can do something using a script, maybe think of a more sleek way of getting the same functionality without compromising the functionality itself or the performance. But without needing to use the script. Because it's just unnecessary things that the gateway needs to spend its time doing, when it could be avoided if you use something like the Ignition expression language, which Inductive have, or consistently let us know that expressions run way faster and use way less resources than the scripting. So if you do find a way to finish something, use an expression or a map transform or something like that, then use that. Otherwise, use the scripting. It is extremely powerful, but don't just immediately default to it. Otherwise, you're spending unnecessary resources.

28:46 
Jaco: Because you can.

28:46
Tristan: Yeah. Which is what I used to do, because why learn the expression language when I already know Python? But it's very important to...

28:56
Laura: To make sure you know your options.

28:57
Tristan: Yeah, exactly.

28:57
Laura: To make sure what will work best. Especially when it comes down to the performance and your gateway needing to carry all that load.

29:04 
Tristan: Indeed.

29:04 
Laura: And I've realized a lot of these things can actually be handled through added modules or specific containers. Not containers, components, etcetera.

29:15
Jaco: Yeah. And there is also view around scripting, there is also view or an opinion at least that scripting, if not done correctly, just adds to your technical debt, making, sort of putting that entire application design under a little bit more risk depending on what happens in future and the ability to support that code that was written five years ago.

29:34
Tristan: 100%.

29:34
Laura: Quick question. Have you, probably you might have, have you written like a script that used like mobile devices features to import types of data? I'm talking about... Okay, that sounds like very technical. I'm talking about like writing a little script. Say if I open up my phone and I wanna scan a barcode, what am I gonna do with that barcode? What am I gonna do with the data? Uploading a picture, doing something like that.

30:02
Tristan: So, I have done profile pictures before, which is actually quite easy. I did kind of cheat though. I store the image in a document tag instead of using...

30:15 
Laura: That's a tip.

30:15
Jaco: That's not cheating, is it?

30:17 
Laura: That's a tip.

30:18
Tristan: Well, it's because the recommended way is to use the Web Dev Module to store files on your gateway, for things especially like PNGs and that sort of stuff. But again, Ignition can do anything, so you could just store it in a document tag if you want.

30:34
Laura: So that's his experience.

30:36 
Jaco: That's a good tip.

30:38
Laura: That's how he targets it from his side.

30:40
Tristan: Don't make your image too big though, then your whole session slows down. But yeah.

30:45 
Laura: Another tip.

30:45
Tristan: As far as the barcodes are concerned, I think I actually sat with you guys right at the beginning when you were doing training as sort of a proof of concept of Ignition when you actually use the barcode scanner to scan someone's administration or proof of registration to the training. And that's how we would log them on our, all the Element8's internal database. So that was quite cool.

31:12
Jaco: Yeah, that's right. Anything else on the data scripting? I know it's the least sexy part of design.

31:20
Tristan: So I think the one thing I will say about scripting, in general, is that, since it is so important to make sure that now that you're the one that's making these functions and you need to maintain them, you need to make use of the scripting library part of Perspective where you can call a function using, similar to how you go system dot, Perspective dot, open pop-up, you now have a section for your own custom scripts. And it's important to keep those all in one place so that you maintain them in one place and that all projects sort of point to that same scripting library. Because you don't wanna make the same script three different times with three different projects if you know you're gonna need them for those projects. So it's definitely something to keep in mind. You don't wanna duplicate work for yourself. Because if someone realizes they need to change that script, you now need to go to five projects to change it instead of changing it in one place. A single version of the truth is always important.

32:19
Laura: I like that.

32:21
Jaco: Cool. So we've spoken about design and layout. We've touched a little bit on security and role management, and we've alluded to some very powerful options, but not necessarily preferred around scripting and data management. So as far as the planning or the layout of a Perspective application goes, we would typically say we design it... Well, sorry. We plan it, we design them both. You've alluded to something which we haven't spoken about at the beginning of our... Just before we actually started recording. And you refer to it as quality of life...

32:58
Laura: Improvements.

32:58
Jaco: Improvements. What does that mean and why is it important?

33:05
Tristan: So I think when I first started projects, as I said, I was very set on making sure that it works, the functionality is there. I don't mind what it looks like as long as it works, and the client can be happy because it works.

33:19
Laura: Real engineer thinking, hey?

33:22
Jaco: Function over form.

33:23
Tristan: Exactly. So in order to force myself to make sure that I take those other considerations into account because they are equally as important, I started doing things like planning my styles beforehand and planning these views beforehand. Now that I have that in place, what it's allowed is that when you get towards the end of a project, there's no crunch time to quickly fix everything to make sure it works. You've got all your styles in place, you've got your consistent UI in place, and now you have the time and the luxury to add these quality-of-life improvements where you finally have the time to change small things that you wouldn't have otherwise even thought of because the deadline's tomorrow. Now that you've planned in the beginning, you have all this extra time to really take your project to the next level. And that's what the quality-of-life improvements are about.

34:13
Laura: It's like resizing a table.

34:14
Tristan: Yeah. If something doesn't quite size properly on the one screen, or maybe this font size is a little bit too small, or I don't really like the layout of this particular view, but since I've made sure that this embedded view is consistent everywhere, I can change it now. And it quickly updates the project without breaking anything. And you really have that time to just tie up all the loose ends, and when you give it to your clients, it's now really elevated it to that next level where they're like, “Wow, this project looks amazing, and it's functional.” Not just functional, which is what I used to do.

34:50
Jaco: Cool. Yeah, I like that. And I think it's a very important aspect of design and the final product that a lot of people don't consider, don't think about.

34:57
Laura: Yeah.

34:58
Jaco: Alright, so as we discussed, we've got a couple of really useful, or there are a couple of useful resources available that you can get today. Right now, available...

35:07
Laura: On the Inductive Automation website.

35:09
Jaco: On the Inductive website. The first one is Tristan's bible, the “Ignition Server Sizing and Architecture Guide.” Very, very informative and quite detailed in terms of not only what to consider but actually what to deploy as far as hardware and system requirements go. Really, really good guide if you haven't seen that. The “Perspective Planning Checklist” is a very practical checklist. Item by item are the most important things to consider, which is what most of... Is most of what we've spoken about. A phenomenal series, “Design Like a Pro.” And I think… I can't remember how many videos are in the series. About six or seven.

35:49
Tristan: Yeah, I think it's about seven.

35:49 
Jaco: Seven videos in the series. Again, you mentioned these earlier. You're probably the first to view the entire series in South Africa, the first person from South Africa to view the entire series. But again, very practical and useful. And then the other webinar was “Common Project Mistakes (And How to Avoid Them).” Also, very very informative and practical.

36:14
Laura: Yeah. Especially for HMI design, scripting, and so on. All those things you don't really think about when you design something.

36:21
Jaco: Yep. Do you have any common project mistakes that you've made and how to avoid them?

36:28
Tristan: Let's think of one.

36:29
Jaco: Just one.

36:30
Laura: Like, I'm so perfect, I don’t make any at all.

36:30
Tristan: I think naming conventions is something that people don't talk about enough. At the end of the day, you need to make your project, its tags, and its views need to have a structure that is easy to understand so that I'm not the only person that understands it. I can give it to my colleague, John, and he can understand it because it's got a structured layout that makes sense. And a big part of that is the naming convention.

37:02
Jaco: Naming convention is almost like a language on its own.

37:05
Tristan: Yes.

37:05
Jaco: That if you can't speak it, you're lost.

37:07
Tristan: Exactly.

37:07
Laura: You know what I've realized? It's not only just with tags, it's with your window names, your directories, your script names, everything you do, have a naming context.

37:15
Tristan: Even things like the names of your functions. What we started doing is you keep all your functions in a scripting library, but some functions you use on views, and some functions are just called by other functions. Now, to differentiate that, you... Well, what we do is if it's got a capital letter, then it's global and it can be used by anyone. And if it starts with a small letter, then it's only used within the scripting library itself. And small things like that, just when someone sees a new project for the first time, and they're trying to debug something, and they can immediately see, “Oh, this function's only used by other functions within the scripting library, so I don't need to worry about breaking anything.” Small stuff like that, even like where to put your custom properties, is something to think about.

38:02
Tristan: You don't want to hide your custom properties on the very bottom component of a view. You wanna keep it near the top so that it's not in it in any way. So if someone needs to debug something, he's not gonna spend three hours trying to find where the problem is. Small stuff like that is just being efficient with your time and making sure that you don't make it hard for someone else to look at your project as well. At the end of the day, you're not gonna be on a project for its entire lifetime, and you don't wanna leave it in a place where you need a degree and Tristan to figure how a project works.

38:39 
Jaco: We're interested now. Cool. So these are four really practical and useful guides and articles that we've... This is really the ones that Tristan handpicked. If you are completely new designing and working in Perspective, but also if you maybe have been working in Perspective but were perhaps not even aware of some of these guides and these webinars. So, useful, practical. Let us know what you think about it. Thank you very much for your time, Tristan.

39:08
Tristan: Thank you.

39:09
Jaco: That was valuable, insightful. We look forward to your new blog.

39:13
Tristan: Tristan Speaks.

39:14
Jaco: Tristan Speaks, the weekly or monthly tips by Tristan. I think it will be helpful for the rest of the community, especially for people that are just starting off. So maybe we can make that a reality.

39:27
Tristan: I’d be game.

39:29 
Jaco: Okay. Cool. We'll do that. Thank you very much for watching. Hopefully that was insightful. We wanted to make it a little bit more informative and enabling.

39:40
Tristan: Concept based.

39:43
Jaco: Concept based, not from our side, but from somebody like Tristan.

39:45
Laura: That works with Ignition every day.

39:47
Jaco: Every day and designs and builds projects in Ignition every day. Hopefully, that was valuable. Let us know if you have any questions. Otherwise, feel free to contact us directly, including Tristan. His contact details are shared as well.

40:03
Tristan: Oh, is that so?

40:04 
Jaco: Absolutely. If you have any ideas or questions, I'm sure Tristan will help you and provide you with his invoice at the same time.

40:14
Tristan: Yep.

40:14
Jaco: Tristan, thank you for your time. That was...

40:17
Tristan: Thank you so much. I enjoyed it.

40:19 
Jaco: Cool. We will see you then for ICC...

40:23
Laura: 2023.

40:24
Tristan: I've already applied for my visa.

40:27 
Jaco: 100%. If we were fortunate enough or some of us were fortunate enough to be there in person at the in-person ICC, which was last week. Sorry, two weeks ago, two weeks prior. Phenomenal experience. Definitely recommended for our South African community that have considered attending. Can definitely recommend it as a very, very valuable event. So hopefully we can see you and all of you there next year, ICC 2023. Thank you very much.

40:58 
Laura: Cool. Cheers.

41:01
Tristan: Cool. Thank you.