Kiosk Queue for Students

Target release

Starfish 5.0

Document status

DRAFT

Document owner

Janet Childs

Product Manager

Janet Childs

Developers
QA

1 Linked JIRA Tickets

2 Feature Overview
2.1 Problem Domain
2.2 Personas
2.3 Use Case Overview
3 Requirements
3.1 SF Admin: Configuring Student Identifier
3.2 Overview
3.2.1 Use Case Details
3.2.2 Validation
3.3 Admin: Changes to Create / Edit Kiosk
3.4 Overview
3.4.1 Use Case Details
3.4.2 Validation
3.5 Front Desk Staff: Launching the Student Queue
3.5.1 Overview
3.5.2 Use Case Details
3.5.3 Validation
3.6 Students: Signing into Kiosk
3.6.1 Overview
3.6.2 Use Case Details
3.6.3 Validation
3.7 Students: Check Place in Queue from the Kiosk
3.7.1 Overview
3.7.2 Use Case Details
3.7.3 Validation
3.8 Students: View Queue Information on the My Success Network
3.8.1 Overview
3.8.2 Use Case Details
3.8.3 Validation
3.9 Students: View Queue Information in the Service Catalog
3.9.1 Overview
3.9.2 Use Case Details
3.9.3 Validation
4 Admin Feature Impacts
4.1 Copy Tenant
4.2 Starfish Admin: Implementation
4.3 Starfish Admin: Support & Debugging
4.4 Reporting
5 Demo Data Requirements

6 Potential Future Enhancements

Linked JIRA Tickets

Insert linked JIRA tickets here. To do this, search for all tickets related to the requirements and paste the JIRA search results link here.

Feature Overview
Problem Domain
1. Many clients use the kiosk feature of Starfish as a way to log and track sign-ins at various student service centers. Students enter their
Last Name, Student ID, Service of choice, the reason for their appointment, and if it is course specific. Starfish confirms their identity and
informs them of the number of students ahead of them in the queue.
2. The only way for students to accurately know how many are ahead of them is to sign-in. For students who have signed in and decide not
to wait, this can create inaccurate numbers in the queue and require the need for staff to manually delete students from the queue.
Knowing ahead of time how long the wait time is at the service center might prevent some students from signing in and then leaving
before being seen.
3. Without knowing how long their expected wait time is, busy students may shy way from signing in or even delay going to student services
for fear of not having enough time. This is of particular concern in high volume centers or where multiple student service centers share a
waiting room and it is not clear who is waiting for what service.
4. There are several variables in how clients may use the kiosk features.
a. Some offer a one stop shop with multiple services being offered through one kiosk, while others offer a kiosk at each distinctly
separate service center.
b. Clients have various degrees of sensitivity to privacy. For example FirstName, LastInitial may be appropriate for some institutions
while it may not be appropriate for others.
c. Some clients may wish to display general kiosk information (e.g. number of students in the queue and longest wait time) on a
large mounted screen; others may wish to only have the information presented on the kiosk sign-in monitor.
d. If wait times are long, students may wish to leave the student service center and come back when it is closer to their turn. Mobile
notifications/queries and/or being able to check their status at the centers kiosk may be needed.

Personas
1. Administrators will enable the queue for any kiosk used and share the URL(s) with all necessary individuals, such as waiting room
managers and/or students.
2. Front Desk Staff will need to initiate the kiosk when the student service center opens, as well as, display the queue for students to view.
3. Students will be the primary users of this feature. Students will be able to view the queue either upon entering the student service center
or remotely through a designated URL.

Use Case Overview

Administrator: Configure Kiosk:
1. The configuration windows for creating and modifying kiosks should include a new field giving Admins the ability to turn on or off the
student view of the queue.
2. Admin should be able to choose if and how the students names and identification are to be displayed on the queue web page. (Nice to
Have)
3. Admin should also be able to create a custom description/instructions to be displayed under the header.
4. Admin needs to know the URL address generated for each kiosk specific queue.
Front Desk Staff: Launch Queue
1. When the queue feature is engaged, waiting room managers will need to open the queue web page on a waiting room monitor dedicated
to displaying the queue.
2. The queue web page should include the number of students actively in the queue, the longest wait time, and a list of students in the
queue for each service in order by sign-in times (first in, first on the list).
Student: View Queue
1. After signing in, students should be able to click a button on the sign-in page that takes them to a page where they can re-enter their Last
Name and Student ID to get an update of how many students are ahead of them in the queue and a current estimated wait time.
2. The queue web page should include a list of waiting students by (TBD method of identification) so students can visually see how many

2.
are ahead of them in the queue and where they are on the list.
3. Students should have access to the kiosk specific queue URLs where they can remotely access real time numbers of students in the
queue and the estimated wait time. This can be accomplished by:
a. giving the appropriate student service center the kiosk specific URL to post on their websites,
b. posting the queue URL in both the student's Success Network and within the appropriate student service section under the
Services tab.
Student: My Success Network
1. Include a real time view of the number of students in the queue and the longest wait time under the appropriate service within the
student's My Success Network.
Student: Service Catalog
1. In the Service Catalog, any service that has the queue feature enabled should have the queue URL listed as well as the number of
students currently waiting and the current longest wait time.

Requirements
SF Admin: Configuring Student Identifier
Overview
1. Tenants should have the ability to decide how the student identifier is to be displayed in the waiting room.

Use Case Details

Screenshot

Description
SF Admin
1. The default format for student identification is:
FirstInitial_of_FirstName + First3Letters_of_LastName +
Last4Characters_of_StudentID
2. There will be a description of the default student identifier
that includes an identifier "equation." That equation will
detail the number of letters/characters that are used and
what the displayed identifier will look like (via example).
3. An option will be available for tenants to request n letters
from the first name, n letters from the last name, and n chara
cters from the end of the student's ID. The user will be
notified of this option via the tooltip, which will read: "Please
contact Starfish Support if you wish to change this format."

Validation
1. If the user has not made a selection on how to display the student identifier, the default format for the student identifier is FirstInitial_of_Fi
rstName + First3Letters_of_LastName + Last4Characters_of_StudentID.

Admin: Changes to Create / Edit Kiosk

Overview
1. Administrators should have the following new configuration options within the Create Kiosk and Edit Kiosk feature:
a. be able to turn the queue off and on
b. choose if and how the students' names and identifications are to be displayed in the queue. (Nice to Have)
2. Provide Admin with the queue URL.

Use Case Details

Screenshot

Description
Admin :: Feature Configuration :: Kiosk
1. A new column titled "Waiting Room" should be added
between the Services and Tools columns. This should allow
users to "Show URL."

Create / Edit Kiosk

1. A new "Display Waiting Room to Students" field should be
added to the existing Create/Edit Kiosk form to allow Admins
to toggle the student view of the queue on or off.
2. This field should be added to the bottom of the form, after
the "Footer" field.
3. This field should be a required field and will include Yes/No
radio buttons. The default selection for this field should be
"No."
4. User instructions should read:
Select "Yes" if you wish to display the waiting room on a
dedicated screen in the service center or if you wish to allow
students to view the waiting room online. Otherwise, select
"No."

Validation
1. If the user has not made a selection on whether to display the queue, we should display the following message, "Please select whether
you wish to display the queue."

Front Desk Staff: Launching the Student Queue

Overview
1. Front Desk staff will need to launch the student queue by opening the student queue in a separate browser from the browser that is
currently displaying the kiosk.
2. The student queue should display each service associated with the kiosk and contain the following information:
a. name of the specific service
b. number of students waiting
c. longest wait time
d. list of students currently waiting for the service

Use Case Details

Screenshot

Description

Queue
1. When the Front Desk staff launch the student queue, the
displayed web page should include the following:
a. name of service
b. hours of operation
c. "xx students waiting without appointments" (where xx is
the number of people in the queue = total number of
walk-in students who have signed in and have not yet
had their meetings started).
d. "mm longest wait time in minutes" (where mm is the
longest wait time = current time the sign-in time for
the first walk-in student currently in the queue to have
signed in).
e. ordered list of students (first in, first in line). The default
format for student identification should to be written as
FirstInitial First3Letters_of_LastName
Last4Digits_of_StudentID (e.g. JCHIL6789) and read
top to bottom in columns left to right. (Note: If there are
more names than will neatly fit within the displayed
columns, we need to consider how the system is to
handle dividing the names into columns so that the top
ordered students are displayed above the fold.)
f. to differentiate between walk-in students and those with
appointments, an icon should be used next to the
student's identification.
g. a key with the meaning of each icon should be
displayed somewhere on the screen.
2. Each service that is associated with the a waiting room
should be displayed on the screen. The web page should be
formatted to contain 1-column for one service, 2-columns for
two services, 3-columns for three services.
3. Because this could be displayed on a static wall mounted
screen with no scrolling ability, the web page should be
designed for a minimum resolution of 1024x768 (this may be
adjusted based on testing).
4. Waiting rooms that contain 3 or less services should
auto-refresh every 10 seconds.
5. Waiting rooms that contain more than 3 services should
rotate through screen views, for example Services 1-3
displays first, then automatically changes to display Services
4-6, then automatically changes to display Services 7-9, etc.
This should be done on a timed loop and pages should
refresh with current information as they rotate.

Starfish Session
1. The front desk staff member's session should quit when they
launch the Student Queue from Starfish.

Validation
There are no validation requirements for Launching the Student Queue.

Students: Signing into Kiosk

Overview
1. The current feedback or welcome page needs to be edited to include the longest wait time students are currently experiencing.

Use Case Details

Screenshot

Description
Kiosk :: Welcome Page
1. After a student signs in, a welcome/confirmation page will
display, with a message that reads:
a. The Kiosk header as title.
b. All messages will begin: "Welcome, {Student Name}."
c. The message will continue:
i. For walk-in students: "You have signed in to the
{Service Name} waiting room. There are xx student
s ahead of you in the waiting room and the longest
wait time is mm minutes."
1. When there are 0 students in the queue,
message should read, "You have signed in to
the {Service Name} waiting room. You are the
first student in the queue."
ii. For students with appointments: "You have signed
in for your 1:15 pm appointment."
iii. For group session appointments: "You have signed
in for the 1:15 pm session: {Group Session
Name}."
d. All messages will conclude: "This page will
automatically return to the kiosk homepage in 10
seconds: {Countdown in Seconds}..."
e. The Kiosk footer.
2. To increase readability, font size for the feedback message
should be larger than what currently exists.
3. This page will be displayed for ten seconds before returning
to the kiosk sign-in page.

Validation
1. If a student tries to Check Status from the sign-in page, return a message that states,
a. For walk-in students: "You have already signed in. There are xx students ahead of you in the waiting room and the longest wait
time is mm minutes."
b. For students with appointments: "You have already signed in for your 1:15 pm appointment."
c. For group session appointments: "You have already signed in for the 1:15 pm session: {Name of Group Session}."

Students: Check Place in Queue from the Kiosk

Overview
1. There needs to be an eye catching button somewhere on the sign-in page giving students who have already signed in the option of
checking where they are currently ranked within the queue.

Use Case Details

Screenshot

Description

Kiosk :: Student Sign-In Page

1. A button needs to be added to the sign-in page with the text
"Check Status."
2. Above the button, there should be the following user
instructions, "If you have already signed in to the waiting
room and wish to check your status, please click the "Check
Status" button below."

Student Sign In Page

1. When students click on "Check Status" they should be taken
to a screen that displays:
a. the Kiosk header
b. user instructions that read, "Please swipe your
Excellent Card or enter your Last Name and Student ID
below, then click the "Check Status" button.
c. "Last Name" field
d. "Student ID" field
e. "Never Mind" and "Check Status" buttons
f. the Kiosk footer

Update Page
1. After a student clicks "Submit" they should be taken to a
status page, with a message that reads:
a. The Kiosk header as title.
b. All messages will begin: "Welcome back, {Student
Name}."
c. The message will continue:
i. For walk-in students: "You are signed in to the
{Service Name} waiting room. There are xx student
s ahead of you in the waiting room and the longest
wait time is mm minutes."
1. When there are zero students in the queue,
message should read, "You have signed in to
the {Service Name} waiting room. You are the
first student in the queue."
ii. For students with appointments: "You are signed in
for your 1:15 pm appointment."
iii. For group session appointments: "You are signed
in for the 1:15 pm session: {Group Session
Name}."
d. All messages will conclude: "This page will
automatically return to the kiosk homepage in 10
seconds: {Countdown in Seconds}..."
e. The Kiosk footer.
2. To increase readability, font size for the feedback message
should be larger than what currently exists.
3. This page will be displayed for ten seconds before returning
to the kiosk sign-in page.

Validation
1. If a student tries to check their status from the sign-in page, return a message that states, "You have already signed in. There are xx stud

1.
ents ahead of you in the waiting room and the longest wait time is mm minutes."
2. If a student is not signed in and selects check status, return a message that states, "You are <b>not</b> signed in to the {Service Name}
waiting room. There are xx students waiting and the longest wait time is mm minutes. To continue, please sign in." OR "You are
<b>not</b> signed in to the {Service Name} waiting room. There are no students in the waiting room. To continue, please sign in."
depending on the number of students currently signed in.
a. The words sign in in "To continue, please sign in." should be a hyperlink back to the kiosk homepage.
3. If the student enters incorrect information on the check status page, they should receive the same message they would receive from the
sign-in page.
a. No name entered: "A student last name must be provided."
b. Wrong name/student ID entered: "The student could not be found in the system."
c. No student ID entered: "A student ID must be provided."

Students: View Queue Information on the My Success Network

Overview
1. Wherever a student service with an enabled queue is displayed within the student's Success Network, the following should be included:
a. the queue URL
b. how many students are currently in the queue
c. the longest wait time for students in the queue

Use Case Details

Screenshot

Description
Student :: My Success Network
1. For all services listed under the Service tab that have
enabled queues, there should be the following information:
a. Between the email address and the website URL we
should display the services' hours of operation.
b. "Waiting Room" with a hyperlink to the waiting room
URL to open in a separate popup window.
c. "There are xx students in the queue and the longest
wait time is mm minutes." should be displayed below
the link to the waiting room URL.
d. If the student has signed into the kiosk the message
should instead read:
i. For walk-in students: "There are xx students ahead
of you in the waiting room and the longest wait time
is mm minutes."
1. When there are zero students in the queue,
the message should read, "There are no
students in the waiting room."
ii. For students with appointments: "You are signed in
for your 1:15 pm appointment."
iii. For group session appointments: "You are signed
in for the 1:15 pm session: {Name of Group
Session}."
2. This information should be directly below "See available
appointments." or "Online scheduling not available."

Validation
There are no validation requirements for My Success Network.

Students: View Queue Information in the Service Catalog

Overview
1. Wherever a student service with an enabled queue is displayed within the Service Catalog, the following should be included:
a. the queue URL
b. how many students are currently in the queue
c. the longest wait time for students in the queue

Use Case Details

Screenshot

Description
Student :: Services
1. For all services listed under the Service tab that have
enabled queues, there should be the following information:
a. Between the email address and the website URL we
should display the services' hours of operation.
b. "Waiting Room" with a hyperlink to the waiting room
URL to open in a separate popup window.
c. "There are xx students in the queue and the longest
wait time is mm minutes." should be displayed below
the link to the waiting room URL.
d. If the student has signed into the kiosk the message
should instead read:
i. For walk-in students: "There are xx students ahead
of you in the waiting room and the longest wait time
is mm minutes."
1. When there are zero students in the queue,
the message should read, "There are no
students in the waiting room."
ii. For students with appointments: "You are signed in
for your 1:15 pm appointment."
iii. For group session appointments: "You are signed
in for the 1:15 pm session: {Name of Group
Session}."

Validation
There are no validation requirements for the Service Catalog.

Admin Feature Impacts

Copy Tenant

Starfish Admin: Implementation

Starfish Admin: Support & Debugging

Reporting
No existing reports need to be modified.

Demo Data Requirements

No development work is required for the demo in relation to these requirements.

Potential Future Enhancements

Admin should be able to choose how the students names and identification are to be displayed when the queue is made public.
Admin should have the option to add a header / footer to the queue web page, if desired.
Provide additional information in My Success Network to students in respect to the waiting room, such as who the student last met with,
how long ago they met, who is working on any of their current flags within that service, etc.
Create either one web page or group of kiosks that lists all waiting rooms, number of students in each queue, and the average wait time
(this may require a field to be added to admin giving the option if whether or not a kiosk should be displayed on the list).