You make a great observation about the difference between designers and developers. I think it's a problem worth working on.

You are right its not going to be easy - and in a way the first step is to get all the frustration out there and out of the way! Then we can all take a deep breathe, realise this will get uncomfortable at times and try and see how things can be improved. If d7 is anything to go by - big steps are being made already. I've watched from the sidelines for quite some time but certainly hope that I will be able to help as well in this.

I applaud you for stepping out of the 140 character limit and really putting your heart out there. Now, every time you see the criticism, just send the link to this blog post and then move on.

The gods picked a good time for this to happen -- just before Drupalcon. I'm looking forward to some news of -- not necessarily a solution -- but an approach for how to tackle the things that can be improved.

I don't know if the docs have matured since the early days of Views 2, but I know I had a hell of a time figuring out how to use the tpl override system. And I'm a coder! Maybe the first step is a concerted effort to educate about that amazing feature. I wouldn't doubt if the resource is already there, but we need to push the hell out of it.

What you do for Drupal is incredibly important and remember that you receive the barbs because Views is so damned important to us all.

Again, thanks for taking that all important step.

Some good observations that really do show a community that does not have a symbiotic relationship.

There are a couple of things I'd like to add to the mix regarding the importance of semantics to designers - specifically typographic designers. Document structure is of vital importance to typographic designers. The display of that structure is what defines brand and many other important factors that determine a design's success. In order for that mental model (of the document's structure) to be successfully communicated through the type (through headings, paragraphs, lists etc), then the underlying code (and the important semantics) must match. My point of frustration yesterday was that these didn't match. I shouldn't have vented on Twitter, but that's what I do, and I'm sorry if you felt it was an attack on your work - it wasn't. It was a result of the code I was looking at not matching the model. Typographic fail. Brand fail. Design fail.

Of course, as you point out, I could override that code. And I probably shouldn't be using Views anyway if I require that level of 'pure' html. Fair point. Wrong tool for the job apparently.

I certainly think it would help to look to other industries where designers and engineers co-exist. Architecture, product and industrial design, medicine (to a degree). All of these industries have designers who require engineers to realise their work. And I seem to be rambling now without any conclusion in sight.

It's a shame there is this divide in this community. In other communities I participate in, there isn't a divide at all.

I'm not sure on a way forward. I'm sure breaking down some of the barriers to participation for designers would help. Recognising that document structure really matters for many designers, and putting in place tools to help designers change those structures without learning a shedload of php.

I totally agree with your last few paragraphs - Views and CCK are such fabulous modules because they are so intelligently generic. The basic code gets the job done. Code is generated so that content is displayed in the correct places at the correct times.

But the thing that is so beautiful about these modules is that the generic code that is output can be adapted to specific circumstances with those magic template files - so many options, so many varieties - a brilliant solution, allowing the designer, developer or designer-developer hybrid, the themer, to make generated HTML semantically correct in the specific situation of the specific implementation. And the modules give you a huge helping hand in choosing and making those templates too! A miracle!

Merlin of Chaos, I thank you for bringing some order to the chaotic world of generated code.

This is an excellent post. Thanks so much! Peer review is one of the things which makes OS work so well. But developers and designers aren't so much peers but instead strange bedfellows. Developers should never have to answer to designers why they did x; the converse is also true when designers want y. As you point out; one group is giving and another is taking and that model does not lend itself to sustainability. One piece of the answer may to continue to improve the documentation which helps us better work together. By empowering the designer to override the overrideable, this encourages the developer to work in the abstract and permits the developer to apply the specific.

First, I want to address something which I'm sure you know is going to seriously piss off designers and this is of course the stance you take that designers need developers and developers don't need designers. My argument against that is simply that Designers don't just make things pretty, they make things usable, and if a developer's product isn't usable, no one will use it and it will become obsolete and then the developer's job will become pointless. But, that's not what I really came here to say.

I'm on the fence with this issue. I am a designer first, and I abhor the default HTML output of Views, but I also really understand the dilemma between trying to please the HTML-purists and still making a module that is out-of-the-box usable for noobs. I don't know how to solve this problem. I'm almost sure it isn't possible to do this with a module as complex as Views. But, I thoroughly thank you for putting all the HTML into a .tpl.php file; because of that it is all easy to be overridden by someone who knows what they're doing.

A side has to be chosen, specifically in the Views module. Does the HTML output cater to professional Designers or does it cater to over-worked non-profit marketing director who just downloaded Drupal and is trying to put together a simple website to help her organization even though she has next to no technological expertise? I would argue that the professional Designers have the ability and resources to override the bad stuff with whatever their hearts desire. That's what I do all day long. The non-profit marketing director might not have the luxury to hire a professional, but her organization deserves a fully-functioning website just as much. And isn't that the spirit of Drupal to give laymen the tools to build serious functionality into any website with little technical expertise?

At the same time, I seriously agree with Purrin's post this morning (http://www.calicott.com/articles/2009/inside-the-box-is-the-new-outside-...) It's time that Drupal needs to start embracing the professional design community a little bit more. Drupal will hit a glass ceiling if Designers don't come on board. No one wants to pay $50k for a web application built on Drupal if it looks like crap and is unusable, and if web development firms aren't able to find Designers who know Drupal, then web development firms will start looking towards Wordpress, Joomla or Ruby on Rails as their chief technology.

I think the over-arching issue here is what Purrin mentions in his post; that Drupal is at a crossroads and needs some central leadership, to make some serious decisions about where Drupal is going so we can all be on the same path.

I'd never thought about how the re-usability of each camps work affects each camp. But now that you've written about it, it makes so much sense. Thanks for writing this. I really appreciate all the work that's gone into Views and find it indispensable.

Merlin, I feel and understand your pain at building an application that is all things to all people. I especially understand the problems of being torn between div-itis and simple, clean markup.

I'm inclined to think that there is no happy medium, and that you're trying to satisfy two drastically different poles with an unhappy compromise.

I can also speak to the miserable and confusing hours our studio has spent writing views overwrites to things that should have been a default: a nice way of presenting calendar dates, a two-column grid with photos on one side and text field on the other. It has no reflection on the quality of your work; it's just that these use cases were never taken into account.

If you categorize 'designer' as a Photoshop jockey who adds a bit of fluff to a web application then I think you have a point.

However, at no point in your article did you use the word 'usable'. Yes, left to developers an application will functionally work however there is no guarantee that it will be useable, or a pleasure to use, or that people won't get lost using it. It will be designed from a data/functional point of view and not a human centric point of view, it may technically succeed but still fail as people hate using it. I really think designers have an awful lot to contribute in this regard. Unfortunately their discipline is not very well understood or appreciated by devs (and vice versa I hasten to add). And I say all this as professional developer who usually too busy trying to get the ruddy thing to work to worry about the UX!

I think the core issue lies here: should Drupal require a developer on a project or not?

Views is insanely complex, and insanely feature-rich. Personally, I think it's at least as important as the rest of Drupal combined, and perhaps this is why it's become a battleground.

On the other hand, I've never needed an Adobe developer to work with Photoshop or with InDesign, or with Microsoft Word. I also don't need a developer to work with Ubercart or CiviCRM or even Sugar CRM.

I ask you this sincerely: am I wrong in wanting Drupal to work for lay persons or designers without the assistance of a developer? If so, where do we draw the line?

Keep up the awesome work! The development world owes so much to you. Thanks for all you do. Throw in a few complimentary divs for me.

Cheers,

Deepsnow

As someone who's been watching this whole thing with some interest (and who definitely comes from the Designer Side of the camp), I'm grateful to hear a longer perspective from you. You make some excellent points, and it's good to see the developer's side of the story.

My observation of this whole mess is this:
1. There's a lot of amazing developers who have been putting untold hours into making Drupal the awesomeness that it is;
2. For a long time, Drupal has mainly been a developer's playground;
3. Now that Drupal's become the robust, crazy-powerful CMS that it is, a lot more designers (like me) are realizing that they can help their clients create bigger, more interesting sites by using it;
4. Those same designers are running into a larger learning curve than they ever have before, since the mechanics of using Drupal are still very much a developer's playground.
5. When we express our frustration, we often get lots of helpful options from the Drupal community, but they're often balanced with either defensive and hostile remarks from developers who don't seem to like criticism of their work (even if it's constructive) and people telling us things like "that belongs in the theme layer" or "you can use a PHP snippet to do that" or "go to the command line" - stuff that's trivial to a developer, but absolutely useless to someone who's always been (and always will be, by intention) a front-end designer.

This isn't meant to be critical - this has just been my observation in the last year or so that I've been working in Drupal.

There has to be a happy medium somewhere if Drupal's going to move forward and continue to grow.

You making ggod points here and the result (at least for me) is that Drupal don't separate enough code and output.

There are CMS's who can achieve that so you will never enter in direct confrontation with designers because they kill absolute control on the output and never meddle with your code.

I'll not give any CMS's name since i'm not here to advertise, but skillful developpers should sometimes look what's news and potentially good on each perspectives.

Regards.

One of the things that I've been particularly interested in lately is how well the work on drupal 7 has been segmented into different types of areas to give a clear bucket for those that know they can certainly contribute their time to that area while knowing they can feel comfortable doing so. While much of this is through IRC or issue queues with patches and reviews etc, it seems like when the need arises, the proper venue for discussion has been used if possible. Most designers I know shudder when I mention all the help they could get in IRC.

Currently in the issue queues when there is an issue, either the maintainer provides a solution, or the community steps up to provide one "because they were made aware that the issue existed and able to step in". While I'm not a module maintainer, it seems as though being able to make folks "aware" of design challenges/needs in the issue queue through some means could be beneficial to actually being able to get that help. And of course as always the maintainer has the last say, whether that helps or hinders progress, who knows.

Just some observations to a topic that will be much larger than any words I've put here.

As a parent who's child just started kindergarten at age 5, there are times we will make a lot of noise to the teacher/school - but that is because we care about our child. SO - thank you to everyone for caring about the areas you hold most dear.

Views actually makes this very easy to do. The problem isn't that views default output "sucks", this is, to some degree, a given. But I think the frustration comes in when people focus on that as the primary problem... it's not. The problem is that there's a little bit of a learning curve to getting the output you want out of views. This is no different than any other aspect of Drupal really, everything has a learning curve here. The important point to take away is this:

If views can deliver the content you want, then marking it up differently really is quite simple.

Earl's spent a lot of time an effort giving us many different tools for that specific job. Heck, even views 1 had the ability to do this (granted you needed to be a coder), but between the ability to literally change the default markup through template overrides (like all other tpl files in drupal) and the ability to utilize per field substitutions (which could literally be used to hide all the default output and rewrite your own custom through the views interface) views really already meets this need. The problem, as with most of drupal, is one of education, and I really think this is where the fat hits the fan.

So this is specifically at you Mark:

Is the problem that you want views default output to be better? or that you need the ability to have that output be better? Because one is stupidly hard, and the other is trivially easy.

Merlin, you've put into words what I think is a very important underlying issue that many have realized but not articulated well (myself included). Thank you.

To those who have noted that developers can't do good work without designers either, well, that's the point. Developers can do passable work without a designer. If a developer just writes code and releases it, it may be ugly, it may be difficult to use, but at the end of the day you can still get something done with it, even if it's suboptimal at doing so.

If a designer (either a graphic designer in Photoshop or an interaction designer or whatever type of designer you want) does a superb job of coming up with a workflow model, a visual layout, or user-facing messages, until a developer ("an implementer") gets involved they can't really do anything but hang their pretty diagrams on the wall. They can't get even a suboptimal product out to users.

A builder working without an architect can still build a house. It may be a crappy house with a roof that always leaks, but it's still a house. An architect without a builder has some nice blueprints he can frame, but doesn't have a house.

Incidentally, the same is true of software architecture and design. That's something Drupal has a hard time accepting, too, in favor of "code it until it works". But that's a subject for another blog...

As for what to do about it, in the near or long term, I see a few things:

1) Developers get more aggressive about asking for usability/design feedback from those who know more than they do, and then take their suggestions.

2) Designers get more aggressive about finding places where their input is useful, and offering solid, substantiated recommendations.

3) Drupal as a whole gets much more aggressive about getting the right people together so that #1 and #2 can happen.

Myself, my professional training is in usability but I currently work primarily as a hard-core developer. There are plenty of places where I'd love to be able to say "hey, design/usability people, what should I do here and why? OK, I'll go do that." There's really no process for that to easily happen, though. For code architectural questions, there's "pop into #Drupal and ask the swarm, and hope they come up with something intelligent", which is not always a good answer but is at least an answer. For design/usability, we don't even have that.

I don't think we can solve the social disconnect until we have the process in place to have a connect. We need that before we have the social convention to connect.

Views is easy to pick on because it's in that gray area of easy to use and impossible to understand.

1. As for designers, let's not get too anal about HTML purity and DIV madness. Views is built generically to cater to the 80% of designs and themes. It balances flexibility in design vs. code weight. Every time I look at views code, it seems very wordy, but the more I think about it, you appreciate the extra DIVs when you want to apply CSS to a part of the code and there happens to be a DIV or CLASS there to get at it. Heck, if you look throughout the code Drupal outputs, it's very wordy, tabbed irregularly, and has 30+ style sheets.

2. Views is template based. You can rip out the entire default templates and use your own. Reduce the DIVs and make it *clean* as you like. But you'll find that you will lose flexibility and expressiveness. I challenge the theme/design community to come up with a Views template theme/plugin that meets those needs and can do it with less DIVs and classes.

I would argue Views needs more documentation, tooltips, use cases and self documentation fields. But that's a different argument.

Embrace the chaos, the madness, the bazaar that is open source.

This was an insightful post. Thanks for writing it but what you mention about developers not needing designers I have to disagree with.

As an analogy, does the heart work in the service of the brain or vice versa? It can be argued either way by those concerned with their own area of expertise. The heart fails, then comes instant death. The brain fails and the rest of the body can live on but then what's the point? It will die slowly. The importance of being symbiotic should be stressed more often. Mark makes that clear enough in his comment.

This problem isn't isolated to Views. I think it's just expressed more clearly on the direction Drupal has taken in the past. I'm not saying the direction Drupal went is bad but this is a good time to be a lot more serious about designers. Dries took it seriously by bringing Leisa and Mark into the picture for core. I think it'll be a matter of time before contrib modules find the right designers to do the same for their projects.

Overall, I see this as a good problem to have. I only wish I could have been more helpful but talk is cheap. We need to tackle this and get shit done. :)

I would love to have access to designers to make my modules (especially Advanced Forum) better but the ones I know are all busy with their own projects. I've gotten some help, especially from stephthegeek, but not nearly as much as I need. AF has a ton of templates and the only thing I have to go on to know if it's any good or not is whether it validates. I'm not a designer and I don't want to be. I want to write code.

So what's a developer to do? I write my modules for free. I'm not going to pay a designer to help me with something that I make no money off of. So, unless some designer wants to help out just to help out, my modules will continue to have "developer made" markup.

AF doesn't have the install base of views by any means, but it's on about 6K sites so not exactly small either. If merlinofchaos struggles to get the help he needs, what does that mean for those of us who have lower profile modules? I don't have a solution, either. All I know is I'm tired of hearing how awful the HTML is in Drupal while I struggle to get anyone to help make it better.

Michelle

With warlords poised on both sides of the fence looking for an excuse to cleave into their opponents I have to step back and view the whole field. I've been a PHP developer for many years and a full time Drupal developer for over a year and a half now but can't claim to be in the "developer camp" since I don't feel like I'll ever have enough to contribute when compared with so many other developer icons. That said I am also a designer and while I don't do as much design now I still work with themers all day everyday and do try to put thought into all my code from a usability standpoint. Even with that though I don't rate myself worthy for the design camp either.

Looking at it I truly don't understand this camp vs camp mindset anyway. Drupal is a tough world to break into from either side. It has never been easy and I don't know that it ever can be. Designers want to see their layouts come to life and all the bells and whistles work without having to understand how to do anything in PHP. Developers want to see their glorious new module become the buzz on IRC after a weekend of caffeine fueled coding but only concentrate on the functionality to get to that point and don't bother adding in any divs or classes.

That was a generalization of course and I know there are lots of mixed bag people in the "community" like myself who spent numerous hours sifting though drupal.org and all the forums, groups, and blogs of other developers trying to find the answers to the everyday problems we face when trying to do practically anything in Drupal and we also visited countless sites and read our CSS books to achieve the design aesthetics we wanted for the site we were working on. Why can't everyone do this? Why does it have to be one or the other?

We are in an industry that is a true combination of form and function. When I'm wearing a developer hat I should keep in mind that if the user experience sucks then my app sucks. When wearing a designer barret when I create a wireframe and mockups for a feature I really need to have an idea on how to accomplish the functionality. This is where the "they need us, we don't need them" litany breaks down. If my app looks horrible it's not going to get used and I wasted my time. If my pretty page looks awesome but the feature is clunky same scenario.

If you are a designer and want to contribute write a style guide and post it so developers can utilize it. Offer up some CSS packages for form elements a developer can drop in, there are actually numerous things designers can contribute back to the community that would be reusable by everyone. Offer to help in the design process when a developer reaches out. As developers don't ignore requests for style changes. Either explain why it's not feasible and how to work around it or do it even if you have to a hundred times. Tag an entry so you can easily find it and just start responding with quick links to caned responses if you have to. And when you have to drop some html into your code do it in a flexible way and add a div or abstract it enough to be useful to others.

If everyone wants a community then treat your fellow Drupal users with more respect and don't offer up insults in the form of criticisms or impotent excuses to cover being slack about a code fix. Drupal will die if designers are not accepted into the fold a little more warmly. Other CMS systems that are more designer friendly will push on even if they lack features. At the same time though designers need to understand the backend a little more as well and take some responsibility in all of this. If Drupal does die then they will end up with a CMS with less features simply because they didn't take the time to learn more about it. Developers, buy a CSS book and read some style blogs. Designers, there are now numerous Drupal development books at your disposal, use them wisely.

Okay, sorry to stream of consciousness babble applied to this wonderful post. I do have a lot of passion for the community as a whole even if the community often seems to volatile to speak out in as a small fish.

Thanks, Earl, for an interesting post written in a calm and not antagonistic tone.

Am I wrong in thinking that Dries (founder/leader of Drupal) has stated that a goal for Drupal should be that (lots of kinds of) web sites can be created with Drupal without the need of coders? Drupal's philosophy so far has been all about providing a lean installation that is easily adaptable to as many use cases as possible.

Views is contrib and its development by Earl was undertaken (and funded) for a particular purpose and yet it really dovetails well with the Drupal philosophy. It's super powerful and super flexible, and if you want it to do some thing a little bit different for a specific application, you can customize it pretty much to your heart's content. You want different markup, you can change the markup with theme overrides. You want bigger changes, you can write (or commission) a custom module to do that.

There has long been chatter about the idea of one drupal core codebase, many install profiles. This could be extended to contrib modules. Someone could offer a package of theme overrides for Views (or any other modules or aspect of Drupal) that offers a different default approach to markup output. Then people could choose between, for example, all-purpose easy to CSS theme Views verbose, and minimalist markup, or markup style x, whatever. One Drupal package for professional designers who want x, one for laymen who benefit from y, etc.

Wwhile not all suggestions/requests may be able to be taken up from the issue queues and incorporated by module maintainers for any number of reasons, many such ideas (eg what sorts of theme overrides to make to adjust markup and how to implement them) can be contributed to the documentation (module documentation as well as Drupal handbook pages).

Thanks for Views! It is indispensable to my daily work.

You bring up the point that tools like CCK and Views let people get a lot done without a developer, i.e. that some 90% of functionality is available out of the box. This is because people such as yourself have built tools that explicitly exists to do code-like things without code.

But, the fact that you, as a developer, can build and release tools without a designer in the first place is due to a similar effect: designers (or people who take up that role) have done enough work with Drupal's default markup and styling so that you can produce a functional, recognizable UI without having to write your own HTML/CSS from scratch. That is, as long as you are willing to stick to the kinds of markup and UI that Drupal supports out of the box, i.e. basic forms and simplistic little AJAX toys, then you don't need a designer. And in fact, a lot of what Drupal does out of the box is not even supplied by Drupal itself, but by the browser.

In other words, Drupal-the-CMF-on-top-of-HTML/HTTP comes with enough pieces of re-usable design out of the box to satisfy exactly the same 90% of needs that developers have. But that 90% is not enough either if you want a sophisticated product.

Most people don't realize this, because it is considered self-evident that you, as a developer, will eventually need to learn some HTML/CSS. But in an ideal world, this should /not/ be the case. If designers should be able to develop without writing code, then developers should be able to build functionality without design.

A developer who is happy with a sub-optimally designed product is no different from a designer who accepts a buggy, insecure hacked up piece of code that nevertheless gets the job done. Both are happy from their own perspective, but both have incomplete work in their hands.

Hehe, I also like this to come up now.

As in many discussions, first comes the frustration, and reason much later. So it should be normal and healthy for the two "camps" to yell at each other for a while.

I am really confident that things will change in the near future. Up to now Design and UX people just did not have a critical mass inside the drupal Community and say Drupal project. Though lots were actually designing it, especially on the well-known and high-profile sites. Many projects get the Photoshop mockups done by people who do not have to care much about the underlying system, so the numbers may lower than I think.

But we are moving towards a critical mass, which is proven by all these attacks that are run on poor Earl. If Designers persist inside the project, things will change. Just like marrying is very probably to give you better and healthier meals and a cosier living room (50 bucks into the sexism cashbox).

Drupal is a super-useful tool for designers, and as it gets a lot easier with Drupal 7 to run your casual blog with it, this will attract quite some.

But as for now, I guess the "pain phase" is not over.

@all: If you don't like it, contribute. The biggest strength of Drupal is its contributors. Without contributors there would be no Drupal. Contributions from both designers and developers are welcome. There are many ways to contribute. How to contribute to Drupal.

Personally I don't miss the before Views time. It's a really big improvement.

@Earl: Thanks for sharing your observation about Designers versus Developers. It will facilitate understanding and collaboration between Designers and Developers.

Views is an awesome query generator very graciously bestowed upon the community. It generates default output. If Earl Miles would have left it at that, one could say, "interesting, I'll try to use it. Hmmm, the output sucks".

But Earl Miles didn't stop there. Even back in version 1 of views he took the time to create the theming wizard, and took the time to explain to those interested in listening (like those of us back then in the Drupal Dojo in 2007), how easy it was to override the default output. He punched up foreach loops into pastebin.com which go into template.php which delivered the data in nice $variables graphic designers don't have to be perturbed by. He started an ititiative to collect all the overridable templates and make them easily available for themers. He did that because he is amazingly sensitive to people's needs, to those working stiffs struggling to come up with a product to meet specific needs.

Then, if you look at Views 2, not only was it pretty much easy to upgrade old Views 1 views, not only was the query generation improved with relationships, views of things other than nodes, etc., etc., etc., but two things emerged: 1) Advanced help, brilliantly fashioned as a separate reusable module, which tells you everything you need to know really to use views, well within the rules of the game for open source free software; and 2) an awesome theming machine: many displays for a single view, on the semantic level; and theming information available at the lazy click of a button which makes gives you all the case-specific templates (at every level of generation from the whole view down to field aspects) which you can then apply at any scope according to a naming convention (all views, just this view, just this view with this display, ...).

The end result is that if you know where your theme directory is, and you know how to copy and paste, and if you then know how to find the convenient (somebody cared about making this usable!) "Rescan template files" button, then, you're in! You can reset (you know where your delete button is, don't you?) and redo. And contribute the whole kit and kaboodle and make a 960 like sensation all over the world.

And to top it off, under the hood, Views 2 is object oriented. So what, ya say? Well, look at this: in the template responsible for generating the whole view, you can scrap the default output and replace it with these three lines of code:

Yeah, stick in all the typography classes you want.

Ah, don't know PHP, you say? No-one in the community will help you do this? Can't find any free videos anywhere on how to do this? Other communities don't have this problem?

What's really going on here?

First of all, other communities don't have this "problem" because they don't have a built in query generator that lets you list stuff without coding. Period.

Second of all: how much are you charging for that website application you're delivering?

Yes, the problem arises when you need to use the off-the-shelf Drupal Content Management Framework to create a product. Then that last 10% Drupal doesn't do off-the-shelf has to be created by a team involving input from development, graphic design, and other skill-sets.

So, it's the economy, oh arrogance!

The real problem isn't any deficiency in the graciously contributed, free as in beer and love, views module; and the problem isn't that developers and coders don't get along in the Drupal community. Old Freud would call that a projection:

The real problem is that you don't have developers and coders working together in your team properly as befits "the making of" your 100K or more website application.

And if it's a 10K website application, you can still afford to make sure the right people with the right skills are teamed together for enough time to get the _product_ done.

And if you're a working stiff trying to get it done on your own (so don't complain, be happy Drupal even exists), you can still find out how to do it by investing a little time...

The real argument, fight, schism is within the shop which, in spite of its lack of best practices, is arrogant enough to say it is defining corporate brands in a website application without taking the time to create a team, create an infrastructure, and best practices overall within their shop so the proper skill-sets interact in the context of a proper process.

Bravo Earl Miles! Bravo Views! Bravo Drupal! Bravo Open Source design (not you, in the software sense) or the lack thereof.

Victor Kane
http://awebfactory.com.ar
http://projectflowandtracker.com

I love Drupal (really, i do). But i think that theme system, as elegant as it is if you like php, is far far away from a CMS like Modx, in wich html and PHP are REALLY separated and where you don't have to find an obscure breadcrumd function in a theme.inc wich is in a "includes" folder; and then copy paste this function in template.php of your themen renaming it with the name of your theme or of your template engine.

Template system of drupal are good, but that doesn't hurt to hear people / designers say that this part could be better.

my two cents, maybe i'm wrong...

There's another way to frame the argument. In the situation where a client has a strong desire for a site to meet a certain visual design aesthetic and likes the designer's work, then the bit is flipped. The designer simply doesn't need the developer. The designer needs the client, and the developer needs the designer.

Perhaps that's askew - maybe the designer and the developer need each other, because the client needs _the services_ of both of the designer and developer, and they both need _the money_ from the client. And if the client is the developer, and the designer still needs the client and the developer, and the developer needs the designer and needs himself, the relationship begins to look incestuous and that's just icky.

But we are talking Open Source here. So, what is the Open Source designer's goal? Completely different than the developers; yet designers like developers share their work. Do a search for "free icons" or "free website button" or "free photoshop template" - even "free site design" and check out what is being offered.

What's the relationship between developer and designer in the Open Source community? The same as any other: everybody's looking for that win-win relationship.

Are you a Drupal programmer and you want to distinguish your work from the pack? Find a designer who's pining to add a portfolio piece that showcases hard-learned usability skills and get to work.

Are you a designer with an idea for the world's best interface, chock full of UX goodness? Compel a Drupal programmer to drink your kool-aid and they can show off their coding talents powered by an amazing CMS. And if you think there's a problem with the interface of someone else's work, pony up and provide a fix.

I loved reading this post and all the comments.

I just wanted to say that because of the steep learning curve with php it seems like it would make sense to try and separate the php and html more than it is - however, I feel this resistance from themers. The themers that I have had contact with prefer theme functions and overrides instead of templates - they turn their noses up at even a simple page-front.tpl.php. I can completely understand why but this makes it extremely hard for designers to get involved.

In my opinion, drupal needs an agreed upon theme structure. I prefer the Studio/Sky way because I know where everything is. If this existed it could be really well documented and be much easier for a designer to learn and contribute their designs.

Anyway - I also want to offer my services to any module developers. I appreciate all the awesome modules out there that let noobs like me make websites that can function - so if anyone wants design/html/css help for a contrib module hit me up!

If the criticism of Views is that the HTML & CSS exported is not suitable then someone who knows something about HTML & CSS should take a look at the module that's exporting it. If getting into the module and poking around sounds intimidating, then you need to ask for help. Saying it isn't done well isn't helpful. Neither is passing down reviews. Get in there and work on fixing it!

The main problem in Drupal has been good developers/programmers over all these years and suddenly one or two very bad, big mouthed, illogical designers. These very few "designers" have lectured a lot of bloats but produced what has crippled Drupal or has hurt or going to hurt plenty of Drupal users. The most sad part is that they have been even successful in influencing some of the key persons in Drupal with self proclaimed bluffs.

Their "design" work even on the face value, even its a simple typography, just sucks. There has been designers in Drupal all these years too but had it not been for these one or two mishap-monsters we would not be hearing of such dev-designer divide.

It is a mishap and misfortune we did not get a designer of the merits similar to developers like Merlin or others.

It is an issue I have observed many times. I created a funny little Flash interaction about this subject. You can see it here: http://sinan.bilimternet.com/blog/what-kind-drupaller-are-you . I created this to show not everybody must be fully a developer or designer, but there are also areas in the middle ;)

(@merlin: I don't know if it is OK to post a link from my personal site, but I just wanted to share it. If you are not happy with it, please erase the comment.)

There is a nice module for the views if somebody really needs a clean, semantic markup for Views: http://drupal.org/project/semanticviews

I didn't try it yet, but I watched the screencast and it seems nice...

I've had a hard time trying to convince the designers at my shop the benefit of using an actual cms as opposed to the ad-hoc bs we've been building forever until recently, when their feet were held to the fire. Now they're game. We've been building drupal sites for a couple of years (every single one using views, btw), but me, the developer, has been responsible for everything except the static mock up until recently because they didn't understand it.

All of our recent and upcoming business has been drupal, so our designers need to learn this, and slowly have been. All of our current sites depend on views more and more as we learn new uses for the flexibility (i.e. http://www.cantonwinefestival.com - the jQuery-driven random fading background on every page - have you seen that one before?).

My problem with designers complaining about too much markup is that the way it is output by views (and panels, which we started using recently) is that it gives you limitless flexibility with design; you just need to know how to use it. If you don't like any portion of the stack of output, there are theme overrides available for every container in the stack, making this a moot point, and any designer who knows how to include a template and process an if-then statement should be able to name an overridden template correctly and make things appear as they wish. Even without (i.e. through css), they should be able to make views look exactly as they wish.

Anyhow, I'm not sure if the guy complaining about too much markup was on this or another post, but they seemed related, so that's my thoughts. You give an industrial machine shop's worth of tools to who ever uses your product; it is not your fault that they lose a finger and an eye in the process, then complain that there is too much markup.

BTW, I've used views for years and think it is the single-most ingenious approach to searching, filtering, and displaying any kind of data I have ever seen. I have just started using panels 3 and believe it will make my designers enjoy their jobs again.

Thanks!

-Rich

Before making my point I also want to thank for the post, the comments and the diplomatic and well-balanced tone in which they are written.

The carpenter/architect analogy is good, but in my opinion, comparing the module developer to the carpenter is somewhat inaccurate. The developer is more the tools manufacturer and/or the material supplier. He may build his house with good tools and good materials but without good knowledge of architecture thus ending up with a house poorly suited for living. The architect, as mentioned, may know how to design a house well suited for living, but without good tools and good materials his cchouse will be just as poorly suited for living.

To make a decent house they need each other. And they would probably benefit from a carpenter, someone who knows how to use the tools and materials and who knows how to read architectual plans.

But most important of all, neither of them wants to keep making houses for themselves. They want to be able to build and sell houses to many people. I.e. houses well suited for living made of good materials and by good tools.

My point is that Merlin and other good developers may have the opinion that they don't need good designers and good site architects, but what are their modules worth if noone is using them? They will only be used as long as people are interested in Drupal powered web sites, and people will only be interested in Drupal powered web sites as long as they are well suited for publishing and presenting whatever people want to publish or present.

Now, as a relatively new drupaller I'm sorry to learn about this community divide. I think it's important to stress that the community is not just made up of developers and designers but also anything in-between. Forcing drupallers into either of these two categories is not helpful.

Also I think it's crucial to acknowledge the importance of every single contribution, whether they be design or module development or anything else. But also to acknowledge that GOOD module developers and GOOD designers are VERY important, and that we in particular need these to work together to make Drupal move forward.

I had to say 75% cause I didn't read all of the comments. The majority of so called Designers aren't Drupal Themers. Most take what is handed to them and try to manipulate it to look the way they want. And with the inclusion of Firebug, the term "Designer" gets tossed around quite a bit.

I myself am a "So called Designer" but I do know a fair bit about PHP and actual theme-ing myself. And I truly appreciate all the hard work the developers put in to Drupal, it's amazing the functionality and ability is on another standard.

Developers do put a lot of hard-work in to everything Drupal, and it's all great.

Now dropping down the Devil's Advocate:

Designers/Themers also put in a lot of work, due to the overly complexity of Drupal and it's modules. Developers build the code usually from scratch with a blank template (Usually their Big Brains) which is complex, but also fresh, new, and cleaner to code. A true designer (not a shoddy "Theme changer") has to go over a vast amount of code that the combined developers created and find ways to tweak, twist, and manipulate to get the cherry on top.

Out of the Devil's Advocate:

Now I do agree with you Developers are the backbone of Drupal (Always has been, and Always will be) and yes they can build great sites, but even great sites need a decent design (Not to complex, but at least decent).

So in conclusion, even thought Developers and designers don't see eye to eye - the reality is that we do truly need each other, if we are to succeed on our journey.

(I have experience in both worlds, Drupal and Wordpress / One is truly ruled by hardcore Developers, and the other is ruled by Decent Designers w/Basic PHP knowledge (Wordpress does have a ton of developers, however the coding and "Modules" are no where near as complex as Drupal).

I take my leave for now, and I hope all of you find a truce and begin to work towards the future cause development and design can truly work and propel Drupal to new heights.

Thanks,

Tone

You're right on, web development and web design are totally different ends of the spectrum. They're related, but developers definitely have more control in the relationship. Design is often an aesthetic issue, or has to do with usability. This contribution often comes as an after thought to the functionality. Most of the web designers I know make poor developers and vice versa. Creating a 'team' environment where there's no clear cost/benefits is going to be hard.

Nice article here. I hope I don't have the wrong idea of what you mean by "designer" here. To answer your question, the best way to bridge the gap (or end friction) is to not worry about 3rd party designers and become the designer yourself. Train your eye and brain, and you won't regret it! If they still want features and whatnot, perhaps they should learn to code :)

You can learn pretty much all that Drupal/modern design is, in about 5 weeks. This won't make you a master at typography, color, space, and layout, but you will be able to "see the light" and be VERY VERY far ahead in the game. In theory, code that obeys common design principals would make the human designer [almost] obsolete. Here are my thoughts about design and how it's completely feasible for anyone to master in a very short time.

Week 1 - 2D Design - Read about this if nothing else. This will teach you the core 10-20 principals of design, layout, and hierarchy, and how/when to use them. These are very simple concepts, but they are not obvious at the same time. Really worth it to check out if you're serious about learning.

Week 2 - Color - The proper choosing, use, and effects of color. There are a number of relations you should understand. There are also a number of effects certain colors have when used together, or on people (psychology). There isn't too much to learn here when compared to 2D.

Week 3 - Typography - The proper use of type/fonts. There is much more to this than you might assume, although most of it isn't too important or relevant. You don't need to understand how to make a font, but you do need to understand when and where to use certain fonts. Even less to learn here.

Week 4 - Adobe Illustrator - When you want to learn to make the eye candy you see on most modern stuff, Illustrator is the way to go. All you need to do is figure out how to use layers, transparency, gradients, outer glows, clipping masks, and the pen tools. Photoshop is mostly for importing stuff you make in other programs, and adding effects to it. Start with Illustrator and NOT Photoshop if you want to gain some really useful graphic design knowledge. If you insist on Photoshop, make the basic graphics first with Illustrator and then import them to add effects or whatever.

Week 5 - Final Practice - Practice making webpage layouts/comps in Illustrator by using proper focal point hierarchy, space divisions, color schemes, and fonts. Look around at top websites/publications and pay attention to their data, color, and visual focal hierarchies. Try to understand why they do things in terms of the principals of 2D design, color, and typography, as well as the importance of displayed data. When you understand the link, and can manipulate stuff based on these principals, you are a "designer" and can officially call yourself that.

There ya go! It's really easy to learn and will make your work much cleaner and consistent in the end. I hope this helps to end "friction" between mindsets.

PS. I studied design at Penn College and it was a total waste of time. I'm aware of what you do in college so no flaming please :)

Love, Dhaupin

VIEWS IS AWESOME!!!!!!!!!!!!!!!!

I love how you can create so much using just views. People have created so many other modules for stuff that views can do (better). This will junk up a Drupal install in no time.... Perhaps they don't understand the power of views and its plugins?

Thanks!

All developers end up doing some design, and all designers end up doing some development. Any designer that can't do CSS/HTML isn't a designer... they are a graphic artist.

Given that reality, the tools we have (which make it super easy to override the default themes) are such that anyone with CSS/HTML and some basic common sense can make Views look any way they want. Sure, there may be a bit of a learning curve, but its MUCH shorter than trying to write the code to mimic views. Even if Views only gets you 90% of the way there... thats still pretty awesome.

Drupal is great because its powerful, stable and flexible. The trade-off is that it requires more effort to understand HOW it can change, and then finding the best way to do so. If someone wants to design for Drupal, then they need to learn how it works. Period.

They don't have to learn how to speak "fluent" PHP/SQL... but they should know the basics. Any template engine will require SOME code to put the output in the right places.

I think one of the problems is that designers often want the system to mold to their vision rather than their vision molding to the system (not just Drupal, but servers, browsers, connections, computers, etc.). Thats arrogant... you can paint a car, but if you want it to look and work completely different... then you are gonna have to work.

I have often seen designers/customers so tied to a concept that they don't care if its going to not work for most users or be expensive (in cost and resources). To be fair, developers fall into this trap too - but the community will reject poorly written code.

Regardless, Views is amazing and anyone who wants to replicate the results by hand are welcome to try...

Bottom line - anything is possible if you have the time and money. And if you don't have the time or money, then come up with a different solution.

ron

However it is important to note that there is a distinction between the artistic designers (those that develop graphical facades) and UI designers (those that ensure ease of use). Sure you can avoid using one or both but beware; Crappy usability will ensure that less people use it. Your modules are top notch in my books however I do sometimes think that a few things could be better presented in order to drill through the hardened skull of the lazy user (if you want to) and give them a eureka moment.

As Steve Krug (one of the pre-eminent experts on UI) says: "If it is hard to use, people will simply use it less."

If it works for you, great. You are a smart guy (prob top 0.1% is my guess) however if you release something you may want to ensure that it is usable by the "lower" (won't say lowest) denominator. Or you can campaign the heck out of it and make them smarten up! Ha ha ha.

At any rate, great work...

Cheers, Derek

Look around you. I would say just about everything you see has been touched by the hands of a designer and an engineer. I think there is a big disconnect with coding because it is language, but to get it into real life you'll need both.

You know what's hilarious to me about this post and the comments at top/bottom I got to? A huge chunk of the *design* community evidently feels that HTML and CSS are the prerogative of *developers* and resent the implication that they, as web designers, aren't good web designers if they don't know and care deeply about HTML/CSS.

And here ya'll are saying that theming, with HTML/CSS, and semantic HTML are the province of *designers*. I'm giggling. I consider myself a designer, but other designers don't always agree with my self-image because I focus on the function and care about the medium we work with to present sites on the web (HTML/CSS). Basically, I get looked at as too nerdy for design because some designers don't agree with too much focus on code. Caring about "technical" rigor in any way restricts creativity, I guess. Forget the need for a solid technical foundation for a product in a technical medium. That's just thinking inside the box.

But I sure as heck don't need a developer to make things function. I do it myself. I taught it to myself for that reason; I don't like relying on others. But I'm aware of the limitations of my skills in that area and if I were ever to put together a huge development project like a CMS I wouldn't want to depend entirely on my own abilities in either "design" or "development."

Anyway, I agree with Ron. There is not a hard and fast distinction here. And OUR perception as individuals that there IS one causes more friction. The question isn't, are you a designer or a developer?, but what are your strongest skills?

I personally have never contributed to open source projects for the reason that I don't feel my coding skills are to be relied upon in such a large project. Plus, when you do a module it's sort of your pet after that and everyone wants you to take care of it and not throw it out of the house when it gets inconvenient. I'd feel pretty sorry for anyone who used a module of mine.

Yeah, which reminds me, I don't think it's so much (as someone or the other said) that *designer* oriented documentation is needed. Just, uh, better documentation. Technical writing is its own specialty. Communicating in the form of a tutorial, too. I've noticed that a lot of developers aren't good at expressing themselves with clarity (about their code), nor are many I've met very enthusiastic about documentation at all. I mean, enthusiastic about complaining about not having it or having to do it, but not really big on documentation in a helpful way. And, even when someone *is* determined and communicative, it's hard to take yourself so completely out of a development project as is necessary to be able to explain it to someone who *really* has to learn it from scratch.

Anyway again, with Views I see where you are going with most of those divs. But it's just too much for my taste. I'd keep it simple and build up based on essentials. But it's not really that bad, just kind of...well, generic. But, that's theming for you; have you seen the code jQuery UI does (it's gotten better, granted, but still)?? For my project, I installed Semantic Views and that, combined with a few tweaks of the template files to strip out divs, makes the Views HTML just about perfect for me. But Views has been so essential to me (I don't see how anyone really uses drupal without it after using it) and the code is valid if not beautiful...and looking at it suggests a valid reasoning for doing things the way they're done.