simon-initiative / oli-torus Goto Github PK

Complete implementation of short answer activity.

A first step in delivery, students can view a learning page.

Revision Resolution

Delivering a learning page involves retrieving - or resolving - the correct revision of the resource for this course section. This is driven, of course, from a publication. Note: This resolution has to happen not only for the page being rendered, but for all referenced activities and for all attached objectives.

Rendering

Right now two types of top level content items exist: Structured Content and Activity References

Structured Content Rendering

A learning page should server-side render any structured content blocks that are included in the page.

To be able to render content server side, Torus will need to recursively transform the content field of a resource revision into HTML. There is relevant Torus prototype code that illustrates a compile-time safe way to build renderers.

Activity Rendering

Activity references are rendered as web components, server side. The actual rendering, of course, will take place client side. To be able to render successfully, the associated delivery script for the activity type must be included in the page. For now, including the scripts for all registered activities is feasible. Long term, though, we will want to only include scripts of activities that are present in the page.

Suggested Plan of Attack

1. Port the structured content modeling code from the prototype. This code is important not only for rendering, but also as a foundation for ingestion and version diffing.
2. Build the HTML renderer for structured content.
3. Build and test the revision resolution. This revision resolution should be as streamlined as possible, given that it needs to execute on every page render. We should strive to implement this in as few queries as possible to the database.
4. Build out the controller and template - and wire in the activity rendering.

This should also include the creation of the multiple choice activity

This is the first step in gradepassback support. We will follow this up with export to CSV and live, incremental passback

Refine and integrate prototype editor code to include:

• Core editor component as a standalone UI component
• Hover toolbar support for inline formatting
• Fixed toolbar support for block insertion
• One representative element editor that demonstrates approach to element editor impl including attribute editing

This involves DataShop integration with streaming of activity information directly to DataShop and retrieval and display of curve information after DataShop makes that information available.

Workflow for adding collaborators is:

1. User A creates an account and creates a project.
2. User B creates an account.
3. User A adds User B as a collaborator to their project from the "Team" section of the settings / overview.
4. Objective: User B receives an email indicated that they have been added to the project

In a single top-level list only, an author has the ability to create new learning objectives and delete existing ones.

There are follow on issues for editing an existing learning objective and for creating a hierarchy of objectives.

Complete the remaining tasks in LTI 1.3 launch work including:

• Integrate LTI 1.3 launch into existing torus delivery
• Remove Canvas API specific integrations
• Transition hard coded example keys to jwk endpoint with runtime configurable key
• Convert nonce caching from agent to database storage for multi-node compatibility
  We might be able to restore the nonce table from LTI 1.1 and simply reuse that implementation
• Cache LTI 1.3 launch params using a unique launch id as a key stored in cookie, so that launch information can be accessed on other pages (alternative to session based) ⟹ fixes cookie too large issue
  Use database to store this information for now, no cleanup task needed because we will store as a permanent record of a all launches
• Re-enable ensure_context_id_matches after lti_params caching is implemented
• Change embeds_many back to many_to_many (or one_to_many), update all roles on every launch
• Add interface for admins to create and manage LTI 1.3 registrations and deployments, remove Institutions section from user accounts
• Cleanup Oli.Lti_1p3.KeyGenerator.generate_key_pair implementation and change to return a tuple for cleaner interface
• Update user model to more accurately resemble OIDC standard values
• Add/update unit tests for both LTI 1.3 library and torus LTI 1.3 launch Defer until LTI 1.3 Library fork
• Add/update documentation for both LTI 1.3 library and torus LTI 1.3 public functions Defer until LTI 1.3 Library fork
• Find and fix all TODO’s
• Cleanup torus LTI 1.3 test endpoint
• Torus documentation for setting up LTI 1.3 integration

Basic publication involves the publishing of all outstanding edits and all current course sections immediately having the new publication applied

We need to develop a solid first version of the relational model.

• Two team members map out an ER diagram, pulling forward existing OLI schemas where possible
• Document design in some ER diagramming tool or another drawing tool
• Review model with dev team
• Create Ecto schemas

An author has the ability to create a new project.

Furthers the infrastructure to add in outcome rollup and grade capture, disabling of hints, etc.

For a course section already created and associated with an LTI context, if new instructors LTI launch with the same LTI context Torus must recognize these users as additional instructors and associate them with the existing course section.

This work involves:

1. Porting over from Echo the relevant media library UI code
2. Creating a new media library backend that stores media items in cloud storage in a way that they end up being resolvable as https URLs from Torus front end.
3. It also has to account for browsing. The media library needs to be able to access and display all media library items for a project in an efficient manner. As a last resort this should involve the Torus database. We should try using cloud storage APIs for this.
4. Must account for determining references. For any given media item Torus should be able to inform the user where in the project that media item is being used.

Authors can see insights from the formative and summative results of students working through course sections.

Student Experience

A student LTI launching into a course should land on a page that displays the top-level view of the course contents, including links to the individual pages.

This top-level view should include a page numbering.

Accessibility

This impl should be accessible. This task should include a deep dive on accessibility and a relay of information found to the rest of the team.

Mobile First

Ensure that this impl is mobile first.

Add in basic ordered and unordered list support

While the infrastructure supports a hierarchy of arbitrary depth, the UI should fix the depth to two levels total.

Taking and retrying formative activities requires the backend infrastructure of activity attempts, hints, and evaluation to be built out.

The "test" mode allows the author to interact with and "test" out the multiple choice activity that they have configured.

In a formative context, they should be able to answer the question and see feedback, request hints, and reset the question and try again. None of the interactions are logged or recorded in any way, of course.

Evaluation

Eventually, activity types that we will implement will utilize server evaluation that we will not want to have to replicate client-side (all the variants of numeric input evaluation, for instance). So given that we know that we will need to implement some of test mode with a reliance on server side eval, lets take the approach that we implement all activities with server side eval

Hint request

We need an approach for requesting hints in a way that doesn't depend on server state. In other words, since we cannot log any activity from test mode, we cannot leverage the state of an activity attempt to determine which hint to retrieve on a given hint request. Perhaps we build out a hint request infrastructure that simply lets the client request a hint by hint ordinal position - thus pushing the responsibility onto the client.

A course section for a given project can be created by a user launching in as an instructor via LTI

A key requirement here is that the reordering is accessible, thus it cannot be strictly implemented via drag and drop.

Author can edit the wording.

An export feature exists to dump the gradebook as a CSV file. This is necessary as a workaround if any LMS does not correctly support LTI grade passback APIs

Reordering is follow on to this.

Publishing should involve a check for the following:

• Images / Video without Alt text
• Broken hyperlinks
• Activities with no attached skills

This task is to build out the first production version of the multiple choice activity editor. A stub impl is in place, we need to:

1. Define the MC model schema - declaring its type and structure. The stem, choices, feedback and hints all need to be of type structured content.
2. Implement an editor that allows editing of stem, choices, feedback and hint definition, according to the UI prototype. We need to think thru the best way for an author to be able to declare the correct answer. If we fix the first choice as "Correct answer" and the others as "Distractors" it may make it challenging for an author to be able to swap a correct answer for a distractor (they would be forced to do some type of two step copy and paste)

The pages that can be selected should be scoped to only those objectives that are present in the parent module.

Automated backup and manually triggered restore capabilities for the postgres database

Build a prototype in Balsalmiq and get feedback from Norm, Judy, Kim, Hal, Erin.

This has to be accessible. It cannot simply be drag and drop.

Following on work for reordering and for assessments.

Integrate the ongoing work to add LTI launch support

When a new student LTI launches with a known context id we capture that account launch as a user and associate it with the course section.

Torus directs the student to the landing page (table of contents of material?) for the course material pertaining to that section.

For existing students launching into a course section Torus should display the last resource that the student had visited.

Selective publication involves an author selecting to publish only a portion of the draft resources in a project.

To complete the core editor component we still need:

• header support
• to fix the handling of list termination when lists are in a table
• normalization tweak to insert paragraphs after voids inside tables

If a student should happen to LTI launch with a context that Torus does not recognize we simply must give them a warning message that this course has not yet been set up or initialized by their instructor.

An author can edit a page.

This is for basic page editing - content sections only and the ability to edit the title of the page.

This is a test.

Build out the skeleton of the web app. This is being done to set the stage for next sprint when we can start implementing package creation, overview, and learning objectives views.

Major pieces from the UX prototype to include are:

• Core layout
• Left hand navigation panel
• Customization of bootstrap to look and feel like the prototype

Final piece of gradepassback is Torus updating the LMS gradebook as soon as a student completes a summative assessment.