How Would You Design a Content Management System?

Rendered Concept of a Digital Content Lifecycle.

By Cathy Hodson

What is a content management system (CMS)? According to Wikipedia, “A Content Management System (CMS) is a computer program that allows publishing, editing and modifying content as well as maintenance from a central interface. Such systems of content management provide procedures to manage workflow in a collaborative environment. These procedures can be manual steps or an automated cascade. CMSs have been available since the late 1990s.”

In other words, a CMS allows multiple content creators (frequently called “authors”), a managed workflow (approval process), and either automated or manual features.

I have experience with two content management systems: Ektron and SharePoint. They both have their advantages and disadvantages. I have also kicked the tires on other CMSs, and they too have the good, the bad and the ugly. Recently I asked the members of the Web Editors group, “If you could design/develop your own content management system, which features would be ‘must haves’?

Must Have Features
The responses were interesting. J.D. desired more project management features, “The CMS should know that nothing goes public until an assignment of copyright agreement has been executed.”

He also recommended staging features, workflow integration (“you should get a view of works in progress”) and annotation, in particular, fact checking and documenting the fact checking.

Barbara wanted “True WYSIWYG. Period.”

Ken wanted to “work on a system that has all the parts that were promised. Twice this week I’ve been told…’Oh, that’s scheduled for the next version.'”

Control
If you were designing your own content management system, which features would you want to include? For me, there are a few, and they have to do with control. Being able to control the style (rules and guidelines used for consistency across a website) within the CMS so authors not well versed in your company’s or your website’s style cannot stray from it. Another feature I’d like would be to have the HTML view of your content be color coded, such as in Dreamweaver. It makes it easier to pick things out when you’re looking for something rather than having everything in black type on a white background. In Dreamweaver, if there’s a problem in the code, the color coding stops where the problem is so you can find where the snarl is a little easier also. (If you’re colorblind, however, that may not be as effective.) It would also be nice to be able to use a global replace in the HTML view.

There are times when it seems that developers of content management systems don’t understand what a content editor or author does. They are not aware of the publishing process that a writer or editor goes through in order to add or maintain content on the website. This disconnect can be a major issue at times. For instance, when my company was going through its most recent redesign, we expressed our desire to the developers that, as all content funneled to me for approval, I needed to be able to see what had changed on each page. I needed a redlined version, in other words. Our company, at the time, had several thousands of web pages. There was no way I could possibly memorize each page and instantly recognized what an author had changed in an existing page when it came to me for approval. Because we have such a high volume of content, I didn’t have time to dig through everything on every page that was submitted to me to try and figure out what the author had changed. Had they deleted any paragraphs? Had they linked to something new? Was there an update to the photos? It would be helpful to see only what had changed so that I could review those changes and then send the page on its way to the website, or back to the author for more work. There was great puzzlement on the developers’ part, not understanding why this was so critical. We finally got across to them why it was so necessary, and were able to implement a customized tool that allowed me to see what an author had done to a page.

Gibberish code
About the time we were discussing this topic, I received an email newsletter, Fierce Content Management, and read the Editor’s Corner: “Content Management Systems drive me nuts!” by Ron Miller. I read with particular interest, “Last week for instance, I tried to drop in some code for the content marketing infographic we published. Typically, it’s like dropping in the code for embedding a YouTube video. You access the source code, paste the embed code, and presto, you have an infographic in your post. But lately our CMS has decided to spontaneously add gibberish to the infographic embed code making it virtually useless and forcing my co-worker, Emily Poe, to have the added work of dropping it in as an image instead.”

That hit home with me, as our CMS also will add gibberish when our authors copy and paste from a Microsoft Word file. Sensing a kindred spirit, I contacted Ron and asked him for his “must have” features. He sent the lists below:

Back End:

  • Make sure it supports multiple writers easily.
  • Make sure it’s easy to update the CMS. (WordPress is drop-dead easy).
  • Make sure you set up a good set of tags ahead of time.
  • Leave a place for the writer to include a one or two sentence excerpt and encourage writers to create this for you.
  • Make sure it’s easy to add alt text to your photos (very important for disabled community).
  • Make sure it’s easy to embed content like video and inforgraphics (easy access to HTML code)
  • Make sure it’s easy to add and edit photos. (visuals are really important in my view).
  • See if you can find a plug in for creating a weekly newsletter and linking it to a mailing list app like MailChimp.

Front End:

  • Accessible contact info.
  • Some sort of comment security like Disquus. Doesn’t prevent morons, but helps.
  • Prominent search box.
  • Resources like white papers and ebooks.
  • Include all your site’s social media info
  • Make it easy to subscribe
  • Make it drop-dead easy to share across all major social networks.
  • Easy to copy and paste text from outside sources and maintain style

None of the CMSs will be perfect. They all have their quirks, and web editors must find work-arounds and solutions we can live with. But it sure would be nice if we could design our own, or at least catch the ear of the developers and have them truly understand what our needs are. Anyone?

Next time: Editor vs. Programmer

Time Management: Six Steps to Peace of Mind

By Cathy Hodson

In the fast-paced, ever changing world of online journalism, is it possible to still, as author/entrepreneur Guy Kawasaki tweeted recently, “rediscover the magic of doing one thing at a time”?

Twitter post by Guy Kawasaki, April 14, 2013

Twitter post by Guy Kawasaki, April 14, 2013

Managing your time is a must for web editors. News can happen very quickly, and you have to be prepared to have your day turned upside down at any moment. Natural multi-taskers, web editors learn very quickly how to juggle their responsibilities but still make room for the occasional emergency.

One of the most important tools in a web editor’s arsenal is time management. Organization and prioritization are integral partners with time management – you really can’t manage your time if you are not organized or cannot prioritize.

Here are some tips on maintaining time management, organization and prioritization:

1. Handle everything only once. Any assignment, any piece of mail, any notes from a phone call, any verbal order you receive – only handle it once. Take the piece of mail and do something with it – add it to a folder for a project you are working on, pass it on to a colleague, or deposit it in the circular file. Actively do something with it, don’t just set it on your desk to be dealt with later. Deal with it now.

2. Keep information and resources for each project together – whether you use paper folders, electronic ones, or a combination – use some type of organizer to keep everything you need on one topic or project together. The photos for this year’s election candidates should all be kept together in one place so they don’t get mixed up with the candidates from last year. The article your boss just handed you about mobile apps should find its way to the reference folder you have for mobile information. By keeping organized and handling this information just once, everything should be where you know where to find it when you do need it.

3. Try to keep one day of your week clear of meetings and interruptions. Physically block out one day of the week on a recurring basis on your calendar so that no one can schedule a meeting for you that day each week. If you have to relinquish for one meeting, fine. But otherwise, keep one day each week as free of meetings as you possibly can. This will enable you to have some actual “work” time to catch up on projects you need to without interruption.

4. Learn to say no, or at least how to barter. Keep a running list of your current projects. When your boss comes to you and says, “You have to drop everything for this new project,” you can honestly show him or her that your schedule is packed, or at the very least it gives you something to barter with. “I could move this project to the back burner if your new project has a higher priority?” The boss can then see what those other projects are and help you move something if the new project does take priority, or perhaps understand that the new project isn’t really as important as the other things you are working on, and can wait.

5. If you have a “time stealer” person – someone who is in your office frequently – either for business or personal reasons – set up a regular time to meet with them so they can continue to use you as a business resource, but you can contain their interruptions to one dedicated session. If they are in your office for personal reasons – schedule a lunch with them now and then to catch up, but learn how to say, “I’d really love to hear all about this, but I’m on deadline. Let’s do lunch some time and you can fill me in then.” Learn to recognize activities and people who usurp your time, and learn to handle them so they don’t handle you and waste time that could better be used for concentrating on the project at hand.

6. Even the best laid plans, however, can be turned upside down. Hurricane Katrinas happen. Learning to delegate important facets of projects to your staff can make them feel involved, engaged and part of the team. If you do not have staff to delegate to, one of the best practices is to break a project into manageable pieces. That way, when you can’t work on one part of the project because you are waiting on someone else, you can move ahead to another portion of the project and get it underway until the first portion of the project comes back to your bailiwick.

What are your favorite time management techniques? Please share them in the comments.

The Agile Editor

If you’re a web editor, you might already work in a company that practices agile software development. But even if your company or your clients haven’t made the transition to agile, they probably will. Agile has been increasing in popularity over the past few years, so it’s a good idea to have an understanding of how agile works and how you can champion content and editorial best practices within this new framework.

What is agile development?
Basically, agile is a faster and more flexible way of managing software and web development projects. Traditional software development involves a “waterfall” approach, with defined phases that move from one to another without overlap: from requirements gathering to design to development to testing to launch. In waterfall, project phases tend to happen in silos (development does not involve feedback from designers, etc.) and can take a considerably long time. And requirements usually can’t be changed until the project is complete.

The agile movement started with the agile manifesto. A group of IT professionals created the manifesto in response to the issues they had with the negative aspects of the waterfall process:

  • Project roles are isolated and communication between the business owner (and the customer) and the team is non-existent.
  • The products take too long to get to the end customer.
  • There is no method for adapting to changing business or customer priorities.
  • A focus on lengthy, technical project and spec documentation is time-consuming and produces documentation that is difficult to utilize.
  • QA and bug-testing are often rushed, so products are frequently released with many bugs.

Agile aims to address these negatives by:

  • Giving the team a voice in making decisions
  • Releasing the product frequently (usually every two weeks or once a month)
  • Focusing on product features that are the most important instead of just features that have been approved, allowing for priorities – and requirements – to change
  • Using short, easy-to-understand documentation (or no documentation at all)
  • Performing frequent QA testing.

Agile encompasses many different methodologies (for example, extreme programming or DSDM), and all of them follow these basic concepts. But the version of agile that seems to be the most popular is Scrum. Scrum (the term comes from rugby) focuses on “sprints”, which are short work periods used to plan software releases. The length of a sprint may vary; I’ve usually worked on projects with 2-week sprints.

Scrum teams usually consist of the Scrummaster, who records the decisions the team makes and brokers issues between team members; the customer (often the business sponsor), developers, product and project managers, UX and visual designers, copywriters, and the QA team. At the beginning of each sprint, the team holds a meeting to prioritize the product features to be developed. The priorities are broken down into tasks (groups of related tasks are called “stories”), and these tasks must be completed within the sprint. Any product features that are not part of the sprint are relegated to the ‘backlog’, essentially a master list of all of the features that need to be developed and tested. The backlog may grow as new requirements and issues are added or discovered.

Each day the teams holds a “stand up”, a 15-minute check-in meeting. On some agile teams, members will actually stand up to ensure the meeting does not go over the time allotted. Members are asked to describe what they completed the day before, what they will be focused on today, and if there is anything blocking their work that the Scrummaster needs to address.

So how does a Scrum project affect a web editor?
In my experience, working on a Scrum project means an editor needs to work harder to ensure that editorial priorities are being met. One of the challenges of agile is that the focus on individual tasks and stories can cause the team to lose sight of the big picture of the overall user experience. Additionally, UX and content deliverables like wireframes and copy and are often rushed at the beginning of a sprint so that developers can start coding, QA can test, and the team can launch the updated product by the end of the sprint. So a careful review of user interactions, copy, and design elements often does not take place; the team is focused on functionality, not content or UX.

On the plus side, the fact that there are frequent releases means that when you do surface an issue, it can get resolved far more quickly than it would if you were working on a waterfall project and had to put your request into a long queue.

Here are some tips on how web editors can work within an agile environment:

  • Focus on relationships. Agile development is built around communication. Team members are encouraged to work together directly instead of through documents, group meetings, or project managers. Get to know the developers and the QA team. You want them to come to you when they have questions about content rather than make guesses or ignore issues (which some people will do if they’re not encouraged to ask questions).
  • Go to the standups. Sometimes project managers will go as proxies for their team, or certain team members will sit out sprints if they don’t have a specific task assigned to them. But make sure you attend the sprint planning meeting and as many standups as you can so you can advocate for the product features from an editorial point of view. Inevitably, questions will arise as developers work on new features, and if you’re involved, you can help ensure that the end user and your editorial vision are represented. You can also help steer the team away from solutions that stray from your content strategy, necessitate an inordinate amount of explanatory or directional copy, or don’t align with your brand.
  • Train the QA team on content and style. You can’t expect your QA team to be proofreading; their focus is on testing functionality across platforms and browsers. But take the time to give your QA team some background on style guides, design standards, and content requirements. This will increase the possibility that they will help you catch inconsistencies. And, if you’re building relationships as noted in #1, the QA team will be comfortable coming to you with questions.
  • Scour the backlog before the end of every sprint. Revisit end-to-end functionality – for example, a sign-on process or a site search.  Perform every step to make sure that the interactions are intuitive and consistent. Review your product with a focus on the user experience and on your business objectives, annual goals, editorial calendar, etc. This will help you determine what the team should focus on in the upcoming sprint, and you want to go to the next sprint planning meeting with these priorities already in hand, because work will begin immediately. Also remember that when reviewing the backlog, changing priorities might mean tasks should be removed from the backlog and replaced with new ones.
  • Volunteer to test whenever possible, including on launch night. Unexpected things can happen during testing, and you want to be there to help advocate for the best solution.
  • Master the bug tracking system. Many content and marketing people will avoid bug-tracking; it’s not the most exciting activity, and some see it as the QA team’s job. But as an editor, you’re already trained to look out for inconsistencies and imperfections. Ask for access to your QA team’s bug tracker if you don’t already have it, and record any bugs you find. That way you can ensure that any editorial problems are tracked and assigned to the right team members for resolution.

Agile can be daunting when you’re accustomed to traditional software development. But be open to its positive attributes, and you’ll find opportunities to educate your team on why editorial review and high-quality content is important for the products you all care about.

Redesign: Staging and Mapping Your Way to Success

By Cathy Hodson

You have a huge company website, and you have a matter of weeks to move content from your current site to your new site. How do you get a handle on how to move your content and figure out all the logistics involved? If your website has more than a hundred or so pages, or even thousands of pages, with all the associated documents and images, how do you get organized enough to know where your content is currently and how to get it to where it will be going on the new site?

By staging and mapping your content.

Staging your content
Staging is really prioritizing. What do you absolutely have to have on your new site when it launches? This is your first stage of content to be moved, before the launch, and the highest priority.

The second stage is the next level of content that – yes, it would be nice to have it on the site when you launch, but if it’s not, it will be the first content to go up after the launch.

The third stage is the final stage of content to be moved. Usually this consists of back issues of publications or content that could be considered “filling in” – background information, links to other resources, more of what you already have up, the finer details that fill in and embellish on what is already there.

What is mission-critical content? Mission critical defined: your business will suffer and your staff will have to scramble (in a bad way) to help your customers or members if this content is not on your website when you launch.

The actual timeline for all three stages depends on how quickly you need to have everything out of your current/old website. Usually all three stages should take about nine months to one year. To have all your content moved within six months of launch is a good benchmark.

Mapping your content
Once you have your content prioritized, you need to map it. Where does it reside on your site now? Where will it be moving to – most redesigned sites have also reorganized. So the content that might be listed under “Professional Development” on your current site might be split up among 2 or 3 different sections on your new site – Education, Continuing Education, Meetings. Somehow you have to note this for  someone who might not have detailed knowledge of your site (such as a temporary worker or consultant)  – where they would find the original content and where they need to put it on the new site.

The first website redesign I was a part of, the consultant that was building the website gave me a spreadsheet to use to map this process. It had columns for the new site location, the current site location, the status of the content (“testing,” “intro done”), a place for information about the content (such as “content needed” or “6 files, public side”), comments (“under construction” “is this the same as federal section on public side?”), and any changes (“name of section changed from X to Y”), and even a showing of which page(s) on the site link to each page or document listed. You can and should adjust the structure of your mapping document to whatever makes sense to you and your team. Is it better to list your content by the structure of the new site, or the structure from your current site? Up to you. Ask the people who will be moving the content which would make more sense to them? Or make an executive decision and decide for yourself which makes more sense.

Links
Something else that is helpful for content movers, especially if they are not part of your company’s staff, is to print out the pages on the current site, and mark up the page with notations for each of the links found on that page. Does this link go to a page on the same website (internal) or does it point to another company’s website (external site)? The internal site’s links may change, and that should  be noted – either on the page you printed or in the mapping document. If the page being linked to is from another department or division, and perhaps they have prioritized that page to be added at a different stage than when your page is going up, that should also be noted so the link can be added when the other department’s page goes up.

If it is an external site link – does it still work or does it need to be updated? If it no longer exists (or can’t be found), do you have instructions in place on what the content mover should do? Remove the link entirely, replace it with something else, or just leave it as is?

Once the plans for the staging and mapping have been completed, it gives you and your team parameters and guidelines for moving the content.

Content management systems
If you are keeping the same content management system, there may not be as much to do with mapping, prioritizing or moving content. It may be a matter of simply moving files across your system, adapting your content to a new page layout, or reclassifying the content. If you haven’t been using a content management system, but will be using one with the new website, you may pretty much have to reconstruct your pages – reformatting, linking to where new pages are, updating headline and other codes. You will have to do the same if you are changing content management systems.

Other considerations
Perhaps your URLs will change also. This is something that can be noted in the mapping document. A change of URL can be problematic – internally, for the sites that link to you, and for any links you publish on stationery or in publications – either those you print yourself or publications you submit materials to for articles or ads. Business cards may need to be updated, as well as signatures in email.

Any specialized domain names that point to deeper areas of your site may have to be repointed to the new location. For instance, our foundation has its own domain name, but it forwards to a deeper page within our association’s website. That location changed when we redesigned in 2011, and the DNS (domain name service) had to be updated to forward to the new location.

A successful redesign depends implicitly on how organized your team is, how much forethought and planning goes into the moving and launching processes, and nailing down the details. If you have never been part of a redesign before, choose your consultant carefully. You should hire a company that can walk you through the process and support you from both a development and an editorial standpoint. This is paramount to the success of the redesign. A redesign for a large website can take anywhere from one to three or four years, depending on how big your website is, what has to be done – a major overhaul of systems and the website, a simple reorganization and facelift, or anything in between.

Plan, prioritize and map. Iron out the details and make sure everyone understands what needs to be accomplished, when it needs to be accomplished by, and what the ramifications and consequences are if deadlines and project milestones are not met.