It has been rewarding to see Paravel’s side project DayTrip grow over the last 6 months into a fully-functioning micro-social network that tens (!!!) of people use every week in our Private Beta. I’ve had many side projects over the years, but in retrospect, some were just big launch days with little-to-no plan for ongoing maintenance plan. DayTrip is quite different.
DayTrip satisfies a need my family and I have in our life. It helps us break the cycle of endlessly watching Netflix on the couch and experience the world around us. We put down the screens to go outside and play.
Building a product in your spare time definitely has its limitations. You can see steep hills and valleys in our commit graph. Our productivity is entirely based on client work and personal situations. In April we began a new client project. June was the big ramp up towards our Private Beta, giving up some nights and weekends. In August my family had health issues and my switch to Windows had adverse effects on my Rails environment…
Life has very real consequences for a side project. Momentum is everything for a product and when building one on the side it adds an interesting dynamic where time is not guaranteed. Planning becomes very modular and implementing must be quick.
Feature Requests
We’re listening to our User Feedback and faithfully trying to decide how and when requests can be addressed. Lots of ideas have been dropped into Github Issues and are being fought about discussed in-depth. Two of our most frequent requests have surprised me a little both in their frequency and what I learned about product development and Users.
1. Everything must be AJAX. Everything.
Most requests fall into the bucket of “AJAX everything”. Typically I feel bells and whistles can wait. Eat your vegetables, then get fancy. But based on User feedback, that extra polish might need to be escalated to reduce the pain of unnecessary clicks and swipes.
I’ve began the slow work of progressively enhancing all our interactions to be more asynchronous with a few simple animations here and there. This is very error prone for me:
- While trying to use ES6’s
fetch()API, I broke the signup form on the homepage multiple times. We lost an unknown number of signups. That’s a big mess up. - While making Follow buttons asynchronous, I introduced a bug where if a button was clicked twice real fast it would delete your account instead of the user-to-user relationship.
I don’t like this work. With a few handfuls of interactions left to make asynchronous, I’m beginning to wonder if a framework like React or Ember could help manage it all. In fact, I’ve developed a mathematical law for my feelings:
Rupert’s Law of Asynchronicity
“For n equal to the number of interactions on a site. As n approaches 3, you’re going to want a framework to manage that bullshit.
I could continue down my path of progressively enhancing everything The Dave Rupert Way™, accidentally deleting a few accounts here and there, or I could look into using a client-side framework to help manage these interactions in a structured way. Surely this is a well trodden cow path.
Beyond my woes of ditching Progressive Enhancement for an SPA architecture, I think my biggest takeaway is: Users expect rich interfaces.
2. We need to be in the App Store.
My hairstylist Kelsy was lamenting one day how she lives a boring life and watches B-rate horror films on Netflix all weekend.
“Oh boy, do I have an app for you!” I said excitedly, grabbing my phone for a demo.
“That sounds exactly like what I need,” she said. “Where can I download it?”
To which I replied, “Errr… uh… derr… well… it’s a website… so… uh…”
This has been a common theme. One trusted friend even said “I don’t use it because it’s not an app.” Damn. Even with a decent Add to Homescreen experience it’s difficult to break the expectation that you download Apps from an App Store to your homescreen for later use. I think I’m learning Users are accustomed to downloading apps.
The need for native clients forces us to prioritize mobile clients and an API over features and enhancements. That sacrifice is probably worth doing. As it stands, DayTrip is currently ~57% mobile users (I expect that to grow)… that puts the responsive website in an awkward position.
Websites aren’t dead by any means, but I do wish Progressive Apps could come faster. If regularly used websites invited themselves to your homescreen, we could focus on building one good universal web experience, instead of a few similar web and native client experiences. Mobile Safari (97% of our mobile traffic) is probably the biggest Progressive Apps hold out though. Nevertheless, it’s important for our content to meet users where they are; be it web, native, mobile, or desktop.
Frameworks & Prototypes
We couldn’t have built DayTrip in our timeframe (0-3 months to Launch, 3 months of Private Beta) without using an opinionated framework. Ruby on Rails’ emphasis on convention over configuration suits this well because it means I don’t have to figure out The Dave Rupert Way™ of doing everything. I just have to find the super well-documented, well-trodden Rails Way of doing things.
I think it’s very important for teams to see ideas come to life quickly. Whether that’s code prototypes in CodePen or utilizing a framework or your styleguide to do the repetitive parts of the thinking and building for you.
Last week I began building out the mobile app using Ionic. I was able to get our four main browsing flows on my phone consuming real data from our API in just under a week. It’s far from being done and final, but having something in our hands to talk about is better than gold.
If you’re limited in time or people, frameworks can be a great way to quickly gain ground.
More to come…
There’s quite a bit more I’d love to share and document about building DayTrip. Decisions we’ve made and how they’ve shaped the product. If you have any specific questions I didn’t address, I’d love to hear them.
And of course, if you live in the Austin area and want to help keep the feedback coming…