1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
|
\input{header.inc}
\title{Criterion A: Planning}
\begin{document}
\maketitle
\section{The scenario}
My school offers co-curricular activities (CCAs) to students after academic
periods from Monday to Thursday. Most of those activities are relatively
limited in space, and my campus has approximately 586 students across 4 year
groups.
Before I joined the school, the CCA department has already been using
\href{https://www.schoolsbuddy.com}{SchoolsBuddy} as a CCA selection interface
for students. However, SchoolsBuddy has the following problems when used at the
scale and to the requirements of our school:
\begin{itemize}
\item When too many students attempt to choose one course at a time,
most of their attempts would be confirmed and recorded in the
database, and the CCA department staff must notice them
after-the-fact that their attempt at choosing a course was
unsuccessful. At that point, there would be much fewer other
CCAs with available places too, leaving the student with
insufficient choices---after they have been told by the system
that their place has already been confirmed.
\item The only way to sign in to SchoolsBuddy, at least for our school's
configuration, is to log on to PowerSchool and click the
SchoolsBuddy Single Sign-on link. This generally works well,
except for the fact that PowerSchool only allows approximately
300 simultaneous sessions, which means that there would be
approximately 200 students unable to choose CCAs on
SchoolsBuddy.
\item Even after logging in, the SchoolsBuddy web page is extremely
bloated. It takes 16.5 MiB to get completely load the
SchoolsBuddy home page, and an additional 8 MiB per additional
page. This takes about 8 seconds on a relatively good connection
without congestion. But when CCA selection starts and everyone
is trying to use student WiFi to log on at the same time,
loading each page could take well more than a minute.
\item Some parts of the interface is unintuitive to students. We have
6 CCA slots: MW1, MW2, MW3, TT1, TT2, and TT3, which basically
mean ``CCA Period $n$''.
\item The selection system does not enforce CCA hours requirements, and
the CCA office's staff must manually verify that students have
completed CCA choices to the year group's requirements, by
literally printing out the spreadsheet to paper and reading
through them.
\item The school has to pay SchoolsBuddy an expensive subscription fee.
\end{itemize}
I am developing this project to replace this legacy system and to improve the
user experience for both the CCA department and individual students.
\section{Rationale for the proposed solution}
I have consulted with the school's IT department and confirmed that, with the
approval of appropriate faculty such as the Head of Co-curricular Activities,
the IT can provision a virtual machine on the school's LAN, running a suitable
server operating system such as Alpine Linux or Debian, to run the solution
that I develop. I am also capable of running the solution on my own hardware in
my dorm if necessary for beta and acceptance testing.
I am relatively experienced in developing low-latency network applications such
as IRC software, and I am comfortable reading specifications of network
protocols on various layers of the OSI model. I am somewhat familiar with
developing web applications in the context of our school's environment, and I
have previously developed a library for web services written in
\href{https://go.dev}{Go} to interface with our school's Microsoft Entra ID
system for authentication (previously known as Azure Active Directory).
The program does not need input data during the development process. During
production, all data is automatically retreived from Microsoft Entra ID and the
Microsoft Graph API via delegated access once a student has logged in via OAuth
2.0; in practice, this data includes the year group (grade level), name,
student number, and email address, all of which are publicly available to any
student via the Microsoft Entra ID portal.
There are no special security considerations other than various standard ones
present when working with web applications. Care must be taken not to leak
client secrets used in the OAuth 2.0 authorization code flow, although leakage
thereof is considered inconsequential as an authorization code would be
required anyway. Cookies must be protected against cross-origin request forgery
and should have \texttt{httponly} and \texttt{secure} flags. It should be made
impossible for a student to spoof another student's course choices, provided
that the victim's school login credentials haven't been already leaked.
\section{Success criteria}
The product shall present to students and administrators an accessible and
easy-to-use web interface for choosing and managing CCAs. It shall address each
of the issues of SchoolsBuddy as presented above.
\begin{itemize}
\item When too many students attempt to choose one course at a time,
their attempts are sequentially processed, and those that
exceed the CCA's member limit are properly rejected.
\item It should be possible to log in via Microsoft Entra ID.
\item The web page must be lightweight. The login page shall be
preferrably no more than 15 KiB. The course selection page
shall be preferrably no more than 50 KiB.
If a compressing content encoding such as \texttt{gzip} or
\texttt{deflate} is used, the values above refer to the size of
resources after decompression. If minification is used, the
values above refer to the size of resources after minification.
The experience should be fast and it should not take excessive
resources on the host server.
\item The course selection categories shall be relatively intuitive.
Students may choose from a table of dropdown choices, where
there is one dropdown per CCA slot; or they may choose from a
set of tables, where one table represents all CCAs in one
CCA slot.
\item The selection system must enforce CCA hours requirements.
\item The selection system must be able to take a CSV of CCAs with
fields such as period, location, teacher, and member cap. It
must then be able to populate its own CCAs table that it
presents to the students with information in the CSV.
\item The selection system must be able to export student choices as a
CSV containing the following fields:
\begin{itemize}
\item Student name
\item Numeric student ID
\item Student year group (grade level)
\item CCA name
\item CCA period
\end{itemize}
These may then be used to trivially import choices to
PowerSchool. It would be best if the PowerSchool API could be
directly accessed to insert the courses, but the API is not
publicly documented.
\end{itemize}
\end{document}
|
