There was a time when all enlistment processes were conducted in person. Much like today’s manual registration, students back then would go to school and line up for hours on end just to pick their classes, except that everyone had to go through this rigorous process. Without online catalogues for classes, students would have to manually look for classes, set up mock schedules prior to enlistment, and share these schedules with friends and acquaintances to find potential classmates.
Needless to say, the creation of the Ateneo Integrated Student Information System (AISIS) in 2006 was a much-needed change that gave students an easier time when it came to enlistment. Even if parts of the registration system today still have to be conducted in person, like the manual registration we are familiar with, the platform allows the student body to skip most of what made the manual enlistment process tedious.
With that said, AISIS still does have its fair share of shortcomings. Aside from occasional errors and glitches, other issues related to the AISIS system such as the roughness of SY 2016-2017’s Talakayang Alay sa Bayan’s (TALAB) online enlistment system and its major server crash show that digitalized systems do not necessarily make things better all the time.
Technological shortcomings
Head developers of TALAB 2017-2018’s enlistment system Luis Ligunas (4 BS CS) and Joaquin Jacinto (4 BS CS) attribute the problems of the first TALAB’s online enlistment system to several factors, the most prominent of which are the management, user interface (UI), and user experience (UX) of the platform.
The first hurdle came in the form of mismanagement. Jacinto explains that server patching is always implemented before the start of regular enlistment, saying, “The whole reason [for] that is because Ateneo servers aren’t able to take in the load all at once.” The first TALAB enlistment made all students enlist at the same time, and it did so without going through the patching that allows the servers to keep up with the usage. Unsurprisingly, the whole server inevitably crashed.
Ligunas stresses that a series of questionable decisions about the UI and UX aggravated the situation further. The unwieldiness of the addition of a “Next” button was a prime example, which made it very difficult for students to find their desired activities. Furthermore, the oversight that allowed anyone to enlist in a limitless number of these activities became a big controversy as some students enlisted for more than ten classes to reserve slots for themselves and their friends, while others were not able to enlist for anything at all.
Computer Society of the Ateneo (CompSAt) moderator Jessica Sugay expresses the same sentiments, saying, “I think the problem […] was miscalculation or mis-anticipation of what [the students] would do.” She says that the developers put a lot of agency in the users, letting go of class restrictions in the hopes that students would only enlist in what was required of them. Moreover, she mentions how the handlers decided to integrate the entire system into the AISIS website in an effort to make it easier or maintain familiarity, but this decision ended up complicating things even further as it had to be adjusted to the existing AISIS infrastructure.
Sugay and the CompSAt team sought to take over the development in an attempt to do things better, and in clear contrast to TALAB 16-17’s problematic enlistment process, TALAB 17-18’s overhauled system showcases the good that can be done with regards to digital processes.
By and for the students
Things changed considerably with Jacinto and Ligunas appointed as the lead developers, and one factor that contributed to the new system’s considerable success is the extensive planning behind the project. “CompSAt and the User Experience Society (UXSoc) did a lot of work in terms of design and preparation even before writing a single line of code,” says Sugay.
Jacinto and Ligunas conducted thorough focus group discussions and consultations with UXSoc and other students in order to create the most comfortable enlistment experience for the end-users. These discussions generated a lot of feedback that was used to create different iterations of potential website designs, each with their own strengths and weaknesses. “From [these designs], we built up on what would eventually be the final design for the website,” says Jacinto.
The final iteration of the enlistment website sought to address all of the major concerns of the previous system. “One main issue that we tackled was that you couldn’t look at all the classes right away, so we loaded everything in one screen,” says Ligunas. Aside from this, they also made sure to restrict users from picking activities with schedule conflicts or enlisting in too many activities all at once. “[We also thought it was] best to implement the batching system again so that we could prevent crashing,” adds Jacinto.
More than the technical aspects, another key factor that led to the new system’s success was the involvement of the students themselves. “I think the students being involved has played a big role especially in TALAB because the input of the students draws from their own experiences,” says Sugay. Given that the students themselves are the end-users of the system, she notes that they have a decent idea of which parts are good and what else could be improved on.
These changes helped in ensuring that the new system ran smoothly and was easy to use. Even if there were some problems that surfaced when the system was launched, they were not overly disruptive and were eventually resolved. Furthermore, they give a clear picture for what practices should be followed or avoided for the creation of digital systems. Proper planning, technological knowhow, and consideration of student input are all necessary factors that future developers should consider in order to match TALAB 2018’s success.
With that said, it is important to note that the execution of the plans to create a new system or update an existing one is just half of the entire process. Even if the students are the end-users of the systems, the decision to implement the CompSAt developers’ output still comes from the administrative offices that are in charge, and this comes with its own set of complications.
Two-way relationship
Office of Management Information Systems (OMIS) Director JP Gregorio stresses that while university administrators were not involved in the actual execution of TALAB, they nonetheless made it possible for the CompSAt developers to build the system. He states that “[the students] asked [for] some data, with the approval of course of the registrar, to incorporate [into] their system.” The aid of the administration in the creation of these systems is pivotal. As Sugay states, “[There was] a lot of coordination with administrative offices, [and] with the Registrars Office.”
However, Jacinto and Ligunas note the need to support students more if ever they do get involved in future processes. “In terms of AISIS or any other new system that we will have in the future, it would be better to have student involvement [and] support from the administration,” says Ligunas. A large brunt of their experience developing the TALAB 17-18 enlistment system involved self-learning and reliance on existing resources, but with a system as technologically complex and more involved within the Ateneo community as AISIS, this dynamic may no longer come through with the same success.
Furthermore, going beyond the actual development process, another key factor involved in the digitalization process is administrative will. “You cant change how processes are done if the people who control them dont allow it,” says Sugay.
She notes how it is not difficult to see why the administration would have reservations about digitalizing certain processes. For instance, the load revision system involves a lot of steps that will be difficult to recreate digitally, such as the gathering of signatures from different offices, payment and or reimbursement if necessary, and the physical verification of the forms.
Creating a digital replacement for a system as complex as load revision requires a great deal of research, planning, and resources to be able to make one that is representative of what it aims to replace. Moreover, the transition also bears the risk of security breaches or even the potential to create a system that may be less efficient than what could be achieved manually.
Towards a digital campus
The success of TALAB 17-18’s enlistment system reinvigorated the community’s efforts towards digitalization. “Because of the good outcome of TALAB, some other offices have already contacted us to build new systems for them,” says Sugay. Overhauling more systems is now within the realm of possibility, but realistically, without any explicit initiative to change major systems such as load revisions or investments in better infrastructure to support them, the student body can expect to see changes to just the minor systems in the years to come.
Moreover, the existence of an additional hurdle in the form of the Data Privacy Act of 2012 makes the imperative to coordinate efficiently all the more important, which Jacinto affirms: “[We] students are not easily given access to information, so that’s where partnering with the administration will really help because they’re the ones who really have the power to use the data.”
He mentions how having access to the emails of students would have made the creation of a password system much easier and bear less of a security risk than what the TALAB 2018 system launched with, but this was something that they had to work around given the sensitivity of divulging such information. OBF emails qualify as personal information as defined in the act, and this prevented them from easily accessing the data without seeking confirmation from the administration and the students themselves.
“We had a lot of hurdles to jump over,” admits Sugay. Having to coordinate with many different administrative offices and work with the stipulations of the Data Privacy Act was grueling for the development team, but she stresses that persistence is key when making a system that is ultimately still operating within a larger institution.
Nevertheless, the future of digitalization looks bright as people begin to leave manual processes behind. With Ateneo offices moving towards systems that rely on tech-savvy brains and steady communication lines with the students who use these systems, it is essential that this transition be calibrated.