Field and Template Design Considerations
Since fields and templates are one of the major ways many users locate documents in the repository, you should carefully consider your fields and templates before creating them. In particular, bear in mind how users will be searching for the documents. Since field searches are a fast and efficient way to locate documents, it is a good idea to make sure that the fields and templates applied to documents will contain the information which users want to search for, in the format they are likely to use.
When creating fields and templates, you can choose either to create the fields first and then add them to templates, or to create the templates first and create fields for use in the template as needed. In general, you may want to create the fields first if you will be frequently searching for the same information across multiple templates or if you will be re-using the same fields in multiple templates. For instance, if you will have an Author field in most or all of your templates, you may want to create that field first, bearing the needs of all relevant templates in mind, and then add it to the templates. However, if your Invoices template will contain mostly unique fields, it may be faster to create the Invoices template and create the fields you need in the template creation dialog. In most cases you will likely use both methods: creating fields to re-use independently and creating fields specific to a particular template when creating that template.
Creating fields and templates
There are two important questions you should ask yourself when creating a field or template: what information users of this repository will use to search for documents, and how best to categorize documents within your repository. The first question is most useful when deciding on specific fields, as field values are an excellent way to search for entries. The second question is most useful when choosing what templates to include, as templates are a good way of categorizing documents and folders.
Field Creation Considerations
A field has two purposes: to provide searchable information to help users locate a document, and to provide supplemental information that the user might need once they have found it. Therefore, when deciding what fields to create (either independently or within a template), bear in mind what kind of information users will be looking for and what kind of information they will need once they have the document or folder open. For instance, if you know that users will be searching for documents by author, it is a good idea to have an Author field that they can use for this search. If you know they will be referencing invoices by an invoice number, you could add an Invoice ID field of some kind. Once the user has the entry open, they might need different information about it: the same user who used an invoice ID to locate an invoice might then want to have the customer's phone number available so they can follow up. Including a Client Phone field would be useful for this purpose.
Bear in mind that fields can be applied to documents as part of a template or as an independent field. If only a few documents will need a particular field, you can create that field independently and simply apply it to the documents that need it.
Template Creation Considerations
Once you know how much and the type of information that should be stored as field data, you will need to decide on what type of template strategy your organization will use. Templates allow you to quickly add several related fields to a document; they are also useful for categorizing documents and allowing you to find all documents of a particular type. It is therefore common for organizations to create one template for each major document type, one template per department, or a combination of the two.
Whatever template strategy you choose, it is a good idea to minimize the number of templates as much as possible. Presenting a user with a long list of templates to choose from can be daunting; if some of those templates are only used by a few documents or folders, you may be better served by combining them into a single template. Remember that you can use independent fields to customize a more general template, which allows you to add exactly the fields you want to an entry without creating extra templates.
When choosing a template strategy, consider the following:
- What types or categories of document are in my repository?
- What information is important for each document type?
- Will users be able to tell which template should be applied to individual entries? (If users don't know which template to choose, they may have trouble filing or searching for entries.)
- Should the template apply to multiple types or categories of document? (If you will process many documents of a particular type, it may be a good idea to have a single template dedicated to that type of document; however, if you have only a few documents of a particular type—or if you prefer to organize your templates by department rather than by document—it may be more efficient to design one template that can be used for several purposes.)
- How many templates will I use? (Too many templates may be confusing for users, but using only one or two templates doesn't allow you to take advantage of templates for categorization.)
Optimizing fields and templates
Once you know the type of information that should be stored in each field, and how you want to organize them into templates, you will want to optimize the manner in which users work with each field and template. This means making it more efficient to specify, view, and search for field data.
Field Names
The name assigned to a field is the first thing that a user will notice when working with field data. You should name your fields so that users can immediately tell what information should be stored in them. For instance, you might wish to create a field to store the shipping date for an invoice. If you name the field "Date," users may not know whether you mean the order date, filing date, or shipping date. Naming it "Shipping Date" would reduce confusion. However, if you wish to apply the same field to more than one template, you may wish to make the name general enough to apply to all the templates. If you want to keep track of the name of the customer for your invoices and applications, creating one field called "Customer Name" and applying it to both templates may be best.
Field Type
Another important setting is the field type. This setting determines the type of information that can be assigned to a field. An analysis of when you should use each field type is provided below. Learn more about field types.
Multiple Value Fields
You can configure fields to allow multiple values for a single entry. For instance, you might want to create a "Document Type" field to store the type of document for a field. If a document arrives that matches multiple types, you could create the field as usual and then specify that it should be a multiple-value field. The document would then be returned in a search for either type. When creating your fields, consider whether it would be useful for users to be able to set several values within the field.
Default Field Values
If a user does not have sufficient information to assign a value to a field, then he or she may leave it blank. If blank fields are undesirable, you can configure a default value for the field in question. This causes a default value to be automatically assigned to that field, unless the user sets a different value. You can use tokens to create dynamic default fields — for instance, you might want to use the date token to automatically fill a "Filing Date" field with the current date. See Appendix A: Tokens for more information.
Required Fields
If you would like to make sure that a value is always specified for a particular field, you can indicate that it is required. This means that a value is mandatory for that field when a user is setting field data. A required field is only required when it is applied as part of a template. The required setting has no effect on independent fields.
Template Field Order
Security
Security can be enforced on fields and templates. This feature is meant to prevent unauthorized users from viewing or setting field data, but it can also be used to make templates more relevant. If a user does not have rights to read the values of a field, they will not see the field at all. Thus, you can use field security to make even large templates manageable, by showing users only the fields which are relevant to them.
Optimizing Field Searches
Searching by the keywords that have been stored in a field can either be a very efficient way to find a document or it can lead to frustration. There are two major factors that determine the effectiveness of field searches. The first factor is the extent to which that field has been populated. The second factor is whether the field values assigned to documents use consistent terminology and formatting.
A field that has been applied to an entry is only useful if it has had a value assigned to it. If no value has been input, the entry will not be returned in field searches. It is therefore a good idea to ensure that fields are filled whenever possible. For instance, you may wish to set a default value on a field; this ensures that there is some value in the field at all times, while allowing users to input a different value if necessary. You can also set fields as required; when the field is applied as part of a template, users will need to fill in the field before they can save the document.
It is also important to ensure that terminology and formatting are consistent when filling in field values. Otherwise, it can be difficult for users to find documents even if the fields have been filled. For example, a user may describe the District of Columbia as any of the following: Washington D.C., D.C., DC, District of Columbia, etc. If a user needs to find all documents associated with Washington D.C., he or she may perform a search using any of those terms. If the user who filled the template field set it to "District of Columbia," but the user performing the search searches for "DC," the entry will not be returned by the search. You can avoid this problem either by creating terminology policies for your repository, or by creating list fields to ensure consistency in the way a field is filled. If the field will contain a limited number of values which can be applied to multiple documents (for instance, a list of states, departments, personnel, et cetera), you should use a predefined list. However, if the field will store unique values (for instance, addresses, phone numbers, et cetera), you should not use a predefined list. Instead, you should create a set of criteria that will guide a user when determining which term or format should be used.
Note: An administrator does not need to predict all possible values that can be assigned to a list field when setting it up. List fields can be modified in the future; see Setting a List of Values That Can Be Applied to a Field for more information.
If the values will be unique in content but of a consistent format — for instance, phone numbers — you can use field constraints to ensure consistent formatting. Users may try to store phone numbers in a variety of formats: 1 (562) 988-1688, (562) 988-1688, 562-988-1688, 5629881688, 9881688, etc. If a user performs a field search using the wrong formatting convention, then the desired document will not be found. Field constraints define a pattern that a value must match before it can be assigned to a field. In the example above, you may require that users specify phone numbers using the following pattern: (###) ###-####. By requiring that field data match a particular pattern, users can be confident as to how to specify a value when searching that field.