How do we make drupal more designer friendly?
Drupal is a great development environment. And, when it comes to creating themes, you don't have to be a php whiz to create them either. There are even efforts to make theming easier with each new release. So, why aren't designers coming to drupal in hordes? Better yet, how do we make drupal more designer friendly?
These two questions go hand in hand. We need to understand why we don't have more designers to know where the weak points are. I highly suspect the weak points aren't just in the drupal code but in the drupal community. I don't think designers are nearly as much concerned with the code as developers.
While, there have been some great efforts but drupal folks like Steven Wittens with his talk Designer Eye for the Geek Guy/Gal there is still a lot of room for improvement. That presentation seemed to be turning geeks into designers. What about turning those artsy designers into drupalers?
Any thoughts, observations, or specks of wisdom floating out there in the ether? Any artsy designers see something you'd care to share?
Comments
#1 My experience...
As a designer, not a coder, I haven't had a very good experience in the drupal community. I agree with Matt, the software isn't the problem...it's the community.
I can muddle through enough php to create the sites I want to create, so that's not an issue. The problem is the way designers (or non coders) are treated in the drupal community. Each time I go into IRC or chat with a drupal coder, they treat you like you're some chump that shouldn't be using drupal...Treated like if you don't know code, then you don't belong in the community. It's mostly coder-ego at work...
I think if there were an acceptance by the average drupal-er for people who don't WANT to know code, but want to design using drupal, you may see more designers come into the community. Afterall, knowing the API and writing modules isn't the dream of everyone...I could care less about that stuff. But until that time when designers are respected for who they are and what they do, they may do what I do: Work with drupal on my own, and steer clear of the community.
#2 Designers group
We have a group dedicated to designers and IA. Feel free to hang out there, and kick anyone's ass there who doesn't respect design. Once you are compfortable, please find a way to contribute back because taking what we all have created and not reciprocating is a bit selfish.
There is truth in what you say about ego deficient coders mocking others. But there are morons in every community. We need designers with thick skins!
#3 how?
How can a designer go about contributing back to design. From what I understand, #drupal-theme is often people with theme questions and not really a design area.
The handbook does have a lot of information about manipulating themes. But, creating a deisgn is different than taking a design and turning it into a theme. Would a design and information architecture area be a good section to add to the handbook?
Contributing for themers stops at irc and the handbook. There really isn't anything on design there.
#4 Not Giving Back...?
Hmm....something I hear you saying is that if you don't give back you're not welcome in the community. And, maybe non-coders are seen as people who can't give back...ergo: they're treated poorly, or as leeches?
I'm not sure how I feel about this. One part of me thinks: "Wait a minute, since when is it selfish to use something free and not give back? If giving back is a requirement, then it shouldn't be free...it should be based on a "credit" system."
The other part of me totally understands...communities like this thrive on giving back. And they wouldn't exist without it. But if I have nothing to give does that mean I'm not welcome in the community?
If so...it's even more inclusive of an attitude than I first thought. It's "we're good guys, we give this stuff away" on the outside and "those selfish ingrates" on the inside.
I guess I echo Matt....I build custom sites and custom designs for those sites. I give back with modules that are built for those sites (although I didn't build them), but beyond that, what can a designer give back? Generic themes don't seem like the answer to me...and even if they were, I still am stuck on this idea: Does the drupal community see giving back as a requirement to not be treated like crap?
#5 ways to give back?
I guess adding to the theming handbook and helping out in the #drupal-theme irc room (which you do, bob) doesn't seem like it's really letting designers give back with their skills enough.
Maybe what I am wondering is if there is a better way for designers to give back? Any ideas?
And, I'm also wondering if there is a way we can be intentionally friendly to designers in a way that makes the community a little warmer to them?
Any thoughts?
#6 Leadership
I don't see how we can possibly expect the majority of people to give back, nor do I think it matters. If you take from Drupal, and then spend your time, say, looking after your elderly neighbour, nobody could possibly call that selfish. If you are friendly and polite I automatically assume you are the kind of person who gives somewhere; I think it matters little whether that contribution comes back to Drupal or whether it is paid forward somewhere else.
And yet, indirectly most people contribute anyway. The more people use Drupal the more exposure Drupal gets. Eventually that attracts more coders or whatever.
Leeches don't just take blood; they also clean it for us. Win/win.
For me I plan to give lots back to Drupal, but mainly because it benefits me directly. I want to build a business around it; and the better Drupal is, the better my service can be. It's completely selfish, but I guess that doesn't really matter.
The Drupal community should continue to ask for contributions because it thrives on that, but it should never expect.
Personally, I've noticed a little less of the attitude you come across, but perhaps that is because I'm interested in code as well as design. But I agree, I think it exists. For example the opening message on the group about the Drupal.org redesign - http://groups.drupal.org/drupal-org-redesign-analysis - meant I didn't subscribe.
The other issue I've certainly noticed is that code is considered more important than ideas. I get the philosophy behind this, but it doesn't work so well for designers who don't produce code.
Anyway, I believe the answer to your question, Matt, is leadership. Drupal has a great leader on the code side, but not really one on the design side. Steven is the closest we have, and he is doing a great job (his talk, for example, and the Garland theme), but maybe he isn't the person who can reach out to designers and get them excited. Or maybe he can't afford the kind of time and energy that would take... because it really would require a lot of time and energy.
You have a great design idea for the Drupal project? Can you code it? No? Oh well, that idea gets lost. That's the reality.
Ideas get lost all over the place, debates meander and die. Somebody needs to focus these ideas and set about getting the best ones implemented.
There is something very telling the discussion above. I've witnessed the same conversation all over the place. People ask for help, and volunteers ask how. But the answer is always vague and uninspiring. People ask because they need to be guided. It's confusing to get your head around Drupal, what needs to be done and how you can help.
I think if Drupal.org was an office, the designers would end up standing around and making cups of tea.
What should they be doing?
How about helping to redesign Drupal.org?
Or collaborating with the marketing team.
Or lending their design skills to the development of Drupal core.
Those are the obvious suggestions. But this is still too vague. How can they help with that effort? And who do they go to when they want a little guidance?
#7 a leader
I think you may have hit the nail on the head. The designers need a leader. A leader that is a designer.
#8 Fantastic
These comments are the most levelheaded and mature thing I've seen come out of the drupal community regarding this topic. Thanks for sharing and being a part of the solution, rather than denying the problem.
#9 Sorry you had a bad experience
Hi Bob,
I'm sorry you've had a bad experience (or a few) as a designer in the Drupal community. I can say that we've experienced a couple of people along the way that made us feel less than knowledgeable about some of the design or code questions we've had for Drupal. But it seems like for every one person that might think they know it all there are several others that are willing to help out where needed.
Hopefully your experiences will become less in the the future.
#10 I don't think drupal needs
I don't think drupal needs 'artsy designers'. I suspect such 'artsy designer' types might find it difficult to find a place in the drupal community. Although it'd be great if they could find a place, and I'm sure their contributions would be welcomed.
What drupal does need, however is usability geeks. And, more important than their virtual presence, is that drupal-geeks respect them and their suggestions, and follow through with implementing their usability and interface suggestions. I suspect the latter might be the hardest block to overcome in a such a code-oriented project as drupal.
#11 Design is usability
I think a lot of people that are not into design think it is just about being pretty. In my view a designer who thinks like that is a bad designer.
Pretty is part of it, but that stems from a balance of mood and clarity.
I think the Ubuntu design is probably my favourite open source example of this. Apple get this too.
#12 design is more than usability
Design is more than usability. There are facets that we don't think of with design when it comes to usability. Take the beautiful paintings of London with Big Ben. Compare them to a picture. The paintings are not to scale, they accentuate features, and we want to look at them more than we do the real pictures. Artists know something about what people like to look at. They know how to turn something ordinary into something beautiful. Drupal needs that. Hey, websites in general need that.
#13 Yes, I was underselling it a
Yes, I was underselling it a bit.
But beautiful artwork has a lot in common with usability. Artists understand how different decisions lead your eye around an image; drawing your attention to different parts. A lot of the beauty comes from the fact that our eyes are guided around the image in a very natural and comfortable manner. They do this through colour and contrast and detail and movement...
An amateur may lead you straight off of the page, or perhaps leave you completely unsure where you should look.
That is just one aspect of course. Good design will conjure up the community spirit for example. And be memorable. And stand out as different from everything else. And so much more.
Beauty is the result of all these things.
#14 Leave design to the designers
1. If you change any Drupal core css files, announce it on the front page of Drupal.org. Otherwise all themes that don't fully overwrite core css will fall apart - as I have discovered after a 4.7.x security upgrade that also brought a change in drupal.css.
2. Dealing with the $css variable in themes is painful. First I have to check what's loaded, then unset() unwanted stylesheets one by one - and often half of a css file is useful while the other half needs to be thrown out, so then comes tedious overwriting, tracing inheritances, copying styles back and forth, etc. CSS logic does not come hand-in-hand with module logic, so instead of modules having css files, we should compartmentalize core css into essential (admin) and non-essential (content) packages and make it possible to switch them off easily with a single line of code. Just what exactly is essential and non-essential could be subject to debate or analysis. Look at a number of well-designed Drupal sites and see which styles tend to be overwritten or thrown out (pretty much everything except collapsing fieldsets, tabs and a few other admin styles).
3. Continuing from point 2 - css files should not be used as a tool to pretty up ungainly HTML. If you are a module developer and the output of your module isn't usable when displayed as plain HTML with default browser styles then chances are that you are doing something wrong. There are very few exceptions to this rule.
4. Update the theme screenshot guidelines: http://drupal.org/node/11637 These guidelines guarantee that only meat-and-potato header-left-right-footer designs can be submitted. "It is best that screenshots are consistent". Translation: We don't like variety. If you have an interesting design specifically tailored for a corporate brochure or a photo gallery site, you need not apply...
#15 submit issues
For these I would suggest submitting issues and starting these discussions.
But, I see these are more of a theming issue and not really talking about how to get designers involved. Unless I am missing something. Are these things turning designers away? If so, how?
#16 blank sheet please
Turning a design into a Drupal theme means you either spend an awful lot of time overwriting defaults, or you spend an awful lot of time trying to figure out how to switch things off so you don't have to overwrite. Designers want a blank sheet when they start working. The biggest time waster in web design is dealing with defaults and tracing inheritances. Spending an entire afternoon investigating what causes the 5 pixel gap under a div - turns out it's some obscure declaration that's inherited from system.css. 95 percent of designers hate this part of the job. One way to attract designers is to make it easy to go back to unstyled content (and when you don't style content it's much easier to spot funny HTML output, so at the end designers won't have to dig in module files searching for theme_ functions).
#17 Agreed....
Edith,
This is a little off-topic, because you're talking about how to make drupal easier for designers to work with, rather than how to get designers involved in the community...but that being said:
I agree with what you say here...us designers want a blank sheet to work with. Probably 50% of my design time is spent hunting down core or module css that I didn't want in the first place. It seems like a total waste of time. As you suggest, a blank page is better...then I can design what I want, and not spend time overwriting existing stuff I don't.
I understand why this is the case, however. They want drupal usable and presentable for "non themers" right out of the box. If nothing was styled, drupal would look even worse when setup by a non-designer. But to me, this almost violates the concept of semantic markup (notice I said almost)...however instead of putting styles in the html, they put them in the core of drupal. For us designers, they might as well be in the html...because we're forced to overwrite them in the same way.
Good point here Edith...
#18 so much css
How would you handle all that CSS. There is a lot of CSS to make things look readable out of the box. All of the CSS on admin screens. The CSS to make menus look right. There is a lot of CSS.
Starting with a blank slate sounds good in theory. But, I wonder how it would be in practice. Would you care to give it a try on a theme? Start with a blank slate. To see how it is in practice. I could show you how to do that.
Or, would better documentation and tools help solve this?
#19 Good point...
I think this is a good point...and maybe there's a happy medium.
I think the point is: as a designer you deal with alot of assumptions about style that are being made by programmers...not an ideal way to start.
Maybe the answer isn't a clean slate, but something closer to that concept would be really helpful.
#20 tools....
I guess I am, also, wondering about tools. What tools could make this easier now with the current system?
#21 cascading themes
The way Drupal would work for me best is to have it come out of the box completely naked, with an option to turn on a couple of optional base themes:
(1) overwrite browser defaults - see Eric Meyer's browser reset stylesheet
(2) provide basic theming for admin pages
(3) provide basic tipographical theming for content (font sizes, padding, margin for HTML elements like h1, p, etc. - see Web Typography Sucks by Richard Rutter and Mark Boulton)
(4) provide basic themes for various layouts (at least 8-10 popular layout types, from simple blog-like 2 column to complex newspaper panels style)
(1), (2) and (3) are just stylesheets; (4) is basically what Panels module does, but it would be nice to have it in core (responsible designers don't build themes on the functionality of a contrib module).
#22 Brilliant!
Edith...this would be perfect. What you suggest here would be a huge leg up to designers and could still easily offer the 'out of the box' styling that others would like...
Thanks for sharing and thinking about this...
#23 What about a Designer
What about a Designer Friendly Drupal Distro?
#24 Relevant issue
http://drupal.org/node/125428