Course Registration

Using the recommendations as outlined in the Mobile Strategies for Kuali Student document, a proof of concept for a university course registration application was developed over a period of six weeks as part of an initiation phase for the student enrollment product. The application features a responsive, mobile-first interface, developed in AngularJS.

Backstory

The Kuali Student project is a student information system established by the Kuali Foundation in 2007. Over the initial years, the primary objective was to build the administrative foundation, which included Curriculum Management and Course Offering. These applications defined essential relationships, such as:

• What is a course, and how is it offered for any given academic term?
• How do the culmination of attended classes constitute an academic degree?

With this data in place, Kuali Student started to prepare for Registration, which would enable students to search and register for classes for a given academic term. As the first student-facing application within this suite of tools, there was no precedent to follow, and all recognized how different of a user experience is needed when students, not administrators, are the primary audience.

In understanding that there were numerous unknowns regarding the best approach for either design or development, I authored a document listing a number of recommendations in order to guide the process along, including:

• designing baseline experiences which can be enhanced according to device capabilities or context;
• building a single responsive application, rather than multiple applications intended for different categories of devices;
• ensuring the application is accessible according to WAI-ARIA specifications;
• serving data via REST web services in order to decouple user interfaces from back-end concerns;
• and generally encouraging more freedom when choosing tools.

Backing these recommendations, leadership allocated six weeks to develop a proof of concept application that embodied these recommendations.

Process

While a separate team prepared the back-end to offer a web services layer, I spent most of the first couple weeks sketching and producing wireframes of the interface, keeping in mind small and larger viewports.

Leveraging my experience using the AngularJS framework the past year for Indiana University projects, I was able to quickly develop the general architecture of the front-end. Once the markup and styles fleshed out, data embedded into the markup was abstracted into static JSON fixtures, and the template was altered to be dynamically driven by these fixtures. With the fixtures as a guide, the services team was able to adapt the web API to match the fixtures. By the third week, the fixtures were starting to be replaced by live web services.

Templates were originally driven by static JSON fixtures, such as in the ScheduleService:

angular.module('kscrPocApp')
  .value('ScheduleService', [
    {
      termName: 'Fall 2012',
      registrationGroups: [
        {
          courseCode: 'CHEM105',
          courseTitle: 'Introduction to Chemistry',
          creditType: 'fixed',
          fixedCredits: 4,
          activityOfferings: [
            {
              type: 'Lecture',
              isMon: true,
              isWed: true,
              isFri: true,
              startTime: '13:00',
              endTime: '15:00',
              buildingCode: 'CHM',
              roomCode: '1105'
            }
          ]
        }
      ]
    }
  ]);

Once built, JSON fixtures were replaced by live web services, such as in the scheduleService provider:

angular.module('kscrPocApp')
  .controller('AppScheduleCtrl', function ($scope, scheduleService) {
    $scope.schedule = scheduleService.query({
      person: 'admin',
      termCode: '201208'
    });
  });

Even though the proof of concept was primarily concerned with the technical feasibility of this approach, I was still able to receive rudimentary student feedback to guide refinement of the user interface throughout the entire project, by means of an Indiana University undergraduate intern.

In order to ensure basic accessibility, the proof of concept was frequently tested with a keyboard as the sole input device.

Outcomes

The proof of concept successfully demonstrated the rapid speed of development capable by decoupling the front-end from the back-end, the engaging user experience possible through modern client-side JavaScript frameworks, and the incredible performance of REST web services. Based on these results, the development team has continued this general architecture, producing higher quality user experiences in less time than sibling teams.

For the first few months following the proof of concept, I guided the Registration development team as they learned AngularJS, and I frequently provided feedback regarding both design and development directions.

Reflection

Since the purpose of the proof of concept was challenging technical concerns over design concerns, a number of design compromises were made. By devoting either more time or a second designer to the project, more effort would have been placed in refining lower fidelity ideas before rushing into code; a visual style would be explored, especially regarding typography and color; and further feedback would be gathered from students, including those proficient with assistive technologies.