PART 1

Customer/User Job-to-be-Done or Problem

As a Skillabi User, I want to ensure that the integrity of my curricular information in Skillabi is intact and can be reverted backed-up giving the option to revert back to in the event of a mistake so that we can experiment and use Skillabi without fear of losing information over time as edits are made.

As a Skillabi User, I want to be able to see changes in my curriculum and skills over time as updates are made for new catalog years in order to get a picture of how my alignment and skills have changed with the use of Skillabi and other curriculum review methods. 

...

• Customers would have the confidence to dive in and extend access to Skillabi to more users with the knowledge that the initial state of curricular content is saved, backed-up and able to be reverted to. This opens up more avenues to use and get value from Skillabi without the fear of causing data problems down the road.

• Customers would be able to see when changes were made, how often they have been made and who made the changes in order to effectively manage Skillabi contentview skill changes across catalog years/versions in order to better understand the impact of their efforts to align offerings with better outcomes for students.

• Unlocks the ability to have a have  “risk free” space workspaces to experiment and make changes in Skillabi while retaining a record of the original dataset. 

• Allows customers to easily see “old” older versions of catalog content and potentially compare it against newer versionsand add new catalogs when they are released instead of trying to combine old and new content in a single space.

Value to Lightcast

• Reduce the risk of losing customer data by protecting the original version and allowing us to easily revert if an error were to occur.

• Allows us to more easily track changes and efficiently refresh customer content annually.

• Allows us to easily identify where and when issues occurred with customer data delivery to find and correct the causehave a data structure that more closely resembles that of our customers in order to potentially better connect with their information and systems.

Target User Role/Client/Client Category

This feature is being built for Skillabi admins to have confidence in data integrity and to be able to structure updates to information over time. Also supports all other institutional Skillabi users by giving them more freedom to experiment and make changes without impacting their curriculum data.

Delivery Mechanism

This feature will be delivered in the Skillabi interface. 

Success Criteria & Metrics

Definition of Done:

• Visibility into the history of changes made (who, when, what changes were made)Catalogs are created and live in Skillabi as a sor of curriculum set that other curricular units fall under.

  • These catalogs can be created, edited, and viewed by users. Each one will act almost like a separate, but connected Skillabi site.

  • There will be “main” and “sandbox” types of catalog

• Ability to revert edited curriculum back to previous changes to the “main” catalog version, or “push” new and approved changes to the “main” version

• Show progress over time in terms of skill gap (market alignment) change between catalog versions

Dependency: database changes, goal to get full postgres transition done by end of Q1 (end of March). need Need to wrap this up before starting beginning to build data versioning. Maybe start data versioning in PI3 Success metrics (guesstimates for now):

Success Metrics*:

• North Star Input: Average Users per Customer Account

  • Increase by 10% or more

• North Star Input: Percent of Users Logging in Regularly

  • Baseline: 45%, Increase by 5% or more.

• 20% or more of customers actively utilize this feature to create a safe space to experiment and allow users to make changes to data.

• We see an overall 15% or greater increase in user edits to courses and programs as they can now safely do so.

• Customers report a greater sense of trust in the data available in Skillabi now that it can be tracked and saved over time.We see an increase in account engagement with our core features (Market Alignment) due to the reduced barriers of being responsible for data integrity

*This will likely have a slower impact than other features due to its function. Would expect to see these changes over approximately 6 months.

Aspects that are out of scope (of this phase)

Saving and making every change visible and revertible akin to Google Docs may be is out of scope for this phase depending on engineering input. In a future epic we may return to the idea of more robust versioning and controls for individual courses and programs.

PART 2

Solution Description

***WIP

...

Solution: Set up curriculum sets to see version history - not that tough. Would have different curriculum sets. Flexible API. Similar to how we do group types. Within the set, could see the history of versions

...

Would also need to think about the interface on front-end

...

Restoring versions would be more complicated. Would be a fairly complicated change to API to do this so that we can restore data - need to do some research

...

We’d want to do this at the course level. Which courses are associated with a group?

...

Would also need to think about the interface on front-end

...

To bring all of these concepts together, this epic will be focused around the creation of and structuring our database to fit the concept of catalogs:

• Catalogs will exist as a sort of set of curriculum. Courses and Programs will all fall under specific catalogs just like they do in the large majority of our customers' institutions.

  • This will help conceptually structure content for our users and will be flexible enough to create additional “catalogs” per department or other denomination. This allows for segregated workspaces for groups of users who do not want the distraction of the entire curriculum.

• When viewing a particular catalog, Skillabi will function as normal. All of the existing features and functions of a Skillabi site will be there, but now those would be falling under a particular catalog.

• There will be a dashboard to view and switch between catalogs

• There will be an “active” catalog set that users are defaulted to upon logging in. This will remove the necessity to interact with this feature if not desired.

• There will be two types of catalog. Main and Sandbox

  • All users can edit and experiment in sandbox catalogs, while only Admins can edit main version catalogs.

  • This allows for all curriculum information to be effectively backed-up

• All content can be copied or overwritten from one catalog to another. This allows users to either revert changes in a sandbox back to the original version, or push changes to the main catalog.

  • Only administrators will be able to push changes up if needed. 

Early UX (wireframes or mockups)

<FigmaLink>Initial Mock-ups for Catalogs Dashboard

Non-Functional Attributes & Usage Projections

Consider design to clearly communicate data structures.

Expect to see 20% or more of customers actively using this feature in the first 6 months.

Will implement passive utilization of this feature for 100% of customers.

Dependencies

Cannot implement back-end changes until the Skillabi database is finished being switched over from MongoDB to PostgreSQL.

...

• Train CDOT team on how to separate and upload learning outcomes for courses when processing customer curriculumcurriculum materials to specific catalogs. 

• Train Education Success on the new feature and explain how to present this to customers.

• Pendo Announcement in Skillabi

Risks

• Reports may not include the right information, or correct information to provide value. This could create negative impressions of the tool at an institution.This feature does add some level of complexity and may confuse some users.

• The concept of catalogs fits with the bulk of our users and our target audience, but secondary audiences like publishers and other partnerships accounts may not fit nicely with their content.

• This will interact with SkillsMatch. We need to make sure that is addressed during build out.

Open Questions

• How can we ensure that exporting the right information is easy and obviouswill SkillsMatch point at the correct Catalog?

• How can we identify the right kinds of information to display in the report and make sure it can be easily parsed by readerswe prevent too much database bloat as we scale?

...

Complete with Engineering Teams

...