 So, thanks for coming. I have a really studio in the back of my house where I do most of my work and so I don't ever see this many people at one time ever. So, I'm a little bit nervous. I want to, before I get started, if there's any back channel conversation about what I'm going to say, just go ahead and tag it with Meta app and then I'll be able to kind of follow up and participate. So, about me, I'm an entrepreneur and a designer and a hacker. I was classically trained as an artist in New York. So, I made the transition from painting in oils to coating was kind of a fun little trip but the thing that I found really useful about that was it was easy to get beat up in art school because people just rip your stuff up and then to go to try to work with a client when they don't understand what you're doing or they haven't communicated well and they can rip you a new one and it's not that much of a big deal. Now, I run a small company with my business partner named Peter Blue and we primarily focus on behavior design and health care and I'm happy to talk more about that another time. So, the first thing as a speaker I want to say thank you to all of you guys. Not only for being here but it's been a lot of time on IRC over the past 10 years and you guys have helped me out at 2 o'clock in the morning when I'm trying to figure out a problem and literally if it wasn't for you guys I would not be able to feed my family and I would not have I would not have the opportunity to pursue the passions that I have. So, thank you very much and I'm hoping that this is a little bit of a give back for you guys. So, how many of you guys are building your own web apps for yourself or for your own startup and then how many of you are building web apps for other people, clients, that kind of stuff. Okay, a little bit. Good. Okay, cool. The things I want to talk about today are not necessarily about building another social network or another analytics tool or another way of connecting Twitter and my whatever music I'm listening to you. And if you're working on those things I apologize if I've offended you but I want to talk about finding real-world problems and trying to provide solutions to them. I think that there's a couple really key things about the stuff that we need to work on and how to help those problems be solved. As an example, obesity in the United States is a huge problem both financially and from how it affects the people that we know and love. It's a big contributor to diabetes, heart disease, stroke, and cancer. A five minute Google search will show you all kinds of stuff to get you excited about helping find solutions for obesity. It's $190 billion a year problem and this is just in paid medical costs. This isn't even around lost productivity or anything else. This is just what we pay in the United States around medical care around the problem of obesity. It's a $14 billion problem in children alone. It's a significant deal and one of the things that can really help in dealing with obesity is simply going for a walk. Getting up and moving around. A lot of literature that we'll see will be exercise and I made the argument recently that exercise is something really hard to get users to do because if you do a Google search right now for exercise you're not going to see anything in there that looks even remotely like what you look like unless you're like one of the one or two percent of us who are really in shape. The stigma around what exercise is and how it works is a really challenging thing to overcome especially when you consider things like gym advertisements as you drive around your town and you look up at the billboards. I don't know anybody that looks like that. I would like to but I don't. I think the idea of walking or it's just simple movement is something that could have a huge impact and could really help fight the problem of obesity in the United States. Of course we can look at high sugar drinks and all that other stuff but the reality is that going for a walk has other implications as well. It helps offset depression which found that 47% of folks who deal with depression going for a walk helped to decrease their reported depression score. So moving around and having some sort of movement is something that could be done and would help a lot of people and I think that in this room we're uniquely qualified to provide tools that would help people be excited about getting up and moving around. I think that there's some pretty awesome things that we could be doing as far as gaming is concerned. Just basic email using the who sort of Django drip library. So we're using that as a tool. You can create an email group campaign on whatever app you're using that will remind users that they want to come back to the application and use it so that they can continue to get up and move around. There's all kinds of stuff that we could be doing. There's a lot of problems that need our help. I will bring unique skill sets to be able to help them. Mental health, poverty, education, social justice, the environment, women, warriors and many many many more. These problems are all in the domain of being able to change behavior. So if you can create an application like a game that changes people's behavior perhaps you can do it in a way that would benefit them or benefit society. A business partner and I have a little passion project that we're working on for fly fishing. And it's really just a simple fly fishing diary. We live here in the Northwest. I'm way more comfortable on a drift boat on the McKenzie than I am standing up here on the stage. And we built this app so that we could start to look at ways to collect data and make those data points more accessible for other folks so that they can understand how the fishery health is, the river system that all around us. So building things that matter, building things that can actually change lives or have a real positive impact are something that I feel like we're uniquely qualified to do. The problem is if no one uses it, it's not a solution. If you build an application and no one uses your app, then you haven't really solved anything. If you build an application and you get that first thousand people in and registered and then you have far off after say two weeks, three weeks, how do you know that you're actually affecting behavior? So if we agree with those things that we could be doing to really help change people's lives, then what we need to really look at is adherence to our solution. So what I want to spend the rest of the time talking about is the idea of how we build a process that enables us using Django tools to keep people excited about the application and making sure that they stay engaged. So this is obviously a graphic that I created to just kind of illustrate our process. It's a pretty simple process and it's designed to be simple on purpose. Our first stage is a sketch phase, second one is prototype and the third one is build. So we obviously, this allow this is going to be really kind of base level. You probably already have gotten all this stuff. But the sketch phase is designed, I'm sorry, let me get back. The sketch phase is designed to capture the ideas real quickly and easily. The prototype phase is designed to deliver something that people can play with. Sort of like if you took your sketches, you're working on a painting, you took your sketches and handed it out to people and said, you have lines to it as well. And then the build phase is where we actually build the application. When we begin sketching, there's three things that we try to focus on doing. Because otherwise, who are we sketching for? Maybe our own curiosities or whatever. We need to make sure that we have users. And this has been something that we've talked about in the projects that we're working on pretty consistently. There's nothing about me without me. I wish I had been clever enough to come up with that. But this was actually brought up in a seminar. And the idea is that if you're building a tool for me and you don't include me, then what are you doing? There's no point in continuing with your application if you're not including me in the process. And by me, I mean me as a user. So one of the things that we really focus on and spend a lot of time on is identifying what the problem is and then what the solution is. I'm going to do that as a good lean startup or running lean or any of those. Okay. So I would strongly, strongly encourage you to go out and get those books. There's some really great practices in there about identifying whether or not we're actually solving the right problems when we're building software. I'm going to say this a couple of times. You guys and us as developers are pretty intimidating people often. When we work with our stakeholders, when we work with our users, we know a lot of things about specific pieces. And it's sometimes it's a real challenge to have a conversation with us. So we might look at something and say, oh, I seem to have developed a solution to this. Well, I know what the problem is. So I'm going to go solve it. And then if we don't encourage users for participating in a conversation with us, and we end up kind of drifting down the road, a rabbit trail and building something that doesn't actually work. Um, doing this, if you guys get running lean and read through that book, I think you'll find that there's some really great methods in there for validating what you're trying to do before you actually do it. A couple of years ago, we were working with a client who we've had a good relationship with. This was about the fourth year of working with them and they came to us with an idea for a new project. And it was pretty exciting. It was it was going to be an aggregation tool that did a whole bunch of cool stuff. And they were starting to allocate budget to it. They were starting to build up the kind of the internal political approval. And we're all set ready to go. And I said, I just finished reading this book. And I said, well, let's hold on a second, let's make sure that we're trying to solve the right problems. So we propose we work with the stakeholders and we propose these are the three problems we're trying to solve. And we sent that out in the survey to their constituents. And these Google forums and they went through and rated all this stuff. None of the problems came back as rating higher than say at three, a scale of one to 10. And it was a good thing that we did that because what ended up happening was because the stakeholders said, well, we're not going to allocate this money towards this if we don't know that this is a problem that actually needs to be solved. We perceive it as a problem, but our users don't actually see it as a problem. They have a whole different set of problems which came back as a unique opportunity for us to take advantage of. So being able to identify what the problem is is super, super important. Using Google forums to do this is one way. Obviously user interviews is another you can sit down with users, talk to them, talk about what are the problems that you have in this regard. If we go back to the walking idea, what prevents you from getting up and walking around, what are the kinds of things that you could do that would offset or give you the opportunity to take a walk that maybe you hadn't thought of before? So having an understanding this problem piece is 50% of what you need to understand before you start. Another 50% of it is what's the solution? So if you can get an agreement from the people that you want to solve a problem for, you can work with them, they can help you identify on a priority, what are the top three things that I need to solve, no problems that I have, and you can create solutions for this. And this is just Google forms, right? It's just, you just type and stuff out. You haven't done any code yet. You haven't done any drawing, nothing. You're just talking with you, you're dialoguing, you can develop some solutions coming up with ideas, and you can use this now to develop your product. This may suggest to you what your primary function of your product is. When we're looking at the side fishing app, one of the big problems that I had was I would come off the water, and three days later I couldn't remember what had happened, never mind what I had been doing the year before. I had no way of knowing what the population difference was between one year and the next. Fishing reports are, you know, not very good for that kind of stuff. So identifying what the problem was, we talked to a bunch of other fly fishing folks and we asked them, what are some problems? Well, I can't ever remember what's happening. I know that I have these flies available to me, but I don't remember when I'm supposed to use them. So the solution was, well, it's a simple value, yeah. You just track what you're doing, select the weather, some basic science stuff, and then you've got the information that you need to do. So coming up with a solution was based on specifically what the problem was. For another project that we're working on right now, I'll manage my fatigue, we're working on developing an app that helps people manage their fatigue levels, specifically to start folks with traumatic brain injury. So we needed to be able to look at what are the problems that people have when they're trying to manage their time. Energy retention or keeping their energy levels up is a real struggle for this population. So knowing how to identify what were the problems. Something simple that I may not have come across was I need a visual cue that tells me when the timer is up. Not only do I need some sort of messaging, some haptic response or something like that, but I need the screen to actually change so that I notice something's happening. Little stuff like that. So these are different pieces that come out of first identifying the problem and then identifying the solution. The last little piece of this is building user advocates. These are people who in essence, as your users, become your friends. In all honestly, you develop a trust relationship with them, you ask them questions, they give you the feedback. You need to have it thick skin because if they're honest, they'll tell you when something you're doing sucks or when something you're doing is great. User advocates are somebody that you can go back to consistently. They'll be your early adopters. They'll be the people who are passionate about what you're doing as well as you, but they maybe don't know how to write code. Often they have a vested interest in knowing that this thing works for themselves. So they will work with you and are much more tolerant of the mistakes you might make in your assumptions as you go along and are happy to help set you on the right road. Additionally, these user advocates are somebody or is a group or a population of people that are going to stick with you through the whole project, beyond just your initial launch. They'll continue to still with you. They'll be excited for you. They'll continue to provide you feedback. These are the folks that you'll get an email from at midnight or four in the morning, hey, I thought about this or hey, when I did this, this didn't work, et cetera. Or you forgot to turn the bug off and now I'm getting code on the page. The sketch phase is about pretending. If you identify the problem, come up with some solutions. The users agree, yes, those are great solutions. Those are things I'd be excited about. The sketch phase is about pretending that you have the thing already. So your wire framing, how many of you guys actually wire framing your projects? You wire frame out views and that kind of stuff. This is incredibly inexpensive. If you're not doing it, you definitely should. This allows you, even with just a piece of paper, to draw out what you think the view is going to look like, maybe what the form is going to look like, what the feedback potentially is going to look like. This will save you so much time and effort. You can use Google drawing if you don't want to just sketch and you're afraid of doing a sketching. I'm a big fan of a service called Brassomic. I have no professional relationship with them other than I'm a paying customer. They've got a great set of tools that you can build together in UIs in a matter of minutes because they've got a library of different kinds of widgets. The principle is not, this is my design I'm giving you. The principle is this is a potential experience. Can you use this? That's why going through this process, using this piece of it, is a really, really important part. You can get users and build momentum by doing this. So if you have your user advocates and you start testing this stuff with them, ask them to share it with other users so that those folks are also excited about what you're doing. This is a screenshot of the timer piece and as I was referring to the left, you see the normal countdown timer and the feedback we got was, I need some sort of visual cue that the timer has changed so we turn the screen red under five minutes. There's some assumptions I made as a designer in this screen which turned out to be wrong and it's a lot around the icon, iconography, all across the top, on the left and the right, and on the bottom left. There's a lot of icons on the screen and just if I was so, it's a mobile view, I need to fit a lot of information and functionality into a small screen. Problem is, feedback came back, I don't know what these icons mean. I don't know if you guys have struggled with this or not. I recently wrote a blog post saying to get rid of all icons, strip everything out as much as you possibly can because there's no common vocabulary around most icons. Most of the icons we look at are interpreted by the designer and the team that's building it. They're not based on a universal principle of understanding. There are a few, yes, but most of them, I would argue, are not. If you use this process, you can iterate quickly. So I can draw a sketch, I can put it in front of users and say, what do you think? I've even done things where I've drawn something out, taken a picture of it with my phone and emailed it to them. Tell me what you think of this. That can go very quickly. This is useful because you can build momentum, like I said earlier, you get people excited about what you're doing, you're responsive. So if someone tells you something, you can push that right back to them. If you have, say, a user advocate group of around five users. If you have more, say, 20 plus, you can synthesize all the feedback and you can say, this is what other people are saying. Here's all the different stuff, the feedback, all the different input I'm getting, and then return that to the user so that they have something that they can understand. Making it accessible is super important too. How many of you right now, if you had to, could actually type out your base camp password if you're using base camp? So a couple. Most of the users that I am working with have hard time even with login screens. And not because login screens are necessarily difficult, but because they have so many services, how am I supposed to remember what this password was? So while I really, really, really like balsamic, the login process is difficult for some of my users. So if I give them access to some screenshots, they have to log in and in order to leave their comments and I will often get emails I don't remember my password. They're emailing me because I'm the face that they're interfacing with even though there's a root. I don't remember my password. Same thing happens on Django apps. So I'll back stuff up with a PDF of the of the actual wireframes in case that happens. I can send it off to him in the meantime while I help figure them out. And I can even just use raw HTML. I worked on a project for helping kids with depression talk to their parents about depression and we built a game. And when we initially got started, there was a lot of things that we were trying to figure out and almost all of our prototyping that we did was all just raw HTML with no styling. Because all I need to do is understand what would happen if the user, I mean all I needed to know was does the user understand what will happen when I click something? Do they do they get the idea that I can do something and then something happens? Right? So that was easy to accomplish with just real basic HTML. Then it's got to be fast. If it takes a month to connect with your users, send them stuff, process it and then get back to them, your users are going to lose interest and or they're going to forget what they were already working on with you. So you've got to be fast, you've got to be responsive, you've got to get back to them quickly. I had a good fortune of working with a guy named Rob Hudson and a guy named Percy Perez. And I wish that this idea was my unique awesomeness that I came up with, but actually it was these guys. And at the time I was a designer just doing fun and design. And these guys were really smart, younger folks and we kept having this problem going back and forth around. I wanted to do this, but I want the functionality to be x, y and z. And they said, I don't know what you mean by x, y and z. I'm like, well, what do you mean you don't know what I mean? It's right here. Look, you can see in the Photoshop cop. It's all really clear. And their pushback was, I don't know what it actually does. Right? So I don't know what kinds of things I need to do in the background. So we switched. And they said to me, you build me a template first and then I'll do the modeling after. And I'll create the views and all the beta models based on what you give me as a template. And I hope I'm not outing them. But that kind of turned my whole grade around. So the idea is that I'm not going to start with my data set. I'm not going to start with my views. I'm not going to start with my URLs. I'm just going to create a basic template. I'm going to start there and start showing the things that I want to have that one on the screen. For that reason, I'm sure there's different, I have forgotten by now, but there's different Django starter kit libraries. I just usually start with just the basic Django install and then static files and fat pages so that I can start building stuff out and getting access to the templates and start iterating in front of users. So it's so quick to be able to, you know, I don't have to do south migrations or whatever depending on the version you're on. So I can build out the templates, modify my HTML, make it do stuff in front of my users, have them give me feedback and make changes. So this is something instead of pair programming with another developer, I can pair program with my user. We can sit there together. Obviously, they're not programming, but we can look at what I'm doing and say that makes sense. It doesn't make sense. Move it up here. I don't understand what you're doing, et cetera. And then some of the front end frameworks that make this, you know, go quickly for the bootstrap Gumby Foundation. What you think about those as far as a front end development framework for later on is a is a different question. For me in this phase, it's really about do I have the solution nailed? Does the user experience makes sense? When a user clicks on a button that says add note, does that experience feel right to them? Are they excited about what it is that that's happening? The thing that I did probably about is I completely stopped using Photoshop or any other 2D mockup tool at all. And the reason is I cannot get the same feeling and the same experience in a 2D mockup that I can with a template or something that I can click, especially if you use responsive design. Using responsive design, you can build a model that works on a phone and is accessible by a URL. So you click it, it does something. You click it again, it does something else. I can't emulate that in Photoshop. So what I found was I was spending a ton of time and effort on my mockups to communicate all these different views, you know, inboard messaging, onboarding system, you know, all kinds of stuff. It just was not working. I figured, gosh, if I just get rid of Photoshop and stop doing that all together and just jump right into the HTML, then I know that I can be able to communicate things quickly and easier and get the feedback I need in order to keep things moving. And so far, we haven't regretted it. It's been a really positive experience not using Photoshop as a mockup. It's for doing mockups. Yeah, if I can't touch it, it doesn't exist. And again, another reason to not be using Photoshop. So if I can pick up my tablet and do things on my tablet, if I can pick up my mobile device, or pick up my laptop, whatever, and actually do something, even if it's completely fictional, that gives me better feedback than having to use a look at something and pretend to click it. Has anybody heard of heap analytics or kiss metrics? A few people have heard of kiss metrics. So, kiss metrics is kind of this awesome data opportunity. You can use kiss metrics to track all all kinds of stuff. For instance, let's say you have a tool and you want to do a conversion from a user who's registered all the way through a fulfilled shopping cart. You can build a funnel report in kiss metrics that tracks the entire experience for a specific user and tells you where they fell off. So I've used kiss metrics to look at online education programs for advocacy stuff for, for instance, traumatic brain injury. And we knew that at some point users were falling off. So the idea was we wanted to identify what was causing that fall off and we used kiss metrics to look at the data and come back. Heap analytics I think is relatively new. And what they've done is they've kind of done this similar thing for free. So you plug in a little JavaScript on your HTML and you can use this on your prototype or your actual build. And you can look at the data and all the fall off and all the different conversion rates, et cetera. It's pretty awesome. If you remember, I'll show you the screenshot with icons. Feedback we got was I don't understand how the icons work. This is a screen graph from the alpha version of the app, the management fatigue app. And we converted to text for navigation. And it's been way more useful because users aren't stumbling over what the icons mean. You don't have to learn a second vocabulary as long as they speak English or can read English. So they can use this app and jump around and can see things quickly and easily. And there's much less cognitive load as far as we'll perceive cognitive load as far as trying to understand how the UI works. I said, using templates and Django Floppages, I just install, you know, do a basic install, get things built up. You can start building your UI off of Django Floppages and building your URLs. Okay, so I just recently started using Angular on my front-end. And basically the way we do stuff is we use Django for all the back-end stuff. Then we use Django REST framework for the API. And then everything else is done in Angular in the front-end. We're still working on user authentication because that's kind of a tricky way to do it. But what's cool about this is the work you do in getting your prototype ready is actually building your app if you're using one of these front-ends. So you can emulate all your data stuff with JSON, just like you would fixtures, and you create your JSON data, set it aside, and do your API calls against that JSON data file. You still haven't built any data models. You still haven't messed with anything on the back-end of the database. It's all just in the front-end. But you can get pretty damn close with this. And to be honest with you, I have a little ball. I actually love doing this stuff. I haven't done a little reading on Ember and haven't played with it much. And I left back bone out since I thought it was Angular. Okay, so build. So you've integrated this with your users. You've put out releases. You can set up an HTML, just fatic site. They can access stuff. They've played with it. They've given you feedback. And now you ship it. And that was strongly, strongly, strongly encourage you to use something like heap analytics or kiss metrics. Plug that in. And now you're starting to integrate not only with user feedback, but with user data. And I can't tell you how many times I make assumptions about how something works or what the user experience is, only to have this data show me that it's completely in the other direction. I'm a big fan of Django REST framework. I think it's a fantastic tool. But one of the reasons I love it more than some of the other API tools is because of this. So I can build an API and play around with stuff. And I can test alternative methods. So obviously I'm in the build phase now. So I'm building my data models. I'm you know, getting real database stuff moving. And I can build my front end at Angular or whatever, however I do it, old school Django or whatever. But this tool gives me the opportunity to have a whole other interface that shows me alternative views. What's neat about this is I've actually shown clients, I'm sorry, now clients, users this view with the Django REST framework. How many of you guys are using Django REST framework? Okay, sweet. So I've used this with other users, Saturn and Futter. And they're like, oh, yeah, I can see you get a list view with the creation thing. You have to translate a little bit for them. But it's gonna be a useful exercise in how do you want this to work. And in fact, this method I used on a recent project where we had a list view of stuff. And because it's a single page app, I was able to make the ad screen and the list screen in the same view. And the user really appreciated that because they didn't have to go back and forth between page refreshes. And the idea came from how those are set up. I think feedback obviously is really important. I highly recommend you systemize it somehow. Depending on your population, GitHub can be really useful. If you do use GitHub, you need to know that they obviously have to create their own account and need to work through them. What does it mean to submit a ticket and how do I make it useful? Google Forms is another great tool. I use Google Forms all the time. Really, really, really like Google Forms. Jango Feedback is a side project that I had a while ago. It's pretty outdated at this point. And the reason is I had a whole project and when I end now I end up doing is it stopped asking the user to please tell me what browser they're using, what version, what all those other things. And just when I have any feedback form that's integrated into my systems, I'll now just add in that second line and I send myself the user agent and it tells me everything I need to know. So, well, most everything. And then they'll give me the feedback. So when I get that email, that feedback email, I get their note with all their user agent stuff. It's easier on them because they don't have to worry about translating something that they don't necessarily understand. I highly recommend that you try to keep data collection as simple as possible, at least in the beginning, to use one service for data, one for feedback. If I added one more to this, it might be one for monitoring like New Relic or something like that. But try to keep your data sets as small as possible, because those data sets will grow quickly, especially if you continue to solicit feedback from your users and they're excited about what you're doing, for instance via Google Forms or something like that, you'll collect a database with lots of records and lots of feedback. So the process we use, scratch, prototype and build has been really successful so far. We've had a lot of good experience with it. We've saved a lot of time by cutting out some of the Photoshop stuff. And by replacing it with live templates that we're building on has been really useful. Special off of you guys, I built templates for both the problem and solutions interview piece. If you're interested in using those in your own work or taking them and running with them, you can just go to www.daymoment.com slash email sign up, send me your email and I'll send you the problem and solution templates. Okay. Any questions? Are we doing on time? Oh, sweet. Okay. Any questions? Any other questions? Thank you very much. That was a very salutary advice. I don't know what you think about this, but one of the things that shocks me most about software developers is how often they don't use the things that they're actually building themselves. So they are entirely reliant on the user. Whereas if you build something and you are also the user as well as the builder, if you've got to live in the house that you built or eat your own dog food or whatever metaphor you like to use, then that loop is very much tighter. And I think it should be compulsory by law or obligatory for developers to use this stuff. And you're not even allowed to develop something unless you're going to use it. Yeah. So my thought of what you say is do developers eat their own dog food or lack of a better term? I definitely agree. I think that we do need to use the tools that we create. One of the things that's really challenging is especially with most of the populations that I work with, there's no way, even if I use the tools, that I'm going to completely understand the problem set that they have. This past spring, I got to be in Coastline Community College where we were testing to manage my fatigue app. And I sat in a room. We had three, I think three sessions, 20 students each, or traumatic brain injury. There's no way I can fully understand what it means to have a traumatic brain injury. So I would definitely agree. We need to, you know, eat our dog food, but we also need to become friends with our users because they're going to communicate to us whether it's easy the first time or not, what it is that we're doing and whether or not it works. That makes sense? It must be easier to be your own user when you're writing a CMS than something like that. Correct. Thank you very much. So it seems like you're doing a lot of user-centered design, which I would love to see all companies do that. My question is, did you ever need to account for users' bias? I mean, you know, when Henry Ford said that people ask for a faster course, did you ever have to account for people giving you some solution that's not necessarily the best? Yeah. So the question is, do you ever get recommendations that the question is, do you have mechanisms in place to compensate for these bias? Or maybe you just never needed to because your users are. You select your users in a particular way so that? No. So for us, one of the challenges is we get a lot of really good feedback. So managing all of it is about time and budget. So many of the things that if they're not in that specific problem set that we established in the beginning, then we backlog it and figure out when and if. I've actually taken things out of that and put people in front of my users and said, hey, what do you guys think about this? Right? This may be a really good solution for more users. How does everybody else think about it? Is this something that we need to consider? Do we need to change our priority? So it's just about conversation. I used to work at a university where I built for them and I was the biggest user of them on this. But we had another 50 or so users who were also collaborating on content. I was in quite a fortunate position because even though my users were often wrong about how this should work and what it should do, I was also the most important user, the biggest user in the system. What do you do when actually the feedback or the desires you get from users doesn't follow best practice or isn't actually going to do the things that they think it's going to do or your users want things that they should not have? Yeah, so that's a really good question. What do you do when your users make recommendations that either they might be flat out wrong or they might be recommending something that's not in their own best interest? For me, it's about being able to dialogue with them. It's about being able to, if you have that trust relationship then you can say to them, no, that's not a good idea. Or if it's really important and you don't understand, which I think is a big issue a lot of times, is help me understand why this is important or is there something else that we can do that helps you accomplish what you're trying to do without actually compromising the law or violating copyright or there's a lot of misunderstanding. I've had people go, well, why can't you just copy the source from that page, put it in that page and it'd be good to go? Well, because you're stealing someone else's IP and you don't look good when you do that. So I'll build that trust relationship. That sort of reminded me of a similar question of some of the things we find is extremely difficult is taking features away. She put a feature out there and it's really hard to tell a user that, you know, you can't do this anymore. Do you have any experience or thoughts on how you can do that in this process, in that one? Yeah. So the question is, how do you take features away or avoid the issue altogether? For me, it's really goes back to identifying the problem solution set. If you only have three solutions and you try to make those solutions as simple as possible and that restricts the amount of stuff you actually produce. So the fly fishing app is a great example. We wanted to do all kinds of cool stuff like geolocation and, you know, go on and on and on. The reality is it was cost prohibitive to do. And if I had released that as a feature, I would not have been able to support it. SMS messaging is another thing that we'd run into a lot. We would love to be able to implement SMS messaging. We have the code to be able to do it. However, if you implement that, you now have to pay for it. So there's an unforeseen budget ramification. So for us, it's about shipping things that are as small as possible. When it does come time to actually have to remove something, that's a marketing opportunity. If you can take the time and justify why you're doing what you're doing and explain it well to your users, is you another chance to connect with them. You may piss some of them off. However, you do get to have an honest dialogue.