Options
  • Replies 7 replies
  • Subscribers 13 subscribers
  • Views 170 views
  • Users 0 members are here
Related

Class - Doc Type: a design brainstorm

jmt@stricklandsolutions.com

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!!

  • For what it's worth, Industry Solutions Builder uses option 3 (Doc Type is a sub-list of Class and filtered by Class selection). Many of the classes have duplicate "Other" document type underneath them, for instance. For a lengthier description of the Client Information Management solutions built with ISB, you can watch this video. Partner Portal also has metadata structure documentation for these solutions.

    Regarding your example above, I think using "Sale Related Document" as a class should be reconsidered since it describes a process and not the document itself. You could use "Sale Related Documents" as a class group instead and have Proposal, Agreement and Notes as classes underneath it. One class can exist in multiple class groups, so you can add for instance Notes to several groups. Under Doc Types you could then have further classification, for instance class Agreement could have Doc Types Sales Agreement, Subcontracting Agreement and Non-Disclosure Agreement.

    It's an interesting topic, so happy to hear about other approaches and experiences as well!

  • I sometimes create the Doc.Type value list as sub list of Class. This way you do not need filters. You have a clear linkage between Doc.Type and Class, and you can use the same property in all classes and views. The downside is that editing the Doc.Type value list is a bit more complicated and requires understanding of the sub list concept.

  • in reply to Joonas Linkola

    You are correct Joonas, maybe my example would have been more accurate with "Contracts or Agreement Documents".

    I purposefully left the Class Group concept out of my options, as I believe that for a company where M-Files is the main enterprise content management solution they will likely need the class groups to filter out departments content type, like "Sales", "Legal", "HR", etc...

    I have never been a fan of duplicating values (to say the least, actually I'm staying away from them like the plague!)... It makes searching and creating views tricky usually and confuses users. Am I overthinking this?

  • in reply to bright-ideas.dk

    Fair enough, another great option. Wouldn't that keep you from "A Doc Type should be applicable to multiple Classes" requirement? Or maybe you create duplicate values as well?

  • in reply to jmt@stricklandsolutions.com

    Yes, it is necessary to create the required options in each class. That obviously will include duplicates in some places. However, it does not create issues beyond the trivial work at creation and maintenance of the value list. Users will not notice the duplicates because they only get one option when they have selected the class.

  • I guess I'd go for document types as classes and use permissions to create illusion of having seperate folders/Classes.

    For example if "notes" is common on every department, I'd have a class named Notes with appropiate metadata. I'd add employee name and department on auto fill by MDCC so I'd have proper rights for every type of document. Project Design would think they add their own "Notes" while Sales, Finance is actually adding files at the same class. This will also get rid of same names in one list (IMHO, very annoying to manage and use).

    For convienence, I'd also add "Share to" property definition to the Metadata Card as multi Select from list to give additional permissions to other employees from there. 

    The other not shared document types that are specific to a department can go under Class Groups named after deparments. And in this context, I'd train users of this vault to make them add files into views we made for them or just type the class name instead of going through list as some of the classes wont be under Class Groups.Not that you can't add same Class to multiple Class Groups; that is totally possible but it will be more work for you Slight smile

  • in reply to bright-ideas.dk

    I'm not sure I'm aligned with you on that one: this has a user impact on advanced search and view creation... "Which of the 2 identically named values should I select when searching for some content or creating a view?"

M-Files
M-Files Support


© 2024 M-Files, All Rights Reserved.