Why Designers don't collaborate like Developers

Events happening in the community are now at Drupal community events on www.drupal.org.
nicelobster's picture

I had an ephiphany at Drupalcon SF. I realized the reasons designers and project managers haven't devloped the same online collaboartion techniques as developers is because of the lack of a feedback loop.

When you participate in the Drupal community as a coder and you either report a bug, contribute a module, or submit a patch, you get feedback in several ways. You gain cred in the community as a person who "gets things done", you gain some respect, or you get to see your work get used and improved by others, all of which create a multitude of good feelings. Feelings of belonging. Feelings of love and acceptance. Feelings of accomplishment and goodness knowing that you are part of something that is bigger than the sum of it's parts. This feedback loop is potent and has been the source of this community's success.

In the design world, if we do it the same way, the feedback loop does not organically do the same thing. When I post a blog about a new technique, the most I get back in the feedback loop are some comments. But I have no way of knowing what people do from there. No way of seeing work that is built on top of my shared ideas. No way or feeling part of something bigger than myself. This is why the design community and the project manager community has not organically thrived within the same structure as the developers in the Drupal universe.

So how do we do it? What is the potent feedback loop that keeps us coming back for more? Drupalcon certainly produces a shot in the arm of inspiration, but that is often lost quickly and the posts in this group dwindle to folks looking to hire designers and themers.

What is the mechanism? How do we share and perpetuate the concepts of open source-y-ness in our area of expertise? Open for ideas....

Comments

still pretty pumped

jessebeach's picture

I'm still pretty pumped from DCSF. Ready to slash out markup with views and reclass the world. Problem is, that's all done locally, usually to fit a specific project :/

Is there anything you've been working on that you want to discuss? I at least am up for it.

kevingarcia's picture

I think you've hit the nail in the head. When I attended your module on design, and saw your fireworks template, my initial thought was "Why aren't we doing this more?" - I think up until now, most designers end up working in rather isolated/insular settings, where discussing our workflows, sharing files, and collaborating (not merely demoing) are seen as dangerous. A designer that takes a template and adapts it is generally beaten down by the design community, instead of elevated.

On the other hand, we are seeing great strides in the "open source typography" initiatives, as well as broader adoption of creative commons, etc.

Perhaps the real answer, would be to have more of us adopt an "Open Source Design" initiative, using CC licensing to distribute and discuss our methodologies. As far as the feedback loop? I'm not sure I have a clear answer to this quite yet. I want to say "participation should be enough" - but there needs to be a critical mass before that becomes really sustainable. I'd be willing to commit some of my free-time resources to growing the community, giving feedback and helping create more common resources.

A lot of it can start here on drupal.org, and if there is enough interest, then perhaps we can talk about starting a proper site with more sharing tools, documentation and such.

Something that came out of the Designer's boaf during drupalcon was the need to bring more designers into the drupal fold and ways of achieving that. Perhaps focusing it less on the technical aspects of drupal, and more on common design elements and methodologies would be the way to go.

Anyway, that's it for my convoluted thoughts.

More Drupal Design Camps!

todd nienkerk's picture

I completely agree with you, Nica. I derive far more satisfaction from maintaining modules than I do banging away on contributed themes, mainly because a module is binary: it either works or it doesn't. Contributed themes exist in an unhappy spectrum ranging from "terrible" to "good enough."

A similar epiphany led me to write a post about why Drupal.org lacks good themes. The reasons I outline there are largely economic. In short, I argue that themes are custom-fit to a client's proprietary brand and therefore rarely reusable; functionality, however, is intended to be reusable and... modular. Open-source themes also fail to pay dividends: What company would use a theme generic enough to be usable and improvable by the community at large?

My collaboration itch is scratched at DrupalCons and camps -- especially the Drupal Design Camp held last summer in Boston. I gained more theming knowledge in those two days than I earned through the previous year's hands-on experience.

Todd Ross Nienkerk
Digital Strategist and Partner
Four Kitchens: Big ideas for the web
IRC: toddross

You only need to look at

lewisnyman's picture

You only need to look at Wordpress to see the benefits quality themes bring to lay people.
For some purposes a templated theme will do just fine.
It's not catering to that market that is holding back the adoption rate of drupal imo.

There is a very provocative active on this subject on drawar: We Don’t Need You to Design Anymore.

Collaborative theming can work, as shown by the Drupal.org Redesign.

I think maybe starting with input for a group of designers, with two project leads to oversee the guidelines.

Once the actual design is done, the development, which I would assume would be close 100% front end, can be split up in the issue queue.

...

todd nienkerk's picture

You only need to look at Wordpress to see the benefits quality themes bring to lay people.

WordPress themes tend to pack functionality into the theme itself instead of relying on a modular, plugin-based method of site building. While it makes setting up a site much easier -- the user only has to flip on a theme to enable all kinds of whiz-bang functionality -- that theme-building approach is unsustainable and counter to Drupal best practices. It's also sales-driven, which means the only people who would improve or support a theme are the people making money off selling licenses for it.

Collaborative theming can work, as shown by the Drupal.org Redesign.

As someone who has been working on that project for nearly a year-and-a-half, I think it's a bad example of whether distributed design/theming works. (So far, it hasn't worked, though the reasons are many and don't all relate to the subject at hand.) A better example would be the theming improvements made to Drupal 7.x.

Todd Ross Nienkerk
Digital Strategist and Partner
Four Kitchens: Big ideas for the web
IRC: toddross

...

Jeff Burnz's picture

Collaborative theming can work, as shown by the Drupal.org Redesign.

Another better example are the candidate themes for Drupal 7 - these have largely been built in a collaborative manner, some more than others (Bartik is the best example). While this is working OK its also excruciatingly slow.

There are many many issue with building anything collaboratively, unfortunately I'm just not convinced themes are a good candidate - modules yes, themes, not so sure.

You only need to look at

Garrett Albright's picture

You only need to look at Wordpress to see the benefits quality themes bring to lay people.

While I can understand what you mean by this, when I think of Wordpress themes, I think of the old adage, "I want to be original, just like everyone else." Too often you can immediately tell that any given site is running Wordpress because it feels like a Wordpress site; like almost all of them are just variations on a small set of themes. In other words, there may be more choices for WP themes, but only a small subset of them seem to be in wide use. Relatively rarely will the fact that a given site is running WP be a surprise - it takes a good amount of theming to scrub off all the Wordpress-ness.

Now, hmm… does any of this sound familiar?

People spend a lot of time worrying about the "lack" of "quality themes" for Drupal. While I think it's great if more become available, I don't really think it's worth agonizing over. So what if a Drupal site run by a non-professional looks like a Drupal site? Most amateur Wordpress sites look like Wordpress sites, and most amateur Joomla sites look like Joomla sites. Now that we've got that over with, is the content on the site interesting?

my revelation

johnvsc's picture

for a long time i wanted to contribute to the community by uploading a theme ... or a series of themes.

I worked for a couple of months building and creating a structure and had some great success with it. by building a base theme and then adding onto it, i learned the more about theming than i had learned before.

and then i abandoned it.

the first reason is, by my very nature, i am not a collaborative person. design / art making is very personal and can't be abstracted. Most artists i know are similar to me. Honestly, i find more true community in the dev life that i have ever found among artists.

Other reasons are: I can't "submit an estimate of time for when an act of creation with be accomplished", i can't "partition the creative process in to individual tasks that can be distributed in economical manner", and i can't spend hours and hours laboring over something that results in, "yeah this is nice but I really want it to look like _______________________________"

drupal is a framework, not a product. Wordpress is a product.

To this point, I think that we can focus on building more base themes. But, i think that a conversation that should exists is " Well, if you are going to use Drupal, you are really going to have to higher a professional themer to make it look just how you want it."

This, is not only cuts to the chase: people want themes that are singular. But, this is also a smart business model.

...

dreamleaf's picture

I think a fundamental difference that is pointed at in the initial posting, about the feedback loop is really valid. However I would go further and say that it's not just about the future usage/long term value, but also the process that is collaboration.

Where you have a module submitted, it is beneficial for the creator to receive input, feedback and assistance at making it even better. For designers (a point I'll hit in a minute), the process of creating something worthy of submission is very subjective. As @johnvsc points out, the creative process is not a methodical or logical process, rather something that requires the independence and freedom to actually get things wrong before getting them right. And of course, it's sometimes in the "getting it wrong" that something happens and the initial idea is changed.

So the basic difference in process comes from the difference in "chaos vs calm". That being said I have a pretty logical structure to designing, but that may be because I am used to interpreting clients briefs that certain aspects of my designs follow certain patterns. /digression off

Since getting my feet wet in the Drupal landscape something has always struck me as a dividing line between the creatives and coders, for some it may be simple wordplay but the definitions within the Drupal community between Designer, Themer, Developer really need clearing up.

I read a lot around Drupal discussions about attracting designers to Drupal, as quoted in this thread - designers have made a massive impact to the Wordpress landscape and could do the same for Drupal... BUT... there has to be an understanding....

Designers design,
Themers take designs and make them work with Drupal,
Developers created the magic that powers the designs at a system level.

Of course there are overlaps sometimes, for me I design and theme, I know people who theme and develop, and developers that create themes. But this highlights the reason I believe 1) that designers aren't flocking to Drupal & 2) why collaboration is so difficult.
Designers entering the drupal world are hit with a culture so immersed in developers and code that they don't see a way to contribute. A simple conversation about "what does designing for drupal entail" quickly turns into a feature list and even quicker into subversion setup and issue queues.

So, am I just waffling on or do I have an idea to overcome the barrier?
I would propose an avenue where developers could request the assistance of a designer(s), as an entrance point into the world and also act as a point of contact for not unrelated questions. Drupal doesn't need "design mentors" but it does need a "welcome team" for the uninitiated.

An example off the top of my head would be the Advanced Forum module. There is very little in terms of alternate options for a good forum system, and it could really be a powerhouse in making Drupal stand against other systems but there would need to be a good range of inbuilt styling to make it compete. Now I doubt the creator has time to be constantly going through creating new buttons or colour schemes but has made it easy to style instead. Match the great module with a great designer and you get a more powerful module.
The designer gets due credit, their work is visible for all to see (use or adapt) and the module is propelled to greater success.

All in all, collaboration CAN happen, but it has to be between the right people. By matching skill-sets to needs would both encourage and equip. So, who wants me?

between the creatives and

Garrett Albright's picture

between the creatives and coders

Because there's nothing creative about coding, amirite?

...

dreamleaf's picture

hoho - wordplay, I like that :D

I was just making the distinction that some people are designers and 1) don't know how to code & 2) don't want to learn to code (because they are designers).

I did state as well that there are crossover people, and even though not explicitly mentioned, I suppose coding could be creative. However, as far as my knowledge goes coding/programming works with established languages which are pre-written and are learnt. You can't compare the "creative coding" in the same way as "creative design"... that would be like having a drupal design standard that says all links should be blue.

The way coders get creative is far different to designers (using my definition of designer) get creative. I have the utmost respect for the people who can take a blank file and craft it into a functional usable piece of code.

I'd love it

michelle's picture

Just stumbled on this old post and wanted to say I'd love it if designers would take an interest in AF. I have no design skills but have been doing the best I can to make the styles design friendly with the help of some friends like stephthegeek. But having someone who has time to really dig into it and make some styles and tell me where the weak parts are (or, better yet, tell me how to fix them. ;) would be awesome!

Michelle

?

nicelobster's picture

Hey Michelle, what does AF stand for?

AF stands for

Thanks for the insight

lewisnyman's picture

Thanks for the insight guys.

Ok I guess a better example would be Drupal 7 or a packaged theme as a "design by committee" process.

The strong point about the Blue Cheese theme, if I am correct, is that clear were written up by Boulton, leaving theme development and testing stages up to the community.

Design by Commitee is a perfectly reasonable process but maybe not well suited to this enviroment?
I could be wrong with this assumption, feel free to correct me.

the first reason is, by my very nature, i am not a collaborative person. design / art making is very personal and can't be abstracted. Most artists i know are similar to me. Honestly, i find more true community in the dev life that i have ever found among artists.

I believe that art is very personal, design is not.
I also believe that you should design for the user, not for yourself.

drupal is a framework, not a product. Wordpress is a product.

To this point, I think that we can focus on building more base themes. But, i think that a conversation that should exists is " Well, if you are going to use Drupal, you are really going to have to higher a professional themer to make it look just how you want it."

This, is not only cuts to the chase: people want themes that are singular. But, this is also a smart business model.

Some customers can not afford to hire a professional designer to create a theme from scratch (or from a base).
Of course I'm not saying that they would be better off then if they did hire a professional to provide them with a bespoke solution but budget always plays a part in any design process, unless there is not one.

And to these people, we are meant to say "Get Lost"? "Go use another CMS"?

I don't think that is a healthy attitude for the future of Drupal.

i whole heartedly agree

johnvsc's picture

that

...art is very personal, design is not.
... that you should design for the user, not for yourself.

but when you are creating a generic theme ... you have yourself as the initial user.

and maybe that is an important distinction / solution.

The notion that people who need themes should go somewhere else ... or pony up a wad of $$$ for a theme isn't what I was going for. Alot of people don't need / want a custom theme: they just want something that is 80% there.

However, creating even a halfway decent theme is a ton of work... not unlike building a seriously robust module.

This is an except from Dries'

lewisnyman's picture

This is an except from Dries' recent article

"8 steps for Drupal 8"

Step 4: Distributions could help, if we do them right

So how do we improve Drupal as a product? We've had Drupal distributions since the Drupal 4.6 era and I first wrote about the potential of Drupal distributions in 2005. Drupal distributions have great potential -- turnkey solutions help us compete in new and different markets, something that could help Drupal become a significant player. The number of verticals is nearly unlimited and the opportunities are numerous.

There is a risk involved with distributions as well, which means that we need to approach them the right way. The risk is fragmentation, and it is why I feel it is important that distributions build on the usability patterns set by Drupal core. Distributions will be most helpful if they are tools that give you a head start towards building a particular type of Drupal site. Distributions that steal focus away from Drupal, or become hard to administer and extend using Drupal core usability patterns, will lead to fragmentation.

Drupal has a lot of momentum today, but we are still a niche player in the bigger CMS market. Drupal feels bigs, but we're still small. If by enabling more distributions all we do is create a lot of inconsistent niche products, some of which will be competing with one another, the Drupal project will lose momentum. If we can build competitive distributions that strengthen and accelerate the shared Drupal brand by using shared design patterns and user experience, we'll win.

Another risk is that small incompatibilities among distributions can drive distributions further and further apart. When distributions start building their own communities of contributors, having their own issue queues, all disconnected from drupal.org, then we have a problem. The difference between a distribution and a fork can be subtle. A proliferation of incompatible, incomplete and disconnected distributions could quickly become problematic. It would make it a lot harder for all of us to support and market Drupal.

We have written a lot of the the packaging scripts needed to put distributions together for Drupal.org, but we haven't decided yet how we want to use it and what a winning strategy could look like. What remains is a strategy discussion, not a technical discussion.

As a community, we have to take responsibility, and make sure that distributions collaborate rather than compete, much like the way that we attempt to work together on modules. That starts by centralizing all the code on drupal.org, by making Drupal core flexible enough, but also by encouraging shared design patterns and user experience. With distributions, community responsibility and leadership becomes even more important. Building one product is hard. Building a set of products in a way that strengthens and accelerates Drupal is much, much harder.

Maybe Instalation Profiles are a good opportunity for designers to collaborate with developers on providing great out-of-the-box functionality and a solid user experience.

There has been talk of integrating a wizard feature in the install that downloads the appropriate profile.

It would be great if we could work together on designing a quality theme to be bundled as a default with an installation profile.

It would be great if we could

Jeff Burnz's picture

It would be great if we could work together on designing a quality theme to be bundled as a default with an installation profile.

That is virtually impossible IMO because many of these distros have very steep theme requirements - think Atrium, Open Publish and others. They're basically incompatible with each other when it comes to theme layer stuff.

...

dreamleaf's picture

It's a great ideology to have, and by the excerpt from Dries, he has identified the main issues with it. In my head a distribution would be used for a SAAS implementation type scenario - where a group is looking to manage a specific customised feature set which in some way radically alters the normal output of Drupal Core.

Installation profiles are more along the "flavours" of Drupal, where the default core is packaged with specific modules to create out of the box sites as you say.

Both distributions and profiles do not lend themselves to a "default" approach in terms of themes, rather a dist or profile specific suite of themes.

I personally like the idea of profiles for a collaborative project, and I see this as more a way to integrate designers within the community. However as has been mentioned a few times in this discussion, a big drawback is that it would take a really long time to achieve any progress.

The only way to achieve a solid and workable system would be to have a predetermined project lead on a profile that has the yay or nay responsibility and who also drives the project forward. Collaboration is key, but managing that process is essential or it would just end up in a 100 page discussion about proper use of code indentation or the merits of Gimp over Photoshop. These discussions should take place and form part of a project, but should not have an impact on the rate at which the project is delivered.

Agreed. Like with modules, a

lewisnyman's picture

Agreed. Like with modules, a lead maintainer would be essential for organisation and productivity.

There is no reason why a implementers guide and a visual style guide could not be agreed upon.

I believe uberdrupal is a good example, with plans to integrate Acquia Prosper. Especially with upcoming support of the color module.

Adding a range of specialised themes to a profile is an even better idea!
Why have the standard generic themes installed for a profile when you can have ones that are tailored to a specific set of modules and content types?

My conversation is giving way to how I think Drupal as a product should work...sorry if this is way off topic.

So, what are some ways we can do this?

nicelobster's picture

So, we have loads of good discussion here. I want to clarify for the record, that I am the kind of designer that never touches code, so from my own selfish standpoint, I'm posing the question, how do we create a feedback loop that is both potent and organically perpetuates itself?

Contributing themes is just one piece of it.

I did that blog about the Drupal Template.. so that was another way.

But what else is worth sharing and how would we do it?

Some ideas off the cuff to get the convo started would be:

  1. submit your designs for peer feedback in this forum
  2. Share some case studies with a really good or really bad client experience
  3. talk about when you see new interface designs and why they're cool

Just some thoughts... Any others??? I"m not sure if any of those would be self-perpetuating-enough... but you never know.

...

dreamleaf's picture

I quite like 1&3, and maybe even with a bit of a spin to combine them.
If we see something cool, I know personally I sometimes try to recreate it as a learning experience, maybe it would be good if we spot something, to share our versions - explain differences, discuss whys etc
It would also be a good platform for themers to input into how this could be realised in application. That way everyone gains something.

#2 I'm not too sure about with this being a public forum an all that :D

Dribble is the closest thing

kevingarcia's picture

Dribble is the closest thing I've found to a fun collaborative environment for designers where iterating is rewarded. Deviant Art, Behance, Kontain also give some options for sharing projects. None of them are drupal specific, however, and they seem more focused on showing off your projects than actually collaborating & iterating. I've encountered very few design-centric sharing sites where critique isn't either sycophantic, or completely mean-spirited. The middle ground is kind of missing.

1,2 & 3 are a good start. Discussions on on-going projects would help as well. Not all of us have ongoing projects at the moment, but I would be more than happy to provide feedback and critique, at the very least, and share my own projects when necessary.

I wonder if any of the already established design communities have a "groups" feature that would allow for a drupal group?. Anyone know of the top of their head?

I'd like to see this forum used more for those, than for employment opportunities or theme specific code discussions, for example. Isn't there a theming group/forum already?

As a designer who is not

nomonstersinme's picture

As a designer who is not always so sure of herself - I wouldn't jump at the opportunity to share my design work with the Drupal community... Design is so personal and subjective.

I'd like to think Skinr Skin sets could be a useful way for us to share the latest techniques and design elements.