Skip navigation
All Places > Q & A > Release Notes > Release Notes: Canvas > Blog

In 2019, Canvas teams are researching an adjustment to the Canvas release schedule focusing on two key objectives: make new features more predictable and improve the quality of Canvas code. We hope you will consider these thoughts with us and provide your feedback!

 

Release Background

Let’s start with the status quo—we know that three-week releases are fast. Canvas loves agile development because it helps our teams move faster and brings features more quickly—more and more software companies are moving to cloud-based continual deployments because of both the engineering and customer benefits. Visit any Instructure office and our teams may seem calm and content (and quiet!) working away on their computers, but if you could peer inside our network of Slack chat channels, you’d find the constant chatter among developers and QA and product teams reviewing changes, brainstorming code workflows, checking the status of outstanding tickets, and providing good-natured banter (my favorite part, really).

 

Canvas Code Quality Improvements

Our three-week releases include code deploys for predetermined features, fixed bugs, backend changes, performance updates, API modifications, platform upgrades, and other code adjustments completed by our engineering teams. All of our changes are code reviewed and tested by our Software Engineers and Software Engineers in Test to ensure it meets our (and your!) standards. These practices allow us to prepare and deliver new Canvas code in remarkably short cycles.

 

Releases and deploys don’t have to be synonymous terms—in fact, our teams would prefer that they weren’t. What if we could put all this code into smaller deploys so teams can focus better and fix bugs even faster? What if you had more time to prepare for feature updates? These are the questions we want to answer, and these results can be done without adversely affecting you as the customer.

 

Predictable Feature Changes

From the customer standpoint, we know that three-week releases include a lot of content that may not pertain to your user role. Or, you’re an admin who gets overwhelmed at the idea of training your entire institution about all the upcoming changes. We’ve been working hard to ensure our release notes give you more tools to help you be the superhero you are, and our new proposal would also give you more time to do just that—we want to ensure consistency on your side so you know exactly when a release is happening and when, without having to consult a calendar.

 

From Instructure’s side, we want to be more mindful about what changes impact your experience, not simply focusing on changes in the interface. We realize there are plenty of behind-the-scenes adjustments that may affect Canvas behavior, and to improve your experience with Canvas features, we want to improve how we release these changes to you.

 

Canvas Release Proposal

Current Release Cycle

The current release cycle includes the following 3-week structure:

  • All new code is deployed to the beta environment with the scheduled beta release (week 1)
  • Canvas release notes are published in advance of the production release (week 2)
  • All beta environment code is deployed to the production environment with the scheduled release (week 3)

 

To clarify terminology, a deploy means making code available in a specific environment; code may or may not be visible. A release represents a scheduled event when code is intended to be visible. Currently, deploys and releases are treated as the same thing.

 

Proposed Release Cycle

To be more mindful with what code we release and when, the proposed change includes a monthly feature release overarching two-week code deploys.

 

New features are defined as any changes that change user workflow for any Canvas-related product. Some new features may be managed by Canvas admins or instructors as a feature option in account and/or course settings. Other features may come from fixed bugs that require a workflow change or an interface change, or API/SIS integration adjustments. The Canvas product team can directly control these features for all products and manage when they should best be released. Feature releases would still follow the regular process of releasing to the beta environment, followed by the production environment.

 

Non-features are defined as non-customer-affecting backend changes, code for new projects, fixed bugs—basically any code that does not affect any Canvas workflows or functionality, or code that improves unintentional behaviors. Two-week deploys allow engineering teams to verify less code at one time, improve quality, and fix bugs twice as fast. Deploys still follow the regular process of deploying to the beta environment, followed by the production environment.

 

The proposed schedule is as follows:

  • Non-feature code is deployed to the beta environment and then to the production environment two weeks later; public-facing deploy notes (such as fixed bugs) are published the same day as the production deploy
  • New features are released to the beta environment a month before the production environment release to allow advanced planning
  • New feature release notes are published three weeks in advance of the production release
  • New features are released to the production environment on the first Saturday of every month; the Test environment is also refreshed to match production data

Proposed Two-Week Canvas Deploys and Monthly Release

 

Proposed Implementation Timeline

Our teams are excited to consider these changes, and we hope you are, too! But rest assured, these changes will not be implemented until all aspects have been thoroughly reviewed. And because we’re aiming to minimize disruption, we’ll make the release cycle change when we feel the change is best suited for you as well. Our approximate timeline looks like this (and is subject to change):

 

  • November 2018: Publish Canvas proposal
  • December–February 2019: Review and explore needs for engineering process changes
  • March–May 2019: Implement engineering changes
  • June/July 2019: Implement new release cycle process

 

We look forward to your feedback!

Insights: Canvas DocViewer

Posted by kmcgee Employee Jun 20, 2017

[14 June 2017 Update] For the most accurate information about DocViewer, please reference Canvas Release: Canvas DocViewer.

 

[7 June 2017 Update] Thanks for your interest in Canvas DocViewer! To best help us manage all existing feedback, please follow the feedback process explained at the end of this blog post. Please also review all existing comments to see if your concerns have already been addressed. Thank you!

As a product manager, one of the most frequent questions I am asked is: "What are you doing to improve the Crocodoc experience in Canvas?" Today I’m excited to introduce you to DocViewer, the next standard in learning management system technology.

 

What does DocViewer do?

DocViewer automatically converts common office documents into web-viewable and interactive learning experiences. This description probably sounds familiar because it describes most of the document functionality that already exists in Canvas. DocViewer will be available anywhere Canvas currently uses Box for content previews and Crocodoc for annotations. (Did you know that out of all five annotation types, point comments are used 49% of the time? Highlight and textbox annotations are the next favorites, followed by strikeout, drawing and area annotations.)

 

 

How is DocViewer different?

DocViewer is not that different from current functionality. DocViewer contains all the same document types and all the same annotation types, with some extra benefits!

  • Modern interface that looks and feels like Canvas
  • Improved performance
  • Fewer clicks

 

More features will be coming soon, including:

  • Color options
  • Persistent tool colors within an annotation session (and from session to session)
  • Free text annotations

 

Mobile Devices

For our institutions using mobile devices, annotations will continue to be supported in our mobile apps. New and improved annotation functionality will be part of our new Canvas Teacher mobile app and eventually replace the SpeedGrader app.

 

Why is Canvas switching to DocViewer?

We know SpeedGrader is one of the top used interfaces of Canvas where instructors spend a lot of time grading student submissions using annotated feedback. In turn, students can respond to their instructor’s feedback and may also be able to view additional feedback from other students using peer reviews.

 

For the past few years, we’ve recognized that relying on third-party tools can reduce the service that we can directly offer to our customers. Crocodoc has been a great product in building the interactive content experience between students and instructors in Canvas, but this product will no longer be supported by Box at the end of the year and will be replaced with a tool with reduced functionality.

 

The needs of our customers have unquestionably outgrown existing Crocodoc functionality—and that’s a good thing! Moving forward with DocViewer, we can:

  • Improve reliability of document rendering
  • Develop new features and product enhancements to drive a more functional roadmap (and adequately address annotation/document previewing feature ideas in Canvas Studio!)
  • Better address hosting needs for international regions
  • Enhance support for assistive technology users

 

DocViewer also gives us a stronger technical foundation to improve existing features, such as contribute to the next version of SpeedGrader. Implementing DocViewer functionality brings numerous future benefits to Canvas.

 

What do I need to do to prepare for DocViewer?

The best part about our new product is that no action is required to enable DocViewer. All Canvas accounts will be migrated to DocViewer by our engineering team. And all course history is coming, too—all previous documents and annotations will also be included so nobody will lose any of their work.

 

When can I use DocViewer?

Our engineering team has been working hard to ensure a seamless delivery for all customers. DocViewer will be enabled for specific environments according to the following timeline:

 

Beta Environment: Friday, June 2

  • DocViewer will apply to all courses in all beta environments ([yourschool].beta.instructure.com).
  • Official details of this new feature are included in the Canvas Beta Release Notes (2017-06-12)
  • DocViewer will have to be re-enabled each week by our engineering team, so the tools may not be be available immediately on Monday mornings.

 

Free-for-Teacher: Monday, June 5

  • DocViewer will apply to all courses in our Free-for-Teacher account (canvas.instructure.com).
  • Instructors and students can view our new document preview and annotations tools within all their courses and help us get feedback in authentic institutional settings for several weeks before making the tools available in production environments for paid accounts.

 

Production Environment: Monday, June 19, through Friday, June 23

  • DocViewer will apply to all courses in all production environments for paid accounts, including all international regions.
  • Account admins will receive an email from our Canvas Support team notifying them when DocViewer will be available in production for their specific database cluster.

 

How do I provide feedback about DocViewer?

We know that being able to test features is important to you as our customers. We encourage you to visit your beta environment on June 2 and take a look at the improved workflow of SpeedGrader.

 

Between beta and production releases, our primary concern is to provide a product that works the same way as previously used in Canvas. DocViewer has been thoroughly reviewed by our support and QA teams by replicating your coursework and grading policies. However, we know there are always going to be use cases and workflows that are unexpected, which is why we ask for your feedback and help to improve Canvas. We want to build software that makes teaching and learning as effortless as possible.

 

Here’s how to share your feedback:

  • General Feedback: Comment in this blog and/or Beta and Production Canvas release notes, which will be posted in the Release Notes space on June 12 and June 24, respectively.
  • Broken Functionality: According to your institution’s support policy, submit a support case to the Canvas Support team or through your Canvas-connected ticketing system. An example of a support case would be if your previous annotations are not showing for an assignment. We definitely want to help with that!
  • Feature Enhancements: Visit Ideas and see if an idea already exists (view the DocViewer content tag to see all related ideas). If your idea doesn’t already exist, create a new feature idea and add DocViewer as a tag.

 

For more help with feedback, we’ve created a new community document that explains exactly what we’re looking for with each type of feedback and how we use it. Check out our Canvas Community Feedback Guidelines document.

 

Thanks for your participation and enthusiasm for Canvas DocViewer!