Take a look at Matt’s post on Bearded’s 3-year anniversary of our signing the papers creating a then-fledgling business. Nice work, guys!
Wow. Three years.
Yes sir, three years ago today, we started a little thing called Bearded. We were just two guys working out of our homes with a dream of helping make a better Internet, and I feel quite confident now that we’re well on our way.
This year was a pretty momentous one for us…
At this point, it seems like a million years ago that disruptive upstarts (disrupstarts?) like Netflix and the iTunes Store were following Amazon into the lucrative territory of the “long tail”, using the scaling magic of the Internets to monetize the individual proclivities of enthusiasts and weirdos with broad offerings that couldn’t be shoehorned into even the most sprawling brick-and-megastore.
When I think about the effulgent promise of infinite media availability coupled with frictionless convenience, this ad from 1999 usually comes to mind. In truth, no one wants every movie ever made - the guy in the ad would probably be happier to collapse on his motel bed and watch whatever wreck of bowdlerized cinema that’s flickering out from TNT or TBS. We just want the movie we want, whatever that might be, but we’d rather not walk the entire video store to find it.
While I’m not really a fan of the iTunes Store, or of iTunes as software, today I’ll be heaping my ire upon Netflix. Lest I be judged bandwagon-hopping, I’m going to tell you upfront that I don’t have a problem with this year’s pricing changes, or with the Qwickster kerfuffle. Those are certainly egregious business missteps, but they’d be bearable if the product itself were strong, and there’d be many fewer customer defections if the service itself were compelling. As it is, Netflix customers pretty much feel like Reed Hastings’ ATM. Here’s why:
It’s been a really long time since I’ve had cable. For years, I felt like I had better things to do than watch television, and I’d periodically join Netflix when I felt like watching some movies at home. For me, the convenience of cable didn’t balance out the paradox of choice effect, and the thing I hated most was waiting as the list of available entertainments scrolled by on Channel 54 (or whatever it was) or the interminable schedule served up by fancy new cable boxes - amazingly, being able to navigate the scroll didn’t much lessen the agony!
How can it be that this is still something that awaits disruption? Anyhow.
At the beginning of “Watch Instantly”, Netflix was exciting, and the uneven catalog was acceptable in light of the groundbreaking access to content it provided. Even getting Starz movies seemed pretty cool. But nowadays the signal to noise ratio is pretty clearly weighted toward static, and looking at the “new arrivals” is kind of like wandering into the video racks that used to lurk in the back of a deli, crammed with copycat jacket art gilding the lilies of films that surrendered any hope of profit long before they wrapped. It’s a challenge to find something I’d like to watch at any past or future moment of my life - let alone instantly.
It wasn’t meant to be this way, and it’s hard to imagine how it’s come to pass, but browsing Netflix is increasingly feeling like watching Channel 54.
The main screen of Netflix tries to guess what I want, grouping movies by ad hoc categories based on my viewing and rating history. Seems like a good idea - but it totally depends on the quality of the recommendation engine. I had hopes that the crowdsourced algorithm that was greeted with such media fanfare might have led to a kind of quantum leap in recommendation quality. If it has, I certainly haven’t noticed.
Those ad hoc categories sometimes end up with comically absurd names, say “Cerebral Westerns with a Strong Female Lead”. It undermines the message that Netflix is trying to convey that their system “knows something about movies” and leaves me feeling pigeonholed - if I’m getting recommendations limited to this category that’s been selected for me, what am I missing that I’d rather watch instead?
It could be that I have odd taste in movies, but I think most people do: what people like and dislike is idiosyncratic. That’s something Netflix was explicitly trying to address when they launched the Netflix Prize - how do we recommend something that you won’t dislike? How do we plumb the far reaches of that long tail for those overlooked gems for something you’ll enjoy? It’s an admirable goal, but the problem is that it’s not working out.
An aside: part of the problem of recommendations is that Netflix’s user policies force my wife and I share an account. Until the recent price change, we had separate logins in order to maintain separate DVD queues - I didn’t like the new 2 DVDs at a time price point - but all our instant viewing ended up commingled. Netflix has the opportunity to get much cleaner data by encouraging user identity, but they’re mashing together disparate tastes in a way that’s probably polluting all of their recommendation data! It’s pretty mystifying.
Is it too much to ask that I never have to know about the long tail of “classic” westerns, that I can want to be ignorant of any “kids shows” despite my appreciation of the Iron Giant, or that I never see a movie no one even bothered to make a promotional image for? I know it’s unfair to expect magical serendipity - to log in and be presented with exactly the movie that’ll warm my hearts very cockles - especially given the catalog Netflix is able to license for online viewing. But that’s what I want, and that’s really what everyone who wants to queue up a movie wants. Until that halcyon day of perfect recommendation, we’ll probably settle for better filters against the tide of crap content.
That brings us to the user interface. We’re inundated with media we don’t want to watch, and we’ve got to browse (the brick and mortar metaphor should be a red flag) manually for the media we do. Unfortunately, Netflix makes this pretty torturous.
First, there are two interfaces: one for DVDs, and one for Watch Instantly. Both show only a few movies at a time, but the DVD browser requires clicking through a pager-style interface, while instant requires hovering to scroll through movies at a fixed speed. I’d guess that the difference theoretically has something to do with optimizing for a lean-back experience (the instant movie images are slightly bigger) but it’s a really strange choice to switch up the interaction this way. The rating stars are hidden by default in instant, where there’s the lowest signal to noise and ratings are most informative!
DVD:
Instant:
If to accept the provided category filter (yeah, I guess I’ll watch a Thriller), but prioritize the highest rated movies (an improvised crap-filter), you’ve got to click the category name (or see all in DVD browsing), then click “sortable list”, then click to sort by rating. It’s quite baroque to accomplish something that the software should be doing by default! Plus, it needs to be repeated every time you change the base filter (category).
To be fair, the experience of watching a movie online is pretty good! If the video quality wasn’t high enough, or the connection was interrupted and killed my playback, I wouldn’t be a customer at all. That’s to say: anyone who’s in the business has to have that covered, at the very least. I don’t want to ignore the fact that Netflix is doing a good job of actually serving their media, but I also don’t want to give them too much credit for solving that problem. Congratulations, Netflix operations! Now convince me that you care about my experience as a user by providing usable software.
Yes! Let a thousand flowers bloom! For Netflix has an API.
Well, maybe not a thousand. I only know of one serious commercial implementation of the Netflix API, at InstantWatcher. It’s got a lot of search options, fast page loads, and it has the most important missing feature, in my mind: curation. For example, you can choose from New York Times Critics’ Picks. Unfortunately, the list seems pretty stale, which points to the main problem with an API: the number of people using an API product is orders of magnitude lower than the total number of Netflix users.
If Netflix supported curated recommendations and all Netflix users were exposed to them, it would be much more likely that content providers (like the New York Times) would buy into pushing their own updates because it would increase exposure to their brands and content.
Further, the integration with your personal Netflix data is clumsy and requires a paid subscription to InstantWatcher. I think they’ve got a great layer on top of Netflix that can help mitigate some user experience pain, but it’s far from perfect. While providing an API frees us from the restrictions of a bum interface, it’s no substitute for a usable interface!
That’s the cost of a year of Netflix, the $7.99/month one DVD package plus the $7.99/month online viewing package. To me, the DVD package is worth the cost, but it’s kind of sad to imagine going back to a Netflix without watch instantly. On the other hand, it’s less clear to me that online viewing is getting me what I pay for, and I certainly wouldn’t restrict myself to the shabby selection of the instant catalog. I feel like it’s an all-or-nothing proposition.
I’m faced with a product that frustrates me, which I see as overpriced. I’m certainly not alone, as Netflix subscriber numbers are in freefall. The question before the 11 million or so remaining users who, like me, are receiving DVDs by mail and viewing movies and television on watch instantly is: should we keep it up? Reed Hastings is clearly trying to put pressure on us to choose streaming and drop our DVD subscriptions, but I’m willing to bet I’m not alone in valuing the content of the DVD catalog over the immediacy of the online catalog.
Were I paying for more than access to a catalog - if the software Netflix provided did more to help me deal with their morass of low-quality content - things would look very different. In its recent spasms of desperation, writhing to avoid an AOL-like collapse into irrelevance, Netflix has become a company chasing its reflection, tripping over its own tail.
I didn’t make it to RailsConf in New Orleans, but my co-worker Dominic did. He brought my attention to a slide from Zach Holman’s presentation “How GitHub Uses GitHub to Build GitHub.” It’s a great - even inspiring - presentation. If you work on software projects, you should click through it.
Now for the slide that got my attention. Well, really it’s two slides, a comparison of the Redmine issue form and the Github issue form.
From an information design perspective, there’s no contest: Github’s form is simple and well designed. All the optional data (assignment and milestone) is subtle and accessible via dialogs. Redmine’s form is an explosion of ill-defined options, and Zach’s annotations on the slide are a pretty fair representation of the cognitive process of navigating the form.
First, a little background. I assume you know about Github - if you don’t, you’ve probably stumbled on my blog by mistake, and you’ll probably want to back out slowly, without making any sudden movements. However, you might not know about Redmine. It’s an open-source ticketing and project management application based on Ruby on Rails (version 2.3). As one might (uncharitably) expect of an open-source project targeted at end users, the user interface can be somewhat counter-inuitive.
Zach’s presentation makes the case that you don’t need additional features - they’re just a layer of complexity that gets in the way of your work. I agree that it’s a good exercise to identify the simplest system you can get away with using - because it’s true that anything else is wasting your time and consuming your cognitive resources.
However, once you outgrow a simple system, you’re spending your time and cognition managing complexity (manually) with simple tools. If there’s not a way to transition to a more complex system that meets your needs, you’re stuck with that manual complexity, which can be a bigger productivity tax than underutilized system complexity.
That’s not to say that you shouldn’t use a simple system, but there are definitely reasons you might not want to. If you know that your project manager is going to want to look at a list of issues that your staff is currently working on, it’s helpful to have an issue model that supports a status of ‘in progress’. Also, I’m not confident that in the context of hundreds, or thousands, of issues that the most critical issues really do reliably float to the top - it’s helpful to have a way for a project manager to set priority for a ticket so it shows up emphasized to a developer (at the top of a list, for example).
These examples are obviously inspired by features common to ticketing systems (status and priority), and you can accomplish something similar with Github’s issue tags. But that doesn’t smell good to me - it’s exactly the kind of wrangling complexity with simple tools that I turn to software to avoid! Why shouldn’t a todo list be stored and edited as plain text? Well, your grocery list can - heck, you could even put it on paper! But it doesn’t have any assignees, priority, or completion, which the issues in your project often do. (A grocery list isn’t meant to be a frivolous example: it’s a project of limited scope that’s intended to be accomplished by a single person.)
Of course, we don’t want to reflect every aspect of our real-world process in our model - that way lies madness. But every project does have a process, even those that claim an ad hoc processlessness, and I think it’s worth spending a little time charting the process and identifying the parts that can be built into your systems. As a developer, I shouldn’t be constantly assessing and juggling tasks: the system should be able to point me to what should be done next. That requires some knowledge of my process to be baked in.
Redmine is pretty clumsy in a lot of ways. The issue form design Zach used in his presentation is probably one of the most glaring examples. But in its defense, it’s extremely customizable, down to the ability to modify the code that’s generating those ugly forms (it is open source, after all). Almost all of the bewildering options in that form are optional, and a better form design could hide them by default or remove them completely. Working with Redmine, I would recommend discussing with your team which elements of the issue model are necessary, hiding everything else. There’s likely a way to collect the meta-information needed to support your process without getting in the way of getting work done.
With all due respect to Merlin Mann, and so much is due, while a priority may be observed, not assigned, the subjectivity of who’s doing the observing matters.* Everyone working on a project has biases that influence what issues they’re going to pick up next. For example, I know there are times when I want to avoid an important issue: it’s a feature I’m not crazy about, it’s part of the code that I’m tired of working on, etc. Sometimes a priority really is assigned - the project manager needs a way to put a thumb on the scale to help inform a developer’s decision of which one issue to prioritize, at this moment.
* To be fair, it’s pretty clear from his article that he’s talking about the paradox of managing your own priorities, not of handling a project workflow.
Some elements of the typical issue model do encourage pointless meta-work. Adding a due date is silly for most issues, and inspires the kind of inflexible granularity that’s well worth mocking. But there I’d like to point out the distinction between resisting meta-work and foregoing the possibility of collecting meta-information. I would hope to steer a middle course: choosing a system that can be simplified to reduce friction (meta-work) but can be extended to support and speed my project’s workflow.
The advantages of Github are legion: it’s almost always actually working, you know it’ll scale, it’s got a fantastic source code browser, and pull requests are totally rad. I love Github, and I have a bunch of projects there.
But here’s the thing: Github, while completely awesome, is not someplace I like to manage a project’s tickets. Redmine, while hideously cumbersome by default, is. There’s definitely personal preference at work there, but I think there’s a reason to embrace complexity in systems - when it’s helping you get your work done, by managing some of that real-world complexity so you don’t have to.
Once upon a time, before the advent of the “blog”, I wrote a content management system. It had a few features: text formatting, file uploads, discussion forums. It wasn’t buggy, per se, but it had its quirks, and at most it had 20-30 administrative users through its entire life cycle. It’s a tragic folly how many hours I invested for each of those users!
Compare this to Drupal: more than 10,000 developers have contributed, and it’s in use on over 500,000 sites. Development is passionate and sustained, and security updates are released regularly. It seems like Drupal is only accelerating, in terms of public awareness and the profile of sites running Drupal (whitehouse.gov being an oft-cited example).
I’ve advocated for Drupal for these reasons, and others as well. Drupal core and its contributed modules provide a lot of functionality out of the box: from user accounts and permissions to custom content types to, well, a lot of stuff. The language of Drupal, PHP, is available on almost every hosting environment and is comparatively fast and easy to scale (I don’t mean to start any fights about this, and obviously the speed a parser executes can’t overcome all poorly written code). I’m committed to open source software, and contributing back to a community that sustains my work is personally fulfilling.
However, from the beginning, I’ve found myself struggling against Drupal. When I started out, it took me a while to discover there was a “right way” to work with Drupal, because so many of the examples I found were what I’d charitably describe as hacks, and it seemed that Drupal was a system that was designed to be used in a clumsy series of kludges in which the ends justify the means. (Before I learned anything else about Drupal, I learned this: if you’re looking for a feature, it’s probably not a good idea to use the module with the obvious name. Image? Event? Twitter? Nope.) Ever since I realized there was an underlying logic to Drupal, I’ve been locked in a series of intractable submission holds, attempting to wring elegant solutions from my work with Drupal.
Some accomplishments I’m proud of. Working with the Patterns module to move more configuration into the filesystem has been satisfying, and it’s great to not even consider checking a database dump into version control in order to collaborate on development of a Drupal site. (Some have used the module update system to achieve the same effect, putting configuration in PHP to be executed via update.php once another developer pulls the code.) However, even this example is bittersweet: the Patterns module remains tragically incomplete, and it’s disappointing that there’s no clean way to share configuration changes across a development team. When I think about ActiveRecord migrations (from Ruby on Rails) by comparison, honestly, I get a little emotional.
Most of my struggles (and my team’s struggles) have more to do with user experience. Once the initial feature list is satisfied by enabling the right modules, hours of work invariably follow to harmonize the display of the content with the rest of the site, to integrate the administrative interface for the features from contributed modules, and to disable (sometimes by extreme measures) interface cruft and unnecessary features that come along for the ride. I really believed, when I started with Drupal, that the commitment of a large number of developers would bring contributed modules into conformity with user interface expectations, and that Drupal would become dramatically more sensible for administrative users and developers.
To be fair: that has happened. A little. There’s been significant work on Drupal core to reduce the confusion users face when they look at the administrative pages. When you install Drupal 7 with no contributed modules, it’s pretty lovely to behold. But even without a proliferation of modules (or “features”, the abstraction that collects modules to be installed as a group) there are core problems that create unneeded cognitive load, such as the differentiation of “Menus” from “Content” and “Views”. As a developer, I understand why these are separate entities, but not why it’s the user’s responsibility to maintain their own mental model for what you might call “Site Structure”. Drupal still seems like a collection of developer-facing concepts lacking a user-centered conceptual framework. And as someone who really cares about user experience, it pains me deeply to have explained away this failing for so long.
In fact, I have recently stumbled on an uncomfortable truth, especially so for a committed long-time advocate. I hate Drupal.
I’m not a hater, generally. I don’t hate foods, or movies, or music. Some things I think are really bad: bad taste, bad execution, etc. But no one’s forcing them on me, so I can pass judgement and move on. No need for hate. But what I feel now is that bitter hatred that wells up in the final days or weeks of an abusive relationship, the gut-wrenching twist when you get a glimpse of yourself from another perspective, the sickening awakening to inverted love.
And I loved Drupal. I really wanted to nurture what we had together. I thought: I know Drupal hurts me - but if I work really hard, and give my very best, maybe Drupal will change. That kept things going, for years. But then I started to come around. I realized that Drupal didn’t give me that Forms API because Drupal loves me. I realized that ignoring me unless I named a (global) function with exactly the right prefix wasn’t just frustrating, it was killing my joy in the work that I do. And I realized, that, essentially, Drupal will not change.
It’s not that the core maintainers don’t want to make a better product - they’re working constantly to do so. It’s that, despite declaring that Drupal eschews backward compatibility between major versions, fixing what’s broken (and I use that word broadly, I know) would alienate too many users and module maintainers. The incremental changes in Drupal 7, while sufficient to break backward compatibility, are insufficient to fix the primary conceptual and functional problems as I see them (it’s tempting to start listing them all here, but that’s for another post). For me to not hate Drupal, much of core would need to essentially start over.
I know it’s not reasonable to expect a successful project to radically reinvent itself, even if I believe it should. So the only rational thing I can do is cut my losses and start making plans to move on.
This could be the kind of article that starts a heated discussion about “right” and “wrong” ways of doing things, but I really hope that it doesn’t. I don’t mean to make the case that you should hate Drupal, or that, if you do hate Drupal, you should stop using it. I’ll still be using Drupal in the future, but I’ll be much more circumspect in choosing it as a framework, first asking: Can this be done in Wordpress? Should this be done in Rails? Every project needs to be evaluated in light of Drupal’s productivity tax, and for me the bar for what makes Drupal a good fit has become considerably higher.
Thank you, Drupal. I wouldn’t be where I am without you. On the other hand, of course, I wouldn’t be where I am without you.
