Why the phrase 'content type' is not a client facing term
A Content type (or rather node type) is a Drupal construct and is relatively recent, making it partially into core in D6 and almost fully into D7.
Should we build a client site in PHP, Wordpress, Zend, Cake, .Net, Symphony, or most other frameworks then the phrase ‘content type’ (particularly what it means in Drupal) will not apply or at-least mean something slightly different.
In Drupal 7 and soon in Drupal 8, what content types used to be has evolved and changed. There are also other modules and other techniques which can and sometimes should be used to build the functionality which used to only be available from content types.
Using direct system specific terms like ‘content types’ when discussing client functional needs is problematic in that it is only really relevant to Drupal and its meaning and usage can change in Drupal.
We should communicate with clients as much as possible at the functionality level and not the system level. Whenever a client has a little system level knowledge they may try to move conversation or even decision making down into the system.
For their sake, stop them. Move the conversation back up into the area of functionality.
Functional specifications provide the list of needs/wants that we must meet for the client Functional specifications should ALWAYS be technology agnostic System design choices can change over time, change with tool selection, and are often best made at the time of actual development.
So, what does it look like to talk functional specs instead of system specs?
Surprisingly, it’s almost the same thing; but different by one degree (My father used to talk about flying and how being off by one degree for too long will land one in the Mojave rather than Palm Springs Not good.)
Functional specifications look like the following Note: We could even use the phrase content type with a client, just not associating it with system level architecture
News articles should only be allowed in the news section of the site Only News Writers can create News articles and only News Editors can approve them Each News article should have an image, a date, an author attribution, body copy, a headline, and a teaser description for when it appears in search results News editors should also have the ability to tag news articles with two sets of terms; one from the global site terms and the other from the news article specific terms
The above functional specification gives us everything we need to have a dialogue with the client, to measure the successful implementation of the feature, and the basic user story necessary for us to build it within the software platform of our choice.
The functional acceptance test becomes the following:
Log in as a News Writer and click to create a new News article Upload an image for your news article Add a date, an author attribution, body copy, and a headline Enter in a brief teaser or description of the news article for when it appears in search results lists Submit your article It should be qued for approval by a News Editor for placement in the News Section.
Now log in as a News Editor:
The above should be how (with the client) we measure the successful implementation of the solution which meets the client’s needs
Note: At no point whatsoever did we need to discuss ‘content types’ or any system level implementation.
Internally, in the Sprint for the News article feature (not before); we will determine the system level approach to meeting this functional requirement
I have said before that I actually don’t care how a developer implements a functional specification, as long as it meets the client need This is sort of half true and half not
The half true part is from an advanced system level background which uses object oriented programming that says, ‘I don’t care how the class is built, just as long as its input and output are the same and meet basic security and programming best practices.’
The half not true is from the architecture and long-term maintenance approach that says, ‘We need to have common patterns on how we are building most sections of this system.’ This will reduce long-term maintenance issues, help with coding collaboration, upgrade paths, and just make sure we are choosing some of the better (or best) platform level options (like better supported modules, etc.)
Clients and non-developers jumping to Drupal content types as part of specifications is a huge misstep It assumes one approach among many It assumes a client or non-developer has the knowledge and skillset to make the right system level choices during development It’s an area where dabblers should stay out of Letting our clients go there is just not needed and can really get in the way Note: It’s possible to build a content type, with a set of blocks, rules, taxonomy, and everything else, and still not meet the client’s functional specification The focus must remain on the need the technology is meant to solve I rather end up in Palm Springs at the end of the journey.
To meet the functional specification above, we can use any number of system level tools/ modules/ approaches Unless the client or the non-developer is fully up to speed and an expert on all the latest modules, tools, and techniques, then they should remain in the role of product owner, not system architect
Of course the client is paying for the project and has the right to know we are using best practices Beyond this, the client’s time is best spent at the functional specification level; reviewing, testing, confirming, and even further refining and defining functional needs
To continue to try to communicate what is going on here, let me explain a few technical ways in Drupal we might choose to implement the functional specification above
We might choose to make the News article its own content type, particularly if it is the only one using a certain set of fields (such as author attribution) We may also keep it its own content type to make it easier to manage permissions and section logic We may even just choose to do it based on the development team’s desire to manage each functional area within its own discrete feature module
If News articles share all the same attributes of a blog post, we may actually choose to combine these two content types into one (not likely but there may be a good reason that comes up during client build calls.) To do this, we might disregard ‘content types’ all together and go with Taxonomy terms that control the section placement and permissions We could use dependent field sets to show the author attribution field only when the content is tagged as a News article
These are developer decisions; as long as the impact of those decisions is not negative to performance or UX and will meet the functional specifications
After system wide patterns are generally established (when we have our typical modules and our overall approach defined), then the best time to make the final development implementation choices is at build time (during the sprint for the feature) Within the three months it takes for us to get to the sprint for this feature a new module may have come out which is the BEST choice of all If we are arbitrarily locked into some other choice or even conceptually locked in, then we lose our ability to be cutting edge. Dare I say, ‘Agile’; in that we make the best decisions at the time of implementation to best meet the client’s needs at that time ‘Providing the best value at the right time.’
I hope this helps explain why defining content types with clients or letting non-developers make development decisions is not what I consider to be an optimal approach It actually wastes time, makes decisions out of context, and turns over the developer area of expertise to clients who would not be coming to us in the first place if they could actually build the system themselves
If we absolutely must use the term ‘content types’, make sure the client understands it is used as a functional term and not a system level implementation term Thus a News content type should have x, y, and z fields (not Drupal field types but general fields like text field, date field, an image uploaded)
I have had a great deal of success with very large scale clients and project implementations I have also worked on enough large projects to easily see red flags Letting the client into the development kitchen is a red flag which at best leads to no good and at worse significantly hinders the project
Transparency = YES Let clients attend daily dev. calls if they desire Let them see code Schedule the weekly build call to demo for them the output of the past week Keep them majorly up to date on the sprint’s burn down rate and where we are on budget and schedule
Do not let them make development decisions and regularly question choices that are really out of their realm of understanding These should be deflected and managed by educating the client but not capitulated to.
Share or Comment via Twitter