eriksmartt.com/blog

Netflix shows the world how not to treat your customers by dropping Profiles — Updated: Change of plans

Like many other Netflix customers, I received the “Important News Regarding Netflix Profiles” email this week stating that Netflix “will be eliminating Profiles, the feature that allowed you to set up separate DVD Queues under one account, effective September 1, 2008.” Upon reading it, the claim sounded so absurd that I assumed it was phishing/spam. Seriously.

Sadly, the news started showing up with quotes and claims that the statement may actually be true. “Netflix Eliminating Account Profiles” (on hackingnetflix.com) claims that “Netflix spokesperson Steve Swasey said that the decision to eliminate Profiles is a ‘final decision.’”

Here’s the kicker though; The now famous email ends with, “While it may be disappointing to see Profiles go away, this change will help us continue to improve the Netflix website for all our customers.” Really? How so?

For those not familiar with Netflix Profiles, the feature was somewhat unique. Instead of having a single persona per account, Netflix Profiles allowed a single account (ie., household) to setup multiple profiles (ie., husband, wife, kids, pets, etc.), so that each profile could manage their own rental queue. It also allowed the main account holder (ie. the parents) to review the other profile’s queue (ie., the kids) and set limitations, like whether the profiles were allowed to rent R-rated movies. The feature was amazingly helpful in eliminating arguments about who controlled the rental queue.

Removing features from a product can be a tough decision for any Product Manager. Features that are rarely used are easy to toss aside; But (market differentiating) features that customers love should never be thrown out without helping the customers replace or replicate the same benefit in another manner. In this case, Netflix dropped a much-loved feature, but left their customers without an alternative (other then opening more Netflix accounts, which isn’t a likely reaction for irritated customers.)

For more:

• Netflix Eliminating Profiles: Tells Us We Don’t Own Our Data

[Update: 2008-06-30] Complaining works! Netflix just announced that they are keeping Profiles:

You spoke, and we listened. We are keeping Profiles. Thank you for all the calls and emails telling us how important Profiles are.

We are sorry for any inconvenience we may have caused. We hope the next time you hear from us we will delight, and not disappoint, you.

Time to backup gmail if this is true…

If this post is true, there’s now a really good reason to backup gmail locally: “Is google shutting down email accounts if they suspect hijacking?“

Reading “The Definitive Guide to Django”; Verdict: A solid learning reference for a beginning/intermediate Django user

Last week I received a review-copy of the new “The Definitive Guide to Django” book from Apress. I hadn’t planned on buying the book since it seemed a little too beginner-focused; but I agreed to give it an honest reading, so I happily dove in with an “it’s Python, of course I’m going to like it” attitude.

Background

The book was written by Adrian Holovaty and Jacob Kaplan-Moss, the creators and “Benevolent Dictators” of the Django Web Framework. It was Holovaty and Kaplan-Moss’ first book, and, I believe, meant to be the first Django book to market. The book was drafted online; open to peer-review and community feedback; and ultimately published under the GNU Free Documentation License.

From the get-go, the print edition had a few inherent market challenges to face: First, the entire book is available online, for free, at: <http://www.djangobook.com/>. Second, in many ways the book is a re-hash of the docs available at <http://www.djangoproject.com/documentation/>, which are also free. Third, the book covers Django 0.96, not SVN. (0.96 is technically the latest-snapshot release, but a lot has changed since 0.96.) And finally, the $45 MSRP could be seen as a little steep for what is effectively a printed copy of a free, online book.

The print experience

Diving in, the book takes the reader through the basic installation process, provides a brief background on how the framework came to be (and why you want one), then steps through the major features (ie., the template system, ORM, URLconfs, generic views, etc.) It’s what you’d expect from a technical reference — no fluff, and straight to the details. There are plenty of code snippets to learn from, and the sidebar notes tend to be insightful.

Since it wasn’t new material for me, the book was a fairly quick read; but the experience of reading Django documentation in book-form was actually quite fascinating. There’s something about settling into a comfortable chair with a book, pen, and highlighter that you just can’t get with online documentation. Perhaps it was just a little more noticeable given the material. When I read the Django docs online, I tend to skim over them while trying to solve a problem. I use them as a reference more then a learning tool, and it’s usually while actively coding, thus my brain is partially distracted with whatever it is I’m building.

With a physical book, you can unplug, step away from the computer, and give the material your undivided attention. This isolation from distraction results in a much deeper understanding of the text. This is the real the value of the printed book — it’s an opportunity to digest online documentation in an environment more conducive to learning and retention.

My general take-aways and observations

• The book definitely has a beginner/intermediate feel to it, but only in the sense of a beginner Django user — not a beginner Web developer or Python programmer. I’m curious how well the book is received by folks who are beginners at Django and dynamic Web development since the text brings up a lot of complex topics in Web development that aren’t really explained. (Ex., database administration, server clustering, manipulating HTTP headers, etc.)
• The breadth of the book is impressive, but in some ways, the book really feeds you through a firehose, so to speak. It throws a lot of new concepts at the reader and doesn’t always explain why you’d need to know them, or how you might use them in the real world. For someone deploying a site with Django, it will be good to know that all these features are available, but it might take awhile before they need to use them (if ever.)
• The book does touch on some of the more advanced Django features (like extending the template system and writing custom middleware), which was nice, but some topics are reserved for the appendix and get limited coverage (ex., model managers and ‘Q’ queries.) Others, like the Sites Framework, are given good exposure, but not so much that the reader is left with a clear picture on when to use them and what their limitations are.
• The forms processing chapter was a bit lighter then what I was hoping for — especially given that the current newforms documentation still trends toward “read the source code.” It provides enough to start using newforms if your form needs are pretty basic, but doesn’t address creating your own widgets, or any of the fun stuff you can do once you start dynamically generating and manipulating newforms objects.
• It might have been nicer if the examples in the book were a little more tied together, perhaps all focused on building a single example project and showing how the various features are used in real-world applications. (The example of the book-publisher’s app was a reoccurring theme, but not so strongly that each chapter applied it’s new learnings to it.)
• The Deploying Django: “Going Big” sub-section provides a nice infrastructure graphics for how high-traffic systems might be setup, but once you get to the point of being “big”, you need to architect for it, and that’s really outside of the scope of this book. For this section, it might have been nice to reference other resources on scaling infrastructure, and perhaps pointing out some of the ways that Django can be optimized for performance and horizontal scaling. (For example, one of the Django projects we put into production at work will happily support 1,200 requests/second, but the database layer and session middleware have been reworked a bit, and the content caching approach is a little different then the standard Django offering.)
• On the more positive side, even as someone who’s been using Django for some time, I still learned a few new tricks, and I was reminded of a few features that I could be taking better advantage of. (And when you do this stuff professionally, every shortcut and productivity gain has monetary value — avoiding even a half-hour of debugging pays for the cost of this book.)
• This book would make a fantastic read for a back-end developer joining a project that is already using Django. I normally tell new developers to go through the Python Tutorial at <http://python.org/doc/tut/> if they’re new to Python, then to complete the Django Tutorials at <http://www.djangoproject.com/documentation/> before trying to grok any in-progress Django project. Now I have a third reference (though I might still suggest that they walk through the tutorials first, so that they have some context when reading the book. Otherwise, there are just too many new concepts to do a straight read-through and still grasp it all.)

Summary

The market needed a good Django book, and this one delivered a solid reference for the framework. Arguably, it’s not really a “Beginner’s Guide to Django”, but hopefully it covers enough of the basics that future books can focus on best practices and more advanced techniques. (On a related note, there’s apparently an upcoming “Practical Django Projects” book, also from Apress, that will focus more on building “reusable Django applications from start to finish”. This might actually make for a better beginner’s book, depending on how it turns out. [Via The B-List: Speaking and writing].)

The million-dollar question then, is “Should you buy this book?” My answer ended up being a bit more positive then I expected, but there are two parts: First, if you’re a front-end developer only, you don’t need this book. You can just read Chapter 4: The Django Template System online, and then use the “Django Templates: Guide for HTML authors” section of the online docs as a reference. For back-end developers, the story is different. If you’re going to just “read it while you hack”, then you might as well just read it online; but if you’re serious about building applications with Django (especially if you’re new to it), then you should consider the book and investing the time to step away from the computer and really let yourself get into it. Unless you are an active contributor to Django (which I’m not, just to be clear), the odds are pretty good that you’ll learn something new, even if you’re already using Django today.

Changing the URL experience with typography

I started using the Locationbar² Firefox add-on a few weeks ago, and I’ve been amazed at how significantly it changes the experience with URLs. The interesting thing is that I already think about URLs as RESTful commands… but when you see URLs broken apart visually into distinct domain, path, and argument sections, the visual interpretation quickly change from “a bunch of random text that the browser understands”, into “a domain-name/brand, and specific service”.

It’s difficult to explain without visuals, so let’s start with a traditional looking URL:

The traditional-looking URL is a bunch of text. We recognize it as a URL, and typically market it as a full-text string. However, many sites use non-friendly URLs (think Vignette CURLs, for those who know what I’m talking about), in which case URLs are often massive strings full of seemingly random characters. When surfing sites with such URLs, the browser’s location bar becomes something you ignore until you’re ready to type in a new address.

Now let’s look at a Location’ized version of the same URL:

Quite different! The Location’ized URL is a distinct representation of a domain name (”eriksmartt.com”), and a service (”blog”). Information we don’t need, which normally just causes visual clutter (like the ‘/’ characters), has been greyed-out, and brand-recognition remains strong.

Here’s another example:

Just looking at that URL, it’s pretty clear what site I was on, and what I was asking for — which is exactly what a URL is. Writing out http://flickr.com/photos/tags/lolcat loses some of this meaning. It becomes a single address, rather then a service and a request.

Of course, clever domain-names can lose some of their brand recognition using this approach:

Still, I’ve already grown so accustom to seeing URLs as Locationbar² displays them, that it feels disappointing to use browsers lacking this capability. I’ve also found the tool to be extremely handy while developing websites, making it very clear which server I’m accessing, and what request I made.

YMMV, but I definitely recommend trying it out — and I’d love to hear about your experience using the add-on!

iPhone development platform will wake up the mobile industry

One of the most interesting topics of iPhone speculation is the choice of interpreted, web technologies as the development platform. I greeted the news with a big smile, and a sigh of obviousness. Having spent a few frustrating years preaching the potential of agile mobile development platforms, it sits near and dear to me to here that Apple is paying attention to a bigger market.

Of course, the old-school, “Mobile 1.0″ crowd’s reaction is just as I would expect. Some of the claims make me laugh, so I felt motivated to chime in on the topic. Let’s break down the big three that I’m hearing:

“No SDK means no killer apps.” There are two issues here: (1) That there are ‘killer’ mobile apps that aren’t already included in the iPhone; and (2) That killer apps can’t be built with web technologies. For the first bit, ask yourself what the killer mobile apps are? Number One is voice… Number Two is SMS… Number Three varies, but support for syncing PIM data, taking pictures, listening to music, checking email, and browsing the web, pretty much covers it. For the second part, to assume that killer apps can’t be built with web technologies would require denying the last ten years of Internet development. The Web has changed everything — and it was built with web technologies ;-) Besides, Apple hasn’t commented yet on whether they’re exposing select native API’s via JavaScript.

“No clear revenue stream (for developers and operators) means no developers.” Stop thinking Mobile 1.0. Stop thinking traditional channels. Stop thinking about the Operators and Manufacturers “owning a customer”. Drop all this telcom baggage and start looking at the Web. There are plenty of companies making significant revenue simply because a large number of people have a browser and a data connection to their PCs. If anything, the mobile market becomes more interesting (and potentially more lucrative) when application development is cheap and the legacy mobile bureaucracy is out of the way.

“Developers need low-level access to the hardware.” This actually came up in a recent conversation, and I just about walked away at that point. Are you kidding? Do you have any idea how much of a PITA (and HUGE waste of time) it is to develop high-quality, reliable, usable, native applications on embedded hardware? I do. And I can assure you that you want no part of it. I appreciate the occasional need, and I’m sure Apple can give the John Carmack’s and Google’s of the world a l33t SDK; but if you’re looking to develop innovative, profitable mobile applications, there’s no reason for you to be tracking down memory leaks and hardware bugs. The less time you waste fighting the hardware, the more time you’ll have to launch new software. (If you don’t believe me, compare the rates of software and business model innovation that happens on the Web vs. on mobile phones. Mobile phones have done wonders for flattening the world, but they can’t compare to the Web as an environment for cheap, rapid innovation.)

Offline web app with Google Gears

The blogosphere is already lit up with posts about Google Gears, and for good reason. Solving the offline/local-storage problem for web applications has been a hot topic — it’s one of those glaring voids in the web stack that keeps web applications from replacing desktop applications completely.

So what is Google Gears? It’s an Open Source browser plugin that provides services (via JavaScript) for offline storage, data recovery, and synchronization. And here’s the best part: it works on Mac, Linux, and Windows… on Firefox 1.5+ and IE 6+ (with Safari support in development.) With such a huge support base, combined with the benefit of being a cross-browser solution and being open source, Gears has the right ingredients to become a defacto solution for offline web applications.

For more details, check out:

• Google Gears Project page
• Google Gears API Developer’s Guide
• Google Gears Lets Developers Take Apps Offline (via Techcrunch)

Today is Wiretap the Internet Day!

Starting today, your intertubes are tapped. You weren’t using those civil liberties anyway, right?

For more, see:

• Today is America’s wiretap the Internet day (Via BoingBoing)
• Reminder: Monday is Wiretap the Internet Day (Via Wired)

Django “lorem ipsum” generator (and a new contrib.webdesign module)

Django “lorem ipsum” generator (and a new contrib.webdesign module)

The Django Web Framework project just added a new contrib.webdesign module with an amazingly simple, but incredibly handy first feature: a lorem ipsum generator. The idea is that a project’s base templates can include generated lorem ipsum for testing layout and page flow, but inheriting templates can override the generated text once real content is available.

The lorem tag is used like this (via the contrib.webdesign docs):

• {% lorem %} will output the common “lorem ipsum” paragraph.
• {% lorem 3 p %} will output the common “lorem ipsum” paragraph and two random paragraphs each wrapped in HTML <p> tags.
• {% lorem 2 w random %} will output two random Latin words.

In practice, you might do this:

templates/template.html:

<html>
  <head>
    <title>{% block article_title %}{% lorem 5 w %}{% endblock %}</title>
  </head>
  <body>
    <div class="article">
      <div class="article_title">{% block article_title %}{% lorem 5 w %}{% endblock %}</div>
      <div class="article_body">{% block article_body %}{% lorem 4 p %}{% endblock %}</div>
    </div>
  </body>
</html>

And then inherit when you’re ready:

templates/article.html:

{% extends "template.html" %}

{% if article %}
  {% block article_title %}{{ article.title }}{% endblock %}
  {% block article_body %}{{ article.body }}{% endblock %}
{% endif %}

Previously, I used to just paste lorem ipsum text directly into the main template (wrapped in block tags for overridding), but this new tag will let you skip the copy/paste routine. Very nice!