Slashdot Mirror
Book Review: Drupal For Designers
Michael Ross writes "Of all the open source content management systems used for building websites, Drupal has a reputation for being one of the most flexible and powerful available, but not the easiest for web designers to use. Drupal version 7 has made some strides in alleviating those flaws, but there is still much progress to be made. During the past few years, a number of books have been published that explain how Drupal designers can do custom theming, but they tend to focus on the technical details of the theme layer, and not the practice of web design when using Drupal as a foundation. That rich yet neglected subject area is the focus of a new book, Drupal for Designers: The Context You Need Without the Jargon You Don't." Keep reading to see what Michael has to say about the book.
Drupal for Designers
author
Dani Nordin
pages
328 pages
publisher
O'Reilly Media
rating
8/10
reviewer
Michael J. Ross
ISBN
978-1449325046
summary
How to design and manage Drupal projects.
The book's author, Dani Nordin, is a Massachusetts-based web designer and the founder of The Zen Kitchen, a UX design business. The book was published by O'Reilly Media, on 1 August 2012, under the ISBN 978-1449325046. The publisher's page offers a description of the book, the table of contents, an author bio, and some free sample content (the first chapter). This publication is a compilation of three previously-released short guides — Planning and Managing Drupal Projects, Design and Prototyping for Drupal, and Drupal Development Tricks for Designers — with additional material. All of these books were written by Dani Nordin, and comprise the "Drupal for Designers" series by O'Reilly Media. (My thanks to the publisher for a review copy of this particular title.)
The book's material spans 328 pages, and is organized into seven parts, which do not include the introduction or the first chapter. The seven parts — each comprising at least two chapters — are largely presented in the same order that a typical reader would want to learn and implement the recommendations: Discovery and User Experience; Sketching, Visual Design, and Layout; Setting Up a Local Development Environment; Prototyping in Drupal; Making It Easier to Start Projects; Working with Clients; and Sample Documents.
Unlike most introductory Drupal books, this one wisely begins with a helpful dictionary of Drupal terminology. The first chapter also discusses the phases that compose a typical Drupal project lifecycle. Sandwiched in between is some guidance on where to place custom code in a Drupal directory system. The author advises that "Any module, theme, or other customization that you create for your site should always reside in sites/all" (page 2, and also reflected on pages 1 and 5). That may be true of contrib modules and themes, but certainly not custom ones, which are better located in sites/default or sites/[domain name]. She states that a child theme should be "stored separately in sites/all/<client_name>" (page 4). Actually, they should be placed in "sites/default/themes" or the themes subdirectory of a domain name directory. Finally, she recommends that for a multisite installation, one should keep "everything in sites/all" (page 5). Lumping everything into the "all" subdirectory would defeat the fundamental mechanism of multisite, which allows one to host multiple sites on a single Drupal installation, with their custom files and settings separated by domain name.
The first part of the book is loaded with valuable counsel on how to conduct the discovery phase of a website project, including coverage of project goals, user experience (UX), mockup tools, user personas, wireframes, prototypes, and the key components of a short-form project brief. It is evident from the narrative that the author is drawing upon a great deal of real-world experience, as well as lessons learned from other veteran web designers. The only blemish is where the author refers to "the project brief in Section 8" (page 45, repeated on page 254), and yet there appears to be no such section in the book. Perhaps she means Appendix A, which has an example project brief.
Once a design team has completed and received sign-off on a project brief — as well as any wireframes and other helpful preliminaries — a logical next step is to build the initial visual design. In the second part of the book, the author demonstrates how she uses sketches, style tiles, layout elements, greyboxing, grid systems, and Fireworks templates for crafting a visual design for a website. Throughout these chapters, she uses a redesign of her own personal website to illustrate the material. Both this part and the previous part of the book contain little information that is specific only to Drupal; thus, it could be useful to designers building websites using other CMSs.
Some readers of the book may already have up-to-date Drupal environments installed and configured on their development web servers. For those who do not, Part III will likely be appreciated, especially if the reader is using a Mac machine, because that is the environment to which the text and screenshots are geared. The author contends that "Windows seems to add an annoying layer of complexity to most of the command-line stuff" (page 102). Yet from my own experience, installing and using Git and Drush on a Windows PC is largely the same as in a Linux environment. Most developers complain that the main hurdle is Git's unintuitive workflow, which is independent of the operating system. The author touches upon some other tools, such as LESS and phpMyAdmin. Chapters 9 and 10 focus on Drush and Git, respectively. The last chapter in this section steps the reader through installing MAMP and Drupal. The discussion is generally comprehensible, except for the first paragraph on page 132, which is arguably the most confusing in the entire book. For instance, echoing a misstep seen earlier, it advises that all changes to your Drupal site should be stored in the sites/localhost directory, which contradicts the advice on the previous page, that all customizations to the site should be located in the sites/all directory.
The fourth part of the book covers prototyping in Drupal: gleaning from the client the information needed to define the content types for the website; choosing the appropriate modules for implementing the desired functionality; using views for displaying data; improving the HTML generated by views; creating custom Drupal themes; and using LESS to better manage the CSS within a theme. The advice is on target, except for the recommendation to use the Submit Again module, which does not have a Drupal 7 release, and has been replaced by the Add another module. Readers who are having difficulty locating the User Reference module mentioned by the author (page 187), can find it as a submodule in the References project. Lastly, the author instructs the reader to enable any base theme used (page 217), but actually it does not need to be enabled; installation alone is sufficient.
Part V, the briefest of them all, explains how to utilize the Features module, as well as Drush Make and installation profiles. Part VI comprises three chapters which offer guidance on how to propose an estimate for new projects, how to push back on unreasonable client requests, and how to learn from and document a finished project. This material is so closely related to that presented in the first part of the book — project discovery, planning, project briefs, etc. — that these final three chapters should have been incorporated into that earlier part. In fact, the first paragraph of this part states that it describes a phase of the discovery process that should be conducted prior to the phase described in Part I. Nonetheless, the author provides smart tips on some of the more difficult aspects of project management. The last part of the book comprises three appendices with sample documents — specifically, a project brief, a work agreement, and a project proposal.
On the publisher's page for the book, no errata have been reported, at this time. That is likely because the book appears to contain remarkably few errata: "What if there was" (pages 81 and 245; "was" should be "were"); "get familiar [with] the command line" (page 108); "a couple of" (page 172; should be "a few," as it is referencing three bullet points); ".less" (page 208, twice; should be "LESS"); "carpal tunnel[s]" (page 231); "original code [for] a feature" (page 242); and ".tpl" (page 266; should be ".tpl.php"). This is certainly a low number of errata for a technical book of this size. Kudos to the author and the O'Reilly editing team.
Overall, the book's style is clear and conversational, with only a few rough patches. Incidentally, the terms "directory" and "folder" are synonymous, but newbie readers who do not understand this could be confused when the two terms are used interchangeably, especially within the same sentence (e.g., page 109). Interspersed at various points in the text are interviews with people involved in web design, entitled "From the Trenches," which add perspective from designers other than the author. The reader will also find some natural humor and humility, which is always welcome in a technical work.
The author and publisher have made good use of the many screenshots, showing sample designs, Drupal user interface pages, etc. Unfortunately, for the Drupal pages, the admin theme used is the default, Seven, which results in black text on a gray background — a poor choice for such wide screenshots being compressed into small images on the page. Consequently, much of the text is barely legible, especially for anyone with imperfect eyesight.
From a technical point of view, the information provided is accurate and worthwhile. The only serious problem is the misleading advice, noted above, concerning the placement of custom modules and themes within the directory structure of a Drupal project — which was undoubtedly unintentional. The reader will encounter some HTML markup, a lot more CSS, and a minimal amount of PHP code. All of it is neatly formatted, and the only apparent problem is where a snippet of example code includes invalid nested "<?php" tags (page 188).
Despite these minor blemishes, this is one of the better-written Drupal books on the market. Web designers who will be working on Drupal projects, should be well rewarded in choosing this book as a solid starting point for their studies.
Michael J. Ross is a freelance web developer and writer.
You can purchase Drupal for Designers from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
The book's material spans 328 pages, and is organized into seven parts, which do not include the introduction or the first chapter. The seven parts — each comprising at least two chapters — are largely presented in the same order that a typical reader would want to learn and implement the recommendations: Discovery and User Experience; Sketching, Visual Design, and Layout; Setting Up a Local Development Environment; Prototyping in Drupal; Making It Easier to Start Projects; Working with Clients; and Sample Documents.
Unlike most introductory Drupal books, this one wisely begins with a helpful dictionary of Drupal terminology. The first chapter also discusses the phases that compose a typical Drupal project lifecycle. Sandwiched in between is some guidance on where to place custom code in a Drupal directory system. The author advises that "Any module, theme, or other customization that you create for your site should always reside in sites/all" (page 2, and also reflected on pages 1 and 5). That may be true of contrib modules and themes, but certainly not custom ones, which are better located in sites/default or sites/[domain name]. She states that a child theme should be "stored separately in sites/all/<client_name>" (page 4). Actually, they should be placed in "sites/default/themes" or the themes subdirectory of a domain name directory. Finally, she recommends that for a multisite installation, one should keep "everything in sites/all" (page 5). Lumping everything into the "all" subdirectory would defeat the fundamental mechanism of multisite, which allows one to host multiple sites on a single Drupal installation, with their custom files and settings separated by domain name.
The first part of the book is loaded with valuable counsel on how to conduct the discovery phase of a website project, including coverage of project goals, user experience (UX), mockup tools, user personas, wireframes, prototypes, and the key components of a short-form project brief. It is evident from the narrative that the author is drawing upon a great deal of real-world experience, as well as lessons learned from other veteran web designers. The only blemish is where the author refers to "the project brief in Section 8" (page 45, repeated on page 254), and yet there appears to be no such section in the book. Perhaps she means Appendix A, which has an example project brief.
Once a design team has completed and received sign-off on a project brief — as well as any wireframes and other helpful preliminaries — a logical next step is to build the initial visual design. In the second part of the book, the author demonstrates how she uses sketches, style tiles, layout elements, greyboxing, grid systems, and Fireworks templates for crafting a visual design for a website. Throughout these chapters, she uses a redesign of her own personal website to illustrate the material. Both this part and the previous part of the book contain little information that is specific only to Drupal; thus, it could be useful to designers building websites using other CMSs.
Some readers of the book may already have up-to-date Drupal environments installed and configured on their development web servers. For those who do not, Part III will likely be appreciated, especially if the reader is using a Mac machine, because that is the environment to which the text and screenshots are geared. The author contends that "Windows seems to add an annoying layer of complexity to most of the command-line stuff" (page 102). Yet from my own experience, installing and using Git and Drush on a Windows PC is largely the same as in a Linux environment. Most developers complain that the main hurdle is Git's unintuitive workflow, which is independent of the operating system. The author touches upon some other tools, such as LESS and phpMyAdmin. Chapters 9 and 10 focus on Drush and Git, respectively. The last chapter in this section steps the reader through installing MAMP and Drupal. The discussion is generally comprehensible, except for the first paragraph on page 132, which is arguably the most confusing in the entire book. For instance, echoing a misstep seen earlier, it advises that all changes to your Drupal site should be stored in the sites/localhost directory, which contradicts the advice on the previous page, that all customizations to the site should be located in the sites/all directory.
The fourth part of the book covers prototyping in Drupal: gleaning from the client the information needed to define the content types for the website; choosing the appropriate modules for implementing the desired functionality; using views for displaying data; improving the HTML generated by views; creating custom Drupal themes; and using LESS to better manage the CSS within a theme. The advice is on target, except for the recommendation to use the Submit Again module, which does not have a Drupal 7 release, and has been replaced by the Add another module. Readers who are having difficulty locating the User Reference module mentioned by the author (page 187), can find it as a submodule in the References project. Lastly, the author instructs the reader to enable any base theme used (page 217), but actually it does not need to be enabled; installation alone is sufficient.
Part V, the briefest of them all, explains how to utilize the Features module, as well as Drush Make and installation profiles. Part VI comprises three chapters which offer guidance on how to propose an estimate for new projects, how to push back on unreasonable client requests, and how to learn from and document a finished project. This material is so closely related to that presented in the first part of the book — project discovery, planning, project briefs, etc. — that these final three chapters should have been incorporated into that earlier part. In fact, the first paragraph of this part states that it describes a phase of the discovery process that should be conducted prior to the phase described in Part I. Nonetheless, the author provides smart tips on some of the more difficult aspects of project management. The last part of the book comprises three appendices with sample documents — specifically, a project brief, a work agreement, and a project proposal.
On the publisher's page for the book, no errata have been reported, at this time. That is likely because the book appears to contain remarkably few errata: "What if there was" (pages 81 and 245; "was" should be "were"); "get familiar [with] the command line" (page 108); "a couple of" (page 172; should be "a few," as it is referencing three bullet points); ".less" (page 208, twice; should be "LESS"); "carpal tunnel[s]" (page 231); "original code [for] a feature" (page 242); and ".tpl" (page 266; should be ".tpl.php"). This is certainly a low number of errata for a technical book of this size. Kudos to the author and the O'Reilly editing team.
Overall, the book's style is clear and conversational, with only a few rough patches. Incidentally, the terms "directory" and "folder" are synonymous, but newbie readers who do not understand this could be confused when the two terms are used interchangeably, especially within the same sentence (e.g., page 109). Interspersed at various points in the text are interviews with people involved in web design, entitled "From the Trenches," which add perspective from designers other than the author. The reader will also find some natural humor and humility, which is always welcome in a technical work.
The author and publisher have made good use of the many screenshots, showing sample designs, Drupal user interface pages, etc. Unfortunately, for the Drupal pages, the admin theme used is the default, Seven, which results in black text on a gray background — a poor choice for such wide screenshots being compressed into small images on the page. Consequently, much of the text is barely legible, especially for anyone with imperfect eyesight.
From a technical point of view, the information provided is accurate and worthwhile. The only serious problem is the misleading advice, noted above, concerning the placement of custom modules and themes within the directory structure of a Drupal project — which was undoubtedly unintentional. The reader will encounter some HTML markup, a lot more CSS, and a minimal amount of PHP code. All of it is neatly formatted, and the only apparent problem is where a snippet of example code includes invalid nested "<?php" tags (page 188).
Despite these minor blemishes, this is one of the better-written Drupal books on the market. Web designers who will be working on Drupal projects, should be well rewarded in choosing this book as a solid starting point for their studies.
Michael J. Ross is a freelance web developer and writer.
You can purchase Drupal for Designers from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
The Drupal Logo is formed from the tears of unsuspecting developers forced to use it.
DRUUUUUUUUPAL! FUCK YEAH!!!
For a while I worked with someone else to put together websites. They would come up with a design mockup in photoshop. Then he gave me a PDF and I did the actual implementation. I would ask him for specific graphical elements when needed. The results were very nice. They looked good and worked well and reliably.
I have seen the results of several 'designers' who made websites themselves, I must emphatically say that they have no business making websites.
I can write a book for web designers too. It would be composed of a single page that says:
If you want to design a website, go ahead. But for the love of $(deity) please then hand it off to an actual programmer. You do not understand the underlying technologies to make it work. You do not understand the security implications of what you are doing. Just because you know how to uncompress a drupal or wordpress archive doesn't mean you know WTF you're doing. Even if you manage to get a working site put together, there is a good chance that it will run poorly because you bolted on way too many plugins, and it is almost guaranteed that you've left gaping security holes that will bite the client in the rear down the road.
So please, get an actual programmer to help you with implementation.
The reviewer accidentally typed O'Reilly in the spot where Packt should go. Otherwise another solid 8/10 Drupal review.
As a noob in the web programming world, I like to try out a lot of the different tools offered that are supposed to ease development.
I tried Joomla! and the results were... less than satisfactory (less of a learning 'curve,' more like a learning free-fall).
I gave Drupal a shot; not terrible, I think if I work with it enough I'll understand the system well enough to make some damn fine looking blogs... if I were interested in making yet another blog site (I'm not).
Long story short, I ended up hand-coding everything anyway.
So it goes.
An enigma, wrapped in a riddle, shrouded in bacon and cheese
I wouldn't ask a softwre engineer to do web design. Why do designers think they can code? I've yet to see an example of a web designer coding that has ended well. It's only that most of them do small unknown sites that they don't get hacked constantly or go tits up all the time.
What the fuck is that animal on the cover? I remember "The Camel Book" and "The Owl Book", but seriously, what the fuck is that thing?
I did some benchmarking and discovered that C or C++ is really great for developing websites with. Everyone moved to Java and Perl and PHP before C++ web development had a chance... OOP > Templating Language > Generic CMS. I found that some shared hosting providers even have GCC installed, and otherwise you can install it yourself, or just upload the binaries and Apache will execute them for you. They run faster than compiling / interpreting PHP or Perl, and I don't have to implement an entire server. I also get access to a huge assortment of software libraries.
I agree CMSs like Drupal or Wordpress have their place. That place is as far from me as physically possible: Anything that runs on PHP invariably requires me mucking about in PHP -- Sorry, I just can't live with that, I'd rather use Java. If PHP is the future, I'll just keep living in the past -- It's actually quite nice here!
Drupal haters say:
"Documentation is a problem".
Answer: we have an active documentation team. Documentation is not as good as it could be, but it never is. It's put together by volunteers, which makes it easy to contribute. Every module has a readme.txt. And there's a huge amount of documentation at . There are hundreds of videos - just last week all of drupalcon.org held in Munich was videoed and put online. And I note that the OP is a book review on another Drupal book.
"It's spaghetti code"
Answer: The code is hugely well structured. It works on a callback-by-naming system, so there's no need to register callback functions, it happens automagically. Mostly, I think that this criticism comes from people who don't understand the architecture. It's not perfect - there is cruft - for instance there hasn't been a settled standard for code-level plugins - e.g. I want to rewrite the standard paging through lists, so that it works better for my site. That uses one style of plugin code. There are others. This is part of growing pain, and is ironed out with each version.
"It's not Object Orientated"
Answer: Much, but not all of the code is OO, but was designed to work on PHP4 as well as PHP5. In time it will all be OO. But more importantly, OO is an idea to promote modularity and extensibility, which are notions that are built into the architecture. For instance, a pattern that is repeatedly used is the system of overrides by putting a well named piece of code in the right place.
"It's written on PHP"
Yep. It's not as fast as C++. Or Java. It's also cheaper to write, easier to learn, runs on almost every webserver, and is a mutt of languages, rather like English. There are hundreds of developers who contribute to the core development and thousands who contribute to modules. I don't know of any open-source C++ CMSs with the same rate of growth. Hardware is cheaper than developers. Turns out that PHP is good enough for Facebook. (Yes, I know: Hiphop. That's optimization.)
"It's complicated and over-engineered"
If you want a tool that is just a blog, then Wordpress is excellent. If you want a tool that grows with you, and can do anything you want then Drupal is probably going to work out better for you than many other tools. That's not to say that there aren't great Drupal blogs, but out-of-the-box, Wordpress is better than Drupal as a blog. But Drupal also has distros/install profiles, which are versions specialised for a particular job. And maybe one of those is a better match for your needs than the core version of Drupal.
"I'm a Joomla/Silverstripe/Wordpress/Perl/whatever user"
Those are all excellent tools. You should carry on using what works for you. But if you are interested in what's happening elsewhere, then come by drupal.org and have a look around. Have a play with one of the pre-packaged versions like drupalgardens.com.
"I can make a CMS. Why do I need someone elses?"
I too made and sold CMSs. Turns out that you can't compete with the rate of growth, the rate at which maintenance is done, or the availablity of add-ons.
"I've always been fine with my hammer and nail and plain HTML."
Yep. You don't make websites that work on mobile phones. Or large websites. Or ones that change frequently. Or you make something which for which a completely custom solution is better: Drupal is never going to be the best forum software. If you just need a forum, then use specialist forum software. But if you need forums, and to put some pages up, and to have an image gallery, and to send SMSs on update, and...etc, then start with a tool that can grow.
"It looks terrible"
It will look exactly how you want it to look. It's true that some other systems have many more off-the-shelf templates. And it's true that Drupal could be more designer-friendly, but shouldn't how your site looks reflect you?
"It does hardly anything - it doesn't even do Wysiwyg"
When you install it, you get a bare-bones system, to which you add parts. The core is a framework to
Doesn't matter how many times I check my writing, the moment I post, I discover something wrong. :-(
"And there's a huge amount of documentation at " http://drupal.org/documentation.