(for undergraduate studies proposers)
Each database is accompanied by a unique proposal form that collects and stores all the database information.
This page explains some proposal form features.
Proposal vs record fields
- Proposal fields: Only display on the proposal form, will be hidden on the approved record, but can be seen again under "View Original Proposal". When a proposal is created, either from an existing record or via “new” button, the field will be blank. For example, “rationale”.
- Record fields: Displays on both proposals and records. When a proposal is created from an existing record, the field will be pre-populated with the same information appearing on the record (if data exists for that field). Field will continue to display after proposal is approved. For example, course “title”.
Descriptions and help text
A description has been added to most fields to provide guidance. In addition, some fields have help text – denoted by a blue question mark icon – that can be viewed by hovering over the icon. This will provide additional guidance, including sending the user to specific areas of this website.
Field validation
- Fields that are required are designated with a red asterisk (*). If a field is left blank, a large red error message will appear during the submission process. Users will need to correct those errors before being able to successfully submit their proposal.
- Fields that are designated with a black cross (†) are required to be completed during the workflow – they have been designed to be left blank for submission and the key stakeholders responsible for those fields will fill them in at a later date.
Field types
Different formats were selected depending on whether content needs to appear in the academic calendar, if the answer/data triggers more fields to populate, workflow considerations, reporting functionality, and for courses specifically, integration needs with Quest.
- Pull-down menus (choose one)
- Radio buttons (choose one)
- Checkboxes (choose more than one)
- Text fields with no formatting features
- Text fields with formatting features (see below for more instructions)
- File uploads
- Type-ahead (start to type and options appear; option needs to be selected)
Text boxes with formatting
Some text boxes allow for formatting and the features are described here. For fields that display only on a proposal, formatting is flexible. However, consistency in look and feel is important to the academic calendar and for fields that display content in the academic calendar, the formatting is crucial. Contact the Office of the Registrar with any questions.
Jump to: Font | Lists | Images | Headings | Paragraph spacing | Tables | Links
Headings
Headings are an important accessibility tool. Each text box's instructions will indicate what level the first header should be (e.g., H3 or H4). Headers of the same import should have the same size. Subheaders should be one level below (do not skip headers). Do not use Heading 6 (too small).
Header size may look odd in the system, but rest assured it will look correct in the published academic calendar.
Paragraph spacing
Bullet lists are preferred over paragraph. However, paragraphs are occasionally needed. When incorporating paragraphs, do not display it with an extra space between them. At the end of the first paragraph, use the Enter key (once). Then start the next paragraph on the next line.
It looks odd in the system, and this is on the vendor's radar, but rest assured it will display correctly in the published calendar. If an extra space is forced, the paragraphs will have extra white space in the published calendar.
The spacing should look like the following example:
The student should submit a petition.
The student must apply to graduate.
Tables
Tables can be complex to build and should be used sparingly, and only for tabular data. Do not use a table to format the look of the content within the field.
Start by using the tools available in the Table builder. Contact the Office of the Registrar for assistance with tables.
Links
Most of the information needing to be added for links is the same regardless of what content the link is pointing to, with the exception of the URL. There is a special way to link internally to other Calendar content, and it is important to ensure the link continues to work year-after-year once a Calendar has been archived.
- URL:
- For links to non-Calendar content: Insert the full URL of the content's page.
- For links to Calendar ("internal links"): Only a portion of the Calendar content's URL is required. You will need to access the URL from the published Calendar. The page code is a portion of the full URL, from the # symbol to the 9-10-digit code (up to, but not including, the ? symbol that appears after navigating to the page).
- For example, Actuarial Science Minor:
- What you see as the full URL, with the key component of the URL in bold: https://uwaterloo.ca/academic-calendar/undergraduate-studies/catalog#/programs/SyxByJ00o3?bc=true&bcCurrent=Actuarial%20Science%20Minor&bcGroup=Actuarial%20Science&bcItemType=programs
- The URL needed for the internal link: #/programs/SyxByJ00o3
- Notes:
- Partial URL should contain the name of one of the databases visible in the Calendar:
- courses [for courses]
- programs [for programs and plans]
- policies [for regulations]
- The URL should not contain the website name "uwaterloo.ca/academic-calendar".
- The URL should not have the word Kuali in it (e.g., if taken from the plan page within Kuali Curriculum Management: https://uwaterloocm.kuali.co/cm/#/programs/view/64d14edd5609858391dab6bf).
- If needing to link to a new page that isn't published yet, reach out to the Office of the Registrar via the support portal for assistance.
- Partial URL should contain the name of one of the databases visible in the Calendar:
- For example, Actuarial Science Minor:
- Text to Display:
- Do not link the spaces on either side of the text being linked.
- Make the link text descriptive - users should know what they will see when they get to the link.
- Title: Leave blank.
- Target: Leave as default (None).