Samsung or iPhone? A screenshot worth a thousand tweets

screenshots of maps apps on Samsung and iPhone

(Okay, maybe not a thousand. But a lot!)

So last night, I saw that John Gruber had favorited one of my Flickr photos from 2008: a screenshot of the Google Maps app on the iPhone. Hmm, what was that about?

It turns out quite a bit. I found Gruber's Daring Fireball post pointing out what appears to be Samsung's alteration and reuse of a screenshot image I created in 2008. You see, three years ago I blogged about iPhone apps I thought were a big deal — "game changers." (The post was cross-posted on BlogHer, where it got noticed.) Scroll down to see my excitement then about the ever-useful, with screenshot in question.

Some nice sleuthing there, John! I tweeted about it and went to bed.

New details in the sunlight

This morning greeted me with more references as this issue caught on. Retweets. The Next Web. Gizmodo. All the scraper sites that pull from them. (I haven't done a thorough search.)

Embarrassing for Samsung, if true. I'll leave judgment to you. But if it's true, it's also a violation of copyright and the Creative Commons license. Not that it's any skin off of my nose. But it's never good for image when marketing gets caught hawking apparent bulloney. (I can't help but wonder why a marketing department would not use screenshots from its own device? Would the Samsung version of the app really so unappealing?)

"The world has infinite knowledge," writer Jascha Kessler would tell his students, meaning that you really need to write what you know and research what you don't know, because the readers will see your bullshit. Of course, that's all the more true now in the web world, where search, social links, and literally a world full of readers are archiving, contextualizing, tagging, bookmarking, and remembering what you put out there. I'm not sure how Gruber found the image match. One of the image search engines, possibly?

"Good artists copy, great artists steal."

Setting aside Picasso's original meaning for the moment, l leave you with the late Steve talking about design in 1994.

Good publicity out of the bad

Oh, and by the way, Efrain's II is indeed the best Mexican food in Boulder. I'm glad they got some free indirect publicity from all this. The green chile is to die for.

The theming firehose (NB for designers & front-end developers new to Drupal)

Drupal markup in a Wordle

You theme with the mark-up you have, not the mark-up you'd like to have.

That's the essential truth that designers and front-end developers new to Drupal need to understand. You don't get to construct your pages from scratch, building out essentials, never a wasted div, never an extraneous class. No, you have to flip the entire process around. With Drupal you're getting markup shot at you from a firehose, and as a themer you need to sop it all up and make it pretty. Don't spill a drop.

What this means is that, by default, you're spending a lot of time debugging the theme you're building so that it handles all the different configurations, content types, page structures, etc. that the Drupal site is throwing at you.

You have to be braced for it. It can be overwhelming. You can feel like you're drowning. Don't worry. You'll get used to it after a few months. Mostly.

Make friends with Firebug.

But wait, can't this situation be changed?

Well, kind of. You can intervene in the mark-up. You can write your own page templates. Your own fields templates. Your own views templates. Your own search templates. Your own node templates. Your own comment templates. But be warned: You're going to be working against a ton of mark-up. And you'll need to know some PHP to add your own variables — mighty powerful and nifty, but your Dreamweaver chops aren't going to help much.

You see, Drupal aims to be flexible, and it does that by throwing a zillion divs, spans and classes into the output. That means if you're not expert at CSS, you're going to be lost adrift in a sea of markup, and if you are expert at CSS, you have to learn how to see through the clutter — because when you have four or five nested divs to contain one single element, it's not necessarily obvious which one to target with your CSS. Especially if there's some nefarious Drupal core CSS already at work.

There are endeavors to make Drupal mark-up better, including in the HTML5 Initiative. But that's a slow process, and it sometimes meets heavy resistance.

Meanwhile, to get sites themed now, you may have to change how you work. Change how you view the web “page”. Get used to being the html sponge, absorbing and directing the firehose, using only the drops you want and letting the rest by without touching a thing. Let go of the idea that you're building from scratch, and get used to the mindset of diagnosing what's already there.

That's the price of power. Drupal is incredibly powerful. You need to flex your theming muscles to match what Drupal throws at you. Work through the complexity. Trust in Firebug. And don't despair. In the end, the resulting webapp is orders of magnitude bigger and badder and more kick-ass than what you could have done on your own, having 100% control but going it alone.

My DrupalCon San Fransciso session: Grok Drupal (7) Theming

The Way Drupal Theming Was

When I started Drupal theming in 2004, it was all a bit overwhelming. Back then, the core theme engine was something called Xtemplate, and it gave the impression to the n00b themer of being a great big mess. When you looked at the page template, it was one big blob of markup and logic, and it was very hard to figure out to change just about anything. What's more, it seemed to be very brittle: change something and you got the white screen of death.

And thus life was for the themer through Drupal 4.5 and the beginnings of 4.6.

New Drupal Theming Power

Then, in 2005, came the PHPTemplate theme engine, thanks to Adrian Rossouw (now with Development Seed), and the heavens opened up.

Suddenly (well, not suddenly, as it took a lot of work) Drupal templating had a structural logic: a nested system that simplified the clutter, gave us defined variables to work with, and provided the basis for extending the system. This was really really cool — so cool that it immediately became the theme engine of choise, and, with Drupal 4.7, it became the theme engine for Drupal core.

I was so excited about it, I did my first Drupal conference presentation on it, at OSCMS 2007 at the Yahoo! campus in Sunnyvale. (It was part of a larger topic of overriding display upon which I collaborated with Greg Knaddison and Ezra Barnett Gildesgame, now of Growing Venture Solutions. The PDF of my slides are available here, though they're pretty outdated now.)

Since then the Drupal theming system has evolved and improved. There are a lot of nifty techniques, tricks, best practices that are available to the themer. What's essential is having a good understanding of the underlying architecture, because that's how you can figure out where to look, how to go about making the changes you want to make the theme yours.

No PHP knowledge is required ... beyond knowing not to muck with what's between the <?PHP ... ?> tags. Of course, knowing some PHP can help. But you can also pick up the basics as you go, if you want to delve into the coded bits.

Learning Drupal Theming in 2010

My session proposed for DrupalCon SF on Drupal theming basics brings a comprehensive look at the Drupal theming system and how the front-end developer new to Drupal can take charge of the output by taking advantage of what Drupal gives you.

You won't come out an expert — that would be a ridiculous promise — but you will come out able to start rocking your own themes. You will have a solid understanding how the Drupal theme is structured, how the various templates work together, how to define regions, how to add your own targeted CSS files and scripts, use of subthemes, some good base themes to work from, how to do custom overrides of obscure, quirky or persnickety output using preprocess ... and you'll grok theming in such a way that even if you don't know how to do something, you'll know how to go about figuring it out, where to look, what to change, etc.

And because we're about to enter the age of Drupal 7, this presentation will be about these things for Drupal 7 (with some notes on how things have changed from Drupal 6). So this session could also be of interest to the experienced Drupal themer who hasn't had a chance to delve much into Drupal 7 yet.

Somewhere over Garland's rainbow

screenshot of new site

Garland has been a good thing for Drupal, overall, mainly for the color module. Anyone remember what it replaced in Drupal core? Yeah, it was pretty ugly. Context is important. So even though Garland is something of a front-end developer's nightmare, it has its purpose for the new Drupal user wanting to do at least a modicum of customization to the site's look, without resorting to coding.

And it has served its purpose here. I leaned on Garland (or actually her fixed-width daughter, Minelli) for my blog here for many months ... maybe more than a year. I honestly don't recall. It was since I upgraded to Drupal 6, when I didn't have time to work up a new theme. Garland gave me something so at least I could present the content here (such as it is).

But thanks to the fabulous NineSixty theme, I was able to whip something together yesterday afternoon — the theme you are seeing right here on That's right, it took me just one afternoon, even though I was hand-coding a few templates. NineSixty made it all so easy!

I had been designing using the 960 grid for quite some time now, but I had never employed the Ninesixty Drupal theme for implementation before. After hearing all the buzz at Design 4 Drupal Boston 2009, I was definitely curious to try it out. Now was my chance.

My own prior themes for rarepattern had been pretty hacky — quick throw-togethers with plenty of shortcuts. With NineSixty, I spent less time and resorted to fewer hacks. I still have some extraneous styles lurking, and of course there's the usual mark-up excess of some Drupal modules like CCK, but this was about quick implementation, with the emphasis on quick.

One of the beauties of NineSixty is that your page layout mark-up and CSS are pretty much already done. You actually accomplish most of your own layout adjustments directly in your page.tpl.php template. Just copy NineSixty's own into your own theme folder — the folder you created to make a child theme of NineSixty — and edit the classes on the various regions.

grid-8 means 8 grid columns wide

prefix-1 means 1 empty grid column before

suffix-2 means 1 empty grid column after

And there's more — push-x and pull-x, for example — to give you all kinds of power. Just change the classes assigned to each region, and your page falls into place.

The rest is just "skinning."

Drupal 7 freeze means time for a new tag: #D7DX

Yeah? Maybe?

[update: maybe not. see comments.]

#D7UX [Tweeted] is about Drupal 7 user experience work.

#D7CX [Tweeted] is about upgrading Drupal contrib modules to stable Drupal 7 releases when Drupal 7 itself is released. Over 100 contributed projects now bear this commitment, which is just awesome!

To me, that leaves #D7DX – a focused effort to get some rockin' Drupal 7 design themes going.

Yes, we have #D4D. And beautiful Drupal 7 themes are part of #D4D. But #D4D is also about Design 4 Drupal events, broader #d4d efforts on, and other design efforts that are happening. But why not a more focused tag, not on making Drupal pretty in general, not on improving the designer's experience in Drupal, but focused just on creating beautiful, semantic, exciting, eye candilicious themes for Drupal 7? For core themes, yes, but also for contrib. All ready and stable by Drupal 7 official release. Now is the time!

I'm writing to myself, here, since for someone who's been working with and designing for Drupal since 2004, I'm very late to the contributed theme party. That has to change.

At any rate, it's an occasion to finally get this blog here out of the Minelli realm. That's a long overdue effort. All I need is a little free time.


Tweet Tweet!

On rating Drupal modules ... where

Harry Slaughter recognizes the need for some sort of evaluation system for the huge number of Drupal modules available on However, I feel he gets the diagnosis wrong.

As far as I can tell, the primary reason for not having a rating system for modules is fear. Module developers in particular are concerned with the fairness of ratings. They are concerned with "gaming" of ratings. They are concerned that inexperienced or "dumb" end users may unfairly give a bad review of a module simply because they don't understand how to use it. These are all reasonable concerns. But they are concerns shared by other OSS projects as well. Sure you will see "bad" reviews, giving a module the lowest possible rating along with some inane review such as "tis modules sukcs BEWARES" :) But who cares, it's just noise that will be drowned out by valid reviews. It works for other OSS projects, and it can work for Drupal.

It's not fear, it's time and energy. Configuring ratings on takes work -- volunteer work, so far. Regarding ratings, it's also a matter of figuring out the proper metrics for evaluating a module. Some measures that come to mind immediately include scalability, ease of use, ease of administration, extensibility (interaction with other modules), as well as aggregated metrics of the status of issues (how long they're open, how many, etc.), number of downloads....

How do you measure that with basic ratings? It's not so easy. Even the architecture and business logic of a ratings system has to be well thought out.

I feel Harry also gets the remedy wrong:

John Forsythe has released what I believe is the first site dedicated to rating and reviewing Drupal modules No doubt this site will be a source of controversy as developers voice their concerns. But we need this resource now.

I encourage my entire audience (hi, mom!) to register at and to submit reviews for both your favorite and most hated Drupal contributions. This is a great way for non-techies to contribute to the community. The site is young, and there is naturally a shortage of ratings on the site now, but that will change as the site brings on more users.

Maybe this database will eventually make its way to For now we can show our support for this type of system by helping build out the database at

I don't think private metrics efforts will get imported into, for risk of skewing the results. And I feel there's some downside to splitting community dialogue into disparate sites scattered around the web. I suppose perhaps it's inevitable -- "scratch your own itch" and all -- but my preference is for efforts.

We're having open discussions about redesigning on, including implementation of some ratings system.

Angie is co-leader of this effort, and has been putting a lot of energy into making it rock. Kieran is also a leader in this effort, and is looking for team leaders.

I've signed on, as have a number of others. While stop-gap sites that fork and fragment module discussions may have some value to some, I feel we benefit most from gathering the resources of the full community. Rather than build out a remote pantry, let's fix up our own kitchen. is our collective home. Redesign is a lot of work. But as Jack Aubrey would say, "Well, then, there's not a moment to lose!"

Join us!

An Apple Store a day keeps the dreadful designs at bay

So we learn from Secret Notes:

Apple's stylish stores and computers, all of which feature unrestricted Internet access, have become such the hang-out and gathering place for MySpace junkies that the powers that be have elected to block the popular social networking site from its systems.

By the close of business Thursday, most Apple retail stores will have implemented the block, designed to reduce the level of loitering at the stores.

More likely Apple's design aesthetic just cannot brook dreadful MySpace page designs appearing within their bricks and mortar.

The horror! The horror!

Nervous time [updated]

It looks like the session we proposed for the OSCMS Summit has been scheduled for March 22nd at 1:45 p.m. 11:30 a.m [?], first last session after before lunch, in "the big room." Even though I feel confident in the topic and the deep knowledge of my co-presenters, I do feel some stage fright. Eeep!

Update: My session on community building was also booked later the same day. That concept from the start is for more of a round table discussion, so I hope people attending this one will come chock full of ideas and experiences to share.

CSS: A house of cards built in code

And Internet Explorer just loves to knock it over. And that's enough said on that.

You've got to know when to 'no' them

One of the challenges in project development is dealing with "scope creep" -- the often incremental changes to a project's goals, features and other specifications that can end up increasing the cost and timetable for completion of the project. Boris Mann points to Susan Mernit's excellent thoughts on the subject:

As someone who spent a lot of her career being the cutting-edge, push the mass market troublemaker, having a job being the one who says No, is an interesting experience--but it is also incredibly cool.

Working with a team of smart people who are passionate about the customer experience, the product AND the business objectives is tremendously fun--and sometimes, completely harrowing.

I've learned that No can cover a myriad of things:

* We're not going to do this right now.

* We won't do this ever, not on my watch.

* This isn't ready to be executed.

* You need to think this through more.

* What are you, nuts?

* Oh geeze, I wish we could do this..but we're not going to, not now.

While what Susan says is aimed more at internal R&D projects, Boris notes the same can be true for client work:

Many web projects, the "launch" of a site is just the beginning. *Maybe* the functionality and content are done, on simpler sites, but now it's time to start marketing and promoting the site. In most other cases, there a bunch of items that fall into a staged launch schedule (say "no" for launch and plan it for a later rollout) or in a big "future features" bucket (say "no" to it at first, and dump it in the future features bucket) which can be revisited over time. And of course, feedback from the users of any website should be taken into account when looking at these lists.

Boris says that in general he's "too nice." I can relate. After 15 years of professional work replete with enough of those hard lessons that I really should know better, I still try maybe a bit too hard to be agreeable to client requests for changes.

In comments on Boris' post, Khalid writes:

It starts with "can you add X?" and you say yes. Then "oh, and it would be nice to have Y too!", and you again say yes. Then "we cannot launch without Z! It is a must!", ad nauseum ...

Not only does this burden you, the site builder, but it takes valuable time and effort from basic features, and can delay the launch.

So, saying "No" is a way to prevent this scope creep.

There is always phase 2 ...


Part of this tension arises from the fact that, in the end, we want the project to conform to the client 's desires. After all, it's not our website (or DVD or video), it's the client's, and when the client wants something, the first instinct is to say "okay." And yet, and yet ... when budgets are bumped up and timetables pushed back, quite often nobody is happy. (And it can be especially problematic when you're the developer and you have other projects scheduled and limited resources to apply to them all.)

It goes back to the post to which Susan refers, by Fred Wilson:



Get occasional email updates on what I'm doing (and not blogging about).

Powered by MailChimp

Subscribe to design