Volunteers wanted!
CMS Consultants is looking for volunteers.
To inquire about volunteer opportunities, contact the volunteer co-ordinator.
Glossary editors must know how to do a few additional things to use the CMS Wiki as our authoring tool:
We hope to make the glossary itself an example of content management best practices. Terms will not be invented, but drawn from actual usage in the CM community. This is called User Warrant. Where more than one term is in use for the same concept, we will include them as variants. Because we also have normative goals, to encourage standards in our community of discourse, we may also recommend our preferred terms. For example, Baked PT Dynamic, or Baked USE Dynamic, or more popularly, Baked See Dynamic.
Our work should be of the same or better quality than the IAGlossary, which currently has about 35 terms and several contributors.
We have a proposed list of over 550 terms, and have written definitions for about 225 so far. (The work is just as exhausting, but much more rewarding, than editing hundreds of CM website descriptions for DMOZ/Google.)
These terms have been gleaned from a close reading of all the major books on CM (Boiko, Rockley, Hackos, Nakano, Addey/Suh, McGovern, Greenspun, and Stahl - auf Deutsch), from online glossaries that cover CM, and from books on closely related fields, like IA. We especially scanned all the indexes. It also used the Boiko/Hackos/Rockley CMS Evaluation Thesaurus.
We need a definite editorial policy for the glossary, and a content template for what should be included in an entry, like quotes and references. The gold standard of controlled vocabularies and glossaries is to use a thesaurus structure (including RT, BT, NT, VT and UF etc.).
If we have a good architectural design, we can rebuild it in chunks to be syndicated via XML transport and presented in other forms (via XSLT). It could feed future editions of CM books. Bob Boiko wants XML inputs for his second edition glossary. We hope it will find a place on all our CM websites, possibly filtered on metadata like "non-tech" if necessary. We could link to single definitions as needed from our websites, as Tony Byne did recently.
Erik Hartman and others are rightly concerned about the limited presentation possibilities in the current Wiki website. But the Wiki works fine as a collaborative writing tool for us to collect the content into chunks. It has revision control, but is not well suited to multilingual versions. James Robertson and Brendan Quinn have contributed additional content so far. Edit privileges are available to anyone else who may contribute.
We have been allowing anonymous visitors to add content. A few valuable additions have been made, but they are swamped by the amount of spam (dozens a week) now that the CMS Wiki is getting well known. We may soon have to enforce our policy that says contributors must be registered users, perhaps well-known to us.
James Robertson's early suggestion to add "see" (e.g., "PDF, see PortableDocumentFormat") has been implemented using "tool tip," which provides the long definition on mouseover of the acronym.
"CMS Glossary-as-a-Service" is a special feed that allows any CMS-related site to offer these glosses, with CSS styling to match the site. Feed designs include glossary indexes (with only defined terms or all terms), in drop-down menus and straight HTML lists, and definition feeds, suitable for inclusion in a Javascript pop-up window or in a <frame> or <iframe> in a web page. The feed will be recursive. Defined terms in a definition will be active links that return their definitions. We are hoping to find testers soon.
The glossary-as-a-service can replace the formal "Related Terms" with the less formal "See Also."
Here is an example of the CMS Glossary as a web service. The web-service connector (running at cmscalendar.com) gets information from the CMS Wiki database, combines it with styling from CMS Watch, and creates a drop-down menu for CMS Watch to federate the glossary.
It opens a Javascript window that matches the look of Tony Byrne's current glossary (e.g., compare his defintion for Apache).
Here are some more custom glossaries that open a new window for the glossary-as-a-service, styled to match the website.
And here are two examples of using an iframe to fit the glossary definition into the look and feel of a site exactly.
A multilingual version of the glossary could be a major public service project for CMS Consultants. Erik Hartman and Paola DiMaio have helped translate pages on CMS Review, and could help organize this effort.
We hope that many of these definitions, and possibly the architectural design if well done, would be adopted by AIfIA, so the CmsGlossary could be a demonstration example of practicing single-source publishing - maintaining our core content in one place, but delivering it to multiple audiences.
Single-source and reuse is also the goal for other major CM community resources, like calendars, resource listings, product listings, feature comparisons, news feeds, etc. See cmsreview.com/CMSFeeds.html and the community news aggregator at CMS-News.org.
We perhaps need some further discussion of the current terms-of-use for the CMS Glossary (Creative Commons License).
Criteria for evaluating the Glossary
(eg. I've already removed definitions for Venn diagrams, broader & narrower terms, etc.)
Just thinking that the list is very long at the moment, and very technically-focused...
Cheers,
James
Thanks for the good work!
To my opinion the glossary can't be long enough, as long as it has some relation with content management.
People are overwhelmed by all these terms and acronyms. They are looking for a source that gives them some explanation. I sometimes check the glossary of C|Net.
The 'problem' of the Wiki glossary though is the way it's published. I have some ideas about presenting the glossary in a more user friendly way. But I'm afraid it's not possible in the Wiki.
Erik
Thanks for the many contributions to the glossary.
However, I would recommend that the CmsGlossary keep every possible related term of interest to CMS Consultants. I can't imagine why too many terms is a problem. An online dictionary can not have too many terms, only shortcomings when it lacks a definition and frustrates its users?
Venn diagrams are a key concept in Information Architecture. See http://www.iawiki.net/DefiningTheDamnThing.
Positioning diagrams (Gartner loves their "magic quadrants," Tony hates them) are a related concept.
Broader, Narrower, Related, Preferred, etc. are the terms of art in a Thesaurus. We not only use them throughout the CmsGlossary, we define them there for the newcomers. [We can replace Related Term with See Also in the web service connector.]
My goal is that this glossary will be one we can proudly share with our Information Architect colleagues.
What do others think?
I agree. Content management and certainly information architecture are very broad areas.
We should think of a more usable interface to present the glossary, though.
A connection between thesaurus, taxonomy, glossary and CMSML would also be really helpful. It's a step too far, but we should strive for something like this.
Cheers,
Erik
> Broader, Narrower, Related, Preferred, etc. are the terms of art in a Thesaurus. We not only use them throughout the CmsGlossary, we define them there for the newcomers.
Ah yes, but in my changes I've started to eliminate the need for the BT, RT links by replacing them with something more user-friendly ...
James
Something more user friendly than the BT, NT, RT links is possible (if not likely) but I think these are still standard terms worth defining in the glossary itself.
Don't see any harm in leaving them in...
Perhaps some categorisation of terms would be useful, so you could look at a filtered list of non "techie" terms.
What did you have in mind to do instead?
* I put the "see" and "see also" links into the main glossary page, making these RT and PT links explicit, but without the jargon.
* In the definitions, I just spelled things out in plain english, such as:
"See PublishingModels for more on static versus dynamic publishing"
Our goal is to make something that informs people, rather than the technical goal of creating a "controlled-term thesaurus" or equivalent. Most readers won't be librarians, and I see no reason to force them to learn about this before they can understand the glossary.
Anyway, just my $0.02,
James
> Hi James,
> Something more user friendly than the BT, NT, RT links is possible (if not likely but I think these are still standard terms worth defining in the glossary itself.
> Don't see any harm in leaving them in...
Hi John,
Thanks for supporting the idea of a comprehensive technical glossary - aimed at true professionals and also available as an educational tool for the inquisitive newbie. We do not have to use these technical terms in our client work, but we certainly better know them and the concepts behind them.
I hope our work will be of the same or better quality than the IAGlossary (http://www.iawiki.net/IAGlossary), which currently has about 35 terms.
We have a proposed list of over 400 terms, and have written definitions for about 125 so far. (Just as exhausting, but much more rewarding, than editing hundreds of CM website descriptions for DMOZ/Google.)
These terms have been gleaned from a close reading of all the major books on CM (Boiko, Rockley, Hackos, Nakano, Addey/Suh, McGovern, Greenspun, and Stahl - auf Deutsch), from online glossaries that cover CM, and from books on closely related fields, like IA.. I especially scanned all the indexes. It also used the Boiko/Hackos/Rockley CMS Evaluation Thesaurus.
We need a definite editorial policy for the glossary, and a standard template for what should be included (like obvious RT, BT, NT, etc, but also VT and UF etc.) . If we have a good structural design, we can rebuild it in XML to be syndicated and presented in other forms (via XSLT). It could feed future editions of CM books. Bob Boiko wants XML inputs for his second edition glossary. I hope it appear somehow on all our CM websites, possibly filtered on metadata like "non-tech" if necessary..
Erik Hartman and others are rightly concerned about the limited presentation possibilities in the current Wiki website. But the Wiki works fine as a collaborative writing tool for us to collect the content into buckets. James Robertson and Brendan Quinn have contributed additional content so far. Edit privileges are available to anyone else who may contribute.
Any chance you might volunteer for the Glossary working group? You are our AIfIA liaison, and I value your IA insights, so even if you don't write any definitions, you would be helpful. I hope that many of these definitions, and possibly the architectural design if well done, would be adopted by AIfIA, so the CmsGlossary could be a demonstration example of practicing single-source publishing - maintaining our core content in one place. This is also my goal for other major community resources, like the calendars, resource listings, product listings, feature comparisons, news feeds, etc. See http://www.cmsreview.com/CMSFeeds.html
What do you and others think?
I have been reading your new and entries, where I can track them down. I see you changed the old Static vs. Dynamic Publishing to PublishingModels.
Thanks for all your work. But I hope we can get some consensus on new directions, especially if we want to drop work already done - there are many man-hours in these pages. More than $0.02.
There is no problem adding new material in a new style and format while we arrive at a policy.
James Robertson wrote:
> I've spent a little time tinkering with the glossary on the CMS Wiki: http://www.cmswiki.com/tiki-index.php?page=CmsGlossary
> * I've added a handful of entries, just some easy stuff like RecordsManagement and DocumentManagement.
> * I've done some housekeeping on the main list, particularly putting in "see" references. If used for the acronyms, this will avoid us having to put in the same information twice (eg CMS and ContentManagementSystem at present). See what you think about my approach.
I like this approach a lot. It works fine for the acronyms. We should always check that the acronym also appears in the definition.
> * I've emptied out the CmsIssues section, and moved the links there to either the CmsGlossary or IntroToCMS. (Bob, can you get rid of the link in the sidebar nav to this section?)
Done.
> * I think we should get rid of the CmsFeatures page, as this would now seem to be duplicated by the CmsGlossary.
This is not at all the case. The Features list grows out of the CMSML effort (http://www.cmsml.org) to identify the key characteristics of CMS that can be used to classify them. See the Gilbane Report at http://www.cmsreview.com/Reviews/GilbaneReport1.pdf. It is also the metadata behind the CMS Review Feature Comparator - http://www.cmsreview.com/Features/Lists.html
It is true that all technical terms used in the Features List should be defined in the Glossary. But there are many more terms in the Glossary than the 100 or so key features.
> * Overall, I think we should we should whittle down the content to just the good stuff, and eliminate any content that is duplicated on other sites.
Let's all discuss this. I think the CmsGlossary should be the definitive reference, one-stop shopping, so people need look no farther for definitions. And there are a lot more branches to be grown before we get out our knives and start whittling away at work already done.
> If this is one of the deliverables of the outwards-focused organisation, then I think we need to consider who our target audience is, and how we should communicate to them.
It is first and foremost for ourselves, but anyone who looks at a site called CMS Consultants (or joins us in our larger community) should be able to learn a lot from our glossary. So we need a clear, jargon-free writing style (even as we define our jargon) and the definitions should be complete, relying on other glossed terms as needed.
> If general readers are our audience, then we need to supplement the currently quite technical content with a lot more business-focused material.
This is OK with me, if the terms of CM business art need glossing, they belong in our glossary.
I guess we need a cms with some version control to manage the glossary list. Or at least some prepublication vs. Publication.
We have something like this in the Netherlands. It's open source (we returned it to the MMBase community). I also mentioned it to Tony concerning the Best Practices.
With your permission I'll ask some 'colleagues' of mine in the Dutch government if we can somehow present this tool to the CM Pro community.
I like Wiki a lot, but for this kind of thing the Wiki is not the right tool.
My 2 (euro)cents.
Erik
Volunteers wanted!
CMS Consultants is looking for volunteers.
To inquire about volunteer opportunities, contact the volunteer co-ordinator.
and a page turning image 
