Graduate-In-Time Application (GITA)

Thursday, April 24, 2008 4:07

Our final project was the Graduate-In-Time Application, or GITA for short. Essentially it is a graduation roadmapper/planner for university students, in this case, NUS students.

Screenshot of GITA roadmap screen

Inspiration for this project came mainly from my experience from the NUS Overseas College (NOC). Before being accepted into the program, I was forced to come up with a roadmap (in Excel spreadsheet), for NOC to determine whether I would be able to graduate in time (within 4 or 4 and a half years) if I were to go for the program. Although initially quite daunting, it proved to be invaluable and very important exercise to go through. It ultimately gave me the peaceful state of mind that I would have taken everything I needed to take, and unlikely to be caught in the accidental scenario of missing one essential module and being forced to stay for extra semesters.

NUS follows a modular system. With this system, it gives students flexibility and freedom in planning their own paths to graduation. For NUS, it also allows them greater compatibility with other universities, as well as increase enrollment. However, most students do not plan out their modules or path to graduation, preferring to leave it to just before the bidding round starts. This results in a lot of last minute changes, biddings and desperate emails to faculty administrators to appeal. While there is a present system available to most students called the FFGV (File-For-Graduation-Verifier), it only opens to students in the final year, whereas planning should be done right at the beginning. Also, each department has their own system, some do not have such a system at all, and it becomes a great hassle for students to have to log in to multiple systems in order to find out all their administrative details.

The GITA will let students know (amongst other things):

1. what modules they need to take, depending on their program.
2. the pre-requisites for each module, and whether they have fulfilled them or not.
3. whether they will be able to graduate in time, based on the modules already read and intend to read.
4. MCs and CAP attained so far, how many more MCs to go, and grades required to achieve a certain CAP.

The whole project development was broken up into 5 distinct phases:

Phase 1 – Project Proposal

For the first phase, we conducted ethnographic studies and interviews to ascertain the needs and behaviors of the students. We also relied heavily on our own experiences. This was like doing the whole “Learning Experience” assignment all over again, having to observe people’s behavior and scheduling interviews for laddering. Almost everyone interviewed knew someone who had to stay back a semester just because of one or two modules. This was also largely due to improper planning earlier on. Despite this, not many students actually take the time to plan, citing unpredictability as their main reason to not doing it. However, after telling them what we intend to do, our interviewees did seem piqued, and gave more comments after.

Phase 2 – Defining

For the second phase, we revisited the concept of personas and four-pleasure analysis framework, just like in Assignment 2. The key emotion that we wanted to give our users was the sense of a “peace-of-mind”, that all your administrative burdens are solved with our application, and even if a disaster strikes, you will still be able to graduate within stipulated time. Additionally, the ability to predict CAP scores and grades may inspire the user to work harder to achieve targeted grade.

After having gone through the four-pleasure analysis, the application of it made more sense now, and so did the product benefits specification. However, the difficult part was having to actually “design” our application in order to meet the specifications. Still, it proved to be a very valuable tool and gave a much clearer idea of how the final application should be designed.

Phase 3A – Information Organization

This phase introduced a new method which we utilized: card-sorting. It is a practical tool to find out how students actually organize information, in this case, modules. First, we designed a simple card like so:

Image of Module card

Then, we asked 9 students from Computing to describe to us how they would sort their modules in order to plan a roadmap.

This was a rather interesting phase. The idea of card-sorting was new to me, but proved to be rather useful. The main problem was that we had way too much “information” for the users to sort. I do believe though, that it is not just the end result that matters, and how users organized the information, but that it is just as important to observe HOW they organize it, and observe their thinking process. This gives even more insight as to how users think and may be more important than how they actually organized information in the end.

Phase 3B – User Evaluation

When we reached this phase, things became really hectic. The main problem with our project that it relied very heavily on the functionality of the application, in order for proper evaluation and testing to take place. Meaning to say, we cannot just “fake” and hard-code our application. It had to work to some credible and realistic degree. As such, a lot of time was spent in coming up with a workable prototype before getting down to real user testing. However, due to the very short time frame, it was near impossible to get that many students to evaluate our product. Still, we did manage to get about 3 users: 1 novice and 2 advanced.

For user testing, we asked our testers to perform 2 tasks:

1. Plan a roadmap and ensure you can graduate in 4 years
2. Estimate the grades required to get a CAP of 4.2 in 4 years

We also performed heuristic evaluation, the experts being ourselves. We followed the framework given in class by evaluating our application based off:

1. Meeting Expectations
2. User is Boss
3. Errors
4. Keeping it Simple

Actually, user testing and heuristic evaluation was not new to me. I had done this before in another computing module, only this time, I had a lot less time to do it. It is extremely useful and important, and given more time, I’d be sure we would have gotten much more feedback and be able to effect more changes. For me, the key lesson learnt during this phase was simply: start programming earlier.

Phase 3C – User Experience Evaluation

This was the culmination and the most interesting phase to me. Initially, I could not really understand what this phase was for, but after going through the circumplex of emotions and designing the questionnaire, it proved its use and importance. In the end, we designed our questionnaire and circumplex based off the four-pleasure analysis we came up with in Phase 2. It was a simple mapping of:

• Appearance of application (physio-pleasure)
• Intuitiveness of application (psycho-pleasure)
• Usefulness (social-pleasure)
• Peacefulness (ideo-pleasure)

The range of emotions used were:

Sure it might be a bit dubious and questionable, but well, it did serve our purpose well and help give us a very general impression of how users felt as they used our system. It was only after completing this phase did I understand how all the other phases, tools and methods linked up.

Back to Homepage

Comments

Leave A Comment