Re: Site Design Strategy

asinning wrote:

This is my first post to this group. I've been trying to figure this out on my own, but I keep running into complications, so I've decided to get some help. Much thanks for any help! I've been writing php server application for a couple of years, but now I'm turning my attention to re-building our company's aging website. This is a big project and is going to require a solid foundation. At the crux of this post is the following question: How do you develop a very robust, dynamic web-site, but also allow non-technical people to contribute? There must be an easier way. Here are my working assumptions and my strategy. Please help me if I'm thinking down the wrong path. Assumptions: 1) Non-technical people in the company need to be able to build pages, and they should be able to post their pages without bothering me. We have a tech-support person who will be able to help them, but she has zero programming knowledge and only a superficial understanding of HTML. 2) Every page needs to reside within he "shell" of the web site. This includes header(the top-level menu) left-side menu (a dynamic, context-specific menu) content (this is what the non-technical people will produce) footer (your standard fare text-based links) 3) I don't want to use frames, and I don't want to use Dreamweaver templates. Strategy: Currently, I am working on the following model:

     There is a top-level index.php page.  This is the target of EVERY

page on the site.

     The page that gets loaded in depends on the parameters of

query-string. It's very simple, if the query string reads "?target=products/gsp", then my php will look for a site-relative document such as "products/gsp.htm" OR "products/gsp/index.hml". Then, this document will get "included" as the content in my "shell".

     Well, this works to a degree, but it requires that people use

"site-relative" paths for all of their graphics and links, which is way, way to much to ask. After all, people are using WYSIWIG editors such as Dreamweaver and even Word to build their pages. Typically, site-relative paths don't work in these environments. They shouldn't need to upload their document to preview it.

     It also requires that they put their page within a 550 pixel wide

-td- tag. I'd love to drop that requirement. So, now I considering the following: A parser that will convert any content into "includable" form. Relative paths will be translated to the site-root, etc. I'm a bit stuck here.

Maybe I've misunderstood but here's a thought: I'm not sure what they're actually doing with these pages but it's usually in my experience something like a headline, a block of text in which you can allow certain HTML tags (you can use tidy within PHP) and some images and some links. Is there more that these folks are doing? Is there a reason to give them so much flexibility in design? Are these home pages as in personal showcases or department-specific offerings? You probably want to set up each user with their own directory or db area so they can upload all their images through your control panel, enter their text and have everything in one place for each user. If you give users the opportunity to put in unlimited matched sets of Headline, text block, image float right left or center (cna cation if required) plus <strong>, <em> and a limited href capability 99% of people will probably be happy. Make sure you rename all images they upload to remove spaces, weird characters and duplicate names. You can use a naming convention like user.image.x. or even md5(imagename). So this way, each user gets a user directory in which all image links are relative to that directory, all images are righ there and ties to the user.

     It also requires that they put their page within a 550 pixel wide

-td- tag. I'd love to drop that requirement.

AAARG. We use a wrapper in XHTML, putting everything in <div> tags so that later, when we change the format, they're not stuck in a <td> as you rightly worry about. Using <div> and CSS positioning increases exponentially your flexibility both now and later. And requires fairly modern browsers but according to our logs almost everyone has them. And if they come in using lynx it'll still *work* in that they get all the info in sensible order. Netscape 4 and IE 4 users are out of luck, but then, they often are anyway in terms of support on the web (please let's not devolve into a flame war over that statement). HTH and makes sense.