"Drupal For Education And E-Learning" Book Review

Submitted by Bevan Rudge on January 4, 2009 - 7:45pm

Front cover of Drupal for Education and E-Learning

Drupal for Education and E-learning is a must-have for any teacher, school or education institution considering a new school website, or technology-centric project in the classroom. Whether the reader has heard of Drupal or not, the book provides valuable insights, empowering ideas and simple instructions to help get any teacher or school on their way to having a powerful, useful and valuable learning resource. The book is littered with Learning Goals which help inspire teachers to find useful and innovative ways of using their website as a learning device for their students. The chapters and sections are well ordered for the target audience. Basic concepts about Drupal, websites and the internet are introduced in the early chapters. Followed quickly by clear instructions to get your first Drupal website set up including important but non-Drupal tools and services like web hosting, FTP and phpMyAdmin. These step-by-step instructions and most instruction sets in the book have an overview or summary of the steps, often called The Short Version which precedes The Detailed Version. This is important for exploratory Drupal users since they are likely to be missing conceptual understandings of many critical components, tools and ideas. The summaries help the reader understand generally what is being introduced, how it fits into the larger picture of their goals and helps them to understand the concepts rather than just how to manipulate the tool. The book also goes beyond Drupal and covers topics such as hardware and desktop software for creating podcasts, integrating with iTunes and creating video. Learning goals and many useful tips are included to help make these successful classroom activities. The book also highlights often-missed features such as garland theme's tabs (aka local tasks) and admin > by module. Views 2 is explained very well and the author's description of views arguments on page 78 is very clear and simple yet complete enough for this introductory purpose;

Arguments allow you filter the content returned in a view through a value in the URL; for example, using arguments you can filter for content created by a specific user based on their username – http://yoursite.org/your-custom-view/harry would give you all posts by user harry, and http://yoursite.org/your-custom-view/tom would give you all posts by tom. Adding arguments is not necessary for all views, and views can function perfectly well without arguments. Used effectively, however, arguments can add a level of flexibility not possible with filters. Arguments are covered in Chapter 13.

Criticism

On the whole the book is excellent and highly recommendable to any educator or education institution – especially primary, middle and secondary schools. However I did find some room for improvement in a few areas. See comment below from the author, Bill Fitzgerald. Installation steps are misleading and could be simpler. The book suggests that as part of the install process the user needs to make a copy of default.settings.php called settings.php (pages 15 and 17). Most of the time this is not necessary – Drupal takes care of this when install.php executes (if filesystem permissions allow it to). Also in the installation steps, the author suggests that a MySQL user and privileges should be created with a SQL snippet that the reader needs to retype (pages 16 and 18). Retyping code is highly error-prone, and this same task can be achieved via phpMyAdmin while introducing the user to MySQL's model of databases, users and privileges. phpMyAdmin is used previously in the instructions to create the database. Bill builds mental models of the website components quite well throughout most of the book. However the section on content types and fields on page 47 is lacks in this aspect. This is a shame, since it is one of the more difficult yet most important concepts for Drupal newbies to grasp. Simpleviews module is a very useful and powerful way to introduce views to Drupal newbies. Bill does not mention it – although I expect this is because it did not exist until after the book went to print. Some screenshots are referenced multiple times in the text but it was often difficult to match textual references to images. Clearly numbered images would have facilitated this. Annotations on screenshots were also often subtle and easy to miss. Though this is a difficult problem to solve without printing in color. See comment below from the author, Bill Fitzgerald. In my opinion the integrity of the book is compromised a little on page 285, where Bill suggests typing out a long PHP snippet into a node body to create two lists of links to views with arguments. Typing copied code is hard work, error prone and extremely frustrating to those who are not familiar with the code syntax. It is also very difficult to manage PHP errors in nodes and generally bad practice to have more than trivial amounts of PHP code in nodes or any text field stored in the database. (Find out how to use PHP on Drupal settings pages safely). The example solution is a bad solution to the problem anyway – two summary views could have done this with no PHP code snippets and introduced some of Views module's more advanced and empowering features. The sample PHP code is also of an unnerving quality. It doesn't use theme() functions for fieldsets, but hard-codes the html markup;

<?php
 $output = '<fieldset class="collapsible"><legend>'. $group['title'] .'</legend>'; 
?>

In my opinion, it is a responsibility of Drupal users to contribute something back to the Drupal community. Similarly it is the responsibility of those who introduce Drupal to others to encourage those people to contribute something and suggest what and how. Bill fails to encourage his readers to contribute. There is just one very small section on the last page of the book about giving support. There are many ways which Drupal users can contribute back to the community, many of which are probably more viable for teachers and schools than giving support. As with most of the books from Packt Publishing that I have reviewed, the index leaves much to be desired. It is missing many of the technical terms I would expect a non-technical user would need to look up, such as panels, arguments, aggregation, field.

Errata

It is very easy to make technical mistakes when writing a book, and I usually find several when reviewing Drupal books. However I found just one minor error in this book; in Upgrading Core – The Short Version on page 361, running update.php is in the first step, when it should be the last step.

About the Author

The author, Bill Fitzgerald, is a long-time contributor to the Drupal project and community. He has recently been featured in interviews on both the Lullabot podcast and Acquia podcast series about his work with Drupal and this book. Bill is the co-founder of FunnyMonkey, a Drupal development shop working primarily within education. He blogs on FunnyMonkey.com. He also maintains a Drupal distro for education; DrupalEd, and runs a groups.drupal.org group for Drupal in Education.

Purchasing

Drupal for Education and E-learning costs USD 45 on Amazon.com, GBP 28 on Packt Publishing's (the publisher) website and is similarly priced in other online and street-stores. Now to convince New Zealand's Ministry of Education to send copies to every New Zealand school and conquer young people's misconceptions about computer science!

Disclaimer

Packt Publishing requested me to review a number of their Drupal books. I agreed to do so in exchange for free copies of the reviewed books. I am receiving no other compensation from Packt Publishing in exchange for these book reviews. See more reviews of Drupal books.

Bevan Rudge's blog

Comments

A couple thoughts here --

Submitted by billfitzgerald on January 5, 2009 - 1:53am.

Hello, Bevan, Thanks for the review/feedback -- One of the challenges I faced when writing a book for people getting to know Drupal/people who don't write code was how much detail to include -- in other words, the balance between the theoretical and the practical. This tension is also compounded by the reality that, when writing code *is* an option, it creates a broader range of (often more elegant) options. These details are a reality for people with a few years of experience building Drupal sites, but are less relevant to people new to Drupal -- many people using Drupal (at all levels of experience) just want to get their project done, and are less concerned about the philosophical underpinnings of how and why the software came to be in its current form. So, I had to make some choices there -- I don't know if I always made the *right* choice, but my goal was to create a set of steps that isolated the general building blocks (CCK and various field types, Views, OG, Blocks and Menus, etc) and highlight processes that could be reused in a variety of different contexts -- basically, modular directions that can be used easily by people with no coding experience. On the whole, your criticisms are things I agree with. I will admit I winced a bit when I read:

Some screenshots are referenced multiple times in the text but it was often difficult to match textual references to images. Clearly numbered images would have facilitated this.

In my first two drafts, I had every screenshot numbered, and the text reference the image numbers. I used a pretty standard labeling scheme: Chapter # - screenshot number, so the 5th screenshot in Chapter 10 would have been Figure 10-5. I was pretty surprised to get the prefinals and see that all of the image numbers had been removed. At the risk of stating the obvious, they never made it back in. You are also right on about SimpleViews -- it didn't reach a stable release until mid-October, and by that point the book was pretty set. I do have a couple questions -- re the install instructions, the install procedure changed in the middle of the summer (IIRC, between 6.2 and 6.3). The details are covered in this issue, and the install.txt (see Step 2) of Drupal core has been updated accordingly -- see the diff on the commit here. Personally, I think webchick's take on this issue is dead on. Also, re the Views snippet: this is one of the areas where I had to make a judgment call. When we (FunnyMonkey) are developing a site, this is the type of code that goes into a mysite.module, or, if it can be adequately generalized, into a module we contribute back to d.o. However, I made the assumption that most of the people reading this book would balk at creating a module; from training people over the years, I have definitely gotten the sense that there is a perceived wall/barrier between adding in code snippets and creating a module -- even though the two are pretty comparable. So, for better of for worse, I went with a code snippet. This is also the same (potentially misguided) rationale behind harcoded html in the snippet. Looking at the snippet from the perspective of someone new to Drupal and/or code, this:

<?php
$output = '<fieldset class="collapsible"><legend>'. $group['title'] .'</legend>';
?>

isn't particularly scary, where the theme() functions for fieldsets are more complex -- so, in the interest of making this specific snippet more accessible for non-coders, I made the call to take the shortcut. Was it the right call? Maybe, maybe not. Also, re:

The example solution is a bad solution to the problem anyway – two summary views could have done this with no PHP code snippets

Is there a summary view that will list out the groups to which a user belongs, then list out the users in a specific role within each group, and then link to all the posts by each individual user in an individual group? If so, I'd love to see it. For my first two drafts of the book, OG, Views, and CCK were either at dev or RC status. While I can imagine some comparable functionality leveraging some of the existing Views2 Filters and Relationships, back when I was writing the book there was not a Views Relationship that would return the users within a specific group, and then link to a list of posts by that user, in that group. And with all that said, if this doesn't already exist within OG/Views2, it's a good candidate for a stand-alone module, which would make the whole snippet (and my ramblings in this comment) a moot point anyways. Finally, re:

Similarly it is the responsibility of those who introduce Drupal to others to encourage those people to contribute something and suggest what and how. Bill fails to encourage his readers to contribute. There is just one very small section on the last page of the book about giving support. There are many ways which Drupal users can contribute back to the community, many of which are probably more viable for teachers and schools than giving support.

Yeah, I hear you on this. I try and lead by example, and FunnyMonkey is very active within both the Drupal and various education-centered communities, but I could have emphasized this more. I feel some blog posts coming up... Anyways -- thanks for the feedback, and, if you're still reading at this point, I commend you for your patience. Cheers, Bill

Thanks for your response!

Submitted by Bevan Rudge on January 5, 2009 - 3:53pm.

Hi Bill! Thanks for your response! It's a privilege to have this conversation with you. :)

Thanks for the review/feedback -- One of the challenges I faced when writing a book for people getting to know Drupal/people who don't write code was how much detail to include -- in other words, the balance between the theoretical and the practical.

I'm sure it is a difficult balance.

I do have a couple questions -- re the install instructions, the install procedure changed in the middle of the summer (IIRC, between 6.2 and 6.3). The details are covered in this issue, and the install.txt (see Step 2) of Drupal core has been updated accordingly -- see the diff on the commit here. Personally, I think webchick's take on this issue is dead on.

Somehow I missed that. I have update the blog post.

This is also the same (potentially misguided) rationale behind harcoded html in the snippet. Looking at the snippet from the perspective of someone new to Drupal and/or code, this:
<?php $output = '<fieldset class="collapsible"><legend>'. $group['title'] .'</legend>'; ?>
isn't particularly scary, where the theme() functions for fieldsets are more complex -- so, in the interest of making this specific snippet more accessible for non-coders, I made the call to take the shortcut. Was it the right call? Maybe, maybe not.

While I'm not sure yet whether I agree, I understand your rationale now.

Is there a summary view that will list out the groups to which a user belongs, then list out the users in a specific role within each group, and then link to all the posts by each individual user in an individual group? If so, I'd love to see it.

I see now that I had not understood the code snippet correctly. I first read it some weeks ago and made some notes, but did not recall accurately what the code snippet does when I got around to writing up this review. I think the following lists can be created with Views2 (assuming the right fields arguments and filters have been exposed to Views 2);

A list of links to Groups I manage
A list of links to My groups (that I do not manage)
A list of links to posts by users (of a particular role) in a group (a summary view for list of posts by user (an unspecified argument) in a group specified by argument or filter)
A list of links to users in og groups, grouped-together by og-group, including duplicate rows/links for users in multiple groups (A user view, as opposed to a node view)

While all of these can recreate components of what the PHP snippet does (and the latter two are actually quite close to the desired functionality), they don't do exactly the same thing, combined or singly. The code snippet creates what I'd dare coin as a double-layered summary view – much like a regular summary view, that creates links to the one-dimensional list of possible permutations of a view that has ONE unspecified argument, a double-layered summary view has two unspecified arguments, and therefore a two-dimensional list of links, navigable by group and also by user. I'm fairly certain that views 2 does not do double-layered summary views, and therefore I agree that this would need at least some PHP code to pull together or modify some of the above views. It's likely that this code would be less lines, but more complicated, than the code snippet in the book, and therefore possibly not a better solution for this context. I agree this would make a useful module, or additional feature for Views 2 (albeit an almighty complex one!) I've made some changes to the blog post.

Anyways -- thanks for the feedback, and, if you're still reading at this point, I commend you for your patience.

I read it with the primary purpose of reviewing it, so I'm not 'reading' it anymore. Although I do hope to use with a local primary school in a pilot mentoring program I am involved in. Thanks so much for taking the time to respond to the view. I'm sure that readers of this review will appreciate input and time. And I'm glad to be able to correct my review so that it is not misleading! Bevan/

Other thoughts

Submitted by billfitzgerald on January 6, 2009 - 12:34am.

Hello, Bevan, Thanks for your thoughtful response, on top of your thoughtful review. Your feedback has been useful and helpful -- although the book is out and done, the opportunity to rethink and revise how I explain Drupal to others (which is a big part of what I do at FunnyMonkey) is always valuable. This conversation has been great; thanks for making it happen. Your breakdown of the Views 2/OG functionality dovetails with what I was thinking. At some point, I think we might generalize this code for D6. We have already done something similar in D5 using Views and Tagadelic to create tag clouds for posts by individual users; the tag cloud shows all yerms used by individual users in a block on specific node types (ie, all blog posts and images) and specific url paths (ie, a user's profile page) -- the tag cloud contains links that include a UID and a TID that get fed to a view to show posts by a specific user in a specific term. We need to clean it up before releasing it out, but the idea is pretty similar to what we're discussing here. On a semi-related note, if you end up using the book in the mentoring program, I'd love to hear how it goes -- and, if there's anything I could help with, let me know. Cheers, Bill