A topic that has fascinated me for years has been to find the most elegant design for a 2 level document classification system. Elegant as in: easy implementation/maintenance and user friendly.
With such a 2 level classification paradigm, Class would represent "what the document is applicable to", and Doc Type would be "the actual type of document". The need for a 2 level classification is a very common design to an M-Files vault in order to control the number of classes to maintain.
The requirements
- Limited number of document Class, and a Doc Type lookup property (on either a Value List or Object Type)
- Doc Type lookup properties ought to be filtered by the Class
- A Doc Type should be applicable to multiple Classes
- Nice to have: AI should be able to "auto-classify"
Example
Class: Sale Related Document
Doc Types: Proposal, Agreement, Notes
Class: Project Document
Doc Types: Plan, Deliverable, Notes
Design Options
Option 1 - Open, unfiltered Document Type list
- With this design, a Document Type value list is created and is unlinked to class. It probably doesn't respect the requirements 100%, but is one of the simplest design. Select a Class, the select a Doc Type.
- Pros: Simplicity
- Cons: Lack of control - A user could select a combination of Class an Doc Type that shouldn't exist, like Project Document and Proposal in the example above.
Option 2 - One Doc Type lookup property per Class
- One could make X different lookup properties on document types each applicable to one class.
- Pros: A clear linkage of doc type values to classes.
- Cons: Lots of value lists and properties to maintain. Search filters can be cumbersome. Might not be easy to get AI to make the right recommendations.
Option 2.b
- Document Type OT with "Related Class" property to filter which class they apply to
- X different properties lookups on the Document Types objects, filtered on the Related Class
Option 3 - Filtered Doc Type list with duplicates
- With this design, common Document Types are duplicated per Class as needed. For instance, "Notes" related to Sales Document class would have an ID of 2, and "Notes" related to Project Document class would be another Document Types having an ID of 3.
- Pros: Can be done with Value List, not need for OT
- Cons: Duplicate values might make the end user search awkward. "Which one is the actual value I need to use in my filter?"
Option 4 - Filtered Doc Type list no duplicates
- With this design, Document Type is an object type, using a "Related Doc Class" property to filter which class they apply to. In turn, Doc Type LU property on a document would be filtered by the "Related Class" which is set on the document as a clone to the document class.
- Pros: Works well responding to all design requirements
- Cons: Complex design due to 2 factors:
- The Related Class property on the Doc Type objects cannot be set through the UI, only API or MFImporter
- The filter of Doc Type LU property can only be done through a Related Class property cloning the Class value. For this cloning to happen as the user creates a new document (or reclassifies an existing one) it needs to be done through static SetValue metadata card rules… one per class.
Conclusion
Neither design is ideal! Whether the user experience is compromised, or the Complexity is a showstopper, I have yet to find the perfect design. Would love to hear other people's thoughts... Share your thoughts, share your experiences, share your creative designs!!
