Curricle

Curricle aims at developing a lively, interactive, playful mode of navigating curricular programming and choices not as a catalogue but as a landscape of intersecting paths; not as an inventory of single items grouped into disciplinary pages and lists, but instead as a unified whole, a dense fabric woven together out of interdisciplinary connections.

The core of the project will take the form of a comprehensive experiment employing course-listing data from the Harvard Registrar’s office and Harvard Archive. These data will produce aggregate visualizations that reveal clusters, connections, cross-disciplinary themes and threads. The aim will be to establish what sorts of approaches yield the most interesting new ways to see, experience, and explore the curriculum with an eye to developing a platform that would leverage the power of curricular data to tell stories that help to orient, guide, and shape student choices in richer, more interactive and imaginative ways.

Potential projects for Summer 2017

User accounts and workflow

1. Problem statement. Curricle’s primary user base will be students seeking to assemble their class schedules for an upcoming semester. They need to be able to easily organize (and sort) classes they’re interested in. We’re looking for both the obvious solutions and the non-obvious, the functional solutions as well as the unconventional. As much as this is an exercise in practicality, it should also be considered as creative and exploratory.
2. Development tasks.
   1. As it’s developed now, users have a single tray of interesting courses from which they can toggle courses on and off to draft a semester schedule or multi-year path. The relationship between a tray and a path could benefit from additional clarification (e.g. should you be able to save a path -- or multiple paths -- independently from a tray? Should you be able to create paths that draw from multiple trays?)
   2. User dashboard -- tray(s), courses i’ve taken
   3. Tag / color code / annotate courses within a tray
   4. Multiple trays with names
   5. Additional useful information that might be available from a user’s dashboard? E.g. goals, research interests.
   6. Create a landing page to orient users to the platform. This would: give context for both advising and historical modes; provide a path for Harvard students to log in; provide a path for non-Harvard students to get a sense of the site without full access.
   7. Differentiate between at least two types of users: students (basic privileges, can view courses, create trays and paths) and professors (additional privileges to add information to their own courses).
   8. How can we create more internal coherence between the search and tray views? One approach we’ve discussed is an accordion (something like this oriented vertically).

Search result visualization

Problem statement.

One of Curricle’s main goals in its advising mode is to connect students with relevant classes the cross disciplinary boundaries (e.g. returning relevant philosophy courses to chemistry students). One way that we’ve approached this is through returning search results as both a traditional list of items as well as highlighting them within a visualization of the entire curriculum. In this way, students can explore both the macro and the micro simultaneously; ideally the holistic snapshot of the curriculum that the visualization provides will encourage broader and unexpected exploration.

Development tasks.

1. Design and implement multiple views for visualizing a set of search results within the context of the larger curriculum. Visualizations should be designed to support the search for relevant courses across departments. Emphasizing (invisible, unexpected) connections between courses is one approach.
2. Develop an interface so that users can toggle between visualizations and adjust any necessary fields.

Historical Data API

1. Problem statement. We have close to 100 years of Harvard curriculum data. As you might expect, the completeness and consistency of the data are quite spotty. Our goal is to make this data available to designers and researchers so that they can analyze and tell stories about the evolution of academic disciplines over the past century. Right now, there is no easy way to work with the data. Our goal is to create a straightforward and well documented API to solve this problem.

1. Development tasks. The API should do the following:
   1. Users should be able to query the database by relevant fields
   2. Users should be able to retrieve metrics about aggregated results (e.g. summary of all values within the “Department” field).
   3. GUI for quick exploration. Non-coding users should be able to explore the schema, build queries, and see results in a basic way.
   4. Student ideas about how to usefully retrieve / aggregate data for visualization and analysis are welcome!