As a residential education software company working with many different colleges and universities, Roompact designs its software in a way that can accommodate the range of approaches institutions can take to the learning process in the residence halls. One of the most interesting design challenges we have confronted is how to accommodate both residential curriculum models and category-based programming models in our software. At first glance, one may not think the processes would be that different. Programming models and residential curricula, however, are based on different sets of assumptions and practices.Tweet This The chart below illustrates a few of these:

The Logic of Curricular versus Programming Models

Whereas different programming and community development models in the past have been largely interchangeable, resting on a similar set of assumptions and practices, curricular models represent a departure from the past. One of these changes is a reduced reliance on programs as the main method of educational delivery. Curricular approaches utilize strategies that move beyond the program such as through community meetings, roommate agreement processes, intentional resident conversations, and attendance at campus partner events.

Programs are a subset of eventsBecause curricula take a broader view of programmatic efforts, the Roompact team made an intentional decision to name our “program-tracking” module “Events.” All programs can be considered events, but not all events are programs (at least in the traditional sense).Tweet This By adopting the “Events” moniker, this allows individuals to think more broadly about what this module can be used for. As we expand and enhance it, Events will allow for an even broader array of educational initiatives that fall outside of the traditional notion of a program.

Roompact
Roompact Software Tip
The “Events” module in the Roompact software can be used for more than just traditional programs. It can also used to track community meetings, campus events that student staff bring their residents to, and any other sort of event-like experience… including more passive forms of programing and education.

A deeper level issue that has given our software engineers a challenge, however, is the inverted logic flow of a curriculum versus a programming model. Under a programming model, student staff members propose programs to a professional staff member who reviews and then approves or denies the proposal. Under a curricular approach, however, this process is reversed. A learning plan is “assigned” to an RA. The approval process occurs through curricular planning and peer review before it is executed by a staff member.

The Inverted Flow of Educational Content GenerationThis inversion has many implications for how one designs software to accommodate both approaches to student learning. Events, programs, and educational interventions need to be proposed and assigned bidirectionally: coming from either the student staff member or from the professional staff member. Program model categories and curricular goal areas also have different tracking needs and assessment expectations. Curricular efforts often require connections to other data sets and stricter consistency with set learning objectives as opposed to the assessment needs of programming models.

Roompact
Roompact Software Tip
If you want to assign a staff member a pre-determined learning or lesson plan, you can use the “split” feature within events to do so. Simply fill out a proposal (or copy and paste from your lesson plan) and tag the staff member(s) responsible for executing it. Then, check the box to “split” the event. Each staff member will now be assigned their own copy of the learning plan to execute.

Splitting Events Feature in RoompactWhile this presents a software engineering challenge, it also highlights why there is so much dissonance when institutions change between programming model mindsets and curricular mindsets.Tweet This The logic of both paradigms and the processes that support them, while similar on the surface, are vastly different. Without an appreciation for the philosophic differences between the two, approaches can become muddled and inconsistent.  The same holds true in designing the software that enables it. The challenge is real.