Purpose

This is a space to explore the steps to build and maintain a Universal Open edX Mobile App (Universal App). This is a working document/ space! We’ll enumerate the technical requirements, legal considerations, feature trade-offs, and maintenance needs. The goal is to collect information in one space to help the community decide whether a Universal App is both feasible to build and sustainable to maintain.

Context

Currently, to enable mobile learning, Open edX instances must: fork, customize, build, and deploy the mobile apps. After deployment, there are continued maintenance costs. The cost and complexity poses a significant barrier to adoption of the mobile app.

A Universal App will unlock mobile learning for learners by lowering the cost of adoption to near zero. Learners will be able to download the iOS or Android Universal Open edX App and connect to their learning site.

Please view the video by @Ivan Stepanok for more context:

Discovery Areas

Legal/ Compliance Research

Will add details here as we research. Two main areas to consider:

1. Legal considerations: what are the risks and mitigations? What do other platforms do?

2. Platform (iOS/Android) considerations: what are the steps required of similar mobile apps to get approved/avoid delisting.

Both require mitigations from the app maintainer.

Illegal, objectionable, or copyrighted content

Legal

The app maintainer must position itself as an "access software provider" which means it is providing software that enables connection to independently operated and hosted content.

In this model, the maintainer does not host content and cannot directly moderate instance content. This limits liability and gives safe harbor protections in the US (more research needed to understand other jurisdictions). The app maintainer will need to:

• Create Instance Operator Agreement that indemnifies the maintainer from instance violations and requires compliance with applicable laws

• Create End User TOS that disclaims responsibility for instance-hosted content and limits the maintainer’s liability

App Store/ Play Store

Pertaining to illegal, objectionable, and/or copyrighted content, the App and Play stores require:

• an in-app reporting and blocking mechanism (App Store on UGC, Play Store on UGC)

• a quick response process to reports (time limit needs to be confirmed)

• an ability to blacklist instances that violate Store content rules

• a contact email/published contact info in the app to report abuse

The stores require some way to remove content/ policy abusers; for an access software provider, there needs to be a strategy for handling and tracking reports to ensure compliance with App or Play Store policies including tracking responses.

Data Privacy

Needs more research. This is complicated with the various international privacy laws. Will need to look at various age verification requirements and reference other similar apps. Good apps to reference: Moodle and MyChart.

Feature Evaluation

This section evaluates technical and product requirements in order to understand the necessary effort to move towards a universal app.

Prerequisite Features

These are necessary features for an MVP of a Universal Mobile App

Authentication

MVP Required scope

• Different instances use different authentication methods. How to cleanly support?

• Potential challenge w/ users registered to multiple instances?

Multi-tenancy/ learning academies

Outlined in OEP-68 (https://github.com/openedx/openedx-proposals/pull/734 )

MVP required scope:

• Shift to run-time YAML config: Development task

• Site selection: URL or QR code: Development/ Product/ Design

• Multi-instance data management: caching? data separation?

•  

Reporting Capabilities (for policy compliance)

Age Verification Capabilities (for legal compliance)

Custom App Only

These are features that are too complex/ specialized for the Universal App. If required for an instance, these features will require a custom app build.

In-App Payments

Suggestion: for MVP no payment support. Consider for near term: support Web Payments and reader app status.

Two methods: 1. An organization as the merchant of record, 2. support only web payments as a ‘reader app’.

Merchant of Record: Not Feasible

If IAP were added, an organization would need to act as the “merchant of record” meaning the org would collect payment and distribute. This is an ongoing significant effort requiring payment management and distribution, and financial tracking and reporting, etc.

Pros:

• no Store fees (Apple/ Google collect fees on IAP)

• simpler flow for users: native IAP are easier experience

• relatively higher conversion rates (than a web payment model)

Cons:

• significant overhead, increased liability for Axim (returns? chargebacks? distribution infrastructure?)

Web Payments (Need to confirm)

In this model, learners can click upgrade/ purchase buttons within the app; the app would direct the user to a browser to a page owned by instances. Instances would then manage payments themselves. This is how the Moodle App handles payments but has some risk… the app needs to be categorized in a specific way for the stores to approve web-payments.

Pros:

• No Store fees

• Very low responsibility/ liability to Axim; burden shifted to instances

• Simple: no additional app capabilities needed

Cons:

• Risks of delisting

• Added step for learners: lower conversion

• Disjoint UX

Heavy Customization

Other Impacted Features

These are features that will need to be evaluated to understand the impacts of a shift to a Universal App.

Push Notifications

Version Upgrades and Version Compatibility

Product Analytics

Block Types

Theming Capabilities

Universal Open edX Mobile App Staging

This section will look at a staged rollout of features leading to a Universal app, a proposed MVP, and future states. Each stage will have hypothesis to test/ validate.

Preliminary Features

Multi tenancy / Learning Academies:

Appendix A: Relevant Apps

Moodle: allows self-hosted instances to use the Moodle Mobile App. This is a close analog to how a Universal Open edX Mobile App would operate. Note Moodle has some additional responsibilities for Moodle Cloud instances (hosted by Moodle).

MyChart: Not in the education space, but a very similar model: self-hosted sites that utilize a single app.

Lessons from Moodle

Moodle has two branches: Moodle self-hosted and MoodleCloud. MoodleCloud is a SaaS offering, Moodle self-hosted is similar to the Open edX platform.

The Moodle app allows any instance, whether self-hosted or through MoodleCloud to use the app. Moodle also has various plans for their mobile apps: Free, Premium, and Branded Moodle App. The plans go from basic access to the app (free) to increased features/ and branding.

Relevant Links

Moodle App Terms of Service https://apps.moodle.com/admin/tool/policy/view.php?versionid=3: This is for self-hosted sites using the Mobile App.

Moodle Cloud Terms of Service https://moodlecloud.com/app/terms

Moodle Privacy https://docs.moodle.org/501/en/Privacy_laws_and_Moodle

Moodle data protection https://moodle.com/news/moodles-data-protection-pledge-commitment

Note: there’s no TOS for Moodle self-hosting besides GNU License.

Relevant Excerpts:

From Moodle App TOS.

11. You must not, and you must ensure each User does not, post, upload, publish, submit or transmit any content that:

1. infringes, misappropriates or violates a third party’s patent, copyright, trademark, trade secret, moral rights or other intellectual property rights, or rights of publicity or privacy;

2. is fraudulent, false, misleading or deceptive;

3. denigrates us, the Website, the Portal, any Moodle App Plans Sites or Moodle App Plans Services;

4. violates, or encourages any conduct that would violate, any applicable law or regulation or would give rise to civil liability;

5. is defamatory, obscene, pornographic, vulgar, offensive, promotes discrimination, bigotry, racism, hatred, harassment or harm against any individual or group;

6. is violent or threatening or promotes violence or actions that are threatening to any other person; or

7. promotes illegal or harmful activities or substances.

On copyrighted content (from MoodleCloud TOS).

10. User Obligations. 2.f

You are responsible for obtaining any consents, licences, permits and permissions from other parties as required for the MoodleCloud Services to be provided including content within Your MoodleCloud Site, at Your cost, and for providing Us with the necessary consents, licences and permissions upon request;