 First of all, I just want to check that everybody is aware that this is the user experience versus user ability talk. I was only expecting about 10 or 20 people to turn up, so just making sure, feel free to leave now if you're supposed to be somewhere else. It's greatly appreciated everybody coming. I know it's the last session and everybody either wants to be in the pool or at the bar or on the plane on the way home. So I just wanted to say thank you before I start because you may be asleep or have left by the end. So I thought I'd get that in now. So I just wanted to quickly run through a bit about the talk because I know that the title is at best wanting for more detail. It's slightly ambiguous, so I just wanted to clarify a few things before we get started. So I wanted to do the talk because every single day I hear terms being thrown around together. For instance, things like user experience and usability, functionality, ease of use, UX, UI. So what I want to do is just to clarify a few of those terms in the way that I use them on a daily basis. That was the first reason for doing the talk. The second was we, at work, we got a new operations director in and at the time I was building lots of designs and architecture and things like that. And his first question to me was does the client care? I don't know. Maybe I've been wasting my time for the past x amount of years trying to build nice interfaces and nice experience. The answer is do our clients actually care what's been received to them? Is that important to them? So they're the main reasons why I wanted to do the talk. So I'll get straight into it. And this was my response to our operations director. So I did some research and I looked at the companies or the systems that I use as a point of reference every single day. So I spoke to a designer this week actually and he gave me some great advice. He said, if you're not a designer and you're not a UX designer, you can't come up with your own designs and just copy somebody else's. So that's what I do on a daily basis. We have a running joke in our office that Google and Facebook are our biggest R&D departments. They do all our R&D for us and we just take their ideas afterwards. But on a serious note I would suggest from these stats and I will go through a few of them. But if we take the Facebook stat for example, that's 1.65 billion users on Facebook. That's half the amount of people who have access to the internet in the world. So the odds are that your clients will be using Facebook on a daily basis. Now we run a programme with a local college and I sat in front of a thousand students and I said, oh can you put your hand up who uses a database on a daily basis and they all look to me like I've got four heads, like no chance. So I then asked them well who uses Facebook and who uses Instagram, who uses LinkedIn, things like that and hands started popping up. So surely you see those as databases, there's just a huge repository of data. So what I do now is if a client wants me to build a CRM system, I know Facebook isn't, but it is a big repository of data that's presented to a user in a nice way. So I try to look for inspiration of products that already exist on the market. I don't like wasting my time to try and reinvent the wheel. Good thing about YouTube, although it says it would take you 60,000 years to watch every piece of footage on YouTube, I know that is impossible, but it is technically impossible as well. The reason is by the time you finish watching the first video on YouTube, an extra thousand hours of footage have already been uploaded. So although the talk will run through the techniques that I use on a daily basis, it doesn't go into great detail about any methodology and things like that. So if you're a designer and you're a rich in UX, please bear with me, it doesn't go into great detail. I wanted to try and give you a snippet of what I'm going to try and demo at the end if we've got time. So this is the example file that you can download. It has a logging process to begin with. If you didn't notice, you can type any username and password, but there was a reason because I wanted to show a logging screen as well. Okay, so a bit about me. If you couldn't tell already from the accent and the people at the back if you can't tell about the croaky teeth, I'm from England. Okay, my name is Jordan. I was previously, before I entered into the filemaker world, I was previously a footballer. As you can tell from my stature, that wasn't American football. So I was quite lucky as a child when I was 19 to 14. I played for Manchester United. I was part of the youth system. I then moved on to Preston North End where I got a few FA cup shirts, league cup shirts. Then I got offered a scholarship at a university in America in Baltimore at Loyola. So I went over there to play out here as well. So what qualifies me to be speaking today about the difference between UX and usability? Well, I've been quite lucky at the company that I work for, which is called We Know Data. I've got to build some systems for some pretty cool clients. So I've been the lead design architect and developer on 10 systems deployed throughout Apple on every single type of filemaker platform. I've also been, I also did the design and the lead for a system within Rolls-Royce and we're currently on our second system for Rolls-Royce as well. The day before I flew out to Vegas, I was on-site for five weeks with TeamGV, which is the British Olympic team, where we deployed a system that helped the athletes get kitted out for the Olympics. So we processed 1,000 athletes, 120,000 items of stock all through a filemaker system, running through check-outs, iPads, et cetera. So the key thing that I want to pick up about the TeamGV project is that the system that we built for TeamGV had to be able to withstand volunteers. So people who would turn upon a morning to help with the event and there were 600 volunteers that were on two-day rotors. So every two days we got 100 new volunteers that we had to train in half an hour how to use the system. So there was a signing process, there was two desktop machines, there was four warehouse machines, there was six check-outs, like a Walmart check-out that was running off a filemaker system, and there was 35 iPads. All 100 volunteers in half an hour had to be trained on the whole system. So usability and user experience were key in that process. So I'll put my money where my mouth is. These are a few of the systems that I've designed and built. If you don't like the look of them, there's probably no point in you listening to the rest of the talk. So this was a system that we built for a charity in London. These are a few iPhone examples of different systems that we've built. This is a system that we built for, well, I suppose you can guess. This is all in filemaker. So every design is in production in filemaker, all being used. Okay. Oh, everybody stayed. Thank you. Okay, so now we've got that bit out of the way. We can get more about the crux of the actual talk itself. Okay, so the talk has three parts. I'm going to try and explain as quickly as I can the difference between some frequently used terms. I'm going to go in a bit more detail about the method that I use on a daily basis, and then if I'm fast enough, I will try my best to get to the example file and solution, cool things. I can't promise it'll be as cool as Matt Petrowski's, but I will try. So to try and highlight what I'm talking about, as simple as possible, I use this diagram to try and explain the difference between a user's experience and what I talk about usability. So in this diagram, and I just want to put this caveat, I'm not talking about cost here, so if money is no object, we try and ask people what car would you choose. Now, in terms of usability, they're both exactly the same. They've both got a steering wheel, a handbrake. If you've got a driving licence, you can drive both if they both stick and you have the right driving licence, of course. But you should be able to drive both. In terms of usability, they are exactly the same. One's as easy to use as the other. But for some reason, every time I've asked people which car they would choose, the majority of people go for the Porsche. I wonder why. Okay, so these are the frequently used terms that I'm on about, although there are vast amounts of more, but I just wanted to try and cut it down to just a few. Okay, so we've got functional. We've got usability design and user experience. Can I just have a show of hands if people have heard these terms being used? Fantastic, that's everybody. Fantastic. Okay. So first I want to cover that these terms are used almost interchangeably and I see them every day, even with my team, they're used interchangeably. They have functionality and all the experience and all the usability. Now what I want to try and get across is that what I say to my team is that yes, although they are interchangeably linked to each other, they can all be treated separately. So this is the diagram that I use with my team. So I say that in terms of user experience, we've got three parts. We have usability and that can be treated by itself. We have functionality and again that can be treated as its own element and we have a user interface design as well. Now the combination of all three makes user experience. So you cannot have a great user experience without the system being functional, being usable and having that nice interface, but you can have a functional system by itself and you can have a usable system and you can have something that looks aesthetically pleasing. Let's get into the actual definition of functionality. So functionality ensures that the product behaves according to the functional requirements and does not take into consideration design principles. So the key bit here is that it's not about design. When you're talking about functionality, your decision is not based on design, it's not based on aesthetics. So let's go with the requirements that we get from a client. As a gardener, I need the ability to record information about my jobs. This may be a functional solution. Has anybody seen a worse design than this? I was very proud of my team. I asked them to come up with the worst design they can come up with and they came up with a file maker starter solution design. No vibrant colours, big colours, gradients that don't match. So I did this talk as a practice talk to a group and somebody came up to me and said this isn't quite correct. So I was okay. They came up to me and they said that, for instance, LinkedIn. The man came up to me and said, I can't find this certain function within LinkedIn, thus LinkedIn is not functional. I said I bet you that if you speak to a LinkedIn engineer at head office, they will be able to tell you where the function is. If you cannot find the function, it means that it is not usable. So, for instance, if we go take it to the extreme, if a user gives you the requirement that they want to go from a context list to a context detail, a functional solution is you can create 60,000 files, put it into a temporary folder, send them to the temporary folder, tell them that it's halfway down the list and they can click on it and open it. That's a functional solution. No matter how long it takes, no matter what process you give them, they can get to the solution that they want. So, this is different than usability. So, usability is the ability to use something easily. And easily is the key point. It has to be easy to use. Now, usability isn't justifiable. So, you can't say that Barbara, who's used the system for 60 years, she finds it usable. When you talk about usability, you have to talk about is it usable for everyone who's going to be using the system? Now, I'm not necessarily talking about is it going to be easy for the five-year-old who downloads the app from the app store. It's within the context of your requirements. So, usability isn't justifiable or quantifiable by, well, one person knows how to use it. It must be usable. We're striving for the ease of use. So, to highlight that, these are a few products that are functional, but not very usable. The Katrina, I actually sent her an email and she was ever kind of let me use these images. The project's called the Uncomfortable Project. There are vast amounts of designs that she's done for perfectly useless products. So, this is the Uncomfortable Project. So, again, it's functional. If you tried hard enough, it would fit for purpose, but it's definitely not usable. So, how do I translate this into a system? So, and I apologise for the contrast on the colour scheme. It may be hard to see. So, the main thing that frustrates me, and it frustrates me when I was applying for the visa to come over here and talk, is that I got a form, and the form had vast amounts of information that I had to complete. And I submitted the same form six times, and every single time I'd missed some key bit of information. If you think about the vast amounts of fields that we present to users on screen, they may have the same feeling towards our forms, as well. So, in terms of usability, again, this isn't necessarily... Our decisions in usability aren't based on design. They're based on trying to make the system as easy to use as possible. So, to make this form more usable, if you haven't spotted it, you could literally just tell the user which one's the optional field. Now, that's okay, and the rule behind this is that if you've got less optional fields than you do mandatory, then highlight the optional one and let the user deduce that you've said this is optional, thus the rest must be mandatory. Now, that still requires some thought process by the user, so we can go one step further. We can add, and apologies again, I think quite... I realise how big the room would be. The red asterix on the side of the field is pretty commonly known that this means that it's mandatory. As well, you can either choose to remove the optional and let the user deduce the one that doesn't have its optional, or you just leave it in. It doesn't really matter what you use to notify the user that something's mandatory as long as it's consistent across your whole system. So, for instance, if you try and sign up for Facebook, they give you a red exclamation mark to tell you you've missed a field. If you use Apple and you submit a form, they turn all the field labels red. It doesn't really matter what it is because the user can find that it's easy to use and understand. So, if I was sat in your shoes now, I'd be thinking, well, surely this all is about user experience. So, this is where user experience, in my opinion, differs. User experience is all about the feeling. The aim for it to user experience is to create happiness for the user. It's an emotional response to a piece of software. Imagine that. But we all know that we can all sympathise with the angry phone call that we get from a client or when our phone stops working. I mean, I can literally go nowhere without my phone. So, I have an emotional connection to a piece of software and hard work. So, the aim here is to create happiness. And it's to create happiness before, during and after using your piece of software. So, I'm going to show through a few examples of systems that I use on a daily basis, and I think that it's really good usability. It gives me a good emotional reaction. So, the right hand image, that's from an icon's library called Icons8, which is all the icons have come from. When you download your copy of Icons8, the right hand image is the screen that you get presented with. I got presented that screen and I thought that was so funny. I literally went to the whole office and got them to download Icons8 just so they could go through that browser, the big child that I am. And then there's Slack as well. If you didn't know already, there's a function in Slack that you can customise the loading message for your team when it opens. So, for instance, you can log on to the Slack admin console and if you've just had somebody that's gone away, you can literally have like a welcome message for when they get back, or it's like they log on at 5 p.m. on a Monday. You can say, you should have been logged on all day, Jordan. Again, these are these things in some of these apps and there's another one that I quite use frequently. This is MailChimp as well. It's a campaign through MailChimp, but the little monkey comes up and gives you a high five. I will admit I give the screen a high five the first time that came up. Again, now, after I've displayed these, I want to give you a disclaimer with these images. And that is that quirky messages, fancy icons and animation alone do not constitute a great user experience. I'm just giving you extreme examples so you can have something to relate to on a daily basis. I want to undermine the effort, consideration and multiple factors that go into making a great user experience. Again, let's go back to those frequently used terms. There's one term that I'm not going to continue within this talk and that's functionality. That's because as professional developers, I don't want to stand here and tell you how to meet functional requirements. What I'm talking about is the difference between usability and user experience. If we can see the right-hand design on the screen, it's purely based on making it as easy as possible for the user to understand. Again, this is from Icons 8. If you want to register and continue for the download, you'll have to complete this form. The right-hand screen is based on making it easy to understand. They've made the assumption that if the user has got to this screen that they haven't signed up to Icons 8 before, they've made the create account button larger than the tiny login button before. That's because if you've stumbled across this screen and you have a login, the option's there, but they're making the assumption that most users will want to create an account at this point. Whereas the user experience screen, I don't know whether you can read it underneath the message, but this is taken directly from Icons 8. They've left another nice message for the user as well. You can see that the design isn't too bothered about... It is bothered, but it isn't predominantly focused on making it really clear to the user. You can see the login button has got as much strength on screen as the create account button. They've sacrificed some usability to give that user some experience. Let's look at usability. I'm sure everybody's seen that before. I think somebody stole that on a previous presentation. That's what we've come with going last. These are the five ease of usability that I try to stick to on a daily basis with our team. Again, there's loads of methodology that goes with usability design, but these are the five that I quite like to reinforce with our team. I think that good usability should be effective. This is the completeness and accuracy in which users can achieve specific goals. That is, I want to do X first and foremost, regardless of functionality. When it comes to usability, can I do X? Next one, it should be efficient. A system with good usability should be efficient. Efficient, I'm defining that as the speed in which users can complete the tasks for which they use the product for. The key bit in here is the speed with accuracy. Speed is useless. Paper is fast, but it's not accurate. Efficiency is speed with accuracy. It has to be engaging. It has to be pleasant and satisfying to use. The visual design is the most obvious element to this characteristic. A nice interface when it comes to usability does help, but it's not the be all and end all. As you can see, we've used words like pleasant and satisfying. It's not like happy. You don't have to make the user to want your system. You just want to make them not hate using it when it comes to usability. That's why we're using words like pleasant and satisfying. The most important that I drill into our team is that good usability has to be error tolerant. The design has to prevent errors caused by the user, and they must help the user in recovering from any errors that do occur. We know, and this is one of our developers' quotes, he said to me, after all, developing is just putting bugs into a perfectly working empty file. Right? Yes, it is. Again, we know that users will make mistakes, and we will make mistakes, but when it comes to usability, it's not necessarily about stopping those mistakes. It's about giving the user get-out clause when they get themselves into trouble. Good usability needs to be easy to learn. This isn't easy to learn that anybody can pick up this tool and use it. It needs to be that you can free up the user's time so that it can gain more knowledge. When you put more functionality into a system, they're not already at capacity. They've got the stuff that they don't need to know or need to use their skillset for. Let's take that away from them. When the hard things come in the system, the hard processes, they've got the capacity to deal with that in the system. This is the main... When I try to explain this to clients, this is the main point of friction that I get. People are concerned that what I'm trying to do is a skill in their job. I'm trying to take away all the skill by letting the system take over. I try to reassure them that that's not what I'm doing. What I'm doing is taking the noise away so you can focus on the things that you're good at. Let the system do all the boring processing stuff. I'll free up your time to do the stuff that you should be doing. Again, that's the five ease of usability. In my presentation, say, audience participation will be encouraged. This is the point that I may need some. Or, sorry, I will need some. This is a task that I give to our developers. I asked them, in line with the five ease of usability, what would you do to make this door more usable? Has anybody got any ideas? A door handle. Fantastic. What type of handle? Pull, push, door knob. Anything else? Could we go even further? What could you do to open automatically? Fantastic. Remove it. Fantastic. Just get rid of the door. Now, the point is here is okay. So that's fantastic. I tell you what, let's remove the door. What happens is this is your front door. What happens if we put a handle in it's a door to a kitchen? You've got a waiter coming in, he gets opened straight onto him. This is the same response that I got from our development team, was the door handle. Then they started to, oh, what handle could we have? It could be chrome, it could be bronze. Then we got, let's just get rid of the door completely. The point is that we can't make a decision. Sorry, that was very unfair. We can't make a decision because we don't know what the door will be used for. So what you have to do is you have to know your user's world. More importantly, you have to understand their pain. When I talk about pain, I turn into a councillor when I speak to clients. I just tell me things that get annoyed when you're at work. I get like, we haven't got enough parking. It's a very English thing, the tea's not good enough. There's no scones at tea time. So what you have to do is you have to get out of the office. You have to put yourself in your user's shoes, and your user's shoes are not in your office. So get out, visit your users. Now you need to visit your users where they are going to be using your product. So if they're home users, unfortunately, you need to go and see what they're working environments like at home. If they're mobile users, go and see if you can spend an hour on the road with them, if they're local, or go into their office, see the environment in which they're working because that will make your decision of how you use or design a system. When you're designing a system, the massive downfall is that, especially for my team, we design systems in a meeting room like this. Nice, quiet walls. We get lunch ordered in. There's tea on tap, of course, being English. It's a nice, quiet environment. We put a lock on the door. It's soundproofed. We make design decisions in a nice, calm environment. Unfortunately, I've been to some of our clients' offices, and they don't look like that. Our systems are used more like this. So without knowing what your system is going to use for, there's no pointing design in this calm scenario. Next time you're in a client's office, just take a step back, especially if they're open plan, and have a look. Just sit back, let them carry on. See how many times people get distracted from their task by a conversation that's across the other side of the room. People get up and leave the task, walk to the side, have a conversation, get a coffee, spend an hour talking to colleagues, and then come back to the task that they were halfway through. See, it's just starting to see these patterns, because if you design a system that locks somebody into a process, and actually they don't finish that process because they're too busy talking about what happened on Breaking Bad, or things like that, then you've put your user into a situation that they can't get out of. This is my justification to our project managers why they say it's taking so long. Why is this not finished yet? I said it is finished. 10,000 ways that definitely didn't work. This is designed to be hard. There is no two ways about it. This is a tough task. You're trying to decide on behalf of a user what they're going to want, because, let's be honest, we get given a requirement that says, I want to add a contact. They don't say I want to add a contact. It needs to take me 10 seconds. I want to go from this screen to this screen to this screen. I just want a contact. Thanks. Let's look at user experience in more detail. As I said, user experience is all about the feelings. I showed my girlfriend this presentation as I was writing it. She turned around to me and said, why are you talking about feelings? She said, you only have two feelings. I said, what do you mean I only have two feelings? She said, you've only got tiredness and hunger. That's fair enough. Feelings are so important because, as humans, we instinctively remember bad experiences in more vivid detail than we ever remember good experiences. That's been scientifically proven. There was a study done at Stanford, which said some people do have a more positive outlook, but almost everyone remembers negative things more strongly and in more detail. No matter how good your system is, if there's a bad experience, the user will latch on to that bad experience first, and they will keep that in their memory. Let's go back to our ancestors where you play with fire, you get burnt, you don't play with fire again. Bad experience. Users have the same reaction. I click a button, it took four hours for the script to run. I won't press the button again. There is a ratio and there is some conflict in research, but some researchers did come up with a ratio of one to five. Every one bad experience that a user encounters in your system, there needs to be five good experiences. If there's a really bad experience, you need five really good ones, there just needs to be five good experiences in the system to counterbalance that one bad one. What do I think makes a good user experience? Again, this is not an instruction manual or a sure guide to how you get a good user experience. This is just the things that I fall back on if I'm struggling to work out, actually, how do I get users engaged to get that emotional reaction? The first one is colour. Again, like with anything, if you go on Google and do research, or go speak to different people, there are conflicting statements on how colour affects people's mood. From my experience, what seems to happen is if a nice blue pallet, and if you do look online, most products do have a blue pallet in them, there's research to suggest that the first emotional response to blue is trust. Whereas the first emotional response to yellow is anxiety. Straight away, if you present somebody with a yellow-based screen, which I wouldn't suggest anyway, but their first emotional response is anxiety to using that screen. In terms of colour, obviously there are things like the traffic light system, big red that obviously warns users as well, but there have been vast amounts of talks that have gone into that in more detail, so I won't do that too much. The next one is visual feedback. Visual feedback is users want to know what's happening. They don't really care if something is going to take four hours, they don't really care whether it's going to take ten seconds, they just want to know how long you're expecting this thing to take and to let them know that you're processing it. One thing we did for visual feedback is that, for a system that we built, we imported vast amounts of data and we had to loop through about 50,000 records, creating different tables. What we did and we know the client loved coffee, absolutely loved coffee. What we did is we calculated, based on the average time it takes to go make a cup of coffee, how many cups he would have to drink before the import would have finished. The next one is show-off effects. Now, that's a very swooping statement, but the show-off effects are anything that grabs the user's attention. Straight away, when I open up Matt's solution, my Petrowski in the last session, the first thing that got me was that splash screen, the video. If you haven't downloaded it, please go download the app. It's built into the system, it's got a splash screen that presents like a video that plays. They're the show-off effects where the user goes, oh, wow. They're the kind of things that you want to grab your user's attention. Now, in FileMaker, we can do that in slide controls, popovers, dialogues, we've got web viewers. Anything that makes the client go, oh, you guys have done a great job. The next one is emotional effect. As I said, my girlfriend and I have been together five years and I can't even guess what her emotional state is. Never mind our users, I don't know whether she says, I'm not in a mood, means I'm in a mood, or I'm not in a mood, or do I need to go buy your present? So trying to second-guess clients is hard. So what you need to try and do is not understand their requirements, but understand them as people. You need to try and understand what annoys them, what doesn't annoy them. And again, this goes far beyond software. The parking, there's not enough parking, or I like tea, I like coffee. You need to try and understand them because your system has to relate to them on a personal level. And the last one is, in my opinion, is the easy one, it's company branding. The first thing I do when I go to design a system is I open the client's website. If they've got a strong brand and a strong website, I just copy it. They've paid for that branding, they've paid for that design, they've paid for the look, I'll just go copy it. Now what company branding does, it makes the system feel part of the organisation. It feels like it's theirs, it's not a third party system that they're forced to use. They open it up, it's their branding, they feel at home, straight away they feel relaxed in their environment. So the next one is, people will buy the image and then they will fall in love with the details. I've never presented a system, a finished system to a user, and I've never heard them say, where's requirement A that said I wanted a tooltip on layout six, six months ago during the planning phase? It just doesn't happen. What happens is you need to get buy in day one. So the easiest way to do that is for them to buy into the image of the system. That doesn't have to even be the aesthetics of the system. It just needs to be the way it presents itself to them. So does it feel natural to them? Can they relate to it? Is there anything that grabs their attention straight away? Afterwards, I will say this, they will get used to whatever you put in front of them. But the point is, you may not even get to that point because you can't get buy in from key stakeholders. So yes, they will buy the image to start with, but they will fall in love with the detail, and that's how you've done the requirements or your KPIs, how much time you're saving them. That comes afterwards when it comes to buy in. So we say they will buy the image first and then fall in love with the detail afterwards. So again, this happens with, for instance, the example with Slack. I would take it that most people didn't know that they had that feature where you can go in and make your own messages, but you've already bought into Slack. Everybody who likes to speak to Slack, other than big corporate clients, love it, they've bought into it, regardless of its API features or its integrations. They've bought into the idea of Slack. So afterwards, you'll fall in love with the fact that you can go around and create messages for your users. You can create your own Slack bots, et cetera, et cetera. But they've got your buy-in. So going back to what's most important to our users, it did take me quite a while to come up with an analogy to show you that it gives you my opinion on the situation between experience and usability. And this is the best one that I can come up with. So the UK, and I couldn't get the stats for the US, so I'm sorry, the UK average daily commute time is an hour and seven minutes. That was of last year. So if I presented you with these two commutes, the usability one would take you an hour for your commute. So it's usable. It takes you an hour. It's most efficient. It's the easiest. Statistically, there are less accidents on the motorway, sorry, highway, freeway, than there are on any of the roads. It's simple, easy to use, very usable. Now if I said that I could give you a greater experience, let's take you through the mountains on your daily commute, but you have to sacrifice an extra hour of your time in the morning to have that nice experience. I will make the assumption that most people would say, no, I quite like my extra one hour in bed, thank you, or my coffee before I set off. I'd rather spend the time on the motorway. But what happens if I could tell you that I could find a balance in between? So how many people would sacrifice an extra 15 minutes in the morning to go on that nicer journey? Anybody? This is the same reaction that I got when I asked anybody, was that we make this choice every single day. Every single day, I choose to walk home the way that takes me 10 minutes longer because I want to avoid the road, I want to go through the park, but it takes me 10 minutes longer. In the morning, sorry, on the holiday, if I'm driving, I want to get to somewhere fast, but I will choose the more scening routes as long as it isn't twice as long, three times as long. So the point that I'm trying to make is that you can sacrifice usability to get a greater experience, but there is a point where users will not sacrifice as much. So you need to find the balance between sacrificing some ease of use for the experience, but there is a balance to make. Okay, so how can we implement this knowledge? I'm going to do. Can everybody see that? Okay. Fantastic. Okay, so this is the demo file. It's totally unlocked. If you can find anything wrong with the experience or usability, then I'm sorry. I put this together in about four hours, so it's hard to give somebody a nice user experience when there is no context, as I said before. So again, I'm sorry, I had to come with something that would try and get my point across. So the thing that I'd like to do on every single system is give them their own login screen. In terms of usability, FileMaker's login process is more than usable. I hardly have any questions about how to login to FileMaker once they find the file at all. But in terms of user experience, it's quite nice for a client for the first screen that they bounce on to be a bespoke personalised screen. So straight away, they feel at home. And the products that we use on a daily basis, they have these types of screens. Facebook, LinkedIn, Twitter, Instagram. You get presented with a nice login screen first. It's another dialogue that pops up and asks you for a username and password. There is some design gone into that screen. So if you want to log into the file, please use any username or password at all. So straight away, if I try to log in, now in the demo file, this presents to you a custom dialogue. And I went to a session that was all about language and after the session I changed the file because I thought there is no need to shove it in the user's face that they've missed the field. The turning red and the conditional format in the background should be enough to inform them that this is the reason why we haven't let you continue. So that's one thing that in the demo file does show you a custom dialogue. I didn't think it was necessary after reviewing it. So let's go ahead and type the password in. And just keep an eye on the logging button. So we just changed that to logging in. And again, I've forced some latency in that process as well. I'll make this assumption that in more systems you go away and load a user's preferences or do some sorts and set some variables. So I'll just do that again quickly. Let's do sign out. Again, that's the visual feedback that I was talking about in experience. You're just letting the user know that I'm doing something. I've registered your click. I'm dealing with it. So the way I did that was really simple. It's just a button bar with two segments. And when you hit login, it sets a global on one height and the other one just displays. You could do it in many ways. I suppose you could do the same with a calculation or a merge variable, et cetera. That was just the fastest way for me. And again, if you go through the sign in... Sorry, I should have cleared that out before. Just as you saw on the design before, we've got the name that has the asterisk to say that it's mandatory. We have the email address. Now, we can see the email straight away. He's telling you that there's an error. Now, what you can do is you can either let the user try and work out that you can click on the error message and it shows them that there is an error and explains to them how to deal with the error. That's not as obstructed to the user. It's not, again, throwing it in the face. Or the more usable solution would be to have the error appear probably underneath in some nice text as well just to show them that there's been an error. Again, that's just a pop-over that if the email address isn't registered as valid, then it just shows. Again, there's some custom functions in the file. Please feel free to take a look at anything. I would suggest if you've ever posted something online, they're probably your custom functions anyway. So, thank you. And again, let's hit all done. And again, I stole this from Facebook. If you try to register for Facebook, they do exactly the same thing. So again, there's an error. Now, you can even display that below. It's good for them to understand why it's important that you have their information and what it's going to be used for. There's nothing more frustrating than having to submit something that's mandatory without knowing why it is a mandatory field. So, let's go ahead and again, all done. Tell the user we're just creating your account. So, the next thing is that I know it's not always possible, but where possible I try to put images in with, especially like a CRM, if it is possible. I know it looks nice under design, and sometimes I see it and think it looks nice, but nobody ever manages to get pictures of all the clients on there as well. But anything that means that the user can recognise what you're looking at straight away, and we recognise faces faster than we do, we can read names. So, has anybody had a look at the file, the example file? Okay, handful. Okay. So, what happens is, again, when I'm... Let me just zoom out quickly. When I'm using systems online, and again, all my references are online systems, I don't look at things like Sage and other pieces of software. I always go online because that's where people are using software. Recently, there's been a change from list views to card views. That's where you can display contacts as a card. And as well, it depends how you want to do it, but the way I've done it, you can also make that expand and contract as well on the left-hand side. So, it will recalculate, and you could also do a search for a card as well. And you can get the nice hover-over effect when you go over them as well. I won't bother showing you things unless you don't want to be showing them. Does anybody want to know how that's done? Fantastic. Okay. So, I'm using something, and I spent... We've got a web department, a new file maker online library of UI elements. What I stumbled across was actually a web framework which is called Semantic UI. A Semantic UI has a whole library on the left-hand side of... Sorry, just to clarify, I'm using a web viewer there, but I will go through that in more detail. Just because of this cleaner, I know absolutely nothing about web or HTML or CSS other than how to get it to do what I wanted to do in FileMaker. So, if you've got any questions about CSS and how the HTML works, sorry, I'm not the guy that you need to speak to. So, there is something in Semantic UI under views which is called CARD. And so far, everything on Semantic UI I found will work in a web viewer with FileMaker. So, all these cards, all these views, everything will work inside FileMaker. And all I've done is at the top, I've downloaded the CSS. And inside the CSS, I've taken that CSS and I've commented out all the speech marks. And I've pasted it straight into a web viewer. Again, I would zoom in, but there's really no point. It goes on and on and on and on and on. The thing that's key, and you can have a look inside the file, is this section here. See that bit? So, halfway down, there is a div class that specifies that you're using the UI link card class. And above that, there is a body color. Now, when using web viewers, just in case you didn't know, you cannot make a web viewer translucent. So, you cannot make it take the color of your background by switching the color off. So, all I've done is added the body tag and put through the color of the background that I want it to be. And then all I've done in between is I've listed a field in the contacts table called html. So, the web viewer is based on an interface table that has got a relationship to the contacts table. Thus, I can use the list function. So, there we go. I'm viewing data from the interface file from the contacts. And I'm using only for search purposes, I'm using a SQL statement to make that relationship. So, let's have a look at that html. Again, this is all in the file you can take a look at. So, for each contact, there is a calculation field that calculates a string of html. The first one is an A tag, and I'll show you that allows you to click on the web viewer element, and it runs a script inside the local file that does something. Afterwards, I'm then base 64 encoding the photo so it appears. And then passing through the header, it's going to be the full name, the job title, and any information. So, again, that was all the way at the bottom. When I'm listing the html, that is just automatically generating a list of html for the web viewer to evaluate. So, let me hit OK. And when I go into browse mode, that evaluates. If anybody can work this out, you've got better skills than me. I can't work out how to take the blue line off the name. I have to let me know that a bit. Absolutely fantastic. But other than that, out of the box, it comes working. You get the hover. It automatically changes size when you scroll. So, the semantic UI has done all the work for you. Literally, it's almost plug-and-play with a few tweaks. And then I can click on a user, and I can then get to their profile. So, one thing in here, and there's been lots of talks about how to create a screen that's got the right ratios and the grids, et cetera. I'm not going to go into that. I'm just going to go in a few things. And the first thing is, what I like to do is, on every single portal, if there is no record presence, I like to give the portal a placeholder. And that's because users can be off put when they enter a screen and everything's blank. There's a blank portal. They don't know what to do. It feels uncomfortable. So, all I like to do is give the portal a placeholder. So, that is literally two icons stacked behind the portal, and the portal disappears if it's empty, and the icons show. Again, I like to point the user towards what they can do in this section as well. Again, that is an icon... Oh, sorry. That is an icon of a speechboard with text laid over the top that hides if the related data is empty. Now, what you can do is that if you really want to go for it, you can actually make... There you go. You can actually put a couple of icons in there so the user doesn't get bored. So, you can say, well, there's no task left. You must be on vacation. So, the other thing is, as well... Let me... Sorry. Matt did feature this slightly in his session. I don't know whether this will work. So, what I like to do is I like to take users into an edit state. So, every single time that they want to edit something, I take them into an edit state, and this allows them to make changes without affecting the data straight away. Now, somebody told me a lot better way of doing this, so this may seem convoluted, but it's the way I've been doing it for years. And that's when the user clicks edit, we load all the information up into globals. And then, at that point, we can freely change whatever they would like. And when they hit save, we push the global data back into the data fields. Or, if they hit cancel, we just flush the globals of any information at all. Now, there's some circumstances where this won't work. So, for instance, if somebody is constantly repeating adding more and more tasks, for instance, you wouldn't do this in a portal if they wanted to keep typing and carrying on because you have to take them into that state. But the things like creating contacts that are going to be done on an ad hoc basis, definitely take them into an edit view. What it also does in terms of usability, it takes the user's focus onto the information that you want them to be focused on. Is everybody aware how to get this scenario where you have a translucent background? Does anybody want to know how that's done? Fantastic, OK. So, this is a popover. And what happens with a popover is if you make the popover larger than the layout in terms of width and height and you anchor that popover all the way round, and then the next thing you have to do is you have to make sure, if I can catch it, OK, you have to make sure that the popover is in a position that it's impossible for it to be opened on that side of the screen. So, if the popover is bigger than the screen, you have to make sure that you set the setting that it's impossible for it to be opened on the left-hand side of the screen because it's larger than the margin on the left-hand side. Then all I've done is set the background of the whole popover to be translucent or transparent. And then somebody was ever so kind to tell me that if you set the outer shadow as well and you set the spread on the outer shadow, it makes sure that it fills up the whole screen. If you don't do that, you end up with a gap all the way round. I've never seen a user notice that gap ever before, but it looks a lot cleaner this way. And then I've just thrown in actual objects on screen in this view as well. So, again, you then get the result of a web dialogue. Now, the key with this, sorry, the good thing that I found with this as well is that it works in portals. Go ahead and create a task, set a priority. Task is for Tom. It's due today. Save. I want to take the user back into an edit mode. Well, I'll just hit edit. And that whole portal record has now taken over the whole screen. And, literally, all I've done is exactly the same technique. So I've set the popover in a portal on a hidden button segment. And no matter how many objects you've got in that portal, when you go to click into it and edit it, it takes over the whole screen. Okay. So the next one is there was... Yes? Sorry, would you mind coming up to the mic? Sorry. Use this technique, but we have a problem with the mode list. When we stretch the screen, the popover doesn't go all the way down when there's not enough records. In a list view? Yes. Okay, so in a list view, yes, that's a very good point. So you need to be aware of this in a list view. If you do this in a list view, you need to make your popover go as far down as it can be bothered waiting for file makers to keep sending it down the list. So if you make it vast amounts longer than the screen, when the user then expands the screen, it renders all the way to the bottom as well. So that is one caveat that comes with this process. If you do do it in list view, and I can show you in list view, which brings me onto something else, which... So if I hit delete all, which I don't know why you would have that button, but, again, we're in list view here, and then we can present a popover in list view to the user as well. So how can we do that? We can put some animation inside that popover, just to let the user know as well. And we can do that in terms of visual feedback. The best scenario that I've seen is tell you what, let's make a change, and let's hit save, and let's tell the user that we've saved their record. So what you can do is there is a custom function. Again, if you can improve on any of these functions, please do. But there's a custom function inside the file, and the leave is called select media. And there is a media table in the file. And all you need to do is load a gif into a container on the media table. And then using the custom function, and, again, you can see this, all you need to do is set a web viewer to the content the custom function calculates. And then the gif will just keep replaying, and keep playing, replaying, and keep replaying. Now, again, you can make a gif stop. I don't know how. So I might have to do some better research. But, again, using the web viewer, simple just, we're specifying that this is a gif, and it's encoding the data, and we're displaying it in a web viewer, and it will just keep playing as well. Again, this is the visual feedback. This is the visual feedback to the user that we're talking about. That's the little extra bit that goes towards the user. And then Matt did show an alternative to this as well, but if I zoom into the top right-hand corner, there is a search icon. Again, in terms of animation, all that is using is a slide control that makes the search field come out as well. It's just those bits of animation that, yes, may take you 10 minutes longer, and I'll let you guys make the decision whether or not it's worth it. But it just makes the user feel, I believe, more at home in the system. Okay, let me just make sure I've not missed anything. No, I don't think I have. Again, if I literally look at... I did some more demos of... If you take, for example, semantic UI, again, I've seen examples of people doing progress boards before. Semantic UI has a progress board section. All I've done is loaded the CSS into a field, and then what we can do is it took me about 10 minutes to probably do this in total. Using semantic UI, we can let a user set the status of a progress bar, good for like status of tasks or invoicing if you're doing working progress invoicing. And then the good thing about the semantic UI is if I go into layout and I actually think I want that progress bar to be small, I just go into the class which is the progress bar, and I just say I would like a small progress bar. And then semantic UI will change automatically to a small progress bar. Or again, just using English, let's say no, I want it even smaller. Let's say I want it tiny. Again, it changes it to tiny for you automatically. Now, what happens if I wanted to say let's go for large? No, too large. Let's just go for the standard. Okay. So what's also good about this as well is what happens if I want to give more visual feedback to a user. The semantic UI, and I'll show you again how you can do that. If I put active, so I want a active progress bar, however you can see that whether it renders correctly, but it puts a shimmer across the bar. Can you see that on there? And again, all this is doing is going on to semantic, semantic's website. If I can find it. Yep, on the right-hand side they have progress bars. And again, all these progress bars once you've downloaded the CSS and put it inside a field all you need to do is click on the button, copy the code, paste it into your web viewer in the right place, and it should all work perfectly. Okay. I've overrun by one minute, so I'll stop there. Has anybody got any questions at all? Please feel free to come up and ask them. Please try and use the microphones. There is Ercom right above me, so I can't really hear. Thank you. Yes. One, thank you very much. All of us in here are file maker developers, but in a lot of cases there's design elements that a designer works with. How important do you think it is? I mean, we have a lot in file maker, but how important do you think it is like the logos and to use really dynamic designs that we have to actually we ourselves as file maker programmers can't use, we have to go to somebody else to get it set up? So, just make sure I've got the question correctly. Are you saying that if there isn't a capability in file maker, do you think it's, are you asking me if it's worth going to somebody else to try and create that? Artistic elements that you might use. So, you know, we have buttons and everything, they've defined nice things like that. So, the question is, do we go to a designer to make, you know, visual things that are outside of what we have in the palette, or do you feel that we pretty much have what we need in file maker, don't go crazy with artistic... So, Loretia, the only things that I don't that I don't use native file maker functions for, and I will do anything to keep everything native, is the stuff that you see in web viewers. So, things where it is card views or you can make, you can actually make a web view scroll across many images horizontally. When it comes to making animations or different styles of buttons and things, I'm a cheapscape. So, anything that's free that I can find online I'm quite happy to use. So, my personal opinion is, just use what's available. I don't really go seeking for too much. So, again, I'll be around after so anybody who wants to come and column me and ask any questions, please feel free to. Thank you again everybody for attending. It's been a pleasure.