In Attendance

Stanford

• Steven Burch

• Giulio Gratta

Appsembler

• John Baldwin

OpenCraft

• Braden MacDonald

eduNEXT

• Felipe Montoya

edX

• Nimisha Asthagiri

• David Joy

User stories

Stanford

• Look and feel

• Feature development

  • Hiding, replacing, adding features

  • Adding disclamers

  • Adding HTML to sidebar, header, footer

• Have their own instances, each individually branded.

• Three separate prod deployments:

  • On campus instance

  • MOOC offering

  • Med school instance

  • Always the same platform code

  • Customizations are feature flagged

  • Use theming to hide SSO accounts tab

• Can't use the word "student" in some instances, for instance.

• SSO exclusively, no unlinking accounts

• Fork the platform

• One repo for all themes

• Fork of pattern libraries

• Ginko

Appsembler

• Customers: tech companies and education resellers

• Multi-tenancy

• Enterprise customers with standalone instances.

• Look and feel

• Need look and feel consistency with external environments

• Fork of platform, different branches for different needs (multi-tenancy vs. Enterprise)

• Enterprise share same branch and use feature flags

• Upgrades are horrible pain.

• Want plugin architecture, been thinking about their own.

• Figures

  • Need customization on frontend

  • Need custom cards/UI elements

  • Brand new code

• Email formatting is hard

OpenCraft

• Does not fork platform.

• Customizations done as theming, plugins, or features which get contributed back.

  • Limits their ability to do detailed theming, have to say 'no' sometimes.

  • Template overrides

  • CSS

  • Use translation files to change phrases.

• Dozens of instances, very easy to upgrade/maintain.

• Want better theming, still without customization/forking.

• Want plugin architecture

• No multi-tenancy

• Want real-time theming

  • Client uploads logo, sees it immediately for instance.

• Email formatting is hard

  • Nimisha says: Maybe better in Ironwood?

eduNEXT

• Three types of instances

  • Customized instances for people in their own data centers/AWS accounts

    • Big customers, very opinionated

    • Code lives in fork.

    • Try to use theming if they can, otherwise change code.

  • - Multi-tenant instance with 3000 sites

    • Use theming to make them all look different

    • Microsites used to change feature flags per client, add custom CSS, etc.

    • Site configurations change themplate path and swap themes for each customer.

  • Consulting for large projects. Super customized. Example: replace ecommerce with something else.

• Different types in different forks.

• 60 features added.

• Don't merge back.

• Every few months, take what's on Hawthorn master and build their features on top of it.

  • Extensive doc on how to do this.

General comments

• OEP process: be more communicative

• Why react? Wide adoption, Facebook adopted React, not bleeding edge, but solid and meets business needs.

• Need to communicate timelines for deprecation. Juniper? Later? Need to know far enough in advance that it's not a surprise and there's time to update/adopt it.

• Feature flags for each of the micro-frontends is a good thing.

• Don't want to rewrite themes with every named release.

• Pattern library: just kill it! Put styling somewhere else.

• Start getting down to brass tacks with practical proposals for customization - move on from requirements gathering.

• If devstack looked different than edx.org, many upgrade problems would be fixed.

• "Make the common case fast, make the uncommon case possible."

• Page that is a particular theming pain point? Dashboard.