Marco asked me what usage we make of mobile for clients, if any currently or planned - I don’t remember recent mentions of mobile on our projects, so checking with everyone.
Marco would like to discuss:
thoughts on open edx’s mobile strategy, how we can get broader adoption for the mobile apps, and whether we should push in particular on provider-built apps for all their customers or skip this focus and shift to a single Open edX mobile app people could opt into using (ex: Canvas / Moodle), or some hybrid version of this.
@antoviaque Since the new mobile apps have come out, we’ve built one set of them for a client and are building another set now.
The new mobile apps are certainly easier to work with overall than their predecessors and are easier to adapt, in my opinion, from what I’ve seen so far.
On the topic of strategy, I want to bring an example from something I’ve experienced here in the states-- from a closed source app that I believe is using a strategy we could steal.
MyChart is an app used by medical providers here. If you download the app directly, you are asked which provider you use and are able to log in once you’ve selected the provider. The experience is provided in a default theme with maybe a logo or two changed and you’re good to go.
We might not be able to have a ‘global provider’ list of most common publicly accessible providers. But maybe we do, possibly maintained by Axim with the option to manually input the target group you want to log into somehow.
Anyhow, when using the normal ‘MyChart’ app you can log into multiple providers and switch between them. This works well and provides a fairly consistent experience without each team needing to maintain their own app.
HOWEVER, MyChart ALSO provides provider-specific custom builds for the providers that decide they want them. This might be because they’re using some special feature build or because they want more heavy customization of the theme, or just to streamline the process. In my experience I’ve been able to use both the provider-specific build and the general build to do everything I care about.
I think this strategy is likely the smart one here-- make it easy to create your own branded, single-instance build, while making a default, universally available one for any team to use without having to maintain a separate app with the relevant app stores.
One, yes, since it’s published, and thus is public info. The other is also probably OK but seeing as we haven’t actually released it I don’t 100% know if we’re at liberty to say so I’ll reserve.
The one we published was the YAM education app. This client came to us primarily to do an app build for him, and was the first client we used the new app with.
Thanks for the detail on this! I’ll be sure to take a look at the YAM education app you shared above as an example of an app / customization on the new code - very cool to see live! Custom app builds make sense as an ongoing opportunity and it is great to hear the new app has been easier to develop on.
Separately, a current concern is the low adoption rate of the mobile apps, driven we suspect by costs to have mobile be an low cost option for platform adopters. The MyChart example above is very much aligned with our thinking, and it sounds like they have both custom apps and a more general provider app as well. Canvas has much more of a centralized app model for its customers by comparison.
Ecosystem App Path:
An Axim hosted Open edX mobile app is something we could consider but has lots of questions to resolve regarding support routing, legal details, what is listed and how, etc. My concern with this path is centralized reliance on Axim for a working mobile app at the network level which requires dedicated investment / support. The upside is that if we solve these tougher network challenges it would be a compelling way for open edx sites to opt into a model that can help aggregate courses / help learners find courses or learning sites that opt into this Open edX app build. You could even envision shared credentials / etc across multiple learning sites being incorporated into this approach.
Provider App Path
Originally we had suspected that open edx providers having at least 1 provider mobile build for iOS and Android available for low / no cost to hosted instance clients would be a helpful way to expand access to the mobile apps, under the assumption that customers new to the platform would be increasingly convinced to try the platform if it also came with mobile learning app options. The higher cost custom mobile apps would be increasingly (hopefully) an upsell option customers select but otherwise it distributes the learning, maintenance, and management of these mobile apps to more groups in the ecosystem than the ecosystem path above. This path only works if providers and their customers see real value in this path since it does require some investment to make it work.
Outside of this decision outlined above for path to pursue, if there are other mobile app barriers for clients you are aware of let me know and we can add to roadmap. (For example the lack of i18n in the new mobile apps I suspect will be an issue soon!)
@marcoatschema The other main barrier that we’ve had so far is that both of our clients have needed SSO to their own provider, not one natively supported. This has meant using OAuth with their web view. There’s a ticket about this here.