Developing large site in segments?

[Phrederik]

I'm currently developing an intranet website that will be used by a single
department within my company. I'm hoping that this project will lead me to
develop for other departments, eventually creating one large site for all
departments to access.

The site will be developed using Visual Interdev 6.

I was just wondering what the best way to develop this site would be. I'm
not looking for anyone to figure out how it all should work, just some
general design pointers that will allow me, at a later time, to add an extra
level before the root of my current website.

Please direct me to another newsgroup if this one isn't appropriate.

 

[rf]

I'm currently developing an intranet website that will be used by a single
department within my company. I'm hoping that this project will lead me to
develop for other departments, eventually creating one large site for all
departments to access.

The site will be developed using Visual Interdev 6.
Ouch.


I was just wondering what the best way to develop this site would be. I'm
not looking for anyone to figure out how it all should work, just some
general design pointers that will allow me, at a later time, to add an extra
level before the root of my current website.

If *ALL* of your links and images etc in the site use relative adressing
then you just bump the current site one level down from the root and add the
extra level *at* the root.

example.com/ gets moved to example.com/leaf/
example.com/ is the new root.
example.com/departement2/ is the other blokes section

or have I totally misread the question?

Cheers
Richard.

 

[Phrederik]

Ouch.

Don't like VI6? It's better than notepad/EMEdit that I have been using.

I'm using it to keep all my documents/pages grouped together and for the
code editing.. I won't be using the "design" interface.

If *ALL* of your links and images etc in the site use relative adressing
then you just bump the current site one level down from the root and add the
extra level *at* the root.

example.com/ gets moved to example.com/leaf/
example.com/ is the new root.
example.com/departement2/ is the other blokes section

or have I totally misread the question?

You have it right, more or less... I'm having difficulty describing what I
mean, which is probably why I'm finding it difficult to design. : )

I guess I'm wondering about how to develop the navigation. If I were to do
what you said, then I'd have to be careful with any links and menu's to be
sure that everything is 100% relative.

 

[Alex Lyman]

(1) I'll reiterate what rf has said: use relative-pathed links (which is
probably the best suggestion anyone can make about web design), and show off
my neurosis while I'm at it. Relative links will always make your life
much, much, much easier. Especially in your case, where file paths are very
likly to change over time. While "/index.html" might work well now, what
happens if you move the site root? Will all your links still go to the
right pages? Nope. I can't stress this enough. Use relative-pathed links.
Even on the things that will never, ever, in a million years, move. Even if
you only have one page, without any links. Use relative-pathed links.

(2) Use page templates. Using templates will make it 100% easier to make a
globally navigable site. Just think, without templates, if you add a new
department, you'd have to go into every single one of the HTML files you
already have, and add that department to whatever form of navigation you end
up using. This may not seem bad when working with one department, with
10-15 pages. But what happens when you have 200 pages? Better use this one
from the start.
If you arn't (and don't have access to) a programmer, there are still many
solutions to this (personally, I've never used VI6, so it might have this
functionality) -- ranging from the free (In the land of search.cpan.org,
look up HTML::Mason [which I use]), to the expensive (Dreamweaver UltraDev 4
[which I also use]). If you are/have a programmer, nothing will beat out a
custom-built solution to the problem -- all the things you can buy (or
opensource) will be more general than you really need, and the things you
will need will be implimented not to your liking.

(3) Make everything nice and small. Even though i's just for the Intranet
now, who can say that 6 months down the line, in the biggest show of
management stupidity your company has ever seen, somebody, somewhere far up
the latter from you, will deem it appropriate to allow the general public
access to your Intranet site? While 10Mb pages may cut it on your nice,
high-speed network, not many in the internet community will be as lucky.

(4) Assume the people using the site are much, much stupider than they
appear to be. If every single one of them has a phD in Communication,
chances are, that atleast 1 of them will not be able to find the "News"
page. Even if you have a flashing red button that says "NEWS!", that is
both: half the size of the screen; and makes a loud, blaring sound of you
yelling "CLICK HERE FOR THE NEWS!" whenever your mouse comes within 10
pixels of it.

(5) Don't use IIS. Nomatter what the IT/IS department tells you, it is in
no way supperior to Apache for Windows. If one of the IT/IS people says "I
can configure IIS for you," don't let them. If you need to, create your own
webserver. But, never, ever, use IIS. IIS will not only make you a target
for almost every Server-Worm in existance, but it will also make your life a
living hell. 5 months into the project, you'll realize that you need a
feature, and you'll delve into every resource on IIS you have, and realize
that IIS3 had it, but IIS5 does not.

(6) Don't use Front Page Extensions. If you're not following #5, then
atleast follow the advice of #3. Some day, management will decide that your
entire company will move from Windows to Macintosh OS X, and you will have
to redesign the entire site without FPEs. This is much like the problems
described in #2.

 

[Phrederik]

(1) I'll reiterate what rf has said: use relative-pathed links (which is
probably the best suggestion anyone can make about web design), and show off
my neurosis while I'm at it. Relative links will always make your life
much, much, much easier.

Definately will be doing this. Makes the site extremely portable.

(2) Use page templates. Using templates will make it 100% easier to make a
globally navigable site.

Again, a good idea. I just need to figure out how much detail to go into on
my template. : )

If you arn't (and don't have access to) a programmer, there are still many
solutions to this

I'm a programmer... but not much of one. Dabbled in many languages but
haven't really mastered any. I'm definately aiming at customer built
solutions, but I really need to review what's out there due to my lack of
experience.

(3) Make everything nice and small. Even though i's just for the Intranet
now, who can say that 6 months down the line, in the biggest show of
management stupidity your company has ever seen, somebody, somewhere far up
the latter from you, will deem it appropriate to allow the general public
access to your Intranet site? While 10Mb pages may cut it on your nice,
high-speed network, not many in the internet community will be as lucky.

The current site will never go public, but I definately avoid anything that
wastes bandwidth. No sounds, minimal graphics, etc.

(4) Assume the people using the site are much, much stupider than they
appear to be. If every single one of them has a phD in Communication,
chances are, that atleast 1 of them will not be able to find the "News"
page. Even if you have a flashing red button that says "NEWS!", that is
both: half the size of the screen; and makes a loud, blaring sound of you
yelling "CLICK HERE FOR THE NEWS!" whenever your mouse comes within 10
pixels of it.

Been there. Done that! : ) I have the luxury of actually working with one
of the users so the interface will match their actual work patterns as much
as possible. I also have some experience writing ISO 9000 documentation and
know that if there is the slightest hint at a question appearing, you must
already have the answer.

(5) Don't use IIS. Nomatter what the IT/IS department tells you, it is in
no way supperior to Apache for Windows. If one of the IT/IS people says "I
can configure IIS for you," don't let them. If you need to, create your own
webserver. But, never, ever, use IIS. IIS will not only make you a target
for almost every Server-Worm in existance, but it will also make your life a
living hell. 5 months into the project, you'll realize that you need a
feature, and you'll delve into every resource on IIS you have, and realize
that IIS3 had it, but IIS5 does not.

Unfortunately, it's all I have at the moment. It's been stable for me. I
have not had any luck getting a consistant Apache installation working. The
site is also using ASP, which is native to IIS. I don't know if the same is
true for Apache.

(6) Don't use Front Page Extensions. If you're not following #5, then
atleast follow the advice of #3. Some day, management will decide that your
entire company will move from Windows to Macintosh OS X, and you will have
to redesign the entire site without FPEs.

No problem having to redesign the site. Just means a big juicy contract.
: )

So far I haven't had the need for any Frontpage stuff. I did have to enable
FP support on the server for VI6 to publish the sites though.


The biggest hurdle that I see is that ASP is involved. This means that if I
drop the current site down one level from the root, the global ASA, etc.
files will no longer apply. This shouldn't be a problem with a bit more
thought put into the design though. I'll get this figured out.

I appreciate the info. Thanks for taking the time!

 

[Toby A Inkster]

Unfortunately, it's all I have at the moment. It's been stable for me. I
have not had any luck getting a consistant Apache installation working. The
site is also using ASP, which is native to IIS. I don't know if the same is
true for Apache.

There is an ASP module available for Apache 2.x, although I've not tried
it.

 

[Beauregard T. Shagnasty]

Phrederik pounced upon this pigeonhole and pronounced:

The biggest hurdle that I see is that ASP is involved. This means that if I
drop the current site down one level from the root, the global ASA, etc.
files will no longer apply. This shouldn't be a problem with a bit more
thought put into the design though. I'll get this figured out.

Drop all your sites down one level.

I use W2K IIS5 and asp on my local machine and have several sites, each
with its own global.asa. Works a champ.

C:\Inetpub\wwwroot\site1
C:\Inetpub\wwwroot\site2
C:\Inetpub\wwwroot\site3 ...