Director of Sales Engineering
Design Department Manager
Mobile apps have become exponentially more important as smart phones and tablets continue to advance and become the dominant computing devices around the world. This means creating an app that is easy to navigate, visually appealing, and functionally consistent is more necessary than ever before. However, there is no user manual to tell you what to include in your mobile app or what structure is best for your purposes.
In this webinar, we'll present a comprehensive layout for building your new mobile app. Join us as we outline our best practices for mobile app creation and how to achieve great mobile interface design.
- Brainstorming processes for building a new mobile app
- Mobile app structures
- Mobile app prototyping
- Mobile app ergonomics and visual style
Kent Melville: Hello, welcome to today's webinar, “Design Like a Pro: Mobile-Responsive HMIs for Any Screen.” I'm Kent Melville, I'm the Director of Sales Engineering here at Inductive Automation, and I'll be your moderator for this webinar. With me today, I have Ray Sensenbach, who's the Design Department Manager at Inductive Automation. And Ray, can you tell us a little bit about what you do here?
Ray Sensenbach: Sure thing, Kent. Yeah, so I joined IA about six years ago, I was the first design hire within software engineering actually, and since I've been here, I've been sort of working on all things Ignition, improving the user experience across the platform. And more recently scaling up what is now the design department by staffing up and training and getting our ducks in a row. But yeah, I'm excited to be here today and demo some of the really neat things that can be accomplished in Perspective on mobile applications.
Kent: Yeah, thanks, it's great having you here with me. And here's the agenda for today's webinar. It's a pretty straightforward one overall. First off, I'll quickly tell you about our software platform Ignition, and then I'll be passing things off to Ray for the main portion of the webinar. He's gonna start by introducing the “mobile mindset” and how it relates specifically to industrial automation. Then he'll go through four principles of mobile UI design with some examples in the demo. And after that, we'll wrap up with some audience Q&A like always. And so if you have questions during the presentation, please type them into the questions area of the GoToWebinar control panel, and we'll answer as many questions as we can. If we don't get to your question in time, we encourage you to reach out to one of our talented account representatives who can help you get an answer. And this is a good time to mention that a recording of this webinar and the webinar slides will be made available within the next couple of days, if you wanna rewatch a section and share with somebody else or just refer back to any of these demo URLs. So let's jump into it.
Kent: HMI design is important, no matter which software you're using, but the examples and demos we have for you today are based on our software platform Ignition. So here's a little bit about it. Ignition is a universal industrial application platform for HMI, SCADA, MES, and IIoT. It's used by 57% of the Fortune 100. We have a couple claims to fame we talk about all the time, one being our unlimited licensing model, also cross-platform compatibility, we're built on IT-standard technologies, we leverage a scalable server-client architecture or web-based and web-managed with web-deployed designers and clients. We talk about our modular configurability, you just buy what you need, only pay for what you need, and also we have rapid development and deployment tools. If you wanna learn more about Ignition, we'll be sure to talk to you about it. Feel free to reach out to us on our website or give us a call, but today we're gonna go a little beyond Ignition, we're gonna talk more about design at a high level, and so for that, I'd like to pass things off to Ray to talk about mobile HMI design.
Ray: Thank you, Kent. So yeah, let's get right into it today. Good mobile design makes it really easy for users to see and control their system right from their phone, but making a good mobile design isn't necessarily easy. So today I'm gonna cover some of these best mobile design tips for creating interfaces that will deliver that great user experience. And sort of a quick disclaimer on the tips themselves, just remember that they're tips and patterns and not necessarily rules, and while the best practices are incredibly useful today, we know, especially in our industry, that all applications are unique. So you might be bending some of the rules today or breaking them, and that's totally okay. The reason being that our industry has really, really unique problems and functionality that are gonna inevitably require really unique design solutions.
Ray: And speaking of our industry, we all sort of know that industrial automation tends to cautiously trail maybe a year or two behind other early adopters of technology, and for good reason that we're all pretty aware of. But as a result, our design patterns within our niches are sort of largely unexplored, so you're still gonna need to get creative and inventive with your solutions. But lucky for us, mobile design at large, and the best practices which guide it, are in a really, really great place, and the advantage for us, again, is that there are plentiful resources out there for learning how to design well, in general and for mobile specifically. So with that in mind, today, I sort of cherry-picked patterns and tips which I feel are gonna be really applicable for this audience specifically.
Ray: Now, I just wanted to give a quick overview of a recent ICC session and the content that was talked about there, because this is also available through our website, and I'm highlighting in purple here those that we're gonna be discussing today. So again, that ICC session is available through our website, so if you wanna dive deeper in this after today's webinar, feel free to do so. But yeah, what we did today was we took things a little bit a step further from that ICC session. Definitely, after I presented we got a lot of audience questions about, “How can I actually build these tools and design patterns that you're talking about within Ignition within Perspective?” Or “Can it really be done?” because some of them are so unfamiliar or not necessarily clear. So today, like I mentioned, we took things a step further and what we did was executed a lot of these principles within a real Perspective application. So I'm gonna be going through the principles and then switching over to a demo. And going back and forth and showing you these things in action.
Ray: Alright, so let's start by getting ourselves into this mobile mindset, which Kent mentioned at the outset. So it's not too different from a general design mindset, but in the mobile context you really need to be laser focused on two things. The first is what your user needs and the second is what your software is being created to do. So this really is about boiling down information that someone might be looking for, and then allowing them to execute the tasks or actions that they might be needing to take based on that information. And additionally, within mobile, you might start to get into the conversation or struggle with the idea of feature parity. Should your mobile app have the same content and features which a comparable desktop application might already have? And my inclination is that yeah, definitely feature parity is the ideal solution.
Ray: When designing for mobile it shouldn't necessarily mean delivering less to your user, but that said, it might require you to think about things a little bit differently or approach them from a different way. You'll need to really streamline information and distill things down to what's absolutely necessary. And the reason I say that feature parity is the ideal solution is because if you can do that for your mobile app, the same should probably be done and carried over for your desktop. It's sort of this mobile-first approach. So interface design is really just this balancing act between visual form and technical function. It's the bridge between the system and the user. So there's really a lot to be considered, especially when, on mobile, in the context of mobile every element is really, really critical because of that smaller form factor. And if your interface is difficult to use, people won't use it, right?
Ray: Regardless of all the amazing complex functionality that you have built in. So how can we meet the needs of our users when designing a mobile UI? That is where these sort of four principles of design for mobile come into play. So I'm gonna highlight a few tips and patterns within each, followed by those demos that I mentioned within a real Perspective mobile app. Alright, let's jump into the first one here, which is all about user control and freedom. You're gonna need to place your users in control of the user interface. So a tip within this section is creating an easy-to-navigate interface. This is really paramount to user control. You want to design an easy-to-use navigation structure. And navigation should be clear, and really should encourage exploration. You want your users to be able to find all these amazing tools that you're building for them.
Ray: Now, context is really the key to a good navigation system and how you provide users that context is from little UI visual cues, and this includes things like page and section titles, which are consistent and clear. Also things like, "You are here" navigation indicators. This can be something like a highlighted tab or navigation item and a menu that lets users know what screen they're on in the context of the screens and pages around it, and the information architecture. You could also include things in this bucket, like global search or filtering controls. These provide again that control and sense of freedom for the user, and you're really providing them with tools that they need to control what they're seeing next and what they need to find, so you're putting them in the driver's seat. And all of these cues within navigation add up to that good user experience and comfortability with the application.
Ray: And I know it can seem a little bit vague, so how can you kind of test or ensure that you're hitting the mark? How can you test that your navigation is intuitive? So there's this sort of quick and easy method, which is semi-crudely known as the “trunk test” that you can try out with your designs. So the idea behind the trunk test is that if you're sort of thrown in a trunk and driven around a city and then dropped off somewhere, you should be able to quickly look around your landscape and answer these four questions: Where am I? How did I get here? What can I do now that I'm here? And where can I go from here? So all of these things should be solvable, or provide you the context within your visual landscape, and surroundings to answer the questions.
Ray: So you can try this out by grabbing some low-level screens in sort of dusty corners of your application and run through these questions. And I'll walk through an example, like I mentioned shortly with our demo. Another portion of putting users in control is this idea of making actions reversible. So in a perfect world, user actions are reversible and forgiving, so the user should be able to quickly backtrack whatever they're doing. This allows them to explore your application without that constant fear of failure. And when they know that errors might be able to be easily undone, it again, encourages that exploration of unfamiliar areas. And on the contrary, if a user is being extremely careful with every action that they take, it leads to slower exploration, and sort of a tense, stressful experience that doesn't help anybody in the end. So a solid example of these reversible actions are undo and redo actions or prompts.
Ray: So undo lets users make changes and go back step by step through changes that were made and redo obviously, just the opposite, take them forward through the stack of actions. So a real-world example that you're seeing in this image is sort of Gmail's notification on their mobile app for when a user deletes a message. This may have happened by accident, so they always provide this banner as sort of an emergency exit to undo that action. And what it does is it allows somebody to potentially leave an unwanted state, no harm done, and they can continue going about their workflow. Additionally, you wanna be providing really informative feedback throughout your user interface. Feedback is usually associated with points of action. So for every action users are taking with the system, you wanna show a meaningful and clear reaction. And there's sort of two subsets of this where the responses can be slightly different.
Ray: So one is a frequent action, which happens all the time throughout the application. For example, pressing a button on mobile. So it's essential to provide some indication that that button has been pressed and acknowledged by the system. And that might be as simple as a changed press state, a hover state if you're on desktop, or a focus state as they are pressing the button, things like that. So it's subtle, but it still lets them know that, “Hey, my button click or press was registered by the app and something is going to happen.” And then the flip side of that is sort of infrequent or more significant actions where your response from the UI should be a lot more substantial. So for example, when filling out a password field in the signup form, a good UI might inform users of all the requirements for their password and whether they have successfully created a good password yet and can move forward in their flow.
Ray: It's definitely louder visually in terms of UI and interaction design, but because it doesn't happen often, it's kind of a welcome guiding principle and a guiding interaction pattern on the application. Okay, so that's the first principle, the user control and freedom. Now I'm gonna jump into a quick demo and show you how we've built these bits out using our Perspective Module. So this is our demo app that the Sales Engineering team has created. And first I wanna talk about that intuitive navigation. So I'm gonna highlight a few ways that this application is intuitive navigationally. First and foremost, just the page titles, right? This grounds users, lets them know where they are. Today's Work, this is my homepage, my dashboard, it's clear. If I go over to other main sections of the application, I have that consistently placed page title.
Ray: Now I know I'm on Work Orders. And same thing for Assets. Additionally, we have global actions, which are always available in the top right here. And these are a good way to let the user know like what global actions they can take from any time. And what they are is important as well. So again, user control. We're giving folks a way to search the entire application to look for work orders or assets. So if I'm looking for “fix” for example, hit enter there, I'm able to quickly get to where I need to go and I have that freedom of control without having to muck through navigation and pages and scrolling if I know exactly what I need. So that's a global action. Additionally, we have a global action for managing authentication states and high-level global settings such as steaming.
Ray: Additionally, we have navigationally, consistent naming. So we're always calling work orders, “work orders,” always calling assets, “assets.” When we can we're associating these icons with those words as well so that it's always consistent throughout the application. And structurally you'll notice we have consistency as well. So there's always subheaders above chunks of content and they use consistent use of icons and spacing around them to have that sort of clear visual hierarchy. And finally, I wanna talk about the navigation bar. Again, this is a global element, it's always available. And because we have this active kind of, "You are here" UI state, when I'm within one of these sections, it's always clear if I walk away and come back or close the app and then come back, which section of the app I'm in just at a glance.
Ray: And then let's circle back to our trunk test we talked about for navigation. If we're looking at this screen for example, can we answer those four questions? So where am I? Page title, I'm on the Work Orders page and this main nav is highlighted, making it clear. How did I get here? It's clear that this is a top-level screen, because the main navigation again reiterates that as well as the page title. What can I do here? So right away I know that I have five work orders assigned to me and there's a clear primary action. So I'm able to create a new work order or based on following mobile paradigms, it's clear that I can click on a work order and dive a level deeper into its details. And where can I go from here?
Ray: And this example comes down to these other sections of the website from the main navigation and then again that kind of user control through search to go anywhere I need to within the application by just typing in a few words. So I think with the trunk test we're doing pretty well. It feels pretty intuitive and the UI makes it clear to me right away how the application works. Okay, now I wanna talk about informative feedback. So I mentioned two types of this: infrequent and frequent actions. So a frequent action in this use case might be just navigating around the app. It's hard to see in the emulator, but we do have press states on these buttons that let the user know that their actions have been registered and something's happening behind the scenes.
Ray: Additionally, we have some subtle UI and UX interactions like when I did type in that search and hit enter, you'll notice a loading state that lets me know that the system has registered that search and is doing something in the background looking for my results. And then I also wanted to highlight this filters bar. So when we do click the filters bar within the search, I can filter to just work orders or just assets or view all, this remains visible as I'm searching. And the blue color change within the filters icon in the search bar lets me know that a filter is applied and active and my results are being filtered.
Ray: And for an infrequent action to show informative feedback to the user, we have this idea of... And let me log in as the correct user, sorry about that. So we have this idea of inline validation. So if I'm creating a work order, let's call it “test,” I'm the requester, the location is headquarters, let's put in some nothing. But if I go down to the completion date and if I happen to set this to a date previous to today, I get that loud interaction state inline on my form, lets me know that there is an error, it needs to be fixed. And the error message does a good job of explaining what needs to be changed and what the solution or path out of this is. Additionally, I'm unable to actually create a work order when there is this error.
Ray: So that disabled button for create gives me, again, informative feedback about how I can fix this mistake. Right, and speaking of search, I just wanted to highlight a few of these other search resources 'cause I get personally asked about this a lot. “How can I accomplish search within Ignition?” So these are two Ignition Exchange resources that are available now, projects from Flexware as well as our own Sales Engineering team. The links will be in the slides that'll be shared out, but they both have these nice search UIs which filter maybe lists of items, or zones in this case for our HVAC building demo project. And yeah, just wanted to highlight the Ignition Exchange and for those of you who aren't aware of it or don't know what it is, the Exchange is this repository where developers from Inductive Automation and the Ignition community as well can share Ignition resources both publicly and privately, all for free.
Ray: So it's really worth looking at because there's a lot of great assets in there. You know, case in point, this Perspective HMI framework by Flexware and this building automation demo project went up fairly recently and it's very, very neat. Great, great UI on that one. Alright, another demo around reversible actions. So looking at user control, let's look at this implementation. So again, on this work order’s details page or details page, I'll click in. If I were to update the status of my work order from active to maybe in progress, you get a confirmation dialogue first, and then once I update the status, a nice inline banner, which is showing me that the status was updated, the system registered it, I think in this case it presents for five or so seconds. Obviously that's up to you. But you see that undo action there that can quickly undo, I press it, the state of the work order reverts back to what it was. So if I happen to update it to the wrong status, hit undo, and you go back in time. No harm, no foul.
Ray: Alright, so onto the next mobile design principle. Let's talk now about making it comfortable for a user to interact with the application. So one idea within this is not asking for users to enter data that they've already entered or that your system already has registered about them. So users are really easily annoyed by tedious data entry sequences, especially when they have already provided information, and especially, especially in the mobile context when you don't have your keyboard, it's a little bit slower to enter in data. So a good user experience and user interface on mobile definitely is performing the maximum amount of work while requiring a minimum amount of information from users. And a big part of this is smart defaults, so making smart assumptions on data entry forms about what the user might enter or what you already know about them, pre-filling form fields for them, saving some time. Additionally, a good UI is an accessible UI. And this really... Designing around accessibility enhances the usability for all groups, not just those that might need it visually, and color is one of these elements of design that has a really strong impact on accessibility.
Ray: So approximately 10% of men and 1% of women have some form of color blindness. So when designing interfaces, it's better to avoid using color as the only way that you're conveying information. So I wanted to touch on this idea of double encoding. You can see in this error message here on the top, it's doing a good job of double encoding, so I'm using both an icon and a text description, as well as the color red, it's really triple encoded, to visually show that there is an error and explain what the error is to the user. Speaking of errors, I mean, you wanna be engineering for errors in general. So it's one thing on inline validation, but also just throughout the application, you wanna account for system errors, user errors, and design into your flows, these solution paths. And messaging is very, very important within error messages. You can see in this top example on the slide. We see these all the time. They're frustrating, you don't know what happened, you don't know what to fix. And on the bottom, it's just a much more clear interaction with the application, and it gives the user the route to fix things and move forward.
Ray: Additionally, you want to be protecting your users’ work and data whenever possible. So that might mean something like confirmation dialogues whenever the user is performing destructive or irreversible actions, or you could go another route, like maybe Dropboxing this screenshot here, which what they do is they save deleted files for 30 days automatically, and those files can be recovered within that grace period, bringing things back that folks might really be relying on or need or plans change, so maybe they didn't need it one day, but they did the next week. And this allows them to retain that data, retain that information without losing it.
Ray: Okay, back to the demo. Let's talk about these comfortable interaction patterns that I just went through. Okay, so let's look at some smart defaults. We already looked at our Create New Work Order format bit, but what you might have noticed, and I hadn't highlighted yet... This already has my information typed, but the two fields for requester and location, users select lists and instead of just putting in select dot dot dot, as a placeholder text, and forcing the user to make a decision and choice every time, you can do a few things here. Like in this case, what we're doing is taking the authenticated user for the application and pre-selecting them as the requester. There might be corner cases where the person requesting is not using the application, and in that case the user still has the control and freedom to select another person.
Ray: Same thing for location, in this demo the idea was to choose the closest geo-located location that you have in your system to this user, as they create the work order. Again, hopefully that helps folks save time here and there, and definitely doesn't add time to the flow, so it's kind of an easy win in a lot of cases, if you're making these smart defaults and assumptions. Okay, and on the note of accessibility, which I talked about, we already looked at that example of a good inline validation, I just wanted to reiterate that we're using the same patterns here where we're double encoding the error as we have the icon as well as the message, as well as the color red. And so this just really, really highlights and makes it clear that this is in an error state, something needs to change to move forward.
Ray: And I didn't mention yet the idea of reserving the use of color, so I mentioned color is very, very powerful in mobile design and design in general, but with error messages or informative, basically with any content or data that's conveying a meaning within your system, so errors, warnings, success, information blurbs, things like that, there's sort of a few categories, but you wanna reserve those colors for just that type of information. So I know when I see red in this mobile application, it's an error. I don't have to guess that it might be just some prettied-up form. I know intuitively it's an error because red is used nowhere else in the app. And additionally on accessibility, there's this idea of accessible color palettes. So the WCAG has this many, many tools out there that you can use to test your color palettes and make sure that they're compliant with color contrast. So this one, the link is Contrast Grid, and basically, this helps everybody out there, especially in the industrial environments that we're working in, bright sunlight, dark rooms, rooms with many, many monitors and fluorescent lights. There's so many odd use cases where folks are gonna be using these mobile applications, so you wanna definitely test your color palettes and make sure that how you're using them is accessible, making sure the colors on the foreground versus background are dark enough to be able to do that by users.
Ray: Alright, and then looking at the idea of engineering for errors. So I kinda showed it on accident earlier already, but we have this idea that this user, R. Sensenbach is authenticated and can create work orders. However, if I sign in as somebody else, in this case, Bob the Builder. So Bob does not have the user privileges or admin privileges to be able to create work orders, so we have engineered for that use case and designed a nice little message to make it clear that that is what's going on in the system. That's why they're unable to create a work order. Alternative routes that you might do, which I think would be a little bit less successful would be just removing the button. You definitely want your application to be consistent for all users, so you can do things like disabled states, that might be one solution.
Ray: But again, with a disabled state, the user gets no information about why that button is disabled and it's a primary action within the application. So we have to create a mobile dialogue that lets them know, again, with our red error text that's only used for errors, what's going on here. They don't have permission. And then down below within the message, know what they can do to solve or circumvent that issue, in this case, talk to their gateway admin. Okay, and finally, within this, I wanted to talk about protecting users’ work. So we have that as a demo within the Assets category.
Ray: If I select an asset, and then maybe one of the actions is to delete that asset, first I'm hit with a confirmation dialogue again, which gives me a little bit information about what my deletion action... Sorry, what the repercussions of it are. In this case, the asset will be deleted, but I get a nice blurb about, "Hey, this is gonna be saved within our deleted assets section of the home page for up to 30 days, in case I need it back." So now at least I'm aware that that section is available if I need to go back and get things later. So in this case, I'm gonna just go ahead and delete that asset, and then show you on our home page, where we have this recently deleted shortcut. And then I can come in here within 30 days, look at what I've deleted, assets, work orders, whatever it is, multi-select and then go ahead and restore them. And again, I'm given this nice inline confirmation banner that my action is registered. I can undo the action if I select it all on accident or something like that, so that can be a really nice way to protect your users’ work and data in case they need to access it later.
Ray: Alright, on to the third section. I'm actually gonna combine these two a bit and do one final demo after I go through all of the principles within them, 'cause they're a little bit shorter. So starting is cognitive load, cognitive load is the amount of mental processing power that's required to use a product or application. It's all about removing barriers, which can make it difficult for users to interact with your user interface. Now, good visual organization really improves usability and more specifically, legibility. So it allows users to quickly find the information that they're looking for, and because of that, they're able to use the interface much more efficiently. So when designing layouts, definitely suggest you construct some sort of grid system or visual rhythm, which can help to avoid that visual clutter that we sometimes find ourselves in. You wanna apply general principles of content organizations, such as grouping similar items together, numbering lists of items, and using headings and prompt text. So this is all about avoiding presenting too much information at once, and you can even use some of these progressive disclosure patterns that we'll talk about in a second to accomplish that.
Ray: Oh, yeah, I just hinted at it, but the next sort of principle or tip is around progressively disclosing information. This is a really good tool to manage complexity. What you're doing here is deferring sort of advanced or rarely used features to secondary screens, which makes the high-level application much easier for users to learn and grok. So this can be applied all over your app in many, many different ways. My examples here show what we have for the ICC 2022 conference website. You'll notice sessions are collapsed by default, you get the time, the most important information is bubbled up to this top. You get the time, the title of the session, the type and track. But then users are able to opt in to exploring and getting more details and specifics about each session by expanding the accordion area.
Ray: And then the second example here, this is the DoorDash mobile application, and they do a really good job of using horizontal space, which is oftentimes forgotten about or neglected in mobile apps. So they're showing the most common or popular items first in the list, but again, they allow users to opt in to exploring more by horizontally swiping or scrolling through these lists. And I just want to highlight this horizontal scroll in mobile apps, 'cause it's a really great way to save space, gain more space and real estate that you might not have had with just a big, big vertical scroll. And it's a very, very natural input method while you're on mobile, you just swipe your thumb naturally left to right across the screen, so it's a nice intuitive experience.
Ray: Okay, so I said I was gonna demo the two together, so let's jump into the final principle of mobile design, which is making user interfaces consistent. Consistency is a very, very essential property. A lot of these other themes and tips and principles kind of lean into it. But yeah, the main idea around consistency, visually and functionally, is the idea of providing transferable knowledge. So users are able to transfer existing knowledge they have about using just applications in general in their daily lives, into your product. So the first sort of side of the coin is visual consistency or style. Your visual style should definitely, definitely be consistent across your application. You wanna be using the same colors, fonts, icons, all throughout the product. For example, a Submit button on one page of your application should look the same on every other page. You don't want folks having to guess what button does what, because it looks different or is treated visually different in different places. Similarly, any color that's used to convey meaning should be strictly applied. I believe I talked about that a little bit already, but in this example of color palette you'll notice that red is named error, it's not just red. Naming colors as well, is a powerful way to sort of ensure that they're applied the same way by maybe other engineers in Ignition.
Ray: Okay, so the other side of consistency is about behavior or functional consistency. So this sort of just means that interactive elements within the app should work the same way throughout the interface. So menu items and lists, sorting and filtering tools, you definitely want to template and reuse those everywhere that you can, so again, users aren't guessing at how things work, or that they don't have to relearn four different ways to filter lists of items throughout an application, that's just frustrating. Too much work for everybody. You as an engineer have to maintain four different ways to filter items, users have to learn four different ways, it's just frustrating all around. So having that functional consistency in your controls is pretty powerful, even though it feels subtle.
Ray: Okay, then to demo a few of these principles of cognitive load and consistency. Okay, so progressive disclosure, there's quite a few examples of this throughout the application, so I just wanted to highlight a few and how we're using them. Starting off right here on the home page, we have, like in the DoorDash application, this nice horizontal scrolling list of filters. So these are saved past filters of work orders, the user is able to bubble up automatically. They're most frequently used filters to the top of the list, and others that they've saved are available with a nice easy thumb swipe.
Ray: So you can imagine the size of these cards is a little bit big and having them all just vertically centered or something like that on the screen would pick up a lot more room than is necessary, so we're utilizing that nice progressive disclosure pattern there. Additionally, on work orders, this is a little bit more subtle, but the work order itself, these cards, they are similar to the ICC website example I showed you earlier, they're sort of bubbling up to the top front-level page here. The most important information about this work order, which gives the user like just enough context about what they are, the status of them, in this case, who it's assigned to, this is sort of a user avatar bubble with initials, and additionally their numbers, which are used to reference them throughout the system. And then clicking into any work order gives you a lot more context, a lot more details about that specific work order. So you've got the details. We also have tasks of how these operator or employee can complete or start these tasks that are assigned to the work order. And finally, there's a whole historical record of changes that were made to the work order, comments on the work order.
Ray: And additionally, you can enter your own messages. See Bob the Builder right now just posted, "Hi there." So again, that's just a nice way of progressively separating out most important information from what a user might want to opt in to learning more about by taking an action. And then finally, I wanted to highlight on the Assets page, we also included these headers here being extendable and collapsible, so a nice way to do this might be to by default, only have the user's most nearby location pre-expanded and then allow them to opt in to expanding other locations with a press. Okay, and then visual clarity, this is a little bit hard to show in the actual emulator there, but I took one of the screens and did this sort of box model overlay on it. So this is showing how our consistent use of both type sizes and spacing and margin and padding, and the icon sizes are all consistent throughout the application for top-level actions. It just gives you an idea of visual rhythm sort of, so your eye is easily moving around the application and interface. It allows your user to just have that feeling of a slicker experience, because everything is consistent and clean. So in this case, we're using an eight-point grid system, which is a really powerful one to use.
Ray: I know a lot of people by default, go to 10, but if you start with eight, it sort of gives you a much more divisible number, so it's definitely a pretty common product design practice to leverage this eight-point grid system for sizing elements and padding and margins. It's just a little bit more flexible than a few of the other more round numbers around it. And then visual consistency, again, a little bit hard to demo in the product, but I think we sort of saw it throughout. Just this idea that all of the UI components and inputs and toolbars and task bars are styled exactly the same way, regardless of the pages and screens that they're presented on. So we're seeing buttons here which are consistent, all of our inputs are the same height and with the same corner radius, all these really subtle things that again, really, really add to the polish and intuitiveness of mobile applications, so having that visual consistency is a pretty good tool to have in your toolbelt.
Ray: Okay, so that sort of sums up my four categories of principles. I wanna close with a few thoughts before we wrap up and go over to Q&A. So I didn't go into it in this webinar specifically, but I wanted to reinforce the importance of the strategy and planning steps of mobile apps before you get into Ignition, before you get into UI design. I definitely encourage anyone who's putting on the designer hat to execute user flows, wireframes, and prototypes. And while these things might not be familiar to you initially, really this design stuff is pretty easy. It's all about just talking to users, iterating on your solutions, and leveraging best practices. And finally, we have the slide which includes a few links to some of the demos and Ignition Exchange resources that we looked at today. So definitely click through to these, go in, play around, and explore some of these things for yourself, see how they're built. And you do not need to scribble this down right now because as Kent mentioned at the outset, these will be available tomorrow on the IA website in the resources section. So with that, I will hand things back over to Kent to wrap us up and we can get to some of your questions. Thank you.
Kent: Yeah, Thanks Ray. If you've never tried Ignition for yourself, you can certainly download it, grab the most recent version from our website. Currently, that's 8.1.24, has some really cool IdP security improvements. So hope you go check that out, and it only takes three minutes to download and install and runs in a trial mode, you can use that trial for as long as you want, absolutely free, and start playing around with all these great design tips that Ray showed us today. Once you have downloaded Ignition, we also have our free online training website called Inductive University, where you can learn all about how to use Ignition. We've got hundreds of free training videos there. So you can learn Ignition step by step at your own pace, and we also have a pretty comprehensive online user manual that you can refer to any time. For those of you are outside of North America, we want you to know that we have a network of International Ignition Distributors who provide business development opportunities in sales and technical support in your language and time zone, and so to learn about the distributor in your region, please visit their website or contact our International Distribution Manager, Yegor Karnaukhov.
Kent: Alright, so also if you just wanna talk to us, you can reach out to any of our account executives here at our headquarters in California, please call 1-800-266-7798. And with all that being said, let's jump into some of the questions you've been asking. Just as a reminder, if you do have questions you can still go to the questions panel within the GoToWebinar interface, and you can type in your questions there. But we did get some questions that were posted throughout. And so Ray, a lot of people were interested in how you were demoing your application, specifically using the Android emulator. So can you talk a little bit about what that was and how you got that set up?
Ray: Yeah, sure thing. So I actually just set that up yesterday, the sales engineers folks got me going on that, and I'm definitely going to be using it a lot more moving forward. But that was... What I did was just install a Android Studio application, which is available on their website, and it's essentially just an emulator. What you do is download the Ignition Perspective mobile application APK from our website. In the download section, you can just search for APK and it allows you to drag and drop that into this application as an emulator, and what we're doing within Perspective is just... So essentially, this is just an Android app running on my desktop. So you can load any number of mobile applications into it. You can use Chrome all the built-in stuff to Android, and additionally, you can grab that APK loaded in here, and what we did was just pointed to our demo application server, like you would with any normal Perspective application. It's pretty straightforward, but pretty powerful tool for testing things out.
Kent: Perfect, and people were impressed with the application, people were asking, “Will it be available on the Exchange?” like you showed on your last slide there. Yes, this application will be coming to the Ignition Exchange. With that being said, we started building this about a week ago, and so other people are asking great questions like, “Can you show me an example of it running on desktop?” This is a mobile application demo, and so while you could open it on a desktop, it's not optimized for that. So it wouldn't be a lot to show there, but yeah, we'll be excited to share this with everybody on the Ignition Exchange. And then another question for you, you chose to use the pixel 3 emulator, but all mobile devices have different sizes. Any strategies or recommendations you have around how to future-proof the sizing of the mobile screens as far as, “Do iPhone pro seem to have some problems?” is what William was saying. But yeah. Any thoughts on the size and mobile devices and how to plan for that?
Ray: Yeah, absolutely. So you're right, I chose that device kind of at random actually, which is a good example of the flexibility of Perspective and specifically the Flex Containers. So this mobile application is very, very heavily using, I think maybe even only using Flex Containers. And what that allows us to do is have that built-in flexibility, I mean there it is, right? So we could have chosen any of those other devices, the mobile application would have just changed itself, grown or shrunk to form-fit the device size, and obviously up to a certain point. If you bring it up on an iPad or a much larger screen, it will work and grow, but at that point you probably wanna build in a Breakpoint [Container] or something, and then start doing a little bit more of mobile-responsive best practices, which we actually have a lot of information about on the Ignition University courses as well, but... Yeah, it was tailor-built for mobile. But with that said, it should present really well across any mobile form factor that's currently on the market up to a certain point. So the main advice there is to use flexible or Flex Containers, so that you don't have to assume the exact pixel device sizes, that's definitely sort of a bad practice, and it's so easy to build in that flexibility that you might as well be doing it.
Kent: Yeah, and somebody else, Benjamin, you've commented that Chrome DevTools has emulation built in for many devices, absolutely. That's a great way to do some quick testing with different devices and different sizes. We ended up going with the emulator here, just because it can truly emulate the mobile app, which has different features, and sometimes the touch screen interacts a little differently than just what the browser emulates, but yeah, absolutely, that's a great tool that I use pretty much every day. So great note there. Ray, another question is, people saw that you mentioned in your menu that you could toggle to dark mode. And people were just asking, “Is that out-of-the-box feature of Ignition, or how does theming work?”
Ray: Yeah, absolutely. So theming is provided within Perspective out of the box. I think we ship currently with six built-in themes, three of which are these dark mode themes and three of which are their counterparts of light. And so that is built in out of the box. You have to do maybe a binding or two within the designer to switch that parameter or property in the session, but it's very, very easy to do within this actual demo, like I mentioned we built it in about a week. So we haven't... That was a little bit deprioritized. I put the UI in there, the toggle. I think we probably will be adding it within the next day or two, hopefully before it goes up on the Exchange, but yeah, to answer your question, it is built into the system, Perspective. And you can also build your own custom themes, we provide access to the CSS files, you can pretty easily duplicate and make some really beautiful custom branded applications in Perspective.
45:27v Kent: Perfect. Reese had asked, he really liked the horizontal scroll concept, let me ask, “How was that implemented? Was that a carousel that was used, or did you just hide the scroll bar?” You wanna talk about that or I can talk about it a little bit too?
Ray: Yeah, you can talk about that one. If you wanna take it.
Kent: Sure, so certainly we do have the carousel available. In this case here, we played around with scroll bars a little bit, and actually if you open this up on just a normal mobile browser, you will see a scroll bar there. So yeah, it could be done in a couple of different ways, but in our case, we have... I don't believe it is a carousel component. Another question, we have a lot of people that are asking just for advice on, if I have a desktop application that's already built, and I'm now trying to add mobile functionality to it, what are the best ways to go about that? People have talked about like, “When should I use breakpoints or which things should I consider?” Yeah, all that kind of stuff, so any comments there, Ray?
Ray: Yeah, so it depends on what your desktop application is built in currently. If it's currently a fully fledged desktop application built out for years and years in Vision, you probably are going to need to rebuild it more or less from scratch within Perspective. And I say that more so to the layout tools that you're using, the front-end visualization of your content, definitely the scripts that you've written, the bindings. A lot of those things can be very, very easily transferred over within the designer, so they're not totally lost. It's more of just the layout flexibility tools that Perspective Module offers are much more obviously, tailor-built for this responsive environment. And I had another point.
Ray: What was it? Oh yeah, so definitely. When do you use breakpoints? When do you use what containers? Everybody has a different method of doing that, I would definitely say check out the IA demo project, ia.io/demo. Sales Engineering has a plethora of mobile-responsive, very, very complex applications on there, which you can just either inspect in your browser or just download on the Ignition Exchange, that's a good way to tease them apart, see how things are done, but in general, with really small screens so that you can account for the spectrum of mobile, I would say leverage Flex Containers a lot. And then for those bigger breakpoints, when layouts shift outside of the scope of just shifting content around, which Flex does really well, maybe embed those Flex Containers within a Breakpoint Container at those larger points. And in general, maybe one is good enough from mobile to desktop, if you have a really dedicated tablet market or section of users, it might be worth doing three breakpoints total, so you have mobile and then tablet and then a desktop experience, but the combination of Flex and Breakpoint is usually all you need to get as far as you need to with mobile-responsive apps.
Kent: And one correction to that, the URL demo.ia.io, if you wanna go access that demo application. If you go to ia.io/demo it will be a nice form for you to fill out with some nice validation there that you can see that you talked about today, to get a demo from our Sales team. But yeah demo.ia.io will show you that online demo project. Also, if you download our mobile app for Android or iOS, it'll point to that demo application by default as well, and somebody asked for that native app. “Do new versions get rolled out for that app?” And the answer is yes. We are periodically releasing updates for that. We don't update the app every time we release a new version of Ignition, but yeah, we have updated it several times, both for Android and iOS. “You mentioned base 8 instead of base 10 for spacing. Do you typically base spacing on pixels or would you ever base it on percentages?”
Ray: Good question. I definitely personally use pixels. Percentage, you might use, I don't think for necessarily like content elements, so text, buttons, those things, but the reason being, because if you're doing mobile responsive, the array of screen sizes is so, so large, and especially once you bring Breakpoint Containers into the mix, a percentage on your mobile Breakpoint might be centered nicely, looks good as a button, but then when you jump to desktop, that new percentage that it's referring to is wildly different. So you just have a little bit less control over layouts with percentages and additionally, percentages are good for maybe just centering really big layout chunks of content, so maybe on ultra wide monitors, you'll notice sometimes there's a maximum width that content block goes and then it just sort of fixes itself there, and centers within your screen that generally relies on percentage-based spacing and that's a good use of it. But yeah, I think pixels gives you a little bit more control. We have seen things like targeting high DPI devices and then serving up a different scale of pixels, maybe it's like all of my eight pix content times two on high DPI devices, so there are some uses of a combination of them there, but in general, I definitely refer to pixel-based spacing and percentages compared to percentages. Excuse me.
Kent: Just to add to that, I think that HMIs... Sometimes we design HMIs so that it'll always take up the full screen and there's no scrolling, and in those cases, percentages may make a lot of sense for some things, but often as you start getting to mobile design, it's a different paradigm because scrolling is your friend. You're not trying to have it only take up this much of the screen, and then it's always fixed. It's expected the content will overflow and then the pixels work really well. I also want to comment, a lot of people have talked about, once again, just how to design effectively for both desktop and mobile. We do have some other webinars out there that talk about this little bit, so be sure to check out all of our Design Like a Pro webinars. This one was really just focused on the mobile aspect and the design paradigms for that, but definitely, I also wanted to highlight within Inductive University, we have some great videos that talk about the different container types inside Ignition, and I'd really encourage you to go look at the video for Breakpoint, I think Breakpoint is a great way to do...
Kent: When you've got really busy screens, you need to do them on mobile, the design is just gonna be fundamentally different. So a Breakpoint Container allows you to create a fundamentally different screen and a different experience for mobile versus desktop. And if you go to our online demo project and go to Water/Wastewater, there are a bunch of examples of Breakpoint Container being used. Much of the rest of the project just leverages Flex Containers or Column Containers, which take the same content and just reorganize it for mobile. And so whether you should be using Flex or whether you should be using Column or if you should be using a Breakpoint, is really gonna be dependent on the type of content you have on that page. And so you don't need to say, I'm gonna use Breakpoints for my entire application or I'm just gonna use Flex for my entire application, you can mix and match based on what you're trying to achieve. And those Inductive University videos are a great place to learn about what type of content works well and which container types. We are about out of time here, and so we didn't get to everybody's questions. So we encourage you to reach out to your account representatives and we can get some meetings scheduled, happy to talk to you guys about these things in more detail. But Ray, any last comments from you just about design, any parting words for these guys?
Ray: Yeah, we mentioned it a few times already, but definitely, I've seen a lot of questions as well, but related to layouts and other design principles in general. We have a lot of content around this published. It's all free. It's all on the website. It's definitely worth digging into, and it's well worth training up staff too in these principles and areas, 'cause mobile design and design in general, slick user interface design can really, really set your application apart, elevate it, elevate the experience and just bring more success to your projects in general. So I'm really excited to see more and more interest in the industry about design, and I'm happy to see where it's going, so. That's all I had for you. Thank you.
Kent: Perfect, well, thank you so much, Ray. And so, yeah, if you just wanna jump to the last slide there, just want to say thanks everybody for joining us. Our next webinar, next month, will feature Sepasoft, so be sure to register for that if you're interested in MES and batch processing, but until then, you can get all of our latest updates on social media and our weekly newsfeed email. And so bye for now. Bye everybody. Have a great day, take care.