Universal Open edX Mobile Application
The Universal App is on hold while we test a smaller, provider-maintained mobile app. See Collaboration around the Universal mobile app POC
Introduction
Currently, every operator must fork, build, and maintain their own app. The cost of doing so is a significant barrier to adoption and in turn access for learners. We propose a Universal Open edX Mobile App (Universal App), a single app published to the App store and Play store that can be used by any Open edX instance. Note: Although there are two Universal Apps (iOS and Android), this document refers to both in the singular as "Universal App."
In this document, we propose an MVP built around core foundational features, with clear validation checkpoints and milestones to build toward a fully featured Universal App. In addition to the technical foundations, we also share preliminary legal and compliance findings: necessary framing and features to minimize any legal risks and/or delisting. These are preliminary: findings and scope must be reviewed by legal and compliance experts.
The Problem
High Cost: Providers have quoted the cost of deploying and maintaining a mobile app for one platform (iOS or Android) as roughly equal to the cost of deploying an Open edX instance itself. For to support both iOS and Android, this means the cost to deploy is increased by 2x.
Low Access: The high cost of deploying and maintaining mobile apps means very few learners who learn on Open edX instances have access to mobile learning.
No Data Drivers: In addition, the white-label model for the mobile apps means those working on the apps at the platform level can only access usage information through providers. This leads to almost no data to drive product decisions or direction.
Universal Open edX Mobile App
The Universal App is a single mobile app per platform (iOS and Android) that is published to the App and Play Stores. Learners would download the app, choose their learning site, and login to access their course material.
By moving to this model and away from a white listed model, we reduce the cost to operators to near zero, and would dramatically increase access to mobile learning. A Universal App will also enable a shared analytics layer giving the Open edX community meaningful usage data to drive mobile product decisions.
MVP Definition
The MVP goal is to validate that a single, centrally published Open edX mobile app can connect to multiple instances and deliver a functioning learning experience for learners. {Define what a functioning learning experience means}.
Included in the MVP are features that are necessary from technical and legal/compliance standpoints.
MVP Epics
Epic 1: Multi-Tenancy Architecture
Architecture enabling multiple sites to connect to the Universal app
Runtime Configuration: Replace build-time YAML with per-instance runtime config resolution. Any instance can connect. Runtime theming for accent color only.
Multi-instance Session Management: Per site data separation, isolating sites from each other. Include architecture work to enable push per-instance (does not need to solve problem of managing push from multiple instances for one learner, this is future scope).
Platform API for capability communication: A way for a server-side endpoint allowing the app to understand what an instance supports (auth methods, feature flags, anything else?). (is auth methods necessary here? I think webview auth is the move for MVP)
Epic 2: Instance Discovery and Authentication
Site finder: MVP will be through a URL (either user pastes in, or clicks a URL provided by their learning site)
Authentication: A webview that shows learner the correct auth method. This will be communicated by the API for capability communication.
Epic 3: Analytics
Key value proposition of the Universal App is to provide usage data to enable data-driven product decision making.
Analytics Instrumentation: Pending product scoping alignment, add ability to capture behavioral data and bugs.
Epic 4: Legal and Compliance
Features necessary for legal or App Store/ Google Play policy compliance. Important: These features are based on preliminary research. A legal/ compliance expert must review assumptions to drive the features for the MVP
Content Reporting Mechanism: In-app ability to report illegal, objectionable, or copyrighted content. Required by stores, and as a mitigation for legal risks.
Age Gate/ Verification: Necessary for COPPA and similar regulations.
Instance Operator Agreement/ Gating: TOS for instances to connect to the Universal App. Must be signed prior to connecting to the Universal App. A method to gate connection until the agreement is signed must be implemented
End User TOS: For legal risk mitigation, require learners agree to a TOS
MVP Success Criteria
Learner should be able to download the app, navigate to their site, and log in to the correct learning site.
Learner should be able to access course content
Application passes Apple App Store and Google Play Store review
Connecting an instance correctly communicates capabilities, correctly loads in-scope theming (brand color, logo, name).
Analytics instrumentation captures key data
Out of Scope for MVP
The following features will be out of scope for the MVP.
Out of scope feature | Rationale |
|---|---|
In-app Payments | Requires a merchant-of-record infrastructure or reader-app classification. Both require untenable management/maintenance or risks. |
Heavy Customizations/ Branding | Basic branding (name, logo, brand color) should be capable, but any full theming is out of scope for the MVP. |
Push Notifications for Multiple Instances | Managing push notifications for users with multiple learning sites is a complex challenge. Assumption: multi-instance learning is low enough frequency that we can defer to future scope. |
Offline Mode for Multiple Instances | Managing offline content across multiple instances, and logging in/out across multiple instances while offline. Follows the same assumption as above: multi-instance learning will be low frequency. Defer to future scope |
Instance discovery service | Multi-instance discovery and search is out of scope. Enabling discovery presents additional legal/compliance issues (confirm: can be seen as an endorsement of content). |
Cross-instance functionality | Ability for user to view all courses/ assignments/ etc across instances; too complicated for MVP. |
The MVP of the Universal App does not aim to satisfy every instance’s mobile learning requirements. Certain features such as in-app payments are intentionally out of scope: for instances that require features such as in-app payments, the MVP will not be suitable.
Staging and Milestones
The proposed staging will allow us to test and validate assumptions with clear definitions of success.
Phase 0: Pre Build Validations and Feature Definition
Phase 0 includes both product and development discovery efforts. The sum of both will lead to more detailed feature requirements and acceptance criteria. As part of this, the team should be fully aligned on MVP vs future scoping.
Phase 1: MVP Build
Develop the MVP features above. Conduct validations ahead of user testing
Phase 2: Limited Pilot
Preliminary test with live instances. Identify partner instances to allow for small scale real use feedback. This version will be live in the App and Play Stores.
Next Steps
Continue forward with Phase 0: Pre-Build Validations and Feature Definition. Extend the Universal App research space to define requirements.
Risks
Certain features may never be possible: in-app payments, etc.
Open Questions
How to handle if a user in low connectivity is logged out? Can we manage log-in offline??
Release version support?