Comprehensive manuals or other help to set up Metadata Structure

Hi David,

Here is my attempt to answer some of your questions, although they may not necessarily be the correct!. So from my experience, having implemented M-Files a year and a half ago:

1) The number of properties does not seem to have a major impact if a user is only importing a small number of documents (i.e. 1 or 2). However, when importing a large number of documents the number of required properties becomes a big issue. I think the main issue is the time it takes.

For example, our users need to upload a lot of photos to our vault following each survey. Originally I thought that it would be great to specify individual attributes for each photo (i.e. photo type, direction, scale etc) but this drove people crazy and required a lot of time (a traditional 'photo dump' into a windows folder took maybe a a minute, importing to M-Files was now taking half an hour!). So, as you can probably guess ,these additional pieces of information are no longer used. I have kept them on the metadata card but they are no longer 'required'.

I have also found that, once I showed users that they do not have to populate the metadata card values in order, saving documents became much quicker (i.e. if they fill out Trip the Client, Project, Project Manager and Team Manager values all automatically populate). Also, showing users that they can type (which filters values) rather than scroll helped.

2) If you make generic categories users will fill them with lots of documents which will increase your workload! Also, as the administrator may not be able to accurately complete the metadata as well as the user could, which can lead to on-going issues.

So, I would rather that the user sends me an email saying 'where should I save this document?' or that they request additional categories be made. Once you update the structure let the user know and check to ensure that they have uploaded/updated the document. This way they know the process the next time a similar file appears and they may not need to contact you!

3) In my opinion, if a field has been set to 'required' then it should serve a purpose. If no value exists for this field then item is probably not meant to be saved as this object or class.

4) I think everybody wishes that they had designed some aspect of their system differently. The key is to extensively test the system before spending lot of time and resources importing documents. We, thankfully, have not had to make any major 'back-end' changes to our operational vault but I would hazard a guess that changing relationships between objects, classes and value lists would be a real pain as it would impact upon so much metadata. Inserting a new property, reassigning incorrect metadata or correcting misspelled names (even though they may appear 1000 times throughout the vault) however, is easy(ish) as you can simply search and update based on the object/class/property.

Anyway, hope this helps. I'm interested to hear other peoples take on these issues.

Cheers,

Simon

Hi David,

Here is my attempt to answer some of your questions, although they may not necessarily be the correct!. So from my experience, having implemented M-Files a year and a half ago:

1) The number of properties does not seem to have a major impact if a user is only importing a small number of documents (i.e. 1 or 2). However, when importing a large number of documents the number of required properties becomes a big issue. I think the main issue is the time it takes.

For example, our users need to upload a lot of photos to our vault following each survey. Originally I thought that it would be great to specify individual attributes for each photo (i.e. photo type, direction, scale etc) but this drove people crazy and required a lot of time (a traditional 'photo dump' into a windows folder took maybe a a minute, importing to M-Files was now taking half an hour!). So, as you can probably guess ,these additional pieces of information are no longer used. I have kept them on the metadata card but they are no longer 'required'.

I have also found that, once I showed users that they do not have to populate the metadata card values in order, saving documents became much quicker (i.e. if they fill out Trip the Client, Project, Project Manager and Team Manager values all automatically populate). Also, showing users that they can type (which filters values) rather than scroll helped.

2) If you make generic categories users will fill them with lots of documents which will increase your workload! Also, as the administrator may not be able to accurately complete the metadata as well as the user could, which can lead to on-going issues.

So, I would rather that the user sends me an email saying 'where should I save this document?' or that they request additional categories be made. Once you update the structure let the user know and check to ensure that they have uploaded/updated the document. This way they know the process the next time a similar file appears and they may not need to contact you!

3) In my opinion, if a field has been set to 'required' then it should serve a purpose. If no value exists for this field then item is probably not meant to be saved as this object or class.

4) I think everybody wishes that they had designed some aspect of their system differently. The key is to extensively test the system before spending lot of time and resources importing documents. We, thankfully, have not had to make any major 'back-end' changes to our operational vault but I would hazard a guess that changing relationships between objects, classes and value lists would be a real pain as it would impact upon so much metadata. Inserting a new property, reassigning incorrect metadata or correcting misspelled names (even though they may appear 1000 times throughout the vault) however, is easy(ish) as you can simply search and update based on the object/class/property.

Anyway, hope this helps. I'm interested to hear other peoples take on these issues.

Cheers,

Simon