I’m excited to be posting another update on Catalog. To start things off, I’d like to bring you up to speed on how the Tech Stack update work is coming along. We’ve made tremendous progress over the last several months and Catalog is looking better than ever. However, digging into software can often be a bit like peeling an onion—it involves peeling back layers. As we’ve dug deeper into the Catalog codebase, we’ve identified a few additional tech stack updates that need to be made to really shore up Catalog and prepare it for the future. This means we’re extending the Tech Stack project by a couple of months before diving into new feature work. While this does add a bit more time and work to the initial scope of the Tech Stack project, you can take it as a sign that we’re fully committed to Catalog’s long-term success.
Speaking of feature work, I would also like to share our prioritized list of projects that we’ll be tackling once we wrap up the current work. However, before I jump into the priorities list (try to resist the urge to skip ahead), I wanted to spend a minute or two explaining our prioritization process. As anyone who works in software will tell you, there is always more that can be built than there are available resources and time. Given these constraints, we use several metrics to help us evaluate the priority of any given project.
First, we consider how a project or change will affect and improve user experience. We also analyze how broadly the change will be utilized. It’s helpful to think about these together. For example, there might be a feature that would be very beneficial for users if built, but might only be used by a very small portion of our users. In general, the more impactful and the more broadly useful a feature is, the higher priority it gets.
Second, we examine how technically feasible it is to build and implement. Some projects that look easy are actually quite difficult to do from an engineering standpoint. The reverse can also sometimes be true, where a feature that sounds complicated turns out to be relatively simple to build. We use the results of these evaluations to plan our projects so that we’re working as efficiently and effectively as possible.
We compile the data from each of these assessments and, looking at them together, use the information to prioritize projects. Our guiding star is to always deliver as much value to as many users as quickly as possible. Sometimes that means doing several small projects, and other times it means tackling a project that will span several months.
One last thought before sharing our prioritized list of projects: The list provided below is not a firm commitment to deliver the features listed by a certain date.
The list below outlines what is currently planned. Plans can change. As we’ve already seen, it’s possible that we’ll run into some unexpected issues in the code. Or a feature might turn out to be more complicated than we originally thought. Or a non-Catalog issue could crop up and alter this plan. For example, critical bugs in other platforms sometimes come up that require an all-hands-on-deck response or unexpected personnel changes. Of course we hope everything goes perfectly according to plan, but often that’s not the case. No matter what happens, we’ll do our best to keep you updated and adjust the plan as needed.
And now, without further ado, here is the prioritized list of features that the Catalog team will be working on:
Catalog sequence of work
Improve user defined field data on export - Currently, when analytics data is exported as a CSV file, all user defined fields data is lumped into a single column, making it difficult to interpret and use. This project will separate each field out into its own column.
Add a new “Listing Report” - This report will aggregate change data by listing, rather than by user. Admins will be able to download this data from Catalog Reports in order to more easily monitor listing activity.
Add date range filter and sub-catalog exports to reports - Admins will be able to specify a date range when running a report in Catalog. Additionally, this project will make it possible to export reports for individual sub-catalogs.
Add a new “Completions” tab to analytics - Admins will be able to view user data in analytics based upon Catalog listing completion dates rather than enrollment dates. As an added bonus, we’ll also be adding a link to view issued certificates from this tab.
Add Catalog data to Canvas Data - For anyone who isn’t familiar with Canvas Data you can read all about it here. We’re excited to bring Catalog data to the Canvas Data Portal.
Our goal is to have all of the above items completed before the end of the year. As always, things might change once we dive in. But if all goes well we’ll end 2018 with all of those on Production for your Cataloging pleasure.
Looking beyond 2018, here are the priorities to start the new year.
Add the ability to duplicate listings - Admins will be able to duplicate any listing within a sub-catalog. The newly created listing will still need to be attached to a new Canvas Course and will include all of the data from the original listing.
Add the ability to manage waitlists - Admins will be able to move users up and down on a waitlist, as well as remove users from a waitlist all together. Waitlist numbers will also display on the Listings page, making it much easier for admins to see how many people are on the waitlist for each listing at a glance.
Add certificate expiration dates - Admins will be able to create expiration dates for listing certificates. They will be able to specify either a specific date or a set number of days from the time the certificate is issued.
Add a shopping cart - This will allow shoppers to enroll in and pay for multiple listings in a single transaction.
We hope you’re as excited about this list as we are. And while we’ve given this list a lot of thought, it’s possible that items might shift or get tweaked as we make our way down.