mergeconflict236
James: [00:00:00] Frank. Here's what I want to talk about today. I want to talk about supporting your application. I want to talk about good support and why it's so important in not only shipping an application. But also putting information into your application to help diagnose when things go wrong. Does that make sense?
Frank: [00:00:33] Oh, yeah. Oh yeah. This has been on our list for a while. And I remember that I liked to talk about it because James, I think I'm going to get a little feedback for this one because I don't think I do a great job at support, but I do as good a job as I personally can. So, but it's definitely a topic that I'm so interested in because I know I don't do a good job.
So I'm always looking for ways to do a better job. That's not going to completely. Break me. So I, I I'm here for this. I'm ready for this episode. 
James: [00:01:04] Good. Because we've maybe talked in the past about websites. Like, you know, I have a, my Caden's website and Island tracker website, and I have all these different things and you know, most of my applications that I ship and to some extent, maybe some that you ship, but I think your applications.
The gears are very file-based. So you could like have someone send you the file and you could try to diagnose it, but there's other things that could happen. I feel as though, like some of my applications are simplistic, so it's like, okay, well the app just works because it does these things. But with my cadence, like the problem I have is that there's, you know, like you said, early on, when we were talking about building this app is there's hundreds of sensors that people can get.
And some of them have some sort of data, some have more data, some have less data. Like I can't buy every single sensor in the war. Right. I can't buy every single device to test it on in the world. So how am I going to attempt to get and. Give the type of support to my users. They deserve because literally within the first week I had people reach out to me that had like bike speed and cadence sensors, like on a road bike, and they're trying to use it.
I had people that had fitness equipment that were attempting to use my application. Um, I had people that bought these really, really cheap, like, you know, sensors of companies I've never heard of. And the entire world, actually, most of them are that, and they all are supposed to work the same. Right. And, um, and then people have these really old sensors.
Like the one I bought, I had to buy off of eBay, uh, because they don't make this anymore. And this person look at me, they email me, like I have this sensor and it doesn't work. And I was like, Oh my goodness, why doesn't it work? I guess I'll spend eight 99 on eBay and eight 99 on shipping to get it to my door, uh, you know, to try to do that.
So there's sort of different levels of support. That is needed and I've learned very quick in the last two weeks, how to make it more streamlined in my application. 
Frank: [00:03:06] It's so funny because when you're talking about these sensors, so I guess this is like episode four or five and the great sensor Epic that we've created.
Sure. Um, but you are reminding me of at least my early ice circuit days when I was validating the simulator and. The way that it just felt most correct to me was to validate it in hardware. So I would go buy every single part the app had and I would test the part out physically and make sure that my simulations matched the part and.
It got expensive because the stupid app supports something like 130 parts and I would have to go buy those, figure out a test set up and all that stuff. So this is all me trying to say, I had it worse than you. So stop complaining. I'm just confining it. It's terrible. I'm just kidding. It's terrible. When you have to go to eBay.
To buy some old hardware because like, what's the real, what's the real benefit. Is there one person with that hardware out there or are there a hundred people with that hardware out there? And I hope to goodness, you're listing out all the hardware in your app store description. So you're getting those search terms and SEO stuff for you.
That 
James: [00:04:20] is, um, uh, that is a side effect. By the way, is the more you learn about what your customers are doing and using with your application, the more SEO effication you can do. In fact, in the most recent update of my cadence, I even, I even put that in the update description. It's like, and now it's almost like a feature, right?
It was a bug, but now it's a feature it's like now it supports who SPU and tracks and just Schwinn IC fours and, and, um, and. I think that's sort of a nice little like, Oh, interesting. Like they're adding more support for more things, even though it was like totally a bug on my fault because I wasn't checking bit flags, but whatever, you know, for me, I totally got it.
Um, but yeah, you know, the hardest part is that diagnosing problem in the applications and my application that I have, you know, we've talked about analytics and crash reporting and that's one type of support, but that's actually not the support I'm talking about because what. I really am trying to accomplish with these users is almost like, Oh, can I just like remote into your machine and help you out?
You know what I mean? Like when someone's like, my computer is not working well, let me just remote into your machine or start a zoom call and share your desktop with me because what I need is I need a, I need a person to. One stick with a stick with me, right? They need to like have a problem, report the problem, and then work with me on testing applications and updates and beta tests, which means I need to opt in to test flight.
They need to opt into Google things or whatever, you know, and that is, is one part of. Of support that I didn't realize that I could take advantage of. I literally have on my test flight, I have all these groups and one is a  group because I'm like I'm putting out releases for different people to try to test their application.
Have you ever done that? 
Frank: [00:06:22] I haven't ever had to get that narrow. No. Um, yeah. I usually have a small trusted friend group and then in everyone else, group kind of thing like that. Um, but that, that's very clever of you to use it that way, because maybe you don't want to barrage everyone because when you put out a new release on test flight, you don't actually have to distribute it to everyone.
So yeah, that could be totally clever. I like that. Um, it's funny though, like people find the most interesting ways to contact you, even if something's missing, I've had people, uh, actually find my company's phone number and give me a call. And in some ways I'm a little bit terrified from that. Um, but, um, when it came to actually diagnosing the problem, there's really nothing more efficient.
And we don't have, we don't have good support like that. Right now, what we have is email and Insta bog, someone leaves you an app review someone, tweets you. Um, yeah. You know, th th those are the avenues. It would be kind of nice though. I don't like the intrusiveness. If there was just a magic button, someone could press and their screen just came up on my computer.
Probably don't actually want that, but to deliver good support, you need something like 
James: [00:07:38] that. Well, I, I agree with you. I feel as though it, it is something that I wish that the main operating system. Like, Oh, as an app store could handle, because I think how a lot of people originally found my contact information was they went to the app listing and there's, there's like, there is a button that says like app support and whatever your email is, it will find it.
But the funny part is, is I actually had to going to a support website that had a different email address. That I wasn't monitoring. It was my, I must buy this domain name and email because Apple requires me to have a@refractor.com email address. So I was sending them there and now I've set up auto forwarding to my, my refractory Gmail.
But then I had had someone actually reach out on two emails, my personal email, and also my Twitter account. I was like, how did you find all this information about, I guess you just Googled James Monza, Magna or my cadence. And like, of course my name pops up, but it's, it's. Yeah, that's a good sign, actually, that, that person wants help, you 
Frank: [00:08:40] know?
Yeah. Yeah, absolutely. And I put my number out there. It was a public number, so it wasn't like creepy or anything. I was just shocked. I was like, Oh, there's an actual human here because you know, it's so detached email and issue reports and everything. I'm like, Oh, there's a person here. So that was fun. Um, if I could, should we give like real quick recommendations?
I, I feel that. Email is still the most common form of support that I get, but something I've really been enjoying is, and this is, this is not new, but we've never, I don't think really talked about on the show is that you can reply to app reviews now. And I noticed that a lot of people use app reviews for support.
Now it's not just, here's a review of the app. It's more like here are 10 things I wish you would change about the app. Here's one thing I absolutely hate about the app, uh, four stars and you're like, okay, now you can actually hit reply and be like, thank you. Thank you. Yeah. I plan on doing some of these.
Some of these are hard, uh, and I'll totally fix that thing that you hate. Uh, please give me a five star, but no, I don't. I don't ever say that part. 
James: [00:09:49] So that's where things started with me as was reviews. And I put into the application, you know, after the user uses it, X amount of times do a review pop up.
But after that, I. Um, was looking at my reviews and this is something that I highly encourage everyone to do is one I installed, um, on, at least on iOS, you can install the app app store connect app. Is that what it's called? The app store? Yep. Connect after it's it's okay. It's fine. But you know, it at least shows you all your stuff in real time.
There is a Google play council. One that also does the same on the browser though. They will actually recommend it will recommend phrases for you to reply back with, for Google, which is crazy. Like machine learning ones like with your contact information. Yeah. Okay. 
Frank: [00:10:36] I'm sorry. Uh, interlude here. I've kind of always wanted that from my support app because I love people.
I love all their feedback, but if I put a bug in there, I get 8 billion reports, the same bug. And at some point you want an auto-fill. So that's a little bit. Creepy as an all things Google does, but at the same time, I've been wanting that forever. So congrats, Google. You got 
James: [00:10:59] it. So, so here's one review.
Okay. So these are, these are people I'm working with. So Caressa she wrote does not pair with my cadence sensor. That was one star. Okay. And then here was the auto response. I literally just hit reply and then they gave me options here. This is machine driven. With the, this is the only context, right? 
Frank: [00:11:22] I heard it and I love it.
I hope it's really robotic. Please be really 
James: [00:11:26] robotic. Hi, we apologize for any issue you may be having. Could you please, could you send details of what you're experiencing to our customer support at refracted, llc@gmail.com. We'll get you up and running. And then I added, if you can send over the specific sensor that you have, that'd be super helpful.
Frank: [00:11:44] That sounds like a form response. That doesn't sound like an AI. I would get very angry. I don't know. That's basically hashtag needs info, check this out. Every, every bug gets needs info. I don't know, but 
James: [00:11:56] like, okay. Okay. Okay. Okay. Here's the next one? Four stars, easy to install and use. Thank you for your comment and glad you're enjoying my cadence.
Is there something else that we could do to deserve a better rating from you? Let us know 
Frank: [00:12:11] now, whatever you don't come and name there's nothing said there, there is nothing contributed to that person. Uh it's it's an unneeded response. Do another. Okay. Okay. 
James: [00:12:22] So here's one that I haven't replied back. Five star review works great with my sensors.
Autoresponse thank you very much for the five star review. I like that. Uh, we are pleased that you enjoyed the app. If there's anything else we could do, please let us know. Refractory llc@gmail.com. Have a wonderful day. Thank you very much for your feedback. That was the third one. 
Frank: [00:12:42] Nah, I don't like it, whatever.
James: [00:12:44] Oh, how do you know? You don't like it? You don't have to use it. It's optional. It's optional. 
Frank: [00:12:48] Sure. Right. I think in this case, like those ones, you just don't reply to you. Don't reply to someone who just says a positive thing other than thank you. No, that's the 
James: [00:12:58] extent. But in, in, in doing so regardless if the automated ones or the non automated ones are good.
Let me tell you, I did respond to the one person that gave a one star review and said it couldn't pair. And they emailed me back because what happens is they now get an email. That says it's this person replied, they emailed me back. They sent me a screenshot with like the sensor they're using. I was like, Hey, this is like, thank you so much.
This should work, blah, blah, blah. I'll give it a purchase and I'll let you do you know how it goes? Right? Like they totally email me. Yeah. 
Frank: [00:13:33] Cool. Yeah. So it works. It totally works. I like it. I just get worried about those one stars cause they hurt and it would've been nice to get the email before the one-star, but absolutely I do.
It's funny how systems adapt and there isn't a unified support system. Like it's kinda too bad there isn't like the app store could have just had a support system built into it, but they don't. So we're abusing the review system to create a 
James: [00:14:00] support system. Okay. Like in an ideal world, the app store would have been like, Oh, you're giving this a one-star is something wrong?
Try to contact support first. Yeah. Something like that. And ideally there would be something that's built into iOS where I could figure that out, but no, it's completely separate. So here's what here's what's happened is since I've put up this app, the first thing I did was reviews and that was good enough.
But then I went a little bit further and I said, Well, let me at least put like an email button in the application. Like, do you need support, click this button? And that at least we'll get them the right email address. It'll give me information about their operating system, their version that they have.
And then that opens up the doors. Have you, have you done an email contact support button in your app, Frank? 
Frank: [00:14:49] Yeah, absolutely. This is what I started with and I still think it's kind of the best system out there, but I'll take that back because I've been trying some new things. Um, but it's definitely, definitely where you want to start out.
Just find yourself an email address that you're going to handle all your support through whatever it happens to be. No one really cares. Um, And then the fun thing to do, as you said, was collect some information, um, and throw that into the body automatically on the phone, just doing this in the past, the minimum things you want to collect are what kind of devices it running on.
Um, which version of the O S and what version of your app, because I have tried to fix things without that information and it's, it's my numbing. So, um, but then you can do other things like, um, maybe have a status for all the services that you're running, things like that just have some flags or whatever other hardware information you need to collect.
Yeah. I absolutely love that technique. And I was a little worried about being invasive, but the. It's not being sent automatically. The person can edit the email and delete whatever they want. 
James: [00:15:56] That's a good point too. Yeah. I actually am only collecting like version information and operating system, but I didn't even think about the version number or the device information or whatever.
I'm now going to add that in, because Xamarin essentials, there's a device info class and you just put them all in there and like, and here's all the things, right. And there's, there's no additional permissions it's like in use that it's not. Being invasive. It's not like you're, you're, you're auto sending this or collecting this in any way.
In fact, uh, I filled out the new, have you filled out any of the new iOS privacy forms that they require you to do now? 
Frank: [00:16:29] No, I feel like I have, but I can't remember. When did they start 
James: [00:16:34] requiring this? It was at the end of last year. You would, because you have to fill out like. 20 forms. It's like 20 pages of, of analytics crash reporting.
What type of data, wind data who gets this data as a third-party data is that this data is that, that data it's so much data and mine. My Caden's was simple. I collect no data ever automate, like I automate, I don't collect any data at all. There's no, I don't even need the internet. I don't collect any data, you know?
Frank: [00:16:59] So they, they always enumerated all of those and they're, uh, well, it started when they first required a privacy policy, but then they said what needs to be in that privacy policy? So then they broke it out into a web app. And so that's why you get 20 questions. Now it's funny because go to 
James: [00:17:17] your app store listing, like if you go to your app store listing today, like on the phone, like you will see.
So if I go to I circuit, I can tell if you've updated it because it's now required. I got to 
Frank: [00:17:28] ice circuit. I don't think I've done it. It sounds like I got a lot of work ahead of me because I have a lot of apps for 
James: [00:17:34] sale. Yeah, it's a pain. 1299. Holy smokes. Um, so it says no details provided under app privacy.
Oh 
Frank: [00:17:43] my God. I'm not stealing your information. What may be public about that right now? Literally I have no idea what I would do with that information. 
James: [00:17:51] If you were to type in and find my app, let me, like, obviously my cadence has like nothing, but I have a scoreboard app that I just updated because apparently it didn't work when I was 14.
I can't find this app. Oh, you know what? I can do the easiest way to find your apps that have bad names is a search for an app that you do know will show up, 
Frank: [00:18:08] tap on your company, Vinny up there it 
James: [00:18:10] is. Um, so scoreboard says at privacy data not linked to you is collected including identifiers, diagnostic and usage data.
Because I have like app, app, app, just stuff in there. So there's all this stuff, but it takes a lot and there's like details. There's all these pages that people can go through for app functionality, analytics, third-party advertising, things like that. It's pretty crazy. So it's, it's inside the app store.
Um, but anyways, That's sort of important to remember, because if you're relying on, you know, third-party solutions, you're often not collecting data or even know anything about a specific user. There are definitely analytics and crash reportings that do that, but not all of them do. And, and, and I, I'm not, that's not my, that's not my thing.
I don't want GDPR stuff. So here's what I did. Frank is one I'm about to update next, not my next update. I'm going to do it. You said, which is, but more data about the device, but in my, in my. Debugging locally. I found myself doing something clever. I thought it's at least clever that I haven't done before.
So I'm going to, I'm going to say it's clever. Okay. Which is I have a static class. That's called lager. Frank I'm no, this is crazy. I know that 
Frank: [00:19:25] it's mind blowing mind blowing. 
James: [00:19:27] Yeah. But I have a single method. That's called a pen line. That's it. Okay. And it does a debugged outright line. Okay. No matter what, and this is helpful because instead of calling SIS system diagnostics, debug dot write line, I can just call a pen line and then it is automatically always going to do this.
But here's the cool part is I put a setting on my setting screen called debug mode. Okay. And. The user can toggle this on before they send me an email. And what it does is anytime that I would do a debugged out right line, if they've turned on debug mode, it will add a line to a string builder in memory, Frank.
Okay. And then when they go to send the email, I take that string builder. I dump it into a file in the cache, and then I attach it to the email. 
Frank: [00:20:27] I like it. I like it. Um, yeah. Might as well keep it in memory. Um, I would almost argue though, you might as well just keep it a memory. Like don't even have a flag.
Just always keep it in memory because chances are, they're going to send you the bug report after the error has happened. So it's a little bit too late to go into debug mode. So. Yeah. And then you could give them the option of whether to attach logs or not, but I definitely liked the idea just, yeah, I might do the timing a tiny bit differently.
Yeah. I thought 
James: [00:21:05] about it. I just didn't know if there was any negative too. I didn't want to constantly write to file because that'd be bad. Right? Um, yeah, 
Frank: [00:21:12] it wouldn't be telling you, this is this a solid state storage writing to file is fine. These aren't spinning 
James: [00:21:17] disks. Oh, that's true. Well, what I decided to do is.
Frank: [00:21:21] Or a SQL Lite database 
James: [00:21:24] I also did though, is that this lager also has a bullying that says, um, debug mode. And what's cool is that if I wanted additional diagnostics, like something that is more complex, for example, um, when I get the Bluetooth data back, what I do is if debug mode is on, I output all of the bytes.
Yeah. Like every bite, just write all the bites. Like I don't ever need that data. You know what I mean? But I'm like, Oh, let me just create a string out of all these bites. So I have it, which is super helpful. And then in my, in my parsing data, I just have logged out of Penn logging out of pen, but I also have some things that are like, if, if I'm in debug mode, then do this stuff.
Type of thing. And I thought about doing that way, because maybe in this instance, I want just some additional information. That's a little bit more compute heavy because like I'm looping over, I'm looping over all of the bytes and putting them into a new string, you know, and these things are happening pretty fast, the Bluetooth readings.
So I was like, I don't want to do this unless I'm in debug mode, but I do like the idea of keeping everything in memory all the time. It's probably not that bad, but either way. This has helped me solve three bugs already. 
Frank: [00:22:41] Yeah, I can't imagine. I mean, it's always what you need. He need good logs to solve a problem.
You either have to capture it in real time with good logs or you have to go scrounge through logs. So I have no doubt. Um, just listening to that, that, that saved you. Uh, It's funny because you have a lot of options in your case. Yeah. I agree with you. I don't think you're going to take any performance hit, actually logging that constantly.
You would have to implement some kind of ring buffer, just so that there's a maximum limit that you would never want to hit for the log, but. There's a million dotnet logging libraries out there that probably do all of this stuff. And it's even built into an S log at least on iOS, but you probably want a more cross-platform solution.
I remember back in the day, I would actually try to get people to connect their iPhone to their computer over USB and bring up console app, learn how to use the search thing, learn how to record the log and then send it to me. I've gotten about 10 people over 10 years to do that for me. And it was like pulling teeth every single time.
It's just painful. I am apologizing profusely every moment that I'm making them do that. So it's well, especially if you're just saving things in memory, I don't think there's any issue with that because. Um, I mean, aside from you gotta make sure you don't run out of memory. People of course, memory is not free, but I meant more from a storing personal information thing because you wouldn't actually transmit it unless they filed a bug report.
And then you could just have a checkbox. Can I attach locks or not? Yeah, I like it 
James: [00:24:21] clean it's clean. It's helped me. I was, I was on a walk today and somebody emailed me. And, and, and it all has to be really automatic too, because I even put in the email, like, please add additional information. No, one's going to add additional information by the way.
So, um, this person just, they, they sent me an email and sure enough, like I dumped the byte data. And then I, I was, I dumped like all the different information about, um, like the, the parsing of my data. So with, with how the sensors work, um, I think I might've talked about this last week, but I may not have is the sensors can transmit only cadence, sensor data only speed day data or both.
And it's the same, it's the same service. It's the same stuff you just parse the data differently. So I have a, um, a printout that says has wheel has crank and crank is the cadence because it's on the crank arm. And I noticed that this person right away in the log says has wheel true, has crank false, right.
And over and over and over and over again. And then I, I emailed him back. I said, Hey, you know, um, it looks like your cadence, your sensor is a speed sensor, not a cadence sensor. And a lot of these sensors can do both modes. They can do a speed or cadence and you just take the battery in and out to swap on the modes.
It's kind of crazy because it's just, it's just different data, right. It's the same thing. And he's like, Oh, I didn't realize that the green was red, not blue, you know, so pretty funny. Um, is there enough that fixed it for him, like right away? And I was like, wow, look at that. So then it got me thinking though, is.
You need to take this data that you have, right? You can, you can put logs into your application and you can put, you know, email things into your application. You're going to view replies. But the thing that you can do is just make your apps smarter, right? Why is it that this person tried to connect the sensor data?
And I have in my logs that 10 times it only has wheel data and doesn't have crank data. Why is why didn't my app? Just tell him that. 
Frank: [00:26:24] Yeah. Um, because triggering off of events is hard. That's why detecting events is hard. The it's fun because these are the exact problems you go through when you're designing.
Um, Embedded systems, real time systems that have to interface with humans. You're always kind of dealing with these questions. It's once you make it safe, then you try to make it usable. And it really is just kind of like UI work at this point because error handling. Is usability, especially for errors that, you know, is, are going to happen when the sensor's in the wrong mode or things like that.
Um, there's a little issue in.net where we try to treat all errors as exceptions. And then we kind of keep in the back of our head. Well, this exception can kind of occur more often than this other kind of exception. And we just kind of keep that as a heuristic in our head. But we can easily fall into the trap of handling every exception the same.
And we really have to think through the error paths. I think that was the lecture I was trying to give. When you're first getting into Bluetooth, I'm like, you're going to have a lot of weird error paths and you kind of got to think through each one because they're different. And what you're talking about of recognizing.
And that it's not even an error, as you're saying, you're just not getting a cadence, but it is an error because your whole app is my cadence. It's supposed to be displaying a cadence. So you have to recognize that as an error condition, even though it's, it's a part of the spec and it's not an exception and all the physical communications are working correctly, it's still an error condition.
So it's fun. Cause this is. Real engineering to me, 
James: [00:28:09] honestly. Yeah, that's true. Yeah. So like right now, what I do, and I'm about to improve this in the next version, based off of this, this feedback is okay. What I'm going to do is right now today, when the user tries to connect to the sensor, I do a little validation.
Like I like make sure I can connect to it and make sure I read data. And today, if I can read data, I display the number. I'll say, put a little question, Mark. And after like 10 events or so if the user has valid data, like any valid data, like it's parsed out correctly, it's totally good to go. I'll say verified, saved, and disconnected.
Like you're good to go else today. Put unable to calculate cadence, please email support. So this user definitely found this because it's definitely reporting back, you know, question Mark negative one, and then it tells them to email. So now what I can do is I can say, Hey, in the case where there's no valid data, can I see and say, Hey.
Is it because there's no cadency to, but there is wheel data speed data, like kind of just displayed that message, you know, can you kind of like continuously update this if an L SIF, like what type of is, what type of invalid data is it? Can I glean a little bit more into it then? I don't know. No, I can't calculate it.
Please email me. Right. Cause the idea email's good, but like you said, early on, is it there? You don't want to live inside of email of support because you actually want to work on your app. Right? 
Frank: [00:29:32] Yeah. And especially if you have a bug and then, you know, you just get swamped in the email or honestly, if, if, even if you just have a popular app, people like to send you compliments and it still takes time to read, but those are the good kinds of problems to have.
It's funny because when, again, I'm going to just go and go back to electrical engineering. Whenever you build a device, you build a diagnostics mode. Into that device. So that out in the field, away from the lab away from all the test equipment, you can still hit a magical key combination somewhere somehow, and a red light or green light would flash, you know, telling you is this thing working or not.
We tend not to do that in software, mostly because we stink at our jobs. Now I'm just kidding, because we focus on unit tests. And not so much integration tests. So we always ship our apps when the unit tests are going green, because you know, tests are easy to write and they're fun to write and they turn red and green, but we definitely don't work very hard on integration tests.
Um, so if you have a piece of hardware, You might for software sake, create a really easy API to it. Something like connect and download data and it returns the data or throws an exception. It's a beautiful API. It's a wonderful program and, or interface, but it's absolute garbage for detecting errors. Um, that's where you want interfaces that.
Are more, uh, granular where they say like connect, subscribed, uh, transfer this data receive. We don't want to write that code, but it gives you the more granular error to that. So there's this constant balance between software that can diagnose its errors and runtime and software. That's easy to program.
Um, in hardware, you unfortunately need to take the hard path as you've, as they're learning, just to get the detailed. Bug reports on what's going on, but I want to put that out there. Also, if your app talks to a server and has any form of integration tests where you're not mocking out the important stuff where you're actually accessing the important stuff, that's what I mean by an integration test, where if you have a web server you need to access, you're not mocking that web server, you're actually touching that web server.
That's the distinction I'm making. Why not? Bury that down into a settings so that if someone's having a problem, you can say, go to your settings, hit this diagnostics mode and let me know what it says. I think that that's just smart software. 
James: [00:32:00] Yeah. Yeah. I agree with that. I think that that's something that often you don't really think about until it's too late too.
That's the other problem is I didn't think about many of these things cause I'm like, it works on my machine. Like all my tests with my sensors. Weren't good. So it must work great for everybody. No. I, I find that if I take every view and every support, email as a learning opportunity in the long run, that's really going to a lead in less support emails and less negative reviews because I can build more of these features into the app to be smarter.
So people don't have to email me so they can self-diagnose. And, but when they have to. That data that I'm getting back is going to be enriched and is going to help me solve their problem faster because at the end of the day, you know, my application is free and I'm, every minute I spend is money lost. 
Frank: [00:32:57] So what a, what a hopeful thought.
Oh, that's so nice. But, but I, I, I, a hundred percent agree with you. Every time I see a support email, I see it as failures on two levels. Um, Well, a whatever problem the person's speaking about. So obviously that's my fault, but, um, uh, what have I even mean by this? Um, it's, it's lacking that self-diagnosis, that we've been talking about for the last little bit where the user's confused.
They don't know if it's their fault or the app's fault whose fault it is. And so it's like, um, Even if the email doesn't expose a buggy bug bug in my app, the fact that they felt the need to send a support email is also a bug. So I see it on both of 
James: [00:33:45] those levels. Yeah. A lot of ways too, that if you're finding bugs, fixing bugs, I do think that some people that you find based on your type of application will enjoy being part of the.
Like working with you to solve a problem. Like, I think if a developer was like, I'm going to work, like I totally like we're working on it. Like, would you be willing to help test it out? Like I'm in, right. Like I want wanna, I want to help. I want to help make the app better, like use this app. And that's what I really found with this app is it's really easy.
Right. I just started like open beta testing on Android, on test flight. You can now just create a link for people to like join or whatever that makes it really easy. So there is some nice things that are built in there. Um, but I will save this now. Let's say you've put in the diagnostics, you've put in the email, you've helped people with bugs.
Here's the last thing that you can do in fact, do this often. I mean, even if you get good praise on your application or if you're solving bugs or, you know, anything, anything that you do when you fix the bug. Okay. And you email them and they're like, wow, it's working great. Now write back one thing. Tell them obviously, thank you for sticking with me or for doing whatever.
And then write one thing down, which is we would love a review for the application. If you know what operating system is, here's a link to do so. Right. And I have a good plan that I use for all mine too, because my cadence is for, for cycling on a bike. So I go as always, we would love review after you give the app.
A spin. Wow. And then I put a Winky face and you know what everyone says. Absolutely. I'll go do that right now. And then sure enough, they leave a review, Frank. Yup. 
Frank: [00:35:38] An old trick. It's not a trick. Um, I don't, I don't know. I guess we both, you know, great minds think alike. Uh, I started doing that with the very earliest support emails, and I don't know if it helped, but like you said, every single person writes back.
Absolutely. I will. Whether they do or not. I don't know. I don't follow up or anything, but like, um, You're right. Um, it's a fair exchange and you're, you're kind of saying that, Hey, I took some time to work here and I know you bought my app and everything, but yeah, I would love a review. You can phrase it a lot better than I just phrase that everyone, 
James: [00:36:18] you can craft this to be a lot better.
And like, you know, I think you could even take it further too is like, you know, There is opportunities in building, which is like even reaching out after that person wrote the review, like checking in like a week or two later, how's everything going. Like you're really enjoying it. Like I saw your review.
That's awesome. Right. And that's a nice touch. You don't want to bombard them. But like this person who I worked with for like a week, they installed like five different builds of the application on my test flight. They went back and forth while I was putting in the diagnostic data, they were sending stuff to me and they wrote a review.
Right. And they even said I needed an app. For my wife, um, who wanted to see her cadence using the Swain IC four, which is a fitness bike. And he said, uh, in here initially it was not compatible, but after contacting the dev, they were able to get it working. Thanks five stars, right? Like that's cool like that.
If they put that message in there, like I didn't ask them to put that message in there about like contacting me and doing this stuff. But these types of reviews are encouraging for others. That maybe are having issues say, Oh, these devs are responsive. Um, one person like wrote back, like I've never gotten a response from a developer before and they got back to me and got it.
Got me, got me set up, like, that's cool. You know what I mean? Yeah, 
Frank: [00:37:39] it's great. You know, I've made, um, some good relationships too. I don't want to say friendships or anything, but like I have a lot of correspondence from people that I've met over support. Getting back to what you were saying about people want to see your app succeed.
That's always the old trick with giving presentations or basically doing anything in public. People want to see you succeed. They don't want to see you fail. So they're very encouraging. As long as it looks like you're giving an effort or something like that. And I've been so lucky to just have wonderful correspondence.
The problem is I could spend all day every day just doing support email, and I'm not my apps. Aren't that buggy everyone. No, it's not a whole bug reports because a lot of it is just, you know, um, for Kalka people want to talk about mathematics for ice circuit. A lot of students want help with their homework.
And if I'm in the mood, I totally sit down for an hour and I help them with their homework and it's fun. And it's honestly really real rewarding. So I'm a little bit lucky to have those kinds of apps, but where I'm also have a problem is it's roughly five to 10 emails every day for the last 10 years of my life.
It's. Um, I can't keep up. It's that simple. Um, so unfortunately what I tend to go through are phases where I'll catch up on as many as I can for the past, you know, two or three weeks, and then I'll go two or three weeks without answering any. And then I'll kind of repeat that process just because me, myself, my own personality, I can't spend.
Every day answering emails. It's just a little bit exhausting to me. Unfortunately, 
James: [00:39:23] it's why there's support teams that exist in the world that all they do are support. Right. You know, I mean, that's why there's support that then works with QA to make sure it's a real bug at a report and then put it into the, into the dev ops system and then you track it, then you fix it, then it's in the release notes, you know, it's, it's a, as things grow, but the problem that you and I have, right, is that we're.
You know, independent developers on these applications. You know, we don't have the privilege to have those dedicated, because like we said earlier, every time, every, every minute that you're spending on support is potential loss, revenue, and time to work on the app. Some people may flip that and say, well, you may lose that customer.
Right. And that, that, that is equal. That, that I would say that that's also true too. So you have to balance that accordingly, right. Is, is building apps, building new apps versus. Fixing something that, is that impacting one person or is it impacting 80% of the people you need to kind of judge those out?
Frank: [00:40:17] Right. Like in my market, I have teachers who are using the app in classes. So if I see a support email from a teacher, I hate to say it, but they kind of get priority because I know that not only could they convince maybe some of their students to buy my app, which honestly I'm thinking about it in the back of my head.
But also I'm thinking about this is kids' educations here. Like, I don't want to screw this up. So please teacher tell me what the app's doing wrong. And I want to fix it to meet that. Not everyone's app is used in education, but it's kind of a fun fallout at that area too, but also stressful. Anytime a teacher emails me, I'm like, what?
Huh? What, what, what's it doing wrong? Please tell me. 
James: [00:40:58] Yeah, I think that might be all I can think about for support, 
Frank: [00:41:02] right, right. Oh, give me a break. It's it's it's not it's non-stop I really think that the machine learning one is valuable. I'm don't really love the results the Google was giving us, but, um, There has to be a way to give at least some customized support.
And I always feel bad because like, when I say five to 10 emails a day, people are like, Oh, that's nothing. I deal with hundreds of emails a day and blah, blah, blah. I'm like, I don't know. Maybe you just have a different personality or something from me, but. Um, it, it would be nice to, I don't know how better interface.
I almost want the Twitter for support. So instead of just going to Twitter, I just have my support feeds or like maybe I should just use discord and have people hang out in a forum and things like that. Like the monitor world's coming. It can't just be email forever. 
James: [00:41:55] I don't know if we end up in a podcast.
Sometime a hundred podcasts ago, we talked about forum support and different ways of putting it. We talked about web based like website based solutions. Right? And now we're talking about like app based solutions and I don't know, I think it is a forum, any different than an email, except for now they have to register for an account.
You know what I mean? 
Frank: [00:42:18] Well, yeah, the, the hope and the prayer is that someone will search that forum and not send you the email. 
James: [00:42:25] That's a good that's, that's the hope. That's true. That's a, that's a valid point. In fact, I do get a lot of like DMS and tweets at me that I have, like, I have a problem with this, or how do you do this?
I'm like, Oh, go ask on the Q and a or on the forum and then, or even sack overflow. And like, someone will find it cause that'll be index and then it's not a one-off. Right. Um, that's a good point. That's a 
Frank: [00:42:45] good point. Yeah. That's the sad one. When I actually spend two hours writing a support, email, explaining the intricacies of simulating analog circuits.
And I'm like, well, I just spent two hours and it's going to one person I'm happy. I helped that person. But at the same time, I'm like probably should have turned that into a blog entry or something like that. Yeah. 
James: [00:43:07] I thought about putting on my website, like a, a troubleshooting thing. But I was like, no, one's going to like know to go there unless the troubleshoot, unless there's a link inside the app that says troubleshooting and then opens the website, you know?
Right. Um, yeah, it 
Frank: [00:43:21] needs to be there. No one uses or you do search, but you're lucky if people do search because ain't no one reads the manual. So no point in putting it there B you better have good Google juice that it's going to find you. So the more reasonable one is help links everywhere in your app.
And we don't do that. Like I remember in the nineties windows apps, you were, we were really big on having a help topic for like, Every UI in your app. And then mobile came along and were like, Oh, thank goodness. We don't have to do help files anymore. But it's sad because we don't have good help anymore.
That's 
James: [00:44:01] true. That's true. Frank, Frank, Frank. All right. I think we did it. I think we solved the world support problems, or at least maybe gave a few people, some tips of my learnings and your learnings, but I would definitely be interested in like what our listeners have been doing either a. In their applications or B support that you've seen in other applications, like maybe you've emailed somebody or there's a really cool ad in that you've seen and used a love to hear from that go to merge conflict that FM hit that contact button send.
Frank and I, and email we'd love that, or hit us up on Twitter or on our daily cord, you can go to all the places and do all the things we'd really appreciate that. And we would just love to hear from you see what you're up to and what you're building and how you're handling support and your applications.
But I think it's going to do it for this week's merge conflicts. So until next time. I'm James Matson Magno. And I'm Frank 
Frank: [00:44:50] Krueger. Thanks for listening.