design

From strictly a hardware perspective, the Droid cannot beat the iPhone. (For those who don't yet know: the Droid is Motorola's 'savior phone,' which they hope will make them a prominent phone handset maker again). How can I be sure? Well, look at the below diagram:

Basically, it comes down to originality, memorability, and design.

Feature for feature, the Droid competes well with the iPhone. Google Android 2.0 is pretty cool, too. But look at the above marketing images:

• The Droid screams 'corporate' and 'dull' – look at all those buttons, and squared-off corners! Not to mention the run-of-the-mill icons all along the edge of the screen (undo, menu, home, and search).
• The iPhone screams 'iconic' and 'holdable' – even though, for all practical purposes, it's the most boring and simple design—only one button on the face—but take a second glance, and you notice the shiny little indentation in the single button on the bottom. Look further and see the svelte and cool curves on the edges, and the look of a light shining from the top of the phone on all the UI elements.

The reason why Motorola's Razr was so popular was it's physical desirability and simplicity. Doesn't Motorola get that? Is Apple the only consumer company that realizes people would rather use a device that's appealing to them in both features and design?

I would love for the iPhone to have a good competitor... I really would. But we still haven't reached that point. Someday, maybe, but the Droid isn't the iPhone killer.

A couple days ago, when building a quick site with limited functionality (basically a pretty front end to a database website), I ran into a hiccup with my custom module/theme for the site, which caused me to scratch my head for a few minutes.

In my custom module (called 'idcards'), I added a stylesheet for a couple forms on the site using the drupal_add_css() function:

/**
 * Implementation of drupal_add_css()
 */
drupal_add_css(drupal_get_path('module', 'idcards') .'/idcards.css');

Later on in the development, I added a custom theme (based off a Zen subtheme I use for many smaller sites), and in that custom theme's .info file, I added a stylesheet named idcards.css.

When I cleared all the caches, I noticed the custom form styling (added by the module's idcards.css file) was missing, and on further investigation, I found that the module's idcards.css file was not being added to the pages!

Luckily for me, this is a small site, so I pretty quickly intuited that it was probably a namespace collision of some sort, and I renamed the module's file to idcards-forms.css. This fixed the issue for me, and now both stylesheets are happily living together. But just throught I'd share this tip in case anyone else encounters this problem: Make sure each one of your site's stylesheets (whether added by a module, your template.php file, or your theme's .info file) has a distinct name.

Part 2 of a series: Building out a full Drupal site in a weekend.

Well, one plane flight down, and a conference to go, I have the main structure of the theme set up (locally; haven't pushed it out to opensourcecatholic.com yet). I decided to go with Zen 2.x's -dev releases, for the simple fact that it's new and the way the Zen project is moving. There are a few rough areas in the documentation, mostly in the 'Readme' file for installing a subtheme, but I got through everything okay.

This theme, I hope, will make its way onto the fine Drupal.org theme repository; getting a CVS account, I'm sure, will be fun ;-)

I started with the very bare layout I had made for the OSC splash page. Then I posted a couple sample blog posts, articles, and other items, and went to town theming all the common HTML elements, positioning the navigation items, and doing some (very) basic testing in IE. Here's a rough idea of how the theme looks at this stage in the game:

Now, mind you, this is quite rough; I was focusing on the main layout for most of the plane flight, and I haven't even gotten around to theming all the listings, more blocks, etc.

But hopefully you have a general idea of where I'm going; I decided to use a digg-like navigation look (border-radius ftw!), and went with Warnock Pro for headings (why not? If you don't have that, you'll at least get Georgia!). I'm still not 100% happy with the 'Zen' way of having Navigation all the way at the bottom for a simple site where there are only a few links. I don't think it negatively impacts SEO much if at all, and although it's a good display of the idea of structure separate from form, it might simply not be worth the hassle.

I'm sticking to the KISS principle for this site, and hopefully will have a very clean, modern look to the site (right now I'm titling the them 'Blue Airy'). I'll keep you posted throughout the rest of the weekend, but postings tomorrow will be very sparse indeed, as I'll be at a conference all day!

Recently, an article on Accessibility appeared on Planet Drupal which caught my eye, so I clicked on it. When I was taken to the article page on d7ux.org, the banner across the top of the page caught my eye (as it was intended to do!):

Our UX Principles:

1. Make the most frequent tasks easy and less frequent tasks achievable.
2. Design for the 80%.
3. Privilege the content creator.
4. Make the default settings smart.

I think those four principles, especially numbers one and two, should be the driving force behind any web or product design.

In what will be the first of, I hope, many case studies, I review the process of redesigning the Saint Louis Review website, from the ground up.

The Saint Louis Review is a local Catholic diocesan newspaper serving the nearly 500,000 member Archdiocese of Saint Louis. The newspaper has had a website since the late 90s, which was ported to a custom-designed CMS in 2001. The PHP/MySQL-based site ran quite well throughout the first decade of this millennium, but was in need of either a serious overhaul or a redesign, to go along with the paper's new tabloid layout in April 2009.

The decision was made in 2007 to port the website to Joomla, but after a few months, a new editor, and more work, it was determined that, due to its extensibility, flexible out-of-the-box permissions, and standards/SEO-compliant codebase, Drupal would be a better fit for the site. Work was begun in January of 2009 to transfer the custom CMS' articles database (over 17,000 articles) to a Drupal site, create a new template based off the colors and design of the new tabloid-format paper, and integrate an easier-to-manage ad system and back-end.

Today I contributed my first 'original' piece of content to Drupal: a handbook page entitled Create a CSS-Only Theme. Since the first time I heard about the Stark theme (a Drupal theme which does nothing but expose all the 'stark' html output of Drupal core), I've been thinking of ways to enable designers to quickly build out unique and beautiful themes for Drupal. In Drupal 7, I think this will be a reality. (And maybe, just maybe, I'll create a theme for inclusion with Drupal 7 in the next few months).

Drupalers (myself included) are currently working on fixing the core template files in Drupal so they will provide enough CSS selectors to make web designers happy. We've finished the main template file, which lays out every page on a Drupal site. We're currently working on the 'node' template file, which lays out the main content area of each 'node' in Drupal. By the time Drupal 7 is released, we should have all the main template files fixed to the point where anyone can build a new theme for Drupal without ever seeing a line of PHP.

One area that needs a ton of help, though, is the Drupal 6 Theme Guide in the Drupal.org Handbooks. I've added one page (see the link at the top of this post), but the bigger problem is the disorganized nature of all the pages in the Drupal 6 handbook. I hope that we can get the pages organized in a logical and coherent manner, removing pages when needed, adding others, and rounding out the categories in an easy-to-remember way. Fellow Drupalers: what will you do to help?

I was browsing the Drupal Theme Garden a few days ago and was reflecting on how incredibly boring (if not ugly) a large share of the themes looked. Out of all the themes I viewed (over 50), I might consider using only 10 or so on a production site for a quick project that I didn't want to create a theme for.

Later on, I read this post on Steven Witten's blog [Acko.net] from 2007, and read through every single comment, because I am extremely interested in the issue of Drupal theming. If you are at all interested in helping Drupal be more themeable and appealing to designers, you must read the post linked to above. Go ahead - read it. I'll wait...

...okay, now that you're back,

A few of the comments in Steve's blog post deserve a mention...

From the blog posting itself: "Not enough Drupal people are savvy enough about theming and design to help out with even small tasks (like a banner) or even give quality tips and feedback on other work. The result is that theming and design receives little attention. Most contributed themes and sites could look a lot better, if they just themed it some more. And getting patches into core that give the defaults a little more oomph is tough, as they are often considered to be useless embellishments.