Well, we've been testing for two weeks. Slowly learning the ins and outs of Webtop and XMetal working under one umbrella. The system is clunky and does not exactly follow the workflows that we had envisioned. But it is possible to get from point A to point B, it just takes all of us helping each other figure out the duties specific to our roles in a given workflow. The defined roles include "writer," editor", "specialist", "supervisor", etc. These roles are sometimes played by the individuals who will play them in real life, and sometimes we switch off; e.g., I will take the supervisor role now and again.
Beyond the clunky-ness, we've run into a difficult issue. The server, run by our own company's Documentum team, has a specific version of EMC software which is NOT playing nicely with the Flatirons server. Inturn, Flatirons has asked our Documentum team to update the EMC software version to 6.5 I think, versus 6.0. This is a bit of a ridiculous request as our particular version of said software is enterprise-wide, across many different branches, in many different countries. So we're about to tell Flatirons that is impossible and that our contract says we should be able to run this smoothly off of the 6.0 server...keep your fingers crossed.
UPDATE
Flatirons is stalling. As a result we have halted testing. More later...
Return to HOME page or leave comment below.
Sunday, December 14, 2008
Monday, December 1, 2008
Week 5 - Under Construction
I am in the midst of revamping this post for legal reasons. Check back later.
Return to HOME page or leave comment below.
Return to HOME page or leave comment below.
Monday, November 10, 2008
Week 3 - CMS Training
So we began our first session of training today with Flatirons. The training was given by Sam, senior developer, who also engineered the system from the get go. It was interesting to hear him explain to those of us who have slim backgrounds in programming just how the system works. He went through a basic, regular document workflow (explained in prev. blog) and began to work through errors that the system would occasionally experience. He then had us begin working directly with the system -- setting our preferences and creating projects to sample the functionality of the workflow.
We were able to set up projects just fine by beginning in Webtop and using its widgets, then launching XMetal and actually editing the xml tags and content. Going back into Webtop, we would then set the project up for review by those designated as reviewers.
Here was one of the major problems that we had to find a quick workaround for: every time we launched Webtop our preferences would not be set. Webtop had trouble saving our preferences, in other words. We discovered that this occurred because our browsers cache was automatically clearing itself out every time we logged on or off our browser. This represented a huge problem because it is a company-wide standard: web browser's caches must be cleared every time a user logged off the Internet. Sam said he would work on the issue and, in the meantime, we could save our preferences in a .txt file and just reload those upon system start up.
I considered this to be an inadequate condition of the system thus far.
Return to HOME page or leave comment below.
We were able to set up projects just fine by beginning in Webtop and using its widgets, then launching XMetal and actually editing the xml tags and content. Going back into Webtop, we would then set the project up for review by those designated as reviewers.
Here was one of the major problems that we had to find a quick workaround for: every time we launched Webtop our preferences would not be set. Webtop had trouble saving our preferences, in other words. We discovered that this occurred because our browsers cache was automatically clearing itself out every time we logged on or off our browser. This represented a huge problem because it is a company-wide standard: web browser's caches must be cleared every time a user logged off the Internet. Sam said he would work on the issue and, in the meantime, we could save our preferences in a .txt file and just reload those upon system start up.
I considered this to be an inadequate condition of the system thus far.
Return to HOME page or leave comment below.
Monday, September 22, 2008
Week 2 - Deciding on a Content Management System Team
As stated in the previous post, we had to axe Astoria from implementing a new content management system for us for various reasons. We sat in limbo for weeks. Finally, an executive in our company said that his own IT team, running a Documentum software, could help in our search for a content management system. The Documentum platform is build by EMC. He also suggested that he knew of a solutions team that could pull everything together for us, as far as integrating the Documentum platform with our data inside an XMetal repository. That team was Flatirons.
Soon thereafter, had our fist meeting with Flatirons. The Flatirons team comprised a Senior Programmer/Developer, a Business Analyst, and a Product Manger. The entire team on our side was present as well (10 Writers, 2 Editors, a Support Specialist, and the Documentation Manager). We had scheduled a 4-hour meeting to hash our work flows, having a much better idea for our goals and requirements versus when we went through the initial steps with Astoria. Also, our roles were already well defined, based on our current responsibilities in our daily routine; although, we were open for any augmentation of roles that the new content management system might require.
The meeting took a total of 8 hours, eating up the rest of our day, and we had to do another full day to further solidify the workflows. In other words, it was no easy task trying to define and then visualize the workflows. Several debates (some heated) took place over what types and how many workflows we needed in the first place, what kinds of documents fit in which workflows, the steps of the workflows, and how the system would operate in each stage of the workflows, and what was to be the outcome of each workflow.
Thus, we first had to separate all the different types of deliverables we currently create. That translated into 4 different workflows: (1) a new, regular document, (2) update of a single or multiple sections of a pre-existing document, (3) a field letter, and finally (4) our online help system. Then, each workflow required it's own steps and stages to be defined. Those steps included, how often the content needed to be reviewed and who would review it; where the content would go after being reviewed; how each version would be saved after the content had been updated with suggested edits by the reviewers, as they were marked on an editable PDF; how the system would denote the different versions in the user interface (Webtop), who would have what types of rights to the content (i.e., write versus read-only); and how and at what point would the final deliverables be created. All of these steps and stages engendered several different decisions. And each one required discussion. Seems like a lot? It was. That’s why it took two days.
Moreover, an overriding pressure loomed beyond just time and money that these two days cost. Based on our decisions in those meetings, we laid the ground work for how the content management system would forever operate after Flatirons had long since implemented the system. Our main concern was that if we made a mistake in deciding on the workflows and their subsequent steps and stages, we would be forever in trouble, having to come up with whatever inadequate workaround we could muster. In this sense, the business analyst was critical in translating our current processes to the programmer, who would then counter with either a “that’s possible” or “no, we can’t do that.” The meetings were of course tedious and exhausting, but ultimately necessary to ensure we did not get an out-of-the-box content management system that was substandard for our needs.
Return to HOME page or leave comment below.
Soon thereafter, had our fist meeting with Flatirons. The Flatirons team comprised a Senior Programmer/Developer, a Business Analyst, and a Product Manger. The entire team on our side was present as well (10 Writers, 2 Editors, a Support Specialist, and the Documentation Manager). We had scheduled a 4-hour meeting to hash our work flows, having a much better idea for our goals and requirements versus when we went through the initial steps with Astoria. Also, our roles were already well defined, based on our current responsibilities in our daily routine; although, we were open for any augmentation of roles that the new content management system might require.
The meeting took a total of 8 hours, eating up the rest of our day, and we had to do another full day to further solidify the workflows. In other words, it was no easy task trying to define and then visualize the workflows. Several debates (some heated) took place over what types and how many workflows we needed in the first place, what kinds of documents fit in which workflows, the steps of the workflows, and how the system would operate in each stage of the workflows, and what was to be the outcome of each workflow.
Thus, we first had to separate all the different types of deliverables we currently create. That translated into 4 different workflows: (1) a new, regular document, (2) update of a single or multiple sections of a pre-existing document, (3) a field letter, and finally (4) our online help system. Then, each workflow required it's own steps and stages to be defined. Those steps included, how often the content needed to be reviewed and who would review it; where the content would go after being reviewed; how each version would be saved after the content had been updated with suggested edits by the reviewers, as they were marked on an editable PDF; how the system would denote the different versions in the user interface (Webtop), who would have what types of rights to the content (i.e., write versus read-only); and how and at what point would the final deliverables be created. All of these steps and stages engendered several different decisions. And each one required discussion. Seems like a lot? It was. That’s why it took two days.
Moreover, an overriding pressure loomed beyond just time and money that these two days cost. Based on our decisions in those meetings, we laid the ground work for how the content management system would forever operate after Flatirons had long since implemented the system. Our main concern was that if we made a mistake in deciding on the workflows and their subsequent steps and stages, we would be forever in trouble, having to come up with whatever inadequate workaround we could muster. In this sense, the business analyst was critical in translating our current processes to the programmer, who would then counter with either a “that’s possible” or “no, we can’t do that.” The meetings were of course tedious and exhausting, but ultimately necessary to ensure we did not get an out-of-the-box content management system that was substandard for our needs.
Return to HOME page or leave comment below.
Saturday, August 30, 2008
Week 1 - Implementing a Content Management System
We have been struggling with implementing a content management system that suites our needs for several years. Then, late last year, we came across an interesting team of IT solutions called Flatirons. They impressed us with there demos and so we gave them the green light, sinking more money into this long-term endeavor of content management.
Before agreeing to hire Flatirons, we were working with a company called Astoria. They did not work out for several reasons. First and foremost, they offered us a 90-day trail on an out-of-the-box CMS system that was not suited for our content needs. We did not know that it would not be suited for our needs, however, because we did not even know what our needs were, which leads into problem number 2. We assumed that the CMS system offered would fulfill our requirements, without having ever defined them in the first place. With that, we had no goals to test the system against, leaving us confused with an overall lack of guidance. In short, we had no plan or model to use as a basis of comparison to judge the new system.
Then technical issues began to run rampant throughout the systems. These problems ranged from server access issues to pop-up windows appearing blank to false graphic conversions; also computers simply crashed for no apparent reason. Moreover, the Web Client interface was not intuitive and the ability to directly comment on a chunk of information while in a review status was non-existent.
Transfer knowledge issues also arose...For further details, see Rebekka Anderson's dissertation analysis by going to her HOME PAGE. She presents a detailed qualitative study analysis of how we have dealt with content management systems in the past and how we finally decided upon hiring a different company than the one we originally contracted.
Ms. Andersen also has some interesting insights to the world of CM at The Rhetoric of Enterprise Content Management (ECM): Confronting the Assumption and Transforming Technical Communication.
Return to HOME page or leave comment below.
Before agreeing to hire Flatirons, we were working with a company called Astoria. They did not work out for several reasons. First and foremost, they offered us a 90-day trail on an out-of-the-box CMS system that was not suited for our content needs. We did not know that it would not be suited for our needs, however, because we did not even know what our needs were, which leads into problem number 2. We assumed that the CMS system offered would fulfill our requirements, without having ever defined them in the first place. With that, we had no goals to test the system against, leaving us confused with an overall lack of guidance. In short, we had no plan or model to use as a basis of comparison to judge the new system.
Then technical issues began to run rampant throughout the systems. These problems ranged from server access issues to pop-up windows appearing blank to false graphic conversions; also computers simply crashed for no apparent reason. Moreover, the Web Client interface was not intuitive and the ability to directly comment on a chunk of information while in a review status was non-existent.
Transfer knowledge issues also arose...For further details, see Rebekka Anderson's dissertation analysis by going to her HOME PAGE. She presents a detailed qualitative study analysis of how we have dealt with content management systems in the past and how we finally decided upon hiring a different company than the one we originally contracted.
Ms. Andersen also has some interesting insights to the world of CM at The Rhetoric of Enterprise Content Management (ECM): Confronting the Assumption and Transforming Technical Communication.
Return to HOME page or leave comment below.
Tuesday, June 24, 2008
Content Management System - Definition for Dummies
Essentially, a content management system is "technologies, tools, and methods used to capture manage, store, preserve, and deliver content across an enterprise" (Assoc. for Information and Image Management, 2006).
What this usually entails is a system based on xml and style sheets which follow the DITA programming language. DITA allows content to be stored in chucks. An xml program, such as XMetal then takes those chunks and formats them into a final deliverable. Control of the system is usually done through a intuitive user interface, such as WebTop.
Also, I strongly advise clicking on some of the companies listed to the right to see what kind of tools and methodologies are offered.
Basic Terms:
DITA = Darwin Information Typing Architecure. This is a language standard that defines XML for publishing, authoring, and managing content. In other words, it's a series of guidelines for XML to follow. Once in the DITA shell, XML becomes structured into attributes and elements all geared to standarize documents and reuse content across multiple areas.
XMetal = Software by Just Systems(R) that uses DITA and XML. XMetal is the software interface that allows you to look XML layouts of deliverables and save chucks of information of those delivrables into a repository.
XML = Extensive Mark-up Langauge.
DOCUMENTUM =
Return to HOME page or leave comment below.
What this usually entails is a system based on xml and style sheets which follow the DITA programming language. DITA allows content to be stored in chucks. An xml program, such as XMetal then takes those chunks and formats them into a final deliverable. Control of the system is usually done through a intuitive user interface, such as WebTop.
Also, I strongly advise clicking on some of the companies listed to the right to see what kind of tools and methodologies are offered.
Basic Terms:
DITA = Darwin Information Typing Architecure. This is a language standard that defines XML for publishing, authoring, and managing content. In other words, it's a series of guidelines for XML to follow. Once in the DITA shell, XML becomes structured into attributes and elements all geared to standarize documents and reuse content across multiple areas.
XMetal = Software by Just Systems(R) that uses DITA and XML. XMetal is the software interface that allows you to look XML layouts of deliverables and save chucks of information of those delivrables into a repository.
XML = Extensive Mark-up Langauge.
DOCUMENTUM =
Return to HOME page or leave comment below.
Subscribe to:
Posts (Atom)
