Category Archives: The Internets

I pray that my child never becomes an actress (assuming it’s a girl)

Posted on by

Because if she does, she’s doomed to a life of being judged not because of her character or her talent, but because of what she wears on the red carpet, or how skinny she is compared to the women ogling the obscene fashion show at home.

Don’t get me wrong; I’m as much a fan as anyone of all the gorgeous curvy actresses we’re starting to see. And I do believe that they’re an excellent role model for girls—showing that a beautiful woman comes at any size. But when I log into Facebook and see a bunch of housewives bitching about how skinny Angelina is, and coming out with that whole “what a horrible role model/she’s gonna make our daughters anorexic” nonsense, I can’t help thinking that’s a really old fucking story, and shouldn’t we be focused on getting *more* attention to the beautiful curvy girls, instead of constantly demonizing the skinny ones?

Here’s the thing: women’s bodies are beautiful. Big ones, small ones, tall ones, skinny and fat ones. I hope that the skinny ones are healthy; I hope the curvy ones are as well. But sitting around bitching about whether someone’s too skinny for someone’s liking sends the message that women are still, and always will be, judged for their bodies, not what they can do, or what they think. Including, and especially, by our own fucking kind.

And that, frankly, is a hell of a lot more damaging than seeing Angelina’s skinny ass on the red carpet.

Thoughts on the Logo Garden controversy

Posted on by
9

Recently, there’s been a bit of a s***storm happening online in regards to LogoGarden.com, a new cheap logo site that just launched. While most designers I know (including myself) hate these sites for various reasons, this particular site looks particularly heinous. While sites like LogoWorks and 99Designs at least pretend that you’re getting work from professional designers (hint: you aren’t), this site admits to “compiling the greatest symbols from around the globe” in order to give its users the ability to quickly and cheaply “save themselves from the embarrassment of a crappy logo.” The video below, put together by these folks, illustrates the story of both types of sites pretty well:

Intro to LogoGarden

The interesting thing about this video, and about the various things that have been written about the aforementioned site (mostly by its owner), is this:

While the various “cheap logo sites” claim to have professional designers, but more often than not use untrained designers who actively steal other people’s work, logo garden basically admits to ripping off the work of professional designers directly in their advertising.

A few of my friends in the design community, including Jeff Fisher and Von Glitschka, have already spotted several of their logos being ripped off by the site; in fact, both of them seem to have found at least 20 of their logos, if not more, being offered to customers of the site.

This is all horrible, and clearly the dude who runs this site is irresponsible, if not actively malicious. But the more I read about it online, the more I wonder if actual legal action is being (or even can be) taken against these guys. Below is a conversation I had about the subject in response to Jeff Fisher’s discovery of yet another logo of his that had been ripped off by this service.

Dani Nordin: Are you and Von planning on delivering Cease and Desist letters to these guys?

Tom Stephan: Von did one better — he tagged the WWF and asked them if they’d seen their logo ^_^

Dani Nordin: +Tom Stephan That’s great, but I don’t see it as “one better.” Frankly, we can bitch and moan about stolen designs as much as we want on the internet; it’s not going to stop these idiots in their tracks until there’s real legal action behind it.

Tom Stephan: I think hitting them from all angles is best. One flashlight scares a cockroach. Floodlights stun it and make it easier to squash. I’m certainly not saying this situation is funny or amusing; I’ve had my own work stolen (not in this scope or scale) and I’m aware that it’s invariably who has the money to fight the thievery. The WWF certainly does, and that may turn the tide in favor of the ‘good guys.’ That being said, LogoGarden will shut down and reopen in a few months or weeks as “LogoForest” or something, and start again…it is what it is, and one of the unfortunate downsides to a tech-enhanced world.

Dani Nordin: +Tom Stephan I don’t disagree with that, actually; I just find myself jaded when I see several days of angry Internet conversation about something without any kind of formal cease and desist letter… of course, seeing it from the outside, it’s very possible that there has been one, but that fact hasn’t been shared. The sad thing is that these types of idiots will never go away; and at least this LG site doesn’t pretend that their competition is professional designers; in the intro video I saw online, they were pretty clear that LogoWorks, etc. was the alternative for this market. They even called out several of the key reasons that professional designers advise against sites like that; the cheap labor, the dude who knows Photoshop (sorta) and throws things together quickly.

Ultimately, the market for all of these sites is the cash-strapped “entrepreneur” who has a “million-dollar idea” but doesn’t know what’s really required to get something like that launched. In other words, the types of clients that most professional designers (especially independents) find crazy-making.

In which Todd Nienkerk, founder of Four Kitchens, rants with me about restaurant websites

Posted on by
Reply

I’ve been hard at work transcribing some of the interviews that I have done in the last several weeks for Drupal for Designers, and I just came across this great conversation with Todd Nienkerk that didn’t quite fit in the book, but was still a Very Interesting Conversation. I offer it below, for your reading pleasure.

Todd, if you’ve never met him, is one of the founders of Austin’s Four Kitchens, a team that works on big websites for great clients. They’re also the people who co-created Pressflow, a Drupal distribution built especially for large-scale websites, and they also run DrupalCamp Austin, which is happening in November.

The following conversation happened a few weeks ago, and covered a huge range of topics — mostly grid systems, design for Drupal, responsive design and various snarky tangents. In this bit of it, Todd and I go off on restaurant websites, and we also talk about working with clients who don’t understand the cost of creating a good web presence.

Todd: I have noticed that the #1 factor in project success from a design standpoint is: has the client done this before?

If this is a client who has tapped three or four people who are junior-level, or are new to this, and they’re communications or marketing people or something, and the CEO says “hey, we need a new website — you’re sort of in charge of that…”

Dani: yes — “you’ve done HTML before, right?”

Todd: exactly, and the person is thinking, “I’ve never done this, I’ve never built a website before,” they come to us and they say, “hey — I’ve never been through the process of building a website before and I don’t know what to expect.” There are two possible outcomes that come from that. Either they have full faith in us, and their bosses have full faith in us, or they listen to us, and they have full faith in us, but their bosses don’t. Or their bosses are saying “we’re a non-profit that has never really done a serious website, and we don’t really get project management — I don’t really understand why UX is necessary. It seems like a lot of extra fluff to me.”

They don’t take us quite so seriously, or their attitude is, “that looks good enough. I don’t want to spend any more money on design. I just need the website to ‘do’ certain things. I don’t really care how it looks.” Those are typically the people who have never been involved in a web project before.

Dani: I also find that part of dealing with non-profits, especially in the client intake/sales process, is reading between the lines, and listening to how they *say* “we’re a non-profit.” I’ve done a lot of work with non-profits, and I find often in conversations with fundraising/development managers that if you hear them say, “well, we’re a non-profit,” in a certain tone, that it’s often a cover for a host of things that they don’t want to deal with.

Todd: Yes, that ends up becoming code for “we’re a non-profit, so we do everything bare-bones.”

Dani: Yes. We do everything bare-bones, we don’t have a lot of money, and to put a sort of New Age spin on it, it’s sort of a “lack” vs. “Abundance” mentality; you think that because you’re a non-profit, you basically have to spend almost no money on your marketing; meanwhile, if you look at the list of biggest, most effective non-profits with the largest reach in the Boston area, most of them spend about 5-6% of their revenues on fundraising efforts — including their website. They’re spending that money, and as a result, they are getting more donations, and they’re able to do more work, than perhaps 100 smaller non-profits in that space combined.

Todd: it’s surprising, too, how many people don’t seem to understand that the most effective dollar they can spend is on a better website. It’s sort of like, when you go to a restaurant’s website, what do you care about? Phone number, address, menu. That’s really all you care about. Who’s the chef? That’s an afterthought — that’s what you might get into when you’re starting to dig around and learn more about the restaurant.

Chances are, when you’re at a restaurant website, you’re about to leave the house and go out to eat, you need the number for reservations, you need the address so you can look it up on a map, you need a menu to make sure that your friend who’s gluten-free can actually eat something there. Or you’re looking at it — which is even more likely — on your phone, and that address is locked into an image, and you have to somehow put that address into your memory long enough to switch apps on your phone and type it all in to find the restaurant — or the menu is locked into a PDF, and you don’t have a PDF reader on your phone.

This is all super-basic stuff, and yet restaurant websites, more often than not, tend to be about the show, not about the information. That sort of conflicts with what I said about advertising dollars, but I suppose it depends on the industry. In the case of a restaurant, chances are that you’re not going to learn about the restaurant on their website, but on Yelp, or some other thing that is gauging its value. It’s not like a non-profit, where you do have to learn about the non-profit and what they do on their website. I don’t think there’s a real “rating system” for non-profits. You’re going to their website because you want to a) donate, or b) learn more about them.

I find that so many websites just assume that the website is little more than a brochure, or a television commercial, or it is some thing that is not a website.

A website has to do what the users of that site expect it to do. And restaurant websites are a good example of how many websites *don’t* do that, because they’re so egregious. They, on the whole, entirely miss the mark. You arrive on the website, and it’s a fashion show. It’s this Flash thing with all the dishes fading in and out, and all this sliding stuff, and you’re like “no. I don’t need this. I just need your address.”

Dani: well, I also think that, at least in the restaurant world, that you’re going to find all that other information on Yelp. So you don’t “need” to have it on your website.

Todd: perhaps.

Dani: The other problem, I find, with restaurant websites — I’ve actually done quite a few, and while I was able to talk them out of Flash slideshows, I’ve done my share of downloadable PDF menus — the biggest problem with creating a good restaurant website is actually updating the menu. The reason is that most restaurants don’t actually have a marketing person. The person updating the website is often the owner of the restaurant, or the owner’s son/daughter/whatever. They’re a chef, they often don’t have very much tech savvy, they usually work 12 hours a night or more.

If you’re a chain with a big marketing department, or you’re a hometown diner with 20 things on the menu that never change, it’s not a big deal, but if you’re like any of the restaurants that I’ve worked with, where you’re a relatively small place with a focus on local, seasonal food, you’re constantly changing your menu. With one of my clients, I basically just set up a Pages template and showed him how to upload a PDF. Because his menu changed every week, and he didn’t have the time or ability to figure out how to update the code of his website. Another client calls me every time he has to change his menu because it’s written completely in HTML and he can’t figure out how to make changes.

So yes, you’re probably just looking for the menu, or the contact information, but the problem with a lot of restaurants — and the reason I think so many of them are horribly bad — is simply because either they’re sort of “fashion” websites, where it’s not so much about the food as it is about the atmosphere, or they are restaurants where you have someone in charge of the website who doesn’t have time, knowledge or interest in maintaining this website.

Todd: Right.

Dani: So really, either way you’re screwed.

Todd: Yep. I imagine that partly, this is — and I think this speaks to all types of industries, and all types of websites — that so much of it requires buy in from the owner of the website, or the owner of the business it represents. In the case of restaurants, you need the owner or chef/owner to not only update the document where they update their menu and print it out — because no chef, no matter what, would not announce the menu in some way; whether they put it on a black board, write it on paper, or maintain it in a Word Document. Because, duh, you can’t not have a menu.

It should be, in my opinion, and I think that this will change over the next several years; it’s changing now, in fact — it needs to be just as “duh” that you have to update the website when you change the menu. Or maybe, you change the menu on the website and print it off from there. Maybe keeping the menu in a Word document or something similar is doing it backwards. Why not kill two birds with one stone and have a good printable template that’ll print directly from your website?

Dani: See, now that sounds like a Drupal distribution that needs to be made, there, Todd. I think we need to work on that.

Todd: [laughs] That would be be cool.

Dani: I think we’ve figured out what we need to do next.

Todd: You’d need one “menu” page node with a good, printable template.

Dani: Absolutely.

Todd: I like this idea. 

Dear Apple: REALLY?

Posted on by
Reply

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.”

wpid-ScreenShot2011-08-07at11.19.25AM-2011-08-7-11-06.png
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.

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

Posted on by
Reply

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 Drupal.org 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.