| Average Rating: |
|
| Sales Rank: | 391025 (lower is better) |
| Price Used: | $16.82 |
| Shipping: | Free Shipping on most orders over $25* |
| Availability: | Usually ships in 24 hours |
| Label: | Wiley |
| Pages: | 352 |
| Binding: | Paperback |
| Publication Date: | 2002-02-28 |
| Published By: | Wiley |
| ASIN: | 0471085863 |
| Category: | Book |
When I see a book that lays out a process structure in the beginning, I expect the table of contents to follow that structure. This book fails to do that. It can be difficult in the first reading to know what phase of the process is described in any particular chapter. The last two phases of development--the pilot project and the roll out--are not described outside the introductory chapter.
Since the content management field is apparently devoid of a conventional vernacular, authors get to invent their own terms for things. I had to read several chapters many times to understand what Hackos means by "information type" and "content unit." It was also difficult to see where metadata fits into the picture. Her information model shows an information repository containing "modules of content", such as reports or manuals. Each module of content may contain one or more "information types", such as letters or recipes. Each information type is constructed of "content units", which can be recipe ingredients or procedure steps. But, you start by defining "dimensions", which become retrieval metadata for the information types.
A dimension is essentially an enumerated data type with a set of discrete values. Once you define the dimensions, you can then define information types and, at the lowest level, content units. These dimensions are translated into metadata attached to "modules of content". This is what confuses me. As described in the book the metadata is attached to the highest level of document in the repository, but not the lowest level of content unit. Apparently, the sole function of metadata advocated here is to aid user-level searching and retrieval, and not to support authoring workflow. I find this a significant shortcoming.
In summary:
Strengths: Strong focus on the end user, case studies, process not overly detailed, a chapter on making a business case, appendices full of checklists, & a good introduction.
Weaknesses: Book doesn't follow process flow, the jargon is difficult to grasp, reuse mechanisms are not well covered, uses a weak metadata model, and really only details the first three phases of a five-phase process.
Recommendation: A number of people I work with like this book, so maybe I'm just cranky. I would check out the comtech-serv.com website where Hackos lays out the process for you and provides some detail. You should be able to get a feel for her style and process there.
In fact it gives in certain areas very bad advice.
One example. Now if you have 1000 information units that are reused for a new computer model D, you need to add this computer model to Good solutions model the relationships between components and in which products they are used I also do not see anything on: Even the XML syntax used is not correct, I'm afraid, since these seem to be empty elements.
For every content unit you will indicate for which product model this information is applicable.
the meta-data of 1000 information units.
The same if a model is taken out of the market.
This is not maintainable. I repeat this is not maintainable.
using PDM software, ERP software or in the traditional RDBMS sense and information units have a pointer to this external information.
- modeling of relationships between attributes
- modeling of relationships between the values of attributes.
E.G. food can have an ethnicity (italian, mexican, chinese, irish, ...)
These could be classified or grouped as european, asian, ...
No word on this.
Particularly noteworthy (at least to me) is the chapter on making a business case for content mgmt, which is increasingly important for technical communicators.