Case Study

Identity Service - Osmo

To enable our end users - kids/students, to safely and securely access all forms of Osmo learning resources from anywhere (device + location) while empowering all stakeholders at school and at home to track and drive learning outcomes for their wards.

Outcome:

5X

User adoption

1200

Schools

20

Districts

Visit

edu.playosmo.com

There are several shortcomings of having student/ child ‘profiles’ nested exclusively under a single parent or teacher account:

Shifts focus from the real end-user i.e the child. Inhibits ability to look at child’s data in a consolidated, uniform manner

Student ‘profiles’ are not recognised beyond the account under which they’re nested. The same child’s profile can exist independent of each other across different guardian/ educator accounts (For example, a child’s profile on the parent’s account while at home and the same child having another profile under the teacher’s account while at school)

Since the focus is on the teacher or a parent as the small independent unit, one cannot track student data at any level beyond the teacher or parent ( for example: school < district < state etc)

Introduction

Why ID Service?

01. Having role-based access is the key to scale in both consumer and EDU worlds

3rd party SSO integrations

Google classroom
Clever/ClassLink integration
LMS/LTI compatibility (content/resource management + tool access)(P2)

Better profile controls +

user data management

Ease of access: Opens up alternate modes of access for younger/ physically challenged students - QR code scan, picture password (easier for younger students)
Prevent switching between profiles - one of top 5 customer requests from Educators for Osmo since 2018
Control access to students towards creating/ deleting/ editing profiles

Role-based access and controls

School/district level reporting
Student data management
Student profile management for school/ district
Home access for students

Seamless access to all Byju’s Education tools and integrations (P3)

Parent, student dashboards
Assessments
Workbooks, Mini-games
Other future cross-platform integrations - byju’s K3, Future School, others.

02. Market opportunity & 5 year vision for EDU

The vision is to build a ‘Byju’s’ ecosystem across both supplemental and comprehensive curriculum, integrated with existent school tech systems and accessed by all school stakeholders from multiple device platforms.

Our positioning as an integrated offering of content + educator tools + devices will allow us to not only further penetrate but also expand the existing market for educational content in schools

03. Competitive landscape

A look at edtech players in the supplemental <> comprehensive ‘spectrum’ indicates the need to enable integrations with existent school systems to unlock scale in both ‘consumer’ & EDU worlds.

04. Why ID Service helps

It connects District, Admin, Teachers, Students, Parents, Admin and every other actor that has a role to play in student performance.

Currently we have student/child ‘profiles’ nested exclusively under a single parent or teacher account. The same child’s profile can exist independent of each other across different guardian/educator accounts. One cannot track student data at any level beyond the teacher or parent (eg, school, district, state, etc)

ID service helps to:

Merge student profiles and provide them with single login credentials
Enable District, School level admin access controls
Enables user access from any device/platform
Seamless access to all Byju’s Education tools and integration

It connects District, Admin, Teachers, Students, Parents, Admin and every other actor that has a role to play in student performance.

ID service helps to:

Merge student profiles and provide them with single login credentials
Enable District, School level admin access controls
Enables user access from any device/platform
Seamless access to all Byju’s Education tools and integration

Implementation journey

3 phase plan

The project was carried out in 3 phases:

Phase 1: Separate Teacher + Student logins
Phase 2.0: Identifying school specific roles of educators from Phase 1 and expansion to districts
Phase 2.1: OneRoser integration (Clever/ Classlink with additional school roles)

Why 3 phase?

Non-integrated webapp experience to be built irrespective of SSO & oneRoster. This will cater to all schools outside Clever/ClassLink jurisdiction.

To migrate existing Osmo EDU users to the new system without data loss.

COPPA - Children’s Online Privacy Protection Act

In the U.S, COPPA applies to all operators of websites and online services that collect personal information from kids under 13

A need to investigate & validate COPPA compliance impact on current flows & backend infrastructure before Clever/ClassLink integration.

STATE AT INCEPTION

PHASE 1

PHASE 2

PHASE 3

Introduction

What is OneRoster

OneRoster® solves a school’s need to securely and reliably exchange roster information, course materials and grades between systems.

Key Features

Provision key roster related data including student, course and related enrolment information between various platforms such as a student information system (SIS) and a learning management system (LMS).

Flexible implementation options to align with an institution’s needs and capabilities, supporting simple spreadsheet-style (CSV) exchanges as well as system-to-system exchanges using REST API’s.

Improves data exchange among multiple systems with roster and grade-book information, thus eliminating problems before they happen.

Transmit scored results between applications, such as student scores from the LMS back to the SIS.

User maps & journeys

It was not an easy task. The problem statement:

Begin by bringing the nested login system to a system with separate logins for student and teachers.

Build a system for teachers to share classrooms with other teachers and be able to merge duplicate accounts.

Integrate Clever/Classlink to open up to district roles with elaborate permission system.

A solution that doesn’t compromise on user features while is still easy to understand and follow from both a student and teacher’s perspective was desired.

The Phase wise plan should work in sync between the OSC & Native end.

All of our user personas for OSC need to be addressed separately, ie

Existing OSC user
Existing OSMO user, not on OSC
New user

In the next section, I will discuss the possible different ways to solve the problem, weighing pros and cons for them, and the conclusion.

01. Approach 1

Phase 1

No schools/groups exist in the Teacher ecosystem. They can invite other teachers to collaborate at a classrom level. Editing rights can be transferred within them.

Shared educators can leave a classroom whenever they want. This will remove the viewing permissions

If owner deletes a classroom, it will be removed from all shared educators

Phase 2

Each Educator can create a school or invite an admin to create a school

Each educator can join an existing one created by another educator through invite.

By default, “My classrooms” & ‘classrooms shared with me’ will exist for all educators before they create/join a school.

Build a classroom level invite system as well.

Creator of the school has edit rights for all classrooms

An educator can only move a “My classroom” to a school

Only the creator of the school and the educator moving the classroom have editing rights initially. They can later be changed.

Educators can be in multiple schools.

Pros

Phase 1 is easily executable with minimal engineering. Can go live faster.

Cons

The school structure in Phase 2(from oneroster or admin control) will be different from the linkages created in Phase 1, which can make back-end migration quite challenging.

Automated classroom sharing will be terminated from Phase 1 when Phase 2 comes in. This can lead to fatiguing UX jump for users.

02. Approach 2

Concept

When Educator logs in, a default entity will be created (can be called “My classrooms”) which will contain all their classrooms.

An educator can invite other educators to that school.

A secondary educator will be able to see all the classrooms in the school (shared roster) but not their student data unless the owner of the classroom gives them view access or transfer their edit access.

One classroom can only have one educator with the edit access but multiple educators with view access. That also means one educator can be the owner of multiple classrooms.

The educator becomes super-admin, who can pass on the access to another educator later-on. Everyone has their own classrooms with edit access and others with only view access.

Can an educator be a part of more than 1 school? -> Yes, they have classrooms in both schools(edit and view). Classrooms can be transferred from 1 to another.

Cons

Anyone from the district can join any school and have access to all the classrooms+educators list.

Pros

Migration from Phase 1 to Phase 2 becomes easy as a pseudo school entity is created in Osmo backend matching Clever/Classlink rosters.

Finding school for a teacher is easy compared to creating one.

Merging is easier in Phase 2.

03. Approach 3

Phase 1

Create schools based on MDR database(3rd party) to find list of all public and private schools with 96% database match with Clever/Classlink oneRoster. More than 90% of current Osmo school users use Clever/Classlink.

Mechanical school creation for all other users, ie, Homeschoolers, Tuition Centres, Libraries, etc.

Permission system - Changes upon request/approval internally within OSC for transfer, assign, delete, etc. It is a limitation because MDR doesn’t hold that data.

Allow switching schools that lie within a district. They mostly carry the same email-domain and MDR doesn’t point towards a specific school in the backend.