Re: when to implement a CMS -- [long entry]

[ Warning: long entry ]

[ Speed-reader's gist: if your (non-CMS) content is in XML, can XSLT help get 
you successfully into a (future) CMS?  -- Comments welcome... ]

==============
I'm curious what people on the list view as the role XSLT might play, in 
helping one "recover" from having to create a website once with no CMS (but 
authoring all content in XML!), and then being later in a (reasonably good?) 
position to transform what you have into whatever you learn your eventual CMS 
is going to require.

Don't know if any of the responders to this thread (or anyone else!) who's had 
so-so or worse experiences going to CMS after investing in building a non-CMS 
site, might fit the situation I'm describing?  That is, had gotten everything 
(content, navigation, special page/section (sub)-headers, etc.) into XML, 
which were therefore (reasonably?) processable to new (CMS-determined) 
structures?

I completed a small-to-midsized-ish project that had as one of four primary 
goals, to "create site content in a format that is 'forward-looking' to 
eventual Content Management System (re)-use."   
  http://reilly2001.info/xml-2-html/ch01.html
That is, unlike the original asker here (Sonia Carter's post; snippet at 
bottom of this e-mail), we knew the CMS would be implemented later (no 
tormenting issues over "maybe do CMS now, along with re-design").  

We were simply executing a complete site re-design without any CMS, but we 
were doing pseudo- or preparatory- CM, by basic means of identifying and 
authoring page fragment 'content types' in an XML we called "BusinessML" 
(essentially extending a structure-only subset of XHTML (small # of very 
basic tags), adding to that as many (proprietary) new semantic elements as 
could be found to apply to the content (e.g. <patentNumber> <dateLine> etc.).

Now, I am not involved in the eventual migration project to the CMS, and so 
haven't lived through the reality of what then happens, but I like to 
(reasonably?) think that the baseline XML we created is 
useful/processable/salvageable to the forthcoming CMS, -- but, maybe I'm 
wrong.

Just to look at what's been mentioned in the thread:
---------------------------------
= Peter Kearney, in his analytical long-ish post of helpful recommendations, 
mentioned "build some small applications for changing content areas" in his 
"lowest bid" scenario (1. low budget, no time, etc.).
  ---- I'm wondering if processing XML against XSLT is/could be part of the 
"small applications" thought there?  Or maybe it was more straightforwardly 
providing some direct editing capabilities of the HTML?

= Lennart Regebro says (from the trenches, it sounds :^) ), all but one 
project "thrashed the site completely" and started from scratch.  
  ---- Hmmm.  Not such great experience(s) to live through.   (btw, what _did_ 
happen on that one project...?)

= Mark Thomas had some thoughtful comments about CMS design restrictions, and 
how "you can't just go from unmanaged content to managed content at the flip 
of a switch...some deconstruction [is required]."
  ---- Can "unmanaged" content be avoided (to some degree?) Can the 
deconstruction be somewhat planned for?  Can a good level of granularity in 
content type determination on the initial non-CMS site, protect you from 
missing the boat of using XSLT to "re-"construct the XML from site #1 into 
the XML/CMS constructs needed for site #2?  (dunno)

= And Adam Gaffin noted that by (in the end, after the "awful[ness]") having 
to do the non-CMS site first, they benefited from not worrying about the CMS 
restrictions overmuch.  Enough subsequent "hunker[ing] down" got the eventual 
CMS version of the site to recreate what the non-CMS site had.
  ---- I guess I'd be curious to learn more, in particular whether XML content 
in 1st site was part of the approach, and if so, whether XSLT was used to 
re-configure content for the 2nd (CMS) site.  And if not XML, what was the 
nature of the "hunkering down," esp. as regards (re-)processing the content 
itself (scripts? macros? manual undertaking(s)? other?).
Also, any interesting "impedance mismatch" examples coming out of the 
reconfiguration of content from the non-CMS mode as you went into the 
constraints of the new CMS?
---------------------------------


So, as I say, I'm posting to the list out of a genuine curiousity about how 
others view the ideas that we applied in our work: 
   - XML tags on the content, at a certain degree of granularity (page 
fragments), with the expectation that transforms (XSLT) could eventually 
re-render that content according to the needs of future CMS applications.

(To try to respond to my own question, just a bit:
- it may be that more specialized bits like navigation are a lot less 
transferrable, say, to Interwoven, or Content Server, etc.
- but I'm wondering about all that "body"-area content - can it be transformed 
to be ready to breakdown/import/use in those CMSs?)
    (And (to Adam Gaffin's point) re: specialized bits like navigation, even 
if you can't just "auto-import" the navigation XML data file per se, at least 
the thinking and design work you did creating it means you're in excellent 
shape to "re-"do the navigation inputting into the CMS (yes?).)

Naive?  Reasonable?  Thoughts, comments, experiences...

Many thanks!
William Reilly
william-r5yOdLURo8qF/[email protected]
Somerville, Massachusetts U.S.A.

If curious:
  http://reilly2001.info/xml-2-html/index.html
  DocBook system documentation
  (~150 printed pages (many screenshots, etc.) as .PDF)
  [by the way, I consider this document simply open to any interested party.]

-------------------------------
Disclaimers & Notes!
-------------------------------
- This "XML-2-HTML" system is not a Content Management System.
- It lacks many, many aspects of a CMS.  No data entry (just plain text/XML 
editors).  No special MS-Word conversion tool.  Nothing workflow-ish. No 
users management.  No versioning (we used CVS). No special publications mgt. 
(though you could work towards that...).  No personalization (no app 
server!).
- It is a one-click (script kickoff) offline website build (& maintenance) 
system.
- The (not large) site it creates is nearly all static HTML (though the bit of 
ASP functionality code is also enclosed within processable XML 
<![CDATA[...]]> sections -- That's something I'd really like to take farther, 
with JSP in its XML format (<jsp:>), avoiding CDATA sections, if possible. 
TBD.))
- It employs a "3-hop" XSLT pipeline to go from BusinessML to "SiteHTML." 	  
    (>> Please << note: this use of XSLT within the system *differs* from my 
question above to the list, about other (future) XSLT being written to 
transform current content to new, CMS-driven structures.)
- It can do aggregations of small content types (e.g. all individual patents 
rolled up onto a single patent page).
- It can do derivations of small types out of larger ones (e.g. full press 
release can also publish out brief, short, and longer abstracts of itself, 
for home page, P.R. page, and 'P.R.s for this year' page)
- Meta-info ("recipe") XML files tie things together, at various levels (site, 
page, fragment content, as well as fragment layout choices)
- HTML templates, an XML "buildlist," and a couple Java classes put pages 
together (we're talking about offline batch processing, of course)
- Ant drives everything

I'd be happy to answer any questions.

P.S.  Something I found - different, yet analogous: XslGen
	http://www.syntext.com/products/index.htm#XslGen
	"XslGen is a simple, but effective tool for web site content management. 
Develop HTML layout in your favorite HTML editor, and keep your content in 
XML. XslGen lets you seamlessly fuse your HTML templates and complex XML 
content into a sophisticated web site!"
(They use 'make,' we use Ant + some Java.)


++++++++++++++++++++++++++++++++
THREAD-TO-DATE (gist)   (reverse chron)
++++++++++++++++++++++++++++++++
On Wednesday 20 August 2003 09:38 am, Adam Gaffin wrote:
>
> Yeah, we tried the old "install a new CMS and do a sitewide redesign at the
> same time" trick and it was awful (OK, in part because we had layoffs right
> in the middle of it all). We wound up launching the redesign first, then
> implemented the CMS. I think this approach worked better for us because by
> the time we were done with the redesign we knew exactly what we needed to
> get the CMS to do. Had we done the reverse, we might have had to make
> compromises on the design because of "oh, the CMS can't do that"
> considerations - instead, we just hunkered down and figured out how to make
> the CMS do what we wanted.
>


++++++++++++++++++++++++++++++++
Mark Thomas <ThomasM-wRZ/[email protected]> wrote:
I agree. Even the most flexible CMS is going to impose some
site-design restrictions, and you will likely not know what they
all are until you try to implement. You can't just go from
unmanaged content to managed content at the flip of a switch.
A truly useful CMS implementation will necessitate some
deconstruction.

If you're going to do anything more substantial [than look-and-feel change] 
(i.e. coming up with new site templates, navigation,
etc) then you'd save some effort by waiting until the CMS is
implemented, otherwise you may find yourself doing it all again.


++++++++++++++++++++++++++++++++
Lennart Regebro <[email protected]> wrote:
In every project but one that I have been involved with where there is 
an existing site which they have wanted to migrate to the CMS, they have 
ended up thrashing the site completely and redoing everything from 
scratch. Only one did indeed transfer the content.

Get a CMS, and redo the whole thing from scratch. It will be faster and 
cheaper.


++++++++++++++++++++++++++++++++++++++++
Peter Kearney <[email protected]> wrote (from much longer post):
1. Low budget, low CMS skills, short time frame - forget the CMS, do the
best you can with the web site and build some small applications for
changing content areas

++++++++++++++++++++++++++++++++++++++++
[ORIGINAL QUESTION]
Sonia Carter <[email protected]> wrote:

...what are the pros and cons of migrating content over to a CMS
before or during a site redesign or once the site is built?

I am currently doing a content audit of the old site and I foresee that lots
of content will need to be updated, rewritten and chucked out.
++++  /END   ++++++++++++++++++++++++++++++++

--
http://cms-list.org/
more signal, less noise.