Table of Contents
PASIprep Writing Guidelines
This is a language guide for the PASIprep UI Guidelines.
The following guidelines can be used as a reference as needed (though it is not enforced): writer_guide.pdf
Case styles
Sentence case should be used in all cases except in:
- Titles (page title, section title, grid title, dialog title, etc), which should use title case.
- Exception: dialog titles that are in the form of sentences should be sentence case (e.g. “Are you sure you want to do this?” in confirmation dialogs)
- Actions in Grid Action Menu Bar should use all uppercase.
- Buttons (excluding the actions within the […] “more” menu) in the Action Toolbox should be all uppercase.
- Actions within the […] “more” menu in the Action Toolbox should be in title case
Dialog titles
Confirmation dialog should have a title that repeats the action the user is trying to perform in a form of a question
- E.g. “Are you sure you want to delete the {business object name}?”
Alert/Information dialogs should have a title that reference the type of data or the action that the user was viewing/performing that triggered the dialog
- E.g. “Registration Status Information” – if it’s an informational dialog explaining different statuses
- E.g. “Error in Deleting Diploma Exam Registration” – if it’s an alert dialog to inform user of an error when they try to delete a registration.
Find dialogs should have a title that references the business object that will be found - Find XXXX
- E.g. Find Student
Section titles
If the section contains a PASIprep Business Object Grid, the section title should generally be the business object name (pluralized)
- E.g. “Student Names”, “Student Phone Numbers”, “Diploma Exam Registrations”
Common Button / Function Names
The following name should be used for common buttons:
- Save
- Cancel (for cancelling out of an action the user is in the middle of performing)
- Add
- Delete
- Edit
- Undelete
- Yes/No (for confirmation)
- Download {File Title}
- OK or Close for alert/information dialogs.
- Use the word that best matches the content of the dialog.
- e.g. if the information dialog reads “Please perform X firs before performing Y”, “OK” would be preferred because user is acknowledging an instruction.
Field Level Validation Messages
| Error Type | Message |
|---|---|
| User did not enter a required field | This field is required. |
| User entered an incorrect format for a field | Please provide a {field} in the format: {format}. e.g. “Please provide a date in the format: YYYY-MM-DDD” e.g. “Please provide an email in the format: @._” e.g. “Please provide a phone in the format: (xxx) xxx-xxxx” Note: When possible, be forgiving on the format; e.g. let user enter phone number as xxx-xxxxxxx or xxxxxxxxxxx or (xxx) xxx-xxxx. NOTE: a hint message should be provided for fields with expected format so user can see what the expected format is. The error message will echo the format if user still fails to type in the correct format. |
| User entered the wrong data type (e.g. they enter an alphabetical string instead of a number) | Please enter a valid {type}. e.g. “Please enter a valid number” e.g. “Please enter a valid date” |
| User entered a string that is too long than the number of accepted characters in a text area (or text input with large number of characters accepted, e.g. >100) NOTE for shorter text fields, the text input should simply stop user from entering more characters than allowed. | This field may not be more than {max # of char} characters. NOTE: the character counter should be displayed below fields that has an upper bound on max number of characters so user is aware of how many characters they can enter in a field. See https://material.angularjs.org/latest/demo/input for demos. |