E-SHELF FOR SOLEDAD UNIFIED SCHOOL DISTRICT

_______________

A Capstone Report

Presented to the

Faculty of CST 499 at

California State University, Monterey Bay

_______________

In Partial Fulfillment

of the Requirements for the Degree

Bachelor of Science

in

Computer Science

_______________

by

Edgar Silverio Leos Almanza

Summer 2021
 1

Copyright © 2021
by
Edgar Silverio Leos Almanza

All Rights Reserved

 2

EXECUTIVE SUMMARY OF REPORT

E-Shelf for Soledad Unified School District
by
Edgar Silevrio Leos Almanza

Bachelor of Science in Computer Science

California State University Monterey Bay, 2021

The purpose of this project was to provide an online resource management system for

Soledad Unified School District, a public school district where on average each teacher has

seven to eight different classroom management resources. The main goal of this project is to

increment the teacher’s instructional time by reducing time looking for their resources or

forgetting their credentials. This was achieved by the main objective—to provide teachers

with a single resource where the teachers can fastly log in and have access to their full

resource roster without having to create bookmarks, overcrowding their MacBooks’

desktops, or having to remember their credentials.

Soledad Unified School district is a California school district housing over 4,500

students across five elementary schools, one middle school, and one high school. Utilizing

instructional time to its fullest for the sake of each of those students is always a challenge, so

it is important to develop a resource that can assist them to employ every single instructional

minute.
 3

TABLE OF CONTENTS

PAGE
EXECUTIVE SUMMARY OF REPORT 2
TABLE OF CONTENTS 3
LIST OF FIGURES 5
PART I 6
BACKGROUND AND APPROACH 6
INTRODUCTION 6
ISSUE: TOO MANY RESOURCES NOT ENOUGH TIME 6
SOLUTION: E-SHELF RESOURCE MANAGEMENT 7
PROJECT GOALS AND OBJECTIVES 7
GOALS 7
OBJECTIVES 8
COMMUNITY AND STAKEHOLDERS 8
EVIDENCE OF NEED 9
FEASIBILITY REPORT 10
PART II 12
DESIGN REQUIREMENTS 12
FUNCTIONAL DECOMPOSITION 12
SELECTION OF DESIGN CRITERION 14
ETHICAL CONSIDERATIONS 16
LEGAL CONSIDERATIONS 17
PART III 18
PROJECT RESULTS 18
TIMELINE AND BUDGET 18
USABILITY TESTING/EVALUATION 19
TARGET AUDIENCE 19
MAIN TASKS 19
FEEDBACK 20
FINAL IMPLEMENTATION 21
DISCUSSION 28
REFERENCES 31
APPENDIX A 32
USABILITY TEST POST-SURVEY 32
 4

APPENDIX B 34
USABILITY TESTING STUDENT SURVEY RESULTS 34
 5

LIST OF FIGURES
PAGE
Figure 1. EER Diagram for E-Shelf’s database 11
Figure 2. Functional decomposition of MVC Framework 12
Figure 3. E-Shelf flowchart 13
Figure 4. Project proposed timeline 17
Figure 5. Usability testing participant breakdown 18
Figure 6. Configure method overriding 21
Figure 7. LoginSucessHandler 22
Figure 8. Teacher page load process. 23
Figure 9. Teacher page 24
Figure 10. Admin Page showing teachers and teachers/resources 25
Figure 11. Resource Detail Modal 26
Figure 12. Teacher Edit Modal process 27
 6

PART I

BACKGROUND AND APPROACH

INTRODUCTION

The proposed project was an online school resource management system for Soledad

Unified School District -- a school district in Soledad, CA. This online school resource

management’s purpose was to congregate resource information in an easily managed, efficiently

accessible, powerful student assessment resource website application. This project has benefited

school teachers and students by aggregating their resources in a single easily accessible site.

Additionally, administrators by providing them with a tool to manage the teachers’ resources.

ISSUE: TOO MANY RESOURCES NOT ENOUGH TIME

Teachers from the district find themselves having access to online resources comprising

sometimes dozens of different web services. Said resources are, many times, difficult to manage,

easily forgotten, or simply inaccessible at a moment’s notice. During class, teachers need to

shuffle through countless tabs, shortcut links, or bookmarks. In addition, having to remember

which students, which classes, have access to what materials can take teachers’ much-needed

instructional time. Additionally, students can find themselves unable to keep track of what

resources they have access to for which classes or what their credentials for those resources are.
 7

One class alone can have access to literature, math, science, and assessment resources, each

composed of at least one or sometimes several websites where they have to log in. This issue

isn’t just restricted to the classroom. Administration can sometimes not be aware of what

resources are available for their teaching staff or students and what their credentials are.

SOLUTION: E-SHELF RESOURCE MANAGEMENT

By intelligently gathering teaching resources, E-Shelf Resource Management has been

beneficial by providing online rostering that can consist from a single classroom to potentially a

whole school distinct. One link, shortcut, or bookmark, a single login. Afterwards, a teacher is

able to select a resource or see all resources available for them. If they forgot their own

credentials for a specific resource they have been able to check in E-Shelf for it. A step above,

administrative staff is able to provide resource information to teacher accounts, see which

teachers are assigned what. The technology department can manage administrative access and

assign, add/remove, resources for the administration to have.

PROJECT GOALS AND OBJECTIVES

GOALS

The goals of this project are to:

● Increment instructional time efficiency by minimizing the time teachers need to spend

looking for a specific resource.

● Facilitate student resource availability by aggregating resources into a single access point.

● Improve resource deployment between administration and teaching staff.

 8

● Minimizing resource clutter in teacher’s technology devices as a single access point will

remove the necessity of manually having to add resources.

● Expedite student resource access by facilitating resource credentials availability for

students.

● Minimize the need for technical assistance by providing access to credential information

for teachers.

OBJECTIVES

● Create a MySQL schema to encompass student (name, id, grade, username, password),

teacher (name, id, username, password), class(name, id), school (name, id),

administrators(name, id, school) and resources(name, id, URL, icon, student_username)

with their respective interlocking keys.

● Build display queries to output information by teacher and student.

● Build teacher and student portals to display resources available as well as credentials for

said resources.

● Build an admin portal where students, teachers, classes, and resources can be created as

well as assigned.

COMMUNITY AND STAKEHOLDERS

This project was mainly targeted to school districts willing to alleviate their educational

and technology teams by integrating their resources into one easy-to-access area with a focus on

the teaching staff. Teachers are assigned a plethora of resources at the beginning of the school

year and as such, have benefitted from the knowledge that E-Shelf can be set up before the
 9

beginning of a school year. Administrators who upon finding a resource that will benefit their

schools have been able to easily convey the information to their staff.

The client group whom the project progress has been presented to is composed of a

first-grade school teacher, a school district network technician, and a systems technician. The

first-grade teacher has been teaching for over four years, three in the district, and classifies

herself as “tech-savvy to an extent” (Teacher client, personal communication, May 26, 2021).

She has experienced firsthand the trouble of having to operate a class and scramble to find her

resources online. The network technician has been working for his school district for over eight

years. Aside from having network responsibilities his duties include aiding teachers directly with

technology issues. The systems technician is experienced in ticketing systems and has

troubleshot many issues that relate to accessing resources for her company.

EVIDENCE OF NEED

During instructional time every minute counts and minutes looking for resources are

minutes wasted. Instructors have been encountered that have upwards of fifteen to twenty

bookmarks in their web browser bookmark bar. During instructional time, teachers have had to

shuffle through them to find a specific one, taking upwards to ten minutes doing this.

Additionally, instructors frequently have to be reminded of their or their student’s credentials via

the technology’s ticketing system. Since the system is managed in a FIFO fashion. Instructors

have to wait for a response which could take hours depending on the technology’s workload.
 10

FEASIBILITY REPORT

At its core, E-Shelf was a combination of website management and a student information

system. While there are many examples of each resource, an amalgamation of each that is easily

accessible as well as user-friendly with just the necessary components of each is hard to find. An

example of one of the components is the Aeries Student Information System Provides.

Aeries is a powerful, robust management environment for student information as well as

inventory management. Praised as “The design and development of this robust, user-friendly

system is rooted in over 40 years of experience in educational technology.” (Capterra, 2021).

While it has the ability to integrate with Google accounts, it lacks resource management. In

addition, it provides a potent user interface, though it could be a little daunting. From it, core

elements for student information management have been utilized.

A user-friendly resource that E-Shelf took inspiration from is Houghton Mifflin

Harcourt’s HMH Central. A student from Soledad’s Main Street Middle school is quoted as

saying “I really like how it[HMH Central] looks, the colors are nice and the pictures are big so I

know where I’m going when I click on something” (Student, personal communication, May 28,

2021). HMH Central is an excellent resource that can provide access to educational material with

the ability to roster, license, and report on students’ educational progress. Being a single resource

from the HMH suite, it lacks integration with any other resources. From it, its user-friendly

interface and simplicity have been incorporated into E-Shelf. Another admirable student

information system is Illuminate Education. Unlike Aeries, however, Illuminate provides

assessment and reporting resources. Its user interface is reported as “Friendlier than Aries'...I can

really see where each component is” (Teacher, personal communication, May 26, 2021).
 11

Its assessment resources are vast and are easily accessible. Additionally, its reporting

system is used by this district as the official grading system for lower grades. While not

integrated in this version of E-Shelf. It can potentially benefit from a similar reporting system. A

second outstanding student resource system is Accelerate Learning’s STEMscopes. It includes a

class management system in which teachers assign, educate and grade STEM material It

encompasses an easy-to-navigate administration interface where administrators level users can

easily update rosters, a similar feature was used in E-Shelf.

 12

PART II

DESIGN REQUIREMENTS

FUNCTIONAL DECOMPOSITION

E-Shelf is composed of three major, interconnected, components. These are An SQL

database to house a district’s information and their relationship tables, a Java-based Spring

Model-View-Controller framework to manage connections, and the HTML user interface.

E-Shelf’s Database consists of the school, class, teacher, resource, and user main tables.

Two auxiliary tables, class-has-teacher and Teacher-has-resource were used to implement a

“many-to-many” relationship. The relationship of the tables can be seen in the EER Diagram

displayed in Figure 1.

Figure 1. EER Diagram for E-Shelf’s database

 13

The MVC Framework is divided into a single main controller which accesses the

database via Repositories and uses specialized MVC classes to modify the incoming database

information for the HTML pages via independent object services. Additionally, security utilities

are utilized for a safeguard login system as well as for redirecting the desired user to their

appropriate page (Admin/Teacher). Finally, an additional file upload utility is used to assist with

image uploading. A functional decomposition chart of the MVC Framework can be found in

Figure 2.

Figure 2. Functional decomposition of MVC Framework

 14

The web-accessed portion of the application consists of two elements. The teacher portal

is loaded when an account with the “teacher” role is used to log in. The admin portal is loaded

when an account with the “admin” role is used to log in.

Figure 3. E-Shelf flowchart

SELECTION OF DESIGN CRITERION

Based on E-Shelf’s design specifications, and taking into account the intended audience,

several criteria were determined to assist design:

● E-Shelf is expected to handle roughly 5 to 6 page views for sessions for teachers

and around 3 to 4 for administration with that number rise at the start and end of

the school year.

● A load of 50 to 100 unique visitors at the beginning of the school year is

expected.

● Cost should be determined based on school funds allocated to technology

resources.

● Teacher portals are to be as straightforward, clean, and as user-friendly as

possible. (No extra menus or pages).

 15

● Search queries should return results within 5 to 7 seconds and should be 100%

correct all the time.

FINAL DELIVERABLES

Deliverables for this project consist of a fully developed website for teachers to log in

and have access to pre-assigned resource links as well as being able to display said resources’

credentials and an admin page for administration account holders to add/remove/update database

data. Additionally, this report, a video presentation outlining E-Shelf’s usage, benefits, and demo,

and all documentation pertaining to usability testings as determined by the usage survey at the end

of the project proposal.

APPROACH AND METHODOLOGY

The project utilizes a centralized JawsDB Kitefin MySQL database server as a backend

framework, a front-end developed online portal utilizing nodeJS, ajax, express, and CSS for

database communication and styling, and Mode-View-Controller Springboot Java framework

structure coded with Eclipse Enterprise Edition. PivotalTracker was implemented to assist with

keeping track of milestones and iteration development.

Fortuitously, the student developer happens to also be a computer technician for the

school district of Soledad, CA, and has worked on setting up class rosters for several teacher

resources. As such, the student developer is familiar with classroom/teacher database

preparation. Additionally, working with the Aeries SIS query configurations has allowed the

student developer to understand, to an extent, the school database structure. Both skills were

utilized to developed E-Shelf’s core system.

 16

Information gathering assisted the development of E-Shelf, as interviews with teachers

about the structure, flow, and content took place. During this, several iterations of the project

were presented and discussed. Major changes, including teacher page simplification, were

determined during these meetings. Additionally, school district technicians and infrastructure

technicians were consulted after every milestone for implementation feedback.

ETHICAL CONSIDERATIONS

As with all technology advancements, there will always be a divergence caused by the

socioeconomic status of the intended target communities. Oftentimes underfunded districts find

themselves having to make difficult budget decisions that end up affecting technology literacy. In

California alone, the average budget spent for k-12 education has been below the national

average according to the 2018 Public Elementary-Secondary Education Finance Data by U.S.

Census Bureau. Notwithstanding, the school district that will be the focus for E-Shelf already has

a relatively robust technology infrastructure. Teachers are well acquainted with web application

access and management and are offered educational seminars on the correct usage of their web

applications whenever possible. Additionally, students are assigned a one-to-one technology

device that can access web applications during class. They also have access to several web

applications to log in to already, making the transition to a single management system easier.

Taking this information into consideration, the development of this project has taken

technology literacy into account and has a relatively uncomplicated design for teachers that

aren’t too familiar with web application management.

 17

LEGAL CONSIDERATIONS

The most outstanding legal consideration when it comes to E-Shelf’s development is the

safeguarding, accessing, and deployment of data. Personal information security is a necessity

moreover when it comes to underage students. The Children's Online Privacy Protection Rule

("COPPA") law impedes the accumulation of informational data with regard to students under

the age of 13 without parental consent. While this has been averted during the development cycle

of the project by utilizing fictitious data, once E-Shelf is ready to be deployed schools are

allowed to act as the parent’s agent to allow data to be utilized safely under COPPA. (Federal

Trade Commission, 2021).

A second but just as important legal consideration would be the appropriate use of the

educational web program’s logos within E-Shelf. One of E-Shelf’s benefits would be the simple

visual presentation for ease of access. This includes educational web program’s clickable logos.

These logos or trademarks are protected under and while the United States trademark law in the

Lanham Act does allow non-owners of a registered trademark usage under “fair use”, it could be

difficult to determine what “fair use” would entail in E-Shelf’s situation. (UpCounsel trademark

law, 2021).
 18

PART III

PROJECT RESULTS

TIMELINE AND BUDGET

The fact that the project was implemented using the MvC framework learned in the

course prior to CST 499 facilitated project timeline constraints per the proposed project timeline

(Figure 4). Additionally, the fact that the student developer’s worksite conducted summer school

aided with continued stakeholder feedback.

Figure 4. Project proposed timeline.

For the most part, project deadlines were met by the indicated dates in Figure 4. Usability

Testing was moved from the seventh of August to the week of Sprint 3. As such Sprint 3 was cut

short and divided into Usability Testing and Reporting.

E-Shelf utilized free-to-use resources for database management and was deployed with

test data at first. As such, there is no real budget for the project.
 19

USABILITY TESTING/EVALUATION

TARGET AUDIENCE

The target audience for E-Shelf is school districts willing to alleviate their educational

and technology teams by integrating their resources into one easy-to-access area with a focus on

the teaching staff.

A total of eight teachers with technology knowledge ranging from not tech-savvy at all to

part the tech council for their school. Additionally, three technicians, two school district

technicians, and one from different technology backgrounds. Finally two administrators, a

principal, and a vice-principal. (Figure 5).

Figure 5. Usability testing participant breakdown

MAIN TASKS

The main tasks that were necessary for the usability evaluation of E-Shelf were

dependant on the role of the testee. Teachers testees were asked to log in to the website using

credentials previously provided, find a specific resource (Classkick for example), locate the
 20

credentials for the said resource (username and password), navigate that resource, navigate back

to E-Shelf, and logout. Administrators and technology testees were asked to do the same using a

teacher account as well as complete a more complicated set of steps with an administrator

account. The administrative tasks included finding a teacher, editing and deleting said teacher,

finding a resource, editing and deleting said resource, creating and deleting a school, and

creating and deleting a class. After usability testing was completed, each participant was asked to

complete a survey (Appendix A) using Google Forms. The survey requested the surveyor’s role

and asked to rate several aspects of the site. Additionally, an open-ended question was ask for

any additional feedback. Their usability ratings can be found in Appendix B.

FEEDBACK

Teachers were able to accomplish the required tasks successfully. There were a couple of

instances where a teacher would navigate straight to the resource without checking credentials.

The overall feedback was positive, with a few stating that this resource management system

“will make my life so much easier!”. There were several suggestions which included

rearranging the resource box, assistance information amongst others. The full survey report is

attached in the Appendix.

Admins were able to accomplish the required tasks for the most part. In a few cases,

E-Shelf’s admin page presented unexpected behavior (resource information not loading for

example). Overall, administration staff did remark that once the program would be completely

finalized it would definitely be beneficial. Amongst the prominent suggestions, filter search by

other information other than first or last name was suggested alongside rearranging of the

displayed information.
 21

While techs were the most scrutinizing set of the focus group, the overall response was

also positive stating that the teacher page was simple and accessible for teaching staff but that the

admin page still needed some work. The most prominent of the suggestions was that the

navigation of the admin page could be a bit more streamlined if the “Hide/Display” buttons

would automatically hide any extra tables automatically as at the moment each “hide/display”

button only works on its own table. Sorting for information was also suggested by them as well

as password modification questions.

FINAL IMPLEMENTATION

The project, in its final state, as submitted, consists of three major components- The login

page, the teacher page to display assigned resources, and the administrative page for data

management.

The login page is the starting point for the project. Simple in its design, it is implemented

utilizing SpringBoot’s security framework supporting class WebSecurityConfigurerAdapter.

This framework provides a default static login page that can be implemented. However, by

extending the class with WebSecurityConfig.java E-Shelf is able to override the default login

page with a costum one by overriding the configure method (Figure 6). Additionally, by

overriding the configure method, the system checks for username via the parameter “email”.
 22

Figure 6. Configure method overriding

Within the same extension of the WebSecurityConfigurerAdapter the method

configAuthentication utilizes a AuthenticationManagerBuilder object to encode the entered

password using BCryptPasswordEncoder and query user information from the database to check

if the user exists and if enabled.

The class ​LoginSuccessHandler which extends

SavedRequestAwareAuthenticationSuccessHandle is in charge of sending the user to the correct

page based on what credentials it has in the database. It accomplishes this by overriding the

onAuthenticationSuccess method and utilizing its HttpServletRequest, HttpServletResponse,

Authentication objects to extract the logged in user authority variable and redirect to the

appropriate API call. (Figure 7).

 23

Figure 7. LoginSucessHandler

If an API call to “/teacher” is made, the loadTeacherPage method in the Main controller

is called. The method extracts security information from the Authentication object and sends a

repository call to the database via a teacherReporitory autowired object from the

TeacherRepository class to extract the teacher information. It then creates a teacherInfo object

via the teacherService class. This is necessary, as the Teacher database class contains objects as

variables (resources and classes) and these cannot be passed to the teacher_page view as they

are. The getTeacherInfo method in TeacherServices extracts class and resource information and

adds it to a TeacherInfo object as String variables. Finally, the loadTeacherPage adds the teacher

and resources linked to that teacher via the getTeacherHasResources method attribute to the

model before sending the “teacher_page” view. (Figure 8)

 24

Figure 8. Teacher page load process

In a similar manner, if an API call to “/admin” is made, the loadAdminPage method in

the Main controller is called. Authentication is checked here for extra security via an if statement

checked within the method call that checkers the authentication object. The process in which the

teacherInfo object is created with a “/teacher” API call is repeated here alongside similar

processes for the rest of the database objects: classInfo, schoolsInfo, resourcesInfo. All database

object responses are added as attributes to the model object and the view “admin_page” is called.

The teacher page excels in its simplicity. As per teacher requested. It displays only the

resources associated with the teacher, link embedded images and a <div> embedded dynamically

programmed set of buttons that show or hide a teacher’s password for a distinct resource. (Figure

9).
 25

Figure 9. Teacher page

The administrator page handles all resource management. The design is a work in

progress as the student developer focused on functionality more than design for most of the

project’s development cycle. Similar to the teacher’s “Show/Hide” password functionality, the

admin page has four navigation buttons to the left which show/hide database resources. At the

moment, each button only interacts with its own database resource. Later implementations would

have had these buttons interact with all resources so that showing a specific resource would hide

all others. (Figure 10).

 26

Figure 10. Admin Page showing teachers and teachers/resources

Each resource table’s functions in a similar manner. A blank “Search” bar filters the

content dynamically as a user types. This is accomplished by a set of JavaScrip filter functions

which after each ‘keyup’ event-listener trigger from the search bar, read in the resource data,

create an empty array variable and for each instance of the resource if it includes the searchable

string adds that specific instance of the resource to the array. From there, the resource table is

rebuilt to contain only the information that the created array contains. Additionally, each

database resource has “Edit” , “Details” , and “Delete” buttons to the left of each individual

resource. The buttons are also added to the filtered table to keep consistency. Finally, a “New”

button appears at the top of each resource table which enables the user to add an additional

database item.

Resource change events are handled through modified BootStrap “Modal” forms and API

calls to the database. The “Details” resource modal triggers a call to the appropriate

find{resourceType}ById method in the Main controller with a @ResponseBody annotation. This

method returns the {resource}Info object from its appropriate service class allowing the modal to
 27

display the requested resource in the modal form. The pop-up modal window displays the

database resource information with the readonly parameters so as to not make any database

changes. (Figure 11)

Figure 11. Resource Detail Modal

The “Edit” Modal functions similar to the “Detail” Modal, with the exception of having

the form fields editable and including the “Submit” button. Submitting an edit form triggers the

API call for the update{resource} method. This method runs the appropriate “add” method from

the resource service which delegates whether the requested additional resource exists already in

the database. Once it determines that the resource exists it updates that resource by utilizing the

repository’s “save” method. A javascript function reads the form and checks for any previous

matches. An example of the process for the “Edit” teacher modal is shown in Figure 12.
 28

Figure 12. Teacher Edit Modal process

Lastly, the “Delete” modal reads in the id number for the selected resource and makes a

call to the delete{resource} method via the appropriate API call. It, in turn, calls the appropriate

service to delete the item from the database via the deleteById repository method.

DISCUSSION

E-Shelf was not without its major challenges. At the start of project planning a prototype

database was sketched on a whiteboard. In it, all of E-Shelf’s planned features were considered.

These included student accounts, school administrative accounts, student_has_class and

teacher_has_student linking tables. Upon further reflection, a scaling down of the database was
 29

suggested to meet deadlines. Additionally, a meeting was arranged with one of E-Shelf’s

stakeholders to present a rough prototype on paper of the intended site. In the meeting, additional

features were presented. These features included the ability for teachers to assign resources to

students as well as group students. Changes were suggested where said features were considered

unnecessary as simplicity for teacher access was the main goal. During implementation of the

EER database diagram it was discovered that an additional “users'' table needed to be

implemented for site access.

The MvC framework presented several challenges as well. Implementation of

SpringBoot’s security framework took several hours, if not a day or two to implement. Tutorials

for utilizing it were followed as best as possible but even then errors such as mismatch

credentials, sending the user to the wrong site, or missing security elements were encountered. It

wasn’t until full implementation of the supporting class WebSecurityConfigurerAdapter was

adapted and the configAuthentication was properly coded, the desired outcome was achieved.

Front-end HTML pages required an extensive amount of JavaScript and it wasn’t without

its adversities. Developing the dynamic filter system for the search bar was challenging as it

required the rebuilding of the displaying table after each key press. At the start of this

functionality testing the entire table would be filtered out, including headings. The headings for

the tables had to be separated from the rest of the table and be made their own identity.

Furthermore, the buttons for “Edit”, “Details”, and “Delete” had to be coded so they function as

expected even when filtering.

To say that the undertaking of the development of E-Shelf was no easy task is an

understatement. It took every once of the student developer’s knowledge, patience, practice and

time to get a working prototype in such a short amount of time. The student developer had an
 30

understanding of the basic functionalities of the frameworks used to develop E-Shelf prior to its

development. However, the challenge presented itself where an integration of said frameworks in

a project from the student developer’s mind and not an assigned homework with predetermined

steps and expected outcomes was needed. Nevertheless, the challenge was gladly accepted and a

desirable outcome was achieved.

Moving forward, the suggested changes from the usability testing will be integrated into

E-Shelf. Additionally, implementation of a student portal for student access would allow students

to log in and have access to their class’ resource information and an automated roster upload via

CSV files would allow for a smoother initial and yearly roster process. Once a more substantial

version of E-Shelf is finalized, it can be presented to school districts as an official piece of

software.
 31

REFERENCES

Capterra. (n.d.). Aeries SIS Pricing, Alternatives & More 2021. Aeries SIS Pricing, Alternatives

& More 2021. Retrieved June 6, 2021, from https://www.capterra.com/p/5544/Aeries

Federal Trade Commission. (2020, December 1). Children’s Online Privacy Protection Rule

(“COPPA”).

https://www.ftc.gov/enforcement/rules/rulemaking-regulatory-reform-proceedings/childre

ns-online-privacy-protection-rule

UpCounsel. (n.d.). Trademark Law: Everything You Need to Know. Retrieved June 6, 2021,

from https://www.upcounsel.com/trademark-law
 32

APPENDIX A

USABILITY TEST POST-SURVEY

33
 34

APPENDIX B

USABILITY TESTING STUDENT SURVEY RESULTS

35
36
37