Creating Blueprints for Drupal Content
Published by Joel Steidl
In the past year, we've added a final step to our information architecture process that we call "Drupal Architecture". Call it what you will, but the outcome is a document that outlines the content types, fields, and taxonomies that we'll use to build the perspective site.
Creating the document takes a while, but it has some nice bonuses:
- It allows us to see all the places the same field is used and limit unnecessary duplication.
- It helps clear up where to use node/entity references and taxonomy references.
- It gives us something to review with the client before building a prototype (some clients do a great job giving feedback at this point, and others struggle with how abstract it can be).
- It speeds up prototype development. It's a breeze to quickly setup content types and create fields with our handy document. Rob has even experimented with using the Google Docs API to automatically create content types. This may work for fields as well, but the spreadsheet would need to be more strict. We would be interested to know if anyone else is programmatically creating content types and fields in a similar fashion.
Once the "Drupal Architecture" document has been created and reviewed with the client, we create the content types and fields in Drupal and go through things with the client one more time. For the client, seeing the spreadsheet converted to node entry forms really helps them connect the dots.
Fields will likely shift a bit as content entry begins, but hopefully your Drupal Architecture provided a good foundation.
In case you missed it above, check out a sample Aten Drupal Architecture document. Let us know if/how you use it!
What other ways do you plan your Drupal site's architecture?
Very nice, Joel. I do something similar in a diagramming tool. I prefer something like Gliffy b/c it's so easy to share with my clients and dev team. Here's a sample of one of my architecture diagrams from last Fall. http://www.gliffy.com/go/publish/3007867/ The diagram format lets me easily see what entity references will be needed. I like that you add more detail, like single/multi value and required.
Hi, nice post. In our company we are building the document, where all content types, taxonomy vocabularies, views, panels, flags configuration are listed in the predefined format. Also in this document we are grouping such configs in features. So we have all site architecture documented and any developer in any time can easily understand how the site functions. Do you outline the views configurations or panels pages in some way during the build of your architecture?
@Lindsay - Thanks for posting your Gliffy example! That is definitely a nice way to view that sort of thing.
@Artem - We typically don't outline views and other site building configuration. We create documents that we call "content maps". They serve as simplified wireframes for each page of the site. The content maps list the content/fields that should be displayed on each page.
Hi Joel, I was very happy to see that you do this sheet as I do quite a similar thing. As the display is tabular, I prefer it to the one you get with Gliffy as @Linsay use.
What I also do in order to see the connections among entities is preparing a class diagram. I like to do it with yuml.me because the script is self exaplained and can be saved separately from the rendered diagram.
Here is an example of such a diagram that I made for a big project: http://yuml.me/97d2b9f6 It can be rendered and edited by going to http://yuml.me/diagram/scruffy/class/draw and paste the following script: [Person]->0..[Building] [Building]->[Community] [Card]->0..[Community] [Card]->0..[Organization] [Card]->0..[Person] [Cemetery]->[Community] [Doc]->0..[Community] [Doc]->1[Card] [Doc]->0..[Organization] [Image]->0..[Community] [Image]->0..[Person] [Image]->0..[Building] [Image]->0..[Doc] [Image]->0..[Tombstone] [Image]->0..1[Personality] [Interview]->1..[Community] [Map]->1..[Community] [Person]->0..1[Person]-[note: mother] [Person]->0..1[Person]-[note: father] [Person]->0..1[Person]-[note: spouse] [Organization]->0..[Community] [Bibliography]->0..[Community] [Person]->0..[Community] [Person]->0..[Bibliography] [Person]->0..[Organization] [personality]->0..[Community] [Tombstone]->0..1[Cemetery] [Tombstone]->0..[Person]
I have lately wrote a post about it but it is in Hebrew :) and can be found here: http://practicall.co.il/1/node/610 if any Hebrew speakers might ever fall on this post of yours.
Thanks again, Amir
Really nice post! Here at our company we were building a document like this one but we are using basically topics to organize the information. We still didn't tried spreadsheets or any visual alternative yet but this examples already gave me some new perspectives! In our case besides the content types, fields and possibly custom entities we are also specifying the views, features and especific modules that the project must have plus an detailed description of customizations in order to be easier to other developers/site builders perform maintainance on the project in the future.
I really liked the idea of automating some things with the Google Docs API. I'll give a try.