Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OEP-64 Mobile Application Codebase Modernization #496

Merged
merged 1 commit into from
Aug 23, 2023
Merged

OEP-64 Mobile Application Codebase Modernization #496

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
99 changes: 99 additions & 0 deletions ...itectural-decisions/oep-0064-arch-mobile-application-codebase-modernization.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,99 @@
OEP-64: Mobile App Codebase Modernization
#########################################

.. list-table::
:widths: 25 75

* - OEP
- :doc:`OEP-64 <oep-0064-arch-mobile-application-codebase-modernization>`
* - Title
- Mobile Application Codebase Modernization
* - Last Modified
- 2023-06-09
* - Authors
-
* Marco Morales <[email protected]>
* Volodymyr Chekyrta <[email protected]>
* - Arbiter
- Ed Zarecor <[email protected]>
* - Status
- Under Review
marcotuts marked this conversation as resolved.
Show resolved Hide resolved
* - Type
- Architecture Decision
* - Created
- 2023-06-09
* - Review Period
- 2023-06-15 - 2023-08-01
marcotuts marked this conversation as resolved.
Show resolved Hide resolved
* - References
- `Related Funded Contribution <https://openedx.atlassian.net/wiki/spaces/COMM/pages/3663429666/FC-0011+-+Mobile+Product+Strategy+Backlog+Development>`_

.. contents::
:local:
:depth: 1

Abstract
********

As part of the discovery effort done for a funded contribution (FC-0011) we are recommending that the Open edX platform adopt newly built iOS and Android applications as the new default mobile applications for the platform moving forward, starting with the Quince release. These new applications are rebuilt with Model View ViewModel (MVVM) architectural patterns and are fully rebuilt in languages native to the mobile platforms (Swift and Kotlin, respectively). These new code bases should facilitate faster development cycles, improved pluggability and community contribution rates. As of July 2023, not all functionality is 100% identical to the existing mobile applications, but efforts are underway to improve pluggability and close common community requirements for the mobile experience.

Motivation
**********

The motivation for this change is to drive adoption, contribution, and improvement of the Open edX platform mobile experiences. The existing mobile applications were authored in 2015 and are not broadly used across the Open edX ecosystem today. Improvements to architectural patterns, development languages, and mobile operating systems have transformed mobile development in ways that make it difficult for our existing code bases to adopt quickly. The Raccoon Gang mobile team rebuilt and open sourced new ios and android applications that form a strong architectural basis on which to continue community development of the mobile applications.

A robust mobile experience makes learning opportunities more accessible whether that is for learners who don't have ready access to personal computers, or need to fit learning into their schedules around work and family commitments.


Specification
*************

The existing mobile repositories are maintained by edX / 2U and can be accessed here:

* https://github.com/openedx/edx-app-ios
* https://github.com/openedx/edx-app-android

* Support for the existing mobile applications will continue through the Redwood release. Starting with the Quince release, we will designate the new repositories as the default Open edX mobile applications to encourage adoption and use of the new applications for community team members.
* Once available, we will link to documentation within the new repositories to describe transition options for community members migrating from existing builds of the older codebases.
* After the publication of the Quince release we will move the original repositories or the openedx-unsupported github organization to help make clear that these are no longer the default mobile application builds moving forward. A corresponding DEPR ticket will be linked to this OEP once it exists.

The new mobile repositories are maintained by Raccoon Gang and can be accessed here:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marcotuts or @e0d, can you review the formatting of this section? I would suggest a fix ,but I'm not sure if this is meant to be one bullet list or multiple.

Here's how it currently renders: https://open-edx-proposals--496.org.readthedocs.build/en/496/architectural-decisions/oep-0064-arch-mobile-application-codebase-modernization.html

image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for flagging Kyle, I didn't notice this so at some point I must have broken this. I can open a new PR for formatting fixes to this.

* https://github.com/raccoongang/educationx-app-ios
* https://github.com/raccoongang/educationx-app-android
* The new repositories will be migrated to the ``openedx`` github organization under the names ``openedx-app-ios`` and ``openedx-app-android``.
* The new repositories will be maintained in accordance with OEP-55.
* Relevant funded contributions and projects relation to the new mobile repositories will be linked from their main project README as a way to help community members find ongoing and future efforts.
* In support of a consistent platform-wide branding interface, the mobile experiences will strive to identify opportunities to consume and extend the Paragon design system, helping to ensure consistent and maintainable UX across channels (i.e., mobile, web).


Rationale
*********

Expanded access and opportunities for learners around the globe means meeting learners where they are, and for many people that means on their only digital device, their phone. Furthermore, enabling learners to continue to learn on their desktop or laptop computers in addition to a full featured mobile experience allows us to support full day learning workflows for those with multiple devices.

Similar to the way the edx-platform has undergone a modernization process over the past few years with updated build processes, micro services, micro frontends, design system tools and more, the mobile experiences will benefit from a modern architecture, being written in the latest development language tools, and set up for increased pluggability and contribution as well.
Copy link
Member

@adamstankiewicz adamstankiewicz Jul 24, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[inform/question] Related to the mention of design system tools, just wanted to cross-link to this Paragon issue about mobile app branding as it relates to Paragon design tokens.

That is, there may be an opportunity to treat the Paragon design system as the "source of truth" for style properties like colors, typography, etc. across both web and mobile native platforms, as is the longer term vision for the Paragon design system.

The Paragon Working Group is currently working towards migrating the Open edX web-based experiences (MFEs) to use design tokens and CSS variables. I don't think it'd be a unreasonable lift to get Paragon design tokens transformed into iOS/Android compatible output that can be consumed by mobile apps. That way, when a style property in the design system changes, its update can more readily propagate across cross-platform with less maintenance required.

Do you think it's worth expanding on how design system tools (e.g., design tokens) could play a role here, or is that too "in the weeds" for the purpose of this OEP?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question I think adding that detail might be in the weeds for the scope of the OEP but the issue in paragon that Ed created is a space we can continue the conversation toward the goal you described of a single source of truth for that kind of design meta.

Others can chime in if they feel like additional detail should be added. Thanks for reviewing!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, sounds good!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adamstankiewicz @marcotuts @volodymyr.chekyrta Non-blocking, but even as someone who is mostly out of the loop on MFEs and the mobile apps, I have the impression that Open edX's move towards Paragon design tokens is pivotal in terms of re-establishing a consistent branding interface for the project. Confusion around theming & branding is consistently identified as one of operators' major pain points ever since we started phasing out comprehensive theming.

What do you folks think of a high-level statement in the OEP stating the design tokens (or something like it) will be supported? For example:

In support of a consistent platform-wide branding interface, the experiences will implement branding via Paragon design tokens once tooling for the tokens reaches maturity.

or, to be more general:

The experiences will strive to support a branding interface consistent with other Open edX frontend applications based on recommendations from the Frontend and Paragon Working Groups.

Copy link
Member

@adamstankiewicz adamstankiewicz Jul 24, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Confusion around theming & branding is consistently identified as one of operators' major pain points ever since we started phasing out comprehensive theming.

@kdmccormick Definitely. I think aligning on how we communicate about Paragon could help begin to mitigate this confusion. For example, perhaps rather than saying "theme-ready" and other "theming" related messaging throughout the documentation, we could adopt "brand-ready" and "branding", as an incremental step:

"An accessible, theme-ready brand-ready, and open source design system built for learning applications."

(from docs site)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you folks think of a high-level statement in the OEP stating the design tokens (or something like it) will be supported?

@kdmccormick @marcotuts @volodymyr-chekyrta I would be in favor of including an explicit albeit brief, high-level mention of the design system (also, not blocking feedback though 😄). Perhaps a blend of your two suggestions, Kyle. E.g. something along the lines of:

In support of a consistent platform-wide branding interface, the mobile experiences will strive to identify opportunities to consume and extend the Paragon design system, helping to ensure consistent and maintainable UX across channels (i.e., mobile, web).

Copy link
Contributor Author

@marcotuts marcotuts Aug 9, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

adding in next commit / update - thank you for the thoughtful inclusion and deliberation on this point!



Reference Implementation
************************

The new mobile repositories are maintained by Raccoon Gang and can be accessed here:

* https://github.com/raccoongang/educationx-app-ios
* https://github.com/raccoongang/educationx-app-android

Rejected Alternatives
*********************

We considered exploring the development costs of incrementally improving the existing mobile applications to fully adopt new architectural patterns as well as the use of Swift and Kotlin. Efforts to use these new technologies go back many years, but it would take considerable effort for the community to support this migration. Realistically the current team at edX / 2U maintaining the repositories would have had to undertake a major development effort to achieve this transformation.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[curious/clarification] What other technologies/architectural patterns were considered beyond Swift and Kotlin?

For example, was React Native explored? While I personally don't have much experience with React Native, I believe one of its primary goals is to enable a "write one, use everywhere" approach where possible, enabling sharing of code across platforms (even between web + mobile). One might hypothesize having shared code across iOS, Android, and web could lead to having the mobile apps be more approachable/maintainable by the community, align closer to other React-based UI development in the Open edX platform (i.e., micro-frontends), etc.

More specifically, I'd be curious whether something like React Native could enable sharing of existing styles/patterns/functionality in the Paragon design system. For example, could common UI patterns across both web and mobile both live under the same Paragon design system, but ship with and get consumed via different implementations (React Native for mobile vs. React for web)? Food for thought; felt appropriate to expand a bit more on the technology choices.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi!

We did not do a deep dive into React Native in advance of this effort, but have received similar questions about this and Flutter ( https://flutter.dev/).

Currently, the belief from the team is that the benefits of native Swift + Kotlin development fit to OS purpose is preferred over the benefits of shared code bases. A number of other companies have posted articles on their adoption of React Native and subsequent decisions to switch back to native development.

As with anything there are likely happy companies and teams on boths sides of this, but we've chosen to stay on the native path for now.



Change History
**************

2023-06-09
==========

* Document created, draft PR opened
* `Pull request #496 <https://github.com/openedx/open-edx-proposals/pull/496>`_
* Updated PR to reflect the latest OEP number and the named release planned
* Updates to match conventions and other OEP feedback