The advent of Content Management Systems (CMS) has seen the usage of computers move from handling data to handling content. So, what is the difference? Content is data with a context. The same data can mean different and differ in importance depending on the context. e.g., a temperature of 29oC can mean hot or cold or normal depending on which place we are talking about. We, humans deal with content and knowledge rather than with data. The challenge with computers though, is that they are built to handle only data, and not content. We have to disguise, repackage, wrap data for creating the content.
I was part of a team creating ManojKhatri.com, an author network. Work on it still continues, but the first iteration is complete. WordPress was specifically selected for this because of its capabilities.
One of them being classification of posts into multiple categories and even heirarchical, which was required for our information architecture. It was identified as a specific requirement that some of the articles would be earlier published in a publication. The articles would be written on diverse topics and of multiple natures, e.g., fiction, interviews, columns, etc. It was also decided that the users should be able to access the article by any of these aspects. This is where we have used the feature of multiple heirarchical categories of WordPress. As you can see on the website, multiple top-level categories called Editorial Type, Publication and Topic were created. They in turn had other categories under them. But this allowed the user to choose the aspect he/she wants to read articles by and then choose the specific categories. This also provided us another benefit that it enforced the author to choose from existing categories. The top-level categories are an indication of what aspect of the post the categories under them represent, they provided a context to the user for the underlying categories.
The other solution we had was to create any of these aspects as custom fields of the corresponding host. This would mean that WordPress would not automatically give us the list of the different topics, editorial types or publications. This would also mean that extra validation would have to be done to restrict the author to certain topics, editorial types or publications. Considering these factors, we chose the former way.
By design, a category in WordPress is a group of articles, which allows me to get all the posts under a category without looking at details of the post. Whereas, the custom field is an attribute of the post, and would require to know the post identifier.
Ideally we would have preferred to create datatypes of each of the aspects – editorial type, publication and topic. However, as I have written WordPress allows, but does not inherently support creation of different datatypes, we would have to create everything related to that datatype. For this iteration, this approach not only saved us lot of time in implementing the content classification but also made it convenient for the user and the administrator. Feel free to comment on this and give suggestions.
Copyright Abhijit Nadgouda.