Rick's Random Ramblings

It’s been two years since I started the big “reworking” of core parts of NetworkLocation. It was my first real Cocoa app. The codebase grew and morphed as I learned the do’s and dont’s of how to write a proper Mac app. Some of the code was still present from v1.0, which could either mean it was doing a really good job or that we had painted ourselves into a corner where replacing it would be painful. There was some of both.

AutoLocate, the little engine we have that figures out where you are, had grown in a way that was really starting to limit us. It had “that one nasty method” that did most of the hard work. It was much too long, and contained approximately zero comments. Modifying it had become something I really dreaded doing because it required thinking of every different permutation that we had designed it to handle, and how that scenario would play down the gauntlet. 

The general UI of the app was still very much so inspired by v1.0. We freshened it up with every release, but it was never redesigned. 

We decided that it was time to start rethinking things, and that it was ok if this release would take longer than our previous releases to build. At the time, we thought… no real new features, we’ll name this NetworkLocation 3.5.

Chris started plugging away at a redesigned AutoLocate engine that was much better designed, and still every bit as powerful (if not moreso).

Phil and I spent countless hours mocking up different versions of the configuration/preferences screen. How do we make all of this stuff simple to use? The biggest disconnect we dealt with was the relationship between AutoLocate rules and Locations. It was a one-to-many relationship, and each AL rule would contain a set of conditions for each type. Combine that with the fact that it wasn’t an ALL or ANY used to evaluate the rule, instead it was “the magic of ALv1 will figure it out”… and you had yourself something that was technically very cool, but in reality, a real pain to explain how to use. As the person who had to attempt to train support staff in how to figure out what was going on with users’ systems, let me tell you… this was insane.

So the challenge… to make something that’s as powerful as we had, but simple to explain. After many attempts we ended up landing on what we have now in Sidekick which is a simple ANY per type, and an ALL across the types. If I configure “at 700 Corydon Ave” and “connected to 22inch Samsung”, then both have to be true for it to work. If multiple devices are listed, then I need to be at that location, and connected to any of those devices. Much. Much. Simpler. Of course, there’s weighting thrown into the mix to find the best match if there’s a tie.

We realized that CoreLocation was by far the most user friendly way of identifying where a Mac was. Having a user interact with CoreLocation though… what with it being based on longitude/latitude… ouch painful. Obviously a map can help here, but interacting with a map in a Mac app is no trivial task. After a bit (ok a lot) of prodding by Phil, I wrote a little prototype to see how difficult it’d be to interact with a live Google Map. Turns out.. it wasn’t that bad. Definitely feasible, but their API is pretty painful to work with. I was stuck writing a bunch of wrappers around it to make it less painful anyways, so that’s when I started MapKit for Mac.

Fast forward another few months when we realize that “NetworkLocation” really doesn’t fit with what the product has become. NetworkLocation started life out as a faster way to switch OS X’s Network Location (the ones you configure under the Network tab of System Preferences). Now very few people actually use NL to do that at all. It’s a tool to configure your Mac based on where you are. One of those things might be to change network settings, but calling it that is about as appropriate as it would be to call it PrinterLocation because it can set your default printer. We had to find a new name: Sidekick. You’re the super hero, it’s that little dude that hangs out and does those annoying little tasks for you.

By now we’ve gutted the UI, rebuilt the AutoLocate engine, added actions, recoded a bunch of the actions with cleaner code, recoded a ton of old code that I decided was too old/ugly to keep around, and changed the entire branding of the app. It wasn’t a hard decision to stop calling it 3.5 and give it a 4.0 version number.

Of course, there were other setbacks, like the fact that we also decided to rename the company at the same time, switched store providers, and wrote a rather sizeable app that sucked up all of my free time.

We worked really hard on this, but I don’t think the end result would have been in the same league had it not been for a bunch of people who helped us out. Ash Ponders and his team at AptFolk have helped us in a big way by providing end user support. I used to do it all, and it left me with no time to do coding. They also wrote the user guide, and did an awesome job of it. Leanne Havelock from FourLetterWord did all of our copywriting for the new site, press release, and a bunch of other stuff (some of which isn’t out yet). Miles Ponson did our app icon and status menu icon, both of which I think he nailed. Our relentless beta testers (too many to name) who sent me many a crash log to tend to. And of course, Tiff who’s been kind enough to let me have an affair with Xcode.

The end result is something I’m really proud of. Sidekick 4.0 works in both Snow Leopard and Lion. We decided to make it a free upgrade for NL3 owners because we believe it’s substantially better and want all of our users to upgrade as soon as possible, so we removed as many barriers as possible. It should be able to import all of your NL3 actions and locations, and even automatically upgrade your NLPlugins to SKPlugins if you have any installed.

Sidekick is the new NetworkLocation.