There are several ways structure and name your folders and documents.
Depending on your type of project different structures and naming conventions might work better for you than others. This article contains some helpful tips when it comes to deciding how to set up your data environment.

This article contains information about the following topics:

Whether you enforce a naming convention through Catenda or just have a verbal agreement with the members of the project about what documents should be called.

Discoverability

The most important factor in the document name is discoverability.

When you look at a document name you should know what the document contains.

Being descriptive and writing out full words can help with this as you can read the word and at a glance understand the contents of the document.

What this does not mean is that the document name should be a whole sentence.

Document names that are too long to read can look like a wall of text and are quickly glanced over.

Therefore try to keep to 1 to 5 words.

A typical situation people will end up with is that they call their document something like:

Presentation_Final

Then when they need to make a change it becomes:

Presentation_Final_Final, Final_Final_For real, Final_LastOneIPromise.
At which point you give up and just call the next one:
​Presentation_Submitted

This situation can be prevented by deciding a versioning convention from the beginning.

You could start your file with Presentation_v1, Presentation_v2, etc...

This will make sure different versions of the same file in a logical order.

While there is a good revision system on Catenda it can still make sense to add a version number.

Sometimes your local revision count differs from the one that was uploaded.

Say that you uploaded v3 of the presentation but then the next one you uploaded was v5.

The revision on Catenda will increment by one while your local revision has incremented by 2. This way you can keep track of which version is the right one.

Historically systems have struggled with spaces in document names. While many systems are able to handle spaces in document names nowadays there might still be reasons to remove spaces from document names

You might want to be able to search for a two words together that are not two separate words.

You could also hope to compress the amount of characters in a name by removing the spaces.

When you take a normal filename like:

this is a normal file name that is very long with many words.png

and you remove the spaces it becomes an unreadable garbled mess as you need some visual ques to where the word boundaries lie:

thisisanormalfilenamethatisverylongwithmanywords.png

If compression is your coal you do not want to introduce another character to separate each word because you would be back to the same length as before. Instead what you can do is capitalize each word.

ThisIsANormalFileNameThatIsVeryLongWithManyWords.png

While this is already slightly better it is still pretty hard to read with longer names.

If the goal is to minimize space you can attempt to group words that belong together:

ThisIs_ANormalFileName_ThatIs_VeryLong_WithManyWords.png

Now we are beginning to enter the territory of a good, short file name that is readable.

Even when file length does not make sense, thinking about compressing words like this makes sense as it is easier to understand grouped words at a glance.

If you do not care about how long your filename gets what you can to make it even better is by introducing a secondary separator. See here how grouped words are separated in one way while the words within each group are separated in another way.

This-is_A-normal-File-name_That-is_Very-long_With-many-words.png

Note that by separating each word it was possible to add capitalize each first word but then have lowercase for the next ones.

In cases where there are many different documents that are all slightly different it does not make sense to repeat the same 4 words over and over again just to add a variation on the 5th word.

In this case you might want to use an abbreviation for each word.

Example: Architecture can turn into ARC, First floor can turn into 1st.

The fact that you can have more information in less space is both a strength and a weakness.

While it is easy to be 100% correct with the file name information this way, this is not always the best way to name your files.

When adding abbreviations you quickly start to notice your files names turn into a garbled unreadable mess.

Take for example:

20110101_ARC_BLDG1_BLCK2_FLR4_Q4_Wa3_Win4_S_C_v4
While it might make sense to the file author that this was a file from:

Jan. 01 2011 about the fourth version of a concrete sill in window 4 on wall 3 on floor 4 on block 2 in building 1 by the architect.

I am pretty sure no-one else in the project will take the time to read it.

Especially not when what the searcher was really looking for was:

20110101_ARC_BLDG1_BLCK1_FLR4_Q4_Wa2_Win3_S_C_V4

Which is a completely different window sill!

If it comes to this level it is better to split your files up in folders.

The document section is automatically sorted by name.

It can therefore be a good idea to add some characters to the beginning of the document so the most relevant document comes first.

Chronological order

In order to get a historical overview on Catenda Hub you can always sort by published or created. By standard the documents are sorted by name. When a member opens up a folder for the first time, the most recent document might therefore not be at the top.

To combat this you can add the date of the document to the front of the document:

20110101 would be the first of January 2011.

This can also be helpful if you have documents that were created a long time ago and then imported to Catenda Hub. Although this name can be altered it can be a useful bit of information when you are looking for a document.

This way you can also sort the name column by date.

Alphanumerical order

To find out what characters come before other characters please refer to the sorting order of lists on Catenda.

In order to get your documents in order of importance you can always sort by labels or amount of revisions. By standard the documents are sorted by name. When a member opens up a folder for the first time, the most important document might therefore not be at the top. To combat this you can add a character to the beginning of the name that makes it so it comes first.
For example you can call your files: 1.0 Most important. 1.1 Less important, 1.2 etc...

Then you might find out that some breaks your rule by accidentally uploading a document with a 0 in front which ends up coming first.

What you might then do is add an _ in front of the name to make sure it comes before any item.

This battle of who is first can seem endless.

It can therefore help to look at the sorting order of lists to see what characters come before others to see what makes sense to use in your case.

It can be hard to find information if there is a lot of information in a list and you have to scroll far down to find the information you are looking for.

If there are too many documents or folders in a folder, they can become hard to find as you will have to scroll far down the list to find the document you are looking for.

At this point it often makes sense to add a sub folder in this list and divide the documents by their most important property.

This can be a range of properties like:

Type of document (Drawing, image, spreadsheet)

Related topic (Walls and windows)

Field of study (ARC, MEP, STR)

Party that uploaded it (Group 1, Group 2, Group 3)

Date of upload (20110101, 20231225)

Maturity (Draft, Submitted, Approved, Denied)

Reasons that can influence the decision of how to divide your documents can be:

Discoverability

Access control

After working with a document structure for a bit you will notice that you start to create many sub-folders. If it takes many clicks to get down to the subfolder you did not solve the problem you were trying to solve by making sub folders in the first place because the information is still hard to find.

It is recommended to not go further down than 3 layers when making sub folders.

This is because most people might remember the last two folders they were in but the deeper you go the more you start to forget where you came from.

In order to prevent this you can move your sub-folders up a level.

Here is an example of a folder that is 4 levels deep:

01_Models-and-drawings

0101_Models

010101_ARC

01010101_Window

01010102_Wall

010102_MEP

01010201_Ducts

01010202_Vents

010103_STR

0102_Drawings

This folder can be simplified to become:

0101_Models_ARC

010101_Window

010102_Wall

0102_Models_MEP

010201_Ducts

010202_Vents

0103_Models__STR

0201_Drawings

Or maybe even simpler:

010101_Models_ARC_Window

010102_Models_ARC_Wall

010201_Models_MEP_Ducts

010202_Models_MEP_Vents

010301_Models__STR

020101_Drawings

As you can see, adding multiple folders that are similar on the same level can help reduce the amount of clicks it takes to get down to the folder containing the documents you are looking for.

Another thing you might notice is that the more you simply the folder structure, the longer the file names become.

When filenames become too long they become hard to read.

It is therefore important to keep a balance between file name length and folder depth.

In this document structure you structure your files after what type of document it is.
All floorplans go in the floorplans folder, all meeting summaries go in the summaries folder etc.

This file structure is easier to use for the client as files that are delivered by consultants are all gathered in once place.

This file structure is harder to use for the consultants as they have many different places where they deliver their files.

Example of file structure

An example of this type of document structure can be:

0101_Information

010101_Admin

010102_Contracts

0201_Images_Presentations

YYMMDD_Presentation-title.ppt

0202_Images_Site-visits

YYMMDD_Site-visit-title.jpg

0301_2D

03010101_Plan_Floor

030101010101_DWG_ARC

YYMMDD_Drawing-title.dwg

030101010102_DWG_STR

030101010103_DWG_MEP

030101010103_DWG_LAN

030101010201_PDF_ARK

YYMMDD_Drawing-title.pdf

030101010202_PDF_STR

030101010203_PDF_MEP

030101010203_PDF_LAN

03010102_Plan_Ceiling

03010103_Plan_Fire-escape

03010201_Section

03010301_Elevation

0302_3D

03020101_Models_Archicad

030201010101_PLN_ARC

030201010102_PLN_STR

YYMMDD_Drawing-title.ifc

030201010103_PLN_MEP

030201010104_PLN_LAN

030201010201_IFC_ARC

030201010202_IFC_STR

030201010203_IFC_MEP

030201010204_IFC_LAN

03020102_Models_Navisworks

03020103_Models_Revit

030201030101_RVT_ARC

030201030201_IFC_ARC

03020104_Models_Rhinoceros

03020105_Models_Solibri

03020106_Models_Point-clouds

03020201_Visualization_Renderings

03020202_Visualization_Images-high-resolution

In this document structure you first separate out the different fields of study that participate in your project.

This type of folder structure can be good if you want to give your users full access to their own are where they are free to move files around as they wish.

This file structure is easier to use for the consultants as they have their own area where they can have control over all the files that they are uploading.

This file structure is harder to use for the client as files from the different consultants are spread out across each their own folder.
​
​Example of file structure

0101_Information

010101_Admin

010102_Contracts

0201_ARC

02010101_2D

02010201_3D_Archicad

0201020101_PLN

0201020102_IFC

YYMMDD_Drawing-title.ifc

02010202_3D_Navisworks

02010203_3D_Revit

0201020301_RVT

0201020301_IFC

02010204_3D_Rhinoceros

02010205_3D_Solibri

02010206_3D_Point-clouds

02010307_Contracts

0202_MEP

020201_2D

020202_3D

020203_Contracts

0203_STR

0204_LAN

With models as documents enabled it is possible to connect models from the models section with documents in the documents section.

If new models are made in the models section they will appear in a folder called the models folder. Models can be moved out of the models folder and moved to where you want them to be in the document structure.

Similar to the above examples you can either structure your models by type:
01_Models -> 0101_ARC -> YYMMDD_Model-title.ifc

Or you can structure your models by field of study:

01_ARC -> 0101_Models -> YYMMDD_Model-title.ifc

The best option to choose here depends on if you think your users will be using the models filter. If you separate models per field of study it might be hard for users to find the 3D models that are mixed in with the other documents of each field of study.

If you are confident your users will find the models filter you can use this option.

If you do not believe your users will use this filter it is better to have all your models in their own models folder so that the user is aware that this folder contains models that can be opened in 3D.