In the recent years, we’ve been seeing a lot of improvements on the organization procedures for web applications. More specifically, the MVC Pattern; which greatly improved development speeds by imposing a well structured architecture. This allowed developers to feel at home with any application that uses the pattern.
The Model-View-Controller (MVC) Pattern is oriented to the back-end. There’s a specification about where to store your interface related code, the View, but there’s no real specification regarding how and where you should store your assets. Enter The Arrangement for View Assets (AVA) Pattern.
The AVA Pattern works side by side with the MVC Pattern. Both are framework and language agnostic, and independent of each other, but together you can achieve a better organization which will improve productivity, especially during advanced stages of the application.
Take these with a grain of salt and remember that you should always use what your team is accustomed to; these conventions may be modified to fit your project, however, try to follow the general idea about the structure.
For instance, you may want use snake_case over the dash-case naming pattern; these types of modifications are a matter of preference.
Need to write some stuff here..
/css/ # Documented? Soon.
style.css
handheld.css
/img/ # Documented? ✓
/js/ # Documented? Soon.
tests/
qunit/
index.html
tests.js
libs/
jquery-1.5.1.min.js
jquery-1.5.1.js
modernizr-1.7.min.js
dd-belatedpng.js
plugins.js
script.js
Conventions save you from having to figure out how the project is structured. The following conventions are the result of testing and polishing rules on production environment over the years.
Grouping is important; especially when you're working with projects that have many assets. The following rule proposes a way to organize these files into an easy to navigate way.
RULE
IF images FROM same GROUP > 5
store in new directory
repeat RULE
else
store in root
This rule may loop a max of 3 times. Having too many levels is not advised since it may make everything more complex to mantain in the long run and will make your css file bigger.
Names for individual files should always be singular, even if they're sprites that contains several elements. This is, by convention, a good practice that is taken from other web related frameworks.
Sub-Directories a.k.a. Groups should be named in their plural form when possible. Remember, this only applies to directories. For files, use the singular variant.
This whole plural/singular paradigm is to follow web frameworks and database naming conventions; think of it as a general recomendation.
background files:
bg(-group)?(-name)
sprites:
sp(-group)?(-name)
buttons:
bt(-group)?(-name)
icons:
ic(-group)?(-name)
other:
(group-)?(name)
When the file is going to have several variants, it's a good practice to append the change in type or dimension using the following pattern.
(name)((-HEIGHTx)(WIDTH)?)?
Please note
logo-300x.jpg
logo-500x250.jpg
logo-500x300.jpg
logo-300x-grayscale.jpg
Notice that you're not forced to add the height when there's no variation to that file. The x is still left in place to denote that we're talking about width and not height:
50x <- 50 width
x50 <- 50 height
Need to document this further.
/bg-content.jpg
/bg-content-light.jpg
/sp-main.jpg
/ic-form-submit.jpg
/placeholders/
content-big.jpg
content-small.jpg
content-medium.jpg
user-display-100x.jpg
user-display-200x.jpg
video-medium.jpg
+1 to everything here.
images are tricky because... well. i normally end up with two sprites... one is a big spritesheet, the other is a vertically very long sprite.. aside from that i rarely have other backgrounds or icon img files.