Why is Drupal is a Good Choice for a Community Website?

5 May 2010 - 2:19am
4 years ago
15 replies
2439 reads
jewel
2010

Hi-

First off, I WANT to like Drupal and I WANT to not cringe every time I'm brought onto a project where the development team is using Drupal and we're not allowed to make a user-friendly site "in scope."

It didn't help that when I logged into the new IxDA site, I saw that it was using Drupal- all to apparent by the horrifically confusing and non-intuitive user profile forms, "tabs", misplaced filters and rude system messages. I certainly don't blame IxDA. What I can't understand and I'd LOVE your input on, is why an organization focused on interaction design would pick a technology that is apparently NOT focused on actual people being able to use or interact with it?

Now, I understand that I may simply have been pulled into projects that are being poorly managed, or working with a team of developers focused purely on cranking out functionality with no care to the end client or general audience. But my gut is that there really are limitations to this system- that's it's meant to be a content management system (where your users logging in are administering the site) and not an interactive website platform.

That said, can you help me learn to understand its parameters? Have you been able to make a Drupal site usable? Are you able to work in an agile fashion or at least accommodate follow-up releases after a launch? Muchas gracias to any tips and magical insights.

-jewel

Comments

5 May 2010 - 3:59am
thepofo
2010

Hi,

I believe Drupal is a super product and with the large community supporting it, it has climbed to its success. However, the default Drupal project templates are not very user friendly, but you can create your own theme files allowing you to build very advanced websites, some examples like VT4.be or transportplaza.eu (both projects where I was the PM) have a lot of community features build in allowing interaction from the user.

Working in a Agile fashion is only focus on specific at the moment and releasing it after a sprint or iteration, something you can easily do with Drupal as well.

 -Eric

5 May 2010 - 7:20pm
zakiwarfel
2004

Providing a blanket statement like this without specifying why isn't that valuable. How about answering the questions of why and how is Drupal a super product? What makes it super?
On May 5, 2010, at 7:16 AM, thepofo wrote:

I believe Drupal is a super product and with the large community supporting it, it has climbed to its success.


5 May 2010 - 8:10am
David Lambert
2009

I'd recommend that you try to separate the technical architecture parts of this decision from the usability parts of the decision.  I think that the statement you made about "not [being] allowed" to make changes says volumes all by itself.


I'm a technical person, not a usability expert by training.  I can assure you that Drupal has a lot to offer in terms of out-of-the box capabilities, extensibility and easy access to additional functionality via a rich developer community.  These are good things.  They mean that the technical team should have to spend less time building plumbing and can spend more time on interior design, to butcher a metaphor.


There's nothing in Drupal that cannot be customized, and very little that can't be customized easily.  Having said that, it might be helpful to know some of the specific things you're trying to change that you've been told cannot be changed.  If these issues have merely been a question of budget, then I'm afraid your argument is with the people making the business decisions to build functionality without the level of design that you feel is appropriate, isn't it?


As far as the IxDA site goes, I'm really not sure what specific grievances you've got, but I'd encourage you to reach out to the team who's been spending time working on this site and offer your help.  The http://www.ixda.org/about/site page lists a number of people who were involved in building this site, and I'm sure they'd welcome qualified, collaborative help in making improvements going forward.


-David


On Wed, May 5, 2010 at 6:26 AM, jewel <jewel.m@gmail.com> wrote:

Hi-

First off, I WANT to like Drupal and I WANT to not cringe every time I'm brought onto a project where the development team is using Drupal and we're not allowed to make a user-friendly site "in scope."

It didn't help that when I logged into the new IxDA site, I saw that it was using Drupal- all to apparent by the horrifically confusing and non-intuitive user profile forms, "tabs", misplaced filters and rude system messages. I certainly don't blame IxDA. What I can't understand and I'd LOVE your input on, is why an organization focused on interaction design would pick a technology that is apparently NOT focused on actual people being able to use or interact with it?

Now, I understand that I may simply have been pulled into projects that are being poorly managed, or working with a team of developers focused purely on cranking out functionality with no care to the end client or general audience. But my gut is that there really are limitations to this system- that's it's meant to be a content management system (where your users logging in are administering the site) and not an interactive website platform.

That said, can you help me learn to understand its parameters? Have you been able to make a Drupal site usable? Are you able to work in an agile fashion or at least accommodate follow-up releases after a launch? Muchas gracias to any tips and magical insights.

-jewel

(((Please l
5 May 2010 - 12:32pm
Julie Blitzer
2009

p { margin: 0; }At least 2/3 of my job is doing UX for a Drupal-only web development firm, so I'm pretty familiar here (but will admit I may be less of a usability expert than some of the others on the IXDA list).

I'd love to hear what kinds of obstacles and criticisms others in IXDA have about Drupal. If we get enough of a debate going, I'd be happy to put time into writing a blog post about it some time soon.

Those who mentioned the Drupal themes are correct. It is incredibly customizable, both on the front-end (public-facing) and back-end/admin side of things. You can build your own front-end themes using CSS/XHTML that are almost completely custom. There are also many back-end administrative themes you can install. (Or you could even create your own but our clients never ask for it.) The default back-end admin theme in Drupal 6, called Zen, is not so great from a usability perspective. I typically push clients to use RootCandy instead: http://drupal.org/project/rootcandy. That said, Drupal 7 is leaps and bounds better on the admin side of things after a large commitment to UX and contracting a team to do the work. And yes, many of the error messages are customizable. And if the site is QA-ed extensively, the user should never see the technical errors. (An admin user may see notices asking for an upgrade, but that's different.) You can customize the forms and layouts as well.

Brian is right when he says there isn't a "perfect" CMS out there, but Drupal is the closest option to it around in that is the most robust, scalable and has an unbelievably large development community that is very enthusiastic and committed to its success. It may not be entirely custom/from scratch, but I've only seen a handful of business requirements in my two years with Drupal that we couldn't do at all. And it has many benefits in that it is open source and the clients aren't stuck with one vendor as there are so many firms and developers around.

The problems with Drupal often arise when developers who don't know the system well "hack" the core modules and functionality. If you do a Drupal project and have influence over what devs to hire, never ever EVER just hire a PHP shop or dev who has never done a Drupal site or hasn't done a Drupal site since version 4 or even 5. Very bad idea.

As with any CMS or web project, a good chunk of the success comes down to hiring the right people to do the development.

Eric is right in that many high profile sites are running Drupal, especially for community projects. I actually just did UX for a community site that is launching any day now, and I'm pretty sure 95% of the functionality needs were met without custom modules. Once the site launches I can show you what the other 5% was.

I'd encourage anyone with UX concerns and an upcoming Drupal project to take a look at http://www.d7ux.org/project-framework/

I should also note that Drupal 7 is in Beta and not exactly production ready, but should be by September at the latest.

Jewel-

What do you want your community site to do? What does the budget for the project look like? If you provide a list of some key functionality I can answer what is and isn't possible in Drupal pretty quickly.

Julie Blitzer

Strategist
Advomatic


From: "David Lambert" <dlambert@appdev.info>
To: blitzer@advomatic.com
Sent: Wednesday, May 5, 2010 10:57:28 AM
Subject: Re: [IxDA] Why is Drupal is a Good Choice for a Community Website?

I'd recommend that you try to separate the technical architecture parts of  
this decision from the usability parts of the decision.  I think that the  
statement you made about "not [being] allowed" to make changes says volumes  
all by itself.

I'm a technical person, not a usability expert by training.  I can assure  
you that Drupal has a lot to offer in terms of out-of-the box capabilities,  
extensibility and easy access to additional functionality via a rich  
developer community.  These are good things.  They mean that the technical  
team should have to spend less time building plumbing and can spend more  
time on interior design, to butcher a metaphor. There's nothing in Drupal  
that cannot be customized, and very little that can't be customized easily.  
 Having said that, it might be helpful to know some of the specific things  
you're trying to change that you've been told cannot be changed.  If these  
issues have merely been a question of budget, then I'm afraid your argument  
is with the people making the business decisions to build functionality  
without the level of design that you feel is appropriate, isn't it? As far as  
the IxDA site goes, I'm really not sure what specific grievances you've got,  
but I'd encourage you to reach out to the team who's been spending time  
working on this site and offer your help.  
 The http://www.ixda.org/about/site [1] page lists a number of people who  
were involved in building this site, and I'm sure they'd welcome qualified,  
collaborative help in making improvements going forward. -David On Wed, May  
5, 2010 at 6:26 AM, jewel <jewel.m@gmail.com [2]> wrote:
>Hi-
>
>First off, I WANT to like Drupal and I WANT to not cringe every time I'm  
>brought onto a project where the development team is using Drupal and we're  
>not allowed to make a user-friendly site "in scope."
>
>It didn't help that when I logged into the new IxDA site, I saw that it was  
>using Drupal- all to apparent by the horrifically confusing and  
>non-intuitive user profile forms, "tabs", misplaced filters and rude system  
>messages. I certainly don't blame IxDA. What I can't understand and I'd LOVE  
>your input on, is why an organization focused on interaction design would  
>pick a technology that is apparently NOT focused on actual people being able  
>to use or interact with it?
>
>Now, I understand that I may simply have been pulled into projects that are  
>being poorly managed, or working with a team of developers focused purely on  
>cranking out functionality with no care to the end client or general  
>audience. But my gut is that there really are limitations to this system-  
>that's it's meant to be a content management system (where your users  
>logging in are administering the site) and not an interactive website  
>platform.
>
>That said, can you help me learn to understand its parameters? Have you  
>been able to make a Drupal site usable? Are you able to work in an agile  
>fashion or at least accommodate follow-up releases after a launch? Muchas  
>gracias to any tips and magical insights.
>
>-jewel
>
>(((Please l
>

5 May 2010 - 8:21am
socialtechno
2010

Well said David. Drupal is good precisely because it separates the user experience and the presentation layer from the functionality, using what Drupal calls "themes".  There are hundreds of open source themes available and you can build your own. However, if nobody on the project team is an advocate for good interface design, you could end up with something that  sucks. That's not really a Drupal issue, it's an IT issue. Techies don't understand design aesthetics.

If you'ld like to talk to someone who understands Drupal and high quality usability, I recommend Hans Idink - hidink@orgis.nl

5 May 2010 - 8:45am
cflory
2009

Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4

Drupal is a very powerful system that lets you build web sites that can be tuned to any designers vision. All systems have boundaries. Some small some wide. Drupals fuzzy boundaries are drawn by a very wide radius.

However to get the most of Drupal you need two groups to work collaboratively .

a. A Good architect / designer to provide the vision, visuals and values for the site

b. A Good technologist to express that vision without compromise

There are no FREE rides when building great products, sites, buildings, cathedrals …

If you just want to add an extension to your house Drupal is not for you

If you just want to renovate your kitchen Drupal is not for you

But If you want to build a multi room , multi floor Mansion or an 80 story Condo+ Hotel + Mall complex or a Cathedral then Drupal is a great choice

If you want to build a comprehensive site to house 20K + members of a community and build a wide array of functionality and features to support that community then Drupal is definitely the right tool for the job

So lets get the architects / designers and the technologist working together to get on with the task of making this a great site for the community . Im sure we are seeing only the first floor of a multi storey complex

 

 

5 May 2010 - 9:27am
regiskuckaertz
2009

In terms of user experience, Drupal is likely to get a real boost thanks to all the work Mark Boulton Design and Leisa Reichelt have done with the Drupal community. You can follow the process here: http://www.d7ux.org/

They also have an ongoing project which is to create an admin theme for Drupal 6 that is actually more goal-focused. There hasn't been much progress so far though: http://projectverity.com/

But even if it currently sucks in many ways, the effort you put in learning it inside out may really pay off. Sites like mtv.co.uk, london.co.uk, whitehouse.gov and many others are there to prove it -- as does ixda.org of course :-)

5 May 2010 - 1:19pm
dsblanes
2010

To me It sounds like you were pullled into projects that were poorly managed from the head up. Drupal is a very extensive open source framework that can get complicated because there are so many ways to accomplish one task. Just to frame the complexity, there are over 4500 modules published for Drupal 6. Some of these modules do not interact well with others. Each project outside of the scope of UX should have a skilled Drupal Architect to determine what modules will work with the requirements from the get go.

With that said, the parameters of Drupal are close to limitless and you can accommodate follow-up releases after a launch. All of the sites that I have built in Drupal have been living organisms since inception. You can always revisit usability issues after the launch and make appropriate changes.

I am a Drupal Developer, I hope this information is helpful.

Daniel

5 May 2010 - 2:08pm
jewel
2010

Thank you to everyone! Your comments already have me re-thinking my concerns and I look forward to diving into your comments and suggestions. 

-jewel

7 May 2010 - 11:19am
Lisa Rex
2009

I'm a Drupaler *and* UXer. The two can co-exist.

The truth is that most sites have a wide range of features on a limited budget only because they are using pre-built pieces (modules). Sometimes these pieces aren't completely usable in all cases. For example, on another site I'm working on, the default call to action "Create an account" became "Sign up for camp"... much more friendly!

Someone famous said "Quality is an iterative process." I'm 99% sure that applies here. :)

And if you wanted to take it further, a lot of Drupal module maintainers (again, all volunteers) would welcome the chance to work with a good UXer to improve the UI/usability. They want people to use and love their module.

6 May 2010 - 10:30am
Michael Haggerty
2010

Going back to some of the original questions -

Drupal is the clay you use to sculpt a site. Whether or not the out-of- the-box tools are usable is almost meaningless, it's what you do with
them that matters.

People choose Drupal for a variety of reasons, and my company has done
a fair amount of research on the question of why people choose it. We
work with non-profits, academic institutions and socially responsible
businesses and put out a survey to over 200 past clients asking why
they chose to go with Drupal. About 67% of people responded, and here
is some data you might want to think about:

  • There is a high degree of loyalty to the platform. ~63% said they
    had used Drupal before on other projects, and about 40% said they
    never considered using another platform for projects we worked on.

  • People identify with the community. ~72% of respondents said they
    respected the open source principles behind the platform. ~30% of
    respondents said the size of the community influenced their decision,
    they believe the project will not suddenly go away.

  • People like the breadth of features. We asked people to pick three
    characteristics that appealed to them about the platform. The top
    three answers were the abundance of features, the ability to add new
    features without needing to recode an entire site, and the ability to
    handle user generated content.

  • When asked about how they use Drupal, the top three answers we got
    were to host their main organizational web site or intranet, to host
    video / images / other collateral, and to interact with their CRM
    system or a social network.

Now, the point of this data is not to make the argument for why to use
it as a creative platform, it's to explain why people choose it in the
first place. These results are kind of biased, I run a Drupal shop and
there is an echo chamber effect at work here. What I see when I read
these items is that people like Drupal because it works with other
systems, you can support it over time (and avoid the costs of moving
to another platform), and people identify with the community and
principles behind it. In other words, the choice is not about how it
works for a single project, but about how it fares in the long run.

It seems to me, from a usability perspective, it's important to
understand this logic. If people are concerned with how a project is
going to survive, the community behind it, and how well it plays with
other systems, this should be a consideration when delivering a tool
we say is 'usable.' Maintainability is a driver in how people perceive
a product.

Best Regards, Michael Haggerty

Michael Haggerty | CEO, Chief Internet Strategist | Trellon, LLC

web www.trellon.com | email mhaggerty@trellon.com tel 240 643 6561 | aim haggerty321

On May 5, 2010, at 6:28 AM, jewel wrote:

>

6 May 2010 - 2:41pm
jewel
2010

Thanks, Michael.

I understand that Drupal as a product is well tended to and keeps improving over time. (It's hard NOT to be a fan of Open Source projects, living in Portland OR.) However, I have yet to have the pleasure of working with a Drupal team that can give me iterative enhancements over time. I continually get push-back that to make the most simple of usability enhancements is like pulling teeth from a toothless baby and that having a staging area apart from a production area for testing new features/builds after a public launch means near-impossible deployments.

My impression is that Drupalers love building new sites, but don't put much (if any) thought on how that site will be adopted by end-users and managers (if used at all) and evolve over time. You can't go to print with a website and call it good. Of course, that's a generalization- I'd love to change my impression.

I suppose this isn't a tech forum, though, simply an interaction design one. On that note, I'd love to encourage the Drupal community to start thinking about the people that will be using their systems. Both the end-user who visits the site and the people who will be managing the site. 3 areas that would make Drupal 70% more user-friendly out-of-the box: user profiles, emails & system messages. I should be able to manage ALL emails that the system sends from one central area. Any module that outputs error messages should plug into a central "messaging management" controller. I'd love the opportunity to "translate" core system messages into human-readable and maybe slanted packages: young & hip, staunchy & corporate, etc. Know where we'd go to start a usability revolution?

-jewel

7 May 2010 - 7:51am
Michael Haggerty
2010

Responses inline.

On May 6, 2010, at 5:28 PM, jewel wrote:

> Thanks, Michael. > > I understand that Drupal as a product is well tended to and keeps
> improving over time. (It's hard NOT to be a fan of Open Source
> projects, living in Portland OR.) However, I have yet to have the
> pleasure of working with a Drupal team that can give me iterative
> enhancements over time. I continually get push-back that to make the
> most simple of usability enhancements is like pulling teeth from a
> toothless baby and that having a staging area apart from a
> production area for testing new features/builds after a public
> launch means near-impossible deployments.

Maybe you want to give an example of what someone is pushing back on.
Something tells me there are other constraints affecting the situation
that you are not acknowledging, or you are working with illiterate
goofballs with no clue what they are doing.

> My impression is that Drupalers love building new sites, but don't
> put much (if any) thought on how that site will be adopted by end- > users and managers (if used at all) and evolve over time.

Despite the flowery language other people in this thread have used to
describe the life of a module contributor, most Drupal developers
could not care less how someone is going to receive their modules.
They are building tools that are going to be useful for the widest
number of people, from different cultures and backgrounds, who bring
expectations that are nearly impossible to predict. They would rather
someone tell them how to make it better than try to guess all the
opinions and attitudes end users bring to the platform.

Your question is about building sites tho, moreso than how Drupal
itself is built. There are really two things to consider here: how are
you expressing UX requirements and who are the people you are working
with?

At Trellon, we do some interesting things with requirements to
communicate tacit details related to usability. If messaging, emails,
etc are a big part of a project, we make sure we include a phase
devoted exclusively to that and budget time for it. We create a lot of
conceptual maps that explain messaging to developers in a way that
corresponds with how they would write code, things that communicate
details for when certain events will happen that can be understood by
a client. It's not optional and it's not something that is going to
fall off a schedule because a developer lacks a perspective on how the
site will be perceived.

A competent Drupal developer should be able to talk with you about how
a site will be maintained over time. They should have some perspective
into what it will take to maintain the site they are delivering.
Understand that there are a lot of people out there who call
themselves 'Drupal Ninjas' and engage in other forms of posturing
designed to create the impression in your mind that they are
competent. This is not always the case and you should remember to
apply scrutiny to what anyone tells you just as you would in any other
circumstance. Like, you should consider it a huge red flag if someone
tells you changing emails or messages in the system is a big deal. To
me, this would mean you are working with some dingbat hipster who
lacks any real understanding of how to work with Drupal and is only
making these claims to justify a higher hourly rate. I would tell this
person you lack faith in the soundness of their technical approach,
work to undermine that person's position in your organization and get
him or her replaced with someone who knows wtf they are doing.

> You can't go to print with a website and call it good. Of course,
> that's a generalization- I'd love to change my impression.

I have no clue what you mean here. What is this 'print' you speak of?

> I suppose this isn't a tech forum, though, simply an interaction
> design one. On that note, I'd love to encourage the Drupal community
> to start thinking about the people that will be using their systems.

I would love to travel through time, and think I have better prospects
of realizing my goal in the near term.

> Both the end-user who visits the site and the people who will be
> managing the site. 3 areas that would make Drupal 70% more user- > friendly out-of-the box: user profiles, emails & system messages.

All of these are things you can already configure through a web based
interface. What specifically are you proposing?

> I should be able to manage ALL emails that the system sends from one
> central area.

There already is a messaging module for Drupal that does this. In
fact, there are a number of modules that allow you to do this:

  • Mail Editor allows you to edit every email coming from your site in
    a single location.

  • HTML Mail module allows you to make sitewide changes to HTML
    templates.

  • Mime mail allows you to do other interesting things.

> Any module that outputs error messages should plug into a central
> "messaging management" controller.

Nah, that would be a terrible idea. I can see a lot of downsides to
that approach. Like, there need to be messages that go into a log,
there need to be messages that display on a screen, there need to be
messages of different priorities, etc. Having a controller for all of
them would be complete overkill, and overkill is not a 'usability
enhancement.'

> I'd love the opportunity to "translate" core system messages into
> human-readable and maybe slanted packages: young & hip, staunchy &
> corporate, etc.

The locale module allows you to do this already. All messages and text
contained in the interface can be easily modified through any of the
locale and internationalization functions that are part of the
platform. Again, the solution here is to work with the right
configuration to start with.

> Know where we'd go to start a usability revolution?

No, I don't.

Go to drupal.org and start reading about the platform. Once you have
taken some baby steps and have a working knowledge of what is out
there, find a usability challenge with the platform and work to
address it. It is clear you are identifying with challenges people
have already been working on, and would benefit from more knowledge of
what is actually out there.

Drupal developers generally respond to examples of excellence moreso
that respond to prodding. This is a 'show me' culture and you are not
going to make much progress without understanding the work others have
done in more detail.

In the meantime, I would try to buddy up with better Drupal
developers. The examples you cite are simple to deal with using tools
that provide web-based administrative interfaces. The fact that
someone has not brought this up with you in the past makes me cringe -
I mean, locale is part of core.

M

> -jewel > >

7 May 2010 - 7:47am
Bruce Shields
2009

I'd like to throw my two cents worth in as a student and newbie. A project group I was on tried to use Drupal for an advanced social computing design class and had to abandon it halfway through the class and switch to PHP. It would be easy to shake my head after that experienc and declare that Drupal is awful and just walk away. However, I can see the advantages of the system. There is a very large, dedicated community of developers who write lots of code to support the system.

After struggling with trying to learn the system on our own, here are the conclusions I would offer:

First, the documentation is really not helpful. The subject of views is a perfect example. Our group included two people with computer science degrees with hundreds of hours of reading documentation and problem solving under their belts. We went to the documentation site and found this:

"The Views module provides a flexible method for Drupal site designers to control how lists and tables of content (nodes in Views 1, almost anything in Views 2) are presented. Traditionally, Drupal has hard-coded most of this, particularly in how taxonomy and tracker lists are formatted."

If you are not already familiar with them, this description tells you nothing. There is no explanation of what a view is or how to generate pages using them. We didn't begin to understand until we talked to a fellow student with Drupal experience. He said:

"Think of Views as a search engine. It goes and finds your content and then displays it on a page."

That's short, concise, and to the point. Two sentences that got across the point that pages of documentation failed to make. I understand that open source = people doing the bits of the project that are fun and writing documentation is not nearly as sexy as writing code, but good documentation would go a long way toward helping new users.

Second, while Drupal is powerful, if you aren't a developer who is comfortable writing a new module, it can be a bit of a straight jacket for design. Specifically in our case, we were trying to create a non-standard view for photo galleries and came to the conclusion we couldn't do what we needed to do without writing a module. That was far too daunting of a task for us. It turned out to be much easier to write the whole site from scratch in a language none of us was familiar with than deal with module writing.

Third, for anyone with even a modicum of coding under their belt (a very small modicum in my case), Drupal is not intuitive at all. I've talked to experienced developers who said it took them a long time to figure out the views. Again, I think this goes back to the documentation I mentioned earlier.

Having said all of that, I can understand that if I have a client with fairly standard needs, i.e. someone who doesn't need a module written, Drupal would provide me with a way for creating a site very quickly. Furthermore, the backend admin section is prebuilt and I wouldn't have to code that, which would save a lot of time.

I also understand that open source projects are inherently limited by workers self-selecting their tasks and other looking on and saying "someone should.....". Perhaps if I end up working at a Drupal shop after graduation I'll volunteer to write some documentation.

7 May 2010 - 11:04am
TerraceMedia
2010

As a Joomla! web developer, I can't resist pointing out that there are several excellent suites, most well-documented and with multi-lingual support, for quick deployment of a social networking site which have written by the larger open source community of  Joomla! developers. You can see a few at http://extensions.joomla.org/extensions/communities-a-groupware.

Syndicate content Get the feed