I just started this new blog. More posts coming this year, and I’ll be importing old posts from previous blogs as I sort through them.
Also, follow me on these networks:
A big milestone in my life was my first visit to the Computer History Museum in Mountain View, CA.
If you’re in the area and at all interested in technology, I encourage you to make a visit to this museum a priority.
Here’s why it blew my mind:
This all happened over such a short amount of time. Almost everything covered in this museum happened less than 100 years ago. That means there are people still alive today who lived through ALL of it.
The incredible amount of work they did in the 1950s to process data seems unfathomable now. Everything was so mechanical and required so many man-hours.
To do something as simple as generate a report of all credit accounts for a department store required rooms full of women encoding data into punchcards, and several MASSIVE machines to process them and finally generate a static, printed report. It almost made me think “why did they even bother to do it that way?” — but they didn’t have another choice.
I get the same feeling about my Hammond Organ. It’s extreme over-engineering of older technology to solve a problem that would be trivial with current technology.
I’m going to expand on this post soon, so for now check out some photos:
Photo Find is an app that lets you pick a photo and points you to the exact location where the photo was taken.
Now, when you have a photo already on the clipboard a new button shows up that lets you quickly paste the photo into the app.
The need for this arose from my own use of the app. If someone sent me a picture via iMessage and I wanted to load it into Photo Find, the process was annoying. I would need to save the photo and then find it with the photo picker interface.
To make this faster, I added a button that shows up whenever an image is on the clipboard. When the button is tapped, the photo is loaded, and if it has location data you will be able to navigate to it.
I decided the button should show up whenever a photo is on the clipboard, whether it has location data or not. Originally I thought the button should only show the button if the photo had location data. However, since there is already a decent user feedback mechanism when a photo with no location data is loaded, I decided it makes sense to always show the button when there is an image on the clipboard. This prevents users from thinking the image wasn’t properly copied when copying an image with no location data.
I was curious about whether this feature would get approved by Apple, since I haven’t seen any other apps dynamically respond to the contents of the clipboard (UIPasteboard).
Does anyone know any apps that alter their behavior based on what’s on the clipboard? I can think of places this could be very useful, like if the Google Translate app automatically translated text on the clipboard when you open the app. UPDATE: My roommate Brian reminded me the Instapaper presents an alert when you open the app and have a URL copied to the clipboard.
Implementing this was a little trickier than it might seem. I had to completely go back to the drawing board on how I was getting location information for a photo. With Apple’s APIs it’s very different to get the location of a photo retrieved with the UIImagePickerController versus an image from UIPasteboard. This was also a good opportunity to switch the image picker location lookup to use PHAsset objects in iOS in favor of ALAssetsLibrary, which I used in the first version.
By the way, while I was writing this I started thinking a lot about the term “pasteboard” vs “clipboard.” It turns out this is another example of terminology inherited from NeXT!
The first version of Photo Find only used meters and kilometers. I’ve been an advocate of the metric system since high school when I decided to make the switch, but I realize there are many people in the United States who still use feet and miles.
I’ve decided a new entrepreneurial theme I want to embrace is profiting from people on the wrong side of history. While I built this app mostly for my own use while hiking, I thought it would be nice if it could make money somehow.
Users of the app were asking for an option to switch to feet and miles, but I wanted make sure to take a clear stance on preferring SI units. After thinking about it more, I realized I could both create a revenue model for this app and provide an economic incentive for people to use SI units at the same time.
Ideally, this app would make NO money, but I have a feeling some peolpe will pay for it. Or maybe some people will buy it to support the developer. 😀
The first time a user selects “ft” the In-App Purchase is initiated. Then, once the user has purchased it, the UISegmentedControl behaves normally to switch back and forth between meters and feet.
The option resides on a new panel to the left of the main screen. The main reason I did this is because Apple requires a Restore Purchases button for any app with In-App Purchases, and I didn’t want to add that on the main screen.
Most of these screenshots you see on this site are from my iPhone 6, so there’s a lot of breathing room. The oldest iPhone that can run the app is the iPhone 4S, since the app requires iOS 8.0. On that smaller screen, everything’s a lot more compact. There wouldn’t be room for all of this on the main screen of the app. The units option and Restore Purchases button are also lower priorities for the user.
I actually thought of this revenue model while developing the first version of the app. Instead of implementing it, I wanted to stick to the Getting Real mindset.
I decided I should release a version with no unit switching and no revenue model, then add it in the next release. In hindsight, I’m SO HAPPY I made that decision and didn’t try to fit these into version 1.0.
Actually getting through the whole app development, submission, and approval process to get my first app in the App Store was so rewarding. It didn’t matter if the app could make money. The app got out there and on hundreds of devices, which provided an opportunity to get feedback on it.
This app is just a fun learning experience for me. After the milestone of a published app I didn’t really touch the code for weeks.
Most of my time right now is spent on Credit Card Insider, so development on this app only really happens here and there late at night when code mode strikes. I probably spend less than 2 hours per week average. I slowly added the clipboard feature after some troubleshooting sessions spaced out over a few weeks.
I would develop a build, try it out on my phone for a week, and then work on it a little more. To the left, you can see a build from late November 2014 that could do the units switching and had a probably-not-working-yet version of the paste button.
Finally, on the night of Saturday, January 17, 2015, I got into code mode at my friend Brian Lee’s kitchen table and built my first In-App Purchase, then submitted the build to the App Store.
It’s actually funny looking back at that screenshot of a previous build. In this photo the app is set to navigate that to a picture of Brian’s jet boat at his house in Deerfield Beach, Florida.
I was home in Syracuse, NY when I took this screenshot in mid-November, so it’s a crazy coincidence that I ended up finishing version 1.1 in his kitchen 1176 miles away a few months later.
The sliding gestures are buggy. I probably should have used a UIScrollView instead of building something custom. My goal was to focus on releasing a version with the In-App Purchase, and then iterate from there.
I already had the sliding “glass” panel in version 1.0, so I sort of organically built the rest of the sliding gesture stuff on top of that before I even realized UIScrollView would have been a better option.
I noticed some minor bugs and usability improvements related to the In-App Purchase after submitting. I’ll probably do a version 1.1.1 at some point in the next few months to squash those bugs.
The In-App Purchase turned out to be much easier to implement than I had expected. On the other hand, the paste button required lots of troubleshooting. If I could go back I would have built the In-App Purchase first, released that version, and then waited for a future release to do the paste button.
Well, I’ll probably not touch this app for a while. At this point it this project has already taught me SO much that will be influential on any other projects, so I’d be happy stopping here. I’d rather spend the time on Credit Card Insider right now.
I’ll probably do some very minor promotion to get the app out there in people’s hands who can really make good use of it. There are no viral growth or retention mechanisms, so those would be two good things to spend some time on development-wise if I want this app to be able to snowball its own growth.
So, if you know someone who might be interested in the app, I would REALLY appreciate it if you send it over to him or her! Here’s the link to download it on the App Store: Download Photo Find on the App Store »
If you like it, please leave a review in the App Store!
Launching the first version of Pee & See has been a really amazing experience because it’s showing me how keeping a product simple while giving it a voice and attitude can be very powerful.
I’ve always been really into the idea of designing a good empty state. Once I added a user system, I realized people signing up wouldn’t have any pees logged. I wrote up this quick message:
Then, I noticed something about this message. I didn’t think much of it when I wrote it, but whenever I was around someone who just signed up he or she would chuckle at this first page after a new signup.
It made me realize that if all the copy in the app was like this, I’d have happier users that would hopefully look forward to logging pees. Humor would also be a way I could nicely get people who aren’t logging pees re-engaged, instead of a more serious approach.
In my original post about Pee & See, I said:
Most development that happens on this will probably revolve around making it as fast and easy as possible for people to log their pees. I think the biggest barrier for most people is getting into the habit.
Right now there are about ~30 people who have signed up. Some of them have never logged a pee, and most of them are not consistently logging pees.
In order to give better insights, I plan to look at all the data in about 6 months with some mathematician and statistician friends. In the meantime, I think it’s important to:
The very minimal time I’m putting into developing this will be focused on automated solutions for retention and growth.
Since it’s a web app, user retention will probably have to all happen through email, for now. I am already collecting emails for account notification purposes, so I plan to add a low-barrier email confirmation step. Here are some of the ideas I’m considering:
Lapsed pee retention emails — My initial plans now are for a few emails that are triggered by people not logging a certain number of pees over a certain amount of time. I’m going to try to make them funny to get people re-engaged, and provide tips for lowering the barrier to adding pees.
Authentication tokens — I might send users a link in an email to log them in automatically, without entering an email address and password. This would be with some kind of limited use authentication token.
Home Screen icon tutorials — Something that can help people remember to log pees and log them more quickly is a home screen icon. Since Pee & See is still a web app, many people don’t realize it can be on the home screen of iOS or Android devices and has special markup that tells devices to treat it more like an app.
I’ll try starting this out with some basic tutorials and screenshots and then seek more automated ways to get people set up with home screen icons. There may be a conflict between this concept and the ease of use of an authentication token.
Positive milestone emails — The next kind of emails I’ll add is for people reaching milestones in their pees. These will be more oriented toward growth, because the calls to action will be more about getting feedback on what they like or don’t like and asking them to share it with friends. I have some good ideas for how to make these funny.
Piss or get off the pot — My current plan is to not have a way to disable email notifications, because users who are actually logging pees consistently would never get them. Instead, if you want to disable the emails, then I’ll ask that you disable your account if you’re not serious about pee tracking. This will help maintain better data integrity by getting rid of the occasional users and getting other people in the habit, theoretically.
I don’t want to spend much time on marketing Pee & See, but I think even what I’ve built so far has had a positive impact on the lives of the people who use it regularly. Dehydration is a big health issue that can be easily prevented, and this is a free and simple tool to help with that.
At the time of writing this, there aren’t ANY social media share buttons in Pee & See. It has no Open Graph tags (which were a major factor in the growth of FourLokoStories.com). There’s no copy anywhere that asks people to share it.
These are some quick wins that I could add with less than an hour of work. I plan to make the sharing calls to action especially prominent at key times for people who have been using it consistently, since I think they would be the best advocates for it.
As long as the retention rate of new sign-ups is improved, there will be a higher number of consistent, happy users. Combined with these minor tweaks, I think it would be possible to get these happy users to share with friends.
Plus, it’s an app about urinating, so I think that naturally helps the word spread.
I probably put about 1 hour of work into this per week… not counting using it, of course! So far, the payoff has been great.
First of all, I haven’t been dehydrated (no headaches) since I started using Pee & See. This means I have more healthy, energized hours to spend on Credit Card Insider, which is a big plus.
Second, it’s been great exercise for my mind to brush up on my Rails skills and other technical skills. I hadn’t used Bootstrap much before the very end of 2014, and that alone has been a great inspiration and learning experience for CSS best practices.
The Bootstrap documentation, much like Apple’s iOS documentation, is a top example in my mind as I create procedures and documentation for every aspect of what we do at Credit Card Insider. The logical and hierarchical layout of Bootstrap itself has inspired me, too, and is now another example I can keep in the back of my mind for a well-designed product.
Did you like this post? I would REALLY appreciate it if you like and share Pee & See on social media.
Do you know someone who might want to track his or her pees and stay hydrated? Please send that person an email right now with a link to Pee & See! You could even link to this article or my previous post about the initial prototype to give some more context.
I was always getting dehydrated. Sometimes I would lose a half a day of productivity because I would get caught up in work, wouldn’t remember to drink water, and then by the time I had a headache it would be too late.
My solution was to make a simple pee logging app. That way, if the time between pees starts getting too long, I would get alerted to drink more water. A quick search on Google and the Apple App Store showed me there wasn’t anything that fit my needs very well.
I came up with the concept while I was out in San Francisco and learning Swift, so I started it as an iOS app. I quickly decided I wanted the data to be more accessible, I wanted to prototype faster, and wanted to be able to access the site from any platform, so I decided to prototype with Rails instead.
I’m a big fan of 37signals, so I often take the approach they discuss in Getting Real for launching new ideas. For the first version, the only thing I needed to be able to do was click a button to log a new pee at the current time, and delete pees (for when I accidentally pressed the button more than once).
For a while, I just had this iOS app that would load a UIWebView of the site. Now, I added an iOS home screen icon to the Rails app so I am using that instead.
Once I got this version going and was using it myself for a few days and talking to people about it, enough people showed interest in wanting to track their own pees. A few nights later I spent an hour adding a user account system, so now anyone can sign up and start logging pees.
Between releasing this first version with users and writing this post, about 20 people signed up. This started as just a project for me to use, but it’s pretty cool that other people want to use it, too.
Next, I’ll probably add some form of email notifications, since there aren’t any notifications yet.
After that, I will probably add some kind of “color” attribute for each pee, so you have the option to indicate how dark it is. I left that out of the first version so I could get something out faster, but I think it could be useful data. I’ve found some existing scales that are used to correlate urine color with hydration, some of which have up to 7 discrete levels, but I will probably go with something simpler like 3 levels.
Most development that happens on this will probably revolve around making it as fast and easy as possible for people to log their pees. I think the biggest barrier for most people is getting into the habit.
If it gets enough adoption, it would be cool to build a native iOS or Android app, or both. I think that could help with distribution by putting it in the App Store and Google Play.
It seems like many people don’t know about how to add Home Screen icons to websites in Safari, or the equivalent on Android. A native app would lower the barrier for pee tracking by separating it from the web browser.
Also, native apps would let the app send push notifications, which I think is important for the hydration reminders. I could set up email or SMS reminders, but that seems too old school right now. Notifications could also remind people to log their pees if they haven’t been.
I’m not a doctor, I’m just trying to keep myself hydrated and now help other people do the same. I don’t really look at this project as a business as much as a tool to help people stay healthy.
I have been keeping my own urination data in the app since a few days before 2015, so as long as I keep it up I plan to have a full year of my own pee data by 2016. At that point it would be fun to find people interested in researching this stuff, or people good at statistics, so we can dig into the data and come up with solid ways to make recommendations and provide useful metrics and analysis about the pee data.
Another direction I could see this going, if it gets a lot of traction, is a hardware device.
It would be like a funnel that you urinate through. Obviously, one of the biggest design considerations would be that it’s easy to clean and hard to get pee on yourself when using the device.
This device would provide some additional data about the urination event, like the volume and flow rate, but the biggest part would be analysis of biomarkers.
It could use mass spectrometry to analyze your urine, and could tell you way more than just your hydration level. From some brief conversations with people who know more about urine than I do, I’ve found that it may be possible to measure things like leukocytes, nitrates, protein, glucose, specific gravity, blood, ketones, bilirubin, and much more.
My early research when I first had the problem lead me to the uChek, which seems really cool. It’s a little bit different than the hardware concepts I’ve been throwing around since it requires consumables (test strips), but there may not be around using consumables for some tests.
I’ve done some preliminary research on instructables to see what kinds of homemade spectrometry is possible. These diffraction slides are kind of fun to play around with, especially if you have some different types of light sources around:
Any electrical engineers or hardware hackers out there interested?
Ideally, this kind of device would be open hardware, so it could be both available commercially and also have less expensive variants and DIY kits to improve health in developing parts of the world.
I want to help keep myself healthy and productive, which is why I built this. If it helps other people, awesome. If it grows into something bigger, that’s awesome, too. If I just keep using it to log my own pees and keep myself hydrated, fine with me!
No matter the outcome I’m happy with myself for spending very little time taking this from problem in my life to research to concept to prototype, and getting something out there that anyone in the world can sign up for and start using.
Check it out at http://www.peeandseeit.com
UPDATE: I’ve posted a second article about Pee & See discussing what’s going to happen next with it based on what I’ve learned so far.
Did you like this post? I’d really appreciate it if you share it on social media! After that, you can read about more of my projects here.
A few nights ago some friends were over and we were doing some Armory Square people watching at the window. Someone joked about putting a camera up, and I hadn’t really thought of that idea before.
I snagged a camera on Amazon a few minutes after that, and got it in the mail a few days later. It’s a Foscam FI9821W. I didn’t do a ton of research on it first, but this one was pretty cheap compared to alternatives like Dropcam.
A few nights later, Ryan bought his first domain name (armorycam.com) we launched the first version of Armory Cam. We’re not exactly sure what the plan’s going to be for this site. Brian and Ryan and I are still trying to figure out ways we can improve the robustness of our streaming setup and actually stream video instead of just one image at a time.
UPDATE 1/25/2015: Ryan and I were looking through some old drone footage from this summer when my friend Edward came up from NYC for a few days and brought his DJI Phantom.
Ryan suggested we release the video with ArmoryCam.com watermarked on it to get some extra attention to the site. So, here it is: