Didn’t We Always Know About Amazon Being Awful to Work For?

Today the twitterati are all abuzz on about the NYTimes article about the Amazon workplace. I’ve been reading how folks are now facing a moral dilemma about supporting Amazon with their prime memberships. I read all this and I wonder why this outrage is present given what we’ve known about Amazon workplace ethics since, well, at least 2011. A cursory Googling uncovers the following:

 

There were some rumblings here and there after this information surfaced about the conditions of the warehouse workers at Amazon, but nothing like the groundswell that caused many of my educated liberal friends to leave WalMart (rather vociferously, I might add) following exposés about its treatment of workers. Yet, today Twitter is lighting up with links to the NYTimes article, and Jeff Bezos’s swift PR move in its wake. And we have a USA editorial piece where the writer is now having a pang of conscience about his Amazon Prime membership.

I can’t help but feel that myself, and my contemporaries, are displaying a special kind of hypocrisy in our outrage. We cannot imagine that the dystopia of the mechanized workplace could possibly extend to the world of the white collar tech worker. But what in the world would make us think that a company that treats its warehouse workers like disposable commodities would not extend this treatment to its office workers as well?  Is the outrage today based more in our bruised, narcissistic projections rather than any true empathy or desire to make the world a better place for all workers? I mean, as tech professionals, we DESERVE better.

If any of us had a conscience, including myself, we would have cancelled our Amazon prime membership somewhere in 2012, after the Mother Jones piece, or even in 2014, after it surfaced that Amazon contracted with Woody Allen. No, it takes a full-blown NY Times article about the educated, white color tech workers to gin up our sympathy, and even then, some of us will sit back and tell ourselves that we are morally superior for eschewing Black Friday in favor of Cyber Monday.

Amazon is simply WalMart in an internet package: A large logistics organization that values volume and speed above all. Every time we press a “Click to Order” button on Amazon, we are no better than those folks pulling into the WalMart parking lot when they can afford to shop somewhere more fair to its workers. Online retailing sanitizes that experience for us.

The internet at its best is a place to connect us to what is real and true about people and places we could not discover otherwise. It is a place to see our own humanity in others, and learn to do better. I fear that, in a case like truly behemoth online retailing, it has served only to distance us from that very humanity it can help us to claim.

It may indeed be time for us to examine our conscience about how we “do” the holidays cyber-wise. As those months approach, and I see my Amazon Prime membership come up for renewal in November, will I, and my contemporaries, have the courage not to click that button once more?

 

What I’m Learning about Higher Education and WordPress (Now That I’m Not In Higher Education Anymore)

I learned WordPress over a period of nearly 10 years within the bowels of public higher education. With a scrappy team, some elbow grease, and good humor, we did some pretty cool stuff with scaling WordPress as an enterprise-level content management system. I learned from working with some genius ed-tech folks at the University of Mary Washington as they scaled multisite into a respectable alternative to locked-down learning management system. I learned from a kickass WordPress developer (also at UMW) about plugin development and the implications of developer choices one makes in the larger WordPress environment.

The lessons I learned there are invaluable to me, and I don’t think I would have learned them in the private sector. These lessons were:

If it’s easy to use by your least-skilled staff, the site will grow.

We had all kinds of editors and authors in our systems. Some were long-term staff with few technical skills. Some were curious faculty. Some were technology-savvy. Some were eager to learn students. The web authoring tools had to be usable by a very diverse and large audience of users that you normally need not support in a business environment where web authoring can be more centralized.

Don’t buy a premium plugin, theme, or framework unless you plan to commit to it

The advent of premium themes and plugins arose over the past decade as developers saw gaps in the core that could be somehow monetized. In higher education, you rarely have enough development staff to build everything. So, you have to weigh at all times, on an ongoing basis, when a requested feature can be built, installed from the main repo for free, or bought as a premium plugin, theme, or framework.

This lack of resources, both in terms of staff and money, makes you develop an eye for the kinds of plugins to use, which ones to watch out for. Arriving at the point of “we’ll just have to pay for it” means you have to go through some labyrinthian purchasing process. In the case of public institutions, you’re paying with everyone’s tax dollars and student tuition dollars, so you’d better justify the expense.

The resultant sense of accountability and responsibility becomes ingrained. I think had I been part of a “money is no object” culture, I would not have tried to hone this skillset.

Collegiality is Primary

The usual bashing that occurs among developers about “other people’s code” happens in higher education, but when it does, it does not work well. You are all working towards a common cause, and no one’s there to look good at another’s expense. When that kind of thing happens, the negativity can really damage teamwork and can slow progress. I learned that I can learn from anyone, even the folks that I didn’t like very much, because I simply had to try to get as much out of my interactions as possible in order to get the job done. The friends I made in higher ed technology are friends #4life. The collegiality of the higher ed development culture is a model for how open source can work.

Oddly enough, the most negativity I had working on a project in higher ed was when I was working within a proprietary .Net framework. The developers on that project took the word “proprietary” at its most extreme meaning. There was no sharing, explaining, learning, teaching. Higher ed culture, on the other hand, is tailor-made for open source thinking. Share it, bork it, fork it, whatever. We’re all in this together.

Higher Education Contributes Mightily to Worldwide WordPress Adoption

15 years ago, college students had to learn MS Office to get a job. These days, they need to learn to work on the web, and many are learning through WordPress. At a party for my new job a few nights ago, I mentioned I was a WordPress developer and was bombarded with questions about WordPress from a few folks who were relatively recent college grads. They wanted to know how to start a WordPress site of their own, how to learn more about it and get good with it. They used WordPress when they were in school, learned how awesome it is, and it is their reference point for how to make a good personal website.

I’m thinking of writing a corny impulse-purchase book entitled “Everything I Need to Know About WordPress I Learned Working in Higher Education.” I won’t. I’ve had dozens of ideas for impulse purchase books (like rating restrooms on major highways by the number of “bowls.” Actually that was inspired by my Dad’s rating system after each rest stop).

This morning in my brand spankin’ new private sector job (which I’m loving), I had to submit a list of requests for purchases for WordPress add-ons to a system I’m now managing. My list included prices and justifications, and came out of learning how to make these analyses through being so scrutinized, and having so many conversations and failed implementations (or learning opportunities) over the years in an environment that required open communication. It was a surprisingly small list — there are few things you need to buy to get WordPress really going for any client. Buy too much, and the cost of backing out can be days of work (someday I’ll write about my disasters in scaling SlideDeck and Soliloquy, but not now…).

The purchasing agent at my new job thanked me for being “so thorough.” I had to laugh — I didn’t do anything extraordinary. But I’ll bet I would not have submitted the requests that clearly had I not walked through the stunningly diverse, complicated, multifaceted world of higher education web development before landing here.

Proving that higher education does not educate only the students but, everyone who works there. So don’t tell me it’s dying.

Friends4life

Jim Groom, Tim Owens, Martha Burtis, Andy Rush, Jerry Slezak, Alan Levine, Ray Nedzel

 

You’re Killin’ Me with the Dragging-and-the-Dropping Already!

I’ve inherited a WordPress site that uses a paid-for plugin that enables “drag and drop” layout changes by the end user. I cannot fault the developer, and don’t like to play that game. The client requested the ability to change layout without coding, and the timeline/fee structure probably led to this as a quick way to provide that. I know that right now, someone’s nose is in my code while they are thinking, “What an idiot!”

So, this is not a slam on the previous developer. It is, however, an inquiry as to why “drag and drop” for WordPress remains this elusive dream tried by many, but has yet to be made part of core.

Here are a few issues I’ve encountered that make me not really like half-baked drag-and-drop tools for WordPress. I can be persuaded otherwise — I just enjoy complaining.

Your Drag-and-Drop Plugin Ages Out

If you’ve used WordPress for any amount of time, you know that switching out plugins as some age and are no longer supported (or no longer work with current WP versions) comes with the territory. It’s the price of doing business with a codebase that’s more organic than Drupal’s (don’t get me started…). When it comes to drag-and-drop WordPress tools, deactivate them, and you risk riddling your page with shortcodes.

Visual Editor Borks the Shortcodes

Frequently, drag-and-drop tools require that you use their editor OR use the “text” editor. If you use the Visual editor, WordPress can wreak havoc on some of the layout. Purists will tell you to disable the visual editor, and I get that. But, WordPress is for the kind of audience that relies on the Visual Editor. The Visual Editor is at the core of any blogger’s, or content manager’s, usability. Any tools they use need not to bork when the Visual Editor is deployed.

Layout and Content Become Tied Together

One of the cardinal rules of the open, semantic web is to not mix the peanut-butter-and-chocolate of layout and content. In its pure state, WordPress strips out extraneous layout code when content is published, leading to much frustration on the part of users, and some usability issues. Indeed, I’d like to see more ability to add and preview theme classes to within the core Visual Editor so the editing experience can be more useful to the end-user.

But, drag-and-drop tools that add (invisibly) extraneous markup can, in turn, undo all the work that a good developer may have put into SEO, semantic markup, HTML5 compliance, and responsiveness. Indeed the site I have inherited now is SO driven by this tool that the pages have no consistent “h1″ title tags at all — lots of classes and bolding though, and it looks really spiffy on the desktop version :)

Add to this that I’m working in a managed host (“Pantheon”) where data can only go one way, and never into production from testing. That means that detailed layout information, stored as data fields by these plugins (but normally stored in the theme and widgets), can become broken unless the work is carefully, manually edited and previewed in production. This is not a good thing at all.

Enter VelocityPage by Mark Jaquith: Problem Solved(!)(?)

Because of the limitations in the native editor, and because of the messiness of drag-and-drop page builders, it feels as though this notion of frontend drag-and-drop editing for WordPress is still elusive.

But, there is a new plugin by Mark Jaquith called VelocityPage. The promise is that it adds only pure, semantically-sound markup that won’t be riddled with shortcode should you want to, down the road, disable it. Or if Mr. Jaquith decides to retire, or leave the world of WordPress altogether :)

I want to try it but I loathe that there is not a trial version — only a demo that doesn’t seem to work very well in Chrome. So, I have to pay $97 for the privilege of seeing what it does to my markup, and my data, which makes me kind of angry. And if it doesn’t do what I’d like it to do, then I’ve spent the money for no good reason.

So, has anyone who cares about things like semantic markup and graceful de-provisioning of plugins, tried VelocityPage and like to share their thoughts before I plunk down the $97? I’m all ears.

Shifting Professionally, Growing Personally

I am exhilarated about a big change in my career. After spending 15 years in higher education web development, I am returning to the private sector, taking my WordPress skills with me. But, the paradigm in which I’ll be developing for the web is far different from what I’ve been working in. I have a chance to redefine where I want to put my focus as I embark on this new adventure.

Much of the work I’ve done has been in the area of facilitating the ease of use for the end user to create and manage content while standardizing the design interface for large web systems. What got sacrificed in that mix was the ability one has to create truly beautiful design, to keep abreast of the latest trends and work towards excellence.

I see the work I’ve done as bringing the value of scale and flexibility, and that has been worthwhile. But, I am ready now to dive deeper into the design end of things. How this will manifest is likely that I’m going to get a lot better with mobile first design methodologies, become much better at javascript, move away from the crutches of expedience (like my beloved Genesis framework) and more into pure development just for the joy of the code, the design, the experience.

This is what happens when you move from managing networks of hundreds of sites, with dozens of web administrators, into managing a single site with only one manager. I am excited that I can move on with the lessons I have learned and grow as a designer and developer.

As much as I’ve absolutely loved so much about working in higher education (especially being around all the smart people!), I won’t miss the lack of resources and the need for too-small staff to wear so many hats that everyone feels unappreciated. I won’t miss settling for (to me), mediocre solutions that were the best I could do under the circumstances. I won’t miss the lack of advancement possibilities and the ubiquitous faculty/administration upstairs/downstairs culture. I am sure that where I move will bring with it a new set of political realities, power struggles, and personal challenges — every workplace does.

But, all the same, I just can’t wait to get started!

Code Does Not Forgive

Stepping down from being a manager of developers to the role of a developer, I left a world of broader ideas with fuzzy edges and entered a world of sharply defined rules. Code is not a concept, it commits in real-time to whatever it’s told to do. When it doesn’t work, it tells you. When it does, there is no fanfare. It just does the job.

Code has no context. It does not “get” that it’s doing something new, or something with broad implications. It does not ask why. Code goes ahead and executes. The only code that asks if you are sure is a code that is written to ask if you are sure. Something as cheesy as "onSubmit="javascript:alert('Are You Sure?');" usually does the trick. Otherwise, code assumes that what you’ve told it to do it will do with no take-backs.

I’ve been watching this new trashy and silly, but entertaining, TV show mostly because it stars an old friend of mine. It’s called “Almost Human.” It’s a near-future world in which police now recruit robots as partners to team up with humans. There are two models. The current models, the MX-43, are like code. They are programmed for the task of fighting crime, and do not ask why. They ask permission only if protocol demands. Otherwise, they follow the letter of the law, which can have uneven results. The law, as we know, also has a spirit.

Enter the older model, the “DRN,” affectionately called “Dorian.” These were programmed with an algorithm called “synthetic soul.” Synthetic soul presumably contains all the “if/then” possibilities for human emotions. It was found that the Dorian’s had too much feeling to do the job, too many emotions, so were scuttled in favor of the newer models that strictly follow protocol. (There are no doubt myriad feminist treatises that could be derived from this conceit, but I digress.)

Due to a shortage of newer units , one of the Dorians, which had been mothballed, gets recommissioned as the partner of a cop suffering from PTSD. It is arguable which of the two is the protagonist, and which is the one with better judgment. Dorian is far more handsome and compassionate than his partner (and, I must say, a better actor by a long shot). The very fact of entering into his character as a subject, rather than a very shiny and amazing object, is a testament to the power of the code.

But at its core, it’s code, and code goes where we tell it to go, with algorithms that merely potentiate actions like infinite fractals emanating from a core pattern of our making. Whether we like it or not, however fancy the output is, it’s still code.

I had an experience this week that reminded me of this cold world of code that I now occupy. Nothing so glamorous as Dorian having an anxiety attack in a public square due to a depleting battery, but something that reminded me that I’m not in the Kansas of “big ideas” anymore.

Add to it that I now work at a school of medicine (The MX-43) where I spent over a decade at a college of liberal arts and sciences (Dorian). Schools of medicine are another culture altogether. A highly mobile faculty that is tasked with teaching students and conducting research, all while caring for patients in a large medical setting. These are people who at any point in time have so much on their plates it’s hard to comprehend. Add to it that, on top of FERPA regulations, IT systems have to live within the strict confines of HIPAA regulations. Notions of abuse of email, what information can go where and who has access to it, as well as the crossover between the academic and patient care mission, can lead to unbelievably complex technology scenarios.

As a result, what comes in an email has large implications here. Folks have been trained and warned about use and abuse of email, and faculty don’t want to have to parse what’s good email from what’s malicious. The stakes are kinda high.

So, when a developer (let’s say, for argument’s sake, it is I), is implementing a new mailing list API (“It works! I’m thrilled!”), and neglects to change default code of "$optin = true;" to "$optin = false;,” results are instantaneous and stressful: 3,900 unwanted emails go out to the population of highly stressed and highly trained school of medicine faculty and staff.

In the world of big ideas, the difference between true and false can be argued for hours, depending on your discipline. The arts and humanities play with true and false along on its palette of a million social constructs begging for deconstruction. Dorian would have tenure.

But here, I feel that I need to learn how to think like an MX-43. More native developers do this as if in their DNA, but I’m learning in my old age to carve out a synthetic anti-soul so as to enter a world of thought where things act as they are designed and there are no unintended consequences that are not programmed into it to appear unintended.

This type of thinking so does not come naturally to me. I expect my excitement about the code to matter to the code. I expect it to be my friend, to know what I meant.

But, the code does not care. It does what it’s told. And the code does not forgive.

PETA and the Trouble with Social Media Campaigns

In case you haven’t seen, PETA shot itself in the foot this week with a social media campaign aligning Martin Luther King, Jr. with the cause of animal rights:
Peta

It included, among others, playing the “Hitler” card with this gem:

pig
Originally posted at peta.org.

 

Needless to say, the backlash has been fierce. Likening the cause of basic human and civil rights for humans with the cause of animal rights by co-opting a loved and murdered leader can make people a little angry. Apologists will defend the intention of the campaign but, unfortunately, the horse is out of the barn, and good intentions have ambled down that road they paved to their inevitable destination.

It’s certain that no one meant any harm here, but social media campaigns have a way of backfiring. It’s one of the reasons why I would like a discussion of how social media is used to promote the activities of institutions of higher education.

I have long been a proponent of social media that comprises the aggregation of academic activity within the institution in service to engaging in discussion with those outside the ivy walls. Such use of social media, if enabled and promoted by those who manage the institution’s reputation, can lead to deeper discussions and further the image of an institution as a place of meaningful dialogue that is sorely needed in our society. I had a unique opportunity at the University of Mary Washington to further this since so much of their academic activity is exposed to the world via UMW Blogs and Domain of One’s Own.

But most other institutions are not so public with their academic dialogue. The majority of those in my profession adhere to the notion that we need to craft social media campaigns, using Twitter and Facebook as essentially streams for sound bytes and nice photos. Authenticated and locked down LMS’s and MOOCs and fears of intellectual capital imbroglios leave other institutions, by comparison, with fewer publicly-available resources for engaging in dialogue. 

What happened with PETA is an illustration of how, when social media, which began as a way of individual voices being networked (one-to-many) can become strained when the individual voice is not an individual, but an institution (or its brand). When I speak as myself, I don’t drag the institution down with me. I become one of many voices, and the aggregate activity of those in my institution can be judged writ large, not based on one person’s reaction or opinion. When an institution uses social media in this way, it can come across as glib and thoughtless. Or, in the case of higher education, too safe and artificial.

Higher education, if done right, should stimulate new thinking, provoke reaction, generate conversation, lift the human spirit. It’s a messy affair, which is why social media can be such a great place for it. Social media, in its very architecture, is messy, prone to chaotic activity, lacking in any real rigor or structure. When well-meaning campaigns enter into the fray, they can feel like your parents just walked into the room and asked a dumb question trying to get with the kids lingo. What may have seemed like a great idea in some ad copy becomes jarring, and subject to a different kind of interpretation. You become “the man,” and as such, subject to all the derision and distrust that comes with that territory.

Context is everything. If you are using social media as an institution to provoke emotions, as you would a “controversial” ad campaign, or self-promote, as higher education has a tendency to do, don’t be surprised if social media comes back to bite you with what it does best: cry “bullshit” in a very public and collective way.

Higher education began as dialogue (you know, the whole Socrates thing). I worry that we have become, instead, institutions that market our meaning to people, instead of engaging in dialogue that gives meaning. In so doing, our watered-down and overly-considered public presence has lost the essence of what made us meaningful to begin with. If we appear irrelevant to people enough to be discussing our own demise, that one is on us.

Reshaping Higher Education Digital Communications for the Mobile Age, Part 2: Tactics Aren’t Strategy

The issue of digital communications strategy is a tough one in higher education. Most products and services geared towards web development, search engine optimization, conversions and the like are geared towards commerce. That is, a successful web effort results in yielding greater market reach and more sales.

Higher education is not so simple. Our web sites and digital marketing efforts support so very many aspects of university life that an overarching strategy is difficult to come by. Is it athletics? Alumni? Admissions? If so, is it graduate admissions? Undergraduate? Oh, and don’t forget parents. Is it Student Affairs? Emergency communications?

The fact is that a simple, one-dimensional strategy is insufficient for an online environment that is not simply a lead generator and sales portal, but a living environment that people inhabit day to day. Thinking through the ways people use the web in a MOBILE environment is even more complex because mobile is about immediate/personal/transactional vs. browsing/reading.

So, where to begin?

We usually begin in the middle. We do this as a matter of shorthand because the issue is so very large that we have to start somewhere, and that somewhere is usually determined by the skillset and experience of the person who is in charge of the environment. If you are a developer, it will be choice of a CMS. If you are a marketing or communications person, it may be the choice of a web consultant or the hiring of a social media director or holding focus groups. If you are a designer, it will start with wireframes and redesign discussions. We generally begin within our comfort zones.

Strategy stretches beyond our comfort zones to more fundamental questions. It asks not “how” so much as “why.” It’s the why that takes you into new places that you may not have considered, helping you to prioritize what you are doing and why. Surely, all of the approaches above are valid answers to the “how,” and all yield bounded results (a new website) that will comprise arguable improvements to current environments. But changes made from these types of tactics, vs. larger strategic goals, will inevitably turn old within 18 months or so and require not iterative improvement, but complete overhaul because the “how” as a driver changes so rapidly.

I’ve lived this more than once with more than one complete University overhaul of a web environment. In 2011, we launched a new website for the University of Mary Washington that is still live today. Without a doubt, the design is a vast improvement over what was there before (which I designed in 2006). But what spurred it on was a mandate from the top that we have a website redesign. It was literally written into the strategic plan. Still, nowhere did it state why this was a priority over, say, more resources for online learning and the like.

So, what we did was, very efficiently and effectively re-designed the website to look better and more current, and then the print communications folks created materials that worked in harmony with it. But, the overall architecture of the site was not questioned. Once it launched, the age of mobile and responsiveness arrived and, from a technical perspective, it fell behind the curve again. And because the mandate was to re-tool nearly 10,000 web pages in a confined period of time, not a lot of time was devoted to re-thinking the content. We migrated old static content to a new container, and the project was done.

What a lost opportunity in retrospect. Because the driver was the a priori tactic of “redesign the website” we missed the larger conversation about “rethink communications priorities” and then build a digital plan into that.

The sisyphean nature of these large, cyclical website redesign projects takes too many resources to not want to not simply migrate content and unify design than to look, very critically, at what all of these online environments do, whom they benefit, and how those benefits support strategic goals for the institution.

The desire for a new redesign can be driven by internal audiences who simply grow tired of the old design. That’s understandable, but do you really want to spend a lot of money so people who are tired of looking at something can feel momentary delight in something new? If you are faced with an aging web presence, here is a better way to go about it:

  • Embrace iteration: Think less about wholesale, comprehensive redesigns and more about small wins that will provide you with some lessons in what works, and allow you to build towards a goal incrementally and iteratively. In my current position, wanting to improve knowledge about and within the Department of Medicine amounted to discontinuing a PDF-formatted emailed newsletter to become a public blog that can be distributed widely via html email and accessed 24/7 outside of our email systems. Over 522 articles have been published in this blog over the past year, and the whole world can read up on the achievements of the faculty in our largest department. We are now poised to create others throughout the institution, including new tie-ins to MailChimp and methods to apply authentication on a post-by-post basis for more private content.
  • Read your strategic plan: If your institution is focusing on certain goals (admissions numbers, athletic recruitment, growing a graduate program, etc.) approach your initial iterative change by selecting the most critical of these, and figure out a strategy to address it.
  • Learn from your own work: Solve a problem, document the lessons learned, and see where the value came from. Then improve, repeat, and, in service to possible larger implementations, figure out how/when to scale your solution. In our case, quick wins we have gotten in our experimental WordPress environment have showed us where the gaps are in what our current web environment offers.
  • Wait on the consultants: Until you’ve done a bit of your own experimentation, and understand better what your resources are, you should not call in a consultant. Call in a consultant to help you with the heavy lifting once you know what you need to do based on lessons learned. If you don’t, you will have a beautiful product that grew out of the mind of someone who will not have to support it and live with it once the contract is up. I’ve seen that not work out well more than once. It’s not a print brochure, it’s a living thing, and the consultant does not have to live with it. You do.

In short, don’t jump into a redesign because internal constituents are tired of the aging website. Rather, be with the people in your institution in dialogue and learn from them what would better help them do their jobs, and what would better help support strategic goals. Then, and only then, should you begin determining tactics like mobile responsiveness, web vs. native apps, CMS selection, new media, social media, etc. All good topics, but not a starting point in and of themselves and NOT the essence of a digital communications strategy.

Reshaping Higher Education Digital Communications for the Mobile Age, Part 1

In my last post, I posited that web presentation/aggregation, vs. web publishing systems, are where we should be focusing our energies in higher education digital communications. However, I didn’t really lay out how I think this can happen, and certainly, dismissing the CMS entirely is a hard thing to imagine given how people have been taught to envision, shape, and experience, the web presence of higher education institutions, from the inside, and from the outside.

I’d like to flesh out this high-fallutin’ notion of APIs and aggregation vs. “content” worship and publishing. For my own clarity of mind, I’ll need to lay out a possible process for how to get there from here. In contrast to 10 years ago, when content management systems began to enable proliferation of content within a “web page” paradigm, we now have an embarrassment of web pages, with little to organize them save the good ol’ college try at information architecture embedded within seemingly intransigent legacy reporting structures that truly, and sadly, continue to shape higher ed web architecture.

Faced with this scenario of too much content, and too little meaning, clogging up the navigational works, how do higher education digital communications professionals reshape the online landscape to respond to the more personal/immediate/mobile web that our audiences now inhabit?

Last year, I did a five-part piece on Marketing and Higher Education. I’d like to start 2014 with a similar series of installments on how to wrench us out of these desktop-bound website monstrosities we’ve built and move us into the next big thing that higher ed sites need to inhabit: the web as a networked community. Over the next couple of weeks, I will try to expand upon the following points:

  1. Tactics Aren’t Strategy: If I hear one more person talk about strategic web development, I’m going to scream. By the time we have arrived at “we need to recreate our website” you’ve moved into tactics. How do we rewind the conversation to reframe exactly what we are doing in the digital space vs. building more websites as a fait accompli?
  2. Community is Key: We have enabled the creation of content, but still do so assuming a one-way street: publishing to the reader. The mobile world thrives on connection and community. What relevance have our reams of the endlessly scrolled, technology-enabled contentfest we call websites when they are carried in someone’s pocket? At some point, you have to examine the wreckage of content bloat and figure out which content stays and in what form. 
  3. Be a Friend: Internal stakeholders have pride of ownership in legacy content and in web presence. You cannot come in guns blazing saying “yes” and “no” to people and not be part of the culture of the place you inhabit. The process to create online community must be done within a community space. Don’t be the big “webmaster” (ugh!) in the sky. Be a resident, not a service provider.
  4. Follow the Data: CMS-bound content sitting there in static-land are causing folks to work too hard to maintain content while dragging down SEO. There are myriad data sources available on our campuses and off that we can access in service to this notion of publish less/aggregate more. Auditing your current CMS-published content will reveal much which is truly directory information, announcements, calendar information, maps, etc. There is also untapped activity on social media sites. How do we harness the power of the information that is out there so we can free our web administrators to publish only what is needed, in the correct places and ways, when it does not exist elsewhere?

Looking forward to expanding on the above ideas as I move into a new year where I’ll be grappling with all of the above. Meanwhile, I wish you a happy new year with this piece of my past: Guy Lombardo on New Year’s Eve, 1977. I watched the original broadcast, as I had every year with my folks on New Year’s Eve. Guy Lombardo, “Sweetest music this side of heaven.”

[youtube]http://www.youtube.com/watch?v=Q-ncPPArxEk[/youtube]

Kill the CMS! We are the World!

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!).

“More than just a website”

These are the words that President Obama has used in his talking points regarding the multiple technical problems of the new healthcare.gov website.

I feel for the team on that project, and this is not an indictment of them, or of the President, or of the ACA. Rather, I am stunned to see that the relationship between the public and the internet has so changed in the past 10 years that we actually conflate a website with the product it delivers. I see this as a messily promising change in how the public regards technology.

As a web developer, this strikes at the heart of a lot of what I do day to day. Where once we were called on to be “web designers,” now higher education web developers are being asked to develop deeper functionality of the type that used to be managed within closed mainframe systems: interactive forms, workflow, asynchronous and synchronous notifications, document management, etc.

Where I used to tell folks “that is not a public web issue, that’s an application issue,” now I seriously respond with tools that can hopefully meet business needs in a public web framework. Where the line between online websites and online apps used to be drawn at this deeper kind of functionality, now I prefer to draw it at the line of institutional data.

That is, if an app requires the use of FERPA- and/or HIPAA-protected data, it belongs with the folks who manage those secure systems. However, if an app need only provide functionality outside of a secure data framework, today’s higher ed web developers have a lot more on their plate than we did a decade ago, producing “brochureware” that mimicked our institutions print communications pieces.

As a result, institutions (including the federal government, it would seem) need to acknowledge that web hosting is no longer a static service, and that data is not worth anything if it can’t be accessed and manipulated easily within a web framework. No doubt the healthcare.gov backend systems were not up to the task of rapid outward-facing web deployment, which in older systems was always an afterthought.

If nothing else, this current debacle makes the issue of open data and data security within a web framework front and center in the technology conversation. I’m anxious to see what happens with our govermnent-vendor-delivered products as a result of this debacle. I am also anxious to see if, in the aggregate, the need to be more fluid with all kinds of data will push the discussion of webservices from its current stalled and overly-specialized state (IMHO) deeper into tools like WordPress so that end-users can take advantage of this website-as-app culture that has come upon us. WordPress uses JSON, but there are not many good tools for end-users to understand and deploy this open data framework as of yet — only the most seasoned developers can unlock them.

All in good time. For now, the notion that the public can view a website AS the product (and not merely a representation OF the product) is good news all around (unless you have to use the healthcare.gov website, I suppose!).