No matter how many fancy acronyms and technologies you throw at your website, it's still all about the customer. And the customer really only cares about one thing: how does your site respond to their needs?
When you cut away all the fancy marketing talk and verbiage, users aren't judging you on your standards compliance or your integration with your back-end (ahem) systems. They're judging you on a completely subjective scale.

How would you deal with these two different sets of criteria? What about when you have 10 users, and 10 different sets of criteria? 1,000? A million?
Cater to your users with dynamic websites
Enter dynamic websites... sites that attempt to provide different experiences for different users. If you can make your site appeal to different users, each with their own personal likes and dislikes, then you're not stuck satisfying one and hacking the other off.
The basic approach to this is having different versions of your site... and different users each get their own, customized version.


Read the next installment: Getting to know you







By 










How would I create and maintain both version of the site? It depends on how different the two versions are. If they both have mostly the same content but a different look and feel I would simply have two sets of CSS, image, and JavaScript files. Then, I'd use a parameter in the URL to indicate which version to use (or use different URLs all-together that serve the same application but the application reads the URL and knows which version to use).
If the content itself is different (or organized in a vastly different manner) between the two versions then a different approach is needed. The specific answer would depend on the specific needs of both versions but the general approach would be to make sure the web application was built in multiple tiers to promote re-use as much as possible. This could be done by sharing a common code base for tasks like database access. Or, a third web application could be created that only provides a web services API which is then used by the two different websites.
There are always technological solutions but first you are going to have o identify the different groups and what there needs are. Have you been able to identify multiple members of each group? You can't provide a separate solution for a group of one. When a user belonging to a specific needs group comes to your site how will you identify the person as a member of that group without driving them away?
I'd go with Ron...the first question to answer is...how do you identify that the user wants to change anything in the first place? And how to (unobtrusively) allow them to do it?
Maybe a simple designer (a-la the iGoogle layout tool?)
Allowing widgets to be collapsed/moved...
OR (easiest for the user)...a "I like minimalism/Innundate me with graphics/find a happy medium" set of radio buttons along the top? (with thumbnails of each)
Pair that with #1, and they can get as simple or as "make my eyes bleed" as they prefer.
In the end, (my .02) it seems to me most folks want to get in and _do_ something, not diddle around with the site's layout. Then again, perhaps part of the customization focus is allowing folks a degree of control...then they're happier...then they buy more...then they come back.
Hmm. Bears thinking about.
I would prefer having a single page. I guess more than concentrating on the target audience(of course we know who are potential customers for the product), we can do a good design that supports what we market.
For example if we sell dress for kids it should have all fun stuffs to suit kids. And if it's a adult dress being sold, the page layout and style should be made to suit them. I guess color, background, layout and font-size could make a huge difference even if there is no great db-api running behind the scenes(of course it should do what it is suppose to do with a decent optimization).