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’.

The Parts of Your Platform

The simpler devices get, the more complex our jobs as developers becomes it seems.

When I first started my independent developer career way back in the dark ages of 2006, building an app usually meant building a desktop product that persisted data locally. In some cases there was an Internet backed service tied to it, but it wasn’t the norm. This was before Dropbox, people.

If you truly wanted Internet connected services, you built web apps. Using a mix of HTML, CSS and a sprinkling of Javascript you could build web pages that could replace your desktop apps with something that could run on any device and any browser.

Once mobile came on the scene, web apps weren’t as ‘sweet’ a solution as some would have liked us to believe. The pendulum swung back towards native app development, but with the added bonus of being network connected at all times.

For an app that connects to a third-party service such as Dropbox or Twitter, always-on connectivity means implementing a third-party API in your app and using that as the foundation for your data access. It’s a little more work than our desktop days, but certainly not that big of a hassle.

Fast forward to 2014 and you’re starting to see convergence of mobile and those web technologies. Mobile apps from smaller developers are starting to offer online services either as a value add (such as the wonderful Day One app) or as the foundation of the service (such as Glassboard or soon-to-be from Vesper).

Mobile apps requiring their own custom backend data isn’t new for many operations, especially those with a large staff and a bankroll of venture capital money to burn. For the mom-and-pop shops like Second Gear and Q Branch, it’s a whole new world that just became more feasible just recently.

So, what changed?

App Pricing And Expectations

When I released Photos+ last year, one of the biggest sources of feedback I received was “where is the iPad version?” Nevermind that I just spent several months perfecting the iPhone version, consumers expected that the app would be run on all their iOS devices.

Beyond just expecting your app to run on both an iPad and iPhone, users also expect that data to sync effortlessly between those devices.

Implementing that amount of functionality isn’t impossible, but at $2.99 per app or so it becomes really hard to make the economics work in your favor. If you can instead sell a service for a monthly or yearly fee, however, and then give the apps away for free it becomes a bit more feasible to make the economics work. Still difficult, but at least less of a crapshoot.

The Cloud!

Everything is in the magical Cloud now. All your files are on Dropbox. All your photos in Photo Stream. Everything else in Evernote.

Cloud computing has eliminated the need to be a sysadmin and host your own server hardware in favor of renting resources in the cloud. Amazon, Microsoft, and Google are the big three and are all jockeying to lay claim to all the CPU and storage on the web.

Glassboard runs on exclusively Microsoft Azure. All user data is encrypted and stored in Azure Table Storage. Images and videos live in Azure Blob Storage. The actual platform app itself runs on an Azure Cloud Service, which makes scaling as easy as adjusting a few sliders on the Azure web site.

Backend as a Service

Take the cloud computing paradigm, and simplify it even further and you get Backend as a Service. With a BaaS provider such as Parse, Google App Engine, or Azure Mobile Services, you don’t even have to worry about provisioning resources on the cloud. Instead you just import an API wrapper into your mobile app and configure a few cookie cutter options on the BaaS provider’s web site.

These providers make cloud-enabling your product incredibly simple. The tradeoff of using one versus the more traditional ‘cloud’ is that costs rise exponentially much quicker. It’s a tradeoff that many are willing to make, plus competition has made pricing a bit more competitive than it was even just a year ago.

The Parts of a Platform

We’ve accepted that running our own server-side resources is becoming a reality, we should analyze what that really means. And more importantly, understand what is involved.

1. The API

The brain of that powers any cloud-enabled service is its API. It doesn’t matter what language you write it in as long as its secure, stable, and reliable. Glassboard started out as a full C# product, but I’ve been rewriting parts of it in Node where it makes sense.

Most of the time your users won’t see your API firsthand, unless you offer it publicly as a value add to your customers. Whether it’s a public API or not, versioning from the start is always a good idea. You’ll inevitably get to the point where you want to add or change your API’s functionality. By versioning your API from the start, you can ensure that legacy clients aren’t immediately cut off as you improve your product.

If you’re running a marginally successful service on an API, it’s worth your financial and time investment to look into services like New Relic and Runscope. New Relic does magic things to figure out bottlenecks and other slowdowns in your API clients. Runscope is an API monitoring service that lets you test the health of your API as you run a suite of tests against it.

2. The App(s)

Whether its iOS, Android, Windows Phone, or OS X, the app is the nut of any platform. It’s what your consumers will predominantly use to interface with your service and will shape their opinion on it.

This is likely going to be where most of your time is spent, assuming you want to build something that stands out in such a crowded market. There are plenty of hybrid app solutions that can get you on all platforms quickly, but quick doesn’t necessarily mean quality.

Glassboard has native Android and iOS clients. Each one is built using the system-specific APIs and designed to look and behave like a first class citizen on their respective platform. It’s far more work (and cost) than the hybrid approach, but I believe a better app experience in turn leads to a better conversion rate to paying customers of the service.

3. The Management Backend

This is the one most people forget. Once you’ve developed your API and built the app(s) to consume it, you likely have a user base that is going to be emailing in support requests and bug reports. Those requests likely mean you need to look into the data stored on your backend.

You aren’t an animal. Running raw SQL queries from the Terminal is neither safe, nor ideal. You need yet another app for your platform. The only difference is that this one is for internal use only.

The admin portal is the piece that most developers forget about until after they’ve shipped, but it can also be one of the most important part of your product once you reach a level of success. Let’s imagine you outsource your support to a third-party company (I recommend and use AptFolk). Ash and crew are a smart group, but they don’t know the internals of your product or how to connect to your servers. Nor should they need to. By offering a web or mobile app that allows them to look up and adjust account information or whatever else is relevant, you’re making your job easier.

Beyond just support, metrics are essential to measuring success or failure. There are simple vanity metrics that are useful for showing on an app like Status Board:

  • Daily signups
  • Active users
  • [Your Specific Data] created
  • Daily/Weekly/Monthly Revenue

For more advanced metrics, I recommend a third-party provider that specializes in things like customer segmentation, funnels, and other more advanced functionality. I use Localytics, but I’m actively shopping for an alternative. Mixpanel is also a nice service, but gets expensive real quick.

Every Piece Matters

The good news is that even though our jobs as app developers is becoming more all-consuming, the tools that enable us to do this are becoming far easier to use. I couldn’t imagine running my own servers back in 2008, and now I don’t have to. Cloud computing takes care of the heavy lifting and let’s me focus on the product itself.

Just because I don’t have to worry about imaging and provisioning servers doesn’t mean I can slack on other parts of my product’s development cycle. The API, apps, and backend platform are all equally important pieces of the puzzle that defines your product. The app may be the only public facing one, but without the API it doesn’t exist. Without the backend management portal, supporting your user base becomes a nightmare that impedes development.

Treat each piece of your product’s stack like it’s the most important, user facing portion bit. Quality isn’t just mean for the surface.

The Full Stack App Developer

Whenever I look at job boards, I notice that a lot of web development jobs are wanting someone who is a ‘full stack’ web developer. To me, that means someone who can build the front end of the application using HTML, CSS, and Javascript as well as the backend using whatever server-side framework is in there. To top it off, sprinkle in a bit of knowledge on cloud computing.

The ‘full stack’ paradigm is starting to make its way to app development going forward as well. It’s no longer enough to just know how to write code for a single platform. To be truly relevant and valuable you need to have an understanding of API design and implementation and cloud computing as well.

Ignoring the cloud or web services because they are out of your comfort zone is no longer an option. The app economy is shifting. Adapt or die.

How I Evaluate Third-Party Dependencies

How do you manage your iOS app dependencies?

This is a question I’ve answered more than a few times the past few months.

Answer: with as few third-party dependencies as possible.

A bit cheeky, yes, but there’s truth in it. As I’ve matured as a professional developer, I’ve learned to understand that a dependency and liability are many times interchangeable.

In general most of the projects I work on have as few third-party dependencies as possible. I do my best to work with what is provided by Apple’s frameworks, as well as my own suite of categories and subclasses I’ve accumulated over my years as a developer.

When something new and shiny comes along that I’m thinking about using, I have a few questions I ask before making a decision.

1. How long would it take me to write my own version of this?

Are we talking about a single class and header file that does something fairly basic that I could churn out in a few hours, or something more feature-filled and complex that is represents weeks or months of work.

Single classes I am more than likely to write on my own. Something heavier like CocoaLumberjack (which is awesome) I am likely to include as a dependency.

2. How well maintained and supported is the codebase?

Is the project actively maintained by a developer, or are we just talking about a code dump that’s just been thrown on GitHub? Is there documentation? At a minimum, is there header docs?

Open source contributors are under no obligation to provide support for their projects, but at the same time, I’m less comfortable basing a major part of my project on something that’s just out there on the web without any direction.

Projects like AFNetworking and ReactiveCocoa come to mind as good, well moderated open source projects.

Sidenote: It bugs me when people look at a codebase that hasn’t been updated in a year and claim it’s been abandoned. Projects can be completed without being considered abandoned.

3. Can I understand the code base enough that I’m comfortable patching/contributing to it?

All software has bugs. Even yours. With a third-party code base that you don’t manage, you are likely going to run into a situation where there are bugs that need to be fixed and patched. How comfortable am I reading and understanding the code base that I am thinking about adding as a dependency? If it’s not comfortable enough that I’d be willing to patch it, I’m may not be willing to include it.

One exception to this is the HockeySDK and PLCrashReporter. I have zero idea how that stuff works because I am not Landon Fuller or Mike Ash. I think they actually speak binary as a first language. Even thought I don’t understand the internals, I depend on Hockey for managing my betas and crash reports. Wonderful service.

4. How much of this code will I actually be using?

A lot of developers have the tendency to instantly import AFNetworking into their project without a second thought. It’s a wonderful resource for the community and something I have used in my own projects. At the same time, it’s a fairly heavy library that does a lot.

If you’re building an API wrapper for a third-party web service, do you really need all that AFNetworking offers or are you just using maybe 10% of its features to accomplish your goal? More importantly, if you are offering the API wrapper for consumption by the open source community, do you really want to force another third-party dependency on them?

With OvershareKit, Jared and I try to err on the side of conservative when it comes to adding external dependencies to the library. As is, it’s a pretty heavy amount of code to ingest in your project. But, most of it is self-contained which we see as a feature, not a bug.

So….about Cocoapods

I have been hesitant to adopt Cocoapods in any of my iOS projects these past few years. I’ve also been pretty vocal about this, but without much explanation.

If you look at any other major platform in play today, they have some sort of dependency management story:

  • Node has npm
  • .Net has NuGet
  • Ruby has Gems
  • Android has Maven and Gradle

Dependency management is admittedly a problem that OS X and iOS have dealt with for years. So, Cocoapods comes along and offers a solution for the problem, but I don’t want to jump on it. Why?

For one, stability and predictability. The dependency systems for every other platform are for all intents and purposes the “official” solution. In some cases such as NuGet, they’re even baked into the IDE. Cocoapods, on the other hand, is developed outside of Apple by the community and hacked into the current Xcode workflows. That’s not to insult the developers of the project. It’s pretty impressive what they’ve made from a technical standpoint. But as cool as a project is, that doesn’t eliminate the inherent risk with using it.

Let’s assume that Apple releases an amazing new Xcode 6 this summer. It has all these amazing features that you absolutely have to use. The tradeoff is that because of so many changes under the hood of Xcode, Cocoapods is now broken and your app is no longer capable of building with the new toolset without a lot of surgery.

On a lesser level, let’s say Cocoapods switches from Ruby based spec files to another format (JSON?). Now I’ve got to spend client time just fixing my build system, which isn’t adding much value to their product.

Are these scenarios this likely to happen? I hover somewhere between ‘maybe’ and ‘probably not’.

Contracting vs Personal Projects

Having described how I analyze third-party dependencies and my thoughts on Cocoapods in general, I will say that I am now using it in Glassboard.

Wait. Didn’t I just say it’s risky to use?

Well, yeah. But dealing with risk is a key part of software development. You have to find your personal threshold and work with it.

In my case, I’m not willing to stake the dependency management of a project I’ve been contracted to build by a client on a third-party platform that generates Xcode workspace and project files on the fly and may prevent the app from building cleanly without a 5+ step setup process. For my own projects, however, I’m much more liberal in my choices.

Let’s say the mythical Xcode 6 build breakage occurs in Glassboard. It will suck, but it’s a problem to resolve in my own product, on my own dime rather than someone else’s.

My personal projects likely also have a longer shelf-live than most client engagements where the codebase evolves over time. Glassboard’s code base is over three years old and is still evolving. Many of my client engagements are to build a shippable version and then move on to the next thing. There’s likely to be a lot of built up bit-rot after a project sits dormant for an extended period of time. Dealing with that rot is part of contracting as much as it is your own projects, but I do my best to limit the amount of rot I put on myself in those client engagements.

I apply the same ‘client vs personal projects’ principle to third-party code dependencies as well. I’ve taken to using the #GlassboardNext codebase as my playground for experimenting with new third-party projects like Cocoapods, ReactiveCocoa, and Mantle even though I can’t imagine a scenario where I’d currently use them a client project (well, maybe Mantle. It’s pretty isolated.)

It’s possible these choices will come to bite me in the ass eventually, but they’re risks I’m willing to take.

I’m assuming this post will get my invitation into the “Old Guy Coders Club” where you hate anything you aren’t used to. I’ll be waiting for my coffee mug and membership card in the mail.

OneNote To Rule Them All

I’m a recent convert to Evernote. I’ve never quite understood the appeal of the service, because it seems like a dumping ground for content that will inevitably get lost, but I was willing to give it a whirl for a few different scenarios.

Overall, my one month experiment with Evernote was a success. I even signed up to be premium. I created Notebooks to store images related to couches we were looking to be. I have a Glassboard notebook with random notes, images, and other bits of info related to the future of the service. I also began using Evernote as a destination of presentation slides I wanted to peruse when I had a few free moments.

The success of something like Evernote is its ecosystem of apps. To become “locked in” to a product like Evernote, it has to be ubiquitous with every platform you care about. It’s not enough to just have an iPhone app and a web app. You need iOS, Android, Windows, Windows Phone, and the web. 1Password is another product that succeeds at this. They’re seemingly everywhere, except the Blackberry.

While I have been using Evernote, I haven’t been happy using Evernote. It’s an incredibly powerful service, but it’s apps leave much to be desired. The Mac app is a mishmash of different visual styles, text sizes and odd bugs. The iPhone app is a bit better visually, but its one of the slower performing apps on any of my devices.

When Microsoft announced OneNote was available for the Mac yesterday, I quickly jumped at the opportunity to download the free app from the Mac App Store.

Sidenote: a major app from Microsoft given away for free on Apple’s proprietary App Store. The times are a changin’.

Satya’s Hierarchy of Notes

OneNote is similar to Evernote in some ways, but different in many others. The concept of Notebooks exists between both services, but OneNote allows you to create different “sections” inside your notebook and then attach pages to those specific sections. Evernote, by comparison, is just a single dumping ground for all the content in either notebook.

It’s hard to say which of these is better since everyone works differently. I personally resonate with the more structured organization of OneNote’s hierarchy. I’ve thus far created three notebooks in OneNote: Glassboard, Second Gear, and Personal.

Thus far, the Personal notebook is most interesting. I’ve broken it down into a few different sections.

  • “Home” is a dumping ground for random notes that don’t really fit anywhere else (To Read, To Investigate, Groceries).
  • “Financials” has receipts and other tax related info I need to keep track of.
  • “carpeaqua” is for any in-progress posts for this site. I have a different page for each post idea and its content.

“Lawn + Garden” is another section in my Personal notebook. I’ve become a bit obsessed recently with fixing the lawn and beddings at my new home this spring. I create a different page for each person’s advice I’ve received, archived web pages of useful info, and tools and toys I want to buy this spring.

Ubiquity & Sync

Evernote has their own dedicated backend service for storing your stash of notes and clips. OneNote piggy backs off of Microsoft’s OneDrive cloud storage service. If you install the OneDrive app on your Mac (also available from the Mac App Store), you’ll see each OneNote notebook in the Documents folder as just a standard website location file, much like if you dragged a site’s address from Safari’s address bar to your desktop.

Double-clicking that file opens OneNote.com to the document, which is weird compared to just opening the file in the OneNote app.

Since all your content is synced to OneDrive, there are apps on all the major platforms you care about: iPhone, iPad, Android, Windows, Windows Phone, and the web.

The iOS app is serviceable, but is still waiting for its iOS 7 update. Functionality wise it’s also fairly clunky compared to Evernote’s iOS app, which is saying a lot.

Creating new content in OneNote for iOS is a much bigger pain than Evernote, which conveniently has buttons for Text, Photo, Camera, Reminder, and List right at the top of its list view so you can easily create a specific type of note. OneNote instead creates a blank document and then has a toolbar along the bottom with small buttons to insert different types of content into the note.

Advantage Evernote. By a mile.

Mac App

Where OneNote shines and what got me to even try this experiment is the Mac app. On the surface, the app is really well done. It takes a lot of queues from Microsoft’s Ribbon metaphor for toolbar layouts, but I believe it’s done in a tasteful way. Yeah, it’s information overload compared to a standard OS X toolbar, but at least it feels like it belongs.

The OneNote Mac app, lets you insert content freeform wherever you want in a note. You can insert a table next to an image, with a todo list above it. I’m pretty positive that the app is using Word’s text processing engine rather than the standard OS X one (the custom dictionary settings in the Preferences is a big hint).

With the Word text processing engine you get some neat features, but you also get a lot of wonkiness you’re likely not used to. For instance, I tried to copy/paste an HTML page I had imported into Evernote to OneNote. The app inserted it as a big pile of gibberish and garbage text. Not even raw HTML tags. Just junk text.

Outside of that though, its a well done 1.0. Keyboard shortcuts feel natural. Data input is quick and works well. And there are so many different data detector types supported by OneNote that’s important.

The visual cues of giving different notebooks and sections inside them color codes is a nice touch that really helps separate content and allows me to match the styles I already use on Google Calendar. I keep personal related stuff green, work blue, and travel yellow.

Clipper

One of the new features with this new OneNote release across all platforms is their new Clipper bookmarklet, which will take any web page you clip and insert it into your QuickNote notebook.

It works, but it’s lacking compared to the Evernote clipper. For one, pages that are clipped into OneNote are imported as static images rather than actual HTML like Evernote does. I believe OneNote is doing some server-side processing to detect words in the document so that it’s still searchable, but it’s far less functional and reliable than having actual text from the document in the note itself.

There’s also no ability to select which notebook or section you want to clip directly into. It goes to your QuickNote notebook, and you will like it.

API

If you’re a developer and you’re ever asked to do work with the Evernote platform, I am so sorry. As powerful as their consumer product is, their developer offering is shit. I’ve yet to meet an iOS or OS X developer that has shared a good experience integrating Evernote sharing into their apps. The Evernote API wrapper for iOS is autogenerated from Thrift and is a beast of messy, nearly unreadable code. It also supports its own unique HTML-ish language for wrapping a notes content before insertion.

OneNote now has an API and just by existing I will conclude that it’s better than Evernote’s developer offering. The OneNote API is a familiar REST implementation and hosts example code for Android, iOS, and Windows on GitHub. I have a few nitpicks on the iOS code that OneNote’s developer team provided, but compared to Evernote I was able to understand it and pick up their platform infinitely faster.

To create new content in OneNote through their API you just post Plain Jane HTML to one of their endpoints.

Is it as powerful as Evernote’s current API iterations? Probably not? Is it easier to use? By a mile. I’ll take simplicity and ease of use over complexity any day.

TODO

OneNote has been around as a product for nearly a decade. As a Mac user, OneNote is a 1.0 and it shows. It’s a really well done 1.0, but there are some missing features and functionalities that impact my workflow.

The biggest is the lack of drag-and-drop. If you have an image you want to insert into a OneNote page, good luck dragging it from your desktop and into the app. The only way is to go to the Insert menu and insert it using a standard OS X open panel. It works, but oh so clunky.

The same can be said for dragging and dropping a document into a OneNote document. This is seemingly impossible. As I mentioned before, I like to use Evernote as a one-stop PDF store for presentation documents, receipts, and other bits of information. This doesn’t seem to be possible with the current incarnation of OneNote.

Finally, lock-in is a concern. There’s no way to import or export your data from OneNote into a format that makes me feel good and safe about my data not being lost into a single vendor’s product forever.

On iOS there’s even more work to do. Getting data into an stashbox app like Evernote or OneNote easily is paramount on mobile. Creating a new document in the right notebook in OneNote on iOS is far more difficult than it should be. There’s also no way to move a page from a your QuickNote section to any other notebook, which feels like a major missing piece of functionality.

So….which one?

This is where I’m conflicted.

From a technical workflow stance, Evernote still reigns supreme as a predominantly Mac and iOS user. The apps are more full-featured and support getting any sort of content into them with ease.

From a “this is how my brain works” stance, OneNote and me are getting along a lot better than Evernote.

I’m leaning towards sticking with OneNote for the next few months and seeing where Microsoft takes it.

My biggest concern with OneNote for Mac is that Microsoft lets it languish for years in between updates like they do the rest of their Office lineup for the Mac. It’s been nearly four years since Office:mac has seen a major update. The iPhone 4 was released in the same timeframe.

Microsoft can easily prove me wrong by improving the app on a regular basis, but there’s an inherent risk with jumping on a new-to-me platform such as OneNote, that I’ll look back six months from now and realize what a horrible idea this was.

I’m willing to make that bet. Don’t let me down, Satya.

The Auteur Theory

You’re likely sick of hearing about the show “True Detective” by now. Like millions of others, I became engulfed in HBO’s latest 8 hour masterpiece over the last few months. Plenty has been written about the Yellow King, Big Hug Mugs, and Matthew McConaughey’s amazing performance as Rust Cohle.

What I haven’t seen get nearly as much play is how the show is actually created. It wasn’t fully aware to me until the 4th episode’s 6 minute long take scene (Spoilers behind that link). It was riveting the first time I saw it. It was even more amazing when I discovered it was done in a single take.

As I read up on the show I learned that the entire eight episode season was written by a sole writer (show creator Nic Pizzolatto) and directed by a single director (Cary Fukunaga). Traditionally TV shows are helmed by a cast of behind the scenes folks who take turns at writing and directing different episodes. With True Detective, a true auteur theory was allowed to play out on screen.

One writer. One director. Eight hours of the best television I’ve seen in a long time.

The best creative works, whether they be TV shows, books, or apps, are the products of focus and vision. At Apple that was Steve Jobs and Jony Ive. WebOS had Matias Duarte, who has been doing wonders cleaning up the mess that was the Android experience. James Dyson does it for vacuums. I just bought a Dyson and it’s a fantastic product.

As I look at my iPhone I can name the person in charge of the vision for most of the apps on my home screen. Here’s a hint: most aren’t from large corporations that include the marketing folks and bean counters as part of the development process. They are from small development shops run by just a few people who have an idea of what their product should be and how it can impact the world. There are no focus groups or A/B testing. It’s just gut reactions and validating it with user response.

Everyone has a role in the creation of a product (even the bean counters), but having one or two talented people charged with shaping the direction of the product results in something that people actually enjoy using and, more importantly, championing to others.

Who knows? You might even make something that puts a smile on Rust Cohle’s face. OK, maybe not.