Forum Moderators: mack
Using a well thought out site structure that uses a logical file/folder structure will greatly help you out when it comes to growing your website.
Because failing to allow for future website expansion during the very earliest planning stages can lead to very difficult choices in the future, I'd like to expand on that a bit. Mostly I'm focusing here on site navigation paths now and in the future as a site grows.
Predicting the Predictable
It's probable that anyone building a new website, business or hobby for that matter, has a subject for the site in mind, and that they have at least some kind of goal in mind, perhaps increased sales.
Simply focusing on increasing sales for your current widget line could be too narrow a vision.
It's always possible that success in one area will lead to customer requests for other areas or products.
Not planning, at least minimumly, for that possibilty can be pretty expensive in the long run.
If you have to redesign and rebuild your whole site to accomodate growth you'll see that pretty quickly. Redisgn and rebuilding can quickly eat up any savings from not initially planning for growth in the future. Worse yet, it can confuse the heck out of your readers or customers, never a good idea.
Predicting Possible Growth Areas Can Be Difficult
Even if you think you have all the possibilties covered, your users/customers might not agree. Allowance needs to be made so you can accomodate unforseen growth opportunities. Hopefully your emails from customers or readers will let you know about possible expasion opportunities.
For instance: You might offer a section on buying widgets, because you sell widgets. It might turn out that your happy customers would be even happier if they could come back to your website and learn all they need to know about maintaining widgets, or repairing, or collecting antique versions, etc.
Plan for Sideways Growth
It is not enough to plan for simple verticle growth,
Widgets
Blue Widgets ¦ Yellow Widgets ¦ Green Widgets
¦-Big Blue Widgets
¦-Medium Blue Widgets
¦-Small Blue Widgets
You also want to consider sideways growth
Big Blue Widgets
¦-Big Yellow Widgets
¦-Big Green Widgets
or
Big Blue Widgets
¦-Repairing Big Blue Widgets
¦-¦-Big Blue Widget Parts
Build-In an Out
It may not be possible to predict every eventuality, so you need to think about this carefully.
Try to leave yourself one or more options for totally unforseen navigation paths through your site.
You where spot on what you said. "Not planning, at least minimumly, for that possibilty can be pretty expensive in the long run"
Many sites appear to have left this out of their design process entirely. When I am on a site browsing a page I like to be able to go down to the directory simply by snipping the end section of the url in the address bar. By setting up your site in the way it not only keeps things simple from a development point of view but it helps your users out a lot.
Predicting Possible Growth Areas Can Be Difficult
Think of your site as a skellington you need to leave rooom for the flesh then you need to let it be able to fatten out a bit. :)
If you keep your file scructure logical it makes it a lot easier to add directories and subdirectories at a later date.
Mack.
These days I have basically one file sitting in the root and that is the index page. Everything else is in sub-directories that directly reflect the core architecture of the site. Within those sub-directories there is plenty of room to plan for Sideways Growth. Once you've established the core navigation and topic areas, growing sideways is a natural occurence.
I now look at my sites as one big <ol> with nested <ol>s 5, 10, 15 levels deep. ;)
Based on my research it appears that FrontPage's sub-web approach is quite well suited to lateral design. It seems to me that people who have gotten themselves in trouble, when it comes to managing large websites with FP, often failed to plan for expansion, putting everything into one monster website, versus sub-webs. That, in turn, makes site wide updates take so much time that problems appear. (The alternative being to update large websites in FP one sub-web at a time.)
Any significant difference between sub-webs and sub-directories, outside the way you can manage them using MS FP's publishing features?
Pageoneresults;
I like the multiple mini-sites concept when it comes to planning for growth. For one thing, it allows you to build a good site to begin with, and then grow it in a natural progression. It's also intersting to note how easily mini-sites can be nested with-in each other.
And using mini-sites can sometimes spotlight additional growth opportunities, spawning even more mini-sites with-in the larger parent site.
This can all lead to what might be thought of as a modular site that could be disassembled and reassembled in a variety of ways, in part or in total.
Which fits nicely with Mack's emphasis on a logical site structure. But we've probably all heard, and maybe even used, the phrase "It seemed so logical at the time". :) If we don't plan for growth, today's logic can easily become tommorows nightmare. All the more reason to spend a little extra time, and money if needed to plan as well as possible at the start.
Now if I could jut learn to spell, and/or proof read...sigh
Any trouble or detriment to thinking of the lateral development issue in terms of MS FP's sub-webs?
Sub-webs get a little too high maintenance for me. Since you cannot share includes among sub-webs, you are literally forced to build a totally self contained sub-web within the main web. I prefer to use the sub-directory approach. I like sharing includes amongst the various sub-directories.
Prefrably in LAMP
Since you cannot share includes among sub-webs
Ahhh.. how hard it is to keep up with rapidly advancing technology!
Yes you can.
Yes you can.
Please do tell!
Anyway there are ways to "include" when you go server-side (e.g. php or ajax).
As for ken_b's post, I often have a similar conversation with clients and their web guys. The visionaries (god bless them) drive the process towards their vision of how it should be, which is GREAT except how do they know how it should be?
I can't afford to halt a driver (or the site might never get done) but at some point you need to get it online so it can evolve around the market needs. I find that in Ken_b's post... and I agree completely. I try and intervene early and hard on the tech side, to enable my eventual extensions, but without invalidating the vision of the charismatic leadership (even when they are unfounded). I also like to get some content up early.
I just accept the inevitable fact that no matter what is done before launch it will be sub-optimal, and it is best to be prepared for change. Really good framework design is essential (database included). Future costs are proportional to the flexibiliy of the framework, al lelse being excellent.
Anyway there are ways to "include" when you go server-side (e.g. php or ajax).
I was hoping you were going to show me a way to do it with FP Includes, bummer! I've been waiting for your reply ever since. ;)
It's all about site architecture. It's like building a house. You first have to lay the foundation (which includes all piping, wiring, cabling, etc.). A good solid foundation is key to long term maintenance, management and performance.
How would you order computer-related articles in the categories internet, networking and hardware?
My current dir structure looks like this. 1 and 2 are two pages from the same article.
/articles/article_title/1
/articles/article_title/2
This doesn't reflect the internet, networking and hardware divisions that exist inside the /articles categorie. Would you sub-divide this into
/articles/hardware/article_title/
/articles/internet/article_title/
/articles/networking/article_title/
?
I have decided not to do this, because I learned from other threads that keeping pages close to root is preferable. Is this really outdated information? I have been reading this article [searchengineworld.com]about URL length and was hoping to keep URLs short.
The latter option does better allow for future growth, right?
As long as the depth of the dirctory structure can be kept to a minimum, I prefer your second example.
The struggle comes when trying to balance what's good for the user, what's good for site maintenance, and what's good for the SEs, probably in that order.
Of course what's good for the user can be largely handled by link structure, which isn't tied to directory structure as tightly as site maintenance might be.
You are talking about the "customer facing" URLs, right? And the SE bot is a customer, too.
I understand you see the categories as "categories internet, networking and hardware?", but what does your audience believe? What does the SE say your audience believes?
It may be very user-centric. To the degree that keywords-in-urls matter to SEs, you want to optimize on WHY they matter in your context. I believe the days of generic on-page optimization are over.
If your site is clearly noted by SEs as being about computer networking, than subcats like "broadband routers" and "bandwidth testing" should do much more for you than "networking" and "hardware".
Same old story - you have to meet the user's need. But the need is changing... keywords in internal anchor text (potential optimization gain #1) and user experience (gain #2) meet different user needs and there for have different optimizations. A compromise design meets neither need IMHO (that's why many CMS systems are sub-optimal).
