Apr 24, 2009
The Web Content Conference in Chicago (June 15-16) is running a special promotion of $100 off the regular registration price. I have spoken at this conference twice and consider it a hidden gem in the content management conference scene. The atmosphere is non-commercial and down to earth, the speakers are exceptional, and the audience is knowledgeable and engaged. If you can get to Chicago this summer and you want to learn about ways to leverage web content, attending this conference is an obvious choice.
Apr 21, 2009
Note: because this report no longer covers the current version of Drupal, it is available for free on Scribd: Drupal for Publishers
Florence, MA (April 21, 2009) -- Content Here is pleased to announce the availability of a new report. Drupal for Publishers, is the first of a new report series called Web Technologies for Publishers. Written for a cross-functional technology selection committee, each report evaluates a technology against the specific requirements of a newspaper, magazine, or broadcast news website. All Content Here reports are written with the customer in mind — distilling a wealth of information from a wide range of sources into a concise, easy to read narrative. Drupal for Publishers has case studies describing Drupal implementations at Fast Company, Lifetime TV, Morris Publishing, Now Public, and The Onion.
The 24 page report is broken down into sections that explain what the different stakeholders (the publisher, the editor, and the developer) need to know about Drupal. The publisher's section contains information about the time to market, availability of talent, cost, and the future of Drupal. the editor's section covers functional aspects such as content entry, workflow, editorial control and general usability. The developer's section discusses extensibility, security, performance, and developer resources.
Drupal for Publishers is priced at $100 for a workgroup license and can be purchased from the Content Here reports store.
About Content Here: Content Here provides professional services and analysis of content technologies, with a deep technology focus. Drawing on real-world implementation experience, Content Here analysts evaluate software from an implementer's point of view to provide technology decision makers with information assets needed to achieve success, save money, and reduce risk.
CONTACT:
Seth Gottlieb, Content Here
Tel: 857.488.4386
E-Mail: info@contenthere.net
Apr 14, 2009
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!
Apr 13, 2009
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.
Apr 09, 2009
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.
Apr 07, 2009
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.
Mar 31, 2009
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
Mar 30, 2009
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.
Mar 26, 2009
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
2 These are important for a template developer because Django deliberately limits the amount of logic you can put into a template to force developers to keep templates clean and make code more reusable. Logic belongs in filters (that manipulate data) and tags (that do more complex logic), and middleware (where you inject additional functionality into the request/ response cycle).
Mar 24, 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!