The manner in which you collect information has a direct impact on the breadth and quality of data you obtain, and web forms are a big way of how users interact with online platforms. In response to this, our schema builder is a powerful tool with all the resources you need to create tight and user-friendly forms to be employed across the portal! 🖊
In this article
(click to jump to topic)
What’s a schema?
In FULL FABRIC, a schema is a form-like structure containing fill-in fields to enter data. Accordingly, our schema builder is where you can easily choose and configure the input fields you want from a variety of field types and additional settings. As with paper forms, data is inserted using text fields and checkboxes, but the cyber environment also lends itself to non-static field formats such as dropdown menus, matrixes, date pickers, file upload fields, and much more. Each format serves a specific function, as will be described below.
Where in FULL FABRIC can I build a schema?
Inside application forms, evaluation forms, event landing pages, the profile Info tab, the profile Experience tab, journeys, classes, and whatever surveys or questionnaires you build through the Forms module. In short, anywhere users and staff must submit data, be it to provide feedback, register or apply for something, dispense personal information or generate new leads. Depending on the area, different types of fields will be available, as will be detailed later on.
Please note that, for security reasons, the profile Info and Experience tabs, along with journeys and classes, are only editable by Full Fabric personnel, so send us your thoughts and ideas and we'll help you turn them into reality. ✌️
How to build a schema
Since schemas are the gateway to precious knowledge on your prospects, applicants, students, and alumni, the ball is in your court to drag and drop your desired form fields into place and adapt them to your needs however you deem logical in terms of usability, logical sequencing, and whatnot. That said, you must begin by creating one or more sections, the content categories that will serve as containers for your fields, and then creating and organizing fields into said sections.
To be sure, sections are groups of thematically related fields. For instance, a section titled Personal Information could have such fields as Name, Address, Telephone, Date of birth, and so on, and a section titled Funding could have fields such as How do you plan to finance your degree?, Do you intend to apply for a scholarship? and If yes, which one?. New sections are blank by default, and it's entirely up to you to decide which and how many fields to incorporate.
Fields are the individual questions to which you need the answer to. As mentioned already, fields are grouped into sections and can't exist outside of one.
The schema builder is composed of two panels: the left panel, where the settings are located, and the right panel, where you can position and visualize the fields you're designing:
Adding sections
To add a section, click Add new section on the top-left corner of the left panel, insert a Name and add Instructions for the user (not mandatory). The last parameter, Visible?, is a bit more complex and also found in the settings for fields, so we wrote about it under Common settings. To finish, click Save to commit to the changes or cancel to return to the main window. You can't directly define the order that a section is to appear in (by default, sections are displayed in the order that they were created), but we're able to do it on your behalf.
Double-tap the title of a section to reopen the editor. The fields inserted into a section can only be edited individually, but deleting a section deletes everything within. Do note that sections are only visible to the end-user if fields have been added to it and made visible (again, jump here to read about visibility).
Adding fields
Creating a new field is done by a simple drag-and-drop action onto the specific section that it's meant to go in, which will instantly open the field editor to set up the field.
Schemas destined to capture profile information must always ask for the respondent's First name, Last name, and Email, as these are used to validate that a profile already exists – in which case the new profile data is added to it –, or otherwise create a new one.
Editing fields is done by double-clicking the field you want to edit, as this action reopens the editor on the left. Please note that changes made are only valid for new submissions, except for deleting fields (related information irretrievably disappears everywhere).
Like sections, fields require a Name and have a text box to leave Instructions for the user. Among the additional settings, some are universal and will thus be expounded in Common settings (e.g., conditional logic, security measures, etc.), but many more are not, owing to the distinct traits of the available field types. These are divided into two branches: standard fields and fancy fields.
Standard fields are basic and highly customizable form fields to record a broad range of data, where you can define what kind of information can be entered: text, numbers, one-liners, etc. Each standard field is just one field in itself, with a very simple set-up.
Fancy fields are advanced form fields with specific uses and pre-filled options. Some fancy fields are actually a combination of multiple fields (e.g., Address and Matrix), while others allow for actions to be set up in the forms (e.g., File upload).
The standard schema fields available in FULL FABRIC are:
Instructions — A read-only field through which staff can share instructional text with candidates, such as form filling directions. To staff, it's a text field:
To candidates, a block of text:
Single line text — Can only be filled in with one line of text and accepts any kind of character, like +, #, etc., making it useful to limit content length (although there's no character max) and a popular choice for phone numbers, as country codes can be written in.
Paragraph text — Similar to the above, but with a bigger text area, allowing text to be separated by paragraphs. Introduces the ability to specify a Word limit and also accepts symbols. Very commonly employed for essays.
Number — Only accepts numeric values. Decimal points are accepted and floats are recognized.
Check box — Allows you to pre-define a list of options of which a user may tick or clear multiple boxes. Click Add more options to add another menu item or press X to remove. You can also add options in Bulk – bearing in mind that this action overwrites whatever options already existed –, like so:
This is how a checkbox looks to th§e end user:
Drop down — Also allows you to pre-define a list of options for users to choose from, the difference being that they're displayed as a menu that drops vertically when the top row is tapped, in this way revealing the choices available. The set-up is identical to that of a check box (see preceding explanation), except for the introduction of a Multi-select? control that determines if more than one value can be simultaneously selected (Yes or No). The design is great for hosting numerous options since they're neatly out of sight unless expanded.
The fancy schema fields available at FULL FABRIC are:
Programmes & Classes — This field is exclusive to institution-level application templates (therefore appearing in the resulting application forms). Seeing as the same application template can be linked to several classes, the purpose of this field is to automatically recall every class where the template is currently in use and produce an up-to-date list, from which applicants are asked to clarify the intake(s) that they wish to apply to. Consequently, the inclusion of this field in the schema is compulsory, as is its completion (in the sense that applicants have to at least pick one programme). There's a Programme choice control on your end to define if the selection aims to be applicants' Primary or Secondary choice of programme, and when designated as Primary, another thing you have to decide is How many choices? are allowed per candidate (One or Multiple).
Frequently asked questions:
➜ Why should candidates have more than one primary programme choice, or even a secondary programme choice?
In case your school makes admission offers to alternate programme choices when promising applicants don't meet the requirements for their first option or there are more applicants than open seats. There are two ways to go about it: you can either configure the application form to have two fields: a primary choice one and a secondary choice one, each allowing for one programme; or you can have a primary choice field offering room for multiple programmes. It's chiefly a matter of preference, but do take into account that, with the latter strategy, you can't tell if the applicant has a bigger inclination towards one of their chosen programmes.
➜ My secondary programme choice field is blank. How come?
Chances are that no secondary programmes and classes were attached to the application template, so go do it. 😉
➜ Where in the application template should I place a Programmes & Classes field?
The Programmes & Classes field should be one of the first things filled out by applicants, as it lays the foundation for what comes next – sometimes literally, shall other fields or even sections depend on its answer to materialize. In view of this, we recommend putting the Programmes & Classes field in one of the initial tabs of the application template, right at the top.
Address — A fixed combination of standard fields tied together to gather address information in a single, homogenous field.
Email address — Used for entering a single email address. Validates if addresses are valid in terms of format and syntax and rejects them when they aren't.
Date — Prompts users to select a date from a calendar pop-up.
Date & time — Prompts users to select a date and time from a calendar pop-up and two time sliders: an hour one and a minute one that moves in five-minute increments.
Organization — Lets people submit the businesses they've collaborated with (i.e., present and past places of work). This field is linked to the Organisations directory (accessible from the sidebar through Industry) – hence, it auto-fills as respondents type; if no match is found, a new organization is created.
Country — A drop-down selector that follows the ISO 3166 standard, comprising 249 countries. Only country names are displayed, not nationalities; to be fully coherent, you may consider phrasing nationality-related questions as What is your country of nationality?, Country of nationality, or something to the effect.
File upload — Attach files, like photos, résumés, scans of personal documents, and more. Settings-wise, you have to define if Multiple uploads? are accepted (Yes or No) and if you want to Limit file extensions? (This field accepts ALL extensions or This field accepts ONLY). By choosing the latter, you must necessarily select which extensions are okay: .pdf, .png, .jpg, .jpeg, .doc, .docx and/or .txt. There's no size limit whatsoever.
Matrix — A table (i.e., a grid that organizes information into rows and columns, or just rows, or just columns). The basic settings include having to choose a Matrix element type (i.e., the format of your table), and naming the Columns and the Rows. Press Add more columns or Add more rows to add new parameters at the bottom or the right of the roster, respectively, or tap X to discard an item. Matrixes are only available in application and evaluation templates.
So, as pointed out, there are different types of matrixes one can create:
➜ String:
The input cells look like single line text fields. Furthermore, if the table is intended to store numbers (e.g., grades, points, etc.), you can set it to Calculate Average and even define different "weights" whenever some data points are worth more than others, like so:
What this does is find the weighted average of all elements by multiplying each "weight" by its matching value, summing everything up, and then dividing the result by the sum of the weights. However, if all the data points are supposed to contribute the same, just define each as 100%, in which case a regular sum will be performed.
Here's an example of a string with average:
➜ Single choice:
Users can select one radio button per row. Here's an example:
➜ Multiple choice:
Similar to the above, but users can select multiple radio buttons per row.
➜ Drop down:
Cells feature pop-out menus containing a list of items, from which only one selection can be made. Cells are always given the same options, established by you under Choices:
Here's an example of a drop down matrix:
🚫 Note of warning: Matrixes aren't exportable to Excel, because they contain information in multiple dimensions; ergo, they can't be translated into a single cell. They can, however, be exported to PDF.
Extendable matrix (a.k.a. Ext matrix) – An advanced matrix that lets applicants and evaluators add rows and is able to blend different types of cells in one table (String, Single choice, Multiple choice, Drop down and Date). Works much like a matrix, except that you have to enable or disable the Extendable? function and go cell by cell to specify its type (String is the default):
Extendable matrixes are only available in application and evaluation forms. Here's an example of an extendable matrix, mixing drop downs, date pickers, and strings, and where applicants are able to continuously add more rows by simply clicking ADD ANOTHER:
🚫 Note of warning: Extendable matrixes aren't exportable to Excel, for the same motive as matrixes.
Common settings
There are a number of common settings across every field, ranging from the obvious to the not so obvious, that are extremely important and useful to master, so we're gonna talk about them now.
Field title – Write a name for your field. This is best worded as a question or a prompt telling the user what to do.
Instructions for the user – Add a description shedding light on what's expected from the user in respect to a certain field, including any conditions. Not mandatory.
Visible? – Opt for This field is ALWAYS visible, which does as it says and is default, or This field is visible WHEN, in which case you have to set dependencies. Essentially, this control manages the relationship between fields in the same schema tab, so setting a dependency means that the visibility of a field depends on the answer to a previous question. For instance, supposing someone claimed to be proficient at French, it makes sense to request a proficiency certificate; but if the person logged their ability as poor, asking for a certificate is moot. This ensures that follow-up questions only appear whenever pertinent, based on the responses given by the person filling the schema. When setting a visibility, the specified answer(s) must be written down exactly as in the parent question. Copy-pasting responses is the best method to guarantee a flawless reproduction.
Required – Make the question compulsory or non-compulsory through the options This field is NOT required (default), This field is ALWAYS required, and This field is required WHEN. Again, the latter concerns dependencies, covered above; in short, you can specify that a field should only be required if the answers to a previous field were such-and-such. Suffice to say, fields that already have visibility-related dependencies can't be configured as Always required, otherwise, respondents won't be able to submit the form when the field isn't triggered; either the dependencies align, or the field has to be Not Required. Dependencies can only be created between fields in the same tab.
Who can edit this field? – Restrict who can edit a field by selecting a role or an applicant state. This makes sure that only staff users from authorized teams can handle the sensitive information submitted in the schema, be it to add, delete or make changes to data; however, when it comes to forms and applications, the choice should usually be anyone, since the fields are supposed to be edited by applicants and other end users, who, besides, can have a multiplicity of states. That notwithstanding, multi-selection is supported, if you want to get particular.
Who can see this field? – Restrict the visibility of application fields, not in terms of dependencies, but in terms of security, to avoid unnecessary exposure of private information. In other words, this manages the relationship between data and staff teams. For instance, if a referee had a read-only application link, they'd be able to access an application form and see every info field inside, but you can take back control over sensitive data by specifying that only certain teams are allowed to access that information.
Map to field – Interlink the whole portal by mapping any profile field to any application, form, event, and evaluation field. This aims to automate the input of data, so that both staff and candidates only have to fill out the same value once, as the information will then spread everywhere that it was mapped to. In the top selector, you're asked to pick which field in the portal is supposed to be linked with the one you're working on, whereas the bottom selector decides the behavior of the mapping function: Overwrite existing value or Do NOT overwrite existing value (when a value already exists in the "partner" field).
*
You have reached the end of this article. Thanks for reading! 🤓 If you have any questions or comments on the topic at hand, or if you enjoy reads like this and have article requests, feel free to start a chat or e-mail us at support@fullfabric.com. Also, please leave a rating below. Your feedback is highly appreciated! 💖
_________________
PUBLISHED: December 11, 2019
LAST UPDATED: October 15 7, 2021 at 2:26 a.m.