Often times what the customer sees is what defines the "quality" of your project.
The reality is that graphics and the "functionality" of your building automation system are what shape the perceived quality of your installation.
In this episode we discuss strategies to implement user friendly graphics while also setting up your BAS front-end correctly.
Click here to download or listen to this episode now.
Resources mentioned in this episode
Transcript
Phil Zito 0:00
This is the smart buildings Academy podcast with Phil Zito Episode 290. Hey folks, Phil Zito here and welcome to Episode 290 of the smart buildings Academy podcast. And in this episode we are going to be discussing how to perform graphics and front end setup. As always, everything can be found at podcast smart buildings academy.com, forward slash 290. Once again, that is podcast smart buildings academy.com Ford slash 290. So I started getting into a little bit of a debate on Facebook, someone posted a picture of a panel. And they're like, Hey, I like the panel. And I mean, it looked nice. And I mentioned Hey, I just did a podcast episode. This was Episode 289. That was basically arguing that, hey, panels, looking nice is great, but it's just one small piece of things. And in reality, a lot of folks will dump a lot of money into install and into graphics. And they will neglect some of the other things like some of the front end setup. Do you just follow the spec and put trends on everything? Do you have your alarms not tied to the actual state of the equipment? Do you go and give every user access to everything or give no users access to anything? You know, what do you do behind the scenes? And I know I know, graphics and panels, they look nice. And people are going to evaluate your installations and are going to say, Hey, your installations look good. And you're going to get people out there who are going to argue and say, you know, if I'm doing good on the things people see I'm going to be doing good on the things people don't see. And I can follow that logic to a point. But I will say with limited bandwidth and limited labor out there. I don't know if that's necessarily true. So in this episode, we're going to be going through what are the common graphics types? How do you develop graphics, what are the best ways when def graphic standard outsourcing graphics
Phil Zito 2:07
and then we're going to kind of switch gears and talk about front end setup. So when it comes to graphics, there are three main graphics that you're going to have right, and those are going to be your home graphic, or your home graphic is going to be the landing page graphic. Ideally, the home graphic is going to allow the user based on what they need to do to access whatever they need to access. Typically, the home graphic will have an overview of the central systems, the air handlers, central utility plant, etc. The outside conditions, image of the building so you can know what building you're in maybe some general data linked to the submittal set, linked to maybe any documentation and a link to floor plans and system graphics. The next graphic up is the Floor Plan graphic and the Floor Plan graphic is just that it's a floor plan. Oftentimes this will be divided into multiple floor plans, and maybe even multiple, multiple floor plans. So you take a floor and you cut it in half and you quadrant it out, depending on how wide the floor plan is. And these can be anything from real simple, just lines all the way to three dimensional and that kind of talks We'll talk about it later about the level of graphics and level of detail. I personally can see an argument for having complex three dimensional graphics, I can also see an argument for having basically text only graphics, I could see an argument for both. It really depends on what kind of customer you're dealing with. And usually the fanciness should not be the driving factor behind that. What should be the driving factor behind that selection should be usability and use case and we'll talk more about that in just a bit. So as far as floor plans, they typically have the temperature within the space a link to the unit serving that space and the link to the unit that is serving that floor. Then we come into system graphics these are usually template graphics for our air handlers, v v boxes, chilled water plants, etc. They will typically include a one line schematic, it could literally be a one line schematic or it could be a 3d photorealistic representation of the unit with a cutaway. Usually it will have on the main system graphic, it will have the primary parameters, then you'll have a link to a secondary, basically table or graphic that will have the actual tuning parameters for that system. These should normally be restricted from an access perspective. More on that in just a bit. He'll usually also have a link to the sequence of operations usually in text format. And you will have a link to any schedules, alarms etc that are specific to that system. Those are the Primary graphics now there are other graphic types that definitely exist. And those graphic types can be, you know, balanced or graphics tested balanced graphics. Those can be functional test graphics. Those can be parameter graphics. Those can be graphics of integrations and API's, things like that. Those can be campus graphics. Instead of floor playing graphics. There's
Phil Zito 5:23
a variety of different types. But those are add ons to these base three graphics. Now I mentioned we have to decide between photorealistic and non photorealistic like just simple simple graphics. You know, if you have a user who understands what a system is, and they understand like, Okay, if I walk up to the air handler, I'm going to be able to find the filter, I'm going to be able to find the fan, then oftentimes, you can get away with really simple graphics, you know, simplicity is best. And at that point, especially if there are self executer, you want to give them easy access to the data. Which brings us up to another point in just a second, which is the header and data flow and data access. We'll talk about that in just a second. Now, if this is a person who has never seen a system before, and they have no idea where the filter might be, or they have no idea where the fan may be, then having a really photorealistic 3d cutaway can actually be very beneficial, especially if it's a younger maintenance team. This can really help you to create a graphic that basically instructs them where they need to go and what they need to do. Now you can add on top of that hyperlinks to maintenance procedures, like below each individual device, you can have a link to its maintenance procedures and common troubleshooting procedures and processes that makes it really valuable, and can make it very beneficial for the user. You can also have links to programming and all sorts of stuff depending on what your software provides. Now one of the things I have mentioned multiple times is the user type. Understanding your user type, understanding what that user should be able to do is going to drive whether or not you go and give them access to points. We'll talk more about users in just a second. So so far, right, we've talked about home graphics, we've talked about floor playing graphics, we've talked about system graphics. Now let's talk about the header. And let's talk about system flow. So at the top of every graphic is what's called a header. And if you've ever seen the menu on a website, right, you go to a website, it's got the drop down menu. That is what a header is, it should tell you what page you're on should tell you like how do I get to my account information? How can I go back? How can I go forward any hyperlinks to any really important parts of the graphics and the layout that should all be available to you. And a really well developed header, as well as well developed graphics should make it to one where flow is seamless. Like, hey, I need to get home, I click the home, hey, I need to get to a drop down to floorplan I can drop down to floorplan you could get to wherever you need. The general rule of user based design is the three click rule, a user from any graphic should be able to get to any other part of the system they need within three clicks. So if I'm on a floor plan, and I need to get to a schedule, for my chiller, I should be able within three clicks to get to my chiller graphic and get to my schedule, I should be able to get to that within three clicks. That is a kind of best practice. As far as user development goes. I don't really focus a lot on mobile, because I just don't feel like it's realistic to be using mobile devices. Now mobile graphics have come a ton or have come very far, especially with newer mobile devices that are large. So that is something to consider. I personally do not want to do programming or major troubleshooting over my mobile device. I will use a breakdown list and you know a drop down list of text in order to do maybe point to point or something. But if I really want to troubleshoot stuff, I ideally want my laptop with the programming software so I can dig into the system and I can dig into the actual programming to see what it's doing. But that's just me. That's how I troubleshoot. That's how I test that's how I do things that isn't necessarily how everyone should do things. Alright, talking about outsourcing or insourcing graphics. Graphics are one of those things like electrical subcontractors that if you don't have a lot of templates, and it's something that you don't have in house talent, it's perfectly fine to outsource you're going to pay more. But you can buy libraries and especially if you drive your customers towards standards, you can create a list of standard graphic standard colors, standard types, and these are things you should be soliciting from your customers. When you do a job like what font Do you want, what color do you want? What's your primary color, what's
Phil Zito 9:54
your secondary color? What images Do you want us to use, etc. You should be going and Figuring out that information, and you should be putting it into your graphics design package. Once you have that information, you can either have your designer, some tools will actually create baseline graphics as you create your submittal. So you create your submittal. And it will create your baseline graphics for the building automation system at the same time. Other tools are going to require you to create your graphics on your own or from a library of graphics. You can also use graphics from graphics providers, I'm not going to get into who they are. But if you google building automation graphics, you can definitely find several graphics providers who will develop graphics packages for you that you can utilize and include in your job. This is really good when you're doing 3d graphics, photorealistic graphics, etc. It's good if you don't have that talent in house to outsource it. And honestly, I don't feel like that's a very return on investment talent. To have on staff, I feel like that's something that can be easily outsourced. For minimal margin erosion, just my two cents on that you can go however you want. But that's my approach. Now let's talk about front end setups. Okay, we've got this building automation system installed, we got a supervisory device installed, we install our building automation server, or we connect multiple supervisory devices to our building to one of the supervisory devices, right. And we say, Okay, this is going to be our head end device, we're going to go and establish our user profiles, we're going to understand our user types. Typically, it's you know, two to three user types, right, you'll have a managerial type, some sort of analyst, senior technician type, and then a maintenance type. Those are the three most common types that you will have when you are developing a front end and develop setting up your building automation system. Once you understand those profiles and types, you can set up user roles. And you can categorize objects. This is where it gets very vendor specific. Sometimes you can categorize objects, sometimes you can categorize categorize devices, sometimes you can't do anything sometimes you can simply restrict actions that end users can take, it's all over the board, depending on who and what product you're using. So just be cognizant of that and approach like, Hey, I'm going to go and I'm going to approach this and I'm going to go and list out, okay, this is what the users are going to be able to do. This is what they're not going to be able to do. And this is the user profiles, user roles, etc. Ideally, this would be listed in the specification, under the section three of the specification execution, but it's not always there. If you're feeling squirrely, you can submit this as part of your submittal package, just realize you might be creating work for yourself, that's not necessary. Personally, I would set up like if it's not specified, and you've never worked with this customer before, I would set up one general user type with base level access. And then I would come back later for a change order and really, like customize it down to what they want, right? I would get really specific in their user types, their access types, and I would really kind of dial it in. I know that seems like you're it feels dirty, like you're ripping off the customer like Shouldn't they just have all this upfront, but you don't know the customer because oftentimes the person executing the construction is not the ones that are operating the building. So you have no idea this could be outsourced maintenance, this could be in source. This could be someone who went to MIT or this could be someone who like, doesn't know how to spell VA s, so you have no idea what you're getting, and just kind of plan for middle of the road, and then come back and customize accordingly. Another thing with the front end setup that you really want to dial in is your alarms and your trends. Those should be specified. They should be specified in the spec but if they aren't, then you definitely are going to want to go and clarify like what am i trending? What am I not trending? What am I alarming? What am I not alarming. And you want to put in your kind of triggering criteria for that you
Phil Zito 14:18
don't want to run a trend when the system's not on you don't want to run an alarm when the system's not on. If the building automation system isn't on or if a spaces an occupied you want different settings for the alarms you don't want everything running off of you know, if it gets above 74 degrees, and you know, it's nighttime in Texas and of course it's going to get above 74 degrees because no one's in the building bases now running. You don't want to trigger an alarm necessarily. So you need to be cognizant of these things as you go and you approach your front end setup. And this is all stuff we talked about in our installation and configuration course formerly known as startup and check out. You could definitely find out more about that at podcast at smart buildings academy.com for slash to now Let's get on this podcast dot smart buildings academy.com for slash 290. I encourage you to kind of let us know what you think about performing graphics in front end setup. How do you do graphics? What are your strategies? What do you think about what I've proposed here today? Do you agree? Do you disagree? I'd love to hear from you. Let me know. And Thanks, Tom for listening and I look forward to talking to you in a future podcast episode. Thanks, Tom. Take care.
