Building Low Code Apps with the User in Mind

Mitch Herrema (00:06):

Hey everyone, welcome back to Make Others Successful, a podcast where we like to help you in your workplace and make you successful so that you can in turn, make others successful and keep cascading that down. It's our goal to always leave you with a lot of insightful tips and tricks and thoughts around building a modern workplace. And today we have a special guest with us. He's been on our team, but he hasn't been on a podcast before. And that is Josh. He's our resident designer here. So we wanted to dig in a little bit more into a video that he and Mike put together on our YouTube where he basically walked through an existing app that Mike had built and gave tips on how to make it better and more user friendly. And so a lot of people liked that video and we wanted to dig more into that topic and get more time from Josh and basically just add on to all of that and keep the conversation going. So do we wanna start with introductions really quick?

Matt Dressel (01:03):

We got a big crowd this time. Yeah, I think this is maybe the biggest, Most people, we four

Matt Dressel (01:08):

People

Mike Bodell (01:09):

Three's, company four is a crowd. Is that what you gonna say?

Mitch Herrema (01:11):

Yeah. So Matt, Matt's here, we got Mike.

Mike Bodell (01:15):

Hi

Matt Dressel (01:17):

Josh, we wanna hear your voice. Yeah.

Josh Everingham (01:18):

Hi, I'm Josh. I'm designer at Bulb and do some work for the state of Michigan and just try to make everyone's life a little bit easier and a little bit more delightful.

Mitch Herrema (01:29):

And yeah, my name's Mitch. I help with a lot of operations, but have a background in development. So I think it'll lend a hand to this conversation. Where do I wanna start?

Matt Dressel (01:40):

So I think the best place to start is to talk a little bit about what we're gonna be talking about. So we're gonna be talking about keeping the user in mind when you're developing solutions. And specifically we're gonna be talking about it related to low-code, no code solutions, which can be a lot mean of different things. Obviously we're gonna be talking about power apps, but it applies to forms, it applies to lots of different things where you're developing solutions or areas where users will interact with whatever you're developing. So let's talk a little bit about what the state of the situation is today. So Mike, I know you have a lot of experience with the work that you did with Josh about creating apps and then having Josh help make it better. You wanna talk a little bit about how Microsoft's default experience works and where it's focused?

Mike Bodell (02:27):

Sure. So I think one of the things that if you're developing power apps one of the first things you'll realize is Microsoft is trying to make it easy to use first and foremost development tool, a way to build apps quickly. It's replacing a lot of different things, honestly. Things like access apps and other things, particularly when we talk about power apps, but it's very wizzy wig. You're gonna drag and drop things onto your screen and those things are not always going to be created or built by Microsoft with the best use case or best user experience in mind. And that's not to be a dig on Microsoft, it's just the reality of the situations. It

Matt Herrema (03:05):

It's a canvas, it's blank blank place for you to play. And so inherently

Mike Bodell (03:10):

It, yeah, it has extra work that you need to do to make it great. One, just a key example of that is out of the box standard gallery control, if you drop that onto a Canvas app, it's got widgets built into it that allow you to select the item and navigate to another screen, for example. But if you're designing the app with a mobile device, mobile layout in mind, for example, out of the box, the entire row is not a touchable or clickable thing. So you have to do a little bit of extra work. And that's something that we talked about a little bit in that video with Josh.

Josh Everingham (03:38):

Yeah,

Matt Dressel (03:39):

I would add to that, Microsoft has to choose one. There's layouts templates and stuff. Microsoft has to choose one scenario. When you're dropping that on that they, that's their starting point because you can't have any option you want. They can't have every different option available to you.So they're choosing one option. And if that option isn't the best for what your user experience should be, you need to take the next step and think about it and come up with a better or change it, configure it differently, add different components, those types of things. You have to take that next step.

Mike Bodell (04:13):

Yeah, I think one of the things that I learned from Josh just in spending that time is to actually take the time and think about the user.

Josh Everingham (04:21):

Yeah, I mean I think it's really easy to just put something down on the page, which is easy and that sort of works, but everything that we do that doesn't involve us taking the extra step to make it more usable for the user is work that we're passing off to the user. So it might be easy for us, but if it's not easy for the user, we're basically just kicking that can down the road for them to take over.

Mike Bodell (04:43):

I love what you just said because all of this work that we're doing, the no code, low code, the whole thing is all about now we can build apps for less money that save people time. And if you're not thinking along the lines that you just described, which is if I don't make it nice for the user or easier to use a better user experience, you're just making more work for the user kinda defeating your own purpose.

Josh Everingham (05:06):

It saves me time as the creator, but it might not save other people time as the actual user and people aren't gonna want to even interact with

Mike Bodell (05:13):

Your Yeah, and that is the goal.

Matt Dressel (05:15):

So let's talk about this for a minute because I think we all agree that is really important. I would also posit that that is incredibly difficult <affirmative> for several different reasons. Number one, if I've got people who are in a mobile app and I've got people who are on big nice monitors and I've got people who are on tiny laptop monitors and I've got people who are doing admin tasks and their goal is to enter as much data as quickly as possible, and I've got other people who use the system one time a year and they need extra information, it is incredibly difficult to try to manage all of these needs. Josh, can you speak a little bit to how you might go about deciding what is the best persona or the best users to keep in mind when you're trying to design something?

Josh Everingham (06:07):

So I think that a good place to start when you're creating anything, be it power platform or custom development or even just literally anything you've ever made for anyone ever, is to just think about what your end goal is and who you think is going to be using it, what you would like them todo and how you think they're gonna interface with whatever it is. So first and foremost, what does the app do? And then from there, who needs to do it and what device might they be doing it on? And while not every single app needs to take every single device type or every single type of user into consideration, you need to think about who will realistically be using that. So you need to figure out if this is a really complex software that people are going to be using at their workplace, specifically sitting at their desk, you might not need to take as many considerations for something like a mobile device, but if somebody is using this app in the field, and if you have a lot of remote workers and people that are not tethered to a desk and don't have monitors set up with their nice ergonomic chair and everything, they might be working in the field.

(07:09):

And if that's the case, then you need to focus on mobile devices and for things like tablets and stuff like that. So you kinda just need to understand your goals as the person creating a tool, but you also need to understand your user as who's going to be using those tools. And that should all be understood before you ever open up a new project with Canvas apps.

Mitch Herrema (07:30):

I'll say, this isn't a new problem, even though, right? It's been around for a long time. And that's why I feel like when application development really took off, it became a standard to say, I have a development team and I have a design team. And they kind of worked together on for good apps. They had both of those things that worked together in order to develop something. But with low code, it's a lot harder to make those distinctions because the onus is on the person to develop their own app. The power is in their hands now and they don't necessarily have all the resources to go through that process.

Josh Everingham (08:10):

And I'll say even a lot of organizations that aren't using the low code, no code app thinking about the users and specifically focusing on design is still relatively new, especially with relatively immature organizations that haven't been building these processes for years and years and years. I work with an organization that I still get pulled into projects that they didn't think they needed a designer, and then when they're halfway through the project and everything's in the red and they don't know where to go, that's when they call us and they start panicking to come need help<affirmative> from us. But the reality of the situation is that you kind of need to start at the beginning thinking about these things. And when an organization has a dedicated designer and a dedicated developer and people that turn the business goals into tangible to do items that process is much smoother. But the blessing and the curse of low code, no code is that it's a good thing that anybody can develop apps, but at the same time, ANYBODY can develop apps and not everybody has that expertise to make something particularly usable. So you kind of have to be the design team and the development team and the business analyst all at once, even though it seems like you're just opening up power apps and starting and making a thing.

Matt Dressel (09:24):

Well, what you really want, in an ideal world, you have a development staff and developers who understand the desire to focus on the user first and they're starting from that position and then they're using design teams to help them where they have gaps where they go, I'm not sure what the best thing to do is here, but in other places where they can themselves start to figure some of that out, it's like a mind shift that happens from thinking about my goal is just throw everything on the page and get the functionality working to, I'm gonna try to think about this differently and use patterns thatI know work for my organization or for my group or that are our standards that we can use. And they work 90% of the time. And then for the 10% you bring in a designer and you say, Hey, I don't know about this. That's kind of the ideal situation. The problem is that takes a lot of time to happen and it takes a lot of education to go on, which is part of what this is one of our goals about this doing this podcast is to get that in people's minds so that when they're thinking about developing, they try to at least think about it, whether or not they do well or not, at least think about it. At least start from that perspective and ask the questions.

Josh Everingham (10:37):

So I think that a lot of people run into this pitfall where they usually think of design as being like what makes something pretty?When I say design, a lot of people just start thinking about nothing but fonts and colors and logos and posters and stuff like that. But when you're creating a product like this, you're also designing the way that you interact with things. You're designing the experience in general. So it's not just things that are tangible like colors, it's also things like where do we start? What’s step one, when do we branch off for one user versus another user, and what do we present at what time to make it more digestible? So it's really easy to create something that's just gonna check off all of the things on your to-do list that, oh yes, this app can do everything that I want it to do, but if users can't figure it out, then it might as well not be able to do anything because the users can't do it.

Mike Bodell (11:33):

So it actually sounds like there's a couple different areas to focus when you're designing with the user in mind. One of those areas being some of the basic principles like where button placement, right size how to use colors effectively, fonts, stuff like that, which we alluded to in those videos that we did. But then the other piece that you just talked about was the user experience for the process that you're guiding the user through. What is the application trying to accomplish? What is the user trying to accomplish? And thinking of your process in terms of how you can design it to make it optimal for the user.

Josh Everingham (12:08):

Exactly. So you need to design the user journey, which is the path. And then there's the user experience, which is where are things laid out, how are users interacting with these step by step? The experience is kind of the frame versus the UI, which is the colors and the text and stuff like that. And the button placement, which is all important, but they're all just different things that people don't often consider <affirmative> when they're working on.

Mike Bodell (12:30):

So some of the stuff that you could do in terms of making it better in terms of button placement and colors and fonts and those types of things is look at ways to build themes for your organization in terms of apps.And there are ways to do that in power apps it's somewhat limited, but you can do that type of thing to give your citizen developers of good starting place to work from. And so in many ways that's a great place to start as an organization because you can solve a lot of that. Lot of those problems. Take the low hanging fruit, right, exactly. And get it outta the way so that we can focus on making the journey the best it can be.

Josh Everingham (13:07):

Yes. So I just recently wrote a blog actually about the psychology of colors. And while I know I just mentioned that design is more than just colors, but color is actually a really important part of design and can impact a user experience and how you think about your users. So what you just mentioned there are things like creating themes. You can create colors that you use specifically for certain reasons, and you have patterns that are established. So things are predictable and for the most part you're gonna be relying on neutrals for your backgrounds and black or dark gray for your text. But then when do you sprinkle in the color? If you want somebody to interact with something that's like a call to action that might be where you put in your brand color. And so your buttons that are your standard calls to action might be your brand color and they stand out because you aren't drowning in a sea of color.

(13:54):

You have neutrals and then a really eye grabbing color for your call to action. And then how do you tell somebody they're doing a good job? Well green with check marks and thumbs up is a good place to start. And if there's a problem, put a big red square in front of their face and an exclamation point or an X and users know immediately, oh, something went wrong here, I need to address this. So establishing those sorts of brand colors, those sorts of color standards, and even things like what is success? What is a warning, what is an error? Or what is just general information look like can all go a really long way, especially if you make a lot of things, it's predictable so you don't have to pick your color. Just,

Mike Bodell (14:38):

It's interesting to me how so much of that we can draw from the world around us. Stop signs are red octagons exactly everywhere.

Josh Everingham (14:46):

And that's a reason for that is because it's, especially in the western world, I'm not gonna say that every culture everywhere sees color the same way, but particularly in Europe and North America and in western cultures, red is urgent, Red means stop, you know, go back to hunter gatherers.Red is blood, red is meat. So it's very primal the way that we react to something like red, we don't ignore it. So putting something red in the way is gonna immediately tell users to stop because since they're a child, they see red on the stoplight, they stop sign, they stop, fire truck is red, you get outta the way. So the things that you want to be noticed and are important, you use red and things that are less important, but something that you might wanna still highlight could be blue because blue doesn't cause that like primal anxiety that red causes and there's a lot of psychology behind when to use certain things.

Matt Dressel (15:38):

So, let's talk about the result of that. If at all possible, you should be trying to choose consistency over perfection. So having consistency in color, having consistency in location and the way things feel to the user is really important. If you get to a screen that needs to be a little bit different here or there, think long and hard about that before you go make it very different than what it was before. Have a good reason for that, have a justification for that. Have an understanding of why that is. Otherwise use the standard. Right? Exactly. And that's not just between for one app. In an ideal world, this is very difficult to get. Every app in an organization has consistency that makes it easier to train, that makes it easier to work with and makes it by and large, even if you do it wrong, even if it's not the perfect thing, it's easier for people to understand because once they understand it one time, they understand it for all of the rest of the applications.

Josh Everingham (16:39):

Exactly. We really don't want to break user expectations, and especially if you have multiple experiences, it's a really good idea to lean into how you solve the problem last time, to consider how you're gonna solve a problem next time. So a good example, we're talking about Microsoft here, is basically every Microsoft Office app has a similar layout. They've got the task bar up at the top, you got your file in the top left that you click on that and you see save as, you see save, you see open, you see all of these print. These are things that if I've never opened up a Microsoft tool, but I have used,

Matt Dressel (17:18):

If they came out with a brand new tool, you'd know whereto go.

Josh Everingham(17:21):

If they come out with a brand new tool tomorrow the first time I open it, I'll know how to save a file. I'll know how to open a file,I'll know

Matt Dressel (17:28):

Formatting shows, formatting,

Josh Everingham (17:30):

I'll know where that should be based on my logical experience. So if I'm creating an app in one instance to solve any task, I can rely on those patterns the next time assuming those patterns are effective and predictable. And you don't have to think about every single thing you lay on the screen. If they're similar, if I put a certain amount of space between a header, a paragraph and a button, I could just use that same number every time.I don't need to reconsider what happens there and I don't need to jam everything onto one page either because you're using a device, there's infinite vertical scrolling for the most part if that's the way you wanna do things, or you can just break it step by step. We don't wanna overwhelm people by just putting everything at the wall at once.

Mike Bodell (18:14):

So that's a very interesting paradigm that you guys just brought up because in the no code, low-code world, particularly in the power platform, if you're thinking about building power apps and you get yourself into the model driven app world there, that paradigm exists. So in that world, you're building your data model first and you're building your app from the model. And everything in the data model is essentially a table and out of the box, what you get with the table is you get some basic forms and you get some basic views and all of those views have the same command bar at the top with all of the same functions like export to Excel, change the view to something different, create a new record, so on and so forth. And the forms are the same as well. And so that's one of the really nice things about that world is you can build your data structure and have all of those things out of the box available to the user just without doing any real work. And really the only thing you end up doing is changing permissions to hide them from certain users that don't need to see certain things. So maybe you wanna not let certain users delete rows, for example.

Matt Dressel (19:10):

Yeah. So what's really interesting about that, Mike, is that one of the things we talked about, I talked about was, hey, different users have different needs. If you are a user that is consuming an application on a semi-regular basis, but it's not something you live in every day doing something all the time, the user experience needs to be very different than someone who is dealing with a thousand records a month, <affirmative> in a particular solution. And they've already kind of created a model. If you're using Dataverse, like you were talking about, that whole experience about everything's all the same, it's all the same, but it's also very, very robust.The default is you get a ton of options that you can copy, you can export, you can do things like you have lots of things that you can do with that, which would be terrible, absolutely horrible for somebody. I just need to go insert a requests

Mike Bodell (20:04):

Focus on, focused on a single thing

Matt Dressel (20:07):

Would be, it's a terrible user experience, but their model is, okay cool, build a canvas app. We built this all low code, it took you three days to build the model driven app. Let's say create a canvas app that focuses on that user experience and use the model driven app for administration and for users that are doing this all the time, right?

Mike Bodell (20:26):

Yeah. So your back office app is model driven, correct?People that have access to all of the data can do anything they need to do with it. But then you've got people, let's say they're in the field and they've got a mobile device, maybe a tablet, what do you give them? A canvas app that has limited function.

Matt Dressel (20:41):

Yep. That can do just what they need and can focus on that. And it's an interesting thing because one of the things that you can leverage with low-code solutions is I, it's easy for me to create new ones. So create three apps that have different experiences for different needs or create three experiences within the same app. Have an advanced button have, do something that you can enable users to have what's best for them and for how they're working with your data. A lot of it has to do with how much time and money and energy and <affirmative>. If you've got two users on the frontend and two users on the back end and nobody uses it a ton, maybe you don't need two different apps, maybe you just come up with something in the middle.If you've got thousands of users on the back end, on the front end and 10 or 15users on the back end, it probably makes sense to have two different experiences.

Mitch Herrema (21:34):

So I wanna maybe come up for air really quick and focus on if someone is building something for the first time or they're just entering this world of low code, no code development and they're building an app for the first time, they aren’t exactly sure where to put, what sort of structure outside of a theme can we put in place? Maybe timeline, how often do they get people to test it? What sort of structure can you put around someone developing an app for the first time that maybe doesn't have the knowledge of how a design team works, <affirmative>, how agile development works, all those things.How do we summarize that for someone that might not know?

Josh Everingham (22:19):

So I think going back to what I mentioned earlier, one of the first things that somebody should do before they ever open up power apps is to, I don't know if it's on a whiteboard, if it's on a piece of paper, just write down what you want to accomplish and who all is going to use this. So when you understand those things, you start to understand where do we begin? So the first thing might be if there's multiple types of users, we want those users to be able to get where they need to go. So if we have multiple types of users for one experience, we might have some sort of landing page, some sort of menu that says I want to do this and I click here and I'm taken to this funnel, or I wanna do this and I am taken to a different funnel, especially with apps that have lots of possible options.

(23:03):

You kind of want to start by steering people in the right direction. And then from there you want to start figuring out what they need todo and how they go about doing that. So if it's something that's repeatable and if it's something that's got a set path through it, I don't know, for lack of abetter word that might be the best way to do something, is to break things down into bite size chunks. So if you're collecting information for some sort of form, for example, you might want to consider everything that you're trying to collect and then try to logically group those things <affirmative>. And maybe you have a step by step page one of five, This is step one, personal information, step two, your goals. And so when you break things into these bitesize chunks, people aren't overwhelmed by what's on the screen and they can accomplish their goal and then click next. And

Mitch Herrema (23:55):

How do they know if it's good?

Josh Everingham (23:57):

How do you know if it's good is if you get bad feedback.Obviously it's bad, but you might be able to solicit feedback from users that if it's in an organization, it's an internal app, Ask people how they're enjoying the experience, how easy it is or how hard it is for them to work with things. So oftentimes it's just getting feedback from users to understand if something's good, but if people are taking a really long time to do things or if they're confused, then they're having a bad time with the experience and there's gotta be a way to solve that.

Matt Dressel (24:28):

So we, I've done a couple different things. So number one, watching usage. So let's say that this is a request process. I would expect there to be 50 requests a week. I don't have any. We launched the new thing and we're not getting anywhere, got five requests why? And to answer the why, I'll often actually try to engage with an end user and ask them to show me what they do exactly. Get on a screen share and be like, Hey, just walk me through making one of these requests. Or Hey, you said there was a problem with the request, can you show me what you did to this? Right. Let's get, let me see what you're doing. Because oftentimes they can't, users can't articulate what's wrong, they are frustrated or they may not even be frustrated, but they're doing something that you don't expect and you don't know it until you see them do it.

(25:21):

Yeah, seeing it is a big part of it. What Josh talked about trying to get feedback. We've used surveys to say, Hey, we launched something new or we sent this out, How was the experience? What happened? Is it, what do you think? Right. So those are some things that I've used in the past to try to gauge it after the fact. I also think it's interesting, whatJosh was talking about going through I think is really common for solutions where you understand the process and people have spent a lot of time thinking about the process going forward. Oftentimes in our world where you're talking about low code, no code, there's a difficult time for end users and visualizing and thinking about what it could be. They just know what they do today and they have a very difficult time following along. So oftentimes what I'll do, it's low code, no code, I'll spin up a demo, an example, maybe it doesn't work all the way, maybe not all the things are there, but I'll come up with a demo quick and say, Hey, let's walk through that.

(26:20):

I'm gonna present it and I'll walk you through what it is and try to get feedback that way. Which sometimes can help people visualize what's going on better because they really, I'll take a perfect example. An email gets sent from one system into a shared mailbox. Somebody gets it, they look at it, take the details from that and put it into another system and then produce a report. And I'm like, hey, we can automate a bunch of those things. Theydon't even really understand what that looks like. And so I'll create a little automation with a dummy email and hey, this is what it looks like and you don't have to do anything anymore. Or you just get an email that says, and when you say that, you say, Oh, you don't have to do anything anymore done. Maybe they're getting freaked. In this case they got freaked out because they're like, Well then I don't know that it happened <affirmative>. And I'm like, Well then I can just send you an email letting notifying you that it happened. It's that kind of thing where they just don't, don't know what they don't know.

Mitch Herrema (27:13):

Yeah, I think that's why the whole wire framing industry is such a thing. How do you create something quick, easy so that someone can actually experience it for themselves? Doesn't have to be full-fledged, but obviously we're talking low code stuff here. So it's kind of wire framing, it's wire framing plus or something. But even in custom development applications, we always start with wire frames. Design something to get people in that mindset.

Josh Everingham (27:39):

Design a design early and test early and test often. A lot of the stuff that you've described here is basically just the entire field of user experience research. There's people whose entire job is to collect this feedback and solicit this feedback and try to draw conclusions from it. And one of the disadvantages of being a small organization that's using low-code, no code is you don't have a research team. And those research teams can be expensive, but even just soliciting the people that you do know working on in your app is a great way to start. Cause that research is that information is worth its weight in gold. And I go outta my way these days whenever I somebody solicits feedback on a digital experience, I jump through hoops to give it to'em because I know that if I'm having a bad time and they ask how I'm doing, ifI just ignore it and stay frustrated, I'm just gonna stay frustrated. But if I give them feedback like they're asking because they wanna improve the experience.

Matt Dressel (28:33):

There’s a chance to link it better.

Josh Everingham (28:33):

Link it better. People don't always know when something's not working. And even if you don't know what the solution is as a user, nobody really expects you to know the solution, but you do know the problem. So I always give this example, people back in the early 18 hundreds or the late 18 hundreds, they wanted a faster horse that could do more work, but what they were given was a car. People don't know what the solution is, they just know the problem

Mike Bodell (28:59):

<affirmative>. So one of the things that I'll put this out there, and I think this is pretty heavy and it's one of the things that I've had to learn and that is the importance of humility in that process as a developer, because you get invested in the thing that you build and whether or not you're getting feedback from somebody who has done the research and is a designer and has that brain, or you're getting feedback from the endusers whenever you get something that's like, Hey, this isn't right, or why can't you make it do something different? Sometimes it's tough because you're invested in it. And the importance of humility in that process is something I think that cannot be overestimated.

Matt Dressel (29:37):

So to that same point, end users recognize that and so then they hold back. Sometimes you can have a couple different types of users.One user can be like, they're gonna just lay it out there and be aggressive and unreasonable in some cases <affirmative> and not even understand. If you try to explain why it has to be a certain way, maybe there's not a way you can change it. But then you've got a whole nother set of users who are like, they've had a bad experience with a developer in the past, naturally not critical, whatever that is. They don't say anything and they don't wanna say anything cuz they don't want to hurt your feelings or whatever. It's also important not only for you to be thinking about it, but to express to the end users. Our goal is to try to make it better based on what you guys need. We're here to deliver on what you need to make your job better or make your scenario better. Give us feedback please.

Josh Everingham (30:27):

Right.

Mike Bodell (30:28):

Yeah. So one of the examples, and I don't know if we talked about it very much in our videos, Josh, but we've talked about it personally. And that is I spent a lot of hours, I don't even know how many hours I spent trying to figure out for the hoteling app, how to get a floor plan map in a situation where I could plot spaces that the user could choose from on the map <affirmative> and that the user could actually zoom in, zoom out, scroll around on that map, and there is nothing in no code, low-code, at least in the power platform right now, that allows you to do what a user really wants to do, which is pinch.

Josh Everingham (30:58):

Oh yeah. That was frustrating for me and trying to understand that as somebody who doesn't create these power apps, I'm sitting there looking at this map that I can't interact with and I'm like, Oh, well can you make it pinch and zoom? And when you say no, I'm like, what do you mean?No, it's a map.

Mike Bodell (31:14):

And my realization was, oh crap, I spent all of that time and nobody likes this.

Josh Everingham (31:18):

And that's just one of the shortcomings of a no code, low code is that sometimes the answer is you just can't do it with what's out of the box. And we came up with a solution, which is functional, it's got sliders that you can slide left and right on the map. You can slide up and down on the map and so you can get to where you want on the map and it has a zoom in and zoom out function, but it's functional in that it's not a map. You can do it, but it's not usable. You know, turn a door handle, you walk upstairs and you pinch zoom a map. And if you can't pinch zoom a map, it can't truly be usable and accessible to users who are Hove been doing this since the iPhone came out in 2007. Everybody knows they see a map, they touch it with two fingers, they pinch, they zoom.

Mike Bodell (32:04):

So if Microsoft is listening, <laugh>, add some better functionality,

Josh Everingham (32:08):

Pinch and zoom

Mike Bodell (32:09):

Please pinch and zoom

Josh Everingham (32:10):

Pretty please.

Matt Dressel (32:10):

So this what you guys were talking about brings us to what I think is the last part of the discussion, which is we're develop, in this case, we're developing low-code, no code. There are limitations, definitely is the drawback to doing low-code, no code. Right? By doing that, you are consciously making a decision that you do not need ultimate control over the user experience. Right? And if you need something different, you probably should not be using low-code, no code to do this. Right? Exactly. You are gonna spend way more time as what Mike alluded to, trying to force it to work how you think you want it to work and you still won't be successful. And I'll tell you, be great

Mike Bodell (32:51):

After all of that time, I was still proud of myself that

Matt Dressel (32:53):

You figured it out,

Mike Bodell (32:54):

That I figured out how to do something,

Matt Dressel (32:56):

Which there's nothing wrong. And to be clear, I'm not suggesting that users shouldn't take what they have and try to make it better or do the best they can, but if the user experience, if pinch and zoom is a requirement, you cannot live without it. This is not the solution for you.Yeah.

Mitch Herrema (33:12):

It makes me want a list so that people can quickly reference needs.

Josh Everingham (33:17):

Yeah.

Matt Dressel (33:19):

I mean pinch and zoom another one. Drag and drop. If you need a solution that needs to Dr. In Canvas in particular Canvas apps in particular, if I need a solution that drag and drops things around in reorders stuff, that is not your solution. So

Mike Bodell (33:33):

Think board view.

Matt Dressel (33:34):

Yeah, board view. That's Canvas isn't just not built to do that, right? Yeah.

Mitch Herrema (33:39):

Also, well, yeah, I have my own reservations about it, but the fact that it is all pixel based, it's Canvas based. Oh yeah. Oh man. It's not dynamic like height. You have to do special crazy containers, things to do,

Matt Dressel (33:54):

Special

Mitch Herrema (33:54):

Containers to make it all dynamic and pretty and

Mike Bodell (33:58):

Responsive.

Mitch Herrema(33:59):

So that can be a little bit of a challenge too. Yeah.

Josh Everingham (34:02):

Yeah. But sometimes it feels like you're creating an app using the old sketch app, which is all pixel based. Technically it's vector based, but you're still

Mitch Herrema (34:11):

Microsoft Paint. How about

Josh Everingham (34:12):

It's like paint? Yeah, it's you're designing mockups in Photoshop, it's 2008 or something. It can solve a lot of problems. And not every problem needs a business analyst and a design team and doing sprints in order to accomplish something. If your goal is to collect some basic information about a user, you're creating a basic survey. You are, you're trying to accomplish something that is simple and straight forward into the point. Power apps is gonna be a great solution for that. But if you're trying to create something that is incredibly complicated, if you're trying to create something that requires a lot of sensitive information and you're just trying to build a lot of trust with your users, power apps might not be the right solution for you. That might be where you have your design team, if you have a design team or you outsource that work to a design team or a development team or some sort of shop that does the stuff for a living. Because sometimes you do need people doing research and people doing wire frames and people coming up with the best solution, not just a solution, but the best solution.

Matt Dressel (35:13):

So I get right back down to brass Tax in 20 some years of doing this type of work, have been asked on many occasions, many times byMicrosoft directly to make their products do stuff that they should not do.<affirmative>. And knowing what those boundaries are and choosing the right thing is really important. It can save you a lot of time and a lot of money because the reality is these tools have their place and that place is huge and it's getting bigger all the time. Microsoft is making huge improvements to make this whole, all of these tools way better for all of these reasons and all of these purposes. But there are just limitations. And if you are stepping outside of that, it's just not worth it.

Mitch Herrema (35:56):

Yeah. For instance, we had a client come to us with a need for an intake process and we said, Oh, forms can probably do this. And we learned that you can't do anonymous form uploads through forms,

Mike Bodell (36:12):

File file uploads,

Mitch Herrema (36:14):

Yes. Sorry, file uploads. And I'm sure there's a logistical reason behind it, but man, we went down that path only to discover that. And it was a huge bummer and we had to work around it in many ways.

Matt Dressel (36:28):

We, and we created a workaround for the moment, but ultimately we're gonna choose a completely different a technology. It's another Microsoft technology. They'll be using a power apps portal, but a completely different technology to try to get around it because it's super important to that customer. This is the core of their business and they need it to be a great user experience and they need it to be something that works really, really well. So we have a workaround for the moment, but ultimately we're gonna use a totally different technology to make that happen.

Josh Everingham (36:54):

What was your work around?

Matt Dressel (36:56):

So the workaround was to basically accept the form input and then on the backend send an email to the user asking them to go place afile in a location. Wow. It,

Mitch Herrema (37:07):

It's a link to a OneDrive OneDrive

Josh Everingham (37:10):

Location. Location. So they send you the information, they fill out the form, we shouldn't

Mitch Herrema (37:13):

Tell Josh anymore, he's

Josh Everingham (37:15):

Gonna

Matt Dressel (37:16):

Rip this out.

Mitch Herrema (37:16):

And then

Josh Everingham (37:18):

You send them an email. So they have to close their form, they have to open their email, they have to open that specific message and

Matt Dressel (37:24):

Then click

Mitch Herrema (37:25):

A link, which takes you to another place, which Josh,

Matt Dressel (37:28):

To be clear

Josh Everingham (37:28):

Oh man,

Matt Dressel (37:29):

To be clear what they're doing today without the form is even more ridiculous. So

Mike Bodell (37:35):

Two things I'll add, right? I'll justify this a little bit because I'm having a hard time being humble right now, <laugh>. But first and foremost, what they're doing today is not great at all. And so this is better. We're building something at relatively low cost for them so that they can prove out that it's gonna be a great system for their customer,<affirmative> and then they'll invest and make it a better user experience. But then the other thing to note about the form specifically in that process is if they go through the correct process from point A to point D, let's say the first form submission is intended to get a back-end review by somebody who looks at it and says, Yep, this is good. Now I need more information. And then that will trigger an email to say, Hey, go fill out this form, upload these files. So it's not completely as bad as you characterized it, but it is definitely not ideal.

Josh Everingham (38:25):

No, that definitely does sound better, but it's still in world still ideal. In a perfect world, you should be able to just drop a file and app right before you click that submit button, right? Anytime a user has to break the window that they're in, we run the risk of losing them. Yep.

Mitch Herrema (38:39):

Yeah. It's see how it goes in the future, but works for now. All right. So I think that's it. I think we covered it all. Yeah. Well, let's wrap up. Josh, really appreciate you coming in and hanging out with us for a little bit. It was fun to chat user experience. I'm sure we will revisit the topic again in the future. So yeah, if you're listening, we'd love to hear your feedback and any questions or comments you have on this topic that we can dig into in the future. Thanks for listening and we'll see you guys soon.

Josh Everingham(39:10):

Thanks for having me and see you guys soon.

Mike Bodell (39:12):

I wanna say a special thanks to Josh for helping make us successful

Josh Everingham (39:15):

<laugh>. Thanks, Mike.

Mitch Herrema (39:18):

Hey, thanks for joining us today. If you haven't already subscribed to our show on your favorite podcasting app, so you'll always be up to date on the most recent episodes. This podcast is hosted by the team members of Bulb Digital, and special thanks to Eric Veeneman for our music tracks and producing this episode. If you have any questions for us, head to makeotherssuccessful.com and you can get in touch with us there. You'll also find a lot of blogs and videos and content that will help you modernize your workplace and get the most out of Office 365. Thanks again for listening. We'll see you next time.

‍