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:
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:
Backing these recommendations, leadership allocated six weeks to develop a proof of concept application that embodied these recommendations.
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:
Once built, JSON fixtures were replaced by live web services, such as in the scheduleService provider:
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.
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.
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.