<!-- Content Here -->

New Look for Content Here

If you recently clicked through to Content Here, you may have noticed that some changes are afoot. Most obvious is that I have retired my old site theme. The old theme has served me well (starting on Blogger and now on WordPress) but it is time to move on. Special thanks to Leslie Charles from LAC Design for her help with the design. Less obvious is migration onto a different web host with hopes of some improved performance. I perceived a small improvement. Please let me know what you think.

But even bigger news is coming soon: in the very near future I will be announcing a new report series. So stay tuned!

Finally, Drupal Gets Deployment

Greg Dunlap, over at Palantir, has a post introducing a new "Deploy" module for Drupal. Most of the site design and behavior in Drupal is controlled through configuration stored in the database (as opposed to files on the file system). The ability to move configurations from one Drupal environment to another (like development to staging to production) has been an achilles heel for Drupal. You can't just copy the database because then you would overwrite your production data with your test data. Assuming that you don't want to be developing on the live site, you had to choose between manually repeating your work on production or resorting to some awkward SQL scripting hacks to move database stored configurations from one database to another. These scripts were always brittle because of Drupal's reliance on an an ID field that is auto-incrememented - it is hard to keep those ID sequences synchronized across different databases. Deploy is a welcome improvement.

Deploy works by allowing an administrator to create a "deployment plan" and extending other modules to give an option to add their configuration to the deployment plan. When the administrator executes a deployment, Deploy grabs all the configurations and content that have been associated with the deployment plan plus their dependencies and pushes them to a target environment. Greg's post has a nice screencast showing what it looks like to the user. Behind the scenes, Deploy adds a global unique identifier (GUID) field (in some companion tables) that is used to match up corresponding rows in the different environments.

It seems like Deploy falls short of addressing the common case where a deployment consists of a combination of configuration settings and content in the database and code in the file system. Deploy is for database-managed configuration only. For filesystem stuff, the handiest tool is a module called Drush that allows you manipulate a Drupal instance from the command line. This allows you to create a script (preferably in Ant or Make) to move files around and update a Drupal instance. Maybe it would be possible to configure Deploy to pull from another instance (rather than push). That way Deploy could be scripted in Drush for a comprehensive (database and file system) update.

These improvements are big steps in the right direction and reflect the impact of large companies running big and important Drupal sites. I expect this aspect of Drupal to be steadily improved and become standard practice by Drupal developers.

NYC Agile Developer Book Club

My friend and colleague Brian Kelly and I are starting an Agile Developer Book Club in New York. The first meeting will be on April 29th (location TBD) and we will start by reading one of my favorite books on software development: The Pragmatic Programmer: From Journeyman to Master

. After that, we will move onto other books in that genre. The general idea is to assemble a cross-language group of developers that want to improve their craft by learning from great books and each other. Each meeting we will discuss a section of the book. Beyond that, it is up to the group to figure out the details.

If you live or work in New York City and want to hang out with some people who also want to be great programmers, please join the Meetup group and block April 29th on your calendar. If you are not in New York, you should still read The Pragmatic Programmer and talk about it to whoever will listen.

Note: in case you were wondering, I have not relocated to New York. I still live in the heart of the beautiful Pioneer Valley but spend a lot of time working in New York.

Different Storage Models for Content

Joel Amoussou has a great article explaining the benefits and implications storing your content in a relational database vs. an XML store. After making the case for when to consider XML over the more common RDBMS/ORM/POJO/Template approach, Joel provides some tips for content modeling and makes some great points about how you need to think a little differently when you work with XML.

I would like to reinforce Joel's comment that the XML stack is quite different than technologies that you or your developers may be used to. The learning curve can be quite steep and many developers just give up before they really get it. Transitioning to an XML based architecture may not pay off for content management applications where your content types consist of a number of structured fields (like title and author) and one or more unstructured elements (like description and body) that the CMS just reads out what the author typed in - in other words, like this blog.

Drupal 7 UI: Be Part of the Solution

As I have mentioned before, the Drupal project takes a very conscientious approach to usability. Unlike many commercial and open source software projects, Drupal enlists the help of usability labs and is very receptive to negative feedback. That is not to say that Drupal has achieved usability nirvana. They struggle with it like everyone else - especially as they try to add functionality and flexibility into the system. It is just that they practice their usability work so out in the open.

There is an opportunity to see the Drupal usability process first-hand by participating in this call to action from usability consultants Mark Boulton and Leisa Reichelt. There are several ways to participate. For more details, visit http://www.d7ux.org

Doubt

After collecting requirements, the second most difficult component of a CMS selection is taking all the information that was gathered during the evaluation phase and using it to make a decision. This is where people get crazy with spreadsheets and scoring in the hopes that math will somehow heroically make a complicated and confusing (and, lets face it, subjective) decision obvious and irrefutable. The process looks something like this... There are a bunch of selection criteria. People rate the products on each criterion. People weight the criteria. You do some multiplication and addition and out comes some very quantitative looking numbers. Nothing looks more convincing than a score where one option has more points than another. But, users don't necessarily want to use a system just because it has the highest cumulative, weighted score. They want to use a system that helps them efficiently get their jobs done while introducing the fewest number of annoyances. if the measurement of accuracy is the overall satisfaction with the solution, this method is extremely faulty.

There are several reasons why the matrix scoring method fails to accurately select the right solution. First, the rating and weighting wind up being very subjective and arbitrary. Veterans of this approach know this to be true when the they remember the feeling of not knowing what to put down or wanting to change their score when they see another product or have more coffee. Second, the final score hides information that is important to the users. A typical example is where a user finds a very important (to him) feature totally unusable but that is overshadowed by excellent ratings in a bunch of less important features. Usually you can't correct this with weightings - especially if there are lots of selection criteria. You can't discuss trade-offs and compromises if you are just working with total scores. Lastly, criteria tend to be of unequal granularity. How can a broad criteria like "usability" be compared with something as specific as "SSL on the login page?"

I take a different approach to the decision making process. Instead of forcing the selection committee into making numerical ratings, I ask them to list their doubts with each solution. Examples of doubts are:

• a concern that the feature would not support a specific task

• unnecessary complexity or awkward behavior in doing a specific task

• an unsatisfactory explanation by the supplier about how a feature worked

• doubt about the vendor's stability or ability to support the customer

• a potential technical incompatibility with the legacy infrastructure

Each of these doubts are investigated as whether they are valid (that is, if it was a misunderstanding or oversight), if there is a suitable work-around, or if there is a reasonable compromise. Through some facilitated sessions, we work through comparing the relative weaknesses of the competing solutions and determining what is tolerable. Follow up demos and calls with the vendors are scheduled and executed. Ultimately, the solution with the fewest legitimate and significant concerns wins. Facilitating these sessions is not as easy as simply reporting matrix scores but I think that it is good that people put some real intellectual energy into making such an important and complex choice.

At first glance, this system seems designed for selecting the lesser of evils and to some extent that is true - there is no such thing as a perfect solution and there will always be compromises (I should note here that there is an option of selecting nothing if no solution is good enough) - but it is really no worse than a numerical system that decides a 5 out of 1000 score is better than 3 out of a 1000. The benefit of the doubt technique is that it keeps the focus on things that have real impact on users and forces users to think through the implications of specific aspects of the solution. This is better than having a user register their concern as low numerical score and then just moving on. A secondary benefit selection committee members learn about their needs and software features as they watch demos and their selection criteria becomes more sophisticated. This approach allows potentially important information to enter the decision making process at any time. Also, after the product is selected, the selection committee can all clearly verbalize the reason behind the decision. If there is a complaint about the implemented solution, a selection committee member can say that they identified it as a concern and then explain the plan to lessen the impact.

I will be discussing this technique as well as all the other components of my CMS selection methodology in my "How to Select a Web Content Management System" workshop at the upcoming Gilbane Conference in San Francisco (June 2-5, 2009). Register before April 28th and save $200 off. Sign up for the full conference package and get an iPhone Touch.

Book Review: Django 1.0 Template Development

I just finished reading Scott Newman's book Django 1.0 Template Development. This is the second Django book that I have read (the first was The Definitive Guide to Django
) and I am very impressed by the number (and quality) of Django books that have been published. 21% of the respondents to a recent "This Week in Django" poll said that they learned Django from reading a book (65% learned from the online documentation). Considering that until recently there were no Django books, this is significant.

Django 1.0 Template Development lives up to its title by focusing on the template layer of the Django web application framework although it does go through some basics of setting up your project and some of the details of the Django request handling pipeline. There is very little coverage of models - just enough to give the sample project some data to work with.

There is good coverage of how templates are loaded and guidelines of how to develop views [1] with plenty of tips on leveraging Django's many convenience features (like generic views) and organizing code for better manageability. There are examples for using and writing custom middleware, filters, and tags [2] with special attention paid to best practices in security. A whole chapter is devoted to working with Django's pagination system. Explanations are well supported with the theory behind and examples that demonstrate the details of Django's behavior.

The area that I was hoping for a little more depth was in optimizing performance. Django gives the developer a lot of options of how to design the application. For example, in addition to the typical template "include" syntax, Django also supports template inheritance (where a child template can extend and override blocks of a page from its parent). There is not much information on the performance implications of deep template hierarchies. The caching chapter gives a nice overview of Django's different caching options and engines and general guidelines but perhaps the art of really tuning a site is the topic for another book.

I would highly recommend Django 1.0 Template Development for anyone who wants to efficiently build a clean and manageable template layer for a Django project. In particular, a developer who needs to make the display tier flexible and extensible (such as the book's example of managing a separate site skin for mobile browsers). Although the preface recommends the reader have a working knowledge of Django and Python, I don't think that is really necessary. There is just enough information to help the developer to understand the overall Django framework but the emphasis is definitely on displaying data.

Notes:

• 1 in Django, the "view" is the code that gathers and preprocesses the data for the template to render

J. Boye: Philadelphia 2009

The conference schedule for J. Boye Philadelphia 2009 (May 5th-7th) is taking shape nicely. The J. Boye team has added several case studies to make it a true "user conference" just like the J. Boye conferences in Denmark that I have raved about in the past. Expert speakers include David Pogue, Lou Rosenfeld, Lisa Welchman, Martin White, and Tony Byrne. J. Boye takes great care to keep the tone of the conference un-salesy and encourage a candid exchange of information. To keep the conversation going after the sessions end each day, there are also three social events: the Conference Dinner (May 5th), the Conference Party (May 6th) and the Farewell Dinner (May 7th). If you are coming in from overseas you also might want to attend the "Jetlag Reception" on Monday May 4th.

Although the early bird special is no longer available, you can use the coupon code "sgphilly" to get 15% off the list price. If you work for a non-profit, you can probably get a better discount by contacting the J. Boye team directly. I hope to see you there!

How I Talked Myself Out of a Kindle

It takes me a really long time to buy a gadget. Over the course of months I deliberate whether I really need the device and, if I do, what options I should get. The current object of my rumination is the Amazon Kindle 2

and, right now, the pendulum is on the "not buy" side of the swing. Here are the arguments that are keeping it there.

1. I like to share books with my friends and family. The exchange of books can be a nice social experience. You loan or borrow a book and you have at least one person you can discuss it with.

2. I buy used books. Used books can be a great deal. I like to browse used book stores and tags sales to find interesting books at a reasonable prices.

There you have it; those are my reasons. They are working for me right now but, in case you are not convinced, you can click through this Amazon Associates link

and put a little money in my Kindle fund (because that I know that I will eventually cave).

Blogging: Alive or Dead?

Paul Boutin's Wired article "Twitter, Flickr, Facebook Make Blogs Look So 2004" last year created a lively dialog about the future of blogging. The general gist of the article (in case you haven't read it) is that mainstream media companies have adopted and started to dominate the blog format while independent bloggers have drifted into the even more casual and spontaneous domain of "status updates."

Independent bloggers do tend to let their productivity ebb and flow and I am sure that many of the "citizen journalists" who were really flowing during the blogging peak are seriously ebbing right now. I agree with Boutin that blogging is no longer the primary way that people casually share ideas. Now, when I run across some interesting information I have three choices. I can blog it, I can bookmark it, or I can tweet it. My general rule of thumb is: when I have something to add, I blog it; when I just want to save it for later (perhaps with a little note), I bookmark it in Delicious (or star it in Google Reader); when I just want to tell my friends, I tweet it. All of my stuff goes into FriendFeed where occasionally people comment and add their own ideas. I imagine other bloggers' productivity is similarly diluted across these other channels.

But Boutin's trend is going even further. There was a great article in the New York Times that described how television journalists are getting addicted to Twitter. Robert Scoble has created his own format on FriendFeed where he starts an item with something like "Why Twitter is not for conversations. I will give you five reasons here:" and then goes on to list them in the comments. As he adds items, everyone else chimes in with their opinions. The result is a Crossfire-like discussion but without the interruptions (and, thankfully, without Tucker Carlson). In this case, he gave 5 reasons out of a total of 158 comments and another 143 people "liked" the post. In these cases the journalist moves from commentator to facilitator or catalyst. But, while this format is very dynamic and has lots of energy, it lacks the authority of a single person summarizing and interpreting the information.

To really develop an idea into a cohesive viewpoint, you may not need to write a 1,400 word exposé but you do need more than 140 characters (FriendFeed allows you more but most people don't use more than 140). And for that type of communication the blog format is very well suited because you have the room to elaborate on your point and you still offer a place for others to make their own comments. Blogging is not going away. If anything, it is displacing the formal article as the preferred format for journalists who appreciate the more intimate relationship with their reading audience that comes with immediate publishing and user submitted comments. My feed reader relentlessly fills up with new content every day so I can't complain about not having enough to read. If anything, I feel like the overall quality of the blogosphere is going up. Blogging isn't dying, it is just maturing. And with maturity, comes sophistication (at least that is what I tell myself).