Hints for good Request form design

Write out the reference interview that is required for the new form you need to design. Suit the reference interview to the audience – do you need a shorter one for clients and a longer one for staff – but remember that you cannot obtain statistics about information that you do not collect!
For most customers (depending on parameter 2.41) the only field that allows clients to submit HTML is the Question field so make sure it is used wisely. The question field is also the field that will be used to identify this question so it should be used for the main purpose of this question. Sometimes, the purpose of the question is an implied question, such as “Please obtain this ILL”, in which case the Question field can be defined as a hidden field with a default that describes the implied question.
Every form must have a Question field, and a Response method field, and enough contact details to match the Response method. If it has any bibliographic fields it must have a title field.
For each piece of data that needs to be collected, select an appropriate RefTracker field taking the data collection type (text or code table) and any functions associated with that field into account.
When you need to use a “User defined” field, appropriately name and enable the User defined field using Code tables and the Data dictionary as appropriate, before starting to create the form in Request forms. An appropriate name will help to document your use of this field.
For each form, be sure that you have included all the fields required to perform the same reference interview that you would have done in person (so the reference interview does not need to be done again). What information do you need to collect to ensure that you have all the information that you need to answer the questions AND all the information that you need for consistent statistics about every question.
If you are allowing the client to choose the response method by including the Response method field as a mandatory field), be sure that you have included all of the client contact fields that will be required to respond to clients using the response methods that you offer (in the Response method code table).
Building Response method into a form as a hidden field is often useful. If clients will ALWAYS correspond with you by email, set it to a hidden field with default “Email” and make the Email address field Mandatory. If no response is required (such as if the form is just collecting statistics), set it to “No response required”. If this form is used to record a request where the correspondence is all provided outside of RefTracker, set it to “External”. Neither “No response required” nor “External” require any client contact details to be recorded.
Is there anything that you know about this type of request that you should include as a hidden field (that client’s can’t see or change)?
Do you need to copy other staff about the progress of this request, or its answer – consider using one of the bcc: field so they are copied on the correspondence as it progresses? If you set the bcc: field as hidden clients cannot see that the emails they receive are being copied, either in the email, or the client interface request history screen.
Another option you might consider is using is the “bcc outgoing client emails” that copies the staff member sending the email (usually used where copies of emails are required for Records management purposes, or where staff want visual confirmation that emails have gone out).
Always use fields consistently. Once you use a field for one purpose, use it only for that purpose.
Do you want the end user to be able to add attachments? If so, you will need to select the way that the Attachment uploading function should be presented for your form (see the “Include requester attachment control” parameter in the Request form Edit options Other options tab.
Its a good idea to always start your Request form with a Division heading that clearly states the purpose of the form.
Don’t be afraid to include explanatory information in the Request form. It can be included in notes associated with specific fields, notes associated with Division headers, or you can create entire divisions that just provide explanatory information.
You can use HTML to improve the readability of your Request formsbold to bold textitalics for italicisered to colour the text<a href=https://www.altarama.com target=”_blank”>click here</a> to hyperlink the text click here to the URL https://www.altarama.com and have that site open in a separate window.
Do you need to consider GDPR or PII privacy? See this Privacy and Request forms help page for information about how you can allows end users to determine what happens to their Personally Identifiable Contact information.

Note that the RefTracker product is WCAG 2.0 compliant which means that it can be used by clients with assistive devices like screen readers. You do not have to do anything special when designing your forms to ensure that they are WCAG 2.0 compliant.

Similarly, RefTracker uses responsive design – you do not have to do anything special to have your form display in an easy to use format on mobile phones.

Also all RefTracker forms automatically include a number of features that prevent form filling bots from successfully submitting questions. Although form filling bots continue to get smarter, at this stage this means that there is usually no need to include a Captcha type field for ensuring that the form user is in fact a human.