Web site file directory structure

[robert_k1]

<p>I am in the process of designing a site. The web pages will be based on assembling and hand editing a few existing online html/css templates and javascripts. Not all pages will end up with the same layouts, or use the same templates and scripts. I quickly realized that I need a good directory structure for organizing my pages and associated files. Here are a few questions I can use some help with.<br>

- Different pages have different images, css files and javascripts. Should I create a top level page folder for each page, and create subfolders for the images, css files and javascripts? The alternative is to have three universal folders, each lumping all the images, css files and javascripts. Which is a better approach and why?<br>

- Between the two above schemes, will there be any speed differences when uploading the files or displaying the pages? Compared to an image file, the css files and javascripts are rather small.<br>

- Does the naming of the files and folders have anything to do with what will be displayed on the pages?<br>

- Do the servers have any preferences or restrictions in the naming and structure of files and folders?<br>

I was unable to google any good tutorials on this. Would appreciate any references.</p>

[sknowles]

<p>Lumpers and splitters have argued this since Websites were first managed. Find what works for you intuitively so you don't have to keep remembering and reminding yourself where the files and images are in the directory structure. I don't think a structure impedes the loading because the url's tell where everything is and it's the server that controls the response. But all of this can be easily managed with a Website management application, such as Dreamweaver where you don't have to remember once you set things up. It automatically keeps things in order and you add or subtract as you want.</p>

<p>That said, I'm a lumper, or what I call controlled chaos. I keep all the html/xml files, css files, document fiels, image files in their own of four folders. It makes it very easy to remember and find files. I also give files names so they're in groups with prefixes and self-identifying short names (all my Web pages are individual, about 400 now with just one css file to make global changes/updates easy).</p>

<p>As for folder names, they're not displayed, only used in the url for retrieval. The important thing is avoid obvious issues, like spaces (usually displayed with %20 in the url) and most symbols (shift-number keys). This is because they're often used by browsers and scripts for variables, actions, etc. Dashes and underscores are the most often used, non-confiicting symbols.</p>

[JAPster]

<p><strong>Do the servers have any preferences or restrictions in the naming and structure of files and folders?</strong><br>

<strong></strong><br>

Depends on what type OS the web-server is running. A Unix type OS (example, some variant of LINUX, or HP-UX, or Sun's SOLARIS, etc) is case-sensitive with respect to filenames. That means that "H" and "h" are counted as two different characters not the same character. So you could safely have files named "pic1" and "PIC1" in the same folder on a Unix type server cause UNIX is case-sensitive.</p>

<p>Not so with a Windows type OS. With respect to filenames, Windows considers "pic1" and "PIC1" to be identical filenames, and it will NOT let you have multiple instances of identical filenames in one folder, so trying to create "pic1" and "PIC1" would result in a big fat error msg. So, in that respect, a Windows type OS is considered 'case insensitive' (compared to Unix).</p>

<p>I know that UNIX type OS's will allow you to use very long filenames, probably up to 255 characters on a LINUX server. When you combine this fact with the fact its also case sensitive, you see that UNIX gives you much flexibility & power in how you can name your files.</p>

<p>With respect to your other questions, here are some s/w development guidelines....<br>

1) Keep It Simple (KISS principle). ... ... Think through the organization of various types of files as carefully and realistically as you can, and then create and name your folders using a simple and straightforwards scheme. Keep it simple. Keep it logical. Keep it functional.</p>

<p>2) Keep identical types of files in their own folder. ... Example, keep all the Java scripts in one folder, name it something that tells you these are Java files. Keep all your thumbnail files in a different folder, and name it something that tells you these are thumbnail files. Keep your cfg files in another folder, and name it something that tells you these are site configuration files. Keep your downloadable files in another folder and name it something that tells you these are files available for user download. Etc, Etc, Etc.</p>

<p>3) Create some good support documentation. ... As you develope your website, and everything is fresh in your memory, write up some good explanatory documentation that captures your understanding of the scheme you selected, what each folder holds, what each page is supposed to do, and what each script or executable does. You dont have to write a book about it, but the documentation should be comprehensive enough so that if you have to put the project down for a while, and then come back to it, you can read the documentation and get back up to speed as quick as possible. You can create simple documentation easily using the WordPad app (Start => Programs => Accessories => Wordpad). Save all documents to a Docs folder along with your other folders. Also make a hardcopy printout of each doc, three hole punch it, and stick it in a 3-ring binder that will grow into your site's 'project notebook'. Keep that handy for quick and easy reference.</p>

<p>4) Design the site so its easy to update with new picture projects. If you want lots of traffic and repeat customers, you want to be updating your site regularly with new pictures, pages, and interesting information. So design your site right up front to be easy to update. That will make the job easier on you later on when you do start to add new picture series.</p>

<p>5) Use comment lines intelligently. .... .... As you code your web pages and web scripts, be sure to use plenty of comment lines (a comment line is a line of text that is not executed or 'run' by the computer but is ignored. It is used to tell the reader of the script or page what the next block of code is supposed to do.) (Example, in the good old DOS days, a comment line started with the letters REM, on Unix systems, any line starts with the pound sign # is counted as a non-executed comment line). Use plenty of comment lines throughout your web pages and web scripts so that 6 months later you can come back to it, read through it, and be able to tell what each part does. A good comment line will succinctly and concisely explain in good English the function and/or purpose of the next block of code. Sprinkle comment lines generously throughout your files so that you can come back 6 months later and understand what each section is supposed to do. This makes trouble-shooting and fine-tuning your site much easier.</p>

<p>6) Be consistent throughout. If you start naming your files like "PicProjsJan2010", then use the same format throughout. PicProjsFeb2010, PicProjsMar2010, etc, etc. In other words, find a filename style that works for you, and use it consistently all the way through.</p>

<p>7) Avoid using space characters or special characters in folder and filenames.... Windows and Unix will allow you to use spaces in file and folder names. Don't do it. It only makes things more confusing to look at, and really complicates things if you start developing your own scripts that have to navigate and access those files. Because in the script you would have to program it to know that the space is really part of the filename. Likewise, using 'special' characters like $ @ # ^ & ( ) ~ and the like, can really confuse the OS when they see those in a filename. So dont try to use spaces or special characters in your folder or filenames. The exception is the underscore character, _ , which is commonly used in filenames, like say, TIFF_Files JPEG_Files, RAW_Files,</p>

<p>good luck...</p>

 

[johan_ingles_le_nobel]

<p>Lumping (ie having one /css/ and one /js/ folder below the top directory and just referencing that) is better for your visitors and for your organisation. By lumping, your CSS and javascript will be cached by the time a user navigates to a second page, so it's quick to load (rather than reloading it every time). Images - depends how important SEO is for you - it's a compromise between better SEO (image in its own folder) and organisation (all images in /img/) With today's broadband the actual loading time speeds are probably irrellevant to be honest. The real advantage is in organisation, especially if you need to make site-wide changes. Also google Yslow - it's an addon that'll help you tune your site for maximum speed. If you use firefox download firebug, it'll let you measure the speed (and you'd see the differences)<br>

Naming - exactly what Alan said, naming, comments too. It's really helpful to read a comment like 'must be done this way because it breaks in safari if I don't' 6 months after you last looked at it - saves a ton of grief.</p>

[robert_k1]

<p>Thanks for all the thoughtful inputs.<br>

Cap vs lower case naming: Since I don't know which server OS I will end up with (another discussion topic to follow), I will keep all the names in lowercase. Got to remember to change .JPG to .jpg also.<br>

Caching universal css and javascript: Good point and something I have not considered. Since my pages will be very simple, and the load time will be dominated by loading the image files, I'm not sure if caching the css and javascripts would make a significance in performance. Preloading the images is more of my concern.<br>

SEO: Not sure what the SEO difference is between lumping and splitting the image files. I will rely upon text descriptions of the galleries, and perhaps the images' captions for SEO.<br>

I'm kind of leaning towards splitting the folders, so that each page would have a top folder with all its files in its subfolders. Here are the pros and cons.<br>

Pros:<br>

- A screen capture of Windows Explorer displayed in detail will show all the folders, files, dates, etc. That will serve as a reminder of where everything resides.<br>

- The site's galleries will be the most frequently updated pages. With each gallery starting at a top level folder and images/thumbnails in its subfolders, I can apply a simple and *identical* naming convention to the image files for *all* the galleries. The image subfolders names would be distinct, e.g. landscape, portrait, etc. But the image and thumnail file names would be identical for every gallery, e.g. nn.jpg and nn_tn.jpg, where nn is the numeric count, and tn is thumbnail.<br>

- I assume that when a gallery is updated, I only need to upload its folders and files, but not the whole site's. If true, then a split scheme would make uploading a single gallery's folders and files easy.<br>

- The same naming convention can be applied to the css files and javascripts. But since there won't be too many of these, making their names distinct is not a big deal.<br>

Cons:<br>

- If the pages use the same css files and javascripts, these files will have to be duplicated in every page's subfolders.<br>

- Since the site's layout and style will be simple and well thought out (famous last words), I don't plan to make frequent, if at all, site-wide changes. If I should need to, I will have to update the css and javascripts in every page's subfolders.</p>

 

[sknowles]

<p>You can split the html and image files into folders while using a common css and javascript folder. You only specify the full url (pathname) instead of the short one. Duplicated common files only adds work, and a css files load quickly so one or a few (some folks separate them by text, gallery and main css files) doesn't hurt.</p>

<p>As for uploading, you only upload what's new or updated, and any global changes or updates (which can be surprising when other pages stop working right or missing new parts, mostly navigation links). And uploading is uploading, it doesn't really matter how many folders you have, only you have to navigate the host structure to upload into the separate folders so they install and work correctly.</p>

<p>One way to avoid creating thumbnails is simply size the larger image file down in the Web page, which is done with the html or css code. It saves having to create them, upload, and manage them, beside disk space, althought they're pretty small files. You just have to keep the proportions in mind.</p>

[richard_king2]

<p>to be frank it makes more difference to you than anyone else. In 18 months time, when you come to edit a page and you cant remember what file relates to what page, spaggetti code and structure will just cause you headaches<br>

<br /> FWIW, I usually have a "core css" AND "core JS" file, and then any extras, specific for a page or function, land in the same folder and get very specifically named - i.e. with the page name. This means in 18 months time, when I come back and look at it, it is immediatally obvious that that JS and CSS file belong to the portrait gallery page, and that one over there belongs to the modal light boox etc..</p>