Folder Structure – The Ultimate Guide to an Organized Folder Structure for Multimedia

Folder structure organization is one of the most important and critical steps to success.You are at your computer, scrambling to find the right file to work on. You keep opening files, but it’s not the right one that you need. You need to find that file now – you have a deadline but you are stuck looking through a pile of files, not knowing which one is the one you need.

On top of that, many different people have worked on the project before you. They have all used different ways to name each file, and to store files in non-related locations. You need: The Ultimate Guide to Organized Folder Structure for Multimedia Projects.

We are faced with three problems:

1. We need a universal folder structure to store all our project work that is the same across all projects
2. We want it to be easy enough for newcomers to be able to use the system without training
3. A variety of people in a variety of roles and responsibilities are working on each project and they all want access to an area where they can store documents and files

Worry not – there is a cure! And yes, you can have it.

Roles

As in every production environment, there are two roles at a high level:

1. Management – deals with organizing the work and resources
2. Production - applies skills to produce the required output as specified by management

Management in this case refers to Project Management. This role needs to store documents that are generated at each phase of the project, for easy retrieval and reference. Production refers to everything from doing analysis, to creating and delivering graphics and interactive functionality.

Although there are varying levels of management in each business and production environment (e.g. Technical Management), for the purposes of clarity we are only assuming the role of the Project Manager (PM) under the management role. At the same time, since analysis and generating content are more related to the business side of a multimedia project, we group them together with the PM under a single title and directory area – Planning.

On the technical side, we want to maintain an area for two separate activities – building the project, and delivering the project.

High-level Project Directory Structure

At the highest level we maintain 3 directories:

• 01_planning
• 02_production
• 03_release

This satisfies the requirements in that it provides separate areas for separate responsibilities; it only contains three folders with some indication about which directory belongs to which role; and (this is a freebie) it follows a simplified project process.

You will notice that most folders have a number in front of the name. This is to ensure that the order of the structure remains the same.

01 Planning Directory Structure

This area is assigned to the Project Manager and Instructional Designers (content developers). The directories available under this area are:

• 01_project_management
• 02_content
• 03_proposal
• 04_DSD

Project Management Structure

This area is reserved for the Project Manager. The structure satisfies all the requirements as set out at the beginning of the article as it is relatively self-explanatory. It contains all the bare minimum items that a PM will need in the course of delivering a multimedia project. The added bonus being that any PM can access this structure in the future and be able to locate all files without much effort. Very important and useful feature if a client comes back 6 months down the track and claims some deliverable wasn’t completed, and the PM is no longer available.

Content, Proposal, and DSD Structure

These are areas that each assigned person working in these areas can use. Content can be used to store documents related to content research; proposal is self-explanatory; DSD for the delivery of the Document Strategy document.

Naming Conventions

In order to make sure that everyone in a production team is speaking the same language, some kind of a standard language is needed. This is why every manufactured part has a unique identifier, part number, or serial number. One of the most important aspects of a functioning and organized directory structure in any kind of digital or software project is – a naming convention. As far as digital production goes, naming convention can be seen as the equivalent of part serial number. Each page, across all projects in an organization, should have a unique id that carries a lot of useful information about the file. This kind of meta-data needs to be compressed so that it can be used as a file name, but at the same time contain enough information about itself so that it can immediately be located. This serial number is also used for change requests, coming from the client all the way down to production.

There can be many ways to approach this, depending on specific requirements for each company. One way is to ignore the requirement for absolute uniqueness across all projects. Although not my preference, a file can be named as: m010_s010_p010. This standard adds extra information in front of each number for m = module, s = submodule, and p = page. The letters can be omitted and the name takes the shape of: 010_010_010.

Another feature that is noticeable is the increment of 10. In this example the second page from module 1, submodule 1 would be: 010_010_020. This provides for unexpected additions in content in between established pages, after content has already been developed. Imagine having 10 pages: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10. What if you want to add a page between 5 and 6? You can make the new page 6, and then you would have to rename all pages past the new 6. Imagine if you have 50 pages, and you need to add a new second page? That is some serious time wasted. With an increment of 10, you can simply add page as 15 e.g. 010_010_015.

For a more unique approach, one that more closely resembles the manufacturing serial part idea, a file can have the name: bmw_promo201005_000010. This name contains the client (BMW) and project id (promo201005), along with a page id (000010).

02 Production Directory Structure

In the five folders that make up the production structure, the most important one is 04_build. In the 00_tools folder, we store all minor software tools, and specific project tools. You may have default system tools that you use for each project e.g. file movers, rename tools, etc. and you can place these in your default structure thereby delivering them to each new project automatically. The 01_Process_documents_and_checklists contains all files and documents in the order in which the development process follows, and this is in fact explained in detail in the 3-part series posted earlier on here as the Multimedia Development Process.

In the 02_design_standards we store all guidelines and associated files e.g. fonts, graphics, brand guidelines, and any other standards as supplied by the client. Next one is the prototype directory, and you will notice that this one has the same structure as the build directory, for obvious reasons.

04_build folder is where we store all the production files. The source directory contains the fla and actionscript files. It also provides for some discretionary structure decisions on this level. This is due to the variety of projects that the structure needs to be able to provide for. We also assume here that there is a central code repository that all projects share, and which sits on a higher / global level. The course folder is where all the deliverable content sits, or in other words, where all the files needed to run the project in the target platform are. The rest of the folders are self-explanatory and support the normal development process. An example of this is that the Instructional Designer supplies a complete storyboard in the 02_storyboard folder prior to build commencing.

03 Release Structure

As reviews by the client are a necessary part of the process, the folder structure provides a nice view of exactly what was delivered at each stage. Although we are able to roll-back file and directory changes, it is useful to have an overview of exactly what was delivered at each stage – without loading previous revisions from SVN or server backup. Four major versions are supported (Alpha, Beta, Final, Delivery), although in reality these are usually compressed to as little as two.

You are now organized

And there you have it. Hopefully, if the presented folder structure is not best suited to your projects or circumstances, you gained at least some ideas on how you can go about organizing your work and becoming more efficient. In my experience, folder structure and naming conventions are the easiest and cheapest way of reducing production time and increasing job satisfaction when working with multimedia and interactive projects. And at the same time, coming from an unorganized or inefficient structure, they provide for the biggest initial gain in productivity.

Share your experience

Did you find the post useful? Have an opposing view, or suggestions? Please comment below.

Another solution to this problem was posted by BLITZ Digital Studios some 5 years ago.

No related posts.