Add a Table covers the basics of adding a table to a form. In this article, considerations and examples are provided for several of the most commonly added tables.
Demographics
When adding a demographics table, often the goal is to report on this data across requests. When that is the case, it’s best practice to define the row and column headers. In the example table below, each row has a demographic group header defined.
If you allow applicants to define their own rows and columns, you can’t ensure consistency with the data, which makes it hard to report across requests. In the example below, applicants can select a demographic group from a drop-down for each row. Since different applicants will select different groups in any given row, there are limitations for reporting on the data in this table across requests.
Project Budget
There are two types of budgets commonly collected on a form: an organization budget and a project budget.
- With an organization budget, the goal is usually to collect the information for reference, rather than to compare it in a report across requests. The best practice in this scenario is to allow applicants to upload their budget in the format they have readily available.
- If there are a few key items from the organization budget that you want to be able to report on, consider building a small table for just those items or build separate questions on the form (e.g. a question asking for the annual operating budget).
- With a project budget, sometimes the goal is to compare the information in a report across requests. In this scenario, you might choose to build a table to collect the information.
If you choose to build a table to collect project budget information and you plan to report on the data across requests, the best practice is to define the row and column headers in the table as in the example below.
If you don’t plan to report on the information, consider allowing applicants to select their own headers as in the example below.
You might also choose to share a budget table from the application to a follow up form, adding a new column for actual expenses. In this case, it’s important to set the cells in the rest of the table with the read only required type, so that applicants can only edit data in the actual expenses column.
Extracurricular Activities
The intended use of extracurricular activities data varies, so consider your needs when structuring a table to collect this information. If the data will mainly be used to evaluate each individual request, you could build the table with more flexibility for the applicant. For example, you could allow them to record their involvement in all types of activities (e.g. community activities, school club activities, church activities, etc.) within one table. In the example below, the Activity Type column provides a drop-down with those options for each row.
If comparing extracurricular involvement by activity type across requests is important to you, best practice would be to provide less flexibility to the applicant. Building separate tables for each activity type would give you more options in reporting on this data. For example, we've built a table for school club activities below.