Comprehensive manuals or other help to set up Metadata Structure

This is a fascinating discussion. Some things I'm asking myself as I'm experimenting with and hoping to roll our M-Files, would like to hear input if anyone has the time:

1. How much is too much (required) metadata values? In other words, what's the point at which you're driving users crazy and/or they just start making bogus selections so they can file a document? 2 values? 4?

2. No matter how well you think it through I'm sure there are going to be scenarios you didn't think about. For those instances do you create a generic category for users to drop files into named "needs metadata" or something like that, so that you can improve your metadata structure and add metadata to those files as needed?

3. Do you ever require a field as a way to streamline metadata, but allow a value of "none" for instances in which is does not apply? Or should metadata ONLY be required when it's certain there will be a value that applies?

4. How easy is it to change en masse certain elements of meta data after you've started? I don't mean change a single value, I mean if you realize something you did is substantially wrong and you wish you'd done it another way.

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

Simon's comments are good advice. Keep it simple from the start. You can always add more details, but it can be difficult to remove them once you have started using them. So if there is no good reason, then don't create more properties or classes. Even if there seems to be a good reason, then consider the extra work required from the user. Will they accept it or will they stop using the system or find a way around it? If so, you have not gained anything but may have lost your chance to make it a successful implementation. As Simon mentioned the quantities involved makes a big difference. Extra time spent on rare occasions is acceptable, but for those documents that come in piles every day, you really need to make it simple and quick to work with.
Karl

To start with a good basic structure, I really recommend to refer to the sample vault provided with the installations.

Is there a way to restore the sample vault? The sample vault in our main installation is long gone.

You can always restore the sample vault from C:\Program Files\M-Files\\Server\sample on your server.

Perfect, thanks!

Sorry, no answer to your question how you can restore a sample vault.
I have a follow up question based on the thread above.

Jason refers to "use document templates instead of creating classes. Originally, I used classes to determine what properties to show to users. I thought it would be easier for them - but the multitude of classes just ended up being confusing. Templates would have accomplished the same thing, and would have also provided a consistent format for many document types."
However, if you use a template that still needs to be saved to a class right? So I am not sure how templates overcome creating multiple classes.
We have 'document types' under a particular class, to reduce the number of classes. (See screenshot).

Just to clarify - you are correct, you do have to create classes. But let's say for example that you have to store several types of non-disclosure agreements (NDA). Each type has some properties in common, but also you want to include some properties that are specific to each type. Rather than creating multiple NDA classes (e.g. "Customer NDA", "Supplier NDA", etc.), you might instead create one "NDA" class and just use document templates for each type. If you give each template the correct properties when you save it, you'll accomplish the same thing with an easier-to-understand vault structure for your users.

Jason