One of the Twitter searches I check every few days is for “Auto Layout”. Twitter is a wonderful place to find people complaining about technologies, and pretty much the only information you’ll see on the Auto Layout search for Twitter is complaints and confusion.
Recently, I read an article from Brent Simmons on his struggles with adopting Auto Layout in Vesper. He claims its kryptonite in a lot of ways and causes more struggle than it’s worth sometimes. Brent is a smart guy, so seeing him fighting the technology isn’t a good sign for others who are just coming to iOS or OS X having much better luck.
Maybe I can help a bit.
Why Auto Layout Exists
Springs and struts has existed nearly as long as I have been alive, so why did Apple even bother doing something like Auto Layout? Springs, struts, and auto resizing masks weren’t necessarily broken, so no need to fix it, right?
Ultimately, Apple believed they were building something better in Auto Layout. Auto Layout offers a lot more functionality and power when building complex layouts in exchange for changing how you think about building your interfaces.
Rather than placing your views on the screen, Auto Layout is about describing the relationships between each of the views and how they relate to either its superview or adjacent views. On the surface, it’s far easier to say that you want to center a button vertically and horizontally in its parent view with an NSLayoutConstraint call than it is to do the math to calculate the exact CGPoint you want to place the button on screen.
From a fussy developer perspective, Auto Layout also helps alleviate some of the Massive View Controller problems that have plagued developers over recent years. Things such as the intrinsic content size and alignment rects allow us to do a lot of view sizing calculations in the view subclass where it belongs rather than in your controllers.
Finally, Auto Layout also enhances the usefulness of Interface Builder, a tool that has been around for decades and is one of the major selling points Apple has when showcasing their developer platform. It got off to a rocky start with Xcode 4’s frustrating Auto Layout implementation, but Xcode 5 has been great.
Debugging Constraints
While the learning curve of Auto Layout isn’t as bad as it once was thanks to the vastly improved support in Xcode 5 and 5.1, there’s still plenty of issues you run into when you are coding up and debugging your constraints-based layouts.
In Interface Builder, debugging constraints is nicely done. If you’ve got misalignment, conflicting constraints, ambiguous layout, or a variety of other issues that could plague your UI, Xcode will instantly warn you and offer ways to resolve the issue. I believe this has helped people immensely understand Auto Layout better.
If you need to work outside of Interface Builder, Apple’s debugging advice for constraints is fairly caveman. There are a few lldb commands such as _autolayoutTrace and exerciseAmbiguityInLayout that can help you figure out how to resolve your issue.
One thing that I don’t think too many people know is that there is an Auto Layout instrument in the Instruments app that you can use to observe what is happening to your layouts in real-time. There are a few caveats to using it on iOS, however.
It only works in the Simulator.
You’ll need to manually add it to a blank Instruments document from the tools library.
Finally, one of my favorite tricks is to set a restorationIdentifier for every view in an iOS view and then using that to help visualize and understand constraints when printing them out in lldb. Here’s a debugging category I use to accomplish this.
With this in your project and your restoration identifiers set, the values output by po self.view.constraints becomes a lot easier to read and understand as well.
It’s Apple’s Turn Again
I was hoping that almost a year after I started pushing the gospel of Auto Layout that we’d be past the point where people are still fighting the technology, but sadly we’ve reached the point where I believe it is on Apple to improve the tools and documentation for Auto Layout if they want to continue to see its adoption grow.
My biggest request? NSWindow on the Mac has a visualizeConstraints method that makes it easy to see what each of your constraints is doing in a running app. Having something like that that applies to any UIView would be immensely useful.
On top of that, the ASCII language, while powerful, offers no real-time syntax checking which leads to a lot of cavemen build/run/check scenarios when you forget a bracket or mislabel something.
And finally? A less verbose syntax. I’ve watched more than a few eyes glaze over when I try to verbally read out “constraint with item attribute related by to item attribute multiplier constant”. There’s opportunities to shrink and simplify that syntax for a variety of common scenarios such as vertically or horizontally centering a view with another view. In fact, if you search GitHub you’ll likely find a dozen different short-hand projects that do just that.
WWDC is just around the corner. Auto Layout isn’t the sexiest technology Apple can highlight during its keynote, but it’s one of their most important going forward. It’s true you don’t need Auto Layout to deal with different screen sizes and orientations, but I sure don’t want to go back to doing it the old way. As Apple starts dealing with different screens in the future, making sure that Auto Layout is at the forefront as an accessible and understandable foundation for layout is essential.
As I mentioned recently, I am working on a refactoring of how Glassboard handles its push notifications system. The short-version is that the current incarnation uses an Azure Worker Role to handle messages of a Storage Queue via C# and a lot of custom written code for tying into each push notification provider we use.
When we last spoke, I was pretty convinced with throwing out the C# code in favor of a Node and TypeScript flavored solution. I was also debating using Azure’s Notification Hub service for delivering the pushes to further lessen my code liability. I have been working on this for the past few days, but it hasn’t been going exactly as I had hoped.
For those that don’t know, TypeScript is a language layer similar to Coffeescript that compiles down to plain old Javascript. It’s got a great syntax that allows you to have typed variables, and just hit 1.0. TypeScript also allows me to be a lazy developer because it integrates natively with Visual Studio’s intellisense. Given that I’m spending most of my time in Visual Studio working on this backend provider, it made sense to give TypeScript a whirl.
If you’re interested in seeing some sample TypeScript, here’s a snippet from Glassboard. I really like the syntax, though having to write my own accessor methods is very cave man.
Microsoft also recently went to a 1.0 beta with their NodeJS tools for Visual Studio that make it super easy to build and deploy Node to Azure. Since I am working with Azure’s storage and CPU emulators in Windows already, using these tools made sense too. I’ve never had much luck bridging the emulators from my VMWare instance to my Mac’s network stack anyway. The Node tools also have built-in support for debugging Node both locally and remotely, which is super awesome.
So, good language. Good toolchain. What’s the matter?
It turns out that Windows has a really annoying problem with long file directory paths. In short, a file name must be less than 260 characters, and a directory path must be less than 248 characters. Otherwise, you get this error constantly.
Unable to copy file ".node_modulesazurenode_modulesrequestnode_modulesform-datanode_modulescombined-streamnode_modulesdelayed-streamtestintegrationtest-handle-source-errors.js" to "objDebug.node_modulesazurenode_modulesrequestnode_modulesform-datanode_modulescombined-streamnode_modulesdelayed-streamtestintegrationtest-handle-source-errors.js". The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. C:Program Files (x86)MSBuildMicrosoftVisualStudiov12.0Node.js ToolsMicrosoft.NodejsTools.targets 74 5 Cloud
Now, imagine you are working with a framework like Node that relies heavily on package modules, which also rely on package modules, which also rely on package modules. You’re going to run into this pretty much every time you build.
I tried working around it at first by mapping a virtual drive for my Development projects, but the nested node modules still became too much for Windows 8 to cope with.
This is a bummer for a variety of reasons. For one, using the Node tools for Visual Studio is nearly impossible for any development situation that relies on a suite of npm modules. As you can see from the error above, I’m trying to use Microsoft’s own Azure module and running into the issue. It pretty much prevents me from building my project and testing it locally in Visual Studio.
And as a developer, I’m bummed for the people working on the Visual Studio Node Tools project. They’ve built something really great, but I’m struggling to use it because of a long-time Windows bug (yes, this is a bug).
I will never complain about HFS+ again.
I have a few options to deal with this issue.
Keep going ahead with what I’m doing and hope that one day Windows stops being Windows.
Work on getting the Azure Emulator to work through VMWare to my host Mac so that I can write the TypeScript code in Sublime Text natively on my Mac.
Throw away two or three days worth of work and go back to a C# solution that likely won’t run into this issue since its dependency model relies on namespaces rather than directory structure.
I’m leaning towards option 2 or 3 even though the Stubborn Developer wants to take option 1.
Option 2 is nice because I can still use TypeScript and Node to manage this portion of the project. I’m pretty sure I can figure out the VMWare issues I’ve had if I sit down for a few hours and tackle it. The tradeoff is that Sublime’s TypeScript support isn’t nearly as powerful as Visual Studio. I’m a lazy developer. I like my tools to enable me to be as lazy as possible.
Option 3 is appealing because I have a good chunk of the code already written in the legacy system. Since I’m switching to Notification Hubs, I can trash a good chunk of the existing code base and wrap it in the Azure SDK’s handling library.
Thanks to an Azure Friday series of videos I’ve got a better understanding of how to handle not using threads to manage the processing on the Worker Role as well.
I’m taking a day to weigh the pros and cons so I can choose which route I want to take. Until then, the lesson learned from this is that new and shiny doesn’t always mean better. Now I’m behind on my ship goal by several days.
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.
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.
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.
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:
You should be paying them money.
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.
