Contents

Ed-Fi Integration with Google Classroom

Two Google Classroom (referred to simply as “Classroom” in some instances below) use cases were initially defined by the Governance Advisory Team for the SIG to investigate:

1. Rostering Google Classroom from the Ed-Fi ODS / API
2. Pushing notifications based on Ed-Fi data into Google Classroom

A third use case was added by the SIG itself:

1. Move gradebook data from Google Classroom to Ed-Fi ODS or SIS

Each of these use cases is discussed below, with an initial definition of the use case and its context and an account of technical options discussed by the SIG, with SIG reflection on preference.

The SIG did not prioritize or rank these use cases, in large part because the SIG did not have an efficient way to determine how pervasive the problems (or opportunities) behind each use case were. However, the surveys, anecdotal evidence and other market information gathered by the SIG suggested that each use case seems to apply to some reasonably-sized subset of school districts.

Use Case 1: Rostering Google Classroom from the Ed-Fi ODS / API

Surveys conducted by SIG members revealed that rostering Google Classroom (setup of sections and population of sections with teacher and student accounts) is a current pain point for some (but not all) school districts that use Classroom.

It was noted that one complexity of this tasks is that the school district needs some way to select which schools (or other entities) to roster, so as to prevent over-sharing of student data. The sense was that as a MVP, this could probably be limited to selection of schools (within a district) whose sections should be synced (e.g. no selecting grade levels, or specific sections, etc.).

It was also noted that this use case is supported by some commercial providers, who provide automated connectors between SIS systems and Google Classroom. These options have subscription or similar fees.

Technical Options

There seemed to be 3 options for rostering:

1. Develop a utility to directly roster Classroom sections using the Classroom API, using the Ed-Fi ODS (or possibly an Ed-Fi API) as a backend.

A software spike demonstrated that this is possible and takes relatively little configuration information (key and secret for Classroom access). However, as noted above, it does require some means for the LEA to configure which schools / sections to roster.

2. Roster via Google Classroom’s support for OneRoster CSV 1.0.

In this option, a OneRoster CSV file would be created using the ODS database (or possibly the API) and that file would be submitted to Classroom for import by a LEA administrator for Classroom, using Classroom tooling and support.

3. Direct integration of Classroom to Ed-Fi API.

In this model, there would be a direct integration of Classroom to an Ed-Fi API. This could be either a push from a SIS system (e.g. Google develops applicable Core Student Data API endpoints) or a pull from an Ed-Fi API (such as the Enrollment API).

This option could be quite similar to #1, as it is essentially a direct connection from an Ed-Fi API to Google API. However, the key distinguishing factor here is that it would be developed and maintained by Google, and integrated with Google Classroom toolsets.

In discussions, the SIG felt that option #1 was likely the most efficient and likely short term option for the community.

Option #2 was attractive, but an API-based integration was regarded as likely simpler for users and therefore preferable. The limited Classroom support for OneRoster (CSV instead of API) would leave some complexity and manual steps for school districts in the process. School districts would have to regularly regenerate OneRoster CSV files and (likely manually) upload them into Classroom administrative interfaces. Further, any errors in that process could be more difficult to diagnose given the intermediate file format.

Option #3 (direct integration by Google) is also an API option and would likely be the best option, but getting a presence on the Google roadmap is likely a long-term project.

Use Case 2: Pushing Notifications Based on Ed-Fi Data into Google Classroom

In this use case, the goal is to deliver student performance insights to teachers (and possibly students) in a context where they already work on a daily basis, rather than asking them to visit (yet another) dashboard or application.

In this model, insights developed from Ed-Fi based data aggregations are pushed into Google Classroom. A software spike demonstrated this possibility.

In this use case, it was seen as important to not “overload” teachers with a feed of insights. This could be accomplished by offering teachers a choice of insight feeds, or by making them configurable.

One field practice that could be built upon for this use case is the common practice of “teacher building-level cohorts” in Classroom. Many school districts already create sections (Google “Courses”) composed of teachers at a school for the purpose of sharing announcements and curricular content. In some cases, these also support teacher “communities of practice.”

Technical Options

A software spike demonstrated the ability to generate primitive analytics insights (the spike used student attendance) off an Ed-Fi ODS and push those into the Classroom UX (via the Classroom API) where teachers could see them.

In terms of Classroom workflows, there were a two main options for such insights, either posting them as Assignments or Announcements. Using Announcements seemed like the more obvious integration option, given the semantic overlap.

A variant of this data flow was to post links in Announcements, where the link contained a brief note about the insight and the document at the end of the link held the full details. For example, if an insight needed to involve a graphic or more extensive information, then the link might take the teacher to an external 3^rd party app where the insight could be presented. Ideally this app is authorized for the Google ID of the teacher, so that no additional login is required when following the link. As a variation of this, it would also be possible publish a file in Google Drive and put that link into an announcement.

In terms of what sections (Google “Courses”) to publish insights into, the best option seemed to be to publish such Announcements into teacher building or grade level cohorts. These cohorts could be populated using the Classroom API if they don’t exist already in Classroom.

Using such “teacher-only” sections was also seen as advisable as a mechanism to protect student privacy.  Pushing insights into teacher-only sections helps safeguard insights from accidental publication (e.g. teacher changes the scope of an announcement accidentally) or view by students (e.g. teacher laptop projected to classroom). In our exploration of the Classroom UX, there was clear risk of such scenarios.

Use Case 3: Move Gradebook Data from Google Classroom to Ed-Fi ODS or SIS

Some districts surveyed mentioned the desire to get gradebook data from Classroom out and into other systems, such as an analytics data source like the Ed-Fi ODS, or possibly a SIS or external grade book application. This case likely is important when teachers or school are using Classroom as the main LMS system, where daily assignments are tracked.

This case has already attracted some investment in connection tooling. Google has announced that it will support the write of gradebook data via the OneRoster API specification (however, rostering into Classroom will continue to use the OneRoster CSV specification). Also, Infinite Campus has developed a connector that automates movement of data from Classroom into their product. However, some districts surveys regretted that this feature was not free, but required a fee.

Technical Options

The SIG did not explore deeply the technical options in this area. To have Google support the Ed-Fi APIs necessary for transmitting grades was seen as a desirable option, but of course requires getting a presence on Classroom’s roadmap.