Moonshots

tl;dr — Photos+ has a new home at Silver Pine Software. Elements has been discontinued due to lack of sales and so I can focus on Glassboard.

When I decided to take over Glassboard, I knew I was at the time biting off more than I could chew as a sole developer. Balancing a product that has three front-end clients, an API server, and tens of thousands of users while also working almost full-time as an iOS and Android contractor isn’t easy. Add on top of that, my existing suite of products and it’s a bit insane.

One of the things I said I would do when I decided to take on this adventure was to simplify and focus my work. I’ve always had a bit of ADD, which is why my suite of apps has ranged from text editors to GitHub clients to photo galleries.

In late 2013, none of these apps were necessarily setting the world on fire financially, but they had users that I wanted to try and do right by. I have spent the past several months working on finding new homes for each of them.

Committed

We announced that The Magical Panda acquired Committed a few months ago. Since the acquisition, Saul and friends have been hard at work squashing bugs and adding new features such as 2-factor authentication support for a more secure GitHub login experience.

Photos+

As of today, Silver Pine Software is the new home for Photos+, the pro’s photo browsing app I released back in December of last year. Photos+ is an app I always wanted personally. I had a pretty large roadmap for where I wanted to take Photos+ in terms of functionality, but being able to realize that feature set and work on Glassboard simultaneously is nearly impossible.

I handed Silver Pine my roadmap as a source of feedback on where I think they should take the product, but it’s totally theirs to do as they see fit. I am happy, however, that their 1.1 release includes support for browsing your Dropbox photo library: by far the biggest thing I wanted to add from day one.

Elements

I was unable to secure a buyer for Elements unfortunately, so it has been discontinued. Sales of Elements have not been more than lunch money and enough to cover paying my support minions for almost a year.

As much as I enjoyed working on it, the market for a paid Dropbox text editor has passed. It’s become too saturated and too mature to reasonably think you can make a decent living from it.

To the Elements fans still using the app, my apologies, but I’m a firm believer in not keeping an app around to rot over time. The good news is that there are dozens of great competitors out there you can choose from.

Focusing On Glassboard

This is it. I’m all in on Glassboard. I don’t have any other products to fall back on or bring in supplemental income.

Google is big on talking about taking moonshots with their self-driving cars, Glass, and terrifying life like robots. These are big ideas, but I wouldn’t say they are moonshots because the company is still almost entirely funded by their insane ad revenue. If self-driving cars or evil robots don’t pan out, they’re going to be fine.

I’m taking a moonshot. Glassboard is a giant undertaking and the biggest risk of my career. It’s a make or break decision that will likely shape the next decade of my career.

I’m working full-time right now to try and launch the first piece of my Glassboard overhaul this summer. At that point, I’ll start to have a pretty good idea whether this was a good idea, or whether I’m going to be heading to the local McDonalds looking for a job.

Wish me luck.

Refactoring in the Cloud - Notifications

One of the things I have been thinking about a lot recently is the architecture of Glassboard. Now that I have everything mapped out for where I want to take Glassboard’s direction going forward both financially and functionally, it’s the time to look at how to actually build that functionality into the existing code base.

The Current Glassboard Architecture

Glassboard’s backend is powered by Microsoft Azure. In terms of computing, there are three main components: two worker roles and one web role.

Azure defines a Web Role as a server that has a running copy of the IIS web server on it, so that users can connect to it. A worker role doesn’t run IIS, but is still a Windows Server instance that you can use to do things like background processing on it and offload some of the heavy activities from your main server role.

This is a rudimentary diagram of the Glassboard architecture as of April 2014.

Glassboard's Architecture

  • The Kitchen Sink Web Role: I currently deploy a single web role that autoscales between 2 and 4 instances based on user traffic. This single web role does a lot. It handles all user authentication and signups as well as managing and distributing the Glassboard JSON API (through WCF god help me). In addition, it also has a few web hooks connected to it, and the Glassboard web app which is a rudimentary ASP.net MVC application with a Backbone.js exterior. It’s a beast.
  • Attachment Processor Role: When you upload a photo or video to Glassboard, it’s thrown into this role to do some post-processing like rotating it to the proper orientation and compressing to save us some server side bandwidth. Right now it’s using ffmpeg, Handbrake and a bunch of scripts to accomplish this. It’s more brittle than Greg Oden’s knees. We’ll get to refactoring it eventually.
  • Notifications Role: The Notifications Role handles distributing all the push notifications and emails that are sent out through Glassboard. Currently it supports Apple’s Push Notification Service, Google Cloud Messaging, Google’s legacy Cloud to Device Messaging, and Microsoft’s legacy Windows Phone Notification Service. Email is distributed via Sendgrid.

Everything in the current Glassboard architecture is housed in a single Visual Studio solution with about 36 C# projects in it. It’s a lot of code to manage. Luckily it’s also well tested, which makes it easier to manage.

Current Notification Role Issues

There are a few technical and ideological issues I have with the current notification architecture.

To send messages between the web role and the attachment processor and notifications roles, I use Azure’s Storage Queue mechanism to pass messages. When you post a message to one of your boards, the web role generates a new XML payload in one of our storage queues that the Notification Role listens for to handle the processing.

Sometimes this queue and the processing gets extremely backed up. Usually the CPU usage spikes to around 90% or higher for long periods of times which can lead to message postings being delayed for several minutes (in some cases I’ve seen hours) at a time. This is no good, especially when building a messaging service.

I’m not sure what the cause is for the spiking CPU other than a lot of delicate C# threading issues which I’m guessing are running amok.

The other issue I have with the notification role is how much of the code for things push notification services is in-house built. At the time Glassboard was originally built a few years ago, there weren’t too many open source solutions for handling push in C# I’d imagine.

I’m fairly conservative when it comes to third-party dependencies, but for things like push notification services there’s not much sense in maintaining your own code library to connect to the service when there are a few good solutions out there used by hundreds (thousands?) of startups and businesses around the world. They’re well implemented, battle tested, and code that is maintained by the community.

Being on C#, that limits the amount of options I have for dealing with push providers. PushSharp seems to be the main provider out there.

The New Notifications Role

Given that I’m not a fan of the C# threading model currently implemented, the amount of code used to power something that’s relatively simple, and the homegrown nature of many of the push wrappers we’re using, I made the decision to rewrite this portion of Glassboard’s architecture using Node. Hang on. Put those Buzzword Bingo cards away. I’m not a fan of rewriting for the sake of rewriting either.

Ultimately, my decision to switch to Node is all about code management. I’m confident I can accomplish the goals of my notification roles with a lot less code using Node than C# thanks to it being a bit less verbose of a language and a variety of NPM packages I can take advantage of for handling APNS, SendGrid, and GCM. The less code I have to manage and maintain, the easier my job is as the sole developer of Glassboard.

I don’t believe I will have any performance degradation in switching from C# to Node for this portion of the code either, though it’s hard to tell before actually writing the code. If anything, I’m optimistic that performance will improve.

A Fork In The Road

There’s two different ways I can approach handling push notifications being distributed through my new worker role. The first is to use these npm packages like node-gcm and its similar ilk to distribute the messages myself like I have always done. The difference being mostly in the language being used (Javascript versus C#).

The other option is to take advantage of Azure’s Notification Hubs which will handle distributing the messages to devices for me. Notification Hub has some advantages that stand out to me:

  • It works with all the platforms I care about: APNS, GCM, and WNS.
  • It handles platforms I don’t care about, but might again someday: Kindle.
  • It does all the device feedback management for me so I don’t have to keep track of which devices I should be adding or removing (such as when a user installs or uninstalls Glassboard).
  • Tagging devices based on certain features seems appealing. For instance, I could tag all of a user’s devices by their UUID and then easily distribute a message to all their devices in one message.

This all sounds great. Why not just do this? Cost.

Notification Hubs are another cost layer on top of the existing charges I’m paying Microsoft for my cloud instances and storage. I’m still in ‘losing money’ mode with Glassboard, so I’m trying to be fairly conservative with my spending.

Glassboard currently sends around 150,000 emails a day according to Sendgrid, but I have no idea how many push messages it sends because it has never had a way to track that sort of information. If I opt into Notifications Hub, I’m likely going to be out at least $200 extra a month, but that could also sky rocket to an even higher amount.

Now you understand why I am giving so much important to data and analytics these days.

My gut says use Notification Hubs. My wallet says roll my own.

Service Bus vs Storage Queues

One last thing I’m still debating is whether to keep using Azure’s Storage Queues for managing the messaging between the different components in my cloud stack or to use the new-to-me Service Bus functionality, which looks to offer a few more features. The Notification Hub functionality Microsoft offers is powered by the Service Bus, which has me considering the switch.

There are plenty of decent articles out there comparing Service Bus vs Storage Queues, but from a more abstracted level that leaves me still questioning which way to go. The conservative developer in me says keep using what I’ve already got because no major Service Bus feature stands out to me as a must-have right now. The liberal developer in me sees Service Bus as the more modern architecture that will likely be able to grow with me as Glassboard (hopefully) expands in years to come.

Feedback certainly welcomed.

Writing The Code

Even though the core architecture of two worker roles and a single web role won’t change with this refactoring of Glassboard’s notification architecture, hopefully this has been at least a little eye opening in terms of how Glassboard is built, and how I envision it being built going forward.

The obvious next step is to write the code, which I started earlier this week by writing the unit and integration tests for the new Node code base.

Since I spend so much time in Visual Studio these days, I thought I’d give the Node tools that Microsoft released a try. Then I remembered that while I love what Microsoft is doing with the cloud and Azure, Windows is still Windows.

A More Responsive carpeaqua

Just a short note to point out that carpeaqua’s design has been refreshed to finally support a responsive layout that should render much nicer on your phones and tablets. It’s something I’ve known I needed to do for a while, but never seemed to get around to.

Thanks to Michael Tofias for being annoyed enough at this to agree to take on the challenge. He is a scholar and a gentleman.

Data Analytics That Matter

Data analytics gets unnecessary grief. When most people think of analytics, they envision Google or Facebook following your every move on the web to figure out what sort of ads to show you while you are browsing. This is pretty creepy.

Admittedly, it’s pretty easy to shift over to the creepy side of analyzing user data, but that doesn’t mean that all data analysis is bad. In fact, it is essential if you want to run a successful product.

When I took over Glassboard, there wasn’t that much data on how the service was being used. None of the apps used analytics, and the server side generated a basic report that contained some basic vanity analytics such as user signups, boards created, statuses posted, and the like.

This is interesting information to notice from high-level analytics like user signups growing or dropping off, but it doesn’t tell us who is using the service or how they are using it.

Why Analytics Matters

Who, how and why are the most important questions you want to answer when you are starting to work with data analytics in your mobile products.

  • Who answers what the current audience for your product is. Your audience dictates how you should charge, what features you should add, and what marketing opportunities you may have as well. If you don’t understand who your audience is, pricing and targeting becomes really difficult.

  • How answers what ways users are using the product. Are you primarily getting users on Android? iOS? What’s the breakdown of iPhone vs iPad? How’s the web app doing? You want to put most of your attention on the platforms people are using, so knowing how people are using is important.

  • Why answers the reasons that someone is actually using your service. This one is a bit more difficult to gather without crossing the creepy line, and I’d argue its less important than the first two. There’s ways to gather this information without crossing the creepy line, which I’ll cover later on.

Choosing an Analytics Provider

Choosing an analytics provider is important. I have two rules for it:

  1. You should be paying them money.
  2. They shouldn’t be using your data for other things like selling ads.

Since Glassboard is an inherently private service by default both of these are essential. All of our board information is encrypted on the servers so that prying eyes can’t pry. I want to understand my user base (in an anonymous fashion), but I don’t want those users to be pawns to be used for a marketing company to sell ads off of.

Right now I am using Localytics, but I’m in the process of switching to Keen, because I haven’t been getting the value out of Localytics to justify its $500 price tag. Keen’s pricing and feature set seems much more promising to me. Mixpanel is probably the other major player in the mobile analytics game. They offer some powerful functionality as well.

Each of these services is going to likely run you into the hundreds of dollars range if you have a marginally successful application. The obvious goal is to be able to use the information you garner from these analytics providers to make informed decisions to help you grow your app’s reach and in turn drive more revenue your way.

Vanity vs Useful Analytics

If you’re just focusing on the vanity analytics such as how many users you have, it’s very unlikely that you’re going to get your money’s worth out of any third-party service. What do I consider vanity analytics?

  • Active users
  • Usage regions
  • Amount of a certain type of data created daily
  • Device breakdowns between iPhone and iPad

This is useful information, but it’s also pretty easily to generate yourself for much cheaper. Alternatively, it’s something you can just check periodically rather than something that needs care and attention on a constant basis.

The real power of analytics comes when you start to understand how your customers are using your app.

  • How long are they staying in it?
  • How many people are viewing your upsell prompts? How many are converting?
  • What’s the average time between a new user signup and the time they start paying for the product or service?

You get the idea. These are hard questions to ask and creating the tools to generate that sort of data is non-trivial. But, when you can start to understand how long someone is staying in your app, you can start to adjust the design of the app to either increase or decrease that engagement.

If you aren’t getting a high enough conversion rate on your premium upgrades, you can start tinkering with the wording or page layouts to see if that will either increase or decrease your conversions.

If you’re getting a bunch of non-paying free users, you can use data to start to understand why they aren’t paying. Maybe your free plan is too generous? Maybe they are just downloading the app and never using it after that first launch? Maybe they are just cheap?

Analytics Through Customer Feedback

Automated usage analytics is a useful metric to have, but far more useful is understanding your user base personally. When I first took over Glassboard, I didn’t really understand who the user base was. I knew how big the active base was, but in terms of who was using the product? It was just guesses and assumptions.

The first thing I did when Sepia Labs handed over the keys was to send out a short user survey using Survey.io to all of the existing premium users to introduce myself as the new owner of the service and to get an understanding of how they were using the product.

Glassboard’s premium user base is far smaller than our free customers, but since this is a bootstrapped company, they are the more important customers during the acquisition. I wanted to understand how the people who supported the service in the past were using it so I can continue keeping them happy going forward.

Our premium user survey had a 70% response rate, which was insanely high. It shared with us a lot of useful information about how Glassboard is being used (many ways I didn’t even imagine!) as well as what alternatives people would consider, which is a pretty good way to learn about some different competitors you may not have heard of.

Another thing I implemented when I took over Glassboard was a ‘personal’ email that is sent out to users a few days after they sign up. It comes from my email address and is basically a prompt to gather direct feedback from our newest users.

Hi [John Doe],

I’m Justin Williams, the CEO and lead developer of Glassboard. I wanted to see how things are going so far.

If you have any questions, feedback or need help with anything at all, reply to this email and I will get back to you with a personal reply.

Thanks again for using Glassboard!

I receive a few responses a day from this, which has been really useful for understanding who is signing up for the service, how they are using it, and (most importantly) what they are finding confusing or hard to grok about Glassboard. By far the biggest source of frustration these new users have is the onboarding experience.

When you sign up for a new Glassboard account through the apps, it creates your account and your first board called “[Justin’s] Board”. It then drops you into an empty news feed. Hardly ideal.

The feedback I’ve received from many users is that they are confused at this point, which is really good personal data. It shows that I have an opportunity to improve the onboarding experience to hopefully receive a more positive response about functionality in the future. We’re working on it now.

Always Keep Tweaking

I’ve been sending the email above for the last few months, and the value from it has diminishing returns at this point. I’ve recently noticed a pretty major influx of new users coming onto the service, but I don’t really have a good idea where they are coming from right now.

I’m thinking my next goal for these new user signup emails will be to just plainly ask users to tell me where they heard about Glassboard and what they are using it for. I may get less of a response back, but the data that does come in will be interesting to see if the understanding I have of my audience from earlier this year still matches the new users signing up as of April 2014.

Data is only as useful as it is current. Long-term trends are meaningful in some use cases, but when you’re in the middle of trying to turn around a ship as big as Glassboard, the past isn’t nearly as important as the present. Understanding your current users is essential to being able to build and sustain a successful product in this new app economy.

Build 2014

I spent last week in San Francisco at Microsoft’s Build conference. Build is an annual (at least I think it’s going to be) event the company holds at Moscone West to share their latest offerings for Windows, mobile, and Azure. I’m not a developer for any of the Windows platforms. Glassboard, however, runs on Microsoft Azure so I was interested in attending both to learn about the new offerings and to put some names and faces together with people I’ve started interacting with recently.

Overall it was a positive experience as someone who only recently dipped his toes back into what Microsoft is doing recently. The last time I used (or even cared) about Microsoft technology was the late 90’s when they were a giant, evil corporation who was charged with being a monopoly. I switched to the Mac when OS X was announced in 2000 and hadn’t really touched since.

Fast forward 14 years later and Microsoft seems to be a whole new company. New products. New CEO. New development offerings. And less of a focus on Windows, Windows, Windows.

Sure, Windows is a key part of the Microsoft ecosystem (and rightly so), but it also no longer seems to be the central focus that directs everything they do. I sat through two THREE HOUR (emphasis mine because oh my god so long) keynotes that prominently featured iOS devices, the Apple logo, iPads, Androids, and even Linux. A few years ago this was the company that dismissed iOS as a failure to launch and instead focused on how they could go from a Windows computer on every desk to a Windows Phone in every pocket.

Windows Phone is still a key piece of technology for them (and 8.1 looks great), but they realize that integrating their services into the other platforms as first-class citizens is best for business.

Whether this was a plan set in place by Ballmer before he left, or new under new CEO Satya Nadella’s watch I don’t know. As an outside just starting to look in, however, it’s refreshing.

A True Partner

One of the biggest differences I noticed between an event like Build and WWDC was in the subtle messaging. Both Apple and Microsoft are massive companies that make billions of dollars and answer to their shareholders. Both companies also offer development platforms for third-parties to integrate with.

What’s different though is that it feels like Microsoft is more interested in working with us as a partner whereas Apple has always given off a vibe of just sort of dealing with us because they have to. Maybe that’s a little sour grapes, but as a developer it was a nice change.

Build was announced far in advance allowing people ample time to schedule and book their travel. Microsoft released the full schedule of the event the night before so you could plan your week out in advance (or just decide to wait for the videos later on). They even provided previews (and access) to upcoming technologies that aren’t ready just yet, but to give us an eye on where they see things going.

It was cool to get a free Xbox One to play Titanfall on, but they also had several sessions during Build that talked about how to actually build an application that can run on that Xbox so that when the time comes that they release a full SDK and support for that, developers will be ready. They provided that to everyone, not just a few select partners that also share a stock ticker symbol.

Open Source

Microsoft isn’t exactly a showman company. The keynotes were well presented, but they also lacked the pizazz of an Apple event where everything feels as cool as a night out with Frank and Dean.

The one area where I sat up and thought “OK, that was cool” was when Anders Hejlsberg publicly open sourced the new Roslyn C# compiler platform on the Keynote stage at the end of his demo.

Roslyn is a key piece of technology for the future of Microsoft and they’re now managing it as an open source project. This allows for a few things: outside contributions and feedback on the platform from fellow developers for one. More importantly, it allows the Xamarin folks who had implemented their own C# compiler to work on MonoTouch. It’s now possible for Microsoft and Xamarin to collaborate together on a single compiler rather than both building in parallel.

Apple has the LLVM project, which is similar in many ways, but I also can’t imagine them working with a third-party vendor such as RubyMotion (for lack of a better example) to make their jobs easier.

I still hope that some day Apple will open source the core iOS and OS X frameworks the same way Microsoft does with .Net and Google does with Android. I’m not holding my breath, but I can dream.

Overall though, Microsoft seems to be embracing open source in new and interesting ways that the old Microsoft never seemed to care about. Previously when they open sourced a piece of technology it’s because they were no longer interested in it. Now, key pieces of functionality that the future of the company is based on are out in the open.

Bizarro WWDC

A week or two before Build, I received a text message from Dave Wiskus of Q Branch/Vesper asking if I was still attending Build. He then informed me that he, Gruber and Brent would be attending the conference as well as part of the keynote.

2.5 hours into the second day keynote, lo and behold my long-time Mac and iOS development friends showed up on a Microsoft stage talking about how Vesper’s sync services are powered by Microsoft Azure.

None of those guys are Windows users. None of them are Windows Phone users either. They’re happily using Microsoft’s cloud services platform to power the backend of their iOS only app.

It was a bit surreal to experience Moscone West with a few other long-time WWDC attendees and compare how similar (and positive) our experiences seemed to be. Outside of there being a DJ spinning house beats above a sea of coding nerds on level 2, we came away impressed.

Showing The Other Side

If you follow me on Twitter, you were probably pretty tired of seeing me tweet things with hashtag #bldwin (you’re lucky I was kind enough to hash them so you could mute if desired). The reason for the excess tweeting was twofold:

First, I tweet a lot anyway. Second, and more importantly, I know my audience is primarily filled with Mac and iOS developers. We’re all fairly busy people and may not always look up to see what is happening outside of the Apple ecosystem.

Build allowed me three days to immerse myself in technologies that I know almost nothing about. I came away impressed with it too. For all its past faults, the New Microsoft is doing things that are on the cutting edge of technology. Their Rx extensions library is everything I hope ReactiveCocoa could be: a fully functional extension to the core C# language built and maintained by Microsoft. Their unit and integration testing story for Windows Phone is light years beyond what either Apple or Google offer for their respective mobile platforms.

Avoiding Longhorn 2015

John Siracusa has a famous article called Copland 2010 where he talks about Apple’s need to begin looking for a replacement for Objective-C and the Cocoa frameworks before they get to the point where it’s too late and they’re in for several years of hurt much like the transition from Classic Mac OS to OS X.

I still love Objective-C and the Cocoa frameworks, but having worked on Glassboard’s Azure backend and Android app in parallel, I’ve seen a different world outside of the Apple prism. What we have is good, but there’s so much more potential to be great with the emerging and more modern development technologies out there.

With things like C#, the Roslyn compiler/frameworks, and the modern WinRT runtime, it feels like Microsoft is way ahead of Apple in the future looking regard. As a developer, I’m jealous of a lot of the technologies coming out of Microsoft. As a user? They’ve got a long ways to go before I consider using Windows over a Mac.

That said, this is the new Microsoft. They don’t need me to use Windows or Windows Phone as long as I use Microsoft services like Azure, Office 365 and the like.

I can’t believe I’m excited about and interested in working with so many Microsoft technologies. The times are a changin’.