- Shopping Bag ( 0 items )
Praise for Web Content Management: A Collaborative Approach
“I thought this book was very good. Well-written, easy to understand, clear, good illustrations, and topical. This is complex, somewhat slippery material, and the author has made it clear and graspable.”
—Mitchel Ahern, Director of Business Development, AdToolsInc.com
“I found myself wishing I had had this book two years ago. It explains better the real complexities of an enterprise web site. It's not a how-to in the sense of fixing what’s broken, but it is a comprehensive guide for web site planners and developers.”
—Linda Brigman, Independent Consultant
“Web Content Management: A Collaborative Approach provides sound principles and practices for designing, developing, and maintaining web-based projects of all sizes and audiences. The content management strategy described in this book is unique because it combines three critical components: processes, technology, and people. In addition, this book provides practical real-life examples and scenarios.”
—John Wegis, Software Development Manager, Kana Software
“This book makes web designers and architects rethink their approach in embracing web content growth. It covers a detailed understanding of web technologies. Through this book, you will learn how to create and manage content to attract customers and suppliers and improve the usability of your web site.”
—Ravishankar Belavadi, Senior Programmer Analyst, Kana Software
“Content management is one of the most important parts of web publishing infrastructure. Any company that thinks it can do without content management has its head in the sand. Business people and web developers alike need to understand the issues explored in this book.”
—Mark Gilbert, Research Director, Gartner, Inc.
“...The best content management materials available on the market today.”
—Robert Rasp, Manager, Content Management and Delivery, hsbc.com
For business managers and web practitioners, the success of their most vital web initiatives depends on doing one thing particularly well--managing web content. As web site content grows in volume and importance, its development and maintenance can no longer be performed either informally or by a single group. Instead, content must be systematically developed, deployed, and managed through standard techniques and processes that enable the site to scale.
Written by the leading visionary in the field, Web Content Management: A Collaborative Approach presents the principles, practices, and mindset involved in web content management. Learn the core issues of collaborative development, including versioning and managing concurrent changes. See how a solution framework used by many Fortune 1000 companies details a step-by-step process for designing and implementing a content infrastructure, including a workflow architecture and a task-based deployment methodology.
This book prepares you for the issues you are likely to face. It describes key tools, processes, and organizational approaches that support effective web content management and shows how all of these elements can be expertly integrated into a world-class enterprise solution--a web site with plentiful, current, and dynamic content that gets critical information to customers, employees, and suppliers quickly.
You will learn:
Real-world case studies drawn from the author's extensive experience consulting for large companies illustrate the practical use of content management techniques. In particular, new managers will find tremendous value in viewing the practices of other web organizations through these "day-in-the-life-of" examples.
With Web Content Management as your guide, you will be better prepared to elevate your web site--whether it is small, growing, or already large--to an information-rich, enterprise-scale solution.
It's been a hard day's night,
And I've been working like a dog.*
—John Lennon and Paul McCartney
Beyond the mountains
there are again mountains.
From Prototype to EnterpriseIt has been a wild four years. Rita's original idea was to build a web site in her spare time to improve the wooden suggestion box outside her company's lunch-room. Over the years, the penciled suggestions on scraps of paper yielded insightful ways to improve product quality, manufacturing efficiency, and employee morale, to name a few. The suggestions bypassed the traditional chain of command, and although the suggestions were almost always anonymous, Rita's group tirelessly made special efforts to respond seriously to each one. Perhaps the reason the aging wooden receptacle led to the changes that it did was the immediacy of the follow-up. Paradoxically, her group had never been formally charged with being the keepers of the suggestion box. It just seemed to be the right thing to do. Rita herself could not have predicted the events that would follow.
2 A.M. SoftwareIt is 1996, and the Internet Age has dawned. No one in the company recalls where the idea came from, but perhaps it doesn't matter. Why not augment the wooden suggestion box with a web site? That way, employees outside that immediate location can participate as well. Rita takes on the challenge during evenings and weekends. She refers to it as "2 A.M. software"
As a skunkworks project, word of the web site's existence spreads by word of mouth and internal e-mail. The suggestion box web site enjoys a steadily increasing flow of visitors. At first, visitors from other company locations visit to see first-hand how the democracy of ideas within that humble support facility can lead to tangible improvements. Soon thereafter, suggestions from other sites begin trickling in. Many of the suggestions pertain to company-wide operations.
Rita is the sole part-time web developer on the project. Just prior to leaving for an out-of-town conference, she demonstrates a prototype to a group of product managers to explain the value of the suggestion system. The product managers offer many suggestions to improve the usability of the interface. After returning from the out-of-town conference, Rita dives into implementing their recommendations.
Without the usual distracting chatter of phone conversations filling the air, Rita adds the pull-down menus to the entry page surprisingly easily. She likes the way that her new menus remove the visual clutter from the page. Eager to show off the new interface, she asks a colleague to try it out. When he tries it, Rita realizes that she hadn't tested her changes with the Netscape browser. They notice that her menus don't erase properly. Because she hasn't tested regularly with different browsers, some new code she recently added is the likely culprit. But which change is it?
The one-week hiatus renders Rita's recollection about the web site internals hazy. She needs help recalling what worked and what didn't work when she last did the demo. Luckily, Rita versioned the entire source tree of the demo web site before leaving on her trip. She's able to figure out what changes are candidates for the browser sensitivity that seems to have been induced by her recent changes.
Web site versioning plays a crucial role in the web development process. It is essential to periodically capture known snapshots of the web site, as we see in Rita 's early efforts with the web site. Snapshots serve several purposes. First, with a known snapshot of the web site a developer can roll back to a known-good copy of the web site. Second, if the web site or a section of it becomes hopelessly broken, a developer needs to be able to selectively pick assets to revert to. An asset is an electronic artifact that embodies the intellectual property of an organization. Having a known working set of web assets lets a developer proceed to make changes with the assurance that there's always the ability to compare to a working copy for ongoing development. A working copy can be used as a reference copy, to discern what changed and what didn't. Typically, only a small fraction of a set of files changes from one day or week to the next, which makes having a reference working copy of a web site invaluable for locating the changes that led to a problem. The core issue of site versioning typically arises distinctly early in a web site's lifecycle.
The PioneersThe team expands to four members. Rita is now the web architect, an informal leader of her band of renegades. They soon find themselves doing independent tasks. Sandy is the quality assurance leader whose primary goal is to build a test harness for the business logic embedded in the web application. She has also volunteered to prototype the online help system. Max is the CGI developer, and he is converting the text-file-based suggestion repository to use the corporate-standard commercial database. James is the interface designer, and he explores ways to simplify the interface.
It is Tuesday. James breezes past the unattended reception desk. He hears a few clattering keyboards from the early risers in the office. As he settles into his cubicle, he listens to the reassuring sound of the coffee maker gurgling the morning's first pot of coffee. James reloads the page that he changed yesterday before he went home.
"What happened to my changes?" James cries out, as he throws his hands into the air. He rechecks the URL to verify that he's indeed pointing at the right location. The reality sinks in. Someone has overwritten his changes with their own changes last night. James gets to his feet. He silently paces the aisle. Later that day, after much wrangling, the team decides to adopt a practice that gives each developer separate areas to do their work. James does his best to recreate his changes from memory.
Two months pass. The team works 18 hours per day 7 days per week to prepare for their presentation to a corporate Internet task force. To build the team's pitch, Rita gathers recent examples of business improvements that gathered momentum from their web site. She hopes to solicit support from the high-level executives charged with selecting and funding a promising set of web initiatives identified by the Internet task force.
James has numerous changes to the homepage file, index.html , and to the first-level pages, such as suggest.html , to deliver the promise of his slick new user interface. Max has changes, too. Although he has been working independently and in relative isolation on his database subsystem, it is now time to integrate that code into the homepage and first-level pages as well.
They hammer out an integration plan on Friday after their weekly status meeting, but when 2 A.M. Sunday morning comes around, Max finds that James hasn't completed the changes that they agreed to. James has either forgotten, or his progress was delayed. Unfortunately, when Max snoops around in the directories on James' development machine, he sees various versions of half-completed sets of pages. Max is stuck. He has to either make guesses about what James intended to do, or he needs to call James at home. He relishes neither option. He had intended to finish his integration Saturday night because he promised to help with his niece's sleepover birthday party on Sunday.
We see the issue of managing concurrent changes coming to the fore when the group reaches four members. Because each person is off doing different projects, and especially because of the nature of web technologies, they hit a "web-wall" This is the point in the lifecycle of a web site when the combination of the number of developers, the number of assets, and the pace of development exceeds the ability of informal coordination mechanisms to adequately do the job....
Peng T. Ong.@CHAPTER = Preface.
I. MOTIVATION FOR CONTENT MANAGEMENT.
1. The Internet Changes the Rules of the Game.
Fear and Greed.
Rules of the Game.
Rule #1: It's the Assets, Stupid!
Rule #2: Experiment. Iterate. Grow.
Rule #3: Respond to Customers Quickly and Frequently, or Lose Them!
Rule #4: Enable the Masses!
Rule #5: Make It Manageable and Reproducible.
2. Overview of Content Management.
From Prototype to Enterprise.
2 a.m. Software.
Universality of Assets.
Managing Web Assets.
Staging the Web Site.
Independent Edit Areas.
Content Management Architecture.
Content Creation/Editing Subsystem.
Deployment and Operations Management.
II. CONCEPTS AND PRINCIPLES.
3. Principles of Collaborative Web Development.
Are We in the Chaos Zone?
Development and Production Separation.
Direct Feedback (WYSIWYG).
Control Mechanisms: Auditing and Enforcement.
4. Best Practices for Collaborative Web Development.
The WSE Paradigm.
Common Work Cycles in Web Development.
Real-Time Development Work Cycle.
Compare-Update Work Cycle.
Review Work Cycle.
Major Test Work Cycle.
5. Templating Empowers Content Contributors.
The Freshness Imperative.
The Challenge of Change.
A Template System.
Advantages of a Template System.
6. Workflow Speeds Work Cycles.
Characteristics of Web Development.
Virtual Assembly Line.
Active and Inactive Tasks.
Building a Workflow.
Designing a Workflow.
1. Identify Interaction Sequences.
2. Identify Candidate Workflow.
3. Sketch the Steps.
4. Identify Known and Not-Yet-Known Parameters.
5. Add Remaining Transitions.
6. Add Notification Steps.
7. Deploying Content.
The Release Agreement.
Making Changes Transactional.
What Initiates Deployment?
Designing a Deployment Infrastructure.
Enterprise Deployment Architecture.
8. Multiple Web Initiatives.
Logically Independent Web Site.
Basic Branch Patterns.
Short-Term/Long-Term Branch Pattern.
Dependent Branch Pattern.
Identifying Branch Patterns.
Example--Using Branches in a Dot-Com Company.
Dependent Web Sites.
III. DESIGN AND IMPLEMENTATION.
9. Using Web Content Management for Globalization.
A Globalization Initiative.
The Easy Path Leads to Trouble.
Design a Solid Platform for International Development.
Work Area Structure.
Template System Design.
10. Summary and Conclusions.
Revisiting the Rules.
It's the Assets, Stupid!
Experiment. Iterate. Grow.
Respond to Customers Quickly and Frequently, or Lose Them!
Enable the Masses!
Make It Manageable and Reproducible.
Content Becomes More Structured.
Content Contributors and Their Tools Become More Specialized.
Blurring the Distinction between Web Operations and the Rest of Business.
More Distributed and Flow-based Handling of Assets, Tasks, and Jobs.
More Emphasis on Content Tagging to Enable Storage, Retrieval, Search, Reuse, and Routing.
Emphasize 24 x 7 Management Infrastructure.
Appendix A: A Smart File System.
Appendix B: A Workflow Design for Formal Hand Off Between Groups.
QA Hand-off Workflow.
Appendix C: A Workflow Design for Predetermined Time Schedules.
Time-Slot Techniques—Detailed Example.
Variations on the Time-Slot Technique.
Appendix D: Basic Process Steps of a Best-Practice Content Management Process.
Example: Web Site.
A Best-Practice Development Process.
Example: Rebranding Initiative.
Content makes a web property what it is. This is as true today as it was yesterday. This will continue to be true into the future, even as technological advances create ever more sophisticated ways to run businesses, reach customers, and react to trends. Content defines the soul of the property. Managing content includes the steps to design, create, implement, modify, archive, review, approve, and deploy.
As a founding engineer, system architect, and principal consultant, I have seen content management projects across industries, geographies, and organizations. Most have struggled to manage the tremendous growth in the web space without a corresponding growth in web tools and techniques. Hence the need for a book--a practical guide for project managers and web architects.
This book has taken me two years to write. During that period, I've been involved in over 50 web development projects in various roles with Interwoven, a content infrastructure software company. My involvement ranged from informal e-mail consultation, to in-depth design meetings, to focused implementation efforts, to complete implementation engagements. These experiences exposed me to a wide range of industries and organizations. It became clear that successful content management solutions share common features and are driven by a core set of principles and techniques.
I have attempted to distill my experience and that of my colleagues into this book. It began as a series of application notes that I wrote for Interwoven project managers and technical consultants. The notes explained concepts, principles, and techniques to help guide implementers and managers of web content management solutions. The notes helped our customers and consulting partners to frame and develop their content management solutions. The notes became the backbone of this book. The true test of a book is the number of scribbles in the margins, post-its sticking from various angles, bent corners, along with the occasional coffee spill. I hope this book will receive the same measure of wear-and-tear. If it does, I know that my goal has been accomplished.
This book will be useful to three broad categories of web practitioners: managers, architects, and developers. Managers benefit from understanding content management for the purpose of structuring the flow of work and planning resource allocation. A development manager needs to know how to separate tasks to minimize interference and how to orchestrate multiple web initiatives. A production manager focuses on streamlining the flow of changes from development, through a review process, to the ultimate destinations on multiple production servers. Accuracy, reliability, and reproducibility are paramount concerns to the production manager. A business manager, especially the executive sponsor of web initiatives, needs to understand how process and infrastructure improvements generate tangible business benefits. Benefits include faster development, more effective use of staff, and greater reliability. All managers benefit from knowing what is possible with current tools.
Architects focus on internal design, integration with other business systems, and technology choices. Throughout the thought process they must pay attention to structuring the design to facilitate rapid development both with the current staff and expanded staff down the road. For these reasons, architects must be cognizant of the precepts of content management. Their goal after all, is to design what can be built, to build what can be assembled quickly, and to assemble what can be tested easily and often.
Developers are specialists who create content as their primary job, such as Java developers or graphic artists, and others who contribute content as an adjunct to their jobs, such as a marketing manager or public relations specialist. A developer who grasps the principles of content management will understand its role in a larger context. This is especially important because a strong developer is inevitably tapped to contribute in the role of lead developer, where understanding the big picture helps to effectively blend the efforts of the group.
The managers, architects and developers who form the primary target of this book collectively have diverse experiences and wide skill sets. This diversity explains the difficulty that sometimes arises in explaining web content management because different people play different roles in the web endeavor. Each category of stakeholder has a different objective, and hence they tend to look at the problem of content management differently. For example, content contributors want the shortest path possible to get their changes to the web, with as few obstacles as possible. In contrast, production managers want to make sure that content is tested, reviewed, and safely under version control. Because of the difference in perspectives, different parts of the content management solution are assigned different priorities. All the views need to be accounted for, striving for a realistic balance.
Organizations are also governed by their current practices. For example, one reader may currently use "edit directly on the production server." A different reader may use the "test changes on a staging server before deploying to production server technique." Others may use the "e-mail content to the webmaster" approach. Part of the challenge is to bring all of these different perspectives up to a common starting point.
Because of all of these differences, finding the initial common ground on which to build the motivation and techniques for content management requires some effort. This includes agreeing on the vocabulary and building a common understanding of the problems. An experienced content management manager or architect will find the early portions of the book a useful refresher on concepts. However, a manager new to content management will find this information invaluable. In addition to setting the stage for later chapters, the book helps frame views on the proper interactions and interrelationships in a true web environment.
One of the important elements of this book is the use of "day-in-the-life-of" examples. New managers will find tremendous value in viewing the practices of other web organizations. These examples are based on companies that I've worked with, and represent a broad cross-section: companies both large and small, from dot-coms to brick-and-mortar companies, from many different industries.
To truly convey the meaning of web content management, we cannot merely talk about tools. This book expands the reader's view to look at people, tools, processes, and organizations as an interrelated whole. That's a big lesson that Interwoven's consulting force has learned over the course of implementing content management for customers over the last three years. It isn't just about installing a tool, loading the content, handing over a stack of manuals, and heading for the exit. Implementing a content management solution is a number of things that are much broader in scope. It is building a partnership between the consultants who understand how to use the product and the customer who understands the social and organizational dynamics of his or her company. It is a fallacy to underestimate the importance of either side of the equation. Building a flawless and pristine installation will not be successful if the implementation effort finds itself blind-sided by an entrenched "not-invented-here" attitude about software tools in general. Similarly, a perfectly aligned organization is useless if there isn't an appreciation of the "art" of managing thousands of web assets, designing effective workflow, and getting that information from content contributors.
That's the challenge and curse of implementing a web content management solution. It is essential to build strong bridges between many constituencies in order to lay a path to success. It can neither be a fully grassroots effort to build a solution from the bottom up without executive sponsorship, nor can it be a top-down solution that is imposed by executive fiat. As with most things in life, there are challenges and struggles in any implementation effort. Without a doubt, the rewards make it worthwhile.
This book primarily speaks to the practice of content management, which differs from the "science" of content management. The term "content management" has only recently been used to refer to the principles and practices around developing, managing, maintaining, and deploying content in an organization. As such, it is more common to find practitioners of content management than scientists of content management. A practitioner slings a toolkit over her shoulder and carries a collection of useful concepts in her head, but her primary objective is to help clients set up an infrastructure to manage content. The practitioner engages with clients, asking questions, sensing the lay of the land, in an attempt to gain insight into which of several approaches to bring to bear on the problem. Success is measured both by how well the implementation matches the original requirements and by how happy the client is. The former tends to be objective, while the latter is hugely subjective. Measuring against requirements moves close to the notion of the science of content management, while client happiness is scientifically unsound.
This dichotomy between the objectively measurable and the scientifically unsound is evident in this book. On one hand, we endeavor to convey the flavor of the practice of content management through experiences gained from numerous client engagements during what will undoubtedly be viewed as the formative years of the Internet revolution. On the other hand, through that limited and possibly idiosyncratic perspective, we strive to distill the common concepts and principles that have proven to be useful across many engagements. Does it rise to the level of science? Probably not. Do I wish that the concept building, hypothesis testing, and strenuous analysis could be infused with enough rigor to qualify as science? Of course. But it is my honest belief that the field isn't quite ready for that degree of consolidation. But just as pioneer farmer might have discerned the science of agriculture, or a village healer might have gleaned the beginnings of the science of medicine, we hope that some of the lessons described here will help others to point the way toward a "science" of content management.
This book has ten chapters that divide naturally into three parts. Part One lays out the motivation for content management. It examines the issues that arise when a solution is not in place. It introduces the concepts of content management that will be used throughout the rest of the book. This section paints the essential backdrop for readers unfamiliar with content management concepts. Case study examples highlight the importance of content management in the proper functioning of any organization's web sites. Readers who are more familiar with content management may wish to skim this section to refresh their understanding of the issues, and jump into Part Two for a detailed discussion of theory.
Part Two introduces the concepts and principles required by a practitioner, and provides the framework to develop a content management solution. Technical architects, project managers and consultants will find the basic building blocks for the content management solution within these chapters. This section presents the content management theory necessary to build a solution, used extensively in Part Three. This section starts with the importance of content management in ensuring a collaborative development environment, highlighting the practices that must be encouraged. It follows with a detailed discussion of the key levers of a successful content management solution: templating, workflow, deployment, and branch design. Each of these sections delves into the theory underpinning each content management lever to understand its value within a content management framework, its impact on an organization, and the complexity required to reach a solution. Examples are used to illustrate common uses of each lever within a business context
Part Three explains how to design and implement a content management infrastructure. It describes a step-by-step procedure to generate the implementation architecture, and proposes a task-based methodology to guide the implementation of the agreed-upon design.
Chapter One--The Internet Changes the Rules of the Game. Motivates the need for a content management solution.
Chapter Two--Overview of Content Management. An introduction to the concepts of content management used throughout the book. It enables you to understand content management without delving into the details necessary to implement the solution.
Chapter Three--Principles of Collaborative Web Development. Lays the foundational principles of collaborative development. It covers the core issues of web site versioning, and managing concurrent changes.
Chapter Four--Best Practices for Collaborative Web Development. Describes the work area-staging area-edition paradigm of development, and lays out the four basic work cycles: development, compare/update, review, and test.
Chapter Five--Templating Empowers Content Contributors. Details the rationale for templating, or separation of content from presentation.
Chapter Six--Workflow Speeds Work Cycles. Delves into the benefits and concepts of a workflow infrastructure to speed the development process.
Chapter Seven--Deploying Content. Introduces the concepts that govern a deployment infrastructure. Presents a design for a deployment infrastructure.
Chapter Eight--Multiple Web Initiatives. Covers the concept of branch design, which introduces the notion of a logically independent web site. These concepts address the core issues of project completion skew, and of long-term versus short-term projects. Details how to design a branch structure for multiple web initiatives.
Chapter Nine--Using Web Content Management for Globalization. Presents design of content management system for a globalization project.
Chapter Ten--Summary and Conclusions. Summarizes what we've learned. Discusses trends in content management and what they imply for the future.
Creating this book took four times longer than originally hoped for and the effort was ten times more strenuous than I would have wished for. But the effort has been worthwhile, in large measure because of the numerous people who have supported this project throughout its lifespan. They all shared the belief that something could be constructed where nothing had existed before.
I owe a debt of gratitude to Peng Ong, who gave me an incredible opportunity to help transform his product vision into software. The initial development team of Kevin Cochrane, Terrence Yee, and Gajanana Hegde steadfastly believed in Peng's vision and provided an intensely creative work environment to launch the product.
Several product releases later, Peng handed me another incredible opportunity: to join his fledgling consulting organization. Robert Gerega, Jennifer Marek, Zhaohong Li, Victoria Chiu, James Koh, Jon Lau, and Robert Turner were extremely supportive of my early efforts to codify knowledge in application notes. I am indebted to our early customers who were willing to put their faith in our people and our products.
I owe thanks to T. Francis Richason, Reza Haniph, Christine Owens, and Raghu Madhok who gave me the time and encouragement to complete the application notes and the manuscript. Marc Carignan deserves mention for being especially supportive and accommodating.
I extend my gratitude to the numerous people who reviewed drafts and provided helpful comments: Adam Stoller, Robert Gerega, Evers Ding, Andrew Chang, Blake Sobiloff, Dave Cadoff, Stan Cheng, Jack Jia, Patrice McCauley, Christine Owens, Dhruv Ratra, Mark Bradley, Raghu Madhok, Kevin Lindbloom, and Anurag Gupta from Interwoven; Mitchel Ahern, Ravishankar Belavadi, Ren Bitonio, Linda Brigman, Jeff Rule, Kenneth Trant Jr., and John Wegis choreographed by Addison-Wesley.
James Koh provided fascinating insights on the birth of a corporate web presence. Wes Modes enthusiastically described his approach to globalization.
This project could not have been completed without the marketing, art direction, artistic, and literary contributions from Ted Fong, Don Wong, Rick Steed, Raina Pickett, Andrew So, Helen Lee, Debbie Ryan, and Marianne Lucchesi. Executive support for this project from Martin Brauns, Marc Carignan, Mike Backlund, Joe Ruck, and Jack Jia was timely and essential.
Executive editor, Mary O'Brien, and her associates Alicia Carey, Curt Johnson, Jacquelyn Doucette, and Chanda Leary-Coutu at Addison-Wesley were tremendous.
Reza Haniph managed the project tirelessly. He deserves extra credit for playing the role of product champion.
Posted July 8, 2001
This book is a 'must read' for all website managers! Nakano expertly explores the ins and outs of web content management in a delightfully refreshing style, using humor, intrigue, and suspense. He brings all the makings of a best selling action-suspense thriller to the otherwise mundane world of web content management. I predict this book will become the standard reference for every web development team.Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.