Everything I needed to know about web development I learned in a session of an undergraduate class in International Relations. The professor said (I paraphrase): “The flaw of U.S. foreign policy is that it always addresses the previous problem.” Foreign policy plays catch up with the disasters of the past. So we have things like the Marshall Plan after WWII, which sought to avoid what happened to a bankrupted Germany after WWI, and the Patriot Act, which seeks to prevent 9/11 after it happened. Meanwhile, things move on and it becomes like a global game of whack-a-mole.
So it is with web development. As an in-the-trenches web developer now, I have to keep my eye on the ball of making code within a paradigm that I am given: The implementation of a content management system (in my case, WordPress). Trouble is, as I happily code along, things are moving fast and furious on the web and the entire notion of the CMS as we know it is, in my opinion, rapidly becoming obsolete.
To deconstruct, let’s talk about what a CMS is: A CMS is a system that allows a group of unrelated people within an institution to create and publish content to the web, usually with the intention of standardizing the web look and feel among them, and to a certain extent standardizing navigational schemes, so as to present a unified appearance of a single interface published by a single entity. Its importance in higher education was to the marketing folks who wanted to present a single brand within a culture that had a history of distributed expression and, by extension, web publishing.
In the early 2000s, the CMS solved the then-problem of disjointed-looking websites that arose from ad-hoc html publishing within companies and institutions. They came along to control the chaos that was the web at that point. The central issue was that when you went from one university department site to the next, the change in design was up to the whim of the person managing that site. The user experience was dreadful as there were frequent dead ends and the constant need to use the “back” button to navigate out of a website back to the institution’s site.
We still use the CMS to solve that 1990s problem of a disjointed-looking institutional website. But the web has moved on, and the look/feel issue of a desktop site is becoming less and less important within a mobile framework. So web developers talk about “mobile first” development as though that is going to solve things. What this means is that, within that CMS that is still the accepted paradigm, we develop our mobile look and feel first, and then build out to the desktop, privileging the mobile theme as primary.
This approach solves a logistical issue of how to stuff the 10 pound bag of full-screen web s$%t into the 1 pound bag that is the tiny mobile screen. But, by not changing the paradigm of how the content is PUBLISHED within the CMS, only how it is PRESENTED, we are not fundamentally moving the conversation along any further. So the bag of content continues to grow, and people are asked to read meaningless “About Us” and “Our Mission” pages, and view mindless responsive slideshows on their mobile phones.
Mobile is about fast access to information you need and transactions you need to make on the spot. Institutional content management for mobile does not need to empower the many to CREATE but rather empower the system to CURATE content that is now proliferating from many sources.
People all over the web are using Tumblr, Facebook, Twitter, Instagram, YouTube and similar platforms to publish content. It begs the question as to why universities spend so much money these days on tools to enable publishing when the tools are already out there. To add insult to injury, when institutional departments publish to their CMS-driven websites, they frequently re-publish the same content to Tumblr, Facebook, Twitter and the like. We even hire people to determine which content gets to be double-published to these platforms — we call them social media managers and now, apparently, every department needs one.
The rise of the social media manager in addition to a webmaster is a sign that things have gotten way out of hand, don’t you think?
I’ve written frequently in this space about my quest to avoid becoming an unneeded administrative expense that takes away from teaching and learning dollars. To that end, I cannot help but wonder how to get webmaster types to move the question along from enabling in-house publishing and re-publishing content to scrapping the CMS altogether and simply curating the content that our departments are already publishing to social media sites, re-aggregating that to a lean, mean mobile-first institutional site. Marketing copy and design can be the fluffy cherry-on-top of aggregated content for the old desktop crowd (read: the administration and high school guidance counselors), but the rest of the world (that is, the prospective student who’s on her/his phone) will simply get lean, mean, up-to-date experiences and, if administrative systems ever catch up, transactions like course registration and admissions applications.
This focuses web development resources on aggregation tools including APIs, and lets web developers continually keep ahead of the curve on where the content is coming from, going to, and how to manage it. It lets webmasters become not publishing-enablers, but content masters and who weave pieces of globally-published content into a whole that defines to the world what the institution means. It frees up TONS of money now used to manage large content publishing platforms.
I urge anyone who has NOT visited this web page to visit it. It’s created by a person called Kin Lane and he is a self-appointed API Evangelist. Kin is a person who inspires just about anyone to see the need to scrap content publishing as we know it and get in the game of content aggregation: http://apievangelist.com
Kill the CMS! We are the World people! Let’s show ‘em how it’s done! (Cyndi Lauper NAILED THIS THING!).