Separating Design From Development - Using Design Tools with Ignition

Speakers

Doug Yerger

Principal Engineer

Grantek Systems Integration

Building screens in Ignition is a breeze, but did you know you can design screens even faster by mocking them up using a design tool? Join us for this session as we talk about the benefits of moving the design process outside of a development platform. We'll cover topics such as design vs. development, UI vs. UX, benefits of using design tools, and an introduction to the design tool Figma.

Transcript:

00:09
Rob Lapkass: Alright, welcome back from lunch, everyone. Let's get started on this afternoon session, shall we? My name is Rob Lapkass. I'm a Training Content Creator here at Inductive Automation, working on Inductive University. I'd like to welcome you to today's session, "Separating Design From Development - Using Design Tools With Ignition." I'll be your moderator for today. To start things off, I'd like to introduce our speaker today. Doug Yerger is a Principal Engineer at Grantek Systems Integration. Doug's 30-plus years of experience includes the architecting, design, implementation, commissioning, and support of PLC control systems, robotic applications, Vision applications, database applications, MES implementations, warehouse management systems, SCADA systems, and HMIs. Doug serves as a leader within Grantek, providing governance, technical direction, and facilitating knowledge propagation. Please join me in giving a warm ICC welcome to our next presenter, Doug Yerger.

01:27
Doug Yerger: Thanks, Rob. As Rob mentioned, my name's Doug Yerger. I'm with Grantek. And before we get started, I just wanna cover a couple terms we're gonna go over today: design and development. But what actually are those terms that we're referring to? Design is your look and feel of your user interface. In the industry, they usually call them UI and UX in the web industry, and that's the user interface and the user experience. So these are gonna cover things like your theming, your screen layouts, navigation, also including things such as what's going on each screen, what's the function of each screen, what type of numeric indicator you're gonna use? You want analog gauges? Do you just want a numeric display, spark lines? Anything like that. But also that user experience is all your user workflows. So, what is the purpose of each screen? What are you trying to do and what is the user trying to accomplish on each screen?

02:37
Doug Yerger: And development is building the application itself, so constructing the screens, tag creation, device connections, scripting, setting up databases. All of that is the development. So that's the building of the application, and the designing is actually creating the ideas of what you're gonna want to do in there. Some of you might be asking, "Well, why are we going to split them?" We had similar thoughts at Grantek, but at some point, we had had enough pain points that we decided we really needed to split them. I'm gonna talk a little bit about Grantek's journey, and you can see how well it matches up with yours. Prior to adopting Figma, which we chose as our design tool, we did our designing, excuse me, within our development environments like Ignition.

03:24
Doug Yerger: We found this led to a number of inefficiencies, headaches, overruns, and missed opportunities. One of the first things we identified was rework that we had to do from undocumented or late request. In some industries, especially those that work without detailed function requirement specs and FRS, or design specifications, or DS, we would reach the 60%, 90% review cycle, and someone would bring up a major item about the user workflows that was not documented anywhere and hadn't been talked about. This often required major rework of the screens, often breaking bindings. I mean, we've all moved things one container to another in Perspective and had to rework them all. So breaks those bindings, and there's a lot of rework from those.

04:14
Doug Yerger: And of course, the project manager's inevitable discussion on whether we need a change order or not for those changes. One project in particular comes to mind for this. We had a customer that was migrating a process. They had a very manual process. It had been a product development. They had developed it, but it was very manual, and basically, the initial project was migrating an access database that was tracking their product into a SQL server with a frontend Ignition project. Well, we were very careful to make sure everyone was in the meetings by asking the customer who was in the meetings, and the customer even canceled some meetings just because people weren't available. So we thought we were doing all that due diligence. We went through there, the project grew through those discussions, adding in things like we're recording test measurements, product validation, and even the shipment processing and interfacing to their ASRS systems.

05:18
Doug Yerger: Well, we're going through all that, all those... Quite a bit of rework during those, but they were all covered by change orders because they changed the function of what was going on, and growing it. We get to the 90% review, a pre-SAT review, and they brought in someone from their quality group that was gonna be responsible for setting up and qualifying each production run. Well, this person went through and said, "Well, these are the steps we have to follow to qualify this." And it meant they had to put things on three different screens, and was all over the place in our application because those were the user workflows we had already discussed and had worked toward. It made a lot of late work in our process. So, put this on the top of the list here because of that. Next point is, if you're doing gap projects, and I'm sure you've all experienced this, part of that is doing your design specs.

06:21
Doug Yerger: Well, when you're doing your design spec, you often need screenshots of what the things are gonna look like, so you can talk to those points. Usually, our engineers, sometimes they use Paint, sometimes they use other applications, but 90% of the time, they would just go into the development environment and mock-up the screens. And that's always creating dummy tags and things like that to keep from overlays, wire framing, or anything else so you can get a nice, clean screenshot. This led to two potential issues. First, we have to rework everything now because they're on dummy tags and not production tags because those are all defined in the DS and have to be approved and worked through. And second one, technically, it's violating the gap process 'cause you're not supposed to be starting development until the design's approved. One other feature that we've experienced with this is since we're doing those designs in a very nimble editor, when the DS does go through revisions and there's changes, it's very quick to update it because it only takes a matter of a few minutes to update versus going in the design environment, moving things around, and getting things working again.

07:41
Doug Yerger: Another pain point is when customers acknowledge they wanted to work through all of their workflows and basically have a discussion saying, "Well, what are we gonna do?" We don't really know exactly what we want the user to do in here. We're gonna develop those as we're doing the project. Well, since you don't necessarily know what needs to be on each screen, how do you start developing? Well, good example of this was an internal solution we had. We were migrating an IIS web-based solution to Ignition Perspective. One of the things we identified in that IIS solution was that the user workflows often started right-hand tab, working your way across to the left hand to put in new products. The workflows weren't very intuitive. You had to know what you were doing to even use the product whatsoever. Well, we said we wanna fix that because, the way we were designing, the way we had to use it is you had to build from the bottom up for all your products.

08:45
Doug Yerger: Instead, the customers always wanted to build from the top down. They have a finished queue, which is at the top of that architecture, and they wanted to always build down, but our system was forcing them to go the other way. So we said, "Okay, let's go ahead and design a whole new user workflow." Well, the way we went through that is we started... In our design tool, we just literally sat down and typed out what these workflows are gonna be. Just literally sitting down, typing notes as we went, writing our design tool of what they were gonna be. As we worked through those, we started coming up with little bit of a thing, saying, "Well, what do we think about this idea of structuring them this way or that way?" And there were several slides like this, of different ideas of what to do. That grew into a more formal one as we went. And then the final design of what the end project looks like. This project is still in our design tool. This is not in Perspective. And just a quick side note, you'll probably... If you can actually read the iChart up here, it's actually showing Oreos. We just chose that 'cause everyone knows Oreos and likes Oreos, so we use that as our demo product as we're going through this.

10:12
Doug Yerger: The final pain point we have are true Agile projects that basically there's not a final goal set in a true Agile project 'cause it's whatever you're using for each sprint. Grantek, we've often done what I call hybrid Agile projects. And what I mean by that is, there is actually a functional spec saying what our goal is, but we're using Agile to define our user interface and user workflows to achieve that functional goal. Still falls under this category for me because there's still a lot of changes happening. Each sprint, you're bringing in new features, which cause a lot of free work and things like that. Things to point out on here is, in the middle of the screen, you can see what's called queue. It's the water queue. That started as an actual vertical list in our original designs. We had the issue there is one, it looked out of place on the screen, but it also grew and shrank in size, making things move around the screen, and kind of just was an eyesore on the screen.

11:12
Doug Yerger: So we ended up deciding on this horizontal list of the items in the queue. All those cards are clickable, which would bring up the queue management screen separately to do any reordering or rescheduling that you wanted to do. Another item, it would be that point-of-view section on the bottom. Those are the point-of-view valves that are in the area that this screen would be accessing. And each of those cards, when you click on them, this lower right section is actually a slide-out that retracts or slides out when you click on the card and brings up your... Putting in a manual control and gives a little more status of it, versus the card itself. So those were our pain points, and we acknowledged that these were getting very costly and causing a lot of extra time on projects and things like that. So we said, "Well, what can we do to fix this?"

12:09
Doug Yerger: Well, Perspective is effectively developing a webpage. So we said, "Well, what do they do in the web world?" We looked at that and that's where we got the idea of using a design tool to actually help. We evaluated several design tools, narrowed it down to two, then did very good cost analysis and workflow analysis with our salespeople and engineers in that we did a little survey inside on which one we thought would be better, and we ended up settling on Figma as our design tool. Figma is a web-based, fully collaborative design tool, and whether working in a browser or their stand-alone application, users are provided the exact same working environment.

12:55
Doug Yerger: On the left is a desktop application, which I keep in dark mode. On the right is the exact same design, open in a Chrome browser. As you can see, everything's identical shown between the two, including the two sidebars. Left-hand sidebar is very similar to your project browser and the Ignition designer. It's gonna show your object hierarchy. And most of the pages, if you're on a different screen, it is context-sensitive so it'll show file structures if you're up at the file level versus inside one of the projects. The right-hand pane is like your properties panel. It's going to change very drastically depending on what type of object you're selected. Currently, what you're seeing there is for that one grouping that's selected inside there. As mentioned, Figma is fully collaborative, meaning users work on the exact same design file concurrently. You can actually see each other's cursors and changes in real time.

14:03
Doug Yerger: In this screenshot, you can see in the upper top, there's my avatar picture as well as a "D" next to it. That's telling me Dylan's in that same file that I'm in. So I know he's working in the file, and since he happens to be in the field of view I have in the file, I can see his cursor, and it has his name there. I don't know if you can notice it there. Right here, it's showing his cursor. If this was live and not a screenshot, you would actually see that cursor moving around as he's doing it. For demonstration or training, you can actually click on one of the avatars on the top and your screen will lock to what they're seeing on their screen, so you can follow exactly what they're doing as they work through whatever they're doing to demonstrate or show. Figma allows commenting directly in the designs. So in the screenshot, you can see the highlighted row in that table has a little comment balloon on it. That's obviously saying there's a comment on that item. Up in the task bar, you see a little red dot on that balloon up on that icon up there. That's telling me there's an unread comment in this file. It is file-sensitive, so if I switch to another file, that dot will go away. So it's telling you where you're at on that.

15:30
Doug Yerger: If we click on that comment icon or on the bubble, it's going to bring up... The right-hand sidebar is gonna switch. If you notice on the left there, it's showing those properties, but it's gonna switch to the comments over here. And it's gonna show all the comments in the file in the right-hand bar. If you click on that comment or click on the bubble itself, it'll bring up the comment on the screen. Great feature of it, you can tag users in your organization. When you tag them, it will actually send an email to them notifying them that there's been a comment in the file that needs their attention.

16:09
Doug Yerger: Another great feature on the commenting is you can share these designs with anyone inside your organization, but also anyone outside your organization. Sharing can be done at the team level, project level, file level, object level. And you can share it for full editing access, so you have an extended workforce, so you can share it there. Or, if you're sending it to a customer, you can send it to read-only access. Read-only users still have that ability to comment directly on the file. Great way to share your designs with customers. No more taking screenshots, sending it to them, having them work through what's going on. The layout tools they have, very simple and align with standard web terminologies, so they align with Perspective very well. That makes that transition very simple. In this screenshot of the property panel that shows up on the right-hand toolbar, you can see you have... At the top, you have some alignment tools. You have the sizing, the rotation, corner radiuses, positional constraints as we come down, and then you're actually gonna have text, fonts, as well as the colors that are used within your selection.

17:29
Doug Yerger: Figma has a feature called Variance, which allow you to have one item. You can kind of think of it as a UDT 'cause you're gonna create instances of it. Here, you can see a very large palette of buttons that one of our customers uses. All of those buttons are the same button in Figma. They're all set... Everything on there, you'd put an instance on the page, and to change anything on there is simply a property change within that variant. Makes reusability great, makes the templatizing great, gets that consistency across to all those applications that you're looking for. In addition, utilizing variables and styles allows you to create all those same themes in Figma as well in Ignition Perspective, create user light and dark modes, even have customer versus standard palettes, your own standard palettes in there. And taking that idea along to show you, that upper-left one there is showing, in Figma, our standard color palette. Lower right is a screen we have in Perspective to just kind of confirm they're all loaded properly. And if you notice, all the colors are identical between those two. Little side note. You see the repeating colors at the top; there's two rows that repeat. That's because the top rows are our Grantek standard colors, and then below that are primary and neutral, what would be used in the projects.

19:07
Doug Yerger: If you have a customer that has their own color schemes they wanna use, you change those bottom two ones to whatever colors you want, and it's gonna change... Everything in our designs will automatically change to their color palettes, no reworking each component individually because they're all done by name. Figma's very easy to get started with. As you can see in the top left, there's only a few tools that you're gonna use. It's very simple to get started with, but it's also very powerful, and as you use it, you learn more and more advanced features, so you can get started very easily with it and grow from there. And like Inductive, Figma has a lot of stuff online to track what's doing it. Inductive has Inductive University, Figma puts most of their stuff on YouTube, all out there, publicly available, free of charge. And in addition to Figma's own published ones, there's a great design community around Figma, and you can find... I know I follow at least a half dozen additional design creators that are constantly talking about different uses with Figma and different features.

20:19
Doug Yerger: Figma, just like Inductive, very, very user-focused. They have a user conference that's toward the end of the summer, so just happened a few months ago. And like Inductive, like we saw this morning, announcing a lot of new features that are upcoming and ones that have been there. And I saved what I think is the best on the features. Last is what they call prototyping. What you're gonna see here is this is all within Figma, but prototyping is linking those design pages you've created into a working model. So as you're clicking through here, this is a recording of me clicking through different areas, showing different features, but it gives you that ability to have discussions with the customers and let them see your user workflows. They get to experience it, and they're not having to envision it from screenshots and descriptions. They can actually see it, play with it, and work through them. It's been great. Just like the designs themselves, you can share the prototypes with your customers so they can actually work through them, play with them themselves, give you direct feedback from them.

21:38
Doug Yerger: So when should you use a design tool instead of jumping headfirst into development? Hopefully, some of you have already seen times where you could see a benefit of the design tool, but I'm gonna cover things that I put on the top of our list. First recommendation: if it's a Perspective project, use a design tool. Perspective, as we've mentioned before, is as much a web design as it is an HMI design, so it benefits greatly from using web design philosophies on there. Doesn't mean that you can't use a design tool for Vision. We've done it numerous times on that. But usually, those Vision projects are gonna hit one of the other points we're gonna talk about, so therefore, it makes sense to use it in a design tool. Next one is you have complicated workflows. We always wanna keep that user experience as simple as possible, enjoyable as much as it can be to the user to use, but at least you don't wanna make it work for them to actually use your application. 'Cause you all know, if it's difficult to use, they won't use it. So, excuse me.

23:00
Doug Yerger: So, that means grouping common entries together on the same page, getting everything together as much as you can, getting that workflow nailed upfront, so everyone knows what's going on, and especially the designers themselves, they really get a feel for what needs to be where and going on with that user workflow. Another one is large projects with lots of screens. These projects have a lot going on, and sometimes things that seem unrelated turn out to be related. And once again, those user workflows are gonna go through there. Another benefit on those large projects is when the developers are going in to start on it. Your development team's probably not one person. You're gonna have a team of developers working on different screens. If they have a design to look at, they're all gonna end up having that same look and feel. I'm sure we've all seen SCADA applications out there where all the user workflows are great, everything's there, but some screens just seem a little different than others as you're working through them.

24:08
Doug Yerger: By having a design in front, everyone's working to that same goal and that same look and feel. Next time I would recommend using that design tool is whenever there are unclear user requirements or part of the project is to develop them during the project. We've seen that example earlier where we discussed how we did that with our internal solution, because basically, if you don't have user requirements defined, how can you start development? You're shooting in the dark; you're just throwing things out there. And by doing it in a design tool, you can create four, five, half dozen different ideas to discuss with the customer, and you're not spending all that time to do it in your development environment. You're doing it much more quickly, much more nimbly, and you can make changes very quickly. One example there is we went on a customer site, did a review, and they came back and said, "Well, I really don't like how we're seeing all the building layouts, status of all the building layouts." And on the whiteboard, he drew what he wanted.

25:15
Doug Yerger: The following afternoon, we sent him screenshots from the design tool of the finished design of the updated version, and he was like, "That was incredible getting them turned around that quickly." We mentioned this before when we were talking about things, but if your actual project is to develop the design spec, you're gonna need that documentation, so doing it in a design tool makes those screenshots and everything easy to create, gets rid of a lot of extra work upfront, 'cause you know there are gonna be changes coming when you're having discussions with those customers on getting that design spec approved. Last one, if we consider HMIs at level one, visualization, SCADA at level two, then you have MES, management, and dashboards, and all that beyond that. I would say that SCADA level two and above are always gonna benefit from using a design tool. Not saying we haven't used it for HMIs, but often with HMIs, we'll use it for maybe a simple... To discuss an overview screen to say, "How can we get this clear?" To bounce ideas together. But if it's systems that you've done many times, you probably might not need the design tool and can jump right into development. But that's gonna lead us to our final topic.

26:42
Doug Yerger: Oh, I shouldn't say that, but yeah. So when should we go from design to development? So, when are we gonna start? Basically, as soon as you have a comfort level that your design's not changing drastically anymore. What that's gonna mean, it could mean you officially have your sign-off from your customer. That's the gold standard, but often doesn't happen. A lot of times, you're gonna say, "Okay, well, they've tentatively approved these sections of the design and we're still working with other ones," and it's like, well, you can take those over to development. You don't need to move over with the full design. So you can move over individual parts as you need to. Figma just released a new feature where you actually can flag the components in Figma itself, and saying, "These are ready for development." Nice feature about that dev mode that they have is, once you flag it, if you make any changes to it, it keeps a change history right in the dev mode interface. So, say you tweak the color from your very darkest color to slightly lighter on that, the developers don't have to dig through to what changed. They can actually look at that change history and go, "Oh, the color changed here." They know the one thing they need to update over on the other side instead of checking everything out.

28:07
Doug Yerger: Is it a one-way transfer? So, do we only go from design to development once, and do we never go back? Wish I could say yes, but, in truth, no. If you get a new feature request, you wanna discuss a new workflow, anything like that, you're gonna wanna go back into that design environment. Rule of thumb I like to go is if you have any notion of the question, "Well, what's that gonna look like?" Do it in the design tool. You might just be mocking up one section of the screen. You might be revamping the design completely to do what you're gonna do. But as you use your design tool, it's gonna become a lot faster for you to do that design in those design tools versus doing it in your development environment. One final note I wanna make on this is that I keep talking about design and development like there's gonna be separate teams in your organization. For Grantek, and I think mostly controls engineer... Controls industry, I should say, design and development are actually the same teams. We don't have separate sections yet. We may in one day, as these keep advancing, but currently, it's the same team of people, but it's still design and development as two separate rules that they're working on.

29:30
Doug Yerger: So the same people could be designing in the morning, developing in the afternoon, jumping back and forth all day long, but that's what you're gonna go through. Basically, you don't need that 100% design to jump over, and you can always jump back and forth any time you want. Now, I guess I'll invite Rob back out here to answer any questions you guys all might have.

30:00
Rob Lapkass: Well, thank you for that informative presentation, Doug. And this brings us to our Q&A part of our session. We ask that you direct your questions to one of the mic runners. We've got two people down here on the floor. We've got a couple of folks up in the balcony, so any questions you have for Doug, please fire away. Right here.

30:25
Audience Member 1: Hey. Okay, so we have your design team doing the Figma mock-ups. Did you have any success with exporting that design, whatever done on Figma, as an imported JSON object so we can reduce the Perspective development?

30:41
Doug Yerger: They do have an export ability. It's gonna bring in your basics of size, corner radiuses, colors, things like that, so you could write some scripting and bring those in, but it's not gonna be able to map that a button is a button, because in Figma, it's a rectangle with colors and corner radiuses, so it doesn't know that it's gonna map to a button component in Figma. You probably could add some variables in there and create... Add some additional variables onto that item, identify it as a button, and then build some additional scripting as a, "Oh, I'm going to read this." I see this additional JSON that's tagged with it and go, "Oh, it's a button; I'm gonna create a button control and scheme it that way." So effectively, you could create those schemes. We haven't evolved that far yet. We're actually looking at it ourselves 'cause some of the export features are fairly new as well.

31:39
Audience Member 1: Thank you.

31:42
Audience Member 2: I'm curious about how you manage the design when there are collaborators and the options when you're presenting to customers. Are there different versions that are running at the same time of the mock-up? What's the practical way that you manage that?

32:03
Doug Yerger: To be honest, we often just go on a team share and show them what we want them to see. But there is full version control. You can actually create branches of your design. And then, once a branch is finished, it can be flagged for review, and then the owners of that design file can actually approve it, and it'll merge it back with that branch. So it does have that full control as well.

32:31
Audience Member 2: Can you do some sort of repo integration with it also? For collaboration.

32:40
Doug Yerger: I don't know if it supports things like Git or things like that. The version control is mostly done within Figma itself, that I know of. We haven't really tried that with a DevOps environment. Typically, what we'll do is we'll have, "Okay, this was rev zero," and we'll copy inside the design file itself and copy that design in and say, "Here's gonna be rev one that we're working on," and we'll go from there. And then we'll have branches within that rev until we're happy with it. And then, when it's released to the customer, that becomes fixed and we'll copy it down for the new work in progress. It's all kept within Figma itself, not a repository.

33:23
Rob Lapkass: We had a couple questions down here.

33:26
Audience Member 3: There's quite a few add-ins for Figma. Are there any that you found especially helpful?

33:35
Doug Yerger: I'm trying to remember which ones I have applied 'cause I put them on so long ago. Hit me up after this, and I'll look at my Figma file and tell you which ones I'm using 'cause I actually don't remember which ones I'm using. I know I have a couple of them in there that are used regularly, but I don't remember their names.

33:56
Audience Member 4: Hi, we're heavy users of Figma for our design, and I'm just curious to learn from you. One barrier or one thing that could be more efficient with our workflow is just trying to... When we're working with other designers or developers that we're taking off pieces, just seems like we have a lot of things that are in comments in Figma and then a lot of things that are out on backlogs, or scrum boards, or whatever else. And is there any way you've found to kind of integrate Figma with some sort of other workflows and development patterns like that?

34:24
Doug Yerger: You're saying like an Agile tool...

34:26
Audience Member 4: Yeah.

34:27
Doug Yerger: Yeah, there's actually several integrations. Figma's integration is several of the common scrum tools already, so you can pull things off the board and say, "These are what we're working on," and publish them that way.

34:39
Audience Member 4: Sounds good, thanks.

34:42
Audience Member 5: So early on, you mentioned doing a fairly robust analysis of various tools in the space. What are some of the other ones that you might have evaluated?

34:50
Doug Yerger: We did a high-level evaluation of probably five of them. We had narrowed it down, at that time, to Balsamiq, Adobe XD, and Figma. We ended up choosing Figma, one, a little bit around costing. We like their license model. It has a great... It ties into our SSO, so we actually log in with our domain credentials to log into it. We control access even internally in our organization through AD groups, through our IT department. So it had a lot of those nice-to-have features that we really liked.

35:31
Audience Member 6: I saw in your development that you're using a lot of test data. And I'm wondering, did you use test data from the customer's site or like autogenerated test data? And how did you go about collecting that if it was customer's data that you were presenting to them?

35:48
Doug Yerger: In Figma itself, that's all just pure text. It's just data we made up and typed in for the design to give them an idea of what it is. It's not dynamic at all. It's not tied to anything. And that's part of what makes it stronger, is we're not having to tie it to anything. We're just showing them what it is. We did know, like in the one I believe is from an alarming tool, we knew what the typical data was gonna be. And in that Oreo example, it's like, okay, we know there's a 24-count package, so we're gonna have a tray. We're gonna have an outer wrapper. We made up numbers. We made up... 'Cause it was just ours to put placeholders in that we knew what they were gonna be and it would make sense to a customer on what we're looking at. We have done ones where it's for a specific customer, where we'll take the real data and put it in in place so they see their data in there. But it's still not dynamic. It's for a specific example 'cause it's static in Figma.

36:47
Audience Member 6: Thank you.

36:48
Audience Member 7: Hi, Doug.

36:49
Doug Yerger: Hello.

36:50
Audience Member 7: Thank you for the presentation. That was good. This is just more of a comment. We now use Figma. We have Sam, and I think the biggest benefit that we found out is, as developers, we're engineers. We may not be the most artistically minded people. So despite the fact that Perspective allows us to create beautiful-looking UIs and UXs, it still looks like something an engineer has created. The artistically minded people... It basically allows the more artistically minded people within our company to truly actually help us develop beautiful-looking UX/UI experiences without actually us having to let them into the designer. And that's been huge on both sides. So, we end up with better-looking applications and not messed up by people like this.

37:37
Doug Yerger: Yeah, and that's one of those things we took from that web design world where you have all those wonderful designers that are saying, "This is gonna be a great-looking web page," but they have no idea what HTML and CSS even are. And they don't need to know; that's not their job. And that's what we're trying to separate there. So yeah, you can bring in your marketing department, let them decide what makes sense for it.

38:01
Audience Member 8: Hi. I've suffered most of the pain points that you show there, so I relate to all that. My question is, in addition to the user interface design, do you use any other tool for the designing of the relation between tables, and databases, and such?

38:27
Doug Yerger: We do use a few tools on that. Usually, it's kind of visualization. To be honest, if I'm doing them, I will actually draw them in Figma 'cause it's so easy to draw in Figma that I will just throw them in Figma and design. Some people like using Visio, but I hate trying to draw connecting lines in Visio because you know they're going to constantly change their path and change how they look whenever you touch anything. So I usually just will draw them in Figma myself when I'm doing it, because I've taken that... I know a lot of people use Paint to draw screenshots and all that. I usually just bring up Figma and draw things in there 'cause I can do it so quickly now.

39:07
Audience Member 8: Alright, thanks.

39:07
Doug Yerger: Thank you.

39:10
Rob Lapkass: Well, I'll jump in with one. I've done a little bit of work with Figma, but if someone in our audience was interested in getting started with a design tool like Figma, what might be the top three or five capabilities or design capabilities, the biggest bang for the buck, the quickest impact kind of things to prioritize on?

39:31
Doug Yerger: Well, I'll start with the first thing that's great about doing Figma: it's free to use to start with. You can have two projects in it. You do have limited number of people you can invite to your file, but if you're just wanting to evaluate it, free to evaluate; you don't even gotta need to contact them. You're just gonna log in, create a login on their site, and start using it. Big bang for the buck. We went over those pain points. Really, where I saw its value right upfront was when we had that IIS application where we know the one we have, we're not real happy with it, we wanna just rediscuss these workflows. How do we want it to work? And we actually sat down with a consultant and worked through typing down what we wanted, and making notes, and just discussing things. We had IIS up on a different screen. Discussed what we wanted, and that's how we came up with that list of the workflows, and then we could just slowly grow that from there. So I think that's one of the big ones is, a lot of times, it's just you can do it as a collaborative tool. They even have a whiteboarding section inside Figma that you can put stickies and notes and everything else around there as well, if you're into that phase of it. I usually stick more on the design side of Figma.

40:57
Rob Lapkass: Sort of a follow-on to that, what kind of design capabilities would you like to see built or added on to Perspective? 8.3, of course.

41:09
Doug Yerger: Being able to integrate with the design tools, as the gentleman out there mentioned, would be great, where we could actually bring things natively into it. Obviously, having to set them up and saying it is a button or whatever, setting up the right class, but that would be a wonderful feature.

41:23
Audience Member 9: So while we're all waiting for 8.3 and those drawing tools, I can see that Figma might be helpful for like SVG creation and sort of standardization that you could then use to import.

41:37
Doug Yerger: Yes, and when you're drawing in there, you can draw basic shapes and things like that, and you can export straight to SVG.

41:46
Audience Member 10: Did you investigate Lucidchart? Did you do something like that? Did you look at that at all?

41:51
Doug Yerger: We had not looked at that one very much. Our analysis started with saying, "What's really big in the web industry?" So we went with the top hitters there, was what we were gonna start with, because we figured that would be our best bang for the buck and have the most knowledge out there for learning it ourselves.

42:14
Rob Lapkass: Oh, looks like we got one over there.

42:18
Audience Member 11: Hi, Doug. You mentioned that oftentimes, the designer and the developer are the same person. What's your opinion on whether that should actually be the same person or whether there should be a separate job for that?

42:32
Doug Yerger: I think that in our industries currently, you're gonna see that developer staying as part of the design team. But as the gentleman from Kanoa mentioned getting in people who are graphic designers, and that might really help with getting snazzier layouts and more eye-catching ones, especially when you're dealing with dashboards and management tools where they want all those things to be flashy and really eye-catching, versus an HMI that we're bound by ISA101 what we're supposed to make it look like.

43:07
Rob Lapkass: Alright. Well, it looks like we're drawing near to the end of our scheduled time. Thank you for all the questions, and how about another round of applause for Doug?

43:21
Doug Yerger: Thanks, Rob.