<!-- Content Here -->

Step right up and watch me change this page! Blindfolded!

Over the years I have seen well over a hundred web content management system demos. I have even done a few myself. But it doesn't take watching many demos before you notice that they all follow the same general patterns. "Watch me change this page." "This is how I find the content I was looking for." "Doesn't this demo website look nicer than yours?" OK, the last one is more implied than said. In this era of Web Experience Management, there are some new elements to the story. "See how this page looks differently to different audiences with different intents on different platforms?"

Don't get me wrong. I still get excited by the possibilities of technology that can show a visitor the perfect content in the ideal format. The problem is that achieving this goal assumes that the user knows what the perfect content and ideal format are. But we don't — not by a long shot. The best we can do is preview a page pretending to be a visitor; and that takes a lot of guesswork.

The missing element in this story is the visitor. That is significant because the visitor is the heart of WEM. After all, the "E" in "WEM" stands for the visitor's experience, not the experience of the content editor previewing the page. How do we get the visitor into the center of the demo's narrative? It is hard to switch back and forth between the visitor and the editor without making the demo appear choppy and disjointed. Besides, as I said earlier, we usually don't know as much about the visitor as we would like to.

Perhaps a better way would be to use data to represent the visitor. Having done demos, I know that showing transactional data (like web traffic) is a real challenge. You need to have lots of recent data to make the demo look realistic. This is why the analytics segment of a WCM demo usually falls flat. The demo environment usually just has a few hits — not enough to see any real trends. That said, wouldn't it be great to go through a scenario that begins with realistic visitor traffic data?

I could imagine a story that started in an analytics area with the identification of an under performing section of the site. Perhaps, you are getting search traffic on the wrong key words. Maybe a lot of people get to the page but then you loose them. Maybe you dig a little deeper and you notice particularly low conversion rates within what you thought was a high potential audience segment. At this point you could show how you reconcile audience segments between the analytics package and the WCMS personalization engine. That is, the CMS might have a "big spender" visitor profile, but how do you see that same population on the analytics side?

From there, you might validate that these visitors are seeing what you configured them to see. Going deeper, you might notice that "big spenders" are predominantly coming from mobile devices. You preview the personalized page on a mobile emulator and, BAM, the answer hits you in the face. The graphic that you thought would be so compelling to this group doesn't scale very well on mobile and makes the page unusable. Only then do you start editing content.

There could be many variations of this story but the key point is that the platform is helping solve the biggest obstacle to engaging visitors: understanding them. I would argue that unless you understand your visitors to this level, you shouldn't even touch personalization functionality. You are not engaging visitors; you are stereotyping them and then ignoring them. You may even be making their experiences worse because you haven't really tested what they will see. You are flying blind. What kind of business value is there in tool that facilitates unproductive tasks? I would argue less than none.

Small Deployments

Last week, when we released a new version of Lionbridge onDemand, I was reminded of a valuable lesson: keep your deployments small. Up to that point, we had been upgrading the production environment on a regular basis — nearly daily. When a new feature was ready, we deployed it. But this development iteration had some systemic improvements (new service types, enterprise features…) so we held off to release everything at once. That was a mistake. The problem was that lots of configuration changes had been building up (new settings, new libraries on the server, etc.) and that led to a lot more work at launch time. As you would expect, some steps were missed that compromised functionality. It wasn't a huge deal. Nothing was obviously broken. There were just some "Oh SNAP!" moments along the way.

Thanks to that reminder, we are back on schedule with regular code deployments. Some of the updates will be "under the waterline" — invisible changes to the underlying architecture to support visitor facing features that we are still working on. The trick is to keep the back-log of un-deployed code to a minimum. In addition to reducing the risk of the actual deployment, smaller upgrades make it easier to troubleshoot issues because there are fewer potential causes. For further reading on this topic read Eric Reis's chapter on Continuous Deployment in Web Operations: Keeping the Data On Time

. David Hobbs also has some great articles on this topic in relation to website launches. The one that springs to mind is Site Launches: do as little as possible. Also, to work in this way, it is also critical that you use a mature code management strategy. A couple of months ago my team adopted the Git Flow branching strategy and it has been a huge help.

People getting used to this model of product management will find it counter-intuitive. They see upgrades as risky, scary things and the natural tendency is to avoid them. But the more you delay an upgrade, the scarier and riskier it gets. And that creates a vicious circle. Even if you know and agree with the small deployment approach, it is easy to justify delaying an upgrade because you want to do one more thing. That is what happened to me.

Deployment Timing for a Global Business

Global businesses operate on a 24 hour workday. No matter what time it is, somebody is trying to get something done - whether it be a customer trying to interact with you or it could be an employee trying to do her job. This can make system maintenance (such as deploying new website functionality or upgrading some business application) a challenge. Of course, we do our best to minimize or eliminate the amount of downtime a deployment causes. In fact, my team regularly deploys new code across our applications several times day (yay, automation!). However, there are also deployments that you try to schedule outside of peak load. Perhaps, there will be brief periods when the system is unavailable or in an awkward transitional state. So the question is, when do you do these deployments? We look at three factors:

• The first thing we look at is the business calendar to make sure we are aware of any events that might drive traffic. For us, this could be a marketing campaign or, for our business applications, it could a peak in workload (like a deadline). It's a good idea to have a mailing list of primary users and announce upgrade plans to them. They will tell you if there is an issue with your schedule.

• The second thing we look at is daily load patterns. All of the systems that I manage are running on Amazon Web Services using Elastic Load Balancers so my favorite tool for this is a CloudWatch ELB Request Count report. That shows nice regular daily spikes of traffic to your sites.

• The third, and possibly most important, thing we look at is our own work patterns. While the load patterns may tell you to do your deployments at 3AM, don't do it. You could be tired and careless at that time of night. Plus, you will probably want to go to bed right after and that would be the worst time to be sleeping. Configuration errors usually take a little while to surface.  You don't want to wake up the next morning to find an inbox full of frustrated users who lost large chunks of productivity.

Using this logic, we typically find our best upgrade windows to be at unexpected times like 2PM Eastern on a Wednesday. During this time: most of Asia is sleeping; Europe is enjoying dinner; and most of the Americas is having lunch or in a post-meal coma. At this time, we have our full team on hand for testing and remediation if anything goes wrong. And we get to sleep well that night knowing if anything were to go wrong, it would have done so hours ago.

One caveat: this strategy probably won't work for you if you are delivering a high traffic service with a ridiculously stringent SLA. But if that is your business, you should probably have an around-the-clock, 3-shift dev-ops staff and lots of people planning and managing deployments.

Flexibility. It's a matter of perspective.

In my many years of collecting requirements for content management systems, I can't think of a single project where the word "flexibility" wasn't on the initial list of requirements. This "requirement" seems harmless enough. What could be wrong with the system being flexible? Flexibility seems like the perfect thing to ask for when you don't really know what you want. But it's a trap. Here is why.

Everyone who hears the word "flexibility" takes it to mean "being able to do whatever I want with the platform." But what that means depends on who you are and what you are personally capable of. For example:

• If you are a content creator, "flexibility" may conjure up an image of MS PowerPoint where you can make text boxes and pictures wherever you want on the page.

• If you are a web designer, you might imagine being able to edit pages as if they were static HTML where you could write whatever markup, CSS, or Javascript that you wanted. And every page could be a unique creation.

• If you are a print designer, you might picture editing one big image in Photoshop where you have precise control over every pixel and don't have to worry about annoyances like browser support or different displays.

• If you are developer might think about structured data that is re-usable and can be controlled by display template logic.

The interesting thing is that these expectations are usually mutually exclusive. The content producer's unstructured PowerPoint document is garbage to a template developer who whats to make global changes or adapt the display of the content for different contexts and audiences. The structured content model and display templates are inflexible to the content producer who doesn't know HTML and doesn't have access to develop and test code. An image produced by a graphic designer is a black box to anyone who doesn't have the source file and the right software to edit it.

And this is why everyone consider's their current CMS inflexible and tries to prioritize flexibility the next time around. But the process just repeats itself again and again.

The first step to breaking out of this cycle is to strike the term "flexibility" from the conversation entirely. Every time someone says the word, he needs to put a dollar in a jar. You can't move forward together if your interpretations of a word are diverging. After that, start talking about "balance of control" as in who controls what on the page. Stake out your territories. This doesn't have to be a land grab. Have mature discussions about control vs. responsibility and the ongoing maintenance implications of these decisions. Educate each other about your different perspectives. Talk through scenarios of what might need to change and who should need to participate in that change.

Most importantly, you should avoid thinking in absolutes like "flexible" or "inflexible." When you talk about balance of control, you are more likely to have productive discussions about moving boundaries rather scraping the whole system because it is "inflexible."

The Website is Launched, the Journey Begins

We have all been there. We launch a new website and, interspersed with general praise and appreciation, there are some hysterical complaints about trivial things like a word-wrap or a punctuation mark. The tone on these emails is similar to someone who just received their huge wedding invitation order and saw that their name was misspelled. They are mad and want immediate resolution to avoid mortal embarrassment on their special day. Ironically, it doesn't seem to matter that the old website was a total disaster. This site is new. It should be perfect.

If you are on the receiving end of one of these complaints, you know how easy the issue is to fix. You know it is nothing like re-printing 500 wedding invitations with gold leaf on expensive paper. You just edit the content in your CMS and republish. In fact, you fixed the problem in the two minutes that elapsed between receiving the urgent-flagged email and the frantic follow-up call. You also know that the content that is the target of the complaint has a shelf life of only a couple of days. In fact, you consider the entire website to be dynamic and constantly evolving. What you launched was not a bunch of static pages but new layouts, branding, and infrastructure to support your dynamic digital marketing program.

In retrospect, it is easy to see where the disconnect started. The internal audience for the site had not seen anything since they fell in love with the mockups. And the mockups were perfect — artificially perfect. The designer put in just enough text to make the layout look full, but not crowded. The PDFs that were distributed didn't depend on a specific screen resolution or browser. The audience was expecting to see those polished PDFs sitting in their browser on launch day; but what they got wasn't exactly the same. Add that to the fact that the web team appeared to vanish after the last site was launched and their anxiety is understandable.

How do we correct this? The number one thing you need to do is keep up the pace. You can't take a break after the new site is launched because that leaves the impression that the site is "complete." You know that launch day marks the beginning of a new phase of your digital marketing program, but if you act like you think your are done, you are bound to get into discussions with people trying to prove to you that you are not. The conversation invariably focuses on the site being "defective" rather than what it really is: a work in progress. Keep the site changing and be transparent with your road map. Regularly communicate with people who have ideas and update them on your progress.

Also, justify your decisions with data. When you relaunch a site, people will often look for their old content to make sure it is still there. If you removed it or re-organized their content, be prepared to explain why. The traffic was low, the content was redundant, the page was competing with more important pages on search results… these are all good reasons to retire a page. The fact that you can respond in this way shows that you are still engaged and moving forward in a thoughtful way. This will further re-enforce the idea that this is a journey and you are a competent and attentive driver.

Depending on your organization's culture and history, breaking out of a "print-final website" mindset might be easy or hard. Generally, the more web savvy your internal audience is, the easier it will be to change people's minds. The older guard will be more difficult to convince. Your line of reasoning should go like this:

Remember how perfect the last website seemed at launch? Well, it only seemed perfect because it was rigid. The designers got it just right and then locked it down through QA. But it was also brittle and it started to crumble from the moment we started to change content. New browser versions and platforms only hastened its decay. This new website is part of a program that involves continuous improvement. It will improve, rather than degrade, over time.

The key is to sell internal stakeholders on the idea that your website is a constantly evolving asset that will never be perfect but will be always be good (or even great). The site will adapt to changing organizational goals and audience expectations. Like the original meaning of the term "launch," putting up a new website should be considered the beginning of a journey, not the end of a project.

Related: Your Website is not a Project.

The "Moving Truck" school of project estimation

Estimation has long been a point of embarrassment for the software development community. A big part of that is unrealistic expectations set by association with construction and manufacturing industries. Software is unlike building houses and widgets because every software application is unique and unprecedented, whereas construction and manufacturing most often involve assembling well-understood components in repeatable ways. Truly innovative construction projects, like the Big Dig, and the Sydney Opera House, regularly overrun their estimates (by 3 times and 15 times respectively in these cases). They shouldn't be compared with building out a subdivision either.

A more appropriate analogy is a moving truck. If you have ever hired movers to help you move between homes, you know that the process starts by someone walking through your house and looking over your stuff. This person may pull out a tape measure a few times but she is not measuring everything and she is certainly not doing things like seeing if your ottoman can be neatly wedged underneath your dinner table. The real purpose of the exercise is to know how big a truck (and team) to bring on moving day. It is up to the movers to make the most of the space and there is a real art to that. Sometimes the moving team can see right away that the job is going to be a real squeeze and they think through every piece like a game of Tetris. But sometimes the truck is just too small, you need to call in another truck. Either that or pulverize your furniture into very compact dust.

The main point of this analogy is that precise software estimation is impossible at the detail level. It takes people who have done lots of projects to give a decent "truck-size" estimate, and even then they can be wrong. In fact, each task estimate will likely be wrong. Accuracy is achieved only at the aggregate level when the underestimates cancel out the overestimates. Just as important, an experienced team will be quick to identify the need to adjust: either by increasing the scope (size of the truck), by leaving low value items on the curb (decreasing scope), or by changing how things are packed together. The earlier you are aware of your constraints the more options you will have.  Only inexperienced teams wait until the truck is full to realize that some adjustments need to be made.

Related: Work Breakdown Structure vs. Deadlines

"Tell me about your setup"

Finding excellent technical people is a constant challenge that I struggle with every day. The traditional recruiting process of searching résumés for keywords has been broken for a long time. You need to use clever techniques like my "One Field Job Application" and engage in various communities to find people who are passionate about their craft and want to do great work.

Interviewing candidates is even harder than sourcing them. You don't want to waste anyone's time (including your own) but you also want to get a real feel of how someone works. Developers who work on large teams are particularly hard to evaluate because responsibilities are often ambiguous. It takes a while to learn that a candidate had a really mundane role on that very interesting project on the résumé or that he/she didn't have the professional curiosity to learn about what other people were doing.

Some recent experiences are leading me to believe that the ideal technical interview question is "Tell me about your setup." While the tools that people use may at first seem mundane and subjective, I am starting to believe that tools are a reflection of the attitude a person brings to his/her work. This theory was originally inspired by the site UsesThis, which contains personal descriptions of the tools that people use. The people that submit their setups are clearly passionate about their work and pay attention to the details. Most importantly, they identify with their work — and that is critical to the type of commitment that leads to greatness.

I am not so interested in what the tools are (although I am starting to see some interesting patterns that I might share in a later post). I am more interested in the why. If an interview candidate starts to light up when explaining why she loves to use something, you know right then that she loves her work and she loves being good at her work. This is especially true for people who like tools that require some dialing in but have incredible power. Users of these tools have proactively invested their time to get better at something. Contrast that with someone who is indifferent about his tools: who just uses what he is offered; who likes a tool because it has buttons that you can click that does things that he doesn't understand. To me, that is a sign that I am talking to a drone that is satisfied with the bare minimum. His passion lies elsewhere or doesn't exist at all.

Passionate professionals who care about their craft don't just make a team more effective, they also make work more fun because passion is contagious. When you see a colleague doing cool things, you want to learn from them. You are also inspired to raise the level of your own work. When your peers are just going through the motions, it has the opposite effect. You de-personalize and get cynical and start identifying with Dilbert.

Drupal not listed as an alternative to Wordpress

Anthony Myers (@xanthonysfx) , from CMSWire, recently posted an article listing "Five Alternatives to Wordpress." His list was really interesting. First, he openly left off Drupal, putting Plone there instead. I really like Plone but I would have to say that Drupal is a much closer analog to the core functionality of Wordpress. The projects even have an ongoing rivalry with each other as shown by Dries's April Fools post "The Red Press of Drupal" where he announces that Wordpress is moving onto Drupal.

Second, the author didn't include blogging products like Expression Engine, MovableType (which, I hear, is improving), and SquareSpace. The products that he listed (Adobe Business Catalyst, Plone, Typo (I have a feeling Anthony meant Typo3, not this relatively obscure Rails blogging platform), Umbraco, and eZ Publish) are all traditional, page-oriented (as opposed to post-oriented) platforms. This shows that Wordpress, at least in Anthony's eyes, has grown out of its blogging roots and readers would be considering it for traditional web content management. I would have to agree with Anthony on this.

The third interesting thing about this article is that the various software communities didn't flood it with comments and other reactions. I would at least expect the very large Drupal community to dive in and lobby for their inclusion. Maybe the link-bait title of this post will change that. :)

How frequently should we update our homepage?

I recently overheard a discussion that should have gone extinct years ago:

"We try to update our home page twice a month … you know … to keep it fresh"

In my early CMS days I used to hear this type of thing all the time when people were trying to justify the need for a CMS by quantifying how much they edit the site. Even then, I thought the idea that people would be pleased by homepage "freshness" was a quaint little fantasy. In the real world, nobody who matters cares about the fact that a home page has changed. The absurdity of the idea is reflected in this Onion article "Man Cruises By William H. Macy's Website To Check Out The Latest" (hat tip to Deane Barker for mentioning it at the Now What Conference).

There is only one reason to change your home page and that is to make it better. What do I mean by better?

• More Current

  Obviously, you don't want to have any outdated information on the homepage. If you were promoting an event, you want to replace that promotion when the event has passed. You may even want to replace it when it is too late for an attendee to consider going. If you have a new product that you want to push, that product should get top billing. If you have changed the way you describe your organization, that change needs to be reflected in the language on the home page. Being current is keeping up with with your content marketing strategy.

• More Compelling

  As I have said before, the only reason why someone visits your home page is because he does not know where to go. More intentional visits will come from deep links from search engines and other sites. Use this indecision to your advantage by driving the visitor to your goals. What content is the most compelling? You will never know until you test and that is where analytics and multivariate testing comes in. By the way, never do simple A/B testing. Always use an "epsilon-greedy" approach that allows the more effective option to automatically bubble to the top.

The simple rule is to never change content unless you have something better to show. But just because the rule is simple, it doesn't mean it is easy to practice. To follow the rule, you need to be producing current content that is in line with what your organization is doing; and you need to be hyper-aware of how your content is performing so you can continually improve it. Capriciously changing for the sake of change may make you feel productive and dynamic, but it isn't doing your organization any good. Never changing your home page is not a good thing either. It is a symptom of a stagnant organization and that is not something that you fix by regularly scheduled homepage changes.

PL Upload: a solution for uploading really large files into a web application.

I am working on this web application project that has a requirement for users to upload REALLY big files (as in 1 gigabyte plus). Given ubiquitous broadband (do people even call it broadband anymore?), and increased usage of video, I would not be surprised if lots of developers are seeing this requirement. The problem is that the basic HTML file upload field is horrible for very large files. It does not resume if there is a momentary interruption in transfer and the server gets stuck with one very large, resource-eating request. The traditional work-around is to use a flash application to upload the files. SWFUpload seems to be the most common implementation, but if you go to the home page, you will find that the project is no longer being maintained and is starting to break with new versions of Flash.

I was feeling pretty discouraged until I discovered PL Upload by Moxiecode. If Moxiecode sounds familiar, it is because they make TinyMCE, which has practically turned into the de facto standard rich text editor (WYSIWYG) for applications like content management systems. Sorry CK Editor.

The best part of PL Upload is that it embeds multiple implementations and selects the right one based on the capabilities of the browser. Modern browsers get an HTML5 implementation. There are also Flash, Silverlight, Google Gears options. You set the order of options to try and some Javascript goes through your list until it finds one that works. Another really nice feature is that PL Upload chunks the data into bite size morsels so that your server-side code gets lots of small requests rather than one big one. This makes resource management much easier and prevents one large upload from compromising the overall performance of the site.

I think the Moxiecode team is brilliant for seeing this problem and building such a nice solution. They seem to have used the same logic as when they came up with TinyMCE. Take a pervasive, nagging problem and build a clean solution that can become a de-facto standard. Their business model is to dual-license the software: GPLv2 for websites like mine and a commercial license for embedding the component in non-GPL software applications. I expect to see PL Upload surfacing in lots of content management systems just like I see TinyMCE.