Cleisthenes fathering modern democracy, James Cook laying anchor in Australia, Neil Armstrong setting foot on the moon and the COS Blog going online. These are among some of the greatest milestones known to humanity.
After several months of debilitating, arguing and discussing without producing results, the COS Blog finally made it into the public domain. This platform allows students of Content Strategy at the FH JOANNEUM to share their knowledge gained in the various areas of study, helping fellow students learn and advertising the cooperation element of the course to potential applicants. It hasn’t been an easy journey; there were no clear start or end points to this project.
Disclaimer: The “COS Blog” mentioned hereinafter refers to the Open Educational Resources platform created by students and teachers of the Content Strategy Master’s course at FH JOANNEUM. (That should keep Heinz happy).
The roots of awkwardness
The project of producing an online educational platform began, but nobody was entirely involved. Ideas of how content should be created were passed around, but nobody knew which platform should be used. The desire to target international visitors while creating interest in the German speaking nations was paramount, but nobody knew how to manage multilingual content.
I attended several meetings on the topic as content management and web development were interests of mine. The further these conversations progressed, I noticed an ever growing lack of understanding of the barriers which faced us. There was a clear focus on frontend content strategy, but limited acknowledgement of the need for a backend strategy too.
As a bug emerges from underneath a rock, I emerged to the forefront of the discussion, brining nothing but similar mess. While nobody really understood the necessity of having a defined URL structure for multilingual content in place before starting, or the complications of implementing a multi-stage editorial review process with user level restrictions, the look on my face made it clear.
The irony of this project: there was no content strategy.
I want it all, and I want it now
After agreeing to take on board the responsibility of creating this platform, it was clear that we were going to be using WordPress. It was the only recognisable CMS for the 70 or so stakeholders involved. Numerous attempts had been made to get the COS Blog up and running, but none had really sufficed to the standard required.
Taking the existing design and layout on board, it was necessary to get a productive version of the COS Blog online before anyone could blink. I made the issues of rushing such a project known to the decision makers, suggesting we rather take our time to do this right and on the first attempt, but the necessity to have a collective source of student resources online was the overwhelming deciding factor. Without visible content online, students would not be motivated to produce any further materials.
Within a matter of weeks, the half-baked WordPress installation was live. Nothing had been tested and the template being used was entirely incompatible with our desired translation management plugin, WPML. As soon as this was known, our options lay with either forgetting the production of English content, or carrying on with the project, but in the right manner.
Draw me like one of your French girls
The emphasis from the beginning of the project had been on content creation. I singlehandedly had to cater for the design of the COS Blog, as well as creating the backend for managing the content and users. Anyone close to my upbringing would confirm that I haven’t touched a pencil since the days of drawing in the back of my exercise books at school; they weren’t even masterpieces by teenager standards.
One of the greatest issues here was the lack of a designer, specifically a web designer. It became difficult to translate the necessity of having a final design before going into development. Firstly, simple features such as the appearance of the navigation can differ a great deal with regards to how they are implemented, and secondly, I knew that I would begin to develop features, only for the goalposts to be moved at a later date.
Thankfully, Anna also surfaced from underneath that same log; the log which protected us from working with a huge amount of decision makers; a large group which would be difficult to collaborate with due to the sheer size. Her input was truly appreciated however, producing wireframes of the final design which received the thumbs up for me to begin development.
Work, Work, Work, Work, Work, Work
Development ensued. Nothing interesting followed during these weeks. Coffee consumption was at a record high, with numerous hours invested in ensuring navigation elements stuck at the right scroll points and that WordPress URL rewrites didn’t cause pure meltdown.
There were numerous issues along the way. Due to the demands of the content and how it should be managed, there was a great dependency on several plugins. These included EditFlow, WPML and an RSS Aggregator. All of which are well-known and highly contributed to plugins, but any WordPress developer will cry at allowing such plugins to have such a great control of content creation.
As WordPress is a CMS based upon a file system with links to MySQL databases, there can be numerous issues with table values remaining from previous pieces of content or plugin installations. While I didn’t run into huge issues here, reinstalling certain plugins and seeing their previously saved settings repopulated within the backend led to some concern about stability.
It’s never actually “finished” though, is it?
This is most often due to error on the part of the developer and the client. As much as it pains me to break this news, it was my fault in this project.
The first priority is to define what the completed state of the project should be. In this instance, it should have been a content management system with a responsive and appealing design, with provisions for hosting multilingual content and an editorial workflow, as well as a stable base for future expansion.
If this had been defined and agreed upon in the very beginning, then I would have not agreed to invest time in the initial COS Blog, knowing that the work would soon be replaced by a final version. In addition, the final version should have been critiqued, altered and tested from a user experience point of view, prior to the release. Due to the pressure of having the COS Blog online, it is currently live without being tested in any of these manners.
As a result, the work will no doubt continue with minor alterations here and there for some weeks to come.
If you gave me six hours to cut down a tree, I would spend four sharpening the axe
There have been numerous lessons learned from developing the COS Blog, with regards to managing clients, managing the project itself and also from a technical standpoint.
The client needs to be informed of the technical limitations of a CMS. Whether this is with regards to the amount of customisation they need, or the dangers of “hacking” previous works, then this needs to be relayed. How this can be told to any client, regardless of their technical understanding, is however difficult to ascertain.
Technically speaking, a clean WordPress installation is always necessary. I have learned over the past months that developing on a local installation and migrating the database is not much effort at all. This will reduce the downtime where the customer’s site is offline and allows for securer development and experimentation, without the need for continual file server changes via FTP.
The greatest lesson learned from this project? How to manage yourself. Without clear deadlines defined as to what should be completed and when, I found myself working simultaneously on different aspects of the site and project. Not having a clear plan in advance of how my workflow should be constructed often led to traps where the development was in stalemate until I could discuss certain features with the client.
Involving the client after these numerous internal deadlines will reduce their stresses at various stages of the project. It will reassure them that the project is on course for completion, but most significantly, it will reduce the chance of producing a finished project, only to hear the words: “Oh, can we change this…”
To be continued…
What next? If we disregard the imminent breakdown of the current WordPress installation and it’s already overweight database, then it is primarily focused on server and user optimisation.
These are stages which should have been completed after a usability test of the COS Blog, but considering that wasn’t done before completion, then the first step would be a desktop and mobile user experience test. This would provide ideas as to how the content could best be delivered, especially considering the upcoming public rollout of Facebook Instant Articles.
If content will continue to be produced at such a high rate, then there needs to be an automatic notification workflow for the various key parties of the editorial process. This will most likely be tied in to the custom post status we created, informing the relevant user once the status has been changed.
Finally, it’s all about the minification and caching of resources. But nobody wants to read about that, right?