Quill Framework - A Unified Platform API

Quill Framework is a platform for educational writing apps. We are unique from most educational platforms in that our apps are tightly integrated into the platform - in particular, when a student completes a learning experience, the student returns to the core platform, and the app sends back data on the experience. Typically platforms are aggregators of content, where users are sent off to other sites, but the subsequent experience is not captured and returned to the core platform. This integration enables us to provide a seamless user experience across multiple learning experiences.

Introduction: Apps & Activities

The two most important concepts within our system are apps and activities. An app is a tool that provides a unique type of learning experience (such as telling a story or drawing a picture). Apps are implemented by external teams with an independent codebase. An activity is a specific experience (often 10-15 minutes in length) within a particular app. Each app has hundreds or thousands of activities. For example, in the app Quill Writer, an activity is to write a short story using words from the Hobbit. Each activity has three parts:

(1) the metadata about the activity (name, description, standards - generic to all apps)
(2) the activity’s materials (such as the assigned words and prompt)
(3) the activity's goal (write a story that has eight sentences).

Connections Between the Quill Framework and an App

Each app is connected to the Quill framework through five parts:

(1) Teachers and admins have access to an app specific activity editor. Each app has its own editor.
(2) Quill Framework has a list of every activity from every app.
(3) Student has an access token that loads the specific activity.
(4) The activity has a defined end goal, and upon completion the user returns to the Quill platform, and data is passed to Quill.
(5) Quill framework has a schema that understands some of the data passed back to it.

(1) Teacher or admin have access to an activity editor.

We provide a page called "create a new activity." This page contains a list of links for each app that provides a content editor. There are two steps to this process: (1) filling in the Quill Framework’s metadata, and (2) the app’s specific content data. This process happens on two separate domains.

When a teacher clicks on "Create a new activity" they are first brought to a Quill Framework metadata data page where they fill out the name, description, standards, and taxonomy of the activity - basically all of the information that relates to how this activity fits into our system.

The teacher then clicks on a "continue" button that sends the teacher to the partner app's content editor, where the teacher then fills out information specific to the partner app, such as the prompts and questions involved with the activity. This process works in the same manner as a student session - we pass over a teacher ID, and when a teacher hits save (similar to step 4), we pass back the activity ID and the teacher ID to the Quill Framework. The Activity ID enables us to link to the Quill Framework metadata to the app specific data, and the Teacher ID enables us to attribute the teacher who created the activity.

(2) Quill Framework has a list of every activity from every app.

Teachers are able to browse for activities through the activity planner. The activity planner displays a list of every activity from every app, with the content arranged through our taxonomy. Teachers are able to assign activities to their students. When a student is assigned an activity, the student sees that activity as a link on the student's profile.

(3) Student has an access token that loads the specific activity.

When a student clicks on "start activity" the student's ID and activity ID is passed to the partner app. The partner app loads the activity for the student.

Note: We may also pass additional settings along, such as whether this is a one player or two player experience. Each app may have its own settings, and there isn't necessarily a clean way of sharing this, except for making a generic bank of settings that apply across all apps.

(4) The activity has a defined end goal, and upon completion the user returns to the Quill platform, and data is passed to Quill.

The main obligation for an app developer is creating an end-state for the activity that returns the user back to Quill, such as answering 10 questions, writing 6 sentences, or drawing a 3 panel comic. This means that app will have to know this is a Quill specific activity, and they are presented with a "complete" button that returns to the Quill platform.

This could be a generic link that goes to quill.org/profile, or perhaps it could be a unique link that directs the user to their next activity. Hypothetically, Quill Framework could generate this link and pass it to the partner app.

(5) Quill framework has a schema that understands some of the data passed back to it.

Each app will have its own logic and generate its own data schema. There are certain universal fields that we will be able to understand (such as the percentage score, and the work produced) while there are other fields that we will not be able to parse. In this instance we will request a generic blurb that dumps all of the data we will not know how to handle. Over time we will build a richer schema that understands new types of data. We will never capture the entire student experience, but we do want to capture the meaningful parts.

Follow Up Project: The Generic Quill App Template

Under this system app developers own their own apps, and have complete control over the content. To enable app developers to build their own educational apps for our platform quickly, we could provide a template app that comes pre-installed with all of the underlying components they need to build an educational app - for example, a template of a content editor, the hooks for the API, our Quill Bootstrap theme, etc. This would likely be provided as firebase app, though we could also provide templates for other frameworks/languages. We could provide these basic components so that you can easily fork the project and build your own app in our ecosystem, while still owning your own app.