Over the past many months, I've been working on a Netflix iPad app in my available time.  I originally had the idea for what I'm trying to achieve with my app since before iPad was released, though I never had time to execute on it until recently.  As with many of my personal projects, this one stemmed from personal frustrations I had with other Netflix apps on iPad.  These apps all share some key problems around design, information architecture, and performance.

There are only a few apps for Netflix available on iPad (if you don't count the iPhone apps that run on the device).  The two prominent ones that let you edit your queue and add new content to it are MovieBuddy and iPhlixHD.  I was instantly turned off by MovieBuddy's gaudy animated graphics and slow performance in loading recommendations.  iPhlixHD, on the other hand, is a very slick app, but its paradigm basically transposes the Netflix API into a menu system.  This hides information the user could use up front to determine how interesting the content is.  Specifically, runtime, release date, availability, and star ratings.

When it comes to performance, many apps lack a cache of information even though the Netflix API allows for it.  This greatly speeds up boot time of the app as well as resource loading.  Also, such caching prevents the reload of detailed information about resources when the user moves back from a detail view and then reloads it just afterward.

I set out to solve these problems for myself by writing a fairly thorough application.  My previous posts about iOS programming patterns came about largely due to this app.  Here is a breakdown of how I solved these problems: In design, the app is very visual: you see large, friendly box art rather than a list of titles.  In information architecture, the pieces of information you really use to make decisions about what to watch is bubbled up to the surface, rather than buried below a tap.  There are also lots of performance related features in the software to make sure the app boots fast and stays fast throughout.

I'm about to launch a beta of the application.  I'd love to get feedback.  If you'd like to participate, please fill out this survey: http://www.tinyurl.com/syfterbeta

~s

After six years and eleven months (plus two internships before that), today is my last day at Microsoft.  Over that period time, I've had the opportunity to help Xbox grow from a scrappy team to the critically important organization it is today.  I couldn't have asked for a better job out of college, especially since it was my dream to work on video game operating systems.  When I became a full time employee at Xbox, I had a number of goals, but two in particular: make Xbox input #1 for as many people on the planet as possible, and personally be responsible for 10+ billion person-minutes of time enjoyed.  I get to say I achieved that last goal by writing the Netflix application for Xbox 360.  I had tried for years through other efforts (I worked heavily on the HD DVD player as well as IPTV), but they weren't nearly as successful.  To this day, I still have a chip on my shoulder about the format wars.

Leaving Microsoft is bittersweet: I love the company and the people I've worked with.  Even after its recent missteps, the company still has the potential to change the world just as well as the valley's darlings, especially given the engineering talent.  And, in particular, Xbox as a group of people has an unrelenting soul intending to make interactive media better all the time.  I don't know of any other companies experimenting with how you interact with media like video games, movies and music at scale, and that uniqueness offers an opportunity to build to even greater things.

So why leave Microsoft?  For the last year, I was working on the now-canceled Courier project, and the cancellation gave me an opportunity to see the lay of the land at Microsoft and elsewhere.  Around the same time (actually a month later), Facebook announced their entry into the Seattle tech scene.  It seemed like the right opportunity to try something new.  Also, what better place to learn about keeping up with runaway growth?  I'm looking forward to tackling some difficult computer science problems, which you don't typically get to do as an embedded systems engineer.

About seven years ago, I leased my second car (though it was my first
lease). I wasn't very knowledgeable about leases, and like many first
timers, I looked at the monthly payment and decided it felt alright.
I was lucky enough to afford it and felt like it fit within my budget.
Back then, I was not as fastidious about budgeting my money as I am
today.

When the lease on my first car was over, I went back to the dealer to
look into leasing the successor to my car. When the dealer showed me
the new lease terms, I balked: the monthly payment was quite a bit
higher than my previous one, but the car wasn't that much more
expensive. While I asked the dealer why that would be, I don't
remember his answer - I don't think I would have believed it anyway.
So, I went to find out for myself.

After reading a ton of different resources related to car leases, I
created a spreadsheet to help me analyze where my money was being
spent. In doing so, I figured out the various ways I could save money
on the car I wanted. Many years later, I wanted to revisit this topic
to present at Ignite Seattle, but the topic wasn't selected by the
Ignite coordinators. Regardless, I thought I'd create a simple
presentation outlining why it's possible to negotiate a car lease, how
car leases work, and what points to negotiate once you've gotten
enough data.

Attached to this post are the presentation and the spreadsheet. Try
them out and let me know if you find them useful!

~s