You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
80 lines
4.8 KiB
80 lines
4.8 KiB
1 year ago
|
|
||
|
|
# Campus visit user interface specification
|
||
|
|
|
||
|
|
Prepared by: Michael Kowalczyk
|
||
|
|
Revision date: 10/3/2024
|
||
|
|
|
||
|
|
## Overview
|
||
|
|
|
||
|
|
A [prototype for the software is available](<../Day 13-14 (prototyping)/clickable prototype/index.html> "Clickable prototype"), and there is only one developer on this project, so this document will only go into detail on those aspects that are unclear or unspecified in the prototype.
|
||
|
|
|
||
|
|
The system will be deployed as a web app with a dedicated email address for sending notifications. Users can sign in directly or use links from emails to perform certain actions without logging in.
|
||
|
|
|
||
|
|
[In larger projects, explain here how each requirement is met.]::
|
||
|
|
|
||
|
|
## Event responses
|
||
|
|
|
||
|
|
Event responses are simple: most of the events in this system are concerned with bringing the internal data model up to date with what is going on in the problem domain. This is true for VisitRequest, ClaimVisit, ConfirmVisit, CancelVisit, AbaondonVisit, VisitTimePassed, SetCommittmentLevel, EditAvailableTimes, CreateUser, EditUser, and ChangePassword.
|
||
|
|
|
||
|
|
Internally, the system is going to model Visits, Users, and User Committments in a similar way as described in the requirements document. The main difference is that internally, the software will keep visitor data as part of the visit itself. There is little practical need to separate these, as repeat visits with the same visitor are rare; having both stored together simplifies the program and only costs a few extra keystrokes for the coordinator on rare occasions. Also, many of the attributes can be folded together. The result is indicated in the following internal data model.
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
AdjustNotificationFrequency and SetEmailLinkTimeout are administrative tasks with simple internal representations.
|
||
|
|
|
||
|
|
## Screens
|
||
|
|
|
||
|
|
In general, the screens should behave as in a standard single-page web app: hitting the tab key should cycle through interactable user interface elements in top-to-bottom order and the browser back/forward buttons are deactivated.
|
||
|
|
|
||
|
|
### Login
|
||
|
|
|
||
|
|
/clickable prototype/pages/login.png> "Login screen")
|
||
|
|
|
||
|
|
The login screen should display an error message on failed login, and should also provide the option to do password reset by email.
|
||
|
|
|
||
|
|
### User
|
||
|
|
|
||
|
|
/clickable prototype/pages/users.png> "Users screen")
|
||
|
|
|
||
|
|
Tab order on this screen is left-to-right per row. The *New user* button creates a new row with all blanks. A name and email must be provided before hitting "Save changes". Otherwise, a modal dialog will point out the omission. If a password is left blank for a user, then they aren't able to log into the system but can still use email links. Only faculty have editable/viewable availability. It is possible to have a user with no roles. Trying to close the browser or switch to the visits tab before saving will issue a warning about changes being lost (ok / cancel).
|
||
|
|
|
||
|
|
### Visits
|
||
|
|
|
||
|
|
/clickable prototype/pages/visits.png> "Visits screen")
|
||
|
|
|
||
|
|
Proposed visits are highlighted in red on the faculty screen. Proposed and assigned visits are highlighted in red on the coordinator screen (because the visit must still be confirmed with the Campus Visit office). Any edit to the filter criteria immediately updates the list. Results can be sorted increasing or decreasing by clicking on columns: visit number, date, student, times, guide, or status.
|
||
|
|
|
||
|
|
### Email click confirmation screens
|
||
|
|
|
||
|
|
/clickable prototype/pages/confirmnonvolunteer.png> "Confirm volunteer screen")
|
||
|
|
|
||
|
|
The prototype doesn't show it, but the message should imply what choice was recorded, i.e. `You have choosen "I am able to do it, but I'm not volunteering (yet). If you change your mind, you can select a different email link or log in to volunteer for this visit"`.
|
||
|
|
|
||
|
|
## Shared states
|
||
|
|
|
||
|
|
There are no shared states or files with other software systems.
|
||
|
|
|
||
|
|
## File formats
|
||
|
|
|
||
|
|
No files are held in common with other systems or with the user. Internally used file formats and/or database tables will be commented on in the architectural design stage.
|
||
|
|
|
||
|
|
## New protocols
|
||
|
|
|
||
|
|
No unique protocols will be necessary.
|
||
|
|
|
||
|
|
## Administrative tasks
|
||
|
|
|
||
|
|
See requirements document.
|
||
|
|
|
||
|
|
## Operating procedures
|
||
|
|
|
||
|
|
It is required that all users of the system check their email frequently (at least once every day or two) and respond to campus visit requests promptly. Meeting the expectation of a quick turnaround time on campus visits relies crucially on this.
|
||
|
|
|
||
|
|
## Installation procedures
|
||
|
|
|
||
|
|
This section will be deferred to the architectural design stage, since it relies on decisions not made yet.
|
||
|
|
|
||
|
|
## Preferences
|
||
|
|
|
||
|
|
The system may be simple enough that keyboard shortcuts would have little use. The plan is to develop the first version of this software and let users determine if such functionality would be useful enough to add subsequently.
|