Help with project directory

Hi everyone. I have question whether I am organizing my files and folders correctly for my projects. I tend to have a folder for each of my pages. I also name my html and css files after the page name. Is this correct, or should they always be names index and style? I would appreciate any help with this!

My project directory:

(the html and css folders are for pages on my site talking about those topics)

If you think in terms of a web site, every folder should have an index.html page, even if it is just a dumby static page. This lets us access the page using only its folder name.

/    =>  site root (index.html)
/about.html    =>  about page on the site root
/folder/    =>  access index.html of folder
/folder/gems.html    => page in secondary folder

Folders like ā€˜cheat-sheetsā€™ and ā€˜internetā€™ are generic and not intended as site content so can sit outside of your main projects folder.

Each site should have its own internal folders for resources, images, etc.

/site-root/   i. e., project name
+ css/
+ js/
+ images/
- index.html

Recommend you set your explorer to not hide extensions.

1 Like

Thanks for the response. Each of the folders I showed in my example has an html file as its index, but theyā€™re named after its page name (e.g internet.html). So my root is index.html but all my other pages have a different name. Is this correct? I noticed you have a file named gems.html in your example. The structure I have used is:

+root folder (project name)
+page folder (e.g internet)
+resources folder (internet)
+css folder
+images folder
-internet.html
+resources folder (index)
-index.html

(edit: the text didnt indent for my example. Certain files are contained in the internet folder, like internet.html and resources folder)

So internet is just one of the pages for content on my site. I put all my css and images in a ā€œresourcesā€ folder as well.

1 Like

We can have any names we choose on our pages, so long as there is an index.html page in every folder. On a web facing server, this prevents outsiders from viewing the list of contents in the folder. A minor concern, but also easy to address.

Working on your own machine you will need to turn on the localhost server to simulate a live web. It is at this time that we need to establish good habits that will carry over to production sites.

Name the folder after the project, and give it an index.html page as the landing page of the folder when no name is given in the URL.

1 Like

I see. I think Iā€™ve been over complicating things by creating lots of folders. So the root folder contains all html files, a css folder containing all css files, images folder, and (for down the road) a JS folder. That makes things a lot easier when referencing paths while linking pages. Well thank you for all your help, it means a lot!

1 Like

Iā€™m sorry to bump an old topic but I see you on the forums all over the place and you seem like a very nice and forgiving person.

Iā€™m having trouble understanding where the HTML files for sub pages go. It seems like all over the internet the advice is to put all HTML files in the root folder for ease of linking. For me this seems crazy because a webpage can have so many HTML files and it would get disorganized.

If I am to interpret your advice correctly, you are saying to have the sub pages that are accessible from the root index.html, such as about.html, in the root folder. Then subpages such as blog.html should be located in a blog directory, and should be index.html inside that directory instead of blog.html.

Then, to extend the question, and assuming I understand correctly, each html page for the blog posts would be in directories such as gems, cheat-sheets, or blog-post-ex-123, and named index.html.

Image included to see it visually:

I sincerely apologize if this is a dumb question. I am new to the community.

Thanks

No need, really, to apologize for what is actually a very good question, and well presented, at that. The compliments could continue, but that would interfere with the science:

Think of practical values. The example on the left gives objects a folder name, and assumes there will be a root file in that folder. It follows that any files that support that folder will be contained, unless, that is, they are global support files, which is moot in terms of explanation; i. e., in a folder on the root, or a file on the root.

The reason I love your left side example is that the url is easy to derive, just link up the directory names in the path:

site root/blog/gems/  #  we're assuming a web server in this discourse.

same as,

/blog/gems/

the ending slash always means, index page.

If something is related to a particular subset, then the index page should point to it from that subdir. It follows we wonā€™t be accepting outside links to those same resources. We keep all interaction within the directory.

If anything, I would want to pay close attention to duplicated storage locations. It is okay to have,

/blog/do-birds-have-wings/

and let the page be ā€˜index.htmlā€™ there is not harm in that. The images for this page can go into a common bin, though. If images are meant to be picked up by the indexer (search engine), keep them all in one images folder right off the root.

/images/do-birds-have-wings.png

Same goes for local.css, but you havenā€™t given it a folder and as long it loads last it will be at the bottom of the cascade (where it belongs). If there are a lot of common selector rules, think about having a ā€˜blog.cssā€™ file in the css folder off the root:

/css/blog.css

Then you only need a local sheet for the odd occasion. For example, say you want a different skin graphic on this page. Easy. Put the file right in the local folder and have the local.css override the URL for that skin graphic selector rule in the blog.css sheet. Itā€™s lower in the cascade so easy-peasy.

Letā€™s say that all the pages off the root have this line:

<link rel="stylesheet" href="/css/main.css">

Now lets look at the Blog:

<link rel="stylesheet" href="/css/blog.css">

But what about the ā€˜main.cssā€™ file? Should it be a separate link above this one? Yes, to maintain the cascade, but, it can also be imported by the blog.css:

@import main.css

That would be the very top line of the blog.css file. It still puts the sheet at the top of the cascade, above the blog.css, and it doesnā€™t require an additional link in the index.html page for /blog/.

We can follow this path logic right down to our local.css:

<link rel="stylesheet" href="local.css">

and give that CSS file this import line:

@import /css/blog.css

Notice we need the path from the root since weā€™re not in that folder like the other two CSS files.

If Iā€™m going on, itā€™s because this all makes sense to me. What are your feelings on this?

Well, first off, thank you for your reply. I feel like I can implement the guidance you have given me into my project. I just have a few questions of clarification because I think the gap between your knowledge and mine is so great that things that are obvious to you are just going right over my head! :sweat_smile:

Iā€™m assuming nesting the images deeper into the structure limits their accessibility to the search engine? My strategy in having an images folder for each sub page directory was to be able to name them descriptively with regards to their content rather than their relationship to the website.
For example,

/blog/lakes/smooth-lake-with-sunset-and-mountains.png # image filename describing the image

rather than

/blog/lakes/header-lake-section.png # image filename describing image purpose within website

It seems like then to achieve this ā€œgoal of search engine fishingā€ I would need to do some folder duplication inside the root-nested images folder that you are suggesting, or suffer a disorganized mass of image files just as bad as the disorganized mass of html files.

/root/images/blog/lakes/smooth-lake-with-sunset-and-mountains.png # folder repetition

or just

/root/images/smooth-lake-with-sunset-and-mountains.png # might be a mess

For CSS, at the moment I just have one style.css and Iā€™m using classes for each element to change the type of page being used. Itā€™s ugly, I know. I just havenā€™t been able to conceptualize a good way to make multiple styles heets for different pages. I just started to learn about SMACSS by Jonathan Snook and was trying to implement some of the introductory principles.

x`

header {
        background-attachment: fixed !important;
        text-transform: uppercase;
        color: white;
        position: relative;
        top: 0;
        z-index: 2;
    } 

            header h1, header p {
                background: none;
                width: fit-content;
                position: sticky;
                top: 0;
                text-shadow: 0.5px 0.5px 5px #fff, 0 0 0.2em #d1e4f4, 0 0 0em #ebddd2;
                z-index: 3;
            }

                header h1 {
                    font-weight: 100;
                }

                header p {
                    font-weight: 300;
                }

                header h1:hover, header p:hover {
                    text-shadow: none;
                }
eader.landing {
                background: url(./images/header-nav/magical-ball-lone-mountain-sunset-reflective-water-big3.png)no-repeat top;
                /* dark blue: #182837 blue:#6f7c8d , lightblue: #d1e4f4 , pink: #ddb9b9 , light grey: #cbccce , cloud: #ebddd2, light orange: #dea369 , orange #b05a19 , dark orange: #702c0b , nearly white #ffd8a7*/
                background-size: 162vw; /* 2445px;*/
                height: 45vw;
                text-align: center;
            }

                header.landing h1 {
                /* margin: top right bottom left*/
                    letter-spacing: 2px;
                    font-size: 5vw;
                    left: 28%;
                }

                header.landing p {
                    margin: -9vw 0 0;
                    letter-spacing: 0.7vw;
                    font-size: 1.15vw;
                    left: 33.7%;
                    top: 5.5vw;
                }
header.page {
                background: url(./images/header-nav/left-corner-mountain-widescreen-sunset-pink-clouds-reflective-water.png) no-repeat top; 
                background-size: 100vw;
                height: 20vw;
                text-indent: 16vw;
            }

                .sticky_parent.page.h1 {
                    padding: 5.5vw 0 0vw; 
                    height: calc(-3px + 10.9vw);  
                }

                .sticky_parent.page.p {
                    padding: 0.5vw 0 1vw;
                }

                    header.page h1 {
                    /* margin: top right bottom left*/
                        font-size: 3.7vw;
                    }

                    header.page p {
                        margin: -3.8vw 0 0;
                        top: 3.8vw;
                        font-size: 0.9vw;
                        letter-spacing: 0.35vw;

Basically I have a different size and image position for the header for the sub page and landing page of the website.

Let me know if this is correct implementation of your suggestion:
I should have the top block, header {}, in the main.css.
Then in the index.css file specific to the landing page I should have the header .landing {}
Finally for the directory nested in the root I should have header .page {} because it is accessed by the rest of the pages?

Thanks for your interest in teaching!!
And please donā€™t be too triggered by the hackjob responsive css. Iā€™m just getting to that module in the course and got ahead of myself just googling solutions instead of following the lesson plan.

To some degree. Search engines look for the ā€˜imagesā€™ folder on the site root but must discover images elsewhere on the site. We can use the images folder for SEO if we create related names like we did above. The image might be discovered before the page that uses it. The name we gave it is suggestive to the indexer so the page is likely to be discovered just by virtue of that stored image in a crawlable directory the SEs scan frequently.

Of course, the spiders are crawling your web and will discover the blog page through the site index page. Which occurs first is now split between this and the above. Or we can see it as having two vectors of discovery, not just one.

To how it could limit accessibility, getting back to your question, one is confined to supposition given that crawlers have full access to everything facing the web unless restricted by robots.txt or htaccess, the latter of which spiders cannot evade or disobey, but which comes with abundant workload for the server and really should be avoided if you come upon suggestions to use it. There are better ways.

Oops! Iā€™ve gone and dragged you down the rabbit hole; pardon me.

Being buried in several directory levels will have a consequence and I suspect the SEs are not drilling down more than two or three (if that) to discover images. On the basis of this probability, it makes immense sense to keep the images at the root level and immediately available with just a domain/images/ path.

To some it is pretend science, to others it is intuitive. We have never needed to game search engines, just produce valid sites and stay between the lines of accessibility, usability and standards conformity. Even along these lines without making a game of it, or attempting to gain a profitable edge, it has always been possible to gain recognition by a search engine. All it takes is a link from a reliable referrer to start the ball rolling.

Say you are launching a photo website that youā€™ve poured your heart into designing and itā€™s sitting there just waiting to be launched. Who do you want to be your number one referrer? Let them in on it. Contact them and ask for a link from their website and social media. Donā€™t plant links. Get them from people who respect your work. Even ten will have more value to a search engine than ten thousand from the crawlers. Launch your site from valued and preferred referrers and forget SEO after that.

Okay, weā€™re in the deep again and I see you have more content to go over. I hope youā€™re okay if this carries over to tomorrow. Signal your 10-4, please. Iā€™m signing off for the night.

Thanks so much for your help and Iā€™ll hope to see you again soon!

1 Like

We mentioned that images we want to have indexed are best located at the highest level, just off the domain root.

/images/

Our skin graphics should not be indexed, however, so where do we put them? Easy, in a ā€˜skinsā€™ folder just inside the /css/ folder.

/css/skins/

    background: url(skins/blog_header.png)

In your robots.txt prohibit access to that folder by robots. Inside that folder put in an index.html page with a simple message: ā€œRestricted Accessā€ with a link back to the Home page, and give the page a robots directive in the meta data (the HEAD). Iā€™ll leave you to research this. Never link to the any pages inside your images or skins folder. Since skin graphics are CSS backgrounds, they are never seen outside of the /css/ folder.

Since there are so many ways to approach all this, and many views, it is left to you to come up with the most maintainable design possible. Keep in mind that SEs donā€™t go very deep into a web, likely never more than four or five levels. The closer to the root level a page is, the better chance it has of being discovered and indexed.

So maybe this is naive but what is the reason I wouldnā€™t want robots crawling my skin graphics? In my case I made the header art and art that goes above the footer (Iā€™m calling it ā€œankleā€), and Iā€™ve name the file descriptively. Granted since it is linked in a CSS file I canā€™t provide alt text for it, so maybe that is my sign that these sorts of art are not meant to be indexed?

Iā€™ve done some more research for directory organizing and came across this guide where everything is given a number.
Iā€™ve tried to apply something similar to my plan, with the format of XX-YY-ZZ-filename.ext where XX is the position of the parent directory within the root folder, YY is further nesting details, and ZZ is the position of the file within the folder it occupies.

šŸ“images /* not named similarly for SEO purpose */
	āœ“ļø01-01-cube-6-pointed-gem-geometry-cluster.svg
	āœ“ļø01-02-gem-information-pointers-sims.svg
	šŸ–¼ļø02-02-01-mountain-lake-cloud-trunk-island-whirlpool-mockup.png
	šŸ–¼ļø02-02-02-ubc-botanical-gardens-burned-hollow-trunk.png
	šŸ–¼ļø02-03-01-tamagotchi-grass-jelly-title-mockup.png
	šŸ–¼ļø02-03-02-cypruss-trees-farming-idle-game.png
	šŸ–¼ļø02-03-03-slime-at-playground-wireframe.png
	šŸ–¼ļø02-03-04-handheld-fire-sprite-idle-game.png
šŸ“02-library
	šŸ“02-02-css
	šŸ“02-03-data
	šŸ“02-04-js
	šŸ“02-01-index
	šŸ“02-02-charybdis-beanstalk
		šŸ“02-02-02-css
		šŸ“02-02-03-data
		šŸ“02-02-04-js
	šŸ“02-03-timer-mechanic-research
		šŸ“02-02-02-css
		šŸ“02-02-03-data
			šŸ’¾02-03-01-borst-jelmer-taatgen-2015.pdf
		šŸ“02-02-04-js
	šŸ§£index.html /* not named similarly for landing page function */
	šŸ§£02-02-charybdis-beanstalk.html
	šŸ§£02-03-timer-mechanic-research.html


šŸ“03-projects
šŸ“04-resume
šŸ“05-contact
šŸ“06-legal

<!-- PAGES -->
šŸ§£index.html /* not named similarly for landing page function */
šŸ§£03-projects.html
šŸ§£04-resume.html
šŸ§£05-contact.html
šŸ§£06-legal.html

So for example, in the website in the order along the nav bar it is:
[Library][Projects][Resume][Contact][Legal]
So index is a silent 01, then library 02, resume 03, so on and so forth. This way they can be tied to a folder with the same number, and the images can be traced back to the page they are displayed on, and they appear within the folder in the same order that they appear on the website.

Images have got to be all in one folder, so to keep track of them they are prefixed with the full number path of their ā€œhost pageā€

02-03-04-filename.extention

02 is the library directory within the root, 03 is the third subdirectory (the Timer Mechanics Research), and 04 means the image is appearing below the first 3 images on that page.

As long as it doesnā€™t get too nested the number prefixes wonā€™t need too many elements and this way while I canā€™t have folders for organization within the images directory, I can at least control the order in which the images are displayed, group them, and of course maintain descriptive filenames too.

Let me know if putting all these numbers is too ridiculous because it feels a little silly!!

P.S. I am trying to follow your approved method of using index within the subpage directory for library, but I am also wondering if I should have the other HTML pages, in this example 02-02-charybdis-beanstalk and 02-03-timer-mechanic-research in the root directory? The internet says we should dump all html files directly in the root but, I just canā€™t bear to do it unless an expert tells me its the best thing to do.

Once again thanks for your hard work and dedication to teaching.

Question: Why would one wish to have skin graphics come up in a search result? What bearing do they have on the subject matter of the page/site? Itā€™s eye candy, that is all. They have no value apart from their appearance/appeal.

When organizing a web we need to think in terms of simplicity and minimum depth (for the sake of crawlers). If you donā€™t want your site indexed, then do what you think is best from a maintenance perspective. If you do want it indexed, and why wouldnā€™t we? then think about the search engines. What meaning do numbers have to the indexer? None. They read words.

I noticed you have your CSS and JS in another directory rather than off the root. You could come to hate that decision, but then what do I know? Iā€™m retired and havenā€™t built or maintained a web in years. Things have changed. Simple was always best, in my view, then as now. If you complicate things it will only be harder to maintain down the road. Once your site is indexed the worst thing you can do is start moving things around. Pick a place that makes the most sense and is most maintainable. Thatā€™s about all I can offer, at this point.

1 Like

Truly this is the crux of my overthinking, my dad always said KISS method (Keep It Simple, Stupid) never fails.

I definitely want it indexed and I donā€™t want to move things around, but Iā€™m realizing that it is very unlikely I will get it right the first time and it is going to be a learning process.

It seems to me the most simple thing is to have the subpages in their dedicated HTML directories, but the minimum depth thing to do is have them all in the root folder. Even with this number naming convention I think it would be a nightmare to have hundreds of HTML files all in the root directory

This is good to know, thanks. If I did want a number to be relevant to the indexer, I will write one or two or whatever.

I was following a guide for that but It seems like that person was in the minority with that nesting strategy. I figured if I link the CSS/JS with the / rather than the ./ in the individual HTML sheet than it shouldnā€™t be too much of an issue.
Essentially Iā€™ve got to organize it by resources, assets, third party > css, js, data or css,js,data > resources,assets,third party So either way the actual files are going to be at least 2 directories deep.
I suppose I could also just name the css files as my-stylesheet.css, and borrowed-from-jim.css and keep them in the css folder. Itā€™s crazy to imagine I would need so many different stylesheets right? It seems to me like the whole point of the cascade is to be able to have only a few sheets to minimize repeat code.

Thanks again for your help!

1 Like

Think of your web as being a book. It has front matter and chapters. The front matter is all the boiler-plate, home, about, contact as pages, along with any other all encompassing pages that donā€™t mix with the content objective.

The chapters are few, usually. E. M. Forster seems to have arrived at 37 chapters as being optimal division of, ā€˜A Passage to Indiaā€™. That is a novel, however. A website is not going to have so much diversity compacted into its general theme.

Still, nothing precludes having several separate ā€˜chaptersā€™, of which ā€˜blogā€™ would be one. Itā€™s just off the root so not a difficult crawl:

/blog/

/gallery/

/travels/

/video/

One will never run out of examples, but the key is to stay on track with the implied theme of the website, at leastā€“the explicit theme for integrity and consistency.

Start small. We can add to a site, and really should once it gets going, but not all at the start. Confine your intentions to one or two categories (chapters) and develop those units. If you adopt the root as your CSS and JS and Images, etc. you will never have to use relative paths. That makes pages a lot easier to maintain since all the internal links point to the root and progress from there. This is a total no-brainer. Bottom line, ./ and ../ are recipe for a nightmare that never ends.

Remember, one CSS folder, one JS folder, one IMAGES folder. We discussed custom CSS for the odd page, or customized chapter style sheet. Build a basic site with that as your foundation. Itā€™s not fancy, but nobody can say it is not simple. Be that strict. This is not oneā€™s hard drive. Itā€™s a web that can be accessed from around the globe and may have heavy traffic loads at times. The simpler your structure the faster your server can deliver.

A server folder may contain hundreds or even thousands of files. Believe me, once we put them in there weā€™re never going to look for it again unless it is to replace it. We know about the picture because of the page that requests it. That is enough to know about it. That is where the search engine makes the connection. A page about Mount Everest and a number of pictures (in /images/) with ā€˜everestā€™ in the name is enough for the SE to connect the dots AND make indexing a breeze (and a better likelihood).

We donā€™t want to document our site for our reference. We need to structure it for search engines and servers. Every directory level can come with its own overhead, especially if htaccess is deployed.

/blog/
    2023-10-19/
        index.html

A search crawler can easily get used to that structure. It will even figure out the date format and just love it (meaning it will be easy to index).

The last thing I wish to do is browbeat you with sensibility as I see it, and may have crossed that line already. Pardon an old man for bleating. Still, my point is to build simple, close to the site root structure and then let the directories fill up with content as you go. To repeat an above mentioned concern: once indexed, never move the page (you can change it, just donā€™t move it). That means you get one chance to get the first step(s) right. Start small, start simple, concentrate your efforts in a small area and be confident that your site, once noticed, will get indexed and crawled regularly (eventually). Stick to your guns and prove the integrity and consistency of the site and you will never need to shell out for SEO.

Happy coding!

Despite all the errors I made, integrity and consistency is not one of them. Even today we can find an old page of mine in the internet archive, and the CSS still works! In that time, the search engines would have indexed this page, else why would the waybackmachine have it?

You want your site to stay alive?

Stretch and shrink that page left to right. What happens? This is known as ā€˜adaptiveā€™ as opposed to ā€˜responsiveā€™, which is device oriented. In the day we would have thought of the two terms as synonymous.

Iā€™m tickled that the archive even hung on to my favicon. Thatā€™s class!