Design Doc

• https://docs.google.com/document/d/16orj6Ag1R158-J-zSBfiY31RKQ5FuSu1O5F-zpSKOg4/edit?usp=sharing

Goals

• Fill niche between instructor dashboard and insights

• Share with other Open edX community to save effort, and community involvement

Customer profiles

• Corporations doing training on their products - training customers and training sales people

• Organization that has number of franchises

  • (Future) Single Dashboard without going to multiple courses/places

Topics

• Coupling

  • Model dependency

    • Currently, pulling from Django models and Mongo data.

  • Testing

    • Unit testing within the app via Pytest

    • Integration testing

  • Integration points

    • e.g., anonymizing via GDPR

      • May need hooks so the core platform would know to call registered listeners.

• Technology roadmap alignment (React, etc)

• Integration with edX pipeline and platform

  • Want real-time data and not be downstream of pipeline

  • Needing REST APIs in the platform

  • Possible future

    • Keeping the Analytics Data API as a contract.

      • Then have implementations plugin.

    • Could reuse frontend and React components

    • Analytics Data API

      • Option 1: Could theoretically pip install into the LMS

      • Option 2: Make Analytics Data API a container for Plugins of Data APIs

        • edx-pipeline generated data

        • figures data API

        • enterprise data API

    • Further future: can the data or API be declared instead of being imperative?

• Data

  • What data is aggregated and not aggregated?

    • Right now, only keeps aggregated data - so no PII.

    • Total users and enrollments.

  •  What time series?

    • Activity at a particular time.

• Maintainability

  • Right now targeting Ginkgo

  • APIs go away or Data models change

Other Notes

• Currently the Frontend is fully dependent on APIs, so dashboard can be replaced.

• Next iteration will have custom reports, can be added as widgets.

• Currently, reverse engineering the instructor dashboard code to understand the data model usage.

• They use APIs where they exist.

  • Couldn't find enrollments API.

  • Using Course Blocks API.

• CSV reports will contain user data.

  • If there is no cache or local storage of that data, then it might be fine.

• Adding APIs

  • OSPRs would be against master; while they are on Ginkgo.

  • Need an API to list the users per course, with filtering.

  • edX is also planning to invest in APIs - needed for Frontend and Backend split as well.

    • However, thinking about those APIs from the business needs perspective, not necessarily from the data model perspective.

    • Can look at Figures' business requirements as input to API discussion.

• Would like to see

  • More things pulled out of the core.

• For Insights, we depended on the event log rather than the SQL models.

  • We assumed the models would change more often.

  • While the event log could be translated.

  • Historically, though, it seems we never really changed our models.

• edX.org's scale would likely not be able to execute Figures as is it currently designed.

• Currently, testing out rebuilding the LMS - in React with decoupled backend.

• Cron tab

  • Pulls from platform's data and puts in Figures' data model

  • Figure's frontend calls APIs in Platform LMS as well as APIs for aggregated data in Figures

• Are real-time use cases a reality?

  • How is progress going on a daily basis, generally.

  • Going through the day, hour-by-hour

    • for example, for communication campaign

  • Jill's post in Discourse also asked for real-time

  • edX has heard about the flipped classroom use case - where educator wants to know about learner's activity.

• Lightning talk - CSS modules

• As long as endpoints with APIs are maintained, with advanced notice of changes/deprecation.

Whiteboard of Option 2 possible future

Open