Episode 428: Matt Lacey on Mobile App Usability

Filed in Episodes by on September 30, 2020 0 Comments

Matt Lacey, author of the Usability Matters book discusses what mobile app usability is and why it can make or break an app destined for consumers, business users or in-house users. Host Gavin Henry spoke with Lacey about the “Six components of great App experiences”, “Things every app should do”,  native apps, password managers, accessibility, feedback, telemetry, locations, non-mobile, example good and bad apps, whether the app is actually needed, testing, connectivity, automation of testing, gettings users involved at the start of development as well as what the most important thing to do as a software engineer is in relation to mobile apps.

Related Links

SE Radio theme music: “Broken Reality” by Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0

 View Transcript

Transcript brought to you by IEEE Software

Gavin Henry 00:00:22 Welcome to software engineering radio. I’m your host, Gavin Henry. And today my guest is Matt Lacey. Matt Lacey is an independent development consultant and focuses on helping developers to create better. Software is the author of usability matters. Mobile first UX for developers and other accidental designers by Manning a Microsoft MVP and contributor to multiple open source projects. Matt, welcome to software engineering radio.

Matt Lacey 00:00:50 Hello, thanks for having me.

Gavin Henry 00:01:00 Is there anything I missed in your bio that you’d like to add?

Matt Lacey 00:01:10 No, that definitely sounds like me.

Gavin Henry 00:01:17 Perfect. During the show where we’ll be talking about what makes a mobile app usable your six components of great app experiences from your fantastic book and an example of a great app and one that needs improvement. However, I’d like to start with an overview of what usability is so about. What is usability? Usability is an area, very word. Which means is it easy to use? Is it simple or not? Not just as it’s simple, but does it do everything the person using the app needs it too. And can they use it and can they use it without trouble? It’s they’re saying it’s a word I should be able to better define. I’m sorry, but that’s part of the magic of it is it’s it’s, um, it’s a loose definition. It’s usability, what they expect it to be or what we expect them to think it should be. Oh, it’s absolutely all about the person using the app. It’s not the customers, right? It’s the user is right. Okay. And that app in general, usability terms as a desktop app or any type of software application. So yeah, so I tried to think of, for the most part, all software is basically the same. You know, the rules for software in one place apply in most places.

Matt Lacey 00:02:12 You know, there are, there are lots of exceptions, but as a general rule, I think, you know, the rules which make software good on one platform or one device or one environment also apply elsewhere. Okay. Regards to usability. What is mobile usability? So mobile is birth is just usability applied to mobile scenario. I would like to think of mobile as being about people, not about devices is the person that moves around. They just happened to have a phone with them, but you know, a person might move from different devices between devices. They might move from using their phone at one point to a PC at another, or to a tablet another time. And it’s that experience, which is mobile. It’s the person that’s mobile. They move around, they use software in different environments and scenarios and on different devices. So we’re not talking about a mobile, we’re just talking

Gavin Henry 00:03:00 About a user being mobile.

Matt Lacey 00:03:03 So we’re not just talking about mobile phones or tablets or whatever else you define as mobile device, a device. Yes. The experience is what matters. And that often, especially now, and more and more is transcending across an individual device. If you think about mobile is just being about phones. You miss out on lots of opportunities and that’s not realistic. So the way people use software nowadays in a lot of cases,

Gavin Henry 00:03:31 Why is usability important to anyone, the person, the company, the charity, the app developer.

Matt Lacey 00:03:40 So usability is important because, well, for many reasons, if you’re building a consumer app, it’s important because your customers have lots of alternatives. And if they don’t, they’d likely soon we’ll have, if you, if there’s any sort of money in the business, you’re in, if it’s a line of business apps that you’re using internally, the usability and the overall experience of using the app will have a great impact on how productive somebody can be in how they feel about their work. Um, if, if someone’s constantly getting frustrated with the software, you’re providing them for them to do their job. They’re probably not going to keep doing the best job for the longest amount of time.

Gavin Henry 00:04:15 And there’s quite a noticeable difference between an app that’s internal. Would you say to use by teams or staff versus one that is going to be listed on the public app store? Because there are private app store.

Matt Lacey 00:04:31 Yeah, so traditionally, yes, I’m a lot more attention is paid to consumer facing apps than to internal apps as a way of defining the two or the two scenarios. But more and more businesses are starting to appreciate the value in a good experience for their own internal software, because it affects productivity. It affects morale. It affects the ability to work remotely, things like that. You know, it’s something which we’re all dealing with at the moment. So those, the needs to think about usability for internal apps is becoming more important. Especially if you think that, well, we’ve got 300 users and we have to give them a day’s training at the moment. So that’s 300 days worth of training costs. Well, what if we could make the app simpler? So we didn’t need to give training. We could save a load of money on training. If we make it a bit more productive, a bit happier, they might work faster. Well, that’s great for the bottom line as well.

Gavin Henry 00:05:22 Yeah. So it sounds like it’s actually more important to sort of nurture usability on internal ops because your staff can’t just leave a bad review and use something else like a consumer may, because they’ve got more choice.

Matt Lacey 00:05:37 I think it’s important everywhere. I don’t think it’s more important in one than the other. Yes. Your staff can’t leave bad reviews in the app store, but I’d hope that they have some way of feeding back in other ways, although that’s does not formal in many, many organizations, but it should be, there should always be a way to feedback further.

Gavin Henry 00:05:59 Yeah. I think we’re going to touch on that. And I’m at the section about all the things I have the option to do some really great tips in there. So if you could just clarify for me, is usability just another word for experience or the different or hand in hand, you know, it’s usability the same as an experience as what I’m trying to articulate.

Matt Lacey 00:06:21 So in, in the, they’re both very vague words. Yes. So we can think about the experience in terms of, or what is it like to use the app? And that’s kind of what I mean by usability. What is it like to use it? How do I feel when I use it? Or how does the person using it feel and how productive are they, can they do what they want? Can they achieve their goals?

Gavin Henry 00:06:46 So could you have perfectly usable, which has a terrible experience.

Matt Lacey 00:06:51 Yeah. Yeah. An app can be perfectly functional, but can be horrible to use. Absolutely.

Gavin Henry 00:06:57 Is, is functionality the same as usual?

Matt Lacey 00:07:01 No. Is it, is it usable? I mean, can you use it to achieve the goal you started to use it for is very different from what’s it like using this app to achieve the goal you started using the for?

Gavin Henry 00:07:14 Yeah. So an example of that could be a very, very simple one. You’re not polluting the pet jar, the app in question, the one with good usability, you click the camera button in the app, it takes a picture and off it goes, whereas a bad one could be a file upload button. And you’ve got to take the picture first, go and find it and then upload it. They have the same function, but the completely opposite.

Matt Lacey 00:07:40 Yeah. They both allow you to achieve the goal of getting a picture through a remote server somewhere or remote location, but how you feel doing it, how long it takes, how you feel afterwards, how will you feel about the company in response to that? They can be very different. Yeah.

Gavin Henry 00:07:53 And that is more into their experience of that.

Matt Lacey 00:07:58 Yeah. So when I say usability, I mean, what is the experience of using the app? Like,

Gavin Henry 00:08:02 Okay, cool. Let’s put a line under that. I think that’s cleared up. So this next question is a bit further down the technical scale, does it mater I want to get this out there at the beginning. It doesn’t matter at all, whether or not users is a native app, it’s brand using the Apple tools for iOS or it’s written with the Android Java or Kotlin programming language, or if it uses a framework that then spits out an Android or iOS app or any other type of app, does that matter at all?

Matt Lacey 00:08:38 Only in a very, very, very small number of cases. The technology used to build an experience, shouldn’t have an impact on that experience. Do you can go to extremes, you know, if I wanted to do something really simple and that meant bundling a whole load of web frameworks technologies inside the browser, buried inside the native app, that might have an impact, but there’s nothing to say that, you know, you must go to native app to get a good experience. Or if you use such and such a framework, you’re not going to get a good experience.

Gavin Henry 00:09:07 The bottom of what you’re trying to do the top is, you know what, so I’ve used user experience, function that we have. And then that leads you down the path of whether it’s native or a framework, you know, with all the other elements you’ve got to think about.

Matt Lacey 00:09:21 Yeah. And then in many cases they use the shouldn’t be able to tell or shouldn’t need to know. So it, it becomes irrelevant for the person using the app, the technologies you use apply to other people who are making it yeah. Or relevant to the people who are making.

Gavin Henry 00:09:36 Yeah. I mean, cause I’m quite tyrannical. I look at what different people use and I’ve seen some apps where it’s a web browser app that has an icon, but it’s really simple. It’s like to use. And that’s obviously the correct choice for the app, you know? And then you might think, well, it should have been done native or something like that. You know what I mean? I’m just trying to expand upon the function it’s trying to do and which path they go down.

Matt Lacey 00:10:04 Yeah. I mean, if it, if it’s possible to put the functionality in a webpage, which just exists in a browser, then that’s perfectly fine to do that. If you can do something more, improve the experience or add additional functionality by building a, any kind of native app or install bubble app, then obviously that can be a benefit too. But if you can do it without, then you can do it without, there’s no point spending time, money, and effort, if you don’t need to.

Gavin Henry 00:10:30 Yeah. It just depends on what else you’re tapping into in that device as well. Doesn’t it that improves the usability and experience.

Matt Lacey 00:10:37 Yeah. There might be functionality, which you can’t do in a browser in which case yes. You need to build an app or something. So whether that’s a totally native app, whether that’s using some framework which exists in a embedded web browser, then that’s fine as well.

Gavin Henry 00:10:50 Excellent. I’d like to move us on now. I think we covered everything I wanted to introduce there. You’ve sort of created kind of what I would call a framework. If you agree. Um, the six components in your book, you call the six components of great app experiences. Would you call that a framework or a set of guidelines or how does that fit in your head?

Matt Lacey 00:11:11 In, in my head, it’s a shortcut for a way of thinking about software, which depending on how you define framework might be a framework. It’s just a useful tool that I’ve developed to be able to think about things beyond the code, which you know, which are very important, easy to overlook.
Gavin Henry 00:11:28 So now that we’ve covered what usability is, can you take me through what you’ve defined as the six components of great app experiences?

Matt Lacey 00:11:36 Okay. So six components, they are context, input, output, responsiveness, connectivity, and resources. Um, and I will go through those just to think about them, um, in a, in a bit more detail, just to explain what that means. So context is about understanding where the apps used, who it’s used by, or who will be used by what do they want to do with it? How do they use it? What devices? So they use it on, you know, where in the world are they, what languages do they speak? All those sorts of questions. It’s questions about the wider context of the app. So you have a frame of reference. It’s all very well going. Well, I’m going to build this app, but if you know the people who might use it, don’t use the device. You’ve built it for them. That’s irrelevant if you build an app, which only has a very small voice, we do everything in English, but most of the people do not use it. Don’t speak English. Well, that’s no good either. So there’s lots of questions about the wider context of the app beyond the technical, can we do this, which need to be considered. And that kind of underpins everything. If you don’t know that, then you’re kind of starting off with one hand tied behind your back. I think it makes things much harder.

Gavin Henry 00:12:43 The context is the why of the app.

Matt Lacey 00:12:46 So it’s, it’s, it’s not just the Y it’s. Yeah. So what, why is a very important question? It’s one of my favorite questions. So why are we building this app? Who is it for? What are they going to do with it? How do they going to use it? What do we want them to do with it? How do we want them to use it? How do they want to use it? How does it compare to the other apps they use? It’s all the questions about the app will be, which aren’t the, how does it actually work at client? Okay. Um, okay. So input input is how does data or information get into the app? And that’s both from the person using it. And from other sources, it’s really easy to think about, Oh, input. I just need to put the things on the screen. Someone’s going to type on the keyboard or the mouse, or, you know, poke it with a finger.

Matt Lacey 00:13:28 And that’s impossible. I need to care about within that. There’s a lot more to think about. And there is also more, more than just that to think about as well. You know, we can put text box or text boxes on screen and have people type things into them, but there’s lots of things we can do to improve that experience. Or maybe make it redundant, ask if it’s really needed. But then there’s other data that comes into your app. All the information that could be coming from sensors on a device, it could become from a remote source. It’s easy to sort of overlook that and think about, yeah, that’d be fine. I’d just make a web requesting the data. But this is, this is input in the same way that whatever gets typed in through the keyboard is input. And you need to think about those things as well.

Gavin Henry 00:14:07 And this ties you back really to context. So the context, where are they when they’re doing this? So that would then filter what sort of inputs would be of use of that point and the context they’re in.

Matt Lacey 00:14:21 Yeah. And if we might say, well, we need to know the location. We could just get the location off the device. Well, are people using devices which allow us to get the location or have they enabled that? What if they’ve not enabled that, thinking about those sorts of things?

Gavin Henry 00:14:35 Yes. A very, very interlinked.

Matt Lacey 00:14:38 Yeah. And it’s obviously connected to input or the opposite of input is output. And it’s really easy to think that output or that just what I put on the screen. And yes, it is what you put on the screen. It’s more than that it’s know, worst case will be, make a visual impact with what we put on the screen. What if we need to make some other impacts? So can we use sound? How should we use sound? Do we need to use some other kinds of outputs, some physical outputs? Do we output to things beyond just the screen in the app? So we send emails where would being to think about those emails? Where are those emails going to be received? Are they going to be received on the same device? That’s the apps being used on? Um, I’ve seen loads of apps where, you know, you sign up through the app, they send you an email and you can’t actually view the app. Well, they can’t view the email easily with the email client on the app, on the device on sorry, on the same device.

Gavin Henry 00:15:27 I’ve seen flows like that, where you sent an email with a QR code to log into the app, but you can’t take a picture of you and email client unless they’ve built the QR code. So it can feed into an image from the device.

Matt Lacey 00:15:42 Yeah. I know. You’ve, you’ve immediately assumed that the person using the device, you probably assumed that they’re sitting in front of their computer, which goes back to context. Yeah. Because as a developer, you were sat on the computer or writing the app, you know, in your editor of choice, you had your phone next to you. And that was really easy to do.

Gavin Henry 00:16:03 I’m totally guilty of this. One of the apps we’ve done is exactly like that. You take a picture of a QR code, but you’ve got to be in front of your desktop, but there are other ways, you know, you can take a screenshot of the acute, it’s a broken flow anyway, it’s the short story. So yeah, that comes back to context as well. Doesn’t it?

Matt Lacey 00:16:24 Yeah. It’s a context, underpins everything and it’s the output. So it’s the we’ve taken data in, or we’ve taken information in, we’ve responded in some way though with our output. And then the fourth point is, or the fourth component is responsiveness. So how do we respond? You know, or how is our response perceived? You know, when I clicked on that button, was it a quick response to whatever I did, did it, did it immediately start doing something? Did it sort of sit and spin and think for a bit? And I kind of wondered if it was all okay. And then I pressed the button again and that had a negative effect and now I’ve pressed it twice and everything’s falling apart. Is it really slow? And how, how do I feel based on the speed of those experiences, if data takes ages to download well, that’s going to make me feel bad if you’re downloading loads of data and it takes ages and it uses that Bluetooth and that’s expensive to me based on where I am and how I’m connecting, then that’s a problem as well. You know, are you thinking about as a developer, how the experience is perceived when someone’s using the app, how responsive is the app? Does it move quickly? Does it slow to navigate between pages or, you know, views in an app, which can feel really slow

Gavin Henry 00:17:37 Going back a step to the more general term software engineering for the whole podcast series is about the developer. That is that step four. So we’ve discussed context, one of the most important bits input, how do we get data in output? How we present that to the, to the user, whether it’s a business consumer inhouse, user and responsiveness, as you’ve explained, is it’s not penis of the art or is that is responsiveness, how quickly things happen or just the user experience of the app. How’s in pushing a button.

Matt Lacey 00:18:17 It’s about making sure things happen fast enough for the person who’s using it. So again, it comes back to context. It’s about what the experience of the person using it is,

Gavin Henry 00:18:28 And is the developer when they get to stage four or any of the steps, in fact, are they privy to the context upfront? Is this part of the software engineering life cycle, where they need to be completely involved with the user or the company they’re doing it for. So they’re always know at what step and where the people using the app are going to be and what they’re going to be expecting. So

Matt Lacey 00:18:54 When I’m building software, I always like to know these things because it’s really important to me to understand who’s going to be using it. So I can be sure that I’m building something that’s appropriate for those people. Things like perception of very subjective. So it’s hard to say, you know, well, this is why I’m for me. Therefore, it’d be fine for everybody. But one of the things we can do is measure and test and ask for feedback on those things. You know, so I always like to get into user user based testing. So real people, whether you call that UAT or beta testing, or, or you have an alpha testing, having real people use the app and as soon as possible, so you can start getting feedback. So they will tell you if it is too slow. And then once, you know, what too slow feels like for the people who are using it, you can measure that and then monitor to make sure that, you know, as the app develops and over time that those, um, those thresholds, that perception is always maintained. That it’s fast enough.

Gavin Henry 00:19:52 At what point would you get that user or the potential users involved, as soon as you’ve got something to show them, and then just iterate, like put the software engineering methodology apart a site, how much do you need to do before it goes on a public stage of a public page, if an app store, or does it matter? Cause you’re constantly working with your users to make sure it’s always a good experience, whether it’s B to alpha or proper life, you know, cause as soon as, as you know, as soon as software is born, you’re looking after it for forever. You know, you don’t, you know, just done. So would you say just as soon as possible that you’ve got something for them to task,

Matt Lacey 00:20:32 I always try and get software in front of real users as soon as possible. The first day of coding on any project for me is set up that deployment pipeline, which will go from, I can check in code and then it will spit out somewhere, some beta test apps, which gets sent where people get notified about saying, Hey, there is a version of this app. You can upgrade, you can do it. And that first version, which I push out, we’ll have a version number in it. And I feedback button and maybe, you know, if, and that’s, it that’s enough for me. What I might do is I might include like a mock up of the sign in screen. So then they go on. So the first feedback which I hope to get is that all the sign in screen doesn’t work. That’s brilliant because that means, I know they’re using it, they’ve tried it. And all the feedback mechanisms work.

Gavin Henry 00:21:16 That’s what I was going to ask next is through every flow of that user, using the app, sign up registration, getting them involved in every step of that. So as soon as there’s a login page, that’s when you start speaking to people or do you just want them to click login? And I suppose that comes back to the context, doesn’t it? You might not even need a login.

Matt Lacey 00:21:35 Yeah. Yeah. Um, the feedback you need will vary depending on the particular application. But yeah, I like to make sure that people can provide feedback and that the software is being used by people who are actually going to be using it in the real world as much as possible, as soon as possible. You know, especially in those early stages, there, isn’t such a thing as too much feedback because the more information you have, the better app you can produce. So that’s especially true before you get to the app store. But knowing once you go public, then there’s going to be a whole load of new feedback. I mean, but there will be things you couldn’t have possibly imagined, um, beyond what your, you know, where we search broadly distributed group of testers, do the real world can always find new things for you.

Gavin Henry 00:22:19 Yeah. It’s quite amazing when you get into this, just how much work it all is, which has completely belittled by a three letter word called app. You know, it’s just so much research and development goes into all this. Okay. So we’ve covered briefly context, input, output, and responsiveness. Number five is

Matt Lacey 00:22:40 It’s connectivity. So it’s really easy to think that we always have a high speed internet connection, but that’s not the case for everybody. That’s not the case all the time. Occasionally connected is the norm. You know, you cannot assume that there will always be a connection. It would always remain up. It will always be fast. It would always be cheap. And the request you start will result in a response. You have to think about connectivity. Can you do without it? What do you do when it goes down? How can you work around it not being there? What can you do to mitigate some of those possible issues? And what do you do if it keeps dropping and coming back and how, how do you live with those scenarios? You know, it might be that your app can’t possibly work unless you have an internet connection.

Matt Lacey 00:23:25 And if that’s, you know, for some technical reasons, that’s the case, then that’s fine. And then you have to make sure you handle those cases where that, that connection is not available or not possible, or doesn’t respond. Um, you have to make sure you handle those appropriately, but in most cases you can get some value, even when there isn’t active internet connection. And so it’s event, it’s, it becomes a case of making sure that you optimize those experiences to make sure that the user can do as much as possible. And then you recover as best as you can. When you have a connection again,

Gavin Henry 00:23:58 Flow in regards to connectivity might be laying you prepare something when you’re offline, that could then be uploaded or sand or saved, um, saved locally. But once you’ve got some type of suitable connection, it would then do what

Matt Lacey 00:24:16 What to do. Yeah. It might be the, you know, you compose some message which you want to send to whatever system you’re sending messages to. Um, it might be that that then sits in an outbox until you have a connection, but it might, it might automatically get retried. You might have to manually retry it. You might allow the user to send it again later. There’s lots of possible things there. And then Whoa, you might queue up lots and lots of these messages. And then how would you send them all? Once you got connected with your bank, do you send them one at a time? Can you batch them to make that possibly make that easier depending on how your systems are written? You know, batching them would be good for, you know, for the, from a connectivity point of view, but it might make, um, how you handle them on the back end harder. And then you have to think about, well, does the order of these messages matter? And depending on the application that can vary as well. Again, it comes back to context, context, underpins everything. So you have to know the app and you have to know more than, Oh, I need to write this code and use this API.

Gavin Henry 00:25:13 I would think that goes back to ALPA as well, because you obviously need to show the user or explain to the user of what’s happened and that the opposite dealing with it on the QS, reducing that type of thing.

Matt Lacey 00:25:26 Yeah. So one of the things that I think makes for a good experience using an app is to always make sure that the user knows what’s going on, don’t leave them guessing or have them asking questions. So if they’re thinking well, did it send I’m offline? What’s happened? What does that mean? As soon as they’re asking questions that that limits and impacts their experience, the best apps you don’t think about using them. So if you go, well, okay, I press the end. And he said, Oh, we’ll send when connectivity returns. Okay, brilliant. I don’t have to think about that. That’s all taken care of by the app. If it just disappears and I don’t know what’s happened well, then, then I don’t know what to think. And do I try sending it again? Does that mean I have to type it or do the process again or whatever is happening? There’s a lot of uncertainty and uncertainty is bad.

Gavin Henry 00:26:11 Yeah. You want to build trust don’t you, when the opposite is going to do something, it does it. And you can just forget about it. Move on. Yep. Connectivity. Would you break that down further? So rather than just checking whether you’ve got a connection or not, would you look to check whether that’s a mobile connection? So three G two G for text messages for G or wifi, does that impact your whole thought process?

Matt Lacey 00:26:36 It depends again on the context of the app. So when I worked on streaming video, that was really important because we, we wanted to make sure we weren’t going to eat up people’s data costs, um, Treme video, when we’re using the expensive thing, they’ve expensive connection rather than the wifi, which is probably cheaper. So we have to think about those. If I’m just sending small packets of data, then it’s probably not an issue.

Gavin Henry 00:27:01 Yeah. Normal I’ll keep using the word flow, just cause that’s what I find. So you did it at the moment, but give them a podcast I’ve played with quite a few different podcasts apps, free ones and paid ones. And then normally prompt when you’re on a mobile connection to say, do you want us to just wait until you’ve got wifi? Because the podcast episodes are quite big. So yeah, I understand what you mean there. So that takes us on to step six or section six, which you call resources,

Matt Lacey 00:27:31 Resources. So that’s, it’s, it’s thinking about what you’re using. Now. The biggest resource you need to consider on a mobile device is power is what I’m doing, going to drain the battery. Cause once the battery is drained, no one can use anything. So then, you know, no one’s going to use your app. And if, if a person can appreciate that, your app is the cause of their battery running down really quickly, they’re going to stop using it. Are they going to complain? And you’ll have your one star reviews and you will have lost customers and they will be off using something else. As back to battery. Technology has developed over the last few years, it’s becoming less of an issue, but I, I installed a new app the other day. It was, you know, it was a simple pseudo-code gay map, but I could quickly tell that this thing was draining the battery faster than when I’m watching streaming video. And I have absolutely no idea why or how they’re doing that. I could probably guess what they’re doing to compete constantly redo all the UI, even though, even though it’s just lines and numbers, which doesn’t need to be constantly redrawn the refresh rates probably. Yeah. So it, there, it might be a case that the technology is caused them to do something or intentionally or accidentally that is, um, is having a negative impact on resources. But it’s, you know, it’s still something to think about,

Gavin Henry 00:28:50 But that could come back to your context, um, section where they’ve just tested it on a simulator or their phone constantly plugged into their desktop. So it’s always got a battery.

Matt Lacey 00:29:02 Yeah, that’s perfectly. Cause it might even be the effects, whatever, make the whatever make of device I’m caught in a way that it doesn’t affect other devices. It might be tied to the framework they’ve used to build the game. Um, it could be totals of things, but batteries, batteries the big one, but there are other resources that can be used as well. And the next biggest one is displaced. You know, mobile phones, more than anything are highly constrained in terms of the space you can get, you know, if you’ve ever had all those warnings about should be archive some of your pictures because it will free up 30 gigs of space on your phone and you like work probably, um, you know, that space can be limited and it’s, it’s hard to understand how much space is available and the consequences of that on the app from a, from a, from a user perspective, you know, what does it mean that I’ve got hundreds and hundreds of thousands of images? What does that mean? I don’t know, but if that’s gonna have an effect on an app which needs to download and store lots of information, which is going to caseloads and loads of files, the variability of this space might be something you need to consider.

Gavin Henry 00:30:02 I know the two things that you’ve touched on and resources, the space and battery, are they things that you can use telemetry data for to monitor and understand that your ops using a lot of the battery or understand that you’ve got X, mag or X gigabytes of storage. So you can do something about it or is this something that with premium phones or modern operating systems they’ll limit hops. I use the battery a lot anyway, but then if you don’t know about that, you can’t improve on it until you get bad review or you’re having constant feedback.

Matt Lacey 00:30:38 Yeah. So measuring power consumption or how, how quickly you drain the battery can be hard. It’s harder to test for than other things. I remember back at the times when we had teams of testers who did take phones apart and put sensors on batteries and calculate voltage changes and technical electronic stuff, I don’t understand, but they were monitoring how things go down. And there are, there is limited tooling, which, you know, means you don’t have to do that as much now. And you know, you can rely on the, the operating systems to take care of some of that for you. Um, and you know, there, there are settings reports. We say, well, this batch, this app use this much of the bandwidth and this much of the power and this much of the screen time, but you can’t rely on the operating system to take care of it for you.

Matt Lacey 00:31:22 The operating system is going to do, what’s basically the operating system you need to do what’s best for your app and your users. Oh, sorry. I was just going to come back to this space and this space is, it’s not something you need the telemetry for, but you can check, you know, well, how much this phrase is there before it’s try and save all these images locally or save all this data or make a copy of the database, which is going to take up loads and loads of space. It’s about being aware of those resources you’re using and being sensitive to the needs of the device, as well as the needs of your friends.

Gavin Henry 00:31:53 Yeah. So making no assumptions, really always checking that you’ve got this space designing the longer running jobs to be able to fail or, you know, know where they are. If the battery dies, for example, what would you put a screen real estate into the resources pod?

Matt Lacey 00:32:10 I tend to think about the screen real state in terms of output, you know, what can we do display in terms of spaces, resources. I might think about sensors more, where can I get this data from? You know, how has the device got a camera, probably how many cameras do I need to think about how I use them? Am I going to use the location sensor? Do I request that depending on the operating system on, and again, this is something which has become easier to do now. And certainly in the operating system does a better job of taking care of for you, but saying, you know, I want to get the location so I can know where my user is. You know, you might dig down and say, well, I’m going to take control of that radio and constantly be checking to find out where I am and if I move, or you could just say, Hey, operating system, do you know the location? Give me your best bet best guess. And I’ll take that.

Gavin Henry 00:32:54 And that comes back to input. You know, what data you need. It’s a form of input and context as well would be, how accurate does that location need to be? You know, do I just need a big circle on a town or do I need it down to, you know?

Matt Lacey 00:33:12 Yeah, absolutely. Everything, everything ties together. Um, and everything comes back to context. Yeah.

Gavin Henry 00:33:17 Okay. You touched upon your experience with the video, um, that you did. Could you take us through the six steps in relation to the app if you’re allowed to?

Matt Lacey 00:33:27 Oh, I’m just realizing I haven’t, you know, I don’t know if I’ve ever sat down and done that for the app.

Gavin Henry 00:33:33 Oh, excellent. I’m looking forward to it. So context, I ask a questions. What is the context of your video app?

Matt Lacey 00:33:40 So this was UK based for, uh, let’s, let’s say TV station as a way of providing live and on demand content.

Gavin Henry 00:33:51 So UK English, us English multi-lingual.

Matt Lacey 00:33:55 So UK, English, no localization as many devices as we can possibly get on the user could, you know, could conceivably be anyone who watches, I mean, mainstream television show, you’re consuming video, not creating, not creating, you know, yet. So this is watching broadcast content

Gavin Henry 00:34:12 And the input for that would be just a guest searching for that video content.

Matt Lacey 00:34:18 So in terms of input, we needed to consider, there was a registration process, registration processes. I want to lose things which can almost always be improved regardless of who’s done it. So there’s, there’s things to consider there. But then the primary input was, you know, how do we navigate the app? How do we select which content you want to watch? And then manipulating the content while it’s playing, just in terms of skipping and pausing, playing resuming, that kind of thing.

Gavin Henry 00:34:40 Yeah. And that comes back to con tax, cause it might, uh, a box standard video play might not be suitable, comes back to what inputs available.

Matt Lacey 00:34:49 Yeah, no, in that, in that case, a book sender media player control was not suitable. And we had to do lots of fun, low level things.
Gavin Henry 00:34:58 An output is the video aren’t per se, watching it with your eyeballs or listening to it.

Matt Lacey 00:35:04 But primarily, yeah, the watching the content and listening to it, it was not a lot of hours to consider in terms of registration. There was some, there were confirmation emails, there was a website where you could also access these things and, you know, access the content. And

Gavin Henry 00:35:20 So the context there might be dependent on who’s logged in their age band, whether they’re a kid or an adult.
Matt Lacey 00:35:28 Yeah. So there’s, there was age restriction, considerations, or, you know, prompt for age consent on content.

Matt Lacey 00:36:14 And um, how do you approach accessibility for inputs? If you’re asking for a search thing, do you tap into voice input for that? Or do you have to consider our subtitles for the outputs? What was your thought process with access with barely, maybe legal requirements for this app, depending on what sector, et cetera. So the worst subtitles for, I think all the content, but beyond that, we just relied on the accessibility functionality built into the device and the operating system. It’s something. Now we could focus on more, which is usually pretty comprehensive, isn’t it? Yeah. Having recently found some interesting looking tools for automated accessibility checking, I’ve been reviewing how I do that in the future. I start something I can put in the show notes for last night. Yeah. So, um, it’s a Microsoft project, accessibility insights IO, I think. And they have web windows and Android automated testing for accessibility.

Matt Lacey 00:37:15 It’s obviously it’s not perfect cause it can’t be, it can’t automatically tell what’s going to be suitable for all accessibility scenarios, but it’s a great way of catching some of the, some of the easier things to, to get right. Or which, you know, excellent. And the notes not get wrong. The things that are easy to get wrong is probably better. Yeah. The low hanging fruit. Yeah. So output we’ve covered is sound facial subtitles for a video app responsiveness. Yeah. So respond responsiveness was fun. As you know, we want as a user, I press play. I want the content to play as quickly as possible, which we can do technically as much as possible. But interestingly, in this, uh, we found an issue in one of the, in some of the code, which was written to understand, interpret the Kodak, such that every two minutes you’d get a slight skip, which is real easy to miss when you’re testing. But if you’re intently watching a TV program or a film and every two minutes, it skips a little bit, then that becomes a big problem, which is why I said, you know, in terms of the, the media controls we were using, we were hoping to do some low level rewriting and work around stuff to deal with somebody who’s problems. But desktop Sharon web RTC I’ll take out the notes, but they spoke

Gavin Henry 00:38:36 About having to rewrite low level sections as well because they’re testing it, didn’t meet what it’s supposed to. Um, but yeah, again, going back to context. Now, if it’s a video app for use videos that are generally less than two minutes, anyway, you might not have noticed it.

Matt Lacey 00:38:53 Yeah. That is perfectly possible. And I think that the, we spoke to the developers who originally wrote the code, which was taking the, whatever the format the streams were. I don’t remember the specific format at the time. And they wrote their code, which made that all work. And they never watched the content very closely. So that’s how they missed it. And just in terms of how things were buffering and how frames were grabbed and where, um, where there were pauses and breaks in the code that they’d never really paid that much attention, um, which is fine until someone’s watching football and, you know, part way through the big match. And it’s suddenly jolts and, you know, you missed the goal and that, well that’s, that’s the end of the world for some people.

Gavin Henry 00:39:32 No, I guess you bought to your point of getting users involved as soon as possible.

Matt Lacey 00:39:36 Yeah. Yeah. Video apps are fun, you know, in that you get heard an excuse to watch loads of hell.

Gavin Henry 00:39:43 So responsiveness in the context of this app is how quickly the video displays and is isn’t smooth,

Matt Lacey 00:39:50 Smooth is the, you know, it’s navigating the app simple and easy and fast. Um, if I want to watch my live program and it’s just starting, you know, you have to fumble to get the app, my phone out my pocket. And then I have to faffing go through blue two steps in the app to get the bit, you know, to get to where I want. And that’s no good. Um, you know, we need people to be able to get to what they want as quickly as possible.

Gavin Henry 00:40:12 Yeah. There’s some tough competition now with streaming apps that you soon find your favorites with how you can get back to the selection of movies or TV episodes, which ones allow you to do other stuff when they play stuff in the background. Um, I will not mention any names, but some new kids on the block aren’t as good as some of the older kids on the block. They’re responsiveness is really apparent of how quickly they deliver that first frame. You know, give me as a user, a great experience. Okay. So connectivity step five. So we’ve done context, input, output responsiveness for your video connectivity. It’s probably going to be one of the most important ones is that

Matt Lacey 00:40:53 That’s important. So as, as we mentioned earlier, there were certain areas where we need to consider, you know, is this an immediate connection? Are people going to be paying a lot for this? And if so, we need to warn them or give them the option to, to, to not, to not watch right now or, and then worth, they’re not watching right now, how do we make sure we get them back like that? Do we then set up a reminder? Do we monitor the changes in the connections? We can do things like that, let them override it, you know, if they really need it, if they really want to, or really need to, they can. But then also we provided options or there was an option for, for some of the content to be downloaded. Um, which, you know, once has been downloaded the connectivity, isn’t an issue for some, for some scenarios where there were adverts involved, then that becomes an issue as well, which is different in different ways.

Gavin Henry 00:41:43 Yeah. Cause you might be four, you might have to present depending on who the ops for relevant up to date advertisements.

Matt Lacey 00:41:51 Yeah. And also in the playing adverts is how the company make their money. It’s really important to them to play as many adverts as possible to the point where it doesn’t impact the experience. But then if, if, if all everyone had to do was just download all the content and then watch it. So get around the adverts and that could be a problem. So there was some work we had to do there for some scenarios. And then obviously the knock on effect of downloading and, you know, large quantities, a video that had an impact for it in terms of resources and how we manage

Gavin Henry 00:42:22 And would a naive assumption be that, um, resources, which you mentioned battery storage. So if you’re offline, you’re going to use your storage when you’re connected to wifi, potentially. Is there a big difference between playing something that’s already downloaded versus streaming it on wifi? I’m guessing because you’re using wifi and radio as well. That’s going to use more resources

Matt Lacey 00:42:46 In theory. Am I about tonight that connection or so as a general rule, a mobile internet connection we’ll use tends to use slightly more power than a wifi one. You know, it’s not something I would, um, spend a lot of time worrying about though, or, you know, try and make any really, um, I, I, it’s not a claim I could back up. It’s something I’ve observed in reality that there’s very little difference.

Gavin Henry 00:43:12 Well about AXA as pretty low level, I suppose, oxytocin flash memory to serve up a big video file. It’s probably less energy than a radio signal.

Matt Lacey 00:43:22 I can, I don’t know. I can’t say, um, you know, in theory you could say that we’re going to use less power by downloading all the content at once. Cause we don’t have to keep that radio up for the entire duration of playback, but these are, these are very small things in terms of what we manage. What we did in that application is we are just monitoring battery drain. So we could warn the user when they were running low, because what we didn’t want is people to be watching and watching his content in the app. And suddenly the device goes off because the batteries run out that that’s really jarring and frustrating. So we would go, well, you know what, when you get, when the battery gets low, we make sure that that icon, which the system presents is still visible. We don’t want to hide that away. And we want to give people a warning that, you know, your battery is running low or, you know, you can’t do it these low. So we’re switching to a lower frame rate so you can still watch, but then you, you know, you don’t get there the high definition.

Gavin Henry 00:44:15 Yeah. I’ve seen that on, um, some of the big name stream in San Francisco where you get, you got 10% battery left, so it gives you better time to go and get your charger. Exactly. Okay. I think that was good coverage of the six things to think about. So just to recap, context, input, output, response, enough responsiveness, connectivity, and resources. And you’ve taken us through an app that you’ve got personal experience with and related it to those six steps. I’d want to spend a bit more time on breaking these six things down. You’ve called it in your book, which I really love things. Every option do. For example, you’ve got analytics which we touched upon, which might be the talent telemetry data of what’s going on or what the user’s doing. You’ve got automated error reporting. So we know before the user knows what’s going on, uh, enabled feedback from the users, work offline, notify users of updates, keyboard adjustments, cut, and paste password managers. There’s quite a few in the list, but I just like to, based on what we’ve covered in the past for almost an hour now, can you take me through some of your list of what you’re probably sick of explaining every time and what you see people doing wrongly all the time, just to get out there in front of everyone, that’s listening to this really important things that every option do, obviously they’re all important, but you know, what would you flip to the top of this section you’ve got?

Matt Lacey 00:45:43 So the, the most important thing, and you know, you, you, you mentioned it, it’s a top of the list is that analytics of what’s going on with the app, the store, you know, if you’re going through a store, we’ll give you some of that. But what you really need to know, the most important thing is, um, is error reporting. If something goes wrong, you want to know about it. Don’t rely on the user telling you about it. Cause they’re not going to know enough to give you all the information you need. And then, you know, by the fact that you have some ever reporting in there, it becomes much easier. However, you’re doing that area according to also have some kind of basic analytics

Gavin Henry 00:46:19 And not only takes being what Springs to mind is website analytics, you know, where they’ve come from, what they’ve done, have they checked out in the context of mobile usability.

Matt Lacey 00:46:31 So then one of the most important things I think from analytics is seeing what devices people are using. You know, if you’re building a website and you’re thinking about web analytics, you’re thinking, but what browser are you in here? We need to think about what device are they on, what operating system, what version of the operating system, because it’s all very well going. You know, 80% of people are using version and minus five or that you know, that the five most recent versions. But if that’s not your users, that doesn’t matter. You know, you might say, well, I want to use this new feature, but it’s only available in the latest version of the operating system. What if your users don’t update to the latest operating system really quickly? Well, then that’s a waste of your effort.

Gavin Henry 00:47:10 Yeah. One thing, one thing I realized the other day is that users would generally have different versions of your app out there because a lot of people just don’t update. And I don’t know why I didn’t think of it, but you’ve just touched on it there. The only might they be using not using the latest, um, up, but they might not have done an operating system up there either. So that is really important. Isn’t it, to, to understand, or at least prompt them to say you should be on the latest app. Is that a technique you’ve seen and recommend?

Matt Lacey 00:47:43 It’s definitely something I like to see in apps. There are cases where it’s not as important. There are scenarios, you know, multiplayer, gaming, being a really extreme, one of where, you know, you really must have everyone on the latest version or it just doesn’t work. But I, you know, where possible I like to have that check in the startup or shortly after startup. So it’s not going to interfere with the user’s flow. Is it, you know, am I on the latest version? If not, can we tell the user in some informative, but non-intrusive way that, Hey, there is a new version and you should update because you will get all these great benefits.

Gavin Henry 00:48:21 It’s really tricky though, isn’t it? Because they’ve opened the app to do what they need to do then and there. And if you have to delay that with however everyone’s brain works, where they’ve just remembered what they’re going to do, and then something else pops into it, you might lose what they’re trying to do. You know, it’s a trick you on, I suppose it comes back to your contacts. You know, how important is that update?

Matt Lacey 00:48:41 Yeah. And it depends what person’s doing with the app. It might be the, you know, if let’s say you have an app which is displaying text-based content or images, and here’s some information you might be able to include amongst that, Hey, there is an update available click here to start the process or to enable it, or here’s how you go to settings and turn it on. So it automatically updates. Cause that’s what you really want. So it might be, you can include that. It might be that if someone’s opening the app to do a particular task and you can monitor based on how they’re using the app on the functionality you provide that, Oh, we know someone comes in the app, there’s this, this and this. And then we know it’s done. And as part of that, Oh yes. Now you’re done. You also put the message saying, Hey, there’s an update. You need to go and get this before you use the app again. Um, how you enforce that is, um, will depend on the, would depend on the app. Uh it’s it’s it’s like all that all good technological and engineering related questions. The answer is always, it depends.

Gavin Henry 00:49:37 Yeah. And there’s predefined assumptions, users half because everyone else is doing it. So it must be the right way to do it.
Matt Lacey 00:49:44 Yeah. Um, the, the way you definitely don’t do it is unless you really, really have to is that as soon as you start up, you do a check and you make sure that they’re on that latest version before you do anything else. That’s the wrong way to do that. That’s the, that’s the most wrong way to do it. You know,

Gavin Henry 00:50:00 I like that the most wrong way. Excellent.

Matt Lacey 00:50:03 So other things which I continually see look wrong, which I think everyone should do better do better. That’s where we were going. Wasn’t it? Empty States are probably one of my big book, Beth.

Gavin Henry 00:50:14 Yeah. That’s quite far down your list though. It must be more, more common. Now.

Matt Lacey 00:50:19 Maybe I’ve just seen it a lot recently because it comes back to that asking questions or, you know, making it so that the user doesn’t have to questions about what the app’s doing or why. And so there’s this empty list and empty list because there is no content is content loading. Is it downloading? Is it doing a search? And is it thinking, is there a problem? Is it taking longer than it should? I don’t want to have to think about that.

Gavin Henry 00:50:42 Yeah. As my connection going, where is my internet down? All those things go through your head. When you see that shimmer of the content going to be populated

Matt Lacey 00:50:51 Related to that one, I see a lot is I default message, which says there is nothing, but that’s just because it’s still loading. So I see this a lot. I’ve seen this a lot recently in search related functionality. So you start typing in a search and before the results come back, it puts up a message saying there was nothing to see here, but it’s only nothing to see because the search is still in process and the server hasn’t responded yet.

Gavin Henry 00:51:16 Do you think that’s because of the async nature of searches, the search has been done. So they’ve displayed the image, but they’re still waiting for the async corporation to come back. And that’s just what they think is the right way.

Matt Lacey 00:51:29 It’s it’s invariably world. We’ll just, someone says, well, if there’s nothing to show, we should have a message where it says there’s nothing to show, but not thinking about the scenarios where that might be the case. Um, and yeah, w w where you’ve got asynchronous operations, that’s a good way to get out of the sink.

Gavin Henry 00:51:45 Um, they might actually think they’ve searched for the wrong thing or the search results come back and there’s not found anything, but it hasn’t completed yet.

Matt Lacey 00:51:52 Yeah. I, I bring this up cause I, you know, it comes to mind recently, many times that I’ve started to search, um, the little, the little dots go along, it’s doing something. It put some message saying, sorry, no results. That’s why I started changing my search. The original search comes back and then, then it starts, I briefly see those flash up, but then because I’ve started typing in something else, they go away again and it goes off to the server to make another request. And I get stuck in a vicious cycle.
Gavin Henry 00:52:21 And you didn’t have a service, the backend and blocked you

Matt Lacey 00:52:25 The app. Yeah.

Gavin Henry 00:52:27 Yeah. Um, one of the, on your list here, um, we’ll obviously link to the book in the show notes. Uh, listeners can get hold of a copy to get into this in more detail, but one of the things that every option do that surprised me, um, we support cutting and pasting of text and working with third party password managers. Is it not, is that not just a given, if you can pay something that another app can get hold of it, or, you know, how does that work?

Matt Lacey 00:52:56 It seems to be the it’s really common for developers to like, to build complexity into registration and signing in screens and entering your passcode as part of the app with complexity, that is, which affects the, the ability to use the dashboard.

Gavin Henry 00:53:20 Yeah. Like an upper case, lower case underscore, you know, your last Pat’s name added on and all this type of stuff. If you use it

Matt Lacey 00:53:30 Possible manager, and you have to look into the, to an app, you don’t want to have to leave the app, go out to the password manager, go there and get the password copied that hopefully copy it, go back to the app and paste it. And then if it’s a nontrivial password, which is generated by the password manager, which you’d kind of hope you have, then you’ve got this long string, which you’re not going to remember, which you then need to type into a different app. And unless you can have both apps open at the same time, so you can see both of them, then that becomes really tricky.

Gavin Henry 00:54:04 Is that not a feature of the password manager to recognized, I suppose you have to approve it, watch the screen and look for tax fields or fields. Do you have to Mark a password, text field as a password? You know, how do they, what should the developer think about there?

Matt Lacey 00:54:20 I don’t have a general, this is what you need to do to work with passive managers, which are, might go. And right now it’s very fun.
Gavin Henry 00:54:26 Got it. Yeah. I’ll link to you. I’ve got a link to your blog. So by the time this comes out in two months, I’ll expect the link there.

Matt Lacey 00:54:35 Take it comes back to thinking about the user, the person using the app when they use the app and they have to sign in, no one wants to input usernames and passwords for security purposes. No one wants to have to remember passwords. So if, if the user’s being good and responsible, they will have a password managers take care of all that for them, what you want is your app to be able to work with that, to be able to get the information in as easy as possible. Now, some people assume that being able to paste into a password box is, um, a security risk because it means the passwords in the clipboard.

Gavin Henry 00:55:08 Yeah. And it depends on going by to understand that if you, one of the most important things is the context, depending on how you’re logging into the app, you might use a login flow that uses the web browser. That’s how the app is. The I’m doing works redirected to browser. So, you know, if you’re, if your password manager works with Chrome or Firefox or opera or Safari, then that’s gonna kind of work. But if you’ve got your own username and password in your app, you know, well, let’s point the listeners to your blog post. When I go and we’ll pick it up from there,

Matt Lacey 00:55:48 It can be tricky, especially if you start doing passcodes, which require custom rules and each individual digit goes in a separate tax control. And then it’s, um, yeah, you’re making it harder for your users. So that’s one of my pet peeves.

Gavin Henry 00:56:08 And if you’ve got your users involved at the login page stage, then they’ll soon be squashed as a problem and got ready.

Matt Lacey 00:56:16 Hopefully. Yeah. Hopefully they’ll go, well, this is a pain and you’ll go, ah, I hear what you’re saying. I will improve

Gavin Henry 00:56:22 Exactly great. That’s the meat of the show. So covered there, I’ll probably move us along a bit cause we can near the end. So given that we’ve, we use apps every day and you’ve mentioned a few recently that you’ve had experience with, they’ve been doing names, has anything shined or how are we going to do it without mentioning the name? Can you give me an example of something less than it’s going to work out? I’m sure that was just great usability, but potentially a really nice experience. You know, what did they get? Right. And then briefly another one that could be improved, you know, I’m not gonna use the word, it was a bad app or it was poor. No. As soon as software has made, it can always be improved. So do you have something in your head that we could spend the next five minutes or so on before we start wrapping up?

Matt Lacey 00:57:13 So email clients are one of these things which have really, really hard to do well. And at the time,

Gavin Henry 00:57:20 The word email into the app stores, you spend all day trying to find something, you know, if it’s not a major brand.

Matt Lacey 00:57:26 Yeah. So as of this week, there was a new email client, which, or email experience emails.

Gavin Henry 00:57:35 If you can invite,

Matt Lacey 00:57:37 I was looking at that today. So naming, naming no names. Yeah. I’m still waiting to get approved as well.

Gavin Henry 00:57:43 If it’s, if it’s still on the ops door two months, it will be a link to in the show notes.

Matt Lacey 00:57:48 But based on the variances with the other software in the past, I’m really intrigued to see what they do. I can’t say. So what, what I know about it makes me excited and think it’s going to be good, but I haven’t used it yet. So one of the, in contrast to that, one of the things I’ve discovered since going through everything, which I put in the book is I’ve ended up focusing on, you know, I see faults and problems and opportunities for improvement everywhere. So it’s really hard for me to get excited about things because I can always find problems and things that could be better. And, and you know, and that that’s a consequence of, you know, going really deep into how do we make things better and you can always see things that could be better. But on the other side, if things are good, you shouldn’t notice is things have to be really, really, really good for people have noticed them. And in terms of using your app, you probably don’t want people to go, well, it’s really fun using this app. I really enjoyed it. It should just work, just work. If you don’t think about it, you know, if I want to send this message or talk to this person or do X thing, if I can do that without thinking about it, without any challenges, without any problems, then that’s a really good success

Gavin Henry 00:59:01 And a bad one or one that needs improvement to put a different spin on it. Something that gets in the way of what you’re trying to do.

Matt Lacey 00:59:09 Yeah. We talked about, um, video apps earlier. I have about nine different video apps on my phone at the moment. And they all do things slightly differently. Some of them put the play in the pause button in awkward positions where I’d keep missing it. Some of them display the, one of them displays the play and the pause button, the wrong way round at some times, which makes me really confused. So I don’t know if I’m doing the right thing. If we, should I press it again or should I?

Gavin Henry 00:59:36 Yeah, no. I’ve seen ones that aren’t very responsive. So by the time you’ve passed poles, it started playing again. And you’re just in the sleep of play and pause, play and pause. Yeah. Just checking a couple of quick questions. Okay. This is great fun. Um, what’s the hardest part of an app to camera, right? Do you think, is it something you keep seeing? I just think, why have they bothered? Is it not again, the users involved at the star or visibility? You know,

Matt Lacey 01:00:05 One of the, I think the thing that jumps out at me most is the people not knowing who it’s for before they start building it. It’s really easy to think, Oh, it’d be great. If there was an app that did this without first establishing, but people want that, are there enough people who want that to make it worthwhile other, other solutions, which are good enough and can you be significantly better than them? It’s somebody thinking about it like a business. And if you just want to build that prefer, and that’s great. If you want to build a map for fun and then get upset that you know, you, haven’t got millions of people paying you to use it. That’s kind of on you. It’s about matching those, the goals and the reasoning behind your builder, understanding that context upfront.
Gavin Henry 01:00:45 But he wants to write software that doesn’t get used today. Nobody wants to write software that nobody uses

Matt Lacey 01:00:52 There. There were a few people that are happy to do it as long as they get paid. But yeah, for most of us, we thought when we want to write software, that makes a difference in people use.

Gavin Henry 01:00:59 And any book author that I get on the show, I always like to ask, where did the idea come from for your book? Because it’s a big heart. I haven’t done it myself, but I was speaking to lots of people. It’s a long process. So, you know, what’s the driver factor for you there. If you don’t mind me asking, feel free, not to answer. I’m sorry

Matt Lacey 01:01:21 The book came about because I wanted to know how to make better apps. And you know, that that’s where I started off. I could see this software that I was being told and bailed. Wasn’t brilliant, but I couldn’t explain how it wasn’t brilliant. And I didn’t know enough to say it would be better if so I went off and learned loads of things about how to make better software, formulate them in my own unique way, which is how he came up with these six components. And they kind of started to resonate with other developers. And I would talk with them and talk to them at conferences and at user groups and things. And that made sense. And then I was talking to a publisher about a, another Berkeley pro. They approached me as a, you know, as an advisor on another project that we’re working on.

Matt Lacey 01:02:04 And they said, you know, if, if there’s ever anything you want to talk about, well, if you, if you ever have an idea for a book and I said, well, it’d be great. If there was a book for developers, which is about the stuff, which isn’t actually writing code because there’s loads of that. But there aren’t a lot of resources for it. And we spent some time going back and forth, refine that really brought everything that’s not code down into. Well, here are some things you can specifically think about and they’ll improve what it’s like for the people who are using your apps. And that’s what we’ve got in the book. I’d just like to thank you for taking that time. Cause it’s, you know, the listeners are gonna appreciate that. I appreciate it. That’s why I approached you. I have to start wrapping up now.

Matt Lacey 01:02:40 Cause I think, yeah, so I can’t move in. So obviously usability is important for Occidental designers and users, but if there was one thing a software engineer should remember from our show, I think we’ve already covered it, but what would it be? Just so underlying through that, it’s going to come back to again, analytics, find out the context, that’s the shortcut to the context of your app once it’s in use. So, so Harvard, the main reason why it’s going to be used and then make sure it’s doing what it’s supposed to. Yeah. Once it’s out there, thanks for people that are using it, which is always nice. See how they’re using it, see where they’re using it, who’s using it, what device is cause that’s going to inform everything going forward. So if you’ve got an app that already exists, you need analytics to know about it, what to do going forward.

Matt Lacey 01:03:27 And if you haven’t, then you need to be talking to people in advance. And is there anything we missed that you’d like to mention? So I’d just like to call out the, you know, this is quite a broad, airy fairy general topic. And one of the things I tried to do in the book is distill that down into specific points of advice, or there are lots of checklists and things to make sure you can go and do and ways to apply the general principles within the book. Yeah. It’s difficult to get really deep down on a 70 minutes. I think we, I think we’ve done a good job. Yeah, no, I’m, I’m pretty happy. So, um, where can people find out more? Um, you got a Twitter account. I see how people get in touch, mostly responsive on Twitter or, um, I have a bloke and mr. Lacey pretty much everywhere if you can’t find on that blog is going to be where we’re going to read that blog post on third party password managers in two months time. Okay. You give me homework. Well, it might have worked for myself. Sorry. I won’t blame you.

Gavin Henry 01:03:57 Excellent. Thank you for coming on the show. Um, I do say this at the end of all my shows, but it’s always a real pleasure to speak to you. Um, and this was no different. This is Gavin Henry for software engineering radio. Thank you for listening.

[End of Audio]

This transcript was automatically generated. To suggest improvements in the text, please contact content@computer.org.

 

Facebooktwitterlinkedin

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,