Design Like a Pro: Building Better HMI Navigation Schemes

About this Webinar

When designing industrial interfaces such as HMIs and dashboards, common design mistakes such as confusing navigational systems, lack of content hierarchy, and cluttered windows can derail your efforts. How can you avoid these pitfalls and keep your HMI projects on track?

In this "Design Like A Pro" series, two user-interface (UI) design experts from Inductive Automation will share effective ways to make your interface design more organized and easier to navigate. They discuss the principles of information architecture and how to apply these practices to build well-structured, intuitive projects.

Learn how to:

• Get best practices for constructing effective information architecture
• Properly define end users and their goals
• Organize content in a meaningful way
• Implement layout organization and visual hierarchy
• Provide orientation cue in your page structures
• Understand the different types of navigational components, how to use them, and their pros & cons

Webinar Transcript

00:00
Travis: Good morning everyone, and welcome to our webinar, Design Like a Pro: Building Better HMI Navigation Schemes. Thanks for joining us today. To introduce myself, I'm Travis Cox. I am the Co-Director of Sales Engineering here at Inductive Automation. I've been with the company since the beginning, and was the former Director of Training and Director of Support, so I'm very pleased to be here today and to also introduce our guest speakers. I'm gonna act as the moderator for the session today, and we have two other Inductive Automation presenters that I'll introduce in just a second. To look at the agenda today, we're gonna start with a quick introduction of Inductive Automation and our software, Ignition. I'll introduce our presenters and we'll dive into some common challenges which Ignition users run into designing their HMI navigation schemes. We will then discuss the field of information and architecture, breaking it down into two parts. First, we'll discuss content organization and then get into creating more intuitive layouts. The question and answer, of course, will be at the end of the webinar.

01:03
Travis: So some company background here. Inductive Automation was founded in 2003. We grew out of Integration Roots. Since day one, we've been an independent company with no outside investors. We're very pleased that enterprises around the world have chosen Ignition for their HMI, SCADA, MES and IIoT needs, and so far it has been installed at sites in over 100 countries. We have our Integrator Program, it has over 1400 integrators and in pretty much every industry worldwide, and our revenues have increased at an average annual rate of more than 40% over the past six years. So if you'd like more information, please visit our website, inductiveautomation.com, and go to the "About Us" section to learn more about our company, our leadership, as well as our customers. Ignition is trusted and used by thousands of companies, including 44% of Fortune 100, as well as 26% of Fortune 500. It is being used in virtually every industry, including oil and gas, water, wastewater, food and beverage, government, transportation, packaging, and many others.

02:03
Travis: Our software Ignition is the first database-centric cross-platform web-deployed industrial application platform for HMI, SCADA and IIoT. Quickly, here are six reasons why it's so unique from traditional SCADA systems. It has web-based deployment with web-launched clients and designers that are zero-install. Its unlimited licensing lets you use as many tags, clients and connections as you want. Ignition offers security and stability. It has a module architecture that makes it easily expandable, and it allows it to open up to future development. It's made for rapid development and deployment, and it offers real-time status and control. We have a great topic here today, and I'm excited to introduce our presenters from the Inductive Automation Team. Today we have Steven Fong, Co-Director of Marketing, and Ray Sensenbach, a UI/UX Designer. Presenters, can you guys each take a minute to briefly introduce yourselves? I'll start with you, Steven.

03:04
Steven: Thanks, Travis. So as Travis mentioned, my name is Steven Fong and I'm Co-Director of Marketing at Inductive Automation. I've been here since 2013, and in my time here, I've held a number of different roles in UI Design, UX and Marketing. My first major project for the company was Inductive University, and since then I've been involved in a number of different projects aimed at making our website more usable and more useful.

03:30
Travis: Alright, thank you, Steven. Ray, how about you?

03:31
Ray: Yeah, good morning, everyone. So I'm Ray Sensenbach, a UI/UX Designer here with Inductive Automation. And I've been with the company for just about a year now, and I'm working as a part of the development team. So most recently I was a part of the 7.9 Gateway redesign, and I'm just really excited to be with you here today and share some tips on navigation design.

03:51
Travis: Thank you, Ray. So we have a really good topic today. We have two experts here that are gonna really give you some good tips on how you can design better applications. So without further ado, I'll turn it over to Steven to dive into the agenda here today.

04:04
Steven: Alright. So as Travis mentioned in the introduction, today's webinar is gonna focus on what's known as information architecture. First, we'll get on the same page as to what information architecture really is, then we'll talk about content organization and how you can plan your project with users in mind. And finally, we'll move into layout organization. Layout organization is all about the interface you actually build, and we'll review strategies and best practices around navigation patterns. In preparation for today, we've worked really hard to distill down a ton of information into simple, actionable concepts for you. We've even built a practice project that we're calling The Inductive Brewing Company. This project will help us see the concepts in action and really get a handle on the new strategies that we're learning. So if you see a green star in the top right corner of a future slide, it just means that we're referencing this practice project.

05:06
Steven: So our practice HMI has some problems. At first glance, the visual design itself seems okay. It has ample white space and uses some of the principles of high performance HMI. However, there are quite a few issues here which can suddenly cause confusion, which relate to the project's information architecture. Some questions a user of this interface may have may include, "What screen am I on? What other screens are there? Where should I go from here? What is a button and what's just plain text? And how do I get back to where I was before?" With the help of our support team here at Inductive, we've identified these as common pain points which others run into when they're building their interactive screens. So today we'll use information architecture to attack these problems head-on and develop a more strategic approach to defining our project's content and designing the layout. Okay, we've been tossing this term around a lot today, but what exactly is information architecture?

06:08
Steven: So information architecture is technically defined as the structural design of shared information environments, the art and science of organizing and labeling websites, intranets, online committees and software to support usability and findability. So like most technical fields, information architecture tends to over-complicate simple concepts. A better definition is this: Connecting people to the content they're looking for. So where might we see an example of this in our everyday lives? One example is that one terrible remote control for that one crappy DVD player that you have hiding in your house. And you know the one I'm talking about, you probably won it at your company's Christmas party, and it doesn't work unless you stand right in front of the player. And worst of all, the buttons make no sense. Like this one that I have at my place, where's the play button, and where is the pause? Why is there so much space given to the number buttons that I'll never use? And why is the most prominent button the eject button?

07:10
Steven: It has every function that you could ever need, but it's impossible to find what you're looking for, and what this remote lacks is proper information architecture. Contrast that to this remote control, and as soon as you get your hands on it, it feels a lot more intuitive, and why is that? It's using tools like grouping, color, hierarchy and shape to help convey the meaning and importance of these buttons. It's still complex and it can still accomplish a lot, but it's way easier to use, and this is what a well-designed information architecture will do for your HMI. And once you start to think about it, you realize that information architecture is all around us. It's the driving force behind things like roadway signage, every website you've ever visited, instructions on prescription medication bottles, exhibits at museums, ballot and voter information guides, every book you've ever read, and even presentations like this one. So we ask ourselves, what do these beings all have in common? They're all used for wayfinding in one way or another. Information architecture helps us to navigate through complexity. It helps us to make our interfaces intuitive and easy to control. An interface with solid information architecture should help to convey to us where we are, what we've found, what's around us, what to expect and where to go.

08:30
Steven: So think of our design like you would a street sign. What can you do to limit frustrations and confusion? So now that we have a better understanding of what information architecture is, let's dive into our first section, content organization. This section is all about how to categorize and structure your project's information as related to project and user goals. We'll start by understanding who our users are and what their needs and goals are, then we'll distill these needs and goals into functionality and then organize that functionality into logical groups that will form the foundation of our navigation. Now, it may seem tempting to skip through this first step and dive right into arranging windows in Ignition, but we can't stress enough how critical this initial step is. So stick with us and let's get started.

09:19
Steven: So in our years of designing interfaces, Ray and I have learned one thing about users, they never do what they're supposed to do. They click everything, they rarely follow instructions and they never read. All that to say that a tailored navigational structure is going to be much more successful than something more generic. We wanna mold our project to our users and not the other way around. So the three major questions that you should ask yourself are: Who is this project for? Are there multiple audiences? And what are their needs? The understanding we gain from answering these questions forms the basis of the navigational system that we're trying to build. To help us keep track of what we're building and who we're building for, we like to use personas.

10:04
Steven: Now, personas are an archetypical representation of a user type. As we gather input from future users of our system, we'll include information about each person's role, their work environment and their goals or needs to flesh out the persona. So for example, after interviewing a couple of fermentation operators, we've built a persona for Zach. It's important to note that while Zach may not be an actual person, he represents a real general audience for our project. Later when we're building out our screens, we'll be able to look back to our persons and say, "Will it work for Zach?" Going through Zach's persona here, we note his role as a brewery fermentation operator. His environment is the brew house floor. There are HMIs on the machinery. It can be noisy, messy, and he's probably wearing gloves. He cares about checking fermentation tank temperatures, being alerted to any problems and know how to respond, and see tank levels and other details, and also have an ability to stop and start fermentation runs.

11:03
Steven: As you interview different groups of users, you start to build out the other personas. Here we have three full personas that we've defined, and they each represent a different group of users who will each have different needs. And they don't have to look just like this. Ray and I both come from visual design backgrounds, so we like to make things look pretty. Your personas can be as simple as a Word doc or a sticky note. The point is each persona we generate will use the system in a unique way, so you need to be sure our project has the content which allows each of them to solve their problems and a way to get to that content. So this brings us to user stories. We'll use this process to begin teasing out actual content for our project. If you aren't familiar with Agile, user stories are a process we use to build functions with a particular user in mind. The format of the user story is simple and reads as follows, "As a blank, I want blank so that blank." This is very important for us because we wanna keep the user in mind as we build out our navigation.

12:05
Steven: For our purposes, we'll fill out the blanks with user, content and goals. So for example, as a fermentation operator, I want a view of the tanks so that I can observe their status. The result of this process are all the bits and pieces of functionality that will form your interface. And as a side note, we could really go into so much more detail about creating personas and user story creation. If you wanna learn more about all of this, check out a session that I did at last year's Ignition Community Conference. We'll include a link to it in our post-webinar email. So as you begin defining your interface, you start collecting a ton of different pages and functionalities. How do you make sense of them? One reliable way is through a process called card sorting. It involves listing out your functionality using literal physical cards or stickies, and getting together with other designers, engineers and users and moving them, the cards, experimenting with different ways of organizing your content. The format makes it really easy to quickly experiment with different structures and get input from your team.

13:19
Steven: Is it better if we group pages like this or like this? Would we need to point to item Z from item A? And what is more important, this or this? Keeping yourself analog with little cards and Post-its and Sharpies allows for more flexibility during the planning phase. You'll find that once something is in a document or even just printed out, people are a lot less likely to make drastic changes, even if it would be a good idea. As you work through the exercise, you find that your content usually falls into one of two content hierarchies, which we'll be going over in the next slide. So there are two basic approaches to your project's architecture; you can go narrow and deep, or broad and shallow. With both, you'll run into what we like to call the Goldilocks Problem; that is, getting the structure to be not too deep, not too shallow, but just right. If your structure is too deep, users get frustrated and lost as they dig down through too many layers of the menu. Too shallow a structure and your menus are forced to be way too long and difficult to navigate. They each have advantages and disadvantages, so let's talk about them a little bit more.

14:30
Steven: So narrow and deep. Again, with the narrow structure, the advantage is that fewer links are presented at once, meaning less cognitive load, your user has to make less decisions at any given time. It's also an intuitive pattern for directing a user down a particular path. On a downside, it means quite a few more clicks. The user can get lost in deep structure or become frustrated when the amount of clicking that they're gonna have to do to get to their desired content. With a broad and shallow structure, you present more links to the user at once. This can introduce some possible friction or confusion because it's difficult to scan all those options. It's also tough to tell what's relevant or related because everything is seen at the same level. The advantage, however, is that users need to click fewer times in order to get to their destination. Too much of something isn't a good solution either, so just be careful with taking your broad navigation too far.

15:30
Steven: So for our hypothetical project, we determined that we had three different users with three different sets of unique and sometimes overlapping needs. We turned those needs into the user stories, so for example, the fermentation operator being able to see tank details, and got buy-in from our group on how best to organize that content. That there are four major sections and maybe that there are four varieties of beer under the fermentation section, for example. For the purposes of our hypothetical Inductive Brewing Company, we determined that our content was most naturally structured as broad and shallow. We determined that there should be three levels of hierarchy. First, we have the top level or primary links of the brewery house, fermentation, packaging and shipping, as you can see here on the top row. Next, we'll use sub-categories to display the secondary pages. And finally, our fermentation category needs a third level to show the specific details of our fermentation tanks. So now we have a good idea of how the content should be organized, what tools can we actually use to make this happen on screen? For that, I'd like to bring Ray back in.

16:41
Ray: Thanks, Steven. So yeah, moving now into the second half of the webinar this morning, we're gonna begin to start thinking about the physical structure of our project's navigation. So I've divided this section of the webinar into two parts. The first is layout, and we're gonna cover here what your users are expecting to see and some common best practices surrounding that. Next, we're gonna get into the navigation structures and talk all about the specific tools that you're gonna be able to use to build out your navigation system. So first talking about user expectations. Now, when you're lost in a new city, you know intuitively where to look for directions. You might look to street signs or building address numbers on buildings, but just imagine how frustrating it can be when these conventions are broken. Now similarly, your average user has very clear expectations about where elements should be located on your screens, and violating these expectations should be avoided whenever possible so as to reduce any potential confusion. There's really no reason to reinvent the wheel here, so just remember that best practices are your friend.

17:41
Ray: So here we're showing a visual example of these user expectations, and this is results based on some eye tracking studies that were done. So let's just walk through each of these elements and talk about where your users expect them to be. So first, we have in red our home link or logo, and you can see that based on these maps, the users usually expect this element to be in the very top left corner of your application. Now, next in purple, or it looks like pink here on the screen a little bit, is what we're calling utilities. Now, this means maybe the system time, login and log out links or other system level information. This is looked for in the top right and at the very bottom of your application. Next, in green, we have navigation links, and as you might expect from our use of websites and the web, that folks look for these in the header and sidebar areas. And finally in orange, we have a page title, and that's usually expected to be roughly in line with your content in the middle of the page. So just keep in mind that this specifically is a US-based example, and you'll wanna take into consideration your specific user base and whether or not they're from a country that might read right to left or have other common layout conventions.

18:55
Ray: So let's get into layout best practices. And as Steven mentioned, your typical users sort of scans, clicks and jumps around the screen really quickly, so in order to facilitate this type of natural user behavior, we're gonna want our layouts to be designed as clearly as possible. So now we're gonna walk through these four simple but powerful layout best practices that should help you in designing your next project. And these include having a clear visual hierarchy, breaking up your screens into clearly defined areas, making it really obvious what's clickable, and just reducing the overall clutter on your screens. So first up is clear visual hierarchy. Now, this just means making sure that the appearance of your content clearly reflects its importance.

19:38
Ray: So the most important thing on a screen should be called out in some way. Maybe that's just making it larger or you just want to make it louder in some way. And you can use tools like color, white space, bolding the text, or some other combination of these things to make that happen. Next step, we have clearly defined areas. Now, we wanna give our content its home on the screen, and we're gonna accomplish that through grouping similar types of content. And the goal here is to just let users know where they can find information. We really don't want them to be hunting around our project screen looking for things, especially once they've found something like it. So just a final note on clearly defined areas is to try to really remain consistent with your layout throughout your entire project. Being consistent between your layouts is just gonna make them easier to use.

20:24
Ray: And here we just have a quick example of establishing clearly defined areas, and this was seen in our recent redesign of the Ignition Gateway. So there used to be some status information in the config sections, a little bit of config in the status sections and vice versa. So things here were just a little bit mixed up, which made it a little bit difficult to use sometimes, and so our redesign really focused on breaking this content clearly apart into two specific sections. There's really no cross-pollination there now, and this makes it much easier to navigate today. So another layout tool that we have is called affordance, and affordance just means making sure that the actions and links within your screens are really obvious and discoverable. When something has a strong visual affordance, it just means that you know what it does or can do just by looking at it. So in our graphic on the right here, we have the top two gray buttons and links, which are not really obvious that they are buttons and links, and so just below it, we add some blue color, some rounded corners and an underline, and these visual treatments just make it much more obvious and clear that these are actionable buttons. So if something is a button, make it look like one. Being consistent is a nice trick here as well so folks aren't left guessing. Make all of your links look the same and save someone a headache down the line.

21:41
Ray: Additionally, you'll wanna make it clearly differentiated positive and... Excuse me. You'll want to clearly differentiate positive and negative actions. So if something is a destructive button or a positive action, you'll really want it to look like that. So you can use maybe the tools of color, like we are here using red and green. So the final tip for a well-designed project layout is reducing your visual noise or clutter. So when building a screen, just remember that each element that you're adding adds to the visual noise making it potentially more difficult to use. So be sure that you're fighting and questioning the adding of any new elements to each screen, and you may even find that it's a better strategy to build out an additional screen instead. High performance strategies seem to work really well in reducing visual clutter, so that's definitely something worth learning more about as well. And the graphics we're showing here are a before and after design from another webinar that we did from the Design Like A Pro Series, which we again, highly recommend that you check out and we'll have a link to that at the end of today's session. So let's move on from layout to navigation now.

22:44
Ray: So the purpose of your navigation is twofold. First of all, it's going to help your user get to where they need to be, and secondly, it's going to provide orientation for where they are now. And we're gonna be working towards a navigation structure which is intuitive and predictable, and our goal is for new and returning users to be able to figure out how to get around your project really easily. And this graphic here just sort of illustrates some of the questions that a user might be having and encountering when they're looking at a poorly structured navigation. So we're gonna talk now about the specifics of building out a good one.

23:21
Ray: So as we're building out our navigation, you'll wanna keep in mind the difference between categories and utilities. Categories are your content. This is the link to the main sections of your application. Utilities, on the other hand, are links to important elements of the app that aren't necessarily part of your content hierarchy. So this is things like helper screens, logging in, logging out, system time, etcetera. This is all a utility. So I'm only mentioning that because you wanna make sure that you're not mixing these two types of links in your navigation structures. This can cause confusion, as we saw before with the eye tracking studies, because users are going to be looking for these two different types of links in two different locations, and they'll be confused when they're mixed together. And this image on the right is just showing our sample brewery HMI, the before section, and this is showing the two types of navigational links here being mixed and that they should be separated, and we'll get to that at the end of the webinar again.

24:16
Ray: So let's discuss the different areas of placement for your navigation. We're gonna go through the top three positions based on user expectations and sort of the space constraints of an HMI. So the first example we're showing here is the top header placement. Now, this placement is ideal for your primary navigation because for one, users are already looking here for their navigation. Additionally, the header is separated from the page's content, which reduces confusion between what is navigation and what is content. Now, one downside here is that the horizontal space is a bit limited, but this can be an advantage because it sort of forces you to organize your information a little bit better and cleaner. Now the second recommended placement is the top subnav area. This is similar to the top header area, but just below it, which gives you a little bit more space because it's not being used up by things like your utilities or maybe your logo. And this is a useful space to use when the header space isn't quite large enough for all of your primary links. And again, it's still a powerful position for your primary hierarchy because this is where users are already looking for their content.

25:28
Ray: Now finally, we have the side navigation pattern, and this is a really common pattern, which is especially useful for when you have quite a few links in your project. This is because it has a vertical structure which supports scrolling, so when your list becomes way too long to fit within your window, users will be able to easily scroll down and get to where they need to get. Now, with a complex project, you're likely gonna be finding yourself combining these placements to form your navigation structure, so here's some examples of how this may come together for you. First is the header side nav combination, and this is a really common structure where the primary navigation is in the header and the secondary navigation is seen on the left and the sidebar. Second, we have the header and subnav combination, which is also really common but is only really useful when you have kind of a small application with not a lot of top level links because of the constrained space there. Now down with number three and four, we're getting into sort of more complex variations of what and how you can combine these things, but there's really no limit to what you can do. Just be sure to keep in mind that you again want a clear hierarchy, and try not to add any unnecessary clutter.

26:41
Ray: So now we're gonna begin to go through some really specific navigational tools that you can use on your interface, and first up, we have tabs. Now, tabs are a great navigational choice for large applications because they're so intuitive. Anyone can look at a tab interface and just understand right away how it works. They're really obvious and hard to miss, and they also suggest this physical space by creating the illusion that the active tab is being brought up to the forefront. So you can see here in our example, the active tab is white and it's clear that it's active on the screen. The tabs two and three, they're clickable, but they're not currently active because they're a little bit grayed out. And the fourth one takes that metaphor sort of to the extreme and pushes that inactive or disabled tab way, way to the back. Now, keep in mind that tabs also work vertically. So again, if your horizontal space doesn't work for them to fit across the screen, try a vertical tab system.

27:34
Ray: So now we have drop-down menus and we see these used really often with Ignition projects, and that's probably because the space is really limited in our HMIs and it's a limited commodity. So these actually suffer from a lot of usability problems and we really don't recommend them for use, and those problems are that a user must seek them out, and they're really difficult to scan because you have to click into them to sort of understand what the options are in the list. So on the right here, we have our two images, which is kind of the before on the top and the bottom on the after. And you can see that we've taken this drop-down or select list and converted it into a tab system, and this allows our users to see all the options at once, which is great for your users' situational awareness.

28:19
Ray: Now, drop-down menus can be effective sometimes like for alphabetized lists like states or countries, but really only in places like that where your user already understands what all the options are and doesn't have to think about them. And another example of refining a drop-down menu into something else that works a little bit better is what we recently did for the Inductive Automation Integrator Search. So our old search on the left here used a series of drop-downs for navigating through a list of 50 plus items. It was a real usability problem which we needed to address, so our new search on the right uses a Google Maps API to match results to a typed-in location. So this is a benefit because the user here can use any type of input that they have in mind to get to where they need to go. So it accepts things like address, zip code, city, state, country, really anything that they are thinking of.

29:17
Ray: Let's talk about file trees for a second here. The file tree is another of these classic components which we see being frequently used for navigation today. So in general, they can be used for larger desktop-focused applications, but we really don't recommend these for anything that's gonna need to be touch or mobile-friendly, and that's because these little arrow icons are really tough and tiny touch points, which can be difficult to click even with a mouse sometimes. Now, they do work really well for actual file paths like we're showing here with tag paths in Ignition, but again, using them for a primary navigation pattern is generally discouraged because they're faced with these usability problems, and it's similar to the select list or drop-down menu to where you just can't see all the options that are present in there at once.

30:07
Ray: And we talked earlier about information architecture being all about wayfinding, so just like every street corner needs a name, every screen on your project is going to need one as well. And your page name should be in the right place, be prominent and match your users' expectations. And so your users are going to expect to see a page name at the top of your content, that's the right place for it. And in addition to being in that right place, they should be large enough to be instantly recognized as the heading or title of a page. People shouldn't be guessing if these are labels or page names, it should be clear. And finally, what we mean by matching user expectations is just that if I click a link on a previous page, like in our images here that says Amber Lager, I would expect to then be taken on my next screen to a page that's titled as Amber Lager. So we just wanna be clear about where we're going and meet those users' expectations.

31:01
Ray: Now let's talk about breadcrumbs. Breadcrumbs tell a user where they are now and give context to where they've come from. They provide links which bring you back up to the top level of an application sort of one step at a time, and breadcrumbs work really well when they're used alongside other navigational tools that we've talked about today, but not so great on their own. So like in our example here, you wouldn't wanna use a breadcrumb as both a navigational tool and the page title, you would wanna use it in conjunction with the page title. Now, that leads to a little bit of repetition, but that's okay because it really boosts the usability of your application. And when it comes to placement on the screen, the user really expects these to be at the top of the content and pretty small, so just keep that in mind when you're building your designs. Next we have the back button, which is another element that we've all been trained to use through our Internet browsing, and we've really come to expect it in our interfaces. A back button will present us with a dead simple decision of, "Do I wanna go back or not?" So they're really easy to use, and they're especially useful in these really deep navigational structures that we mentioned at the beginning where you might need to jump up quickly back between a few levels.

32:16
Ray: So let's take a look at our before and after interface here and sort of discuss how and where we applied these layout and navigation tools to improve the interface. So for Inductive Brewing Company, you can see the legacy interface next to our fully refined version here, on the left is legacy. And I sort of highlighted with the numbers in red here, the sections that we're gonna have to discuss. So if you looked in the top left to number one there, this is where our original navigation was located. Now, the type of links here was mixed, like we talked about, between categories and utilities. So in the right, what we've done is decoupled these types of links and moved them up to the top, top header area.

32:55
Ray: So in the top header area, you can see the primary navigation links. In the far top right, you can see those utilities, which again is where the user expects them to be. And number two is our HMI's logo, and the link to the home screen. Now, before this was sort of placed randomly haphazardly in the middle of the HMI, and again, we've moved this to the very top left where users expect it to be, and now it also links to the homepage of the application. Number three here is our secondary navigation. And again, we moved this up to the subnav position below our top header and converted the buttons into tabs, making it really clear what's active at any given moment. And number four is the select list that we discussed or the drop-down that was used to see our tank details navigation. Now, we changed this again into a tab structure, making it much more clear what all of the options were at any given time. And finally, number five was a text link that was bringing the user to another area of the application. And we just sort of redesigned that using visual affordance, making it blue, adding an underline, just so it's much more obvious at a glance that that's a clickable link.

34:10
Ray: So we're sort of winding it down now, and I just wanna leave you with a larger look at our refined HMI. It might seem visually subtle just by looking here, but by restructuring the project's content and navigation from the ground up, the results of usability are actually pretty drastic. So in the end, we hope that these steps can help you to design organized and intuitive projects using Ignition. And here are some additional resources which cover this topic in really much more detail than we're able to go into today. The first two are videos of our past webinars. The first is Design Like A Pro: Graphic Design Tips for HMIs, and this is really a great resource for improving the visual design of your interfaces. And the next video is a session that Steven gave from last year's ICC Conference, UX Tips for Industrial Applications. This really gets much more into depth of the concepts from the first half of today's webinar. And there's also a few books here we should recommend that you pick up. And the first is Don't Make Me Think. The second is labeled Information Architecture, and then we have The Design of Everyday Things.

35:17
Ray: And finally, we have this link here which you can use to join our own user feedback program, and so we'd really greatly appreciate it if you join this group. We use it to gather your input on new Ignition features and really just validate all of our design efforts here. And overall, it just helps us to be sure that we're building the right tools into Ignition for you. Alright, and with that, I'll pass it back over to Travis.

35:38
Travis: Alright. Thank you, Ray and Steven for that very good information about how to build better applications. So we talked a lot about Ignition today, and I encourage you guys to learn more about it by simply trying the software for yourself. You can simply go to inductiveautomation.com, and you can download the full version of Ignition for free. It'll simply run in a two-hour trial period that is infinitely resettable and you don't lose any configurations. So you can get a real proof of concept up and running and show these different techniques in action before ever looking at buying the software. And we have a really good tool online that is called our Inductive University, and it has over 600 videos that are short. They're targeted to really show you how to build and use various features of Ignition. They are designed to guide you through all of the steps that you need to learn. And at the end, you could even earn a credential, which is your first step on your way to certification. So it's really easy to sign up if you haven't already done so and you can start learning Ignition at your own pace. And it's a great free resource, so I definitely encourage all of you guys to check that out. Some of these concepts are in there.

36:52
Travis: I put a slide up here of our account executives. And here at Inductive Automation, we are really willing to give you guys a personal demonstration of Ignition. So we can show some of these techniques and how they would be put to action. If you've never seen Ignition in action as well, we're happy to answer any questions and to show you the product. So please call one of these representatives to get a personalized demonstration of Ignition. I've also put up there the panelists email addresses and should you have any questions, we can send these to help get answers to that. So now, it's time for Q&A. Let's first start with... We have a couple of questions in here. We have a question from Andrew. Is putting the navigation at the bottom of the screen excessively un-intuitive? Ray, Steven, I'll throw that to you guys.

37:43
Ray: Yeah, so this is Ray here. Thanks for the question, Andrew. I would say it's definitely recommended that you start from the top to the bottom, and that's just because of the user expectations that we talked about in this presentation. And you really just wanna reduce all the roadblocks that you can. There's really no reason to have it at the bottom unless... It really depends on your application, so stick to the conventions when you can. And unless there's a really, really dire reason for you to do so, I'd say definitely keep it at the top.

38:15
Steven: This is Steven. I have to agree with Ray. We've experimented with navigation and wizards on the bottom. One thing that we've found is that sometimes they're confused with footer elements, so people tend to kind of ignore and gloss over them, kind of going back to the idea of expectations. So I also don't recommend putting it on the bottom if you can avoid it.

38:35
Travis: In that same breath guys, how about alarms? A lot of times we like to put that at the bottom so they can see all the alarms that are currently active in a particular area. What's your feedback on that?

38:48
Ray: Yeah, so alarms I'd sort of clump into the utilities that we talked about, the type of navigation for utilities, and I'd place those probably again in the top right just based on user expectations, at least a jumping-off point to a larger view of those. So again, just clumping them along with other types of utility navigation.

39:05
Steven: Yeah, I agree.

39:06
Travis: Right, and it's a way of reducing a lot of clutter. The lot more you have on the screen, especially at once, it's gonna be harder for the operator to make the right decisions and to react fast enough. That's a good principle there. So the question from Dan, "What about the URL for the feedback page?" I'm gonna skip back just for a moment on that just so you guys have that URL here for the feedback. Definitely take a screenshot of that. We will also be sending out this PowerPoint so you can get access to it. I think there were a few questions of whether or not you're gonna get the slide deck, you will definitely get this. No problem.

39:40
Steven: To get to the slide deck, we post the webinar on our Webinars On Demand section on the website, and we will include a slide share of the slides that you see today.

39:51
Travis: Perfect. Alright, so the question from Jeff, "Are there any plans to put multi-touch gestures into your navigation for the future?"

40:00
Steven: That's a good question, Travis. That might be a good one for you.

40:02
Travis: Yeah, I'll take that particular question. So we are working on a new... Right now, our rendering system for the clients is Java, and we are working on a new version, Ignition 8.0, which is gonna have a peer web rendering client, which it will use HTML5 and CSS as how we render that. And part of that will be to definitely take advantage of the gestures. So we certainly have... It's an important part of it, we are looking into it, making sure that we can take advantage of it. Because if you're on a mobile device, you really wanna take advantage of the pinching, the zooming and the various things that are there, so we are... We're definitely looking at that. There's a question from David here, "Does Ignition have an easy way to incorporate status into the navigation?" And I'll kinda take a little bit of that. So depending on what we have, if you look at the header bar, say you have tabs up there, you can certainly change the indication on the tab, a color or the background, maybe putting an icon or something in there in each of the ones that would give some indication on that. Really, you wanna make sure you do it in a way that's not gonna be confusing to the operator. Ray, Steven, do you have an idea more about this?

41:17
Ray: Yeah, so that sort of goes along with the navigational principle of you are here, so you definitely want to visually show the status of your navigation, whether it be active, inactive or possible to be clicked. And as far as active goes, you wanna call that out using color, maybe bold text and underline, somehow make it very clear that that bit of navigation is active at that moment, and that can currently be done right now with the tab structure in Ignition. And I know in the new 8.0, we are working on additional powerful tools for you to do that.

41:52
Travis: Okay, thank you. There was a question here about whether or not you should put navigation... What you can actually click on in a database, and I'll take that one. I really think... I tend to frown upon relying on a database for the navigation of the application because of the sheer fact if I lose communication to the database or we do patching on that, that the application's rendered pretty much useless at that point because you don't know what the tabs are or where you can go. So I would tend to put the navigation inside of Ignition. Now, with that being said, a lot of people do have navigation that is a tree view style that they kinda tie to who's logged in and what areas they can go to. And I'd say as long as you have a plan on having a fallback that is native in Ignition, that's not relying on the database, then I would say it's okay. But other than that, that's the main concern with putting the navigation in the database.

42:47
Travis: And then as a side question to that, "Is it applicable to make the user adapt or configure the navigations himself?" And so this is more of the ability for a user to choose to set the navigation for themselves. And I'll first take a stab at it and then you guys can comment on it. I would imagine this is probably... They're not gonna know a lot of these design principles, and they're not gonna have done those stories and have the cards to really figure out what that navigation structure should look like. I would say it's probably not the best idea to do that for the main navigation, but there might be particular screens where you can build many different widgets that they could have on a home screen that they could pick from. So I don't know. Ray, Steven, what do you guys think about that?

43:30
Steven: It's actually a cool thought, and the idea of a personalized interface is definitely something that has gained a lot more attention lately. So the idea of, say, Joe might have 10 options but only has three that he ever uses, and having the ability to turn the other ones off and maybe come back to them at some future point, yeah, that's actually a very interesting idea.

43:54
Ray: Yeah, I agree. I think customizing the options is a neat idea. I would hesitate to customize the location of these things 'cause, again, your user doesn't necessarily have the knowledge you do as far as a designer approaching the problem, and you just wanna give them the best tools possible, the best placement possible from a usability perspective, and then maybe give them the power to change the content rather than the navigation's placement itself.

44:22
Travis: Okay, there's a question here from Andre, "How many monitors does Ignition support? Does the back button know which monitor I'm on?" Ignition 7.9 now has multi-monitor support natively and each of the desktops you open. So if you had, say, four monitors, four different desktops, one client, each of those... The navigation structures within each of those are independent, and you can of course have one desktop navigate a different desktop's screen if you wanna set that up. So the back button in each of those would know where they came from as far as that last main screen. So that's a good question. There's a question from Justin here, "I've read a lot about gray HMIs being good for operators. Yours have more color than I was expecting to see. What is your opinion on using colors on HMIs?"

45:11
Steven: So yeah, the gray HMI definitely comes from the High Performance HMI Handbook, and that's something that's widely used in the industry. And the issue sometimes is that it helps to provide guidelines for how an interface could work by giving you a limited set of tools that you can deviate from. I think both Ray and I feel that there are opportunities though to provide... If you kind of know the basics of contrast, proximity, space and all of that, you can actually deviate from that and add some life and extra color and context to your HMI. So there's room to deviate from that if you kind of understand the basic principles that the High Performance HMI is trying to push.

46:03
Travis: So there's a question here from Tom, "Are words preferable over universal icons, especially for hyperlinks to other screens?"

46:10 Steven: Yeah, so the issue with icons is that they really aren't universal. Sometimes, depending on what part of the country you are from or where in the world, your interpretation of what the icon means may differ, and it may involve a little bit of hesitation or this unknown element to interpret what the icon usually means. I find that it's usually best to pair the icon with a descriptive element of what it is. Having the two together seems to work out really well in terms of providing something that people can identify really quickly.

46:45
Ray: Yeah, definitely. That was exactly what I was gonna say. I'd say pair the two, definitely never use icons alone because, again, there's cross-cultural meanings for different symbols, and there's now thousands and thousands of icons and these icon sets, and they tend to get sort of abused in interfaces. So just, again, make it as dead simple as possible, and pairing that with the word itself tends to work really well for that.

47:10
Travis: So there's a question here from Eric, "How should you handle different screen sizes? Should elements re-scale with the window or be a fixed size?" Now, I'll start here while you guys are thinking. I know right now with Ignition, if you want to design for a desktop and a mobile device, typically it's recommended to have two different projects because the screen sizes are quite different and you can't fit as much into a mobile device as you can a desktop. With that being said, there's a lot of design principles, especially on the web, as far as where it knows the size it's at and it will adapt, and things may show or hide. And I know Ignition 8 is gonna be designed around those particular principles.

48:00
Steven: I've thought a thought on that. So going back to our idea of identifying the user and the context that they're using your interface in, you have to wonder why would one person be looking at your interface on a screen versus looking at it on their phone? And they may have... They might be in different environments, so that having the same interface work for both may not be effective. So think about, this person on mobile, is he walking around on a plant floor? Are his needs gonna be different from someone in an office looking at a similar interface? Another thought too, is that the expectation for each user, depending on the device that they're using, may be different. So on a desktop screen, it's very obvious that an alert might pop up on the top right. On a mobile device, it might be too small or it just might not make sense because mobile alerts don't tend to pop up that way. Or it might be in their pocket, so how are they gonna know? So you might think of a different type of alert, say, for that kind of context, like maybe a sound alert or a vibration or something like that. Just think about how different devices might meet a different need for the user.

49:17
Ray: Yeah, that's great. As far as re-sizing or having a fixed size, there's not really a perfect answer for that 'cause, again, it all depends on your project's context and the context of your user, but generally, yeah, you wanna design based on the context itself. So you can't really resize a 20-tab interface down to a mobile interface that just doesn't work because of the space constraints. So you'd, in that case, want to have a specific tailored mobile design for that user and their needs.

49:46
Travis: And that's usually how it's done. Separate projects in Ignition for... One for mobile, one for desktop. And those paradigms will always... You can have templates, of course, you share across the two and things that you can... So you're not designing things twice. But it is generally a good practice to do that then try to build one that fits everything 'cause it just is difficult. There's a question here from Daniel, "What do you think about master navigation screens whose main content is a bunch of links? Also, what about direct links from screen to screen?"

50:17
Ray: I think master navigation screens are a great idea as far as building out sort of the high-level structure of your HMI, it's a good starting point as far as jumping into the rest of the content hierarchy, sort of like a dashboard overview of your content. And as far as using inline links to jump between content, it's probably gonna be discouraged because that sort of buries them. And unless it's inter-linking between content that's at the same exact level within your hierarchy, for example in a news article jumping right to the next news article or something like that, that does work, but when it's these main navigation links that we're talking about which relate more directly to your project's structure overall, you're gonna wanna stick with the higher level header or sidebar strategy.

51:12
Travis: I would say that on the idea of having inner links in the windows, for certain processes it makes sense where you wanna go from one process area to another, but make sure it's not lost. Like they showed having that sub-navigation menu where you can just have different tabs for all those areas. You might go next, but it's tracking that you're going next to those different areas so the user's not lost, I think, would be really important.

51:35
Steven: Yeah, kinda going back to the idea of the master navigation, if you recall, we talked about broad and shallow navigation, this is pretty much what we're talking about. And you wanna make sure that while it's a good idea to use this style in certain contexts, you wanna be very careful about overwhelming the user with too many different options because it can be very difficult to parse. And it's hard to say at exactly what point it becomes too much. It really depends on the content and the user. So definitely test it out. Take two users and say, "Can you navigate this?" Or even time them to see how long it'll take them to find what they're looking for.

52:12
Travis: Alright, let's see, we've got time for maybe one or two more questions. "Is it possible or any plans integrating anything like Twitter Bootstrap to allow for responsive design?" Like I was saying, Ignition 8.0 will have responsive design built into that, so it's still in development. When that is released, you'll be able to see more about that, which... And always there's a few questions here when Ignition 8.0 is gonna be released. 2018, I'll just give you that target. Hopefully early 2018. Alright, let's see, there's one more question here about high performance HMIs. "Does Ignition more closely align with the High Performance HMI Guidelines or ASM Consortium?" I can certainly say that Ignition as a platform, we try to be generally applicable. We wanna be able to work in different environments, including in particular high performance guidelines. We have the tool set in there, things like moving analog indicators, sparkline charts, radar charts. Of course, the use of color and the navigation principles that we talked about today are just part of... Are a native part of the platform. So we can certainly follow these guidelines, but it is up to the developer to build it in that way, in which case we always recommend getting a book on the principles to understand clearly how they work.

53:29
Travis: Alright, there's one more question here from Andre, "Do you recommend displaying the most recent active or unact alarms, say, near the bottom of the screen? If so, should the alarm summary object be used and how many alarms should be listed? Four, five?" Kind of a two-part question, but again, that's about putting the alarms at the bottom of the screen. And Ray, you...

53:54
Ray: Yeah, I'd say, again, I would have an indicator somewhere higher up in the screen to indicate that it is a really high priority item because these are alarms, so you wanna bring your operator's attention to them by having them up in maybe the top right utilities area. If that maybe is just an anchor link or something that brings them down to your actual larger alarm table, that's fine, but again, the priority of your screens is intuitively top to bottom so you wanna be sure that things that need attention are somehow brought attention to them. And whether that's by an element appearing up at the top of the screen which then brings you back down, that's probably an okay strategy, but...

54:36
Travis: Well, thank you, Steven and Ray, for the very informative session here today. Thank you guys for attending. That's gonna be the end of the webinar here today. So thanks for watching here today. We'll be back in March, next month, for another free webinar about a new product release, so look forward to that. And that concludes our webinar. Have a great day.