Page tree
Skip to end of metadata
Go to start of metadata

Introduction

This document collects together my thoughts on the current LMS front end architecture and how it can be moved forward.

Current State

  • Responsive design
    • A lot of the UI will need to be rewritten to support a responsive design
    • Asset management (images, videos) need a strategy to support multiple presentation sizes while considering load/performance - BT
    • Most UI elements are defined in fixed pixels rather than in a flexible system - BT
    • It seems a good time to rethink how the templates are managed (inheritance and file structure-wise)
  • Performance issues
    • LMS pages are very large as they include templates and JavaScript inline
    • Production-level/compiled CSS is redundant, bloated (including overrides for poorly scoped universal/basic styling) - BT
    • Need to make more of the content cacheable so that it doesn't get downloaded over and over
    • Should minify our JavaScript files (both edX and third party) to reduce the size and number of files that are downloaded
    • Should parse our compiled CSS to remove unused/overcomplicated rules (both for file size and for UI element rendering performance) - BT
    • Files should be cached based upon a hash of their contents so that they don't get reloaded every time we release
    • the common/ directory structure Sass/CSS and its use across applications are very unclear and perhaps not beneficial - BT
  • XModules
    • A large percentage of what students see is provided through xmodules
    • The plan should be to move these to xblocks but when
    • Sass/CSS for xmodules is very poorly architected and is difficult to maintain - BT
  • XBlocks
    • XBlocks have large payloads as their JavaScript is mostly inlined
    • XBlocks need support for dependency management
    • XBlocks would benefit from being written using Backbone
    • XBlocks aren't editable in Studio without custom hacks
    • XBlocks' styling is not scoped well - can affect overall LMS UI - BT
    • An XBlock has no base set of UI elements it can use to start from - reinventing the wheel, and often poorly, each time - BT
  • Adding new features
    • Only two mechanisms are platform changes or XBlocks
    • Currently an XBlock is limited in the ways in which it can enhance the platform
      • It can provide unit-level components for students
      • It can provide custom editing experiences in Studio (with limitations)
      • No mechanism to provide admin capabilities for managing services (e.g. ORA)
    • Ideally new features would be implemented as plugins to the platform
      • They should live in their own repo
  • Theming
    • There is no standard defined for building new features in a way that they can be themed
    • Assets, basic UI styling, and levels of extension are not architected well for theming purposes - BT
    • Markup/UI classification patterns are not architected well for theming purposes - BT
    • Adding additional or alternative views/pages is cumbersome at best and not possible at worst - BT
  • Testing
    • Almost no JavaScript unit test coverage in LMS because the code is too tangled
    • Bok Choy can be used for acceptance tests, but can't handle unit testing

Proposals

  • Use RequireJS for dependency management
    • Has proved itself in the Studio code base
    • Makes unit testing possible as each file is self contained
    • Allows files to load dependencies as needed
    • Incremental adoption possible using shims to provide non-RequireJS features
  • Use Backbone for dynamically updating UI
    • Has also proved itself in Studio
  • Discontinue usage of CoffeeScript
    • Incremental switch over as a big bang is too costly
    • New features should be developed in JavaScript
  • Adopt and/or develop a common component library
    • Common components helps greatly with theming as they will work out of the box
    • New UI can be built more quickly by reusing existing components
    • Many benefits to sharing JavaScript components with Studio that is further ahead
    • Analytics team is using Bootstrap (for prototyping purposes) which we might want to consider
  • Improve JavaScript code coverage
    • As code is converted to RequireJS/Backbone, new Jasmine tests can be implemented
  • Improve the pipeline
  • Features should be independently deployable
    • XBlock is the main mechanism for plugging in new capabilities
    • Need to extend XBlock so that it can extend different parts of LMS and Studio. Examples include:
    • Open question: Are there other front end plugin points that cannot be satisfied by extending xblock?
  • Longer term: support some of the same improvements in XBlock
    • Provide an AMD (RequireJS-style) interface for managing dependencies (see Why AMD?)
    • Implement XBlocks using Backbone and templates'
    • Determine how XBlocks interact with CSS, theming etc
    • Provide a pipeline so that xblocks can be run efficiently
    • Note: need to convert legacy xmodules to xblocks to see the full value

 

  • No labels

11 Comments

  1. I agree strongly with a common component library, that can be shared between Studio and LMS. We will need to figure out the CSS aspect though to make things truly work "out of the box".

  2. I agree with switching to RequireJS, but I think we need to handle the minification and caching issues at the same time. Perhaps extensive use of shims would allow us to work through issues upfront.

    1. I think we need to look at the user impact of any of the optimization options. Ultimately, I think we want our page load speed to be fast. The RequireJS method used in Studio requires the user to re-download all assets after each deploy (pain-point for China). On the other hand, since we merge all our css and js into one file, each deploy usually does have changes in those files... 

      1. Thanks Christina Roberts and Frances Botsford. I agree with both of you that the first thing we should do is work out how to build a pipeline that minimizes file size and that caches appropriately. From talking to DB, this shouldn't be a problem if we use RequireJS Optimizer (http://requirejs.org/docs/optimization.html) which he'd always planned to do for Studio but just didn't get to.

      2. On the CSS side of optimization there are a lot of improvements we can make, including:

        • Adding CSS optimization tools to our pipeline (https://github.com/giakki/uncsshttp://www.minifycss.com/)
        • Refactoring base-level styling within the LMS that we constantly need to override/fight (adding redundant lines to our file size)
        • Abstracting out app-wide styling vs. specific view/experience styling (including refactoring our pipeline's use of /common/ assets) - as Frances Botsford has mentioned in the past

        With images and other assets, we'd also want to follow a lot of the good advice here on selecting the right format and optimizing how we store and save these files - https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/image-optimization.

         

        1. Images can ratchet up the overall size of assets required to render a given page very quickly.  I agree with Brian that we should carefully consider the guidelines listed in the link he provided.  I was recently involved in testing support for the <picture> and <source> elements and ```srcset``` attribute in my involvement at W3C and native support is in nightly versions of Chrome and Firefox.  Support for ```srcset``` on <img> elements is supported in Webkit nightly.  As we make our framework responsive, we should also make our images responsive.  Non-supporting evergreen browsers will ignore the unsupported elements and attributes.  A good polyfill is available here: https://scottjehl.github.io/picturefill/

          My test file is here if anyone is interested (again, must be using a supporting browser): http://cptvitamin.github.io/implementation-tests/picture.html

  3. This is a great list of thoughts. I've added some initial thoughts (initialed "BT") with UI design, HTML/CSS, and my previous experiences in mind. I have a few more topics to cover and will add them shortly. I imagine Frances Botsford will chime in here too.

    Thanks for the effort and sharing. Looking forward to figuring out how to clean things up!

  4. RE: XBlocks, I would recommend at least considering/exploring the use of Polymer (http://www.polymer-project.org/) and web components to solve the problems inherent in current XBlock rendering (in lieu of Backbone).  I say this because I think it can solve many more current and future problems with rendering XBlocks on the front end.  It would also allow XBlock creators a greater ability to define default visual styles and behaviors and authors more flexibility in overriding or extending those defaults.

    Would love to discuss further.

    1. Hey Mark. I'd also love to discuss this further with you. I just did a little reading up on Polymer and it sounds very intriguing.

      One question: does it provide any isolation between components? We are suffering from xblocks interacting badly with each other (needing different versions of JQuery, for example), and it would be great to find a solution to that problem.

      1. Each web component has complete CSS and JS encapsulation, so if different libraries are required to run on a single page, they should be able to run concurrently.  This wouldn't be very efficient (wink) but we have to pick our battles I guess.

  5. Just wanted to point out this Front End Discovery page created a while ago - might be worthwhile to compare notes (I know our team has some related requests listed there) - https://edx-wiki.atlassian.net/wiki/display/AN/Front-end+Architecture+Discovery