Two things have become cear.
- There is no such thing as Drupal Specific Design
- Number 1 is only true if the project budget has no limit
The concept of Drupal Specific Design is false. There is nothing we can't do in Drupal, given enough time and resources. Yet, there always ARE limits on time and resources, which brings me to the next questions: how do you define Drupal Specific Design? What are the design patterns in Drupal that are easy to deploy, and which are hard?
I'm interested in opening this discussion, hearing stories and examples of things that were both easy or hard to implement. I want to help document where we are today, to help other designers who are new to Dupal get a grasp on some of these concepts. I have a few stories of my own, but I would like to hear from all of you.
As a counterpoint, I want to share one story to help explain why I want to instigate this discussion...
For years my co-worker has been repeatidly saying to me, "Don't worry about the technology. Design the best solution for the problem and we will figure out how to build it." He said this to set a stage for creative problem solving and to foster innovation. Knowing too much can influence how you problem solve, and he wanted to keep my mind untainted by the current constraints of what Drupal could or couldn't already do. This thinking helped us push the envelope over the years of what is possible in Drupal. While there is a time and place for this thinking, understanding the technology you're designing for helps you be a better team player.
7 years later, he still says the same thing and while I've listened to his sage advice, I've been learning as much as I can from a laymans standpoint on how Drupal works as well as what the latest web trends and innovations are outside of Drupal. Knowing this stuff has helped me be a better team member. Understanding how my designs get translated into code dictates how I think about problem solving. So in a way, I know know too much. However, I also know how to stay on budget and deliver a site on time. Both are valuable.
I would like to share some tid bits, and open it up to others to share as well so that new designers can read this and learn from what we have all gone through.
Bits of info I've picked up over time
- Every page in Drupal tends to have a page title. You can choose to not show it, but this is a standard out of the box configuration and something to consider when designing your pages.
- When you design a side block or pane, the padding on each should be consistent from block to block. It should be a conscious choice to deviate from this.
- Understanding the mark up heirarchy between the main page content and the side block content will help you decide where to re-use styles, and where to create unique ones
- Adding things like carosels(main content area on this page) are easy to build in Drupal
- Beauty Tips(hover function on this page) are a nice and easy way to improve the usability of your site
- Beauty tips don't work so well when nested in a carosel
- Adding styles for secondary admin tabs, error messages, breadcrumbs, pagination, input fields, buttons, and tables will drasticaly improve the look and feel of your site, and are not hard to implement. (Ref: Drupal Template)
- Paying attention to line height and letter spacing will dramatically improve the typography on your site
- Collapsable Blocks are a nice way to show and hide content (ex:Drupalcon SF Schedule
- Always review your work after it's built
Add your stories and tips on things specific to Drupal and Design. I want to know both what has worked and what has been hard.
Comments
960.gs
Well I believe that very important part of designing a website for drupal is basing your design on 960.gs I think iit is helpful. I'm not sure how you aproach, but I prefer designing on 960 grid system, always reviewing our work.. is part of our work.
Personally, I work as a
Personally, I work as a freelancer once in a blue moon. Most of my sites have been purely zen theme based with nothing but CSS for the most part. Suprisingly, I've gotten some pretty interesting stuff done on this alone. Recently, I've been experimenting with chapter 3's template for fireworks and as a wireframe starting point, it's definately gotten me to pay more attention to the drupal specifics that we should always design for: pagination, default blocks, default node teasers, etc.
http://www.chapterthree.com/blog/nica_lorber/design_drupal_template_appr...
It also helps in the case where you can start designing before the wireframes are "approved" by the client.
I'll disagree with #2
I'll disagree with #2. Almost all of our work is fixed-budget and we never design specifically for Drupal. But I suspect this only works where the designer is actively involved in the design execution. When the process is more of a designer passing the design to a themer to execute (pretty common), that themer will inevitably make assumptions, largely based on what Drupal makes easy, so it makes sense for designers to work with those assumptions in mind. But I'd try to avoid that situation.
I'd love to hear more about what in Drupal causes budget problems with design execution. I've run into the page title thing a few times, and have talked about just not making assumptions about page titles in the base theme to keep that more flexible. The rest of that list seems like good advice for any site, not just Drupal. If there are Drupal-specific headaches for design execution, we should find a way to remove them rather than continuing to work around them.
If there are Drupal-specific
100% agreed.
Main thing I was trying to point out above is how the underlying structure make some things easy, and others hard. And it's nice to know which we are designing. Example: the "more" button on blocks has it's own class and is therefore easy to give a special style to. Tid Bits like that...
there is no such thing as
I propose this be called "nicelobster's law" is absolutely true.
"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.chapterthree.com
blog: http://www.nicklewis.org
I presented this topic at the
I presented this topic at the Stanford Drupal4Design conference. "Better Websites through Deeper Collaboration".
My slides are at http://www.slideshare.net/jskulski/dear-designers-love-developers
The interesting examples slides start on slide 12.
For some background, I work am the lead developer / drupal architect at Chapter Three. After Nica joined Chapter Three, the question became how we can take advantage of having more control over the design process? It's an ongoing discussion in the company and community and I'm excited to see more designers weigh in on this.
Nica, it's great to see you bringing this to a larger design audience. I'd love to hang out in the thread and provide a developer's perspective.
Word
Thanks Skulski. Way to bring it back home.
For those who don't like clicking, here are some quick notes from the presentation.
Drupal is good at:
Question: you only gave one example on your slideshow of what was hard. Can you give other examples?
Question: you only gave one
Gonna try this one for kicks.
Its not that making a part of drupal look a certain way is hard.
So out of the box a "node" has a teaser and page view. In typical drupal installs I work on, such a "node" might have upwards of 5-7 different looks depending on the context.
Its not just that its hard to program, its that a human being who isn't a drupal ninja actually may have to enter in content that agrees with a display style. Example, what if nodes need to appear in a sidebar with an image, a title, and 120-140 descriptions? Now we need an image crop field that squares away images at the right dimensions, as well as a "short teaser" field (which is more anal about length than regular teasers) and titles need to be kept in line too.
I dunno if that made any sense at all, but that's where I see drupal design getting hard.
"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.chapterthree.com
blog: http://www.nicklewis.org
more formalization?
Although I realize I'm probably suggesting more overhead for a content provider, what do you make of more robust content type management? Perhaps a blog type that incorporates these extraneous presentation pieces into specific fields? And when the fields are absent, you can skip that piece of content for display in areas where it just won't work.
Fixed in D7?
I think that frustration might be gone (or at least minimized) in Drupal 7, where the binary $teaser is replaced with an open-ended $view_mode:
http://api.drupal.org/api/function/node_view/7
Of course, this will only improve theming if modules actually start using more view modes, and do it in a way that makes sense. I'm not sure how that's going to work.
Well in d6 we already have
Well in d6 we already have hacked multiple display modes (goggle "switchy tpl trick", "display suite", etc... ) .
The basic problem still comes down to someone on the "node form" end of the equation still has to understand what these 10 god damn fields are actually for, and what output to expect from them. I suppose that's the real matter of difficulty I find with designing drupal sites. Its not whether we can make it work (we can) its whether someone needs a manual the size of a 747 owner's manual to document how to enter a blog entry. (exaggeration sure, but exaggerations are interesting :-D )
"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.chapterthree.com
blog: http://www.nicklewis.org
CMSes are supposed to handle that...
Nick, while yes, ugly forms can be created, the entire point of a CMS is to hide that sort of "we'll be formatting this data later, so you have to give us all of the info now". Data entry shouldn't have to care about presentation... presentation should handle lack of data gracefully.
If you have 10 fields that are needed in order to theme the item 10 different ways, perhaps it's time to revisit why and how you ended up that mess.. and what is optional (and thus hidable for most cases, think conditional fields/ajax appearing options/etc), and what is critical info, and thus should be easy, defaulted, and otherwise clear for use.
No website should require a manual in order to figure out what to do. (And as I type this, I'm fixing a website with just such a problem... a site where they didn't do it Drupaly despite being in Drupal, they didn't understand how to think like Drupal as a CMS.)
A great example, nick. Let me
A great example, nick. Let me also just clarify when I say "hard" I don't mean that it is something that can't be done. "hard" means "taking longer than necessary to solve the problem". The more you can play ball with Drupal, the faster it can be developed and thus the more interesting things can be done.
Hard things can be 1) fun or 2) tedious. Be wise and cautious with 1) and avoid 2)
Agreed. When problem solving
Agreed. When problem solving less effort = good because it frees up time to solve other problems. Generally, I find it hard to communicate this reality.
"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.chapterthree.com
blog: http://www.nicklewis.org
Design for Drupal is a moving target
Having done a presentation last year at D4D Boston attempting to prove that Drupal can do anything a designer can imagine,
http://diallo3.pdtraders.net/2009/comic-places/
http://www.commonplaces.com/comicplaces
I'll also agree that the target is moving, and moving rapidly, to the point where your Rule #2 is really better written as
While it would be nice if Rule #35
was always true, it's not, and when not true, that is when the project budget needs to cover the development required to fufill Rule 35 to the extent needed for your Design.
So perhaps a rewrite would best be