views:

1224

answers:

6

I am curious as to whether or not anyone knows of a good reference/best practice on how to organize a website's assets.

I have always had a folder for CSS/scripts/images and just dumped everything in there, but this gets out of hand as the site grows.

On the other end of the spectrum I have heard of people creating a css/scripts/images folders in each logical location of the website's hierarchy.

For example, the root contained common CSS, scripts, and images. While different sub folder, (representing different logical locations in the site), had their own set of folders for specific assets.

How do you do it?

+1  A: 

resources are usually shared so my habit (I won't speak to best practice) has been along the lines of

~\resources\data\*.xml
~\resources\images\*.*
~\resources\scripts\{packagename}\*.js
~\resources\styles\{skinlabel}\*.css
~\resources\transforms\{packagename}\*.xsl

images will often have subfolders along the lines of "icons" and "backgrounds"

transforms will have packages like "utils" (for things like namespace washing and json converters), and some app specific names

scripts will also have packages for libraries (1st and 3rd party) and app specific stuff, but as mostly JS is packed into a single resource file in practice the folders only exist for debug and source storage purposes, and the code will be accessed from e.g. ~\resources\scripts\packed.js

And I'll make sure things in transforms (and data if I have a data folder) aren't available directly with web.config or similar

annakata
A: 

In general it should be a more or less deep tree organization. As the tree became deeper and deeper your organization became very fine grained.

For example you may have a location for "product". Within "products" you differ between "software" and "hardware". "software" may be separated divided in product names like "xy". So each parent ("software, hardware, ...") holds resource which are common for all children and the child ("xy") holds its' own resources.

Seika
i understand hierarchical organization, I specifically asking about things like css/scripts/images
Greg Dean
Oh that must be what you mean by resources... So you prefer the second method idescribed
Greg Dean
+2  A: 

You want just enough organization to make sense, but not more than is needed!

General Structure

I've run into this issue with a site I'm redoing, and that is that while it may make sense to have :

/academics/classrooms/kindergarten/ka/index.html

It would be far more simpler to have:

/academics/kindergarten/ka.html.

(See this for details).

The reason that's a problem is that there have been times where the wrong index.html was overwritten by the person that's maintaining the static site while I build the dynamic backend and port the front-end to be more maintainable.

Scripts

With regards to scripts, you want them in one folder, and you want to lock down access to that folder (read access, and no peering at the directory structure).

CSS

With CSS, it makes much more sense to have a central CSS document, in one place, to facilitate ease of updating.

Resources

With regards to images, it makes to have each subject's images located logically within the root of that structure. For me, that means /academics/classrooms/kindergarten/images/ .

There is such a thing as too much organization, and such a thing as not-enough. Based on empirical experience, you want to land somewhere between where I've landed and where you started out.

George Stocker
A: 
  • documents (all documents related to the site including backups of email messages)
  • design (.psd,.fla, .ai sources)
  • archive (zipped version of the web folder in the format yyyy-mm-dd_rev.zip
  • web (actual site dir with .aspx or php files)
    • configuration files
    • css (css)
    • images (images and to the site desgin)
    • scripts (javascript files and libraries like jquery)
    • documents (uploaded images and documents related to the site content)
    • staticcontent (html and other static html files)
Ronnie
+1  A: 

CSS: In general, one head-link is better than many head-links, so I try to keep to number of css files low. If the project is not too large, one /CSS folder in the public root is enough IMO. If necessary I split up the css files into layout.css and general.css or similar plus the different ie6_hack.css etc.

If the project is a bit larger, I create one substructure similar to the main one for each module. This is ok, since the corresponding files are only loaded, if the module is in use.

IMG: With images it's even easier, they are so easy to administer because you can view them with thumbnails. If the images are prefixed in a logical way, there is no need to distribute them all over the file system, IMO.

tharkun
A: 

For basic HTML

  • Root/style
  • Root/script
  • Root/images

For ASP.NET

  • Root/script
  • Root/Themes/ThemeName/ - css go in the root
  • Root/Themes/ThemeName/images
StingyJack