Design Decisions & Rationale

Throughout Toodle's development, our team made several decisions to improve how the system supports university tutoring. While the project requirements established the main functionality, we had to consider how that functionality should work in practice.

Many of these considerations were influenced by the tutoring structures and processes familiar to us within the School of Computer Science and Applied Mathematics (CSAM) at Wits.

The following decisions reflect how we refined our original approach to make Toodle more practical, intuitive and representative of a real university tutoring environment.

Separating Administrator and Lecturer Responsibilities

Our initial design had three roles: Organiser, Tutor and Student. However, we recognised that the Organiser role combined responsibilities that would not necessarily belong to one person in a university department.

For example, managing user access across the system is different from coordinating tutorials, allocating tutors and reviewing timesheets for a particular course.

We therefore decided to separate the Organiser role into Administrator and Lecturer, resulting in four roles.

This allows Administrators to oversee the system while Lecturers manage academic activities associated with their assigned courses. The distinction better reflects how administrative and teaching responsibilities are divided in practice.

Separating Courses from My Courses

Originally, the Courses page displayed the entire course catalogue, even when users wanted to see only the courses they were involved in.

We decided to introduce a separate My Courses view because browsing available courses and managing assigned courses are different activities.

The Courses page allows users to explore opportunities, while My Courses gives Tutors and Lecturers quicker access to their own allocations and coordinated courses.

This adjustment was intended to make navigation clearer and help users focus on information relevant to their responsibilities.

Making Excusals Session-Specific

We recognised that recording an excusal against a general date did not always provide enough information about the work a tutor would miss.

A tutor may be responsible for multiple sessions, including tutorials and laboratories, on the same day. Knowing only the date would make it difficult to identify the affected session or arrange suitable cover.

We therefore refined the excusal process to require the specific session and occurrence date.

This makes each request more meaningful and allows the system to identify the duration and type of teaching activity that needs to be covered.

Swapping Individual Sessions Instead of Entire Allocations

The original approach to session swaps involved exchanging tutor allocations. However, we recognised that a tutor may only need someone to cover one particular session rather than permanently take over their course responsibilities.

We therefore changed the approach so that swaps affect specific dated teaching sessions, while the original course allocations remain unchanged.

The other tutor must agree to the exchange before it can be approved by authorised staff.

This gives tutors greater flexibility while preserving clarity about their ongoing responsibilities.

Choosing a Calendar Subscription Approach

We wanted tutors to be able to view their teaching schedules alongside their other academic commitments.

One option was to integrate directly with Google Calendar. However, this would introduce additional account permissions and synchronisation requirements while limiting the initial integration to a particular provider.

We instead chose to use iCalendar subscriptions, which are supported by Google Calendar, Outlook and Apple Calendar.

This provides a simpler way for users to access their schedules through their preferred calendar applications without requiring separate integrations for each one.

Improving Lecturer Access

When introducing the Lecturer role, we also considered how academic staff should gain access to Toodle.

Using the same onboarding process as Students would require lecturers to provide information intended for tutor applicants, such as course marks and personal availability.

We therefore adopted a separate staff access process, where access can be approved or initiated through an Administrator.

This allows lecturers to enter the system with the appropriate responsibilities and access the courses they coordinate, without completing an unrelated Student onboarding process.

Overall Design Approach

These decisions reflect our effort to make Toodle more than a collection of required features.

We considered how different users would work with the application, how tutoring activities are organised within a university, and how changes to one workflow could affect another.

Our goal was to balance simplicity and usability with the administrative structure needed for managing tutors, courses and teaching responsibilities.

By refining our original designs and approaches, we aimed to create a system that feels practical and appropriate for a university environment such as Wits CSAM.