Dear Apple: REALLY?

Here’s the rundown:

My mother, because my niece is now officially a Middle Schooler, decided in a fit of generosity and proudness, to buy my niece an iPod Touch, which she’d been begging for for MONTHS.

She didn’t, however, do any research into actually *owning* an iPod Touch, which meant that she didn’t realize that owning it required my 12-year-old niece to create an Apple ID, which requires her to put in somebody’s credit card information.

So when the niecelet told Grandma that they needed a credit card in order to let her set up an account, Grandma said, “hell no,” and thought no more of it.

Then she got her credit card bill. And lo, the niecelet did FIND her credit card, and go more than a little bit crazy on the App Store. With two separate cards.

So now, the tech-savvy aunt gets called, and I get to spend my weekend cleaning up a big old mess.

Here’s my problem with all this:
When I called the Apple Store, to complain about the fact that there’s no actual option to CONFIRM that an Apple ID belongs to a child and set restrictions on it, I was advised to simply get her an iTunes gift card instead of using a credit card (and where in the UI for setting up an account is that even mentioned?). Or, alternatively, I could set her up with a pre-paid credit card that I keep adding money to as rewards for good behavior. Good idea, if she was 13; most pre-paid cards require the user to be at least 13.

Both of these are excellent suggestions, and ones I had thought of when I was planning on buying her a Touch (before Mom decided to do it herself). However, there’s still a single, epic fail at work here:

Apple does not bother checking to see whether you are a CHILD before you set up an Apple ID. Or rather, it does, but it makes it way too easy to lie about your age.

And if you are a parent, setting up an Apple ID for a child, it does nothing to help you monitor and create restrictions on the account. For example, if I set up restrictions on the Touch (which, believe me, I have), all I can do is disable the ability to access iTunes or the App Store altogether; there’s no way to, for example, allow her to download all the free apps she wants, but require a passcode that I set up to download any paid apps. And they sure as hell don’t make it easy to figure out how to remove your credit card information from a given account, which is evidenced by the over 5 million results for “removing credit card information from iTunes.”

Really, Apple. This is serious s***

I have no problem admitting that I’m a rabid Apple fangirl. But on this topic, they have majorly, epically failed. I love the idea of changing the way that we buy music and apps; but really, if you’re going to do that, it’s pretty much common sense to recognize that kids are consumers too — and give parents a way to easily (note, I said easily) prevent their kids from bankrupting them on Justin Bieber mp3s and multiple seasons of a TV show you’ll never watch.

Here’s a simple way to do it:
The moment you enter your date of birth into the Apple Store, and it shows that you’re less than 16 years old, don’t require a credit card.

Their current practice — simply telling you that you “don’t meet the minimum age requirement,” is the same kind of stupid cop out that Facebook uses. Both of them want to pretend they don’t have to take responsibility for what tweens do on the service. There’s nothing that will prevent a kid from simply lying about her age, or that requires someone to actually verify their age somehow. So, my 12 year old niece simply pretends she was born a couple of years earlier, and hilarity ensues.

Let’s face it: if you make a fun product, parents will want to buy it for their kids. And not all parents have the technical prowess to deal with all the crazy wrenches Apple throws you to simply use their products. Yes, it’s easy(ish) for someone who is used to everything that Apple makes, but for someone who just wants to own an iPod, there’s a ridiculous, and DANGEROUS, learning curve that Apple has decided to throw in the works for any kid who gets one of these things for Christmas.

And yes, I’m COMPLETELY fired up right now.

Gearing up to write

As I may have mentioned on this here blog (but also have been oddly quiet about), this summer is a Writing Summer. I’m in the middle of writing Drupal for Designers, a series of guides for O’Reilly geared towards designers who want to work with Drupal but don’t need yet another recipe book telling you how to download a module. It’s a great project, and one that I’m psyched to be doing. But I am noticing that the experience of writing a book, from a project management standpoint, is far different from the experience of creating a website.

In some ways, it’s remarkably similar to what I do in my consulting/UX work. There’s a huge amount of research, and user interviews (I’ve done about 12 interviews thus far, and still haven’t talked to all the people I want to), and the book is basically the result of that research and interviews. But I’m still working on the flow of writing; getting to that state where I can accept that writing and research is what I do all day.

This is, I think, a problem of being self-employed for as long as I have been. I get so accustomed to wearing several hats that wearing any one of them for too long feels foreign. While this is a pattern I’m looking to change in the future, once I find the right team, I imagine that there’s still a bit of unlearning I have to do in order to feel truly comfortable focusing my attention exclusively on the aspects of my job that I love. The temptation to retreat back into code and implementation – which is often easier, but less interesting to me – still catches up to me now and again.

None of this is really a complaint, per se. But it is an observation that being a writer seems to have a different character, and a different set of requirements, than being a site builder or a coder. Because writing is something I love doing, it almost feels like I’m taking a break; I couldn’t possibly be doing this because I’m paid for it, or because it’s my job. This is what I’ve always done just to get things off my chest, or to share information that I’ve learned. Having it as my job, at least temporarily, almost makes me feel like I’ve been given a free ride to goof off. So while I’m making headway on the book day by day, I almost feel guilty having to step away from code and clients for a few hours a day.

And then I remember that there’s a book deadline looming, and I have a lot of research to compile, and I get back to it.

In which I vent with Leisa Reichelt, about UX and Drupal.

It was a dewy, slightly drizzly day on the Internets. I was on my third latte.
Serenaded by the sounds of a bustling coffee shop in Prague, I chatted over Skype with Leisa Reichelt, part of the UX team that is responsible for the overhaul of both and Drupal 7. What follows is a rather incomplete summary of our conversation, which centered around the challenges inherent in doing, communicating and selling quality UX work.

The best UX design comes from collaborative effort, not working in a silo.
Traditional “waterfall” projects, where the entire design process is siloed and done prior to development, often leads to work being hacked up in the development phase. As a result, many UX designers end up feeling embarrassed by projects after the fact. As Leisa notes in a recent blog post, it’s not uncommon for UX designers to accompany their portfolios with an embarrassed “don’t look at the site; it’s awful.” By engaging developers early on in the process, and ensuring that you’re creating things that can actually be implemented, you reduce those risks.

Say you’re a UX designer on a corporate team; too often, your job amounts to working away at a desk, headphones on, creating a stack of wireframes that you then present to stakeholders. Two things will usually end up happening here:

  1. Because you did the design on your own, regardless of the stakeholder input or user interviews that went into the design, your instinct will be to defend the design against a perceived onslaught of criticism. This shuts down stakeholder input, which can only make your life more difficult.
  2. Similarly, because this design was done in isolation, stakeholders may feel that they haven’t had enough input in the design, which will lead either to strenuous objections that derail your design, or worse – unwillingness to comment at all, which keeps you from making the design better.

This doesn’t just happen on corporate teams; it happens in Drupal shops, Agile environments, and all sorts of tech development teams. In an artifact-centered environment, much of the actual thought that goes into good UX design can get overlooked or devalued; many a designer has heard feedback that stakeholders don’t want to “waste too much time” on activities such as user flows, concept diagrams, and other things that help us frame the design challenge before us. As designers, an important part of our job is communicating to clients the importance of just those activities, and encouraging clients to get on board in helping to create them.

We’re not designing pages, we’re designing interactions. At its most basic level, a website is a collection of web pages. But underneath that collection of pages is a series of interactions that a user will have with a given system. Even something as simple as a newsletter signup – something that’s often thrown into a webpage at the last minute – carries with it a series of questions that need to be answered:

  • What information do you need to collect?
  • What information will the user be willing to give?
  • Why would they be willing to give that information?

Keeping design purely at the level of wireframes – or pages – prevents stakeholders from understanding how those interactions play out. Information Architecture is not just about understanding Drupal’s menu systems and taxonomy – it’s about understanding how users expect to access information on a given website. It’s about creating an interaction that makes sense – and stripping out the things that don’t.

Good designers are facilitators as much as they are craftspeople. Let’s face it. This is an industry that favors tangible artifacts over process. It’s easy to talk about the craft of design – and to judge its physical output. We’re used to doing it. But design is not just the creation of artifacts. More often than not, a designer is facilitating collaboration among stakeholders from varied backgrounds – all of whom have a stake in the final output. We’re asking tough questions, and creating patterns and use cases. How, then, do you sell that? What does a wireframe, for example, tell you about all the non-tangible elements that went into creating that wireframe? When your role in a project is to act as facilitator, what in the physical output of that process can you claim as “your” work?

The confusion of physical artifacts versus process is one of the key reasons that many teams don’t understand what good UX design actually entails. Too often, as mentioned above, the focus is on tangible output – wireframes, user flows, etc. – and often, the processes that truly make up the design of a successful interaction have more to do with conversation, conflict, and being up and away from the computer. How do you communicate that process, and its value, in an environment that is still obsessed with what they can see?

This is a challenge that Leisa is starting to work on. The idea, still in development, is to create short video portfolios that document a given design process. And yes, she’s prototyping it in Drupal.

Start prototyping as early as humanly possible. One way to ensure both that you’re capturing the interactions that need to take place in a given system, and to ensure that what you’re designing can actually be implemented, is to start prototyping as soon as possible. This is one of the key benefits of Agile environments – whether you’re working on your own or in concert with a developer, putting ideas into code not only makes developers happy, but it allows you to see what issues come up with your designs early in the process.

This doesn’t mean that the classic Drupal approach of “there’s a module for that” is correct, either; starting to prototype early in the process doesn’t excuse you from putting thought into how interactions might play out, or spending time sketching out ideas before you jump straight into code. One of the biggest challenges that site builders face – whether they’re designers or developers – is leaning too heavily on Drupal to create interactions for you. Design patterns are useful, but it’s just as important to make sure that the patterns you’re choosing are the right ones for the job.

Drupal needs designers. But it doesn’t just need designers to enter the community; designers come into Drupal all the time. Getting them to stick around? That’s a bigger issue. Recently, when discussing my path as a Drupal designer with a colleague, he asked me, “Why Drupal?” My immediate answer was, “because I enjoy an uphill battle.” Yes, things are getting a bit easier for designers in the Drupal community. People get that we’re doing good work, and they’re starting to understand why we need to be here. But too often, the design conversation in the Drupal community isn’t a design conversation at all. It’s a theming conversation. At the last two Design for Drupal Camps, the feedback I saw from designer friends of mine – people I had specifically invited to the camp – was that for a design camp, there was surprisingly little in the way of design sessions.

This is one of the challenges inherent in a developer-centric culture such as Drupal; while theming and front-end development is vitally important to successful Drupal projects, calling it “design” is one of the things that prevents designers – many of whom are very skilled, but not coders by any stretch – from feeling welcome in the Drupal community.

There’s much more to cover here. It feels like this post barely scratches the surface of all there is to say about good design in the Drupal community, but to use a phrase from my dad, it’s a big nut to crack. Constructive comments are warmly welcomed.


So many things to say about being in Prague. For one thing, I’m delighted at the amount of international travel I’ve been able to do this year. Between the honeymoon last year, this trip, and a potential trip to London in August (should one of my sessions at Drupalcon be selected, various appendages crossed), I’m feeling positively European.

New things:

  1. We discovered that, in Prague, there seems to be such a thing as a Tourist Dungeon. At least, that’s what we’re calling it. The first night here (after we fell asleep for several hours due to OMGJETLAGWTF) we went to a brew pub called Pivovarsky Düm. Excellent beer, okay food, but the service – well, let’s just say that once the host realized we were tourists, we were very politely pointed to the basement, where we were delivered English menus. This, after being told off by a waitress and the bartender for asking if we could grab a beer while we waited for a table. Fortunately, this hasn’t been my experience with every place we’ve been, but it was still uncomfortable for our first time in the city.
  2. Why did we stay, you might be thinking? BEER. Delightful, unfiltered, wonderful beer. The fruit beers were not really my thing, but I will say that they were the best of the genre I’ve tried. My favorites were Coffee beer (OH MY GOD GOOD), and Nettle beer – which was green, with a very herbal thing going on. If they had it in the US I’d buy it by the case. It’s a much better St. Patty’s Day alternative than the Budweiser with green food coloring we serve in bars around Boston. Nick tried a Wheat beer that, speaking as a Harpoon UFO fan, absolutely blew UFO out of the water. It was fresh, lemony, and the best of the bunch that we sampled.
  3. Speaking of Budweiser, apparently it’s also the name of a Czech beer that’s entirely different from Budweiser, but has exactly the same logo. Our hotel, in fact, serves it.
  4. I have decided that there are entirely too few sandwiches that involve sliced hardboiled egg. Part of this was decided based on Clover’s Eggplant and Egg sandwich (one of my favorite things). But in the Amsterdam airport, I was delighted by a sliced egg and bacon sandwich, and there’s a deli near our hotel that serves slices of bread with sliced egg, a bit of cucumber, tomato or pepper, a slice of ham and pickle. It is the most wonderful thing ever. I have a feeling I just found my new summer staple meal.
  5. I’ve also learned, thanks to a Drupal buddy of mine, who introduced me to a local Drupal designer, that there’s a Coworking space less than a mile from my hotel! I plan on heading over there on Wednesday to work for the day, and I’ll be heading to a Drupal meetup that evening – which will likely be all in Czech. I’m fascinated to see how that works out for me (I know very little Czech).
  6. Most things here are surprisingly cheap. The best, though, was massage – through the hotel, I got an hour-long, and desperately needed, massage for about $60 American, which included tip. I can’t tell you how much I needed that – I can, however, say definitively that it will be happening again on Thursday.

And, just a touch of snark:

  1. I didn’t realize until I came to Prague exactly how much Rhianna or Celine Dion I could listen to in a sitting. Thanks to the hotel, and the local coffee shop, I’ve learned that the answer is “quite a bit.” I’d like to unlearn that.

I’m trying to view Prague as both a bit of a much-needed vacation and a writing expedition. The first draft of the project management guide for The Designer’s Guide to Drupal is due on June 1st, and I’m much further along in writing than I am willing to believe I am. It’s interesting, once you start getting things down on paper, both how much you actually know and how little you *think* you know. No matter how much material you have, it never quite feels like enough. Fortunately, things are going along pretty well, and this trip offers a good opportunity not only to get out of my normal way-too-busy schedule, and organize the vast amounts of research I’ve been collecting into something cohesive for the publisher.

What’s been delighting you lately?

Usable vs. Poetic interactions

In Thoughts on Interaction Design, author Jon Kolko talks about “poetic interactions.” The thrust of his essay was that a truly poetic interaction went well beyond simple “usability” – whether a task is easy or efficient to perform – and that too much of interaction design, especially in the digital realm, focuses on usability to the exclusion of other factors. As Kolko writes in his essay,

“Some practicing designers balk at the idea of designing poetic interactions. One early reviewer of this text was as blunt as to say, ‘I have other things to worry about – like shipping a working product that isn’t awful.’ Yet if designers focus only on the low-hanging fruit of functionalism or usability, the human experience with designed objects is destined to a level of banality. As ideological as it may appear, what if that piece of enterprise software offers – for a fleeting moment of use – a poetic or soulful experience?”

This dichotomy of usable vs. “poetic” interactions is something I’ve often come across as a designer, before and after the transition to UX. When I talk to clients and hiring managers, user experience is far too often discussed in terms of usability testing, to the point where the terms are interchangeable. When asked what kind of user experience activities a team might do in a course of a project, often the answer is wireframes, a few user flows, and user testing – in fact, the ability to write and execute a test plan is the most often requested attribute of UX designers in job postings, aside from knowing a whole bunch of front-end coding stuff that many UX designers don’t touch.

This got me thinking more and more about the author’s discussion of poetic interaction, and the idea of creating something that isn’t just usable, but can actually shape behavior. Whether we want them to or not, the interactions that designers create can help shape behavior, for better or worse. Facebook, for example, has changed the way that we think of social interaction on the web. Is the interface “usable?” Yes, once you get used to it. But the point of Facebook isn’t an easily intuitive interface; it’s about getting you to interact with people in a new way.

Likewise, the RMV isn’t necessarily “usable.” But it does have some poetry to it. When you arrive at the RMV, you’re sorted according to what you’re there to do, and then you get a number that corresponds to the task you’re there to perform. By separating the tasks with a letter (as they do in Massachusetts), and giving you an approximate wait time up front, you’re prepared for the task of waiting. You know what to expect. So you bring a book, or your iPod, or you find some other way to occupy your time.

This is the difference that exists between things that are “usable” and things that are “poetic.” You may not understand the poetry, you may not appreciate the poetry, but it exists. And subtly, it changes you.