(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.
Important: We recommend saving often. If an error is made, select Cancel to go back to the previous saved state or Delete Proposal to start again.
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”.
Progressive disclosure/conditionals
Certain fields will only appear if another field has been answered a certain way.
Caution: Toggling between fields that control the appearance of other fields will cause data present to disappear.
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.
Font
- Bold: Use to emphasise a small amount of text.
- Italics: Use only for the name of a form or a title of a formal publication.
- Strikeout: Do not use for academic calendar content.
- Underline: Do not use for academic calendar content.
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.
Lists
Bullet lists: Most commonly used. Stick with the default settings (do not choose the other shapes).
Numbered lists: Use for Additional Constraints field, or when the order of operations matters. Stick with the default settings (do not use other styles).
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.
Links
For non-Calendar links:
- URL: Insert the full URL.
- 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).
Images
Do not add images to the academic calendar.
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.