Capstone Report Final

Running Head: CLASSMINDER CAPSTONE REPORT 1
Capstone Report: ClassMinder
Client:
Chad Martinez
Team members:
Moises Bernal
Nicholas Tippner
Course:
CST 499: Directed Group Capstone
California State University, Monterey Bay
June 12, 2018

PROPOSAL FOR A BEHAVIOR TRACKING APPLICATION 2
Table of Contents
Executive Summary……………………………………………………………………………. ...3

Part 1…………………………………………………………………………………………… ...4
Introduction………………………………………………………………………………… ...4
Problem/Issue in ...6
Technology……………………………………………………………….
Solution to the Problem/Issue……………………………………………………………… ...6
Project Goals and Objectives………………………………………………………………. ...7
Stakeholders and Community……………………………………………………………… ...8
Evidence that the Project is Needed……………………………………………………….. ...9
Feasibility Discussion……………………………………………………………………… ...9
Part 2…………………………………………………………………………………………… .13
Functional Decomposition…………………………………………………………………. .13
Selection of Design Criterion……………………………………………………………… .14
Final Deliverables………………………………………………………………………….. .15
Approach/Methodology……………………………………………………………………. .16
Legal Consideration………………………………………………………………………... .17
Ethical Consideration………………………………………………………………………. .17
Part 3…………………………………………………………………………………………… .19
Timeline/Budget…………………………………………………………………………… .19
.
Usability .22
Testing/Evaluation………………………………………………………………..
Final Implementation………………………………………………………………………. .24
Conclusion…………………………………………………………………………………. .35
References……………………………………………………………………………………… .38
Appendix……………………………………………………………………………………….. .39
Appendix A………………………………………………………………………………… .39
Appendix B………………………………………………………………………………… .41
Appendix C………………………………………………………………………………… .42
Executive Summary
Many schools currently have methods that track classroom behavior either through Excel
sheets, whiteboard applications, or simple pen and paper. However, current methods are
rudimentary or require heavy involvement from the teacher during class time. This proposal will
go over a product that tracks classroom behavior in an intuitive and easy-to-use way.
Program goals include designing an application that will improve efficiency of entering
behavior data for teachers, identify patterns of behavior for teachers, improve academic
performance of students, and improve communication between parents and teachers, as well as
fully deploying this application in a school and establishing secure protection for behavior data
and communication channels.
The timeline for completing this project took place over an eight week period beginning
April 25 and ending June 16. In the first week, the developers researched behavior data and
compiled resources around behavior improvement and completed the full design for the
application. Implementing student profiles, behavior tracking, a communication method for
parents and teachers, and security protocols and encryption for behavior and communication data
were done in weeks 2 and 3. At this point, the first week of testing began, with feedback being
reviewed and implemented by week 5. The final features were implemented by week 6, and
week 7 consisted of the last week of testing. All improvements will documented and the program
will be presented at the end of week 8.
The purpose of the application is to track both behavior and academic standing, as well as
schedule meetings between parents and teachers so that issues can be addressed. Keeping track
of student behavior information will allow teachers to identify trends that would indicate whether
a student is on a path to success or if a student is falling behind. It will also allow parents to have
more updates on their child’s behavior, so that corrections can be made faster than if they were
just informed at a yearly PTA meeting.
The initial population that will be affected by this application include teachers, parents,
and students that are a part of Wasco High School, as well as any other school populations that
are willing to participate in the testing phase of the project’s runtime. The client for this project is
Chad Martinez, a mathematics teacher that gained approval to test this project from Wasco High
School’s administrative board. If the project is successful, then this application could positively
affect school populations across the country.
After the testing phase is complete, the main anticipated outcome was successfully
producing a working version of the designed application. This included all critical errors being
resolved, all database entries being able to register successfully, and all meetings being arranged
successfully. Beyond getting a functional version of the product working, the development team
is looking to make sure that the client and all stakeholders are satisfied with usability, and
security protocols are successful so that the integrity of student behavior data is maintained.
Since the development of the product met all anticipated outcomes, the development team will
look to market the product to other educational facilities that would be able to make use of it.
PART 1:
Introduction
For this Capstone project, this team worked with high school teacher Chad Martinez to
develop a behavior tracking application in the academic environment called ClassMinder. The
application tracks both behavior and academic standing, as well as schedule meetings between
parents and teachers so that issues can be addressed. Teachers can end up managing multiple
classes of students, making it hard to identify patterns that would indicate that a student is falling
behind. This application makes it easier for teachers to see these patterns, and provides parents a
real-time view of their child’s learning experience.
Few classroom behavior-tracking apps and parent-teacher meeting schedulers exist
already, and the ones that do can lack both context and convenience. The problems that this
project aims to solve are the inconvenience of entering student behavior data during class time
and the difficulty of comparing different kinds of behaviors across all classes and identifying
meaningful patterns that can be brought to the attention of parents and addressed. It also tackle
the problem of underprivileged families not having access to all the digitized data that
technology-integrated classrooms would be compiling.
By enabling real-time input that tracks frequent behaviors and participation rates, this
product reduces the amount of data that a teacher needs to enter during class time while still
maintaining the detail and integrity of that data. It also tracks different kinds of behavior so that
unique issues and academic performance for students can be addressed or rewarded
appropriately. The application also compiles all relevant data for a student into a meaningful
report that can be printed out and reviewed by parents without digital capabilities.
Each of these features was designed and implemented over an eight week period. During
the first two weeks, the overall design of the user interface as well as the core functions that
allow teachers to add students/classes and update behaviors was implemented. Then the
application was turned over to the client so that the functionality could be tested over the next
two weeks, during which time the project team wrote the functions that allow teachers to
message parents, schedule meetings, organize seating charts, and generate behavior reports.
After this, the project team studied the trends in behavior that the usage of the application was
affecting, then making any necessary changes so that each function is executing efficiently. The
final two weeks were reserved for reviewing feedback and implementing minor changes based
on that feedback, as well as creating the presentation for the Capstone festival.
Teachers will be the ones that benefit the most from this project, as it will improve their
behavior tracking methods as well as make them more efficient. Parents looking to be involved
in their child’s academic progress also stand to gain, as they will have real-time access to their
child’s behavior and potential areas for improvement that they could address through an
improved line of communication with their child’s teachers. Finally, students’ academic lives
will be enhanced, as parents and teachers can provide better support towards identified areas of
improvement and maintaining interest in academic success.
According to the American Psychological Association, students can find success later in
life despite IQ and socioeconomic status if they maintain an interest in school and are a
responsible student (Sliwa 2018). This means that keeping track of student behavior and
participation is vital to their success later in life, and improving the efficiency of tracking
methods allows teachers to make sure that no student is forgotten. By providing these resources
to the people that need them, this project could become a necessary part of the educational
system.
Problem/Issue in Technology
In the average high school, teachers tend to have only 90 minutes for their classes, with
teachers in lower grades having even less time. An ideal school day has the students perfectly
behaved and prepared with all necessary resources to utilize their time efficiently. However,
these ideal days don’t tend to happen, with a high percentage of students being disruptive,
distracted, or unprepared. Even just one student misbehaving can cause a whole class’ learning
experience to suffer.
The question for teachers becomes, “How do they track, manage, and address the
behavior of the students they teach?” There are resources available for behavior tracking, such as
behavior sheets and classroom apps, but when class time is so short the inefficiency of these
resources becomes its own problem. Managing behavior can be done with parental involvement,
but when teachers manage multiple classes and hundreds of students, PTA meetings can be hard
to schedule and crucial trends of behavior can be lost.
Solution to the Problem/Issue
As part of addressing these problems, the programming team has designed each feature of
the application with efficiency and ease of use in mind. The main functions of the application are
quick behavior data entry, detailed student profile information, behavior report generation, and a
parent-teacher meeting scheduler. Additionally, the application will be available for parents so
that they can view the behavior data of their students independently, promoting more parental
involvement in their student’s life.

Project Goals and Objectives
Goals
● Improve efficiency of entering behavior data for teachers
● Identify patterns of behavior for teachers
● Improve academic performance of students
● Improve communication between parents and teachers
● Fully deploy product in one school after successful test run in one class
● Establish secure protection for behavior data and communication channels
Objectives
● Researched behavior data and compile resources around behavior improvement (Week 1)
● Completed full design for application (Week 1)
● Implemented student/class data input (Week 2)
● Implemented behavior tracking (Week 2)
● Implemented student profiles and seating charts (Week 3)
● Implemented analysis of behavior data and behavior report generation (Week 3)
● Implemented meeting scheduling for parents and teachers (Week 4)
● Implemented security protocols and encryption all relevant data (Week 4)
● Reviewed feedback from teacher and parents (Week 5)
● Reviewed academic performance of students (Week 5)
● Finished redesign based on feedback, implement major feedback changes (Week 6)
● Redeployed in classroom, implement minor feedback changes (Week 7)

● Documented effects of improvements and compile into presentation for Capstone festival
(Week 8)
Stakeholders and Community
The stakeholders of this project include the customers, direct users, project team
members, and the client. As stakeholders, they are affected by the outcome of this project. The
education community also stands to gain a tool for managing student behavior through the
collection and analysis of behavior data acquired directly from teachers and parents.
The direct users include the teachers and parents/guardians of K-12 students. In general,
the teachers will utilize the application to update student behavior and parents/guardians will
have access to these updates. The teachers stand to gain a tool for managing student behavior
that is more effective than typical discipline systems (e.g., steps, detentions). The
parents/guardians stand to gain an easier way of keeping track of how their children are behaving
in school. Rather than relying on asking their children or waiting for contact from teachers or
administrators they can access this information through the application.
The customers would include teachers, administrators, and schools/districts. The team
intents to have a fully functional product which teachers, administrators, and/or entire
schools/districts could purchase to be used in their classes. Therefore, these stakeholders stand to
gain a behavior management system for students and stand to lose the money spent on
purchasing the product.
The project team members, Moises Bernal and Nicholas Tippner, stand to gain
experience developing software as well as a successful project to be included in their portfolio.
The project team members also stand to gain or lose a passing grade in the CST 499 course.
The client for this project is Chad Martinez, a mathematics teacher for Wasco High
School in Wasco, California. The client is also a stakeholder who stands to gain a working
application which he can use to manage the students in his classes.
Evidence that the Project is Needed
In a 2012 study released by Scholastic and the Bill & Melinda Gates Foundation, it was
found that classroom behavior has “notably worsened” when surveying teachers who have taught
at the same school for five or more years. Over half of these teachers say that they wish they
could spend less time on addressing behavior issues. Finally, 38% of teachers list the need for
more parent-teacher collaboration as one of the greatest challenges they face within the teaching
profession (Scholastic 2012).
To summarize, teachers are in need of a tool that can deal with the increase in behavior
data, input that data quickly and efficiently, and schedule meetings with parents to discuss the
best way to address issues that their student is facing. The application designed as a part of this
project has all the necessary functions to be the tool that addresses these problems. Its student
database can handle entry and requests of behavior data efficiently, and its user interface will
allow quick entry for both positive and negative behavior actions. Finally, the application’s
scheduler function will track contact information and availability to make PTA meetings happen
more often.
Feasibility Discussion
This feasibility discussion will be taking a deeper look at the results of the environmental
scan of ClassDojo, the popular classroom behavior management application created in 2011
(ClassDojo, 2017), and its effectiveness. ClassDojo tracks and rewards students through a points
system, as well having features to allow parents and teachers to communicate and for teachers to
share images and stories with parents and teachers. Due to its wide usage for the past seven
years, there are many reports featuring feedback from teachers, but surprisingly few that look at
the application’s effects on students.
ClassDojo utilizes a points system to track and display student behaviors for teachers and
students to see. Based on this points system, students can be rewarded or punished based on the
amount of points they get, gaining points for good behaviors like participation and teamwork,
and losing points for missing assignments and being disruptive. Teachers can also utilize a
“stories” system, similar to social media sites, that allow them to share pictures and tell stories
from class that parents and students can see. Finally, reports on each student based on behavior
data can be generated and reviewed by both parents and teachers, showing good behaviors in
green and bad behaviors in red.
Child psychology is a complicated subject, and so the full effects of ClassDojo in
classrooms is hard to measure. However, feedback from teachers and parents using the
application can be reviewed. Teachers have generally reported a good experience with the
application, with one teacher saying in a New York Times review of ClassDojo, “ClassDojo
gave students feedback as a way of encouraging them to develop skills like leadership and
teamwork” (Singer, 2014). However, parents have some concerns about both privacy of student
data and the public nature of behavioral rankings, saying that it results in “public shaming.”
Child development professor Brigitte Vittrup (2015) discusses ClassDojo’s effects, writing
“Color charts and behavior apps simply display the behavior. They don’t provide guidance for
problem solving, nor do they provide motivation for long term behavior change — other than the
fear of public shaming.”
As a result of comparing and contrasting the features that ClassDojo has as well as how
they were laid out, the programming team behind this project made sure to take a new, original
approach as to how their features would be designed. After going through the signature features
that ClassDojo has, it can be determined that the main features of the application are its behavior
tracker, classroom newsfeed, and parent-teacher communication channels. While there are
similarities to the capabilities of ClassMinder, when each feature of ClassDojo is looked at in
detail, there is enough of a difference for all of ClassMinder’s functions to be considered unique
and innovative.
The first feature to compare is the main function of both applications, the behavior
tracker. Each program allows teachers to create a virtual classroom, add students to the
classroom, and input behaviors that are encountered throughout the class. However, ClassMinder
has added ways to improve this process and make it more efficient. ClassDojo doesn’t track
students outside of the classrooms they’re in, so a teacher would be unable to combine data for
the same student that is in two different classes, or look at and sort all students from every class
they teach. ClassMinder keeps students in their own database, so they can easily be added to
multiple classes and have their behavior from all classes viewed by each of their teachers.
Behavior input is easier too, as ClassMinder has a customizable seating chart that allow for
sections of the class to be selected and assigned behaviors.
Parental communication is another key part of both applications. ClassDojo and
ClassMinder both have the the ability for teachers and parents to send messages to each other.
However, ClassDojo’s messaging channel is straightforward and nondescript, functioning as a
simple text messenger between teacher and parent. Their main focus of parental communication
is done through their Class Stories section, which functions similarly to Facebook’s News Feed,
with teachers posting pictures and statuses from the class throughout the day. ClassMinder’s
method of parental communication implements both text messages and scheduling function for
arranging parent-teacher meetings. The application will track parental contact information and
availability and combine it with the teacher’s availability so that meetings can be scheduled
efficiently and without overlap.
Finally, the last function to look at is how behavior data is organized and displayed when
a teacher or parent looks at a student’s profile. ClassDojo’s displays a student behavior as a
donut graph, each positive behavior in green and each negative behavior in red, with the
percentages for each accompanying it. The behavior can also be organized by day of the week,
again showing percentages of positive and negative behavior. ClassMinder’s behavior graphs
will go a little more in depth. Starting off, each behavior can be filtered to show a graph of the
most common behaviors. Also, behavior data can be filtered by teacher, time of day, and class.
This way, the root of student behavior issues can be identified, such as a student not liking a
specific teacher, a student not being a morning person, or whether a student is uninterested in a
particular class.
PART 2:
Functional Decomposition
The database that handles all information passed through the application is divided into
three main sections. The User table tracks identifying information and whether the account was
created by a parent or a teacher, and is associated with the Classroom table, a custom Behavior
table, and the Meeting table. The Classroom table tracks class names and who teaches them, and
tracks what students are on the roll in the Student_Behavior table. Finally the Student table
tracks student information, and uses three other tables to track their classes, behaviors, and
parents.
The ClassMinder application consists of several PHP pages that allow teachers to track
and student, class, and meeting information through the above database. At the homepage,
teachers can choose from tabs including Students, Classes, Resources, and Help. The Students
page selects and adds new students using SQL statements based on the current user’s ID number,
and displays class, behavior, and parental contact information based on the selected student’s ID
number, as well as allowing Parent users to choose a meeting time based on the availability of a
teacher for a selected class. Teacher users will determine their availability by using the Meetings
page. Student behavior is shown using JavaScript to arrange the data gathered from the Behavior
table into printable collections of charts. The Classes page also uses JavaScript to display all
students in a class within an editable seating chart, where teachers can select multiple students to
add behavior data to the Behavior table.
Selection of Design Criterion
When the project was initially designed, the programming team determined that users
would need to be able to create and manage students and classrooms, as well as add behaviors
and parental information to those students, generating behavior reports and scheduling meetings
based on this information. As the project progressed and user feedback was received from the
client, desired features were creating students and meeting availability times in bulk for teachers,
as well as being able to efficiently add behaviors to multiple students while looking at the seating
chart. Now that all user requirements and desired features have been gathered, the project team
can effectively analyze and set goals for the final version of the application.
The initial user was a high school teacher managing a class of math students, but the
ultimate goal is to have the database effectively manage information from multiple schools using
the application simultaneously. This would mean that the servers hosting the application would
need to remain up, and that there would need to be protection for the database itself and a backup
server in the event of catastrophic failure. Costs for maintaining these servers and keeping the
domain name would be covered by grants, donations, and potentially ad revenue if the project
becomes widely used. The project will need to operate within U.S. privacy laws, and potentially
international privacy laws if the project expands further. User-friendliness will always be
prioritized, since efficient behavior tracking is the keystone of the application. The effect on
underprivileged schools will be closely monitored, and if it’s determined to be overall negative,
then the project will be pulled and redesigned.
Final Deliverables
The main deliverable of this project is the main behavioral tracking application itself,
consisting of the ability to track, graph, and analyze behavior in the classroom as well as
communicate with parents about suggestions for improvement. However, the secondary
deliverables consists of surveys designed to continuously track the application as it is used by
different teachers, and surveys for parents and students in order for the application to be
genuinely helpful and avoid it becoming too intrusive on students’ personal life. In addition to
the surveys, there is also a guide for setting up the application in a classroom in an appropriate
and respectful way.
The application consists of three main components; the ability to input and track behavior
of students in the classroom, the ability to analyze and analyze and sort the input behavior data,
and the ability to communicate with parents. Any data sent and received by teachers will
encrypted appropriately and will go through the right security protocols that will keep the data
integrity intact. Keeping the user interface clean and easy to input data into was a major priority
when the application was designed, and any user interfacing with the application will be able to
understand the purpose of each element within the display.

The surveys for teachers includes questions concerning errors encountered, ease of use,
effectiveness in the class, and helpfulness of the behavior improvement suggestions. The purpose
of this survey is to identify areas of the application where the user interface and algorithm design
can be improved, as well as finding the smaller bugs developers may have missed. The surveys
for parents and students include questions concerning their views on privacy, the potential
intrusiveness of the application, and how it affects their academic experience. This survey will
identify data-gathering areas that could be potentially cut back.
Approach/Methodology
In the beginning stages of the design phase, the team looked at research papers on child
psychology in the classroom in order to prioritize behaviors that should be being tracked.
Research papers on improving child behavior also were compiled, so that helpful suggestions to
address bad behavior and maintain good behavior were generated. Additionally, the team looked
at reviews of other behavior tracking applications to see which features should be included and
which ones should be avoided. Once all features of the application had been researched
thoroughly, the team moved from the design phase to the implementation phase.
The features were converted to stories which could be tracked through an agile project
management system (i.e., Pivotal Tracker). The stories included the software implementation
descriptions and requirements. These stories were carried out by utilizing either backend or
frontend solutions. For the backend implementation the project team used PHP, Apache, and
MySQL with Amazon AWS. The frontend implementation was accomplished using HTML,
CSS, and JavaScript. A version control system (i.e., Git) was used for the team members to work
collaboratively.
The team received weekly feedback from our client who used the developed application.
This included feedback on added features and suggestions of features that could be added in the
future. After receiving feedback, the team determined whether more stories should be added to
the project management system, such as adding Excel sheet importing for creating students. Each
week consisted of adding/amending features to the project by going through development and
testing phases.
In order for the client to use the application in the classroom, the team asked the client to
add students to a classroom. The client was also be able to add behavior information about
students regularly. Once the team had deployed a version of the application, the client asked
parents if they would like to use the application. When parents used the application, the team
distributed surveys so that feedback was able to be gathered.
Legal Consideration
Recording of student behavior by a teacher without parental permission is fully legal, but
the application will still emphasize communicating what the teacher will be recording, how they
will be recording it, and what types of actions they would take to address problems. The
application will also inform the teachers downloading it that they need to get permissions from
the school administrators to use it and that they should inform their fellow teachers so that there
are not miscommunications about how student behavior is monitored.
Ethical Consideration
In order to promote effective improvement in classroom behavior of students, a proper
balance of documentation and intervention was be struck. However, if this balance was not
struck, then students might be unduly punished or otherwise negatively affected by the program
as a result. Students could also be discouraged if their classmates are repeatedly rewarded for
positive behavior that they might not be able to replicate, either because they are intimidated by
public speaking or they feel they are not as knowledgeable as their classmates.
Underprivileged groups such as lower-class families and children in abusive homes face
potential negative impact compared to their peers. As this is a digital application, lower class
families could potentially fall behind without the same access to the applications resources that
other families would take for granted. This would only compound the education gap between
wealthy and poor families.
During the deployment phase, the programming team closely monitored feedback from
the teacher and addressed any apprehension and negative reaction from students unused to
having their behavior monitored closely. A new technology in the classroom always runs the risk
of causing disruption among students. In the future, the team will need to maintain the integrity
of student behavior data and maintain continuous security updates to prevent any privacy
infringement. If the product is deployed in other schools, then the team will need to make sure
that the product is deployed effectively so that disadvantaged schools are not left behind when it
comes to providing product maintenance and support.
As part of the mitigation plan for potential negative effects, the programming team has
identified solutions that will address the ethical problems aforementioned. Parents without access
to the necessary technology to use the application will be brought printed out behavior reports
generated through the application and designed to have the same pertinent information as other
families. Teachers also control whether a parent can be linked to a student account, so that a
dummy student profile can be created and linked for parents the teacher is wary of giving
detailed behavior information to.
PART 3:
Timeline/Budget
April
Sun Mon Tue Wed Thu Fri Sat
22 23 24 25 26 27 28
Week 1 Share Design Settle on a
Begins results and client-side design for
Begin choose the version of the
Classroom resources the client-side
Behavior to be used application version of
Research in the based on the
Phase application results of application
research
phase
29 30
Design Settle on a
server-side design for the
version of server-side
the version
application
May
1 2 3 4 5
Week 2 Convert all Implement Implement
Begins design ideas storage of storage of
Create into stories student student
GitHub for Pivotal information information
project and Tracker
database
server
6 7 8 9 10 11 12
Implement Implement Review Week 3 Implement Implement Implement
behavior behavior code as Begins student student behavior
tracking for tracking for needed Test all seating charts seating analysis and
students students written charts behavior
functions resource
page
13 14 15 16 17 18 19
Implement Receive Implement Week 4 Improve Implement Establish
behavior daily conversion Begins behavior data sharing security
graphing feedback of data into Review and charts between protocols for
from client printable begin testing parents and sending of
reports application teachers data
with client
20 21 22 23 24 25 26
Implement Test Revise Week 5 Implement Establish Review
encryption security code as Begins meeting what student
for all data protocol needed Review scheduling changes to behavior
and feedback for between UI should data
encryption the week parents and be made
teacher based on
feedback
27 28 29 30 31
Analyze Establish Review all Week 6 Implement
trends and what potential Begins new changes
improveme changes in changes Begin
nt s in the the with the implementin
data algorithm client g new
should be changes
made
June
1 2
Receive Hold
daily usability
feedback testing with
from client client
3 4 5 6 7 8 9
Review Implement Review all Week 7 Receive Receive Patch any
potential changes changes Begins daily daily immediate
changes with client Begin feedback feedback bugs
with client second from client from client encountered
testing by client
phase
10 11 12 13 14 15 16
Review Gather Create Week 8 Update Practice Capstone
changes application presentatio Begins presentatio presentation Festival
with client information n, finish Write n based on make final
and its Capstone speech professor changes to
effects report feedback product
In this project, there were a few resources required during the development and testing
phase. Initially, the product was be tested on an Amazon Web Services EC2 server, and can be
moved if server needs change. Visual Studio Code will be used to write both server-side and
client-side code, while temporary Apache servers will be opened to test SQL commands to the
database. The database will be designed and implemented using MySQL Workbench. Beyond
software resources and server capabilities, this project will require varied browser-capable
devices for testing purposes.
Each phase that is part of creating the application had clear and achievable milestones,
and there were only a few small changes that were made to the schedule. In the design phase, the
first milestone was finishing the design for the user interface, while the second milestone was
finishing the design for the server-side infrastructure and database. Both of these milestones were
completed on time. Then, in the development phase, the milestones were completing behavioral
tracking capabilities, completing teacher-parent communication capabilities, and successfully
getting the finished product interfacing with the database. Due to the importance of getting a
fully developed version of the application to the client early, the schedule was changed to have
the product finished by the end of the fifth week, and more programming time was scheduled to
develop the behavior reports for Weeks 3 and 4. Additionally, the meeting scheduler was
prioritized over creating a parent-teacher messenger, as it needed resources that were outside of
the scope of the project. Finally, a successful test run was completed for the final milestone.
The initial budget for the project was a few hundred dollars for various server costs and
obtaining resources necessary to development, with the cost split between the two members of
the team. However, as the first year of server hosting was offered free through Amazon, and all
coding resources were free thanks to the team’s status as students of CSU Monterey Bay, the
only costs to finish and showcase the final version of application was the $7 needed to register
the domain classminder.net.
Usability Testing/Evaluation
During the testing phase, the application was deployed in a high school setting and run by
the client, Chad Martinez, a high school mathematics teacher. In each week-long testing period,
the client used the application to monitor classroom behavior per the instructions of the usability
testing plan (see Appendix A), fill out a feedback form that details his user experience, and
gather feedback from students and parents that explain how the application affected them and
whether it improved or detracted from the academic lives of the students (see Appendix B).
Usability testing had the client test the three main functions of the application; behavior
tracking, behavior analysis, and parent-teacher meeting scheduling. Specific functions to be
evaluated will be the ability to enter varying behavior data, assigning students into a seating
chart, compiling behavior data into printable reports, and creating availability time slots that
parents can choose in order to create a meeting. The goals of the first round of testing was
critical error correction and improving ease of use, while the second round of testing focused on
fixing navigation and presentation errors.
All user testing took place in a mathematics classroom at Wasco High School, in a
classroom size of about 20-30 students. The client, mathematics teacher Chad Martinez, opened
the application with his browser, and interacted with it as the need arises during class time. When
the class was over, he reviewed and compiled all data generated then decided what information
he will need to pass on to the parents. When each round of the testing period is over, all relevant
information that could help to improve the product will be collected, such as demographic
information, satisfaction assessment, and suggestions for improvement.
In the first round of testing, only behavior data entry and the class seating chart
management were available, with the Project Lead explaining each of the application’s functions
and the goals of the testing before the round begins. In the second round of testing, behavior
graphing and analysis were enabled, along with the meeting scheduler. Improvements based on
feedback from the client and other stakeholders were implemented during the second phase as
well.
The roles established as part of this project will include:
Facilitator
• Reviews instructions and goals with the client
• Defines usability and purpose of usability testing to client
• Supports the client to solve any immediate problems encountered
Developer
• Uses Agile development methods to implement immediate feedback changes
• Fixes critical application bugs encountered during the testing phase
• Monitors client’s usage of the application
User
• Reviews instructions and goals with the facilitator

• Provides thorough documentation on scenarios specified
• Writes and gathers feedback from other stakeholders
During the testing phase, the client looked to complete thorough documentation when the
following scenarios occur; corrective action is taken over a student’s behavior, a parent is
notified about trends in a student’s behavior, incentives are given to improve student behavior.
The first testing round was considered successful when all critical errors were resolved, all
database entries were registered successfully, and meetings were successfully registered. The
second testing round was considered successful when the client and stakeholders were satisfied
with usability, and detailed behavior reports were generated and reviewed.
Final Implementation
The core of this project centers around the design of its database. Teachers need to input
and manage students, parents, classes, meeting schedules, and how each one is associated with
the other. The User table tracks user account information, such as their name, e-mail, password,
and whether they are a teacher or a parent. The Class table keeps track of the class name, where
the user has set the front of it to be, and what school it belongs to. The Student table keeps track
of student names and whether they’re currently active in the school or not, utilizes the
Student_Class table to associate students with the classes they are enrolled in. The Behavior
table holds the default behaviors, their names and descriptions, and whether they’re positive or
not. Custom behaviors are saved by associated a userID with them, and behaviors are associated
with students through the Student_Behavior table, which also tracks what class they were entered
for and what time they were entered. Finally the Meeting_Slot and Meeting tables manage
meetings for parents and teachers, with the former keeping track of teacher availability time,
designated meeting locations, and whether the meeting slot has been requested by a parent, and
the latter keeping track of the reason the parent scheduled a meeting, which teacher they
scheduled a meeting with, and when they scheduled the meeting. The majority of PHP files that
comprise this project make use of this database to display and update all stored information on
the website.
The first step that a user will take when using this application is creating an account.
When a user initially fills out the needed information, the data is passed through PHP pages
generated using a factory design pattern. The user’s permissions are determined when they create
the account and choose whether they would like to create a parent or a teacher account. The user
type is passed through the factory pattern, and then a user is created of the relevant type. Once a
user has been created and stored into the database, the data can be retrieved by either the user ID
or the email that the user used create the account, and stored into its own User class which is held
by the current session. Currently, the user can choose whether to create a parent account or
teacher account at the time of account creation. The code for the User factory is shown below:
class UserFactory
{
public function getUserType($role)
{
$role_type = 'User_' . ucwords($role);
// Generate UserType object based on given role
if($role_type=="User_Teacher")
return new User_Teacher();
else if($role_type=="User_Parent")
return new User_Parent();
return null;
}
}
After the user is created, they can go to the login page, where they enter their chosen
email and password. Using User classes functions to save and compare this information to the
email and password of a related account stored within the database, the login page is able to
verify whether the user entering the email and password has an account that can be logged into
using the email provided, and whether the user who created the account matches the one
currently attempting to log in by comparing the password entered with the SHA1 encrypted
password stored in the database. When all information is verified to be correct, all relevant user
information is retrieved from the database and saved into a SESSION User class. This data is
also saved into session-related variables, which are referenced in all pages that interact with the
user. The login process has a Model-View-Controller design, with the User class being the
model, and the View handling the PHP page that user is presented with while the Controller
holds the code that handles the information the user passes to the server.
Once the Controller verifies whether the user is valid and whether the user is a parent or
teacher, the user can then access the home page. Teachers can select students, classes, meeting,
resources, and help, as well as the settings page. Parents can only access students, meetings,
resources, help, and settings
When accessed by a teacher, the student page will show a list of students that are
associated with that teacher in the Student_Class table. When accessed by a parent, the student
page will show a list of students that are associated with that parent in the Student_Parent table.
Adding a student to a teacher’s list is handled by the same code that handles adding a student to a
specific class. The classes page will show a list of all classes that that user has created, and each
one will link to a unique classroom page that displays a seating chart and allows teachers to add
students, remove students, enter behavior data, edit the seating chart, and add students through an
uploaded CSV file.
Both the students page and the classroom page can have students added to them by users
with the teacher role, with the data for either being passed through the same PHP page. If the
name of a student is passed to the page for adding students, done through adding a student from
the teacher’s student list, then the student is added to the Student table in the database and
assigned the default “Unassigned Class.” An instance of this class is created if the teacher is
adding a student for the first time, otherwise the SQL will pass its ID and the student’s ID to the
Student_Class table. If a class ID is passed along with a student name, then that class ID and the
student ID are added as a pair to the Student_Class table. The code for handling adding students
is shown below:
if((isset($_POST["fName"]) && isset($_POST["lName"])) ||

isset($_POST['studentClass']))
{
if(empty($msgs))
{
$nConn = new Connection();
if(!isset($_POST['studentClass']))
{
$userID = $_SESSION['userID'];
$str = "INSERT INTO CLASSROOM (title, userID,
schoolID)
SELECT * FROM (SELECT 'Unassigned Class', $userID, 0)
AS tmp
WHERE NOT EXISTS (
SELECT CLASSROOM.title FROM CLASSROOM WHERE
CLASSROOM.title = 'Unassigned Class' AND userID=$userID
) LIMIT 1;";
$nConn->getQuery($str);
$arr = array('schoolID'=>'0', 'userID'=>$userID,
'title'=>'Unassigned Class');
$classroomSelected =
$nConn->getRecordByArr('CLASSROOM', $arr);
$classroomID = $classroomSelected['classroomID'];
...
$student = new Student($_POST["fName"],
$_POST["lName"], $sID);
$studentCreated = $student->save()!=0;
$studentID = $student->getStudentID();
}
else
{
$json = $_POST['studentClass'];
$obj = json_decode($json);
$studentID = $obj->{'studentID'};
$classroomID = $obj->{'classroomID'};
$title = $obj->{'title'};
$gotoClassroom = true;
}
if(!is_null($studentCreated) ||
isset($_POST['studentClass']))
{
$str = "INSERT INTO STUDENT_CLASS (studentID,

classroomID)
VALUES ($studentID, $classroomID)";
$nConn->getQuery($str);
$success = true;
}
}
}
Teachers also have the option to add an entire class’s roster by using the provided CSV
file to upload a list of students. This is done by separating values in the uploaded file by commas,
and looping through the file row by row and using the PHP for adding students to handle
multiple students being input at once.
The seating chart keeps track of changes to student positions by updating their saved x-y
coordinates within the database. JavaScript is used to handle users dragging and dropping
students from the unassigned row to their position in an initially empty grid. When they do so,
the coordinates for that student ID are set, and when the user saves their edits the page passes all
coordinates paired with student IDs to the database for an update. Student coordinates are
initially set to (0,0) if they haven’t been assigned a seat.
Once the class is set up, the teacher will be able to start registering behaviors for students.
This is done by creating a page that holds a smaller version of the seating chart, with labels
encompassing each student square so that tapping on them will select them as part of a checklist.
Another checklist is shown below the seating chart selection area, listing all the default positive
and negative behaviors contained within the database, as well as giving checkboxes associated
with text boxes so that teachers can input custom behaviors. All selected behaviors become
associated with all selected students, using student ID and behavior ID pairs entered into the
Student_Behavior table. Every custom behavior created is saved into the Behavior table and
associated with the current user’s ID.
Once a student has behaviors entered for them, teachers can take a meaningful look at
their behaviors through the behavior report on the student’s profile page. This page is accessed
either directly from the teacher’s student list or from the classroom’s seating chart, and if it was
accessed from a classroom, then the behavior report for that classroom only will be previewed.
The student profile page also includes what classes that the student is associated with through the
Student_Class page, their four most recent behaviors obtained by sorting the Student_Behavior
table by time and limiting to four, and parental contact information gotten from the
Student_Parent table. Behavior reports can be accessed by specific classes or the teacher can
choose to get a report that combines all classes. All behaviors associated with a student get
compiled and displayed using Ajax and JQuery. The code retrieves behavior counts, dates, and
types, and puts them into several meaningful graphs. The code for creating these graphs is shown
below:
function createPieChartNoClass(constCHART,studentID, startDate, endDate)

{
$.ajax({
url:"./queryWeeks.php",
data: {
'studentID': studentID,
'startDate': startDate,
'endDate': endDate
},
method:"POST",
success: function(data){
let allData = jQuery.parseJSON(data);
//console.log(allData);
let totalDays = 0;
let totalPos = 0;
let totalNeg = 0;
let totalBoth = 0;
let totalNone = 0;
for(let i in allData)
{
totalDays=i;
if(allData[i]['posBehaviors']>0)
{
if(allData[i]['negBehaviors'] > 0)
totalBoth++;
else
totalPos++;
}
else
{
if(allData[i]['negBehaviors'] > 0)
totalNeg++;
else
totalNone++;
}
}
...
Another feature that the application has beyond behavior reports is the ability for teachers
to generate availability time slots that parent accounts can choose from to schedule a meeting.
Adding meetings can be done through the Add Meetings page accessible by the teacher, where
the teacher inputs the time and date of the meeting, how long the timeframe of availability is,
whether there are multiple meeting slots within that timeframe (e.g. a teacher wants
parent-teacher meetings to be fifteen minutes and they’re available for half an hour after school),
and whether they’re available at the same time every day (M-F) or once a week. In order to
generate a large amount of meeting slots quickly, nested while loops are used to track the time,
day, and current week. The code for accomplishing this is shown below:
if(isset($_POST["meetingTime"]) && isset($_POST["meetingLength"])

&& isset($_POST["meetingLocation"]) &&

isset($_POST["meetingDivision"]))
{
$teacherID = $_SESSION['userID'];
$meetingTime = $_POST["meetingTime"];
$meetingLength = $_POST["meetingLength"];
$meetingLocation = $_POST["meetingLocation"];
$meetingDivision = $_POST["meetingDivision"];
$formatDate = new DateTime($meetingTime);
$meetingIntervals = floor($meetingLength /
$meetingDivision);
if ($meetingIntervals == 0)
{
echo'<script>';
echo'function myFunction() {
alert("Number of slots greater than available
timeframe.");
}
myFunction();
</script>';
$error = true;
}
$meetingSingleInterval = new
DateInterval('PT'.$meetingIntervals.'M');
if(isset($_POST["meetingCount"]) &&
$_POST["meetingCount"]!=1)
{
$weeks = $_POST["meetingWeeks"];
}
if(isset($_POST["meetingCount"]) &&
$_POST["meetingCount"]==2)
{
$days = 6;
}
while ($weekCounter <= $weeks)
{
$dayCounter = 0;
while ($dayCounter <= $days)

{
if (!$error)
{
if (($formatDate->format('l')=='Saturday' ||
$formatDate->format('l')=='Sunday') && $_POST["meetingCount"]==2)
{
$dayCounter++;
$dayInterval = new
DateInterval('P'.$dayCounter.'D');
$formatDate =
$formatDate->add($dayInterval);
$meetingTime = $formatDate->format('Y-m-d
H:i:s');
continue;
}
for ($i = 0; $i < $meetingDivision; $i++)
{
$nQuery = "INSERT INTO MEETING_SLOT
(meetingTime, minutes, teacherID, location) VALUES (\'$meetingTime\',
$meetingLength, $teacherID, \'$meetingLocation\')";
$arr = array('meetingTime'=>$meetingTime,
'minutes'=>$meetingIntervals, 'teacherID'=>$teacherID,
'location'=>$meetingLocation);
$meetingSlotID =
$nConn->save("MEETING_SLOT", $arr);
$formatDate =
$formatDate->add($meetingSingleInterval);
H:i:s');
}
}
$dayCounter++;
$dayInterval = new
DateInterval('P'.$dayCounter.'D');
$formatDate = $formatDate->add($dayInterval);
H:i:s');
}
$weekCounter++;
$weekIntervalDays = $weekCounter * 7;
$weeklyInterval = new
DateInterval('P'.$weekIntervalDays.'D');
$formatDate = $formatDate->add($weeklyInterval);
$meetingTime = $formatDate->format('Y-m-d H:i:s');
}
$success = true;
}
If a parent wants to see these graphs and meeting slots, they’ll need to be linked to a
student through the Student_Parent table. This is done by having a teacher enter the email
address of a parent account into the Link Parent page accessed from the student’s profile. The
user ID associated with that email is then paired with the selected student ID on the
Student_Parent table. If the email entered doesn’t have an associated account with the
application, then an email is setting out using the application’s SMTP server to that email
requesting that they create an account. The email will contain a register link containing the
student’s ID so that when the parent registers an account, they will be immediately linked with
that student.
The project team encountered a few obstacles beyond the standard scheduling delays.
When the database had first been created, there were a few key pieces of information that weren't
included in the design. Once the relevant portion of the development process had been reached, it
was realized that the application needed to save the positions of students in the seating charts,
custom behaviors that users create, and associate both parents and teachers with meetings. These
values hadn’t originally been included in the database. Additionally, in order to be able to send
out emails to parents without accounts, the team needed to establish an SMTP server that could
pass messages to people’s emails. All of these issues were addressed by the final release of the
product.
When the project begins to roll out to more users, the development team plans to invest
more into server hosting, as well as set up support so that teachers having trouble creating and
managing their account have a resource to turn to. Once school-wide implementation is ready for
the application, the team plans on working directly with school administrators to set up accounts
and student rosters for all teachers in the school. As the team receives feedback from more users,
they will continually release patches so that the application can keep being improved.
Conclusion
Teachers that keep track of behavior in the classroom are currently overwhelmed, as the
current resources they have are either inefficient or unintuitive. Parents looking to be involved in
the academic experience of their child are rarely updated about their child’s behavior, and
meetings with busy teachers can be few and far between. ClassMinder looks to solve these
problems by offering teachers a way to easily manage large classes of students and quickly enter
behavior data during class time, as well as offering parents a real-time, comprehensive look at
the way their child’s behaving and giving them the ability to schedule short meetings with
teachers so that issues can be addressed.

When the project was initially being designed, the team looked at research papers on
child psychology and improving child behavior. Additionally, the team looked at reviews of
other behavior tracking applications to see which features should be included and which ones
should be avoided. During the development process, the project team used PHP, Apache, and
MySQL with Amazon AWS for all server-side needs. The client-side input and user interface
were handled using HTML, CSS, and JavaScript. GitHub was used for the team members to
work collaboratively.
Various designs were utilized in the making of this project. Factory design was used to
easily generate users with varying roles such as parent and teacher, as well as leaving the
potential to create new types of roles, such as principal. Model-View-Controller design was used
to handle a user logging in and saving all of their data to the current session so that all pages
dependant on knowing the user they’re working with would have the necessary data.
In the future, we plan to further improve communications between parents and teachers
by making improvements to scheduling of parent-teacher meetings and adding messaging
between teachers and parents. We also plan on implementing school-wide integration so that a
teacher managing a classroom of students can share information with other teachers of that same
school. Finally, we would like to improve our mobile design, so that teachers can manage their
class outside of the classroom.
As a team, we learned a lot about what it takes to develop a web-based application.
Time-management is critical for a project of this scope, and setting small, personal deadlines
helped us to manage that. We also communicated frequently, and we weren't afraid to come to
each other if we got stuck. Acknowledging that this project was a team effort helped us get
through every obstacle we encountered. Overall, we were satisfied with what we created, and
look forward to seeing what impact it has.

References
About us. (2015, June 15). Retrieved April 8, 2018, from https://www.classdojo.com/about/
LiveSchool - Track, Reward, and Improve Behavior. (2018). Retrieved April 8, 2018, from
https://www.whyliveschool.com/
Scholastic. (2012). Classroom Behavior Problems Increasing, Teachers Say. Retrieved May 12,
2018, from
https://www.scholastic.com/teachers/articles/teaching-content/classroom-behavior-proble
ms-increasing-teachers-say/
Singer, N. (2014, November 16). Privacy Concerns for ClassDojo and Other Tracking Apps for
Schoolchildren. Retrieved April 8, 2018, from
https://www.nytimes.com/2014/11/17/technology/privacy-concerns-for-classdojo-and-oth
er-tracking-apps-for-schoolchildren.html
Sliwa, J. (2016, February 26). Behavior in high school predicts income and occupational success
later in life. Retrieved April 8, 2018, from
https://www.eurekalert.org/pub_releases/2018-02/apa-bih022218.php
Vittrup, D. B. (2016, October 13). Class DoJo App Is Already Past Its Expiration Date.
Retrieved April 8, 2018, from
https://www.huffingtonpost.com/dr-brigitte-vittrup/class-dojo-app-is-already_b_8287582
.html
Appendix
Appendix A
Usability Evaluation Test Plan
Authors: Nicholas Tippner and Moises Bernal
Contact Details: Nicholas: ntippner@csumb.edu, Moises: mobernal@csumb.edu
Final Date For Feedback: June 12, 2018
Product: Classroom Behavior Tracker, a web application that organizes student behavior data
and converts it into printable reports.
Test Objectives: This test will identify key runtime errors, common usability problems, and
general opinions surrounding the application.
Participants: Chad Martinez, a high school mathematics teacher, applying the product in his
classroom.
Equipment: A Windows Surface Pro tablet running Google Chrome.
Test Tasks: Go through the application’s menus, determine bottlenecks for student behavior data
entry during class time, generate multiple reports from behavior data, and schedule meeting
times to discuss student behavior.
Roles: Moises Bernal (Facilitator), Nicholas Tippner (Developer), Chad Martinez (User)
Location/Dates: Wasco High School, Wasco, California. First round of testing: May 16 to May
22. Monitored User Evaluation: June 2. Second round of testing: June 6 to June 12.
Schedule: On the first day of the week, the developer will explain to the client what changes
were made since the client was last updated on the status of the product, as well as what
functionality the product currently has. The facilitator will cover what responsibilities the user
has, how to use the current version of the product, and how appropriately give feedback. During
the next two days, the user will use the application to track student behavior, generate reports,
and schedule meetings with parents, giving daily updates to the facilitator about their experience.
Over the weekend, the developer will implement any necessary changes to fix errors encountered
by the user, as well as minor changes that the user suggests to improve functionality. The process
is repeated for the next two days, and at the end of the week, the user fills out their own feedback
survey and gathers feedback from students and parents about their experience.
Appendix B
Feedback Surveys
Teacher Feedback Survey
1. How easy was it to input behavior data into the application?
2. Did using the application ever become distracting during class time?
3. Was the interface intuitive and easy to use?
4. How fast were you able to enter simple behavior data?
5. How fast were you able to enter comprehensive behavior data?
6. Did you encounter any errors during your use of the application? Please describe thoroughly.
7. If errors were encountered, did you understand what went wrong?
8. Were you able to easily recover from input mistakes?
9. Were the behavior improvement resources satisfactory?
10. Did you feel that you had enough resources for help with the application?
11. Do you think this application will help to improve student behavior?
12. Do you think the behavior reports will help parents understand their student’s behavior?
13. How was your overall experience with the application?
14. Are there any functions that you would like to see added?
15. Are there any design changes that you would like to see added?
Parent/Student Feedback Questions
1. Did the application make it easier to schedule meetings with the teacher?
2. Did you feel that the reports generated by the application were thorough enough?
3. What questions would you like answered in the behavior reports?
4. Was usage of the application noticeable during class time?
5. How did the application affect your overall academic experience?
Appendix C
Project Team Roles

Moises Bernal acted as the Project Lead, organizing project deadlines and workflow, and
assigning tasks as needed to make sure overall productivity is maximized. He will be the main
point of coordination with the client, Chad Martinez, and will communicate any requests and
ideas to the rest of the team. When the development phase is complete, he will present the
application to the client, and provide any necessary education towards using it. He will also
gather all feedback during the testing phase.
Nicholas Tippner will act as the Product Owner, representing the stakeholders and
making sure that their feedback is heard and acted upon during the development and testing
phases. He will be the main point of contact between the development team and the professors,
communicating project updates and problems as needed. When the development phase is
complete, he will produce feedback surveys. Then, when the first round of testing is complete, he
will update the surveys based on what successes and failures were encountered.
Both members of the development team will be working on the design and development
phase of the application. Moises and Nicholas will each gather student behavior research
resources, and then collaborate to determine what will be relevant towards the overall design of
the project. Nicholas will initialize the design phase, and identify core methods to be
implemented. Independent and pair programming will be utilized when programming the core
parts of the application. Moises will take point on database design, management, and
implementation. Nicholas will focus on the user interface and client-side scripts. The developers
will work together when designing and implementing the server-side code, as well as designing
the security protocols that will keep the integrity of all data passed through the application
secure.

Capstone Report Final

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Capstone Report Final

Uploaded by

Copyright:

Available Formats

Running Head: CLASSMINDER CAPSTONE REPORT 1

Capstone Report: ClassMinder

June 12, 2018

Executive Summary……………………………………………………………………………. ...3

real-time view of their child’s learning experience.

Few classroom behavior-tracking apps and parent-teacher meeting schedulers exist

technology-integrated classrooms would be compiling.

improvement and maintaining interest in academic success.

to schedule and crucial trends of behavior can be lost.

Solution to the Problem/Issue

involvement in their student’s life.

Project Goals and Objectives

● Improve efficiency of entering behavior data for teachers

● Identify patterns of behavior for teachers

● Improve academic performance of students

● Improve communication between parents and teachers

● Establish secure protection for behavior data and communication channels

● Completed full design for application (Week 1)

● Implemented student/class data input (Week 2)

● Implemented behavior tracking (Week 2)

● Implemented student profiles and seating charts (Week 3)

● Implemented analysis of behavior data and behavior report generation (Week 3)

● Implemented meeting scheduling for parents and teachers (Week 4)

● Implemented security protocols and encryption all relevant data (Week 4)

● Reviewed feedback from teacher and parents (Week 5)

● Reviewed academic performance of students (Week 5)

● Finished redesign based on feedback, implement major feedback changes (Week 6)

● Redeployed in classroom, implement minor feedback changes (Week 7)

Stakeholders and Community

administrators they can access this information through the application.

purchasing the product.

experience developing software as well as a successful project to be included in their portfolio.

application which he can use to manage the students in his classes.

Evidence that the Project is Needed

profession (Scholastic 2012).

the application’s effects on students.

green and bad behaviors in red.

Child psychology is a complicated subject, and so the full effects of ClassDojo in

fear of public shaming.”

similarities to the capabilities of ClassMinder, when each feature of ClassDojo is looked at in

sections of the class to be selected and assigned behaviors.

Parental communication is another key part of both applications. ClassDojo and

However, ClassDojo’s messaging channel is straightforward and nondescript, functioning as a

efficiently and without overlap.

a teacher or parent looks at a student’s profile. ClassDojo’s displays a student behavior as a

add behavior data to the Behavior table.

Selection of Design Criterion

then the project will be pulled and redesigned.

deliverables consists of surveys designed to continuously track the application as it is used by

and respectful way.

understand the purpose of each element within the display.

identify data-gathering areas that could be potentially cut back.

distributed surveys so that feedback was able to be gathered.

are not miscommunications about how student behavior is monitored.

In order to promote effective improvement in classroom behavior of students, a proper

wealthy and poor families.

comes to providing product maintenance and support.

detailed behavior information to.

devices for testing purposes.

tracking capabilities, completing teacher-parent communication capabilities, and successfully

the domain ​classminder.net​.

tracking, behavior analysis, and parent-teacher meeting scheduling. Specific functions to be

fixing navigation and presentation errors.

the domain classminder.net.

Authors: Nicholas Tippner and Moises Bernal

Contact Details: Nicholas: ntippner@csumb.edu, Moises: mobernal@csumb.edu

Final Date For Feedback: June 12, 2018

Equipment: A Windows Surface Pro tablet running Google Chrome.