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