MarioRicalde · April 9, 2011 18:24 · May 12, 2011 · May 12, 2011 · Apr 17, 2011 · Apr 17, 2011
diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -43,7 +43,7 @@ You'll spend some time trying to figure out your own code. Wasting your precious
 Members of the team will be looking into your code and you'll be looking into theirs. If you add up the time asking questions or figuring out how stuff is organized; you'll end up with a lot of **wasted** time.
 
 #### As a Team Leader
-As an Outsourcer
+As a Team Leader you know that efficiency is the key. Time is valuable for you, and you know that changes to your team is something you need to expect. Think of ho wmuch time it will take your team to figure out the work a team member left; or explain the basics to a new member.
 
 ## Overview of the Structure.
 

diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -40,7 +40,7 @@ The odds are that you're going to work alone on the project. You complete the pr
 You'll spend some time trying to figure out your own code. Wasting your precious time.
 
 #### As a member of a Development Team
-When more than
+Members of the team will be looking into your code and you'll be looking into theirs. If you add up the time asking questions or figuring out how stuff is organized; you'll end up with a lot of **wasted** time.
 
 #### As a Team Leader
 As an Outsourcer

diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -130,16 +130,15 @@ Need to document this further.
     /bg-content.jpg
     /bg-content-light.jpg
     /sp-main.jpg
+    /sp-interface.png
     /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
-      
-      
+      user-mid.jpg
+      user-small.jpg
+
       
 #### Thanks to:
 

diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -111,19 +111,16 @@ This singular vs plural convention is taken from web-related paradigms (mvc, dat
 
 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)?)?
+    (name)(-variant)
 
 Example:
 
-    logo-300x.jpg
-    logo-500x250.jpg
-    logo-500x300.jpg
-    logo-300x-grayscale.jpg
+    logo-big.jpg
+    logo-small.jpg
+    ad-skyscraper.jpg
+    ad-midsquare.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
+Using names as variants will allow you to change the proportions of the file without having to change any reference.
 
 <a name="images/examples"></a>
 ### Examples

diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -34,12 +34,16 @@ The main plus you'll get from the AVA Pattern is consitency. And that alone is s
 
 Think of the following use cases:
 
-- As a Freelancer
-  - The odds are that you're going to work alone on the project. You complete the project and months later you need to give maintenance to the project; and you completely forgot about the file structure and file names of the project. You'll spend some time trying to figure out your own code.
-- As a member of a Development Team
-  - Without a 
-- As a Team Leader
-- As an Outsourcer
+#### As a Freelancer
+The odds are that you're going to work alone on the project. You complete the project and months later you need to give maintenance to the project; and you completely forgot about the file structure and file names of the project.
+
+You'll spend some time trying to figure out your own code. Wasting your precious time.
+
+#### As a member of a Development Team
+When more than
+
+#### As a Team Leader
+As an Outsourcer
 
 ## Overview of the Structure.
 
@@ -69,7 +73,7 @@ Depending how you structure your project you may end with several files inside y
 
 The following conventions are the result of testing and polishing rules on production environment over the years.
 
-Please keep in mind, that we don't advise to have many images in your directory; you should **always** use sprites when aplicable.
+Please keep in mind, that we don't advise to have many images in your directory; you should **always**<> use sprites when aplicable.
 
 <a name="images/grouping-rules"></a>
 ### Grouping Rules

diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -65,7 +65,11 @@ Need to write some stuff here..
 <a name="images"></a>
 ## /img/ Directory Convention
 
-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.
+Depending how you structure your project you may end with several files inside your `img` directory; having a naming onvention will 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.
+
+Please keep in mind, that we don't advise to have many images in your directory; you should **always** use sprites when aplicable.
 
 <a name="images/grouping-rules"></a>
 ### Grouping Rules
@@ -84,12 +88,11 @@ This rule may loop a max of 3 times. Having too many levels is not advised since
 <a name="images/naming-rules"></a>
 ### Naming Rules
 
-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.
+Names for individual files should always be **singular**, even if they're sprites that contain several elements (`sp-interface.png`).
 
 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.
-
+This singular vs plural convention is taken from web-related paradigms (mvc, databases, etc).
 
     background files:
       bg(-group)?(-name)
@@ -105,8 +108,8 @@ This whole plural/singular paradigm is to follow web frameworks and database nam
 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 
+    
+Example:
 
     logo-300x.jpg
     logo-500x250.jpg

diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -1,3 +1,6 @@
+Note: This is still in the workings. If you have anything you want to see added into this document please leave some feedback in the comment section below; or mail me at kuroir at gmail dot com
+
+
 # Arrangement for View Assets Pattern
 
 - [Introduction to the AVA Pattern](#introduction)

diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -1,7 +1,8 @@
 # Arrangement for View Assets Pattern
 
 - [Introduction to the AVA Pattern](#introduction)
-  - [What do I get as a User from the AVA Pattern](#)
+  - [Why do we need the AVA Pattern](#)
+  - [What do I get from the AVA Pattern, besides consistency?](#)
 - [/images/ Directory Convention](#images)
   - [Grouping Rules](#images/grouping-rules)
   - [Naming Rules](#images/naming-rules)
@@ -33,6 +34,7 @@ Think of the following use cases:
 - As a Freelancer
   - The odds are that you're going to work alone on the project. You complete the project and months later you need to give maintenance to the project; and you completely forgot about the file structure and file names of the project. You'll spend some time trying to figure out your own code.
 - As a member of a Development Team
+  - Without a 
 - As a Team Leader
 - As an Outsourcer
 
@@ -128,4 +130,12 @@ Need to document this further.
       content-medium.jpg
       user-display-100x.jpg
       user-display-200x.jpg
-      video-medium.jpg
+      video-medium.jpg
+      
+      
+      
+#### Thanks to:
+
+- [Armando Canals](http://twitter.com/armandocanals) for his feedback.
+- [Cesar Salazar](http://twitter.com/cesarsalazar) for his feedback.
+- [Chris Eppstein](http://twitter.com/chriseppstein) for his feedback.
diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -32,6 +32,9 @@ Think of the following use cases:
 
 - As a Freelancer
   - The odds are that you're going to work alone on the project. You complete the project and months later you need to give maintenance to the project; and you completely forgot about the file structure and file names of the project. You'll spend some time trying to figure out your own code.
+- As a member of a Development Team
+- As a Team Leader
+- As an Outsourcer
 
 ## Overview of the Structure.
 

diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -12,7 +12,7 @@
 
 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 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. This is where the Arrangement for View Assets (AVA) Pattern shines.
 
 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.
 
@@ -22,14 +22,16 @@ For instance, you may want use snake_case over the dash-case naming pattern; the
 
 ### Why do we need the AVA Pattern?
 
-You may think that there's a steep learning curve involved with the AVA Pattern; however this is not true.
+You may think that there's a steep learning curve involved with the AVA Pattern; however this is not true. The main objective of the AVA Pattern is to provide a written docuentation for you and your team to consult when in doubt about how to store your assets.
 
-### What do I get as a Developer from the AVA Pattern?
+### What do I get from the AVA Pattern, besides consistency?
 
-### What do I get as a Outsourcer from the AVA Pattern?
+The main plus you'll get from the AVA Pattern is consitency. And that alone is something that is worth your time. Consistency is not something you should only want to achieve when you're working on a team with other Developers working on the Front-End but it's something you should aim for for your own sake.
 
-### What do I get as a Project Manager from the AVA Pattern?
+Think of the following use cases:
 
+- As a Freelancer
+  - The odds are that you're going to work alone on the project. You complete the project and months later you need to give maintenance to the project; and you completely forgot about the file structure and file names of the project. You'll spend some time trying to figure out your own code.
 
 ## Overview of the Structure.
 

diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -1,6 +1,7 @@
 # Arrangement for View Assets Pattern
 
 - [Introduction to the AVA Pattern](#introduction)
+  - [What do I get as a User from the AVA Pattern](#)
 - [/images/ Directory Convention](#images)
   - [Grouping Rules](#images/grouping-rules)
   - [Naming Rules](#images/naming-rules)
@@ -19,6 +20,17 @@ Take these with a grain of salt and remember that you should always use what you
 
 For instance, you may want use snake_case over the dash-case naming pattern; these types of modifications are a matter of preference. 
 
+### Why do we need the AVA Pattern?
+
+You may think that there's a steep learning curve involved with the AVA Pattern; however this is not true.
+
+### What do I get as a Developer from the AVA Pattern?
+
+### What do I get as a Outsourcer from the AVA Pattern?
+
+### What do I get as a Project Manager from the AVA Pattern?
+
+
 ## Overview of the Structure.
 
 Need to write some stuff here..

diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -99,6 +99,7 @@ Notice that you're not forced to add the height when there's no variation to tha
 <a name="images/examples"></a>
 ### Examples
 
+Need to document this further.
 
     /bg-content.jpg
     /bg-content-light.jpg

diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -9,15 +9,15 @@
 <a name="introduction"></a>
 ## Introduction to the AVA Pattern
 
-In the later years we’ve been seeing a lot of improvements on the organization procedures for web applications. Specially with the MVC Pattern which greatly improved development speeds by imposing a well structured architecture, that allowed developers to feel at home with any application that used the pattern.
+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.
 
-Model-View-Controller 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. Which is what The Arrangement for View Assets Pattern is.
+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, specially during advanced stages of the application.
+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 accostumed to; these conventions may be modified to fit your project, however try to follow the general idea about the structure.
+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.
 
-Common stuff you may be willing to change is using snake_case over the dash-case naming pattern for instance.
+For instance, you may want use snake_case over the dash-case naming pattern; these types of modifications are a matter of preference. 
 
 ## Overview of the Structure.
 
@@ -41,14 +41,14 @@ Need to write some stuff here..
       script.js
 
 <a name="images"></a>
-## /img/ Directory Conventiona
+## /img/ Directory Convention
 
-Conventions save you from having to take some time 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.
+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.
 
 <a name="images/grouping-rules"></a>
 ### Grouping Rules
 
-Grouping is important; especially when you're working with projects that have many assets. The following rule proposes a way to organize this files into a easy to navigate way.
+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
@@ -62,9 +62,9 @@ This rule may loop a max of 3 times. Having too many levels is not advised since
 <a name="images/naming-rules"></a>
 ### Naming Rules
 
-Names for individual files should always be in **singular**, even if when they're a sprite that contains several elements. This is by convention a good practice that is taken from other web related frameworks.
+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.
+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.
 
@@ -80,7 +80,7 @@ This whole plural/singular paradigm is to follow web frameworks and database nam
     other:
       (group-)?(name)
 
-When the file is going to have several variants; it's a good practice to append the change, in type or dimention, using the following pattern.
+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)?)?
 
@@ -91,7 +91,7 @@ Please note
     logo-500x300.jpg
     logo-300x-grayscale.jpg
 
-Note 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:
+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

diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -41,7 +41,7 @@ Need to write some stuff here..
       script.js
 
 <a name="images"></a>
-## /images/ Directory Convention
+## /img/ Directory Conventiona
 
 Conventions save you from having to take some time 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.
 

diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -15,17 +15,36 @@ Model-View-Controller Pattern is oriented to the back-end. There’s a specifica
 
 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, specially during advanced stages of the application.
 
+Take these with a grain of salt and remember that you should always use what your team is accostumed to; these conventions may be modified to fit your project, however try to follow the general idea about the structure.
+
+Common stuff you may be willing to change is using snake_case over the dash-case naming pattern for instance.
 
+## Overview of the Structure.
+
+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
 
 <a name="images"></a>
 ## /images/ Directory Convention
 
 Conventions save you from having to take some time 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.
 
-Take these with a grain of salt and remember that you should always use what your team is accostumed to; these conventions may be modified to fit your project, however try to follow the general idea about the structure.
-
-Common stuff you may be willing to change is using snake_case over the dash-case naming pattern for instance.
-
 <a name="images/grouping-rules"></a>
 ### Grouping Rules
 

diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -7,7 +7,7 @@
   - [Examples](#images/examples)
 
 <a name="introduction"></a>
-# Introduction to the AVA Pattern
+## Introduction to the AVA Pattern
 
 In the later years we’ve been seeing a lot of improvements on the organization procedures for web applications. Specially with the MVC Pattern which greatly improved development speeds by imposing a well structured architecture, that allowed developers to feel at home with any application that used the pattern.
 

diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -1,10 +1,22 @@
-# The Index
+# Arrangement for View Assets Pattern
 
+- [Introduction to the AVA Pattern](#introduction)
 - [/images/ Directory Convention](#images)
   - [Grouping Rules](#images/grouping-rules)
   - [Naming Rules](#images/naming-rules)
   - [Examples](#images/examples)
 
+<a name="introduction"></a>
+# Introduction to the AVA Pattern
+
+In the later years we’ve been seeing a lot of improvements on the organization procedures for web applications. Specially with the MVC Pattern which greatly improved development speeds by imposing a well structured architecture, that allowed developers to feel at home with any application that used the pattern.
+
+Model-View-Controller 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. Which is what The Arrangement for View Assets Pattern is.
+
+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, specially during advanced stages of the application.
+
+
+
 <a name="images"></a>
 ## /images/ Directory Convention
 

diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -8,7 +8,11 @@
 <a name="images"></a>
 ## /images/ Directory Convention
 
-Conventions save you from having to take some time to figure out how the project is structured; these  are the result of testing and polishing rules on production environment.
+Conventions save you from having to take some time 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.
+
+Take these with a grain of salt and remember that you should always use what your team is accostumed to; these conventions may be modified to fit your project, however try to follow the general idea about the structure.
+
+Common stuff you may be willing to change is using snake_case over the dash-case naming pattern for instance.
 
 <a name="images/grouping-rules"></a>
 ### Grouping Rules
@@ -22,14 +26,17 @@ Grouping is important; especially when you're working with projects that have ma
       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.
+
 <a name="images/naming-rules"></a>
 ### Naming Rules
 
-Names for individual files should always be in **singular**, even if when they're a sprite that contains several elements. This is by convention a good practice that is taken from other frameworks.
+Names for individual files should always be in **singular**, even if when they're a sprite 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.
 
-The General rule to name files:
+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)
@@ -46,10 +53,18 @@ When the file is going to have several variants; it's a good practice to append
 
     (name)((-HEIGHTx)(WIDTH)?)?
 
+Please note 
+
     logo-300x.jpg
-    logo-500x.jpg
+    logo-500x250.jpg
+    logo-500x300.jpg
     logo-300x-grayscale.jpg
 
+Note 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
+
 <a name="images/examples"></a>
 ### Examples
 

diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -5,14 +5,13 @@
   - [Naming Rules](#images/naming-rules)
   - [Examples](#images/examples)
 
-
 <a name="images"></a>
-# /images/ Directory Convention
+## /images/ Directory Convention
 
 Conventions save you from having to take some time to figure out how the project is structured; these  are the result of testing and polishing rules on production environment.
 
 <a name="images/grouping-rules"></a>
-## Grouping Rules
+### Grouping Rules
 
 Grouping is important; especially when you're working with projects that have many assets. The following rule proposes a way to organize this files into a easy to navigate way.
 
@@ -24,7 +23,7 @@ Grouping is important; especially when you're working with projects that have ma
         store in root
 
 <a name="images/naming-rules"></a>
-## Naming Rules
+### Naming Rules
 
 Names for individual files should always be in **singular**, even if when they're a sprite that contains several elements. This is by convention a good practice that is taken from other frameworks.
 

diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -2,7 +2,7 @@
 
 - [/images/ Directory Convention](#images)
   - [Grouping Rules](#images/grouping-rules)
-  - [Naming Rules](images/naming-rules)
+  - [Naming Rules](#images/naming-rules)
   - [Examples](#images/examples)
 
 

diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -1,9 +1,17 @@
-# /images/ Directory Convention
+# The Index
+
+- [/images/ Directory Convention](#images)
+  - [Grouping Rules](#images/grouping-rules)
+  - [Naming Rules](images/naming-rules)
+  - [Examples](#images/examples)
 
-[Test](#lol)
+
+<a name="images"></a>
+# /images/ Directory Convention
 
 Conventions save you from having to take some time to figure out how the project is structured; these  are the result of testing and polishing rules on production environment.
 
+<a name="images/grouping-rules"></a>
 ## Grouping Rules
 
 Grouping is important; especially when you're working with projects that have many assets. The following rule proposes a way to organize this files into a easy to navigate way.
@@ -15,13 +23,14 @@ Grouping is important; especially when you're working with projects that have ma
       else
         store in root
 
+<a name="images/naming-rules"></a>
 ## Naming Rules
 
 Names for individual files should always be in **singular**, even if when they're a sprite that contains several elements. This is by convention a good practice that is taken from other 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.
 
-The General rule to name files 
+The General rule to name files:
 
     background files:
       bg(-group)?(-name)
@@ -42,9 +51,8 @@ When the file is going to have several variants; it's a good practice to append
     logo-500x.jpg
     logo-300x-grayscale.jpg
 
-<a name="lol"></a>
-
-### Example
+<a name="images/examples"></a>
+### Examples
 
 
     /bg-content.jpg

diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -42,7 +42,8 @@ When the file is going to have several variants; it's a good practice to append
     logo-500x.jpg
     logo-300x-grayscale.jpg
 
-[Lol][lol]
+<a name="lol"></a>
+
 ### Example
 
 

diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -1,6 +1,8 @@
 # /images/ Directory Convention
 
-Conventions save you from having to take some time to figure out how the project is structured; these conventions are the result of testing and polishing rules on production environment.
+[Test](#lol)
+
+Conventions save you from having to take some time to figure out how the project is structured; these  are the result of testing and polishing rules on production environment.
 
 ## Grouping Rules
 
@@ -19,6 +21,8 @@ Names for individual files should always be in **singular**, even if when they'r
 
 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.
 
+The General rule to name files 
+
     background files:
       bg(-group)?(-name)
     sprites:
@@ -30,12 +34,15 @@ Sub-Directories a.k.a. Groups should be named in their **plural** form when poss
     other:
       (group-)?(name)
 
-When the file is going to have several variants; it's a good practice to append the change, in type or dimention, for instance:
+When the file is going to have several variants; it's a good practice to append the change, in type or dimention, using the following pattern.
+
+    (name)((-HEIGHTx)(WIDTH)?)?
 
     logo-300x.jpg
     logo-500x.jpg
-    logo-gray.jpg
-      
+    logo-300x-grayscale.jpg
+
+[Lol][lol]
 ### Example
 
 

diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -29,6 +29,12 @@ Sub-Directories a.k.a. Groups should be named in their **plural** form when poss
       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 dimention, for instance:
+
+    logo-300x.jpg
+    logo-500x.jpg
+    logo-gray.jpg
       
 ### Example
 
@@ -41,6 +47,6 @@ Sub-Directories a.k.a. Groups should be named in their **plural** form when poss
       content-big.jpg
       content-small.jpg
       content-medium.jpg
-      user-display-small.jpg
-      user-display-medium.jpg
+      user-display-100x.jpg
+      user-display-200x.jpg
       video-medium.jpg
diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -15,24 +15,23 @@ Grouping is important; especially when you're working with projects that have ma
 
 ## Naming Rules
 
-Names for individual files should always be in *singular*, even if when they're a sprite that contains several elements. This is by convention a good practice that is taken from other frameworks.
+Names for individual files should always be in **singular**, even if when they're a sprite that contains several elements. This is by convention a good practice that is taken from other frameworks.
 
-Sub-Directories a.k.a. Groups should be named in their plural form when possible; there are some exceptions, like names.
+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.
 
     background files:
-      bg{-group?}{-name}
+      bg(-group)?(-name)
     sprites:
-      sp{-group?}{-name}
+      sp(-group)?(-name)
     buttons:
-      bt{-group?}{-name}
+      bt(-group)?(-name)
     icons:
-      ic{-group?}{-name}
+      ic(-group)?(-name)
     other:
-      {group?}{-name}
+      (group-)?(name)
       
-## Example
+### Example
 
-Example:
 
     /bg-content.jpg
     /bg-content-light.jpg

diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -35,7 +35,7 @@ Sub-Directories a.k.a. Groups should be named in their plural form when possible
 Example:
 
     /bg-content.jpg
-    /bg-header.jpg
+    /bg-content-light.jpg
     /sp-main.jpg
     /ic-form-submit.jpg
     /placeholders/

diff --git a/survival-kit.markdown b/survival-kit.markdown
@@ -1,4 +1,4 @@
-# Image Directory Conventions
+# /images/ Directory Convention
 
 Conventions save you from having to take some time to figure out how the project is structured; these conventions are the result of testing and polishing rules on production environment.
 
@@ -12,11 +12,12 @@ Grouping is important; especially when you're working with projects that have ma
         repeat RULE
       else
         store in root
-        
 
 ## Naming Rules
 
-Names should always be in singular, even if when they're a sprite that contains several elements. This is by convention a good practice that is taken from other frameworks.
+Names for individual files should always be in *singular*, even if when they're a sprite that contains several elements. This is by convention a good practice that is taken from other frameworks.
+
+Sub-Directories a.k.a. Groups should be named in their plural form when possible; there are some exceptions, like names.
 
     background files:
       bg{-group?}{-name}

diff --git a/survival-kit.txt → survival-kit.markdown b/survival-kit.txt → survival-kit.markdown
diff --git a/survival-kit.txt b/survival-kit.txt
@@ -0,0 +1,46 @@
+# Image Directory Conventions
+
+Conventions save you from having to take some time to figure out how the project is structured; these conventions are the result of testing and polishing rules on production environment.
+
+## Grouping Rules
+
+Grouping is important; especially when you're working with projects that have many assets. The following rule proposes a way to organize this files into a easy to navigate way.
+
+    RULE
+      IF images FROM same GROUP > 5
+        store in new directory
+        repeat RULE
+      else
+        store in root
+
+
+## Naming Rules
+
+Names should always be in singular, even if when they're a sprite that contains several elements. This is by convention a good practice that is taken from other frameworks.
+
+    background files:
+      bg{-group?}{-name}
+    sprites:
+      sp{-group?}{-name}
+    buttons:
+      bt{-group?}{-name}
+    icons:
+      ic{-group?}{-name}
+    other:
+      {group?}{-name}
+
+## Example
+
+Example:
+
+    /bg-content.jpg
+    /bg-header.jpg
+    /sp-main.jpg
+    /ic-form-submit.jpg
+    /placeholders/
+      content-big.jpg
+      content-small.jpg
+      content-medium.jpg
+      user-display-small.jpg
+      user-display-medium.jpg
+      video-medium.jpg
No results found