Redesign Conundrum

[cluksha]

Background:

I am working on redesigning a current magazine web site. The site posts every article online. (controlled circulation so it is free to qualified readers. Some pages are access prohibited.) We have every article back to 1996 and most of them are on static pages.

My choices, that I can see, are to continue making static pages, continue making static pages using templates, have all the articles entered into a database record and pull each article in the same fashion many others do - "?storyid=44901", or what I just now thought of was having the article itself be a static page with style sheets and make a db record for each article with a file location for the content. (index.cfm?storyid=44901 and the index does a cfhttp of the static page.) Hey that sounds pretty good now that I think of it.

Well, my dilemma is really that I have never had the chance to do it myself and have seen it done other ways that I just thought were insane. Does anyone have any opinions on how I might best do this to help down the road?

Pros and cons -
static pages: Pros - I can format the pages as I wish with the images properly placed etc. Cons - we all know those and they far outweigh any pros that I can think of.
Static w/ Templates: Pros- I change a template and all the static pages change. - Cons - 1000s of pages will have to be uploaded. Major time and server load.
Article Code entered into DB record: Pros - easily pull article content via short url and no static pages. Code gets rendered in the fashion stated by container page css. Web editor can't change layout of whole page Cons- The web editor (small team environment) needs to create the page in html, strip all the opening code and paste what is left into a record's field. All the image calls etc must be full links, not relative - I think?

Any good ideas? Anyone doing this kind of thing now and really like the way it works? As it stands now, I will have to go back and recode all the old pages -over time- to fit into a new model with current styles. There are 3 different iterations already of our site, so many pages contain an old navigation scheme built into the page, while others were built in frames etc. - YUCK!

Thanks everyone for the input.
Chris

 

[ChrisHunt]

Sounds like you've got a major job on your hands, here's some more food for thought...

You're right, totally static pages are a non-starter, but templates are a possibility. The "Major time and server load" only happens (as I understand it) when you first upload the pages and/or when you make changes to the templates - once done, it give the server the least work to do. It does tie you to producing your pages through whatever template system you're using to add the bits in though.

An option you don't mention (and one I use for a couple of my sites) is to use Server Side Includes to put in the navigation etc. as each page is served. It's a bit like templates - your pages consist of static HTML to mark up just the articles, with special comments to say "include the content of this other file here". See faq253-3309 and faq253-2000 for more info on SSI.

The database option sounds good too, provided you have the ability to write such a system, or the budget to buy one in.

I think a factor you should be considering is "how are articles going to be entered into the system?". Are the people doing it comfortable writing raw HTML (or some simplified markup language such as the one used on this forum), or are you looking for a WYSIWYG solution?




-- Chris Hunt

http://www.mcgonagall-online.org.uk

http://www.napitalia.org.uk

http://www.leicesteryha.org.uk

 

[cluksha]

To be honest - I will be using cfincludes for the framework already. SOrry I didn't mention it.

But what I think I may do is something akin to this....

url?art=23
Include Header
Include Navbar
Include content caller page
Include footer

Where content caller page says "search db for artid=23, find it's file location that is stored in the field FileLocation, and then <cfhttp \#FileLocation#>"

If this makes sense to anyone - please let me know I am on the right track. IF not please stop me now for I was just told to move ahead and move ahead fast.

Thanks!
Chris

 

[tviman]

IMHO, you should use a dynamic approach, either text files or databases, to keep the ability to be flwxible with the overall magazine layout. The thing that would worry me is every time the magazine makes an overall design change (new colors, new fonts, new column placement, etc.) past articles will have to follow the new format. This may be OK for you but it's not how good magazines stay in business.

If it were my magazine, I'd store the articles in one database and the formatting in another database and link the two files by an "article number". Therefore, when you want to view an article written in 1998, the format database would call up all the format features that that were present in 1998. Yes, it's a little more work but in the long run, your magazine will have the ability to show it's evolutionary cycle to it's readers. Additionally, I'd make sure that the articles were in a standard text format and let the format database take care of the mark up, thus alieving the burden of writing HTML code, or having to extract HTML tags from an article.

There's always a better way. The fun is trying to find it!

 

[cluksha]

The only problem I see with keeping the article in text file etc. is that the articles are not just plain old every day text. There are images placed throughout each earticle and there is plenty of formatting going on.

Maybe I misunderstood you, but the text needs to have the markup in order to place the images properly etc. As for the styles - they will be separate from the text of the doc itself.

The other thing is that I am attempting to make this as easy on the web editors as possible. They, right now, only know how to create a full html page in front page and know absolutely nothing about styles. (The biggest issue is that they refuse to change their ways YUCK!) But I am attempting to change all that.

Thanks!