Top Tips For Great Mobile Interface Design

Speakers

Ray Sensenbach

Design Department Manager

Inductive Automation

Good mobile design makes it easy for users to see and control their system right from their phone, but making a good mobile design isn’t necessarily easy. This session will cover some of the best mobile design tips for creating interfaces that deliver a great user experience.

Transcript:

00:00
Ray Sensenbach: Morning, everybody. So I don't have a moderator this morning, so I'll just go ahead and jump into it, introduce myself, and we can talk about some design tips. It's really great to see so many people here, so much interest in design. That really gets me going. So thank you so much for joining this morning. My name is Ray Sensenbach. I am the Design Department Manager at Inductive. And I joined myself about six years ago as the first design hire within the Development Department. And since that time, I've just been working towards developing what is now the Design Department. And I was pretty instrumental in the beginning stages of designing Perspective, strategy around that. And more recently, really focused on this 8.3 gateway rewrite that I've talked about a bit this morning. Now, as today's session title sort of suggests, we're gonna be talking about tips for mobile interface design. And my plan is to first kind of get us into this mobile mindset, and then, I'm gonna talk about a little bit of design process, how that typically goes, and highlight a few points within that, that I think are gonna be useful for this audience. And then we're gonna talk specifically more about those user interface patterns and changes that we can make within our apps to improve them.

01:22
Ray Sensenbach: And a quick disclaimer on tips themselves. I'm calling these tips and patterns instead of rules. And that's really intentional because best practices are incredibly useful. But every app is unique, and definitely, in this industry specifically, we're solving for really novel problems. We have new design patterns that haven't been explored too much in the mobile space. And so it's okay if you break or bend away from some of these tips and practices that I'm gonna talk about today. You gotta make that decision yourself and just realize that you're designing for your user and trying to get them the best experience possible. And so speaking of sort of our industry today, mobile design within this space, like I mentioned, is a little bit unexplored. So we're gonna be inventing and designing new paradigms that will slowly become our own best practices for ourselves over time. But lucky for us, design, mobile design specifically at large, has matured and gotten to this really good space now. So that advantage that gives us is that there's so much resources and references out there as far as tips, best practices, things like that, which we can really lean into, and build upon. So jumping into the mobile mindset.

02:36
Ray Sensenbach: So content strategy. This is sort of the first step towards developing your mobile app. At its bare bones, what it is, is focusing on information or content and tasks. You wanna be focusing on what information that your user might be looking for. And then, within that, what tasks or goals that they want to be achieving. So this is sort of a good little one-liner to keep in mind as you're designing mobile. And that's that your mobile experience should be really laser-focused on what your users need to do and what your software is created to do. You wanna find that sort of sweet spot between those things. And as you get into this mobile mindset, one of the first decisions you might be making or discussing with your team is one of feature parity. So maybe you're deciding whether or not you wanna have feature parity between this new mobile experience that you're designing in context with an existing desktop application that might already exist in your company. Now, this argument for feature parity is generally, “Hey, mobile is smaller, there should be fewer features, less information, much more scoped experience.” But I wanna argue against that for a few reasons. First and foremost is that people, users, they move fluidly generally between desktop and mobile apps. So somebody might be working on the plant floor and then jump to a control station or something, and they're gonna expect feature parity between those two and be frustrated when they don't find it.

03:58
Ray Sensenbach: Also, mobile, I mentioned it's in a really good place right now as far as design standards go. So it's very... It supports very well both information and tasks, which is what we're focused on designing for. So if you're stopping yourself after you've sort of mobilized a few of your key features, I think you're leaving a lot of opportunity on the table. And finally, you're likely relying on a lot of unfounded assumptions. So you might be saying things like, “Oh, people on the plant floor won't need to see that.” But again, this is an assumption, and they're gonna run into that frustration when they don't have full feature parity between the two. And so, I think that designing for mobile shouldn't necessarily mean delivering less. What it might actually mean is sort of prioritizing information or content in a different way, or streamlining your user flows so that you're prioritizing what's most important, and delivering things when they're only absolutely necessary. And also, I mean, if you're able to do this in the mobile context, you should probably then parallel that in your desktop experience as well. So my top tip here on feature parity is that, yes, your mobile app should include all of the information and tasks that you present on a desktop environment. So now I'm gonna look through a few of these steps of the design process and quickly highlight a few actionable tips within each.

05:19
Ray Sensenbach: Okay. So user flow diagrams. This is generally the first step of a design process. What these do is they sort of map a specific person's path through your application towards their goal. And they typically include key screens, decision points, and branches based on what decisions the user's making. They're really useful in laying out groundwork and making sure that all the paths are accounted for, not just like the happy path. So they're great at highlighting dead ends and intentionally making you design for those dead ends and for error states and problem situations. And it might feel intimidating for maybe a non-designer to be looking at graphics like this and thinking that this is what they need to create for their user flow. Maybe you're unfamiliar with the labeling. You don't quite know what the decision point is or what it should look like. How should I use color coding? What do I need to be documenting at this stage? And I wanna share with you a quick shorthand method for user flow mapping that I think is a really nice way to do this in a more analog, fast-paced, iterative way.

06:22
Ray Sensenbach: So I mentioned already, user flows are just a collection of individual interactions. They're really, really focused on what the user sees and what the user does. So this shorthand follows that same pattern, where above the line, you have what the user sees, and then below, what they do or what action they take. And then they move to the next screen, what they see, what they do. And it just goes forward just like that. But I mean, it looks nice right here, but let's look at it in a really messy, true state. So this is probably what you're gonna be actually doing for user flow mapping. So this here is an example of the Inductive University login flows. And I wanna break down quickly what's happening here so that you can maybe use this in your next design. So here I'm highlighting the first, the starting point of this flow. I'm on the landing screen of Inductive University, and my action the user is taking is opening the menu doc. Next, what they see is the main navigation overlay, and then below is highlighting what they can do here. And I'm using that dash line to denote different actions that the user might take, different branches they might go down.

07:29 
Ray Sensenbach: Then we're moving on to the next step. In this case, they selected sign-in. So I'm presented with the sign-in screen. I'm sort of following that lower map there, and they have new options and so on and so forth. So you can kind of see how it's really effective and quick. It cuts out a lot of the croft and polish that you don't necessarily need when you're user flow mapping. And you also might want to use these useful labels to simply... Being that this is an analog process, you're eventually gonna run out of space on your piece of paper, you're gonna run out of space on the whiteboard, need to erase and start over. So just really simply labeling these paths can help you reference them later and sort of organize your big stack of paper as you're sketching these out. Okay, so that's my main tip for user flow mapping. And now, for wireframing stage, the wireframing stage is really for understanding what the user flows are and how they fit into common navigation structures for the mobile space. And again, wires can be super informal. My main tip at this stage is to be really fast and messy.

08:29
Ray Sensenbach: The whole stage of wireframing is meant to be super iterative. You don't wanna make anything sacred at this point, and you want to encourage a lot more collaboration with team and stakeholders or whoever's involved. And this is a very similar mantra to what the user sees and does, but essentially, you as the designer, wanna be thinking, I'm going to be building this so that the user can do that. You're focused on information and tasks still. And aside from being fast and messy at this stage, my main tip here with wireframes is to do them. So they're really crucial in the design process. They, like I mentioned, they allow you to really quickly hash through a lot of ideas, and they enable that collaboration we already talked about. But they really help you get you aligned on the direction of the solution. So with regards to wireframing and what you might be wireframing, I wanted to highlight some of these common mobile structural patterns for how users might flow through information, get to their tasks, and things like that.

09:32
Ray Sensenbach: And the main way that mobile differs from desktop is in terms of form factor. So that gives us this different unique set of patterns that you maybe aren't as familiar with as desktop. So the first pattern is the standard hierarchical tree. You're sure you're very familiar with this. For the sake of time, I won't get too far into it, but we have an index page, and that sort of branches down into subpages and so on and so forth. And it's a really good model for really content-based applications. It's good for organizing complexity. But on mobile, it can be a little bit difficult to visualize the depth of these structures. So you might think of a navigation that slides over again and again and again, and it's hard at that top level to really inform the user of where something might sit at those lower, lower levels. Not impossible, but just something to be aware of if you're designing in this way. Then we have the hub and spoke pattern. So this is a very common flow in mobile applications. You start again at that central hub, but in this case, you're bouncing out to separate user flows.

10:34 
Ray Sensenbach: You're navigating... The user is navigating down sort of a clear path towards something else. And it's one of those flows that's useful within others. So you might be stacking and using quite a few of these. It won't be just one for an entire application, but like I said, it's very good for apps that have a lot of distinct user flows, distinct paths. But you also wanna be cautious with this one when the user needs to maybe multitask from those lower levels of the spokes with other spokes. That type of navigation is a little bit more awkward and difficult to design for. Then the nested doll pattern. We're all probably familiar with this on mobile apps we use today. It's just a linear flow or linear progression from high-level information down to lower-level actions and content. But it's really good because it gives the users a really strong sense of where they are because, generally, you don't jump to the last step in this. You've intentionally navigated down that path to where you are.

11:30 
Ray Sensenbach: Again, another barrier here is exploration because when you do get down to these lower levels within the nested doll pattern, it's a little bit difficult to have visibility into maybe other nested doll flows or other sections of the application. Then we have the dashboard, as we more commonly know it, but some people call it the bento box. This provides, again, a key index screen, but the difference here is that we are providing the user with a little bit of preview or tips or information at a glance at the top level of the dashboard to give them enough information or context to make the decision as to whether or not they wanna navigate down that path. And generally, it's really good for multifunctional tools, where you can bubble up information about what's happening in these various spaces. And on mobile, specifically, I wanted to mention to be cautious with it because it's a little bit difficult within that form factor to bubble up enough information to give users context as far as what's actually happening in these various areas. It's really just a pain point of screen space in this case.  

12:39
Ray Sensenbach: Then we have the tabbed view. So this is really useful for fairly simple applications when you have a few really distinct sections of the app. And it's great for multitasking in this case because the user always has that sort of navigation or fixed jumping-out point to one of the other sections of the application. And it's always visible there in the fixed tabbed view. But again, it's a little bit harder to work with complexity in this one. So it's more suited towards those simple content structures. And then, finally, we have the filtered view. This is one that you're probably very familiar with. It's great for navigating really complex data sets. And the user basically filters down the information to get a narrowed view of exactly what they want to be seeing. It's really good for complexity and high volumes of content, but the difficulty here is that it might be tricky to visualize, in your UI, what filters have been applied, and what specific data set I'm looking at. It's not impossible, and it can be designed for obviously, but it's just something to watch out for and make sure you're intentionally visualizing what filters have been applied.

13:50
Ray Sensenbach: Okay, so now that you know a few of these common design patterns on mobile, I'm gonna get back to wireframes quickly and talk about what they should be focusing on. So you should be definitely wireframing every screen within your application. And then also, the focus within those screens and your sketches should be mainly focused on the placement of elements, the labeling of those elements. Navigation is definitely a big one. And then things like functionality and feedback are really easy to sketch out and navigate at the wireframe stage. Now, if you're worried about putting pencil to paper and drawing and being an artist, there's a few useful tools that you can use. So in this image, you're seeing some products from this website, uistencils.com. They have these great UI stencils that have common navigation elements on them, arrows, search glass, things like that, so you can get higher fidelity more quickly. And also, they have these great Post-it notes of the mobile design apps there, which are also super useful. You sketch within the actual form factor instead of just on a blank piece of paper. And then you're also able to just peel those off and stick them on a wall and start putting things together and visualizing how your application works.

15:01
Ray Sensenbach: So speaking more to fidelity, I wanted to give a quick example of what I thought was sort of the too-hot, too-cold example here. Again, what I'm referencing is this Inductive University course overview page. So in our not enough example, it does a really good job of outlining the general layout and what elements exist on the screen. But where we're not doing a good enough job is labeling. And also, we're not getting quite enough fidelity in specifically those section cards. Those are just big blank spaces. Whereas, at this stage of fidelity, you wanna be outlining a little bit more of the content that's going to exist there. Then we have our just right example, which you can see. Now, the logo is labeled as logo, and I'm putting a little bit more content, and specifically, instead of page title, it now it says “select a course.” So we're getting more into labeling and the verbiage that the application is actually going to be using. And looking one to one as I'm sketching this with something that already exists. This is probably a little bit too high fidelity, but it's right about there.

16:07
Ray Sensenbach: And then with the too much example, mainly the things I think are no-no's here, right, is I'm actually drawing the logo, icons, I'm giving them shape and form. That's definitely too much at this point. And then, with the highlighter, I'm sort of highlighting what is interactive on this screen. You're gonna be working with a team or just by yourself. And so I think the designers will understand what is interactive at this stage. Highlighting interactive elements, not giving you too much bang for your buck. Okay. And then finally, within the design process, prototyping. So prototyping again is this really crucial step because until you're really touching and feeling an interface, you don't necessarily know if the experience is going to be a good one or is working. And there's this great notion of if a picture is worth a 1000 words, a prototype is worth a 1000 meetings. It's really hard for a lot of people, especially non-designers, non-visual people to sort of grok the direction you're going with something like a wireframe. But when you actually show them a prototype, and they're able to touch it and press it and interact with it, that sort of aha moment generally happens.

17:14
Ray Sensenbach: And again, yeah, so you might feel like after wireframing, you've got a really good idea of your application, you wanna jump in the designer, you wanna jump into some visual application and start building out screens, but definitely don't skip this step. And so, this is a similar simple analog tip to prototyping that I had with user flows. And so, if you've done the wireframing step at this point, you can do something called paper prototyping. So it's a really simple way to simulate the mobile app experience for your stakeholders, for your team. And basically, I mean, it is what it looks like. You're taking pictures of your wireframe, and then you're slapping big hotspots on them so that they're interactive. It doesn't have to be advanced, but what it does is it gets it into the device, it gets it on the screen, it lets people click around and interact with it. And definitely, a tip here also is not to focus on transitions or animations. I know a lot of prototyping tools have this built-in, and it's easy to get carried away with fades and slides and all this stuff, but it's way, way too early for that. And tools that you can use to do this.

18:16
Ray Sensenbach: I mean, you can do this in PowerPoint, you can do this in the Designer, you can do this in Google Slides. It doesn't need to be a fancy design tool like an InVision or a Figma, although if you're familiar with those, they're definitely useful as well. All right, so getting into the design principles themselves. So interface design is this balancing act between visual form and functionality. It's sort of the bridge between your user and the system. So there's a lot to be considered, especially on mobile when every element is important, every pixel plays a part in the bigger picture. So how can you be meeting the needs of your users when designing for mobile UIs? And so I've sort of bubbled up these tips that I have into these four principle categories. I'm gonna go through each of them now, starting with placing users in control of the interface.

19:16
Ray Sensenbach: So first, within this, is creating an easy-to-use navigation. Your navigation should really be clear and easy to understand, and really the key point here is encouraging exploration. So you want users to be able to find all these great, powerful tools that you're building. And good navigation, it puts users in their comfort zone by providing visual context. And that context from your UI is gonna come in the form of things like page and section titles, as well as maybe like “You are here” navigation indicators. So that's like a highlighted tab or a highlighted navigation element. It lets me know that I'm on this page. You could also add like global search and filtering as kind of an easy escape for the user to jump to another screen and kind of give them an idea of control over where they go next.

20:02
Ray Sensenbach: And if you've done all these things, and you're feeling like you're in a pretty good place with your nav, a good way to test it is with this silly test called the trunk test, which it does a good job at allowing you to ask these four questions. And the idea behind it is if you are kidnapped, thrown in the trunk of a car, blindfolded, driven around for an hour and dropped off, you should be able to answer these four questions pretty quickly just by visually using the wayfinding of the city around you. And it's the same thing for your mobile app. So a good way to test that out is to maybe randomly draw a few screens or grab some that are like in the dusty corners of your unused areas of your application, and just literally walk through these questions and make sure that you can answer them.

20:45
Ray Sensenbach: And if you can't, you might wanna move things around or bring in a little bit more of these labeling elements that we talked about to provide that context so the user always knows where they are, where they can go, how they got there, and what they can do there. All right, also within having control of the user interface is giving this the user basically a way to backtrack. So you're making actions reversible. And the main example of this is undo. So it might be frustrating if users accidentally delete something without having an undo action available. You basically always want to have a clearly marked emergency exit for when folks get to an unwedded state within your application.

21:29
Ray Sensenbach: Also, you wanna be providing informative feedback. So there's sort of two parts of this one. So at its core, like for every action the user is taking within your app, your app should answer back with some clear, meaningful feedback. And this can be on the one side, like really simple and subtle. So for something like a button that the user's doing frequently all the time, something simple as like a state change or a press state, an active state is gonna give that feedback that, hey, this thing's been pressed, now I can wait for the next thing to happen, my nav or something like that. But then, for something a little bit more infrequently done and substantial, your response can be more substantial. So I'm creating a password in this case. That doesn't happen very often, and you definitely wanna make sure the user's getting the feedback that they need, even though it is more substantial in terms of these things are changing dynamically, there's a lot of real estate being taken up on the screen, but because it happens infrequently, that's okay. You wouldn't wanna do something as loud as this for like a button being pressed, obviously.

22:32
Ray Sensenbach: Okay, and then this is sort of the bigger one, the bigger section, making it comfortable for users to interact with your app. First, within comfort is this idea of reducing element and content so that the users are directly looking at what they're supposed to be doing on that screen. The whole idea of less is more. Now, I don't mean like actually stripping out information completely, I just mean reorganizing it in such a way that it's accessible when the user needs it, but when it's not necessarily needed, we hide it or put it somewhere else. So having a lot of irrelevant information presented in parity with relevant information, they kind of start to cancel each other out. Things get murky. You don't understand as intuitively what is important to me on the screen. This is a pretty clear example that we're probably mostly familiar with. The Lyft app. It has a lot of functionality within this application, but when I first launch it, this is all I'm seeing.

23:32
Ray Sensenbach: I'm seeing the context of where I am, I'm seeing where I can go, and I'm seeing maybe some past actions that I've taken, some past visits I've made. Also, within this is not asking users for data that they've already entered. This can really easily annoy users, especially with repetitive tasks. And essentially, what you wanna be doing is making your mobile application do as much work as possible and requiring the user to do as little work as possible. That's sort of that sweet spot again. Yeah, if we're tediously entering data over and over again, it gets frustrating, especially when you kind of know that this app already knows my name and you can use things like geolocation. “Hey, this guy's at this plant.” I should already put that in there. And you don't wanna like hard code these things. You want to have smart defaults, is basically the idea.

24:16
Ray Sensenbach: So making smart guesses about what you think the user's going to need in their data entry as much as possible throughout your application is very powerful. This is a good one. Just avoiding jargon and system-oriented terms. So essentially, this is just clarifying the content by making things easy to read and understand. Your system should really be speaking your user's language, using words and phrases and concepts that are familiar to them rather than jargon or acronyms and things like that. And the big one in this is not using cliche, because a lot of times, you're designing alone by yourself or with a small team, you think something's funny, you put it in the app, and then somebody else, your actual user is using it on the plant floor for eight hours a day, and they just cringe every time they see that. They kind of start to hate you, right?

25:03
Ray Sensenbach: So this example shows these navigation options being a roost, migrate, fly, and what they're actually trying to say is, buy, rent, sell. Like, it's just so much more clear and intuitive to name things what they are, even if you think you're being funny and cute at the moment. Okay, so a big one for comfort is mobile ergonomics. So this is super important for touch targets, and this image here is showing these sort of natural and comfortable areas within devices that we can touch with our screens, with our thumbs. So touch targets within mobile should be large enough for users to accurately select them. Again, we have this sort of example of big to small. Hey, it's a smaller space, button should be smaller, just shrink everything, but definitely, because we're interacting with our big thumbs, we want things to... Especially interactive elements to be a lot bigger on mobile than they would be in your desktop application.

25:53
Ray Sensenbach: Another thing you might do here is put your navigation at the bottom of the screens than them on the top. We all know that's a pretty common design pattern on mobile, and that's because of this graphic exactly. It's a much more natural area to reach, rather than going way up to that “ow zone” at the top. Some other maybe tips you could take from this is maybe using vertically centered dialogues for confirmation actions. So it puts that right in the middle of a “comfort zone” rather than in some strange corner. And also, you could utilize those “ow” corners for like destructive or actions that can't be undone so that you know that the user has really intentionally reached for them and pressed them versus accidentally clicking them as they're navigating otherwise. All right, so designing accessible interfaces. Accessibility within design is a pretty deep topic, so I'm not gonna get too far into it. I just wanted to highlight one specific tip here. And just the general idea that if you are providing an accessible interface, it gets better for those that need it and for everyone else in general.Because the practices within accessibility, especially for design benefit everybody.

27:03
Ray Sensenbach: So the specific tip here was to avoid using color as the only way to convey information or states. So in the top, you see, are good example of a triple encoded message for an error. And on the bottom, this is one is just using color to let me know. And if I'm one of the 10% of males that have color blindness, then I wouldn't be able to not necessarily get the information or context they need that this is in an error state. Usually, double encoding is enough. And what I mean by that is using color and maybe text, for example, or color and that icon. In this case, I used all three just to give the example of triple encoding.

27:46
Ray Sensenbach: Okay, engineering for errors. So errors are definitely an unavoidable design experience. We all hit errors every day. So you wanna make sure that you're intentionally designing for these states, and that means things like messaging and even error prevention. So here at the top, I'm seeing one of these really frustrating error messages that we've all run into. It's telling you something's wrong, but you have no idea what to do with that. You don't know how to fix it for next time. And what good error messaging does is it provides you with a good idea of what went wrong and then a path towards recovery. So, in this case, my file type is not supported, but hey, maybe I need try JPEG next time, and that's gonna work.

28:23
Ray Sensenbach: And I mentioned error prevention strategies as well. There's some cool ways to do this, and it is super application-specific, so I didn't have a great example, but the one that came to mind was when you try to attach an email on Gmail, and then you send it without the attachment, it throws up that preventative error. “Hey, it looks like you were trying to attach something. Do you still wanna send it?” Or “Do you want to go ahead and attach that?” Like, that saved my life quite a few times. So little contextual patterns like that for error prevention can go quite a long way. All right, so protecting a user's work. This is a difficult one, but there are some ways you can go about making sure that deletions specifically are not wiping out a large set of data that your users worked hard on or is important to them.

29:14
Ray Sensenbach: So that could be as simple as what you're seeing on the left, which is just discard or deletion confirmations, making sure that anything destructive always has a very clear confirmation the user must go through, or it could be this other method on the right with Dropbox, where once I've deleted a file, what they do is they save it for you for 30 days. So it's recoverable still, like just in case, and I'm sure they actually do both patterns where you're confirming the deletion, and then they save it for you, just in case. All right, reducing cognitive load is the next sort of principle category. And if you're not familiar, cognitive load is just the mental processing power that it takes to use your product. So it's about simplifying things and, again, making the user not think or work too hard to interact with your app.

30:01
Ray Sensenbach: So a good tool within reducing cognitive load is this “theory of chunking.” So the average person can only keep about seven plus or minus two things in their working memory as they're interacting. For me, maybe it's closer to five, but you wanna basically present your content in more memorable ways, so through chunking, and you're also deciding what to show to the user instead of just showing everything to them all the time. Good example of this, I thought, was this set of filters. I think this is Airbnb, if I remember correctly, where they have something like 20 or 30 filters to drill down into the type of places that you wanna rent. And I thought filtering was pretty applicable to this audience. So you can see how they present it. It's chunked in a nice way where you have categories, and also just the input UI is very, very mobile-friendly so it makes it a little bit more fun and just simple to understand each of the sections and navigate throughout this, even though it is very, very complex filtering system.

31:02 
Ray Sensenbach: Okay, then I want to talk about this idea of recognition over recall. So recognizing something visually on your screen is so much easier than having to recall whether or not it's interactive. So this applies specifically to basically just making your visual UI design for things that are interactive look like they are. So this falls just general best design, best practices within design. So highlighting things, we don't have Hover on mobile, but getting things a pressed state. When something is selected within the list, a nice big check mark highlighted back area there. So you're using these design tools, like color icons, underlining links to make sure people know intuitively right away, recognize that they're links. And then I mentioned already a few of these states. So just visually, you should be able to recognize what is interactive, what's not, and the state that it's in.

32:00
Ray Sensenbach: Okay, you also wanna be using real-world metaphors or just leveraging those to our advantage.So this, again, is just creating a connection, letting the user apply knowledge that they already have to the functionality of your application. So in this example, we're seeing a lot of metaphor in play. We see the folders being used for like groups of things. We've got the search icons. So the magnifying glass indicates search. Microphone indicates voice input for search. What else was there? The trash can for delete, the mail for email. There's just a lot of good metaphor that you can rely on here to reinforce meaning, reinforce interaction. But you do wanna stick with universal metaphors, which can be tricky. You might think that everybody knows what this machine is, so you're gonna draw a picture of it and put it in your nav. But then what happens with the new hire? What happens with somebody who's coming in in an emergency situation? They need to navigate somewhere quickly. You wanna avoid those things that aren't universal so that you'll eliminate kind of some pain points.

33:06
Ray Sensenbach: Okay, then this one was on visual clarity. So this is kind of a big topic, but I definitely wanted to include it for a few of the tips within it. But this is just general good visual organization. This is things like using a grid system or even a spacing system. Digital designers nowadays really rely on this eight-point grid system. It's definitely worth looking up, where everything is sort of some factor of eight, and that just provides like a nice vertical and visual rhythm throughout your application's design. You can kind of see that in play here. The only examples are 24, but definitely this is a material design example, and it's using that eight-point grid system as well. It also... Visual clarity is impacted a lot by spacing. So spacing groups out apart from one another, giving them a nice label so that they stand out and just, again, have that nice visual rhythm.

34:03
Ray Sensenbach: Progressive disclosure is a pretty deep topic, but it's very, very useful, especially on mobile, for managing complexity. There's a lot of patterns you can use for progressive disclosure, but essentially what you're doing is initially just showing a little bit of information enough to let the user make like an informed decision about whether that's the path they wanna take or not. So I took a few examples here, the ICC mobile, or actually, I think this is a website on mobile for ICC. So the schedule here gives you enough information to decide whether you're interested in learning more about it, and then if you click it with this nice accordion pattern, you get the full description, maybe a little bit more about the speakers, more information. So they're progressively disclosing that only upon request. It could have been designed just as well, with all of the information on the page. But by hiding just a little bit of it, you make it easier to navigate that top level, easier to navigate through, and decide where you actually want to go.

35:03
Ray Sensenbach: Also DoorDash, I definitely wanted to highlight this horizontal scroll bar pattern in some way, and I thought progressive disclosure was a good one. So they use these scroll areas to sort of tease that there's more content available, but again, they're not just showing all of the filters at once, so it helps to hint that there's more information and filtering there. But again, not showing it all at once. And it's really useful on mobile because that horizontal space is something we don't take advantage of much. Whereas vertical is pretty precious, you wanna keep things within a tight space vertically. So leveraging that, and it's also a very natural scroll interaction with our thumbs to scroll left and right on mobile.

35:44
Ray Sensenbach: All right, so the final principle was making interfaces consistent. Consistency with style is things like using the same colors, fonts, and icons throughout your application. You don't wanna have a navigation arrows back and forth, which look different in different places. So just sort of a simple subject here really, but an important point of this is, if you have colors or styles that are used exclusively to convey meaning, so in this case, like error, you shouldn't be using this error red as like a decorator anywhere else within your application. It sort of causes it to cry wolf, and it quickly loses its meaning and context to where when there actually is an error state, people might gloss over it. So really reserve the right to use stateful colors and visual style just where they have that meaning.

36:39 
Ray Sensenbach: And then the other side of that is functional consistency. It's very similar tip, but things should work the same way that they do everywhere in your application. So select lists should sort of have the same select state. Checkboxes should be presented in the same way everywhere with the same touch areas so that you're not, I'm guessing, at how things work every time. It just sort of makes them more consistent, makes it more intuitive overall for your user. And again, they're not having to learn anything. It can quickly grok and understand naturally how the application works.

37:16
Ray Sensenbach: Consistent with user expectations. Fairly similar, but this one more relates to patterns and design that exists outside of the scope of your application. So these are like really platform-wide principles and things that we've all just become familiar with for the sake of having a phone in our pockets. So this main platform level back button should always take the user one step back in their navigation, one level up in their flow. We don't want to be trying to reuse or change these really, really core user expectations for how software works.

37:51
Ray Sensenbach: Okay, so that sort of sums up the tips, and definitely these slides will be available. So if I went way too fast through something, ask a question, or you'll get these after the fact. But yeah, the final thoughts here. So we talked a little bit between the split of planning a project and then executing it. I just wanted to reinforce the importance of that planning stage. It's super crucial to get you to a place where at this execution phase, you're able to make good decisions. And all this stuff might not be familiar to you, but it's fairly easy and straightforward. You mainly just wanna be collaborating with users, talking to users, getting them involved in your process as much as you can, and iterating definitely on your designs throughout the process. And I put that last note in there just because if you're still not feeling comfortable, your confidence is low, there's plenty of product design shops, agencies, consultants that could be hired out for this type of thing, obviously. So it's probably worth the investment, or even just staff up some designers that could help as well. But yeah, it's really important to get right, especially in our end industry where the stakes are so high and the design is so crucial to the success of your product. All right, that's all I had. Thank you.

39:10
Audience Member 1: Thank you Ray. This is Jason Coope with Kanoa Consulting. I enjoyed both sessions that you did today.

39:18
Ray Sensenbach: Thanks.

39:19
Audience Member 1: Question, in terms of user forgiveness, we've got a number of times where we've given the user the opportunity they can, if they want, request to get a year's worth of data that every single asset, this could be a long running query. Is there a way building in Perspective that we can actually add in a button to cancel a request if it's gonna take too long? We know we can go into the gateway, you can look at running scripts, you can abort those, but there really seems to be once they've requested that data, there's not much we can do about it.

39:50
Ray Sensenbach: That's a good question. So is it a script that's running to accomplish that?

39:53
Audience Member 1: It'll be a script library, probably a SQL query on the backend. Maybe it's coding a stored procedure.

39:58
Ray Sensenbach: I am not sure off the top of my head. I don't wanna give you the wrong answer, but I would think that's possible. Maybe we can... I can follow up with you afterwards, or we can track down a dev who would definitely have the answer for you on that.

40:10
Audience Member 1: Okay. A follow-up question then, based on that response, not on that response. Progress bar, we've had varying degrees of success with having a progress bar, particularly for that if it's an operation that is gonna take some time. With the nature of Perspective, the fact that we can have many nested views, subviews, we may have it where we have a query that gets data, that gets data populates, few parameters on subviews. Those, in turn, are gonna go and get data. So I can have a view that will suddenly magically appear with a progress bar, but I never really know how long it's gonna take. I might clear it, but there may be subviews with scripts running or are still running. So is there a best practice, or have you come across a mechanism?

40:55
Ray Sensenbach: Yeah, I'd say design-wise, the best practice would be what you're talking about, like kind of having a loading bar that indicates with, hopefully, a degree of accuracy, how long that operation's going to take. What you're specifically asking… How to accomplish that in Perspective with the views? I haven't accomplished that myself or tried to, but I know we have two different loading states. What are they called? There are two different ways in which we display views as they're loading. I think one is sort of a one-shot all at once, once it's all loaded and there, whereas the other is popping in the views and data and subviews within them as it's received.

41:36
Audience Member 1: That's probably on startup. The view is already there.

41:40
Ray Sensenbach: I see it.

41:41
Audience Member 1: It is just waiting, it's gone off, and it's gonna be our custom scripts inside. So I can say maybe you can use session properties or something to say that everything is... Things are still active. Just haven't found a particularly easy way, and just when I think that I've accomplished it, I suddenly noticed that the view is still loading data.

41:57
Ray Sensenbach: Yeah, it's definitely an important design pattern. And I know we have also an ideas form request, which is on the same lines with more appropriate like loading states for all of our components themselves.

42:11
Audience Member 1: All right.

42:12
Ray Sensenbach: Yeah, I don't have a good answer for you. I'm sorry.

42:12
Audience Member 1: No problem. I'll keep an eye on it.

42:14
Ray Sensenbach: It's food for thought. And yeah, maybe we can talk more about it too and get some ideas going.

42:18
Audience Member 1: Okay. Thanks again, Ray.

42:19
Ray Sensenbach: Yep, of course.

42:22
Audience Member 2: Pretty trivial question. When you're building your wireframes, when do you know you're at a good stopping point and you're not overinvesting in that?

42:30
Ray Sensenbach: Yeah, I mean, I'd say once you sort of hit that point where you have A) Like all of the screens or key screens that you think are going to exist in the final application. And then B) it's really just about that fidelity example that I was trying to show, where you can grok the functionality and use of the screen and probably how it will be built with UI. But you're not... I don't know, it's like kind of a gut thing.

42:54
Audience Member 2: Yeah. Do you advise adding interactivity for the user experience for them to get a feel for it or just blank screens and more explanation than the actual interactivity?

43:03
Ray Sensenbach: For wireframes?

43:05
Audience Member 2: Right. If I present it to the user, this is the look and feel of the website do you suggest to add more interactive components to the website or the wireframe, or just more, or narration of what it would look like?

43:18
Ray Sensenbach: Yeah, it sort of depends what you're trying to test at that stage. I mean, if you're talking about just trying to validate the content and the structure of the page, obviously, interaction wouldn't be needed. But if you're trying to validate like a user flow, like can they get from home screen to logged in or through the password retrieval flow or something like that, then yeah, interaction's gonna be pretty key to what you're validating there. So it kind of depends.

43:45
Audience Member 2: Thank you.

43:45
Ray Sensenbach: I hate using that answer 'cause it's always the answer. You're welcome.

43:50
Audience Member 3: I can probably talk loud enough. You can hear me, right? Quick question on the screen filters back towards the beginning, are those filters for the screens predefined by the developer, or can a client do a search text field and contained in any text, contained in any of the screens be displayed?

44:06 
Ray Sensenbach: Sorry, it was search filters?

44:08
Audience Member 3: Yeah, you had a filter where you filter your screens?

44:14
Ray Sensenbach: Oh right. That navigation pattern.

44:16 
Audience Member 3: Was the user able to type in there, say for example, motor fault and it'll show 'em all screens, it contained motor fault in that screen?

44:22
Ray Sensenbach: You could do that. Yeah.

44:23
Audience Member 3: You can. Okay.

44:25
Ray Sensenbach: Yeah, definitely.

44:25
Audience Member 3: All right, cool. Thank you.

44:29
Audience Member 4: Hi. So I noticed a few different features that I kind of saw on there that I have been looking for actively. I would say the snack bar, for one, as well as an active like a bottom bar, a bottom menu bar. And I was wondering if there was any plans to have those more readily accessible to things. I know you could probably do stuff with pop-ups and add a whole lot of scripting to make your pop-up go away for like the snack bar case. But was there any plans on getting the more very mobile-specific elements like that being a little bit more usable?

44:58
Ray Sensenbach: Yeah, the backlog for these types of features is pretty endless, but definitely, with the bottom-docked navigation bar, you can accomplish that with the tabs for sure.

45:08 
Audience Member 4: Right. Is there a reverse feature on it or something like that, or is it a matter of, I don't know, is it a matter of reflecting it or something?

45:16
Ray Sensenbach: It's just a matter of placement.

45:20
Audience Member 4: Just placement?

45:21
Ray Sensenbach: Using it as a bottom dock versus a top dock in that case.

45:23 
Audience Member 4: Sure. Okay.

45:24
Ray Sensenbach: Yeah. And then for... Sorry, what was the other feature?

45:26 
Audience Member 4: Snack bar.

45:28
Ray Sensenbach: Snack bar. Yeah, that's definitely, like you said, able to be created now through scripting and timing duration for how long it should be retained on the screen. I don't think we have a specific component request for that type of feedback, like as a pre-built component. But yeah, I've accomplished it myself through, just like you said, popups and some scripting.

45:48
Audience Member 4: Okay. Wonderful. Thank you.

45:52
Audience Member 5: Do you have any Ignition demo in the mobile app?

45:56
Ray Sensenbach: I do not. I mean you can do the... Her question was do we have an Ignition demo, I believe for the mobile app?

46:03
Audience Member 5: Yep.

46:04
Ray Sensenbach: Yeah, so our live demo at demo.ia.io is... You can pull that up right now on your phone, and it is a pretty fully functional demo of Ignition and what you can do with Perspective. So that might be what you're looking for.

46:19 
Audience Member 5: Yep.

46:19 
Ray Sensenbach: Okay. And I think we're out of time for questions, so I'm gonna call it there. Thank you so much for coming, and I appreciate all your questions and attention.