 Hello everyone, thank you for joining us today. My name is Matthew O'Dell, the Technical Marketing Manager at FileMaker, and I'm excited to be your host for today's web seminar on Essential Design Principles. Today's seminar is based on material from FileMaker's newly released Design Interaction Guide. We're also joined today by the author, Dr. Don LaVan, who is the founder of Vanguard Custom Software and will be doing today's live demonstration. But before we get started, I have some brief housekeeping notes. For the best experience, we strongly recommend that you participate in this web seminar with at least a broadband connection. If you have any problems or require online assistance at any time, please contact Citrix Technical Support at 888-259-8414. Again, that number is 888-259-8414. During today's presentation, we will also have an opportunity to take questions. So let's briefly talk about how you can enter a question. Go to the control panel, click on the questions section, and then type in your question and hit send. We will cover as many questions as time allows at the end of our presentation. Now I'd like to introduce Dr. Don LaVan, the founder and lead designer of Vanguard Custom Software. Dr. LaVan is an experienced designer who helps business owners create exceptional software and user experiences. A recognized final maker expert, Dr. LaVan was hired to provide consulting to final maker on the design of the starter solutions and many of the features used by final maker developers. In addition to being a sought after speaker at the final maker developers conference, pause on air conferences, and other software industry events, Dr. LaVan also offers a three day experiential design studio in which he provides training in the software design principles and processes that are the foundation of Vanguard's proven design work. So without further ado, I'd like to hand things over to Dr. Don LaVan. Don, the floor is yours. Thank you, thank you, Matt. All right, let's get started. Good design is what we're gonna be talking about today. And there are three things that in my view make up good design. The first and most important thing is that good design addresses the user's goals. Goals are the reason for the things that we're building. We're trying to enable people to achieve their goals in specific situations that they need to operate their businesses. Good design addresses the user goals and is usable. So usable means that the solution helps the user accomplish what they want to be able to do that they can figure out how to do it that it's easy and efficient. And that's where we're gonna spend most of our time today. And lastly, good design is aesthetically pleasing. The design is really important because successful designs can help people achieve big goals and solve big problems and save money. In contrast, unsuccessful designs can really waste time and money and cause users to feel frustrated and annoyed. And I'll give you one quick example that I can think of very clearly. I did a redesign last year for a company that were made nameless, but there were 115 customer services representatives sitting on phone banks and they were using a solution that had a dashboard screen and a list view and a detail view. And every time a customer would call, they would have to select the customer. But to go from the detail screen, they had to go back to the dashboard to select the customer. Just moving the select customer dialogue button from the dashboard screen into a pop-down list, save 15 seconds every time one of the CSRs perform this action. Well, just that 15 second savings is gonna save this company $500,000 over the course of a year. Design matters. So today, you're gonna learn the key principles of interaction design. We're gonna focus on simple actionable strategies you can use to create more usable FileMaker Pro interfaces. And specifically, how to make interfaces easy to learn and efficient to use. Now, I structured the presentation that way and the guide that way because there are really two different types of users that you're addressing. The new users who you have to gently onboard into your solution, help them figure out how to get around, how to learn, how to accomplish the things they wanna do. And then once they've learned it, how to be as efficient as possible so that they can get their jobs done so they can accomplish the goals that we're trying to enable them to accomplish as quickly and as efficiently as possible. And we're gonna spend time and talk about the principles for each of these separately. So let's start with make it easy to learn. You can help people learn to use your application by designing your interfaces to explain themselves, by providing clear and responsive feedback and providing navigation elements which orient and direct your users. And I'm gonna go through each of these high level points in detail and they're further spelled out in detail in the guide. So let's start with the first one. Design your interfaces to explain yourself. When people encounter a new piece of software, the way they try to figure out how it works is exactly what any of you would do when you arrive in a new town or get to a new building or encounter a new experience which is you scan the environment, you look around for things that are familiar to you, for things that you can recognize and you draw on your past learning on your internal mental models to make sense of the things that you're encountering new. It's the same when people are starting to use your software. They will open up the solution and they will start to scan to find the things that they can recognize, the things that they can, that will trigger past learning and their internal models of how the world works and how software works. And so you wanna design your interface so that they explain themselves so that people can recognize the patterns that they're familiar with. To do that, one of the things that you gotta do right off the bat is you're gonna use visual formatting to differentiate interactive elements from non-interactive elements. In any solution, there are some elements that are clickable, that are interval, that are editable and those are different than the ones that are not. So fields, portals, all of these things, buttons, those are interactive elements. Labels, text strings, those are non-interactive. And you want your user to be able to tell immediately upon looking what's interactive and what's not. So if you look at this group of fields, they're the same four fields and some of them could be interval and some of them not and you can't tell necessarily. I mean, at this point it looks like the four on the left are interactive and the four at the right are not. Now, I'm not talking about doing this. I'm not talking about applying colors willy-nilly. But I'm talking about being specific and conscious and making choices about how you communicate. Your software, your interfaces are establishing a conversation between you and the people that are using it. And so you wanna speak clearly so that they can understand. So in this example, the Dev Contego application last year, the designer was very conscious in using just one color blue to indicate everything that's interactive and everything that's not interactive was in grays or blacks. And so while there's no three-dimensional shading or gradients to very what's been called a flat design, there's a great deal of clarity here as to what's interactive and what's not. So as you are designing, you wanna take advantage of the themes and styles. FileMaker introduced the ability to create and save and utilize custom themes and styles last year in FileMaker 13. And in doing so, the themes that ship with FileMaker provide a couple of clear styles to help you start to make the differentiation. So most of them have a default, a minimal edit and a read-only. Those can help you start to distinguish what's editable from what's not, what's interactive from what's not. And as you make decisions, as you format a particular element in one way, for example, a string of text or a label, every time you use a similar element in a similar way, go ahead and use the style that you already created so that you're developing a style guide as you make decisions. Now as I mentioned before, when earlier in the lives of people using computers, it was necessary to use a lot of very heavy visual formatting, gradients, Moyer patterns and others to communicate what was interactive because it was hard to see on the screen. Now that we've got retina screens and people are really used to using computers and touch devices, it's not necessary to be that heavy handed. So you wanna use the minimal visual formatting necessary. And you can see an example of that in this screenshot from InkPad designed by the proof group where they've just used a little bit of formatting in the shading of the gray and the ellipses after the inquire and the right-facing chevron after the learn more to indicate that those are buttons and differentiate them from everything else. Icons can be a really great tool to help people learn how to use your interfaces and they can enable recognition memory. But most icons are not iconic, not truly iconic. So you wanna make sure that if you're using an icon that may take some learning that you prepare it at the beginning with a text label. Later, so the first couple of interfaces that people encounter, most likely you're gonna wanna use icons with text labels. And then if you show the same icons again in a smaller way and a smaller subset of functionality later in the interface, you might be able to drop the text and just use the icon because they've already learned the meaning, they've already associated the icon with the text and then they can draw on recognition learning. The next thing that you wanna do to make your interfaces really easy to learn is to provide clear and responsive feedback. As you're walking through life, every action that you take is followed by a reaction. As you take a step, you feel your foot hit the ground. You feel the impact of your foot on the ground. You feel the sound of the ground under your shoe. It's the reason they spend so much time with Foley artists with making movies to add in all those sounds of the footfalls of the door squeaking of the keys rattling that don't necessarily get picked up by the mics to enable the world to feel realistic. So in software, you wanna make sure that every action is followed by an understandable and expected reaction. FileMaker gives you a number of ways to do this now. You can use the object display, state styling, you can use conditional formatting, you can use merge variable variables, and you can use custom dialogues. So an example on the screen, there's a formatting difference between the normal object state and the pressed object state, and it's just very subtle, but there's enough to let somebody know that they take it in action. So to use the object state styling, you're gonna wanna select an object, go to the appearance tab of the inspector, style, choose the object state. On the left, you can see that the normal state is selected, and on the right, you can see the pressed state is selected. Style the object, and then go back out into browse mode. It's important to use only the minimal formatting, the least intrusive form of feedback that you can give. We'll talk about that more in a minute. You wanna make sure, especially to provide feedback for scripts and processes where the user's gonna be waiting. Nothing is more frustrating than pressing a button and not seeing anything happen. The users are often left to wonder, did they do it correctly? Is something happening? Did they break something? And very often, they may just mash on the button and try it two or three times. So you wanna make sure to provide feedback about scripts and processes the users need to wait for. And you can create dialogues like this fairly simply using merge variables and the refresh object script step. Refresh object script step is a very, very powerful step that allows you to create interfaces that are very responsive and provide a lot of feedback, and there's more information about how to do that in the guide. As much as possible, you wanna integrate status information into the interface. Like I said before, you wanna use least intrusive method possible. You could use a custom dialogue to indicate that this invoice has just been paid. But if you use a custom dialogue when you don't need to, you're interrupting the user's attention. And you wanna be as considerate of the user's attention as possible. So you wanna find ways within the user's normal workflow within the interface itself to integrate the status information as much as you can. Another thing that's really important to do to help a user learn to use an interface is to provide navigation elements to orient and direct your users. Now, in life and in most common organizational systems now, the most important, most of these navigation systems are organized in what's called a hierarchy. And a hierarchy is basically a set of items where at each layer of an item, there are mutually exclusive relationships between objects in the hierarchy. So in real life, you can think of the Amazon product catalog that starts out the whole set of products and then books and then fiction books and then current award winner fiction books. That's a hierarchy. In FileMaker and in software applications, generally the hierarchy goes in this way. There's the whole solution and then there's the found set and then there's the current record and within the current record, there's the most important information and the secondary information and then everything else. So as you start to design a solution, you wanna start out by getting a really clear understanding of the world that you're building and how the users think about the world and where the information fits into the world. And then you want to organize your information as they would organize it in the natural hierarchy they would use to think about and describe the world. And as you're going through the information you've collected and that you're putting into your solution, you wanna ask what data and functions are related to or operate upon the solution. What data and functions are related to or operate upon the found set. What data and functions are related to operate on the current record and get a very clear distinction in your head between solution, found set, current record and within the current record, what's most important, what's secondary and how the sibling elements group together, how they are related to each other. Once you understand that you wanna start to arrange and design the layout elements to mirror the underlying hierarchy. So this is the context starter solution. And the context starter solution has a pretty clear hierarchy that you can see. So here you can see that at the top left the buttons that are at the top left are solution, found set rather, found set related functions. So it's navigation between records. The top right, there's the current record functions. The send by email, the delete this record, add a new record. In the just below that, you have the current record photograph and summary. So the most important information about the contact, their picture, who they are, their title and the most important contact methods. And then below that you've got groupings of the current record name fields, address fields, phone numbers and other contact methods. Once you've organized that information, you wanna use visual styling to communicate and reinforce the hierarchy. So when people encounter objects, our eyes like to see patterns and groupings. And when you have things that are styled the same, your eye will group them together. But your eye will also notice outliers. So things such as color, shapes and sizes will draw your attention. You wanna use those differences to communicate the hierarchy. So the most important thing should be the heaviest and the boldest. The second most important thing should be just a little bit less than that. And then everything else can organize in a way that communicates the hierarchy. And again, the styles built into the shipping themes in FileMaker 13 are designed in such a way to help you go ahead and implement the hierarchy. So title text one and the sophisticated theme gives you the most important thing. Title text two gives you the second most important thing. The default gives you what's a typical editable field and label. The accent text is great for using for headers and call outs. Once you've organized your interface and once you've used visual styling to communicate the hierarchy, you wanna step back and you wanna squint at it because the most important things should pop out at you. So this interface is a reorganized stripped down version of the Asset Star solution. And if you look at this interface, there's nothing really distinct on the left side. You don't really know what's most important. Compare that two to what actually shipped where even squinting, you can tell that there's something distinct along the top. You can sort of tell which are the buttons. You can tell the most important information and the second most important information is there at the top left. And the groupings of everything else below it. So you wanna squint at your interfaces or if you wanna take that extra step of bringing them into an image editor and blurring them out or looking at them at 50% in FileMaker. Just so that they're small enough that it's hard to make out the key details but enough to see whether the most important things are coming through. You wanna provide landmarks to help orient users to where they are and where they can go. So now that we've talked about the hierarchy, now we're talking a little bit about actually how to implement navigation. So the first part of that is getting the hierarchy right. The second part is providing landmarks to help orient users and provide context to where they are. So I live in New York. I travel for work often from my town of Dopp's Ferry. I take the Metro North Railroad. I go to Grand Central Station and I get out and I take the subway to somewhere else in Manhattan. And then each step upon my journey, every time there's a junction point where I have to make a decision, figure out where I am and where I'm going, there's a sign in the Dopp's Ferry train station. There's a big sign that says Dopp's Ferry and it's got an arrow pointing to New York City. When I get out in Grand Central, there'll be a sign that says Grand Central Station track 42 upper level. With a sign pointing towards 42nd Street and a sign the other way pointing towards 57th Street. Those signs help me understand where they are, where I am. They help me reinforce the mental model I have of the world that I'm interacting with them. They help me know where I can go next. They help me gain trust in the system and decrease anxiety. Landmarks in your applications do the same thing and navigation elements. And so you want to think about all of the various junction points where somebody first finds themselves in your world or when they make a decision about where to go or when they arrive somewhere. You want to provide a landmark that'll orient them to where they are and provide elements that show them where they can go. When you're designing these elements, you want to make them as clear as possible. You want to provide well differentiated navigation elements that tell them where they are, what they can do there and where they can go. This interface comes from Angel City Data. This is one of their applications. And you can see very clearly differentiated. You can see both where you are. You're on the current record of Jake Johnson. And what you can do here, you can look at the three open orders, the zero history words if there were any. And the one quote. So you want to make it really easy to know where you are and where you can go. So in review of making it easy to learn, you want to help people learn to use your application by designing your interfaces to explain themselves, differentiate the things that are interactive and the things that are not and use visual formatting and styles to reinforce the model that you're helping them build. You want to provide clear and responsive feedback. Every action should have an immediate and understandable reaction. Don't make users wait without any information about what's happening. And as much as you can integrate that information into the interface. And you want to provide navigational elements to orient and direct users. Do that by understanding and developing a clear hierarchy that models the world as they know it outside of the computer. Provide landmarks to help orient the users and make those landmarks and navigation elements as clear and easy to read as the big green Helvetica signs on the highway that you can see when you're traveling 50 miles an hour. Now let's talk about how to make it efficient to use. So efficiency for users of software is all about reducing demand. Any software application provides three kinds of demand upon users. There's cognitive demand. How much does the interface make the user think? There's visual demand. How much information do they have to sort through and look at before they find what they need? And there's physical demand. How much do they have to move their body, their fingers, their mousing hand to get to something that they need to do to accomplish their goal? As much as possible, you want to decrease the demand in your application. You can do that by focusing interfaces to help users achieve specific goals. Being consistent and monotonous. Not requiring great precision. Supporting the development of productive habits. Anticipating and preventing errors and not interrupting. And as I did before, I'm gonna go through each of these in detail and again in the guide they're spelled out in even greater detail. So let's get going. Focus interfaces to help users achieve specific goals. As I said before, we are designing solutions to enable specific people to accomplish specific business goals. And as much as possible, you want to focus your interfaces to enable users to accomplish the goals in specific scenarios. So to do that, you wanna start out by figuring out who are the people in the problem space? Who are the people you're designing for? And you wanna really understand everybody in the organization who may interact in some way with the solution that you're designing. So if you're designing an invoicing app, it may be the owner of the business. It may be the person creating the invoice. It may be the accountant reviewing the invoices. And it may be the customer. You wanna understand each of the actors. And then you wanna identify each of the scenarios that they're facing. So again, in an invoicing solution, if the actor that perhaps you're focusing on is the person who's completing the invoice, the scenario may be that they're gathering and recording all of the information that they need to create an invoice. You want to identify the actors' goals in those scenarios. What are they trying to accomplish? It's not just they're trying to print a report. That's the task that they're doing to satisfy the goal. Or it's not just that they're trying to print out an invoice. That's the task that they're trying to satisfy. The goal is to create an invoice to ensure that the company gets paid or to produce the information required to satisfy government regulation. That's the goal. Once you understand the actor and the scenarios and their goals in the scenarios, you can create one sentence problem statements that help you really focus your interface. For example, when designing invoices start a solution, one of the problem statements we used was, design a workflow for a filemaker go iPhone solution to enable a business owner to create an invoice in remote meetings with customers when they're away from their office computer. Once you have a very clear problem statement, it makes it really easy to design a solution to that statement because you can use that statement to decide whether any particular information should be on the interface or not. And the answer is, if it helps serve the person you're designing for and accomplish their goal, you include it. And if it's not, then you put it somewhere else in the solution. Once you've identified the actor and the scenario and their goals and created a problem statement, as you're designing the solution for that problem statement, you wanna be as clear as possible in providing a clear path to completion. Now, these are two versions of the same interface that a occupational therapist might use to record a clinical visit. The one on the left has a very clear, straight through top to bottom path to completion. The one on the right has more of an S-shape where you go from top left to top right to middle to bottom to bottom right and then down. Now, it's true that in Western cultures, most people read with an S-shape curve, but you want to, as much as you can, understand their normal workflow, how they're gonna go through the information that they're having to complete to accomplish their goal and be as direct as possible in the path to completion. Anything that is extraneous, that doesn't quite fit in the service of the scenario you're designing for, you wanna move either onto its own layout or into a popover or a pop-up window. You want it to be accessible and the design term for this in interaction design is called progressive disclosure. And it basically means take anything that's not necessary for accomplishing the primary goal and move it so that it can be disclosed progressively when the user needs the information. In this case, it's the assets start solution and we're looking at the history of the checkout and check-in of assets. Well, if those things were included within the main interface, it would just provide a lot of noise for something that they only need to look at every so often. So by moving it into a popover using progressive disclosure, it reduces the cognitive and the visual demand placed on the user and allows them to be more efficient. Be consistent and monotonous. A consistent interface is one where each instance of a button or an element that serves the same function as one presented prior is styled and formatted in the same way. So you want to be internally consistent in the look, feel, and function of elements. Now, by internally consistent, I mean consistent within a particular platform. So you wouldn't necessarily use exactly the same styling on the desktop that you do on the iPhone or the iPad filemaker go interfaces because they have different form factors and different needs. What's really important is that somebody can apply their knowledge, that the model that they've built of how something works and the learning that they've done from one platform to another. So each time you make a decision about how a navigation element's gonna work or a button or a piece of text or an editable field, record that as a style and use the styles to help you maintain an internal consistency. A monotonous interface is one where there is one and only one way to perform each action. The best example I can give you of a monotonous interface is the iPhone and the home button at the bottom of the iPhone. So when you are within an application, there is only one way to exit that application and get back down to the springboard, the launcher, and that is to press the home button at the bottom. Because there's only one way to perform that action, it limits the number of choices that users have to make. And so when you're thinking about putting multiple buttons on the same interface, you wanna limit how often you do that because if you have three print buttons on the same interface as opposed to one at the top, it actually slows the user down just a second because they have to make a tiny little decision about which one to use. And so it's not necessarily an unviolable, it's not a rule that you can't ever break because there are times within the workflow that it makes sense to bring a button closer, but you wanna not do that just all the time. Don't require great precision. Physical demand is significant and there is a rule in design that says the further away a target is or the smaller a target is, the longer it will take somebody to reach that target to acquire it and the closer a target is or the bigger it is, the easier it will be to acquire it. As makes sense within the workflows that you're designing, you wanna minimize the distance somebody has to travel and the precision they have to use to get to the things that are interactive. So you wanna make sure not the size targets smaller than the recommended. On a desktop, the smallest size that somebody can really acquire without great precision is 12 pixels by 12 pixels. Really much more comfortable is 24 pixels by 24 pixels and on a touch device, the smallest that you really should use is 44 pixels by 44 pixels. Anything smaller than that is really gonna be very fiddly and hard to get correct. And in fact, what you really wanna do is maximize the target size. These screenshots come from the contacts interface on FileMaker Go on the iPhone. And you can see the two little buttons on the left and the right. Well, if the designer had sized the buttons to the size of the icons, they would be really hard to acquire and instead what they did was besides the buttons to the full available space which gives a huge touch target. You want to, as much as you can, provide the maximum target size that you can within reason. You wanna support the development of productive habits. People will develop habits to things they do every day and those habits will either be productive or destructive and you wanna help them create productive habits. To do so, you wanna set a logical tab order. Make sure when you finish designing an interface to go back and set the tab order so that it works within the path of completion that you've designed. You wanna set field exit options so that people can exit the fields in the way that's most familiar and comfortable to them. You wanna enable the use of keyboard shortcuts. And in FileMaker 13, there's a number of ways you can do this. The easiest way is in your script editor, enable, check the scripts that you want to show up in the script menu. The first 10 scripts that you check will have the keyboard shortcuts of command one through command zero on Mac or control one through control zero on Windows. You can also use custom menu items or on layout keystroke triggers. You wanna make sure you take advantage of those. And you wanna be consistent in configuring custom dialogues. If you set up your custom dialogues, the default button has always canceled, but every so often you make the default button delete. Well, you've just enabled a destructive habit because users will be very familiar with just dismissing the dialogue, reading it quickly and dismissing it. And all of a sudden you've enabled the destructive action in the default. You wanna be consistent that you are not putting the destructive actions in the default and that you're formatting your dialogues in the same way each time so that users can develop productive habits around them. You wanna make sure not to interrupt. People's attention is limited and fragile. And if you interrupt somebody, it will take them a while to regain their attention and their focus. And so you wanna make sure that you only interrupt when you absolutely have to. And instead, wherever you can, as I said before, integrate the information that you need to give them into the interface. The other thing that's really important in helping efficiency and learning as well is anticipating, preventing, and helping users recover from errors. We are all human. As we're designing software, we will make mistakes. Our people who use our software are human. They will make mistakes. The way you help users recover from those mistakes make all the difference. So to do that, you wanna start out by identifying potential errors. And there's a couple of different kinds of errors that are sure to happen. One is validation errors. If there are data points that you require or require to be in a specific way, you wanna make sure to identify those upfront and take action to provide users information about those validations before it becomes an error. So there's a couple ways you can do that. One is to highlight required fields. If you have an interface where there's just one field that's absolutely required, show the text string required or an asterisk in some way. You wouldn't necessarily wanna show the text required next to every field because that just provides a lot of noise. But if there's one or two that must be required or they're gonna fail validation, you wanna call those out. You wanna constrain choices. There's a number of different ways you can constrain data entry choices in FileMaker. You wanna take advantage of those. You can use radio buttons, checkboxes, drop-down lists, pop-up menus, and drop-down calendars. You can also create filtered picker windows or pop-overs where you've put a portal within a window or a pop-over and use that to help users constrain the choices. You wanna provide inline validation. So the best place to validate for something that users are gonna need to make sure they get right is right at the place that they're entering it where their focus is already on the field that they're entering. Using the refresh object script step and scripts and custom merge variables. It's very easy to do this now. So on the left, I'm counting for the number of characters in a field and I'm validating. Well, you can use a on keystroke trigger combined with a script step to count and a variable and a refresh object to just refresh that 115, 114. Similarly, with the date of birth, you can use an on exit script trigger that again goes to a script and does a little calculation to see if the data is right and uses a conditional formatting and an emerge variable to provide them feedback. You want to provide actionable error messages. When errors happen, you wanna provide users a very clear path to recover from it. On the right, there's an error dialogue that says there was an error. We cannot complete this sale and the choices are okay or cancel. Okay is a terrible string to use for a button in an error dialogue because it doesn't give the users any information, it doesn't give them a way to recover. As opposed to the one on the left that says this sale is marked tax exempt but we do not have the client's tax exempt form on file. So we've identified the problem. Now we're telling them how they can recover from it. You must either upload documentation or edit the invoice and the buttons give them those two choices. So they have a very clear path and either one will help them recover from the error. Don't interrupt. As I've said a couple of times already, you want to be respectful of your user's attention. You wanna be considerate. And there are two ways that you might often interrupt and one is modal dialogues, modal windows and the other's custom dialogues. Both of these are really important tools when you absolutely must get the user's attention but you wanna reserve modal windows and custom dialogues. For those times when you absolutely must get a response from the user or inform the user about something or they cannot accomplish the goal that they're trying to accomplish. Otherwise you wanna integrate the information into the interface and find other ways to communicate to the user without interrupting their flow. So in review of how to make it efficient to use, you want to reduce the demand imposed by your application. To do so, focus interfaces to help users achieve specific goals. Be consistent and monotonous. Don't require great precision. Support the development of productive habits. Anticipate and prevent errors and don't interrupt. Okay, so as a global summary, design your interface so that it explains itself. Provide feedback, identify and mirror the underlying hierarchy. Enable efficiency and prepare for, detect and help the users recover from errors. I would be glad to take questions at this point. Thank you very much, Don. That was really, really great content there. So before we get into the Q and A, I'd like to remind everyone how to actually ask questions and then also provide a little bit of extra resources for you here. So first off, if you do have a question, please go to the go to meeting control panel. Click on questions and enter your question and hit send. So please put those questions in now so that we can get any if you have any before we finish up here. A few other resources that will be handy for you. This actual guide exists in our final maker community. Actually, Don, can you mind if we go back there? Exists in our final maker community where you can get tips from experts and collaborate with other developers there and share your experience. There's also some great content there, like tech briefs such as this, as well as our design performance guide that talks about performance in FileMaker and how to design performance solutions. There's tons of examples there as well as news and updates. And also we do have some members only webinars for people that are members of the community. You can also get this guide at the community. So if you go to community.com, and actually there's the link direct at the bottom, you can also get to it from the featured resources at the very bottom of the homepage just by going to community.finalmaker.com and look for design interaction guide. Also, other webinars like this are available if you go to finalmaker.com slash support slash webinars. We have a bunch of recorded webinars there as well as see the schedule of webinars that are coming up. We have some great training resources at finalmaker.com slash support slash training. And of course, if you do have other questions and want to reach out to Don directly, there is his contact information. We will leave this up as we answer some of the questions here. And so let's dive in. Don, actually there was one question that was coming in. You were talking about interviewing and talking to users. And some people were kind of curious about getting buy-off to actually interview all of the people at a company. How do you actually go about getting buy-off from the people that are paying the bills as well as the people that are doing the work to actually go and interview and talk to them? And what types of things do you do when you interview them to figure out what their tasks are and what their goals are? Don, you might be muted. Let's see if we can get you back on here. Sorry about that. That's a great question. And it's a great question. And actually that question is the higher subject of the first day of the design studio that I teach. But let me answer it in summary. So the first thing that I do is I make it very clear that our goal is to spend as little money as we can getting to the best possible solution. And the way to do that is to move the expenditure of money back so that you're learning as much as you can up front. There's a Frank Lloyd Wright, I think it's Frank Lloyd Wright quote that says, it's cheaper to fix things with a racer on the drafting board than on the construction site with a sledgehammer. And it's the same sort of thing. So first thing I do is I get buy-off from the owner to help them see that it's going to save them a lot of money by gathering this information. And then I kick off every project by convening a meeting of all of the people that are involved. And I generally have the owner introduce me, make it clear that we have a process that will lead them through this process. Designing custom software is expensive and scary and prone to budget overruns. And so we have a process that will help them get through this. And then we set up a meeting where we communicate the expectations that we are going to talk to everybody and that I'm going to ask a lot of no disease questions. And that our goal is to try to understand as much as we can about the workflow, the people, the business so that we can have a really good understanding when we get started. And then as I'm interviewing people, I use a combination of interview techniques, making sure to ask open-ended questions. So questions that elicit more information rather than closed-ended questions, which close off information. And I look around the room and I see how many calendars are on the wall and how many stacks of paper. And I ask them about all of these various artifacts and what they're for. Because I'm trying to figure out what are people doing to solve the tasks that they're doing now to accomplish the goals? And what parts of their existing solutions can we learn from? Like I said, that's a shortened version of the answer. We cover it in detail in the design studio. And I've spoken about it a number of times at DevCon. So if you have those slides, you may want to go back to previous years and look at some of those presentations. Great. Thanks, Don. Actually, we should just point out, I think we sent a link to the guide that was unfortunately the incorrect link. We will be actually putting that up here in the chat soon. And for any of you who are chatting us, we are sending you out a new link. So you should be getting that soon. Next question, we actually had two that we're talking about color. One was asking, we have a general comment about your thoughts on using color. And another person was curious about your thoughts on fields changing colors to indicate errors or required fields or anything like that. So I guess part one is about using color for fields to indicate errors or things such as that. And then general thoughts on color. So color can be very helpful to communicate hierarchy and status and outliers. But you want to be careful because 10% of the population is colorblind in some way. And so I generally will start out by designing things in black and white and we'll get the interface so that communicates well enough in race scale and then add color for additional emphasis and visual pleasure. So I definitely do use color. And you can use it for those things that the questioner was asking about. But you want to make sure that the interface communicates without color first and then use color to enhance the experience and enhance the communication. Did I get both of the questions? I don't know if I did. I think that answered it there. The general idea of one of the things we always have to remember is dealing with accessibility with people that are colorblind. And the use of color can be helpful, but it can't be the only thing that we use. So another question here, you want to take this one. When is it a good idea to incorporate all tables into one file versus creating a solution with the collection of several files? I know that this probably has some performance implications if we want to talk to it in that way. But I guess we're probably asking you in terms of usability or interaction, what is your thought on one file versus multiple files? That's a great question. And my answer has changed over time. Taking performance character considerations out of it, taking, deploying to go out of it, just from. So one of the personas in any solution is the current developer and future developers. And so I am always trying to communicate as much as I can with the me six months or a year from now that doesn't remember what I did or people that come along after me. And so I very often, before thinking about deploying to go or thinking about performance characteristics, or an issue, would segment data tables and files in a way that makes communication easier so that you don't have 300 scripts in a file. You have a set of modules that are now that's a little bit more muddled because it's not as beneficial to deploy multiple files to go. Although there are some performance benefits from limiting the number of tables and files. So you have, instead of deploying your entire solution to go, you deploy a subset of the tables and the functionality that's just going to be forego. Matt, you want to add anything to that? Yeah, I think that's definitely a great way to look at it. I've always felt the same way when it comes to, I think similar to you, we have gone both ways on this in which at one point I was thinking, no, it should always be in one file. We can create everything in one file. We might as well have it in one file. But then, especially when you have times where there are people that are very familiar with FileMaker and like to use the status toolbar and like to use the layout dropdown to navigate around, when you start to get multiple interfaces in there for different people with different sets of layouts, that layout dropdown loses its meaning after a while. You can't really easily navigate between things. And so sometimes breaking things out for those kind of scenarios actually can be quite helpful in terms of security and other pieces where you can really control the experience. And actually on that same topic, let me see if I can find this question here. Here it is. I find myself in situations where I'm pressed to design interfaces where users with multiple roles quote unquote need to use the same interface for reduced complexity or cost. So they end up being busy and crowded, but this is acceptable to the stakeholders at first glance. How do you approach this type of situation or do you avoid multi-role interfaces at all costs? No, there's a real balance between simplicity and complexity and there's nothing that says you can't have multiple scenarios in one interface. You wanna just be clear about who's using the interface and how they're gonna encounter the multiple various scenarios and make sure, if you're oversimplifying an interface, that's not gonna work for those people either. One of the things I didn't talk about in this presentation was that you gotta take into account the user characteristics, are the people that are gonna be using the interface, are they gonna be, you know, temp workers are gonna be on the job for three weeks, or are they gonna be career people, they're gonna be using the same interfaces for 10 years. And so it may be that that's what efficient for a high-level intermediate user is not efficient for a novice user. And so there is that tension between making it easy to learn and efficient to use. I tend to design my interfaces for specific scenarios, but certainly there are times where you add in a second or a third scenario to one interface, but you do wanna be very cautious about it. You wanna be thoughtful in making choices about it and do it in a way that the second scenario or the third scenario doesn't diminish from the ability to accomplish the first scenario. And I think both of these I think get to a similar question which comes up in a lot of cases and I've definitely heard it a lot before in my interactions with other developers out there, which is this idea that my clients don't wanna pay for this. They don't want me to spend extra time doing multiple interfaces. They just want me to do one thing and that's good enough for them. And so maybe it kind of does come back to this, what are some techniques to win people over with design or win people over with, I know what I'm doing here, I'm making the best thing so that your users can understand this properly without making a cluttered busy interface. Oh, well the answer to that is very simple. When they're trust and increase their power. So users will be skeptical of change, skeptical of what is gonna cost them and what is gonna get them. And so you start out by looking for the low hanging fruit that will provide the biggest bang. Allow them to see that those things are successful and on time and on budget and you'll start to win their trust. Increase their power. I am constantly looking when I'm designing for how can I intervene within the user's normal workflow in a way that amplifies the power of the actions they're already doing. So for example, a number of years ago, I think I've given this example at DEF CON, I designed a solution for a group in New York City that gives money to artists and they need to track stories about those artists so they can report on their qualitative impact on arts and the artists in general. Well, they were already sending stories to each other via email. So we created a pop mail scanner and enabled an email address so they could send those stories directly to an email address, pull it into the database and associated it with contacts. So we took an action they were already doing and increased the power of that action. So they were doing something already and now that same action results in those stories being captured, associated with contacts, taggable and searchable in a way where they're not doing anything different than they were before but they've got more power now. Look for ways you can increase their power. All right, well, thank you Don for your time. We're right at the end of our hour here. We really do appreciate everyone for logging in and paying attention. We hope you got a lot out of it. I know I did. Thank you everyone and we hope you can come back and watch another FileMaker webinar in the near future. Have a good day.