Feb 24, 2015
I was recently talking with a friend about how hard it is to find a good Drupal developer. While Drupal is the second-most widely used CMS, finding developers who know how to work with it properly is really challenging. I think there are three reasons for this.
- Drupal is so ubiquitous that most PHP developers have had at least some level of exposure to it.
- You can get a lot done in Drupal without knowing what you are doing.
- Most of the people hiring Drupal developers are not able to evaluate the quality of the work.
In thinking about this, an analogy came to mind:
Drupal is to web development as Powerpoint is to design.
PowerPoint is everywhere. Anyone who knows a little bit of PowerPoint, and can search the web for images, can convince himself that he is an adequate designer (or at least a good visual communicator). But the more you care about design, the more horrifying these amateur presentations are. PowerPoint itself isn't bad. If you do have good design skills, PowerPoint can be an incredibly powerful design tool. But there are more bad designers working in PowerPoint than good designers.
Similarly, Drupal has a huge library of modules that you can install and configure about as quickly as you can drop an image onto a slide. An expert Drupal developer will know what modules to use, have good judgement of when to use them, and have a solid process for testing and managing configurations. A Drupal amateur is unaware when he is creating a mess that is going to create embarrassing situations in the future.
So how do you separate the wheat from the chaff in the Drupal developer ecosystem? I tend to focus on three areas:
- The types of sites the developer worked on. Wrong answer: "I build Drupal sites all the time."
- How the developer finds modules to use. Wrong answer: "I just search for them."
- How the developer manages configurations across environments. Wrong answer: "I just click boxes."
By asking these three questions, I can usually get an idea of expertise and craft that a Drupal developer applies to his work. Happy hunting!
May 06, 2013
Anthony Myers (@xanthonysfx) , from CMSWire, recently posted an article listing "Five Alternatives to Wordpress." His list was really interesting. First, he openly left off Drupal, putting Plone there instead. I really like Plone but I would have to say that Drupal is a much closer analog to the core functionality of Wordpress. The projects even have an ongoing rivalry with each other as shown by Dries's April Fools post "The Red Press of Drupal" where he announces that Wordpress is moving onto Drupal.
Second, the author didn't include blogging products like Expression Engine, MovableType (which, I hear, is improving), and SquareSpace. The products that he listed (Adobe Business Catalyst, Plone, Typo (I have a feeling Anthony meant Typo3, not this relatively obscure Rails blogging platform), Umbraco, and eZ Publish) are all traditional, page-oriented (as opposed to post-oriented) platforms. This shows that Wordpress, at least in Anthony's eyes, has grown out of its blogging roots and readers would be considering it for traditional web content management. I would have to agree with Anthony on this.
The third interesting thing about this article is that the various software communities didn't flood it with comments and other reactions. I would at least expect the very large Drupal community to dive in and lobby for their inclusion. Maybe the link-bait title of this post will change that. :)
Jan 13, 2012
If you read Content Here through RSS or just follow links to individual articles, you may have missed my new publications page. In addition to listing some articles that I have published on other sites, the publications page now includes reports that I used to sell here at Content Here. I have not kept these reports up to date with the technologies that they cover but the background information and selection strategies are still very relevant. They are posted up on Scribd where they are free to read. You may find the following reports particularly interesting.
-
This was Content Here's first report. It reviewed 7 open source Java web content management systems (Alfresco, Apache Lenya, Daisy, Hippo, Jahia, Magnolia, and OpenCms). While the individual product reviews are all out of date, the first 20 pages of the 173 page report contain useful information on the rise of open source content management and how evaluating open source platforms is different from commercial platforms
-
This is the Alfresco review from Open Source Web Content Management in Java but updated to version 3.1 which was released in April of 2009.
-
This is my most recent report. It was published in 2009 and covers Drupal 6.10. The interesting thing about this format is that it reviewed Drupal from the perspective of a publisher. The report is broken up into 3 sections: "what the publisher needs to know," "what the editor needs to know," and "what the developer needs to know." I think that much of the general commentary is still very relevant.
Feb 09, 2011
This article comparing Drupal to Django is pretty old but I just noticed it. There is a nice summary in the conclusion:
Drupal represents a middle ground between framework and CMS that we’ve chosen not to take. Drupal is far more capable than a CMS like WordPress, but also much less flexible than a pure framework. But more importantly, the facts that Drupal isn’t object-oriented, isn’t MVC/MTV, doesn’t have an ORM, and is generally less flexible than a pure framework, not to mention our preference for working in Python over PHP, all contribute to our decision not to use it.
I reached a similar conclusion on a recent project.
Mar 25, 2010
There is a great Reddit thread on The Onion's migration from Drupal to Django. The Onion was one of the companies that I interviewed for the Drupal for Publishers report. One of the things I mention in the report is that The Onion was running on an early version (4.7) of Drupal. The Onion was one of the first high traffic sites to adopt Drupal and the team had to hack the Drupal core to achieve the scalability that they needed. While versions 5 and 6 of Drupal made substantial performance improvements, The Onion's version was too far forked to cleanly upgrade.
Still, The Onion benefited greatly from using Drupal. They were able to minimize up-front costs by leveraging Drupal's native functionality and adapt the solution as their needs changed. Scalability was a challenge but it was a manageable one. Even though forking the code base was not ideal, it was a better alternative than running into a brick wall and having to migrate under duress. The Drupal community also benefited from the exposure and learning that came from The Onion using Drupal. Everybody won &mdash how often can you say that?
I can understand the choice of Django 1.1 (current) over a hacked version of Drupal 4.7. Having built sites in both Drupal and Django, I can also see the appeal of using a Django over Drupal 6.16 (current). Django is a more programming-oriented framework and The Onion has programmers. Django is designed to be as straightforward and "Pythonic" as possible. Drupal tries to make it possible to get things done without writing any code at all; and if you can avoid writing code in Drupal, you should. As a programming framework, Drupal has more indirection and asserts more control over the developer. The Onion's staff of programmers clearly appreciate the programmatic control that Django affords and they are quite happy with their decision.
Jan 26, 2010
Nica Lorbor, from Chapter Three, has a great post on their highly optimized Drupal design process. In the article, Nica shows how they start from a Drupal template that has roughly 25 common named elements (some native Drupal, some not) that can be styled according client specifications. A specialized Fireworks template calls out these elements and helps map them to a mockup to facilitate conversation between the designer and the developer. This creates a common language that binds the design to the code that the developer needs to work on. This also probably quickly identifies visual design elements that are not part of the normal Drupal/Chapter Three build, which need special consideration for estimation and budgeting.
I think the efficiency of this process supports my philosophy that you should work with a partner that specializes in the CMS that you intend to implement. Chapter Three didn't invent this methodology for their first Drupal implementation. I am sure that it evolved over time. It also speaks to the efficiency of designing with the platform in mind. With this process, everybody on the project (from designers to developers) understands what is going to be easy and what is going to be hard. Designers are guided towards concepts that are more efficient to build. Yes, you could build any design on Drupal, but that doesn't mean that you should. With some site designs, you will be fighting the natural tendencies of the platform: increasing both the implementation and maintenance costs.
I should probably make the point here that I am not implying that all Drupal sites (or sites from any other CMS) look alike - particularly to the untrained eye. Nearly all of what the casual site visitor notices (font, palette, page layout, buttons, etc.) is totally customizable in Drupal and any other CMS platform. Guessing what CMS was used involves much more subtle characteristics that you wouldn't notice unless you worked with the platform extensively.
This all raises a chicken and egg problem that I have discussed before. If the product influences the design and the design defines the requirements that drive the product selection, where do you start? As I mentioned in "When it is not all about the software," the key is knowing enough about your requirements to define a short list of options that you can evaluate on more subjective levels (such as aspects of design).
Oct 28, 2009
By now, most people have heard that whitehouse.gov has been migrated over to Drupal. Apparently, the administration has built a level of comfort with the platform with its experience using it for recovery.gov. While the Drupal community is doing high fives all around and equating this with being the most powerful CMS in the free world, I wouldn't go that far. I would say that Drupal is a very good choice for powering the kind of website that the Obama administration is trying to foster: content rich, news oriented, faceted, and populist.
Apparently, Slate Magazine's Chris Wilson wasn't so generous with his critique of the choice. I discovered the Slate article by reading Conor McNamara's excellent post
"Drupal misrepresented by Chris Wilson of slate.com." In my opinion, Conor's responses to Wilson's points are spot-on. Some of Wilson's criticisms reflect configuration choices, not limitations of the platform (like not being able to add Javascript to a content objects. It's a bad idea to allow this by the way.). Slate.fr uses Drupal and the Today's Pictures section of Slate.com is Drupal powered. It seems like Chris has just enough knowledge to sound ignorant. Readers of my reports know that I can get critical of technologies. But whenever I criticize, I make sure to do my research because I know that I am going to get attacked by defenders of that technology. Chris is about to learn this lesson. If Slate.com's commenting system wasn't so bad, he would learn even faster.
Aug 28, 2009
Recently there has been a lot of chatter about friction between the designers and developers within the Drupal community (see posts by Earl Miles and Greg Harvey). The Drupal community is huge and dynamic and is bound to have various skirmishes as members with different backgrounds and needs try to get what they want out of the platform. But I didn't really expect that the divide would be along the lines of developers and designers. I thought it would be between high-end adopters (like media companies) and low-end adopters (like individuals, small companies, and non-profits that make up the bulk of the Drupal community). Or it could have been between people who see Drupal as a business application and those who see it as a development framework.
The Drupal community is keenly aware of the importance of usability and has done a lot of work to identify issues. With the upcoming version 7 release (code freeze any day now), Drupal upped their usability efforts by bringing in some high profile designers to participate. The transition from being developer-dominated to having a more even balance between design and development is important for the Drupal platform as a business application. Mark Boulton and Leisa Reichelt conducted a very open process to incorporate peoples design ideas and feedback. Now that I think of it, this rift between new ideas and the old Drupal guard was pretty inevitable. This kind of transition is not easy. Both sides need to adapt. I don't think there will ever be total harmony between pure developers and pure designers but I do think the project can achieve a healthy level of tension that improves the software.
Aug 25, 2009
Readers of the Drupal for Publishers know that Drupal lacks a native system for associating different page layouts for different sections or pages on a site. Sub-layouts are typically implemented with conditional logic in the template code (page.tpl.php). The Drupal Panels module puts this control in the administrative interface and is becoming widely used within the Drupal community. To learn more, check out GotDrupal's excellent video tutorial on Drupal Panels. As you can see from the video, the Panels user interface is quite powerful but is also very complicated because you have to create these rules to determine under what conditions a layout should display. You still probably want a developer or well trained administrator to do the work on a staging environment and then migrate the configurations to the production environment.
Jul 17, 2009
Readers of Drupal for Publishers know that Drupal has been very successful in the small to medium newspaper market. In fact, the Newspapers on Drupal group is assembling a list of modules commonly used by newspapers. This effort has been going on for some time but there has been renewed energy because the older list was oriented around the outdated 5.x series of Drupal.
There is also a Drupal distribution for newspapers called ProsePoint that bundles Drupal, many of the modules listed by the Newspapers on Drupal Group, and some other third party code. I think that creating vertical specific distributions of software is a neat idea and there are lots of great examples. Gartner has been talking about CEVAs (Content Enabled Vertical Applications) for years but it is unlikely that their commercial software vendor audience will be as quick to capitalize on the idea as open source communities.
From an open source community perspective, vertical distros introduces interesting dynamics. On the one hand, these groups definitely strengthen the bond within segments of the community who can benefit greatly by collaborating with peers with very similar needs. On the other hand, specialization of community segments requires strong central leadership to maintain common ground and prevent the different groups from becoming too self absorbed and self interested. I don't think this is a problem in the Drupal world because leaders in the Newspapers on Drupal community seem to have a very strong belief in and commitment to the Drupal project as a whole. For now, at least, this very active constituency seems to be nothing but a positive force in the greater Drupal movement.