![Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]](../sites/all/themes/drupal4hu/images/bg-center/bg-center_4.png)
The biggest problem with the Drupal 7 usability process is communication. To quote Bojhan "I think its essential to recognize that with how the feedback process was handled during D7UX, we demotivated a crucial group: our core developers". Indeed. Lost in the several hundreds of comments in this or that d7ux.org blog post and getting no feedback which we were used to in the issue queue caused a lot of people to throw up hands and walk.
Again in Bojhan's blog post "in most discussions, developers assume that design proposals are ill-informed…" to which Eaton answers in the comments "and designers, in most discussions, assume that developers are visually illiterate and uneducated about UX matters".
All we people who want one thing, a better Drupal, are pretty much in two camps with very few people being in both of them and looking at the other side with a suspicious eye, taking every comment, taking every failure in communication as an insult. We need to learn each other's culture and work together. A dream? Maybe. Having an ambassador between these two camps would certainly help. We could call this person a Usability Lead for example. Not that this is the first time this issue was raised. Half-jokingly, we named a Drupal Usability Grand Poobah before and Crell called for such a person and a HIG too.
Let me take a a personal example which has haunted me for months and only Crell has shed light on it when I showed him an earlier draft of this post (which bore no resemblance to this version): I have opened an issue complaining about what Structure contained. I felt I was reasoning in the issue and Leisa was pretty much telling me to get lost. This is not true. Leisa was saying "benchmarks?" in her own way which I did not comprehend at the time.
We developers, and I in the forefront, who pretty much built the sand castle (yes it can be gone in the wind like that) should embrace designers and in case of a communication breakdown we should indeed post just that: "I do not understand what you are saying. I was reasoning but what you are saying does not sound reasonable to me, can you elaborate a bit?". It requires a lot of patience but it is the road forward.
Commenting on this Story is closed.
To be honest, I think a middleman is the wrong path.
This problem seems to extend far beyond our little sphere of drupalisms vs design ideals (except in large agencies that primarily rely on flash).
Perhaps its that designers do not understands the materials we are constrained with, and we do not understand or appreciate the coherent forms they want to create. Designers and developers are equally bullheaded most of the time -- we usually have goals that are fundamentally opposed -- we all know the fancier the design, the harder it is to build, and maintain.
Personally, I think the real problem is that there are designers that don't know how to develop, and developers who don't know how to design.
Personally, i don't think either should be allowed to exist a perfect world (excluding programmers who do work that users never interact with).
This is not to say I believe that designers need to know how to build the website they design, or that developer needs to know the full reasoning, tradition, and theory behind designs (by all means, designers who actually provide that are worthy of great respect -- but must just color in between the lines in my experience -- and wear pointy shoes, and tiny glasses with no prescriptions), but that both sides need to at least understand where each other is coming from.
I honestly do have prejudices -- but its mostly just all the hack designers i've worked with where even as a layman (who was taught by Mark Boulton's posts) i could see that they were quacks coloring the color book. I loathe designers who don't consider the costs vs. benefits. At the same time, I will slaughter 500 goats in honor of the designer who actually gives me style guide!
Prejudice aside, Leisa and Mark (he actually introduced me to the theory behind design), and the designers involved in Drupal 7 are incredible people, and they have my full support. Their videos of using drupal made giggle (and were deeply critical, but they were so cute, and right!)
Again, we don't need middlemen -- we need all need to grow. In this perfect world inside my head course. :-D
As my example have shown -- and there are many more -- sometimes there is a complete breakdown in communications because we simply do not understand what each other is saying. In these cases someone who speaks the language of both camps could smooth out the problem like Crell did for me. yoroy's comment certainly agrees with this: "it's not that we don't try to communicate, it's that we don't really have a shared vocabulary for this subject matter yet."
I had a similar experience with parts of D7UX, and I'm one of the UX guys in Drupal… During the ux sprint in Utrecht last june, it took us (Mark, Leisa, Dries, Bojhan and me) two full days of talking, face to face, to finally come to an understanding of the big picture of the D7UX proposals as a whole. It started to make sense, and I was then able to make this movie explaining it a bit more. I was reallly happy I finally could make that explanation. I was really sad it had taken us so long to get there. If even the subject matter experts needed that much time to get to an understanding, how could we expect the community at large to grasp it and get behind it?
There has been a whole lot of communication going on. Talking with people in Paris showed me it's not that we don't try to communicate, it's that we don't really have a shared vocabulary for this subject matter yet. The benchmarks <> usability testing anectdote is a perfect example of this.
Another big take-away from Paris is that *everyone* has a hard time handling the discussion around big vision, broadly scoped topics. We'll want to build new or improve existing tools and processes to handle the big-picture discussion and direction. Looking forward to continued talking and building with you all.
I couldn't agree more here with regards to the difficulties of communicating. I'm really sorry you felt that I was telling you to 'get lost' in that Structure issue as it was definitely not my intention - what I was really trying to say (and perhaps I'll do a better job this time) is that it is incredibly difficult for us to find a way to negotiate the design between the opinions of important people within the Drupal community, like yourself, and the needs of all the others who aren't represented at all, so we were doing lots of testing of these unrepresented people outside of the community to try to bring some balance and objectivity into the discussion.
I have a feeling that was probably not much of a better explanation than my first attempt, sorry!
This was a pretty complex project and, as it happened, Mark & I probably spent about 80% or more of our time trying to communicate what we were working on and less than 20% actually doing design work. And still, not enough!
I've previously said that I think Drupal needs a design community leader and the main reason for this I think is that there is a *lot* of work that needs to go into trying to get these communication channels working more effectively, and to continue this communication effort. A resource dedicated to this cause could probably achieve a lot for Drupal.
Personally I don't think this is a developer vs designer thing, although I agree that the lack of a shared vocabulary is a big problem and the lack of exposure to the way designers work within the Drupal community is also a challenge. I actually think that the biggest issue in the D7 Usability project is that we were pulling in different directons, and actually the framework v product discussion is the root of the challenges we face, but that's probably a whole other post.
Thanks for sharing your perspective.
eh, sorry, I didn't mean that to be an anonymous comment. It's me, Leisa ^
The problem is one of assumptions.
Designing a user interface involves assumptions about your user base.
A framework can not comfortably make any assumptions, as it has no way of knowing what will be built with it.
Assumptions about the user base of Drupal the product needs to be made in the 'product space', but we don't have a clear separation of the framework space and product space in drupal at the moment.
One thing we discussed on this with several people in Paris is that the d7ux process used "trending" in a lot of cases, instead of replying to individual comments one by one as one is used to in issue queues. Or wait, maybe that is not that universal in issue queues either. Dries does a similar trending (in my eyes that is), where he just comes in an issue and states an overall feeling instead of delving into individual items in many cases. The difference is that we except and understand this from Dries (hey, he managed to get to the issue to reply at all :) while the same was not acceptable for many from the "Drupal newbs" in the d7ux process. There was some authority exercised, while the regular "everyone is equal" environment was expected. From what I've seen in the issue queues, we usually accept (and I dare to say even welcome) trending summaries from "trusted domain experts", because it helps us skip the hundred comments that were before (see also below), but maybe Mark and Leisa did not manage to achieve that "trusted domain expert" mark in many eyes.
In a highly related note, I'd like to strongly echo yoroy's point on the issue queue not being useful for big picture discussions. I've heard this in relation to this "designer vs developer" divide several times, and seen Drupal 4 Designers emerge as a separate site "because drupal.org is built for developers". The reality IMHO is that drupal.org tools are not suited well at all for the big picture discussions for developers either. An amazing number of discussions are lost inbetween separated issues and groups.drupal.org summary posts which went nowhere due to lacking more over-arching tools. I'm equally frustrated to read up on a hundred comment thread, let alone reply to each one of them one by one in a heated or just plain big picture debate. It's not a developers vs. designers issue, it is a "we grown too big and did not grow our tools with it" issue. Unfortunately the drupal.org redesign plans do not seem to be offering any solutions for these process issues either. If the separate tools for designers do emerge to be good, that at least will have some lessons on how to improve drupal.org, because it is in need of serious improvements to accommodate the developer processes too.
Unfortunately the drupal.org redesign plans do not seem to be offering any solutions for these process issues either.
it's worth noting that, to the best of my knowledge, addressing this very important issue did not form part of the drupal.org redesign brief (at least, certainly not the brief that Mark & I received).
It would be a wicked design project though.... I agree that the tools are definitely not helping our situation at the moment.
Yeah, I'd consider it a major problem that we did not even manage to launch the drupal.org redesign (although the plans were finished almost a year ago). And to a non-insider ear, the latest Lullabot podcast might make it sound like it was due to Mark or Leisa, while it is 100% due to the volunteers around drupal.org (including me). A bigger problem is that by the time we launch that redesign (hopefully sometime in 2011), we deliver solutions for 2008's problems and goals. Issues like improvements needed in the development process will not even have solutions planned, let alone any implementation.
(Anyway, this is going offtopic here - except maybe to underline again, that developers are frustrated with the tools at hand just like designers are).
I'm a staunch supporter (perhaps should be more loud) of where we have ended up. In some ways I think its silly that we are debugging the process, as such a small percentage of our real user base has even gotten the first whiff of it -- just today, a coworker who works on drupal sites 40 hours a week asked me "how's drupal 7 coming along". The verdict that matters is still months away in my mind regardless.
Gábor touches on a point though: our collaboration tools suck. I believe issue wikis would be a good first step. Among the biggest issues is simply that that a comment thread is a really bad way to organize input from hundreds of people.
I think allowing people to give something as simple as a "thumbs up" to insightful comments in issue threads would go a long way. I'd complain about having a seperate d7ux website, if it weren't for the fact that i could see our tools getting in the way of Mark, and Leisa. As far as Drupal groups, I sort of feel like its role should be limited to local organizing -- though i'll point out that our Austin group seems to use facebook, not groups.drupal.org even for that.
Then there's the roadmap thing. Lawl.
Finally, and i'm just throwing this idea out: creating a position for a design/usability maintainer in the same spirit that we have webchick primarily overseeing d7 code. If we're serious about having a leader, this leader will need teeth, and authority. This is just my opinion of course.
I too foam at the mouth for a big picture solution. Solving one problem in the issue que can be a full time job. From what I've seen of GoogleWave, I'm hopeful it will be a solution. No idea when it'll be out though, and we kind of need something soon.
Re: lack of communication... I personally think there was quite a bit of communication, but it lacked real metrics. For example, we heard a lot about test results - but I for one never saw test results. Previous usability tests show that if there's proof, the community will rise to a solution. In this case, results were only mentioned vs shown.
"It requires a lot of patience but it is the road forward." Yay chx! I'm so glad you feel this way!
joshmiller
The subject of designer/developer communication has actually been on my radar since Steven Wittens wrote Drupal's Designer Future, but the “Design for Drupal” movement I envisioned didn’t fully coalesce until Drupalcon DC. Before that time I was working on creating a comfortable space for designers with better documentation, etc to explain the Drupal theming system to designers. But for the past year, I’ve also been actively trying to bridge the gap between the designers and the developers in the Drupal community. Because it was apparent, even before designers found their voice at Drupalcon DC, that developers and designers didn't think about things in the same way. Both sides were accidentally pressing each others buttons.
Do we need official Designer/Developer Ambassadors? Whether there is an official or unofficial position, the most important thing is for everyone in the community to learn that this is simply a communication issue. Its not a clash of cultures; its that these two parts of our Drupal community lack a shared vocabulary. And I'll continue to try teach each side about the other's point of view and to facilitate discussions. I invite anyone to watch the first half of my Drupalcon Paris presentation on this very subject.
As web applications need to incorporate more and diverse knowledge bases, its important that we learn to communicate with the experts in those fields that join the Drupal community.
I think the core of the problem is that a designer's task is open-ended, whereas a developer's task is just to "make it work." That is, someone writing code has three goals: make it as simple as possible, as fast as possible, and make it work. "Simple" in code is a relatively straightforward consideration; speed can be measured quantitatively with benchmarks; and it either works or it doesn't. Designers' tasks have a lot more ambiguity, which makes it harder to please a majority, which in turn leads to a restriction of the audience. (Sometimes I feel like the new Drupal toolbar should have a little button that switches Drupal between "simple" and "advanced" configuration mode so Drupal's interface can be applicable to a larger audience.) This restriction in audience makes people on either end of the spectrum -- in this case, the people writing the code to implement the designs -- to feel alienated, which reduces motivation.
If UI development is going to move forward in Drupal, it needs to be in such a way that the people who implement the designs feel that the design is relevant to them.
If UI development is going to move forward in Drupal, it needs to be in such a way that the people who implement the designs feel that the design is relevant to them.
and this is the massive challenge that we face if we're going to pursue the 'product' goal within the larger Drupal project. If you followed the strategy behind the D7UX designs then it is entirely clear why the interface doesn't necessarily gel well with many of the experienced Drupal developers - because it wasn't designed with them in mind as the primary audience.
As long as the UI of Drupal *does* support the developers as the primary audience we'll fail in the goal of making Drupal a better product for people who use Drupal as a tool to publish content (as opposed to creating new functionality etc.).
So, as I've noted above, it comes back again to the framework vs product discussion - I really think that is at the root of many of the problems we've encountered with the D7 design work.
early on I got so tired of being told I didn't understand, I stopped trying to even bother contributing and took a vacation.
sepeck
http://www.blkmtn.org