Skip navigation
All Places > Ideas > Blog
1 2 3 Previous Next


40 posts

Hey everyone, 

We're grateful for all of the feedback we've received on Post Policies. The team has been working hard to address the most pressing issues and we've released several bug fixes over the last few weeks. And there's more work to come. To that end, we're looking for feedback on some proposed changes to Post Policy. Our goal with these changes is to make the feature more intuitive and reduce confusion. We also do not want these changes feel too disruptive to people who have already been using Post Policies. And we're anxious to get feedback on if we're heading in the right direction. 

Ok, let's get into it. 

1 - Updated Iconography 

The first proposed change is to the icons that we're using. Our goal here is to make the icons more streamlined between Gradebook and SpeedGrader, while still providing users the information that they need. 

For anyone who is unfamiliar with the new Post Policy feature, in New Gradebook you’re now able to set the policy for a course or an individual assignment that governs if grades are made available to students immediately as they are entered or if they are hidden until explicitly posted by the teacher. An assignment that has grades hidden by default has a “manual” policy, while the default behavior that makes grades available immediately to students is called an “automatic” policy. 

After grades are entered for students using an automatic post policy, they can be hidden if necessary; any new entered grades or changed grades are identified as being hidden (automatic hidden status). When using a manual policy, new entered grades or changed grades are also identified as being hidden (manual hidden status). Hidden grades must be posted before they can be made available to students.

This is what the new icon chart looks like:

Here’s a mockup of what the icons would look like in Gradebook headers:

Let me talk through the changes. First, you’ll notice that we’ve added a dot to the eye icon. We believe that most of the confusion around the eye icon has come from us trying to convey two different bits of information in a single icon. By using the eye icon to indicate the post policy for the assignment and a dot to indicate if there are grades actively being hidden, we hope to remove ambiguity and make the icon much more intuitive. The crossed out icon always indicates a “manual” post policy, while the dot will always indicate that a grade is hidden. We’ll also be updating the color of the badge in the individual cells to match the blue you see in the mockup. If an institution uses a custom color scheme, the badge will take the primary color.  

We’ve streamlined the icon between Gradebook and Speedgrader to make its meaning more consistent. In both places you’ll be able to see not only the post policy for the assignment, but also if there are grades that are ready to be posted to students. 

We’ve also changed the icon in the total column to more closely match what we’re trying to convey there, which is the total score includes at least one score that is hidden from the students. 

2 - Simplify posting to automatic assignments 

We’re proposing getting rid of the "Graded" option when posting to automatic assignments. If the assignment is set to post grades automatically, any posting that happens will have the same result if you post to everyone or graded. Since those two actions yield the same results, we can get rid of one of them to reduce any confusion.

3 - Posting to “everyone” sets policy to Automatic

When posting grades to everyone on a manual assignment, we're proposing also changing the policy for that assignment to automatic. This will get rid of the manual icon in the header and feels more in line with what users expect that action to do. We’ve added some wording to the post description to inform users that the policy will be changed:

We will also updated the confirmation alert with similar language. Post to a specific section or only to students that have been graded will not change the policy to automatic. 

We’re hopeful that these changes reduce confusion and make this feature even easier to use. Let us know what you think in the comments!


UPDATE September 4th

Wow! Thanks for all the feedback. We’re so lucky to have such a passionate community of users and we genuinely appreciate everyone taking the time to chime in. 


While most of the comments so far have focused on the icons, it does sound like we’re on the right track with #2 and #3 mentioned above. Watch the release notes to see #2 and #3 be implemented in a future release. We’re excited about these changes!

I wanted to take a minute to give a bit more context for the icon proposal that we made and talk through some of our thinking. We’re proposing 2 icons for Post Policy. 

Eye Icon

First, an “eye” icon. This will most often appear with a slash through it and will indicate when an assignment has a manual policy, which means grades and comments are hidden from students until they are explicitly made available. As has been pointed out, an eye with a slash through it conveys something not being visible. We agree. The eye is meant to convey to faculty that the grades for an assignment will not be visible to students as they are entered.

It has been suggested that a different icon be used to indicate the policy on an assignment. This is certainly a possibility. However, no matter what icon we use, there will need to be some learning for faculty initially. We feel like the slashed eye icon does convey that grades entered for that assignment will be hidden from students. 

Dot Badge

The second icon is a colored badge. As has been mentioned in the comments, this is used elsewhere in Canvas to denote when something needs the user’s attention or when something new has happened. In a similar way, the dot here is meant to let the instructor know that something is requiring their action. There are grades that are ready to be posted as soon as the faculty is ready to make them available to students. If they post all of the grades that have been entered the dot disappears, and reappears when there are more grades that need to be made available to students. The blue dot in the header will also have consistency with the individual cells in the gradebook, as well as the hidden count in the tray.

UI Help

One common suggestion has been that we provide an easy way for users who are unsure of what the icons denote to learn more beyond the user guides. We’re exploring repurposing the current keyboard shortcuts model to be a more general “help” section. We could then include a key to these icons (as well as the keyboard shortcuts) directly in the UI.


Here’s a different view of the icon table above: 

Thanks for your thoughts!




UPDATE September 9th

Hey everyone! 


Back with another update. First off, let me say one more time how grateful we are for everyone who takes the time to share their thoughts and feedback with us. We’ve been reading and discussing every single comment. 


It’s clear that using the eyeball icon to convey the policy state is confusing. It’s also clear that it will be the most intuitive to have two totally distinct and independent representations of the policy and the current visibility state of submissions. With this feedback in mind, we’ve got a new proposal that we hope will address many of your concerns. 


First, we’re proposing that we use the eyeball with a slash through it to indicate that there are graded submissions that are hidden from students. It will only appear in the gradebook header if there are grades/comments currently hidden from students for a given assignment. 


Second, we’re proposing displaying manual post policy status where muted status used to be conveyed - right below the assignment title. This will put it front and center for instructors and remove any ambiguity associated with a new icon. Additionally, this placement will feel familiar to users who used mute functionality in the past. 


Here’s an example of what 2 assignments would look like, both with manual policies. The first doesn't have any graded submissions that are currently being hidden from students, while the second one does.

We will only show the policy state if it has been set to manual. Similarly, we only show the eyeball if there are graded submissions that are hidden from students.  



Let us know what you think in the comments! 

Hello all! My name’s Daniel Nehring and I’m on the data science research team here at Instructure.  We’ve been busy behind the scenes working on improving our Nudge project that was implemented last year as a part of Canvas X.  


We are not currently seeking any more volunteers for Canvas X for the Fall Aug-Dec 2019 semester, however, I just wanted to create a quick update for the community/interested parties. 


Nudge is a prototype service that helps students effectively manage their time and coursework. Nudge currently messages students via canvas conversation messages. In this pilot students have the ability to opt-out of receiving nudges and provide feedback whether the nudge was or wasn't helpful. 


When enabled, Nudge sends the following messages to students through Canvas:

  • Upcoming Assignments: An assignment is due soon and the student hasn’t turned it in yet. Prompt them to turn it in / finish.
  • Late Assignments: An assignment due date has passed and the student has not turned it in. If the assignment has an applicable “until date”, we prompt them to submit late.
  • Positive/Generalized Nudges*: This category is more  broad, at the moment we will be sending general study habits, encouragement, and praise.   

Nudge leverages machine learning to determine if/when to send a Nudge.  This is a departure from a threshold/rules based approach. So instead of setting a rule “send message x hours before an assignment is due," our new model takes in a series of inputs and outputs either an optimal date/time or a “no nudge”.  This is significant because we do not to send too many Nudges to students, which could lead to students ignoring Nudge altogether. Conversely, we do not want the students to become reliant on the Nudging system and use it as another assignment reminder system. 


We're pretty excited about Nudge and If we have any further updates we'll posting them here in the Community page.


Privacy Notice: Canvas is committed to keeping you and your student’s personal information private. All participants will be able to opt out at any time. Any and all use of the data from this experiment will be used to make Canvas a better product and not shared publicly without express prior consent.

Recently, IMS Global announced the deprecation schedule of the LTI 1.0, 1.1, 1.2, and 2.0 specifications. Going forward, LTI Core version 1.3 (LTI 1.3) will be the recommended specification for new integrations and any integrations wishing to upgrade their LTI security framework. The LTI 1.3 specification has an enhanced Security Framework and also allows tools to layer on new services (LTI Advantage) for a deeper integration experience.

With the IMS announcement also comes a security update, LTI versions 1.0.2 and 1.1.2, for tools that do not wish to update to LTI 1.3. After reviewing the CSRF threat described in the IMS announcement with our security team, we agree with the IMS recommendation to upgrade to LTI Core version 1.3. Instructure has no current plans for supporting versions 1.0.2 and 1.1.2 in Canvas LMS. This decision was made in part because the work to support them for LTI integrations is nearly as resource intensive (for tool providers and platforms) as supporting LTI 1.3, which Canvas is already certified for.  If this is a concern, please reach out to your Instructure CSM or Partner Manager so we can discuss your concerns.


Some useful resources for adopting LTI 1.3 and LTI Advantage services are listed here:

From IMS:

  • LTI 1.3 and LTI Advantage Overview: Within this link you will find public documents outlining the core LTI 1.3 specification, Advantage service specifications, an implementation guide, and more.

From Instructure:

Lauren Williams

Instructure + Unsplash

Posted by Lauren Williams Employee Jul 25, 2019

If you attended InstructureCon 2019, you heard us announce a new partnership with Unsplash, a leading community of photographers that supplies a large library of beautiful images. You may have even met some of the team or attended a presentation about the Unsplash platform. We’re excited to bring great content into Canvas through our integration with Unsplash.  


Why Unsplash?

Unsplash provides curated, high-resolution professional photographs for free. Curated images means safe searches! No more unsavory content showing up for you or your students. And with a library of over 1 million photographs, you’ll surely find something you can use to enhance your courses. 


Additionally, if you find an image that you love and want to see more from that photographer, you can easily click their name on the image thumbnail to visit their Unsplash profile. 


Where do I find Unsplash?

Right now, you’ll find Unsplash options in Canvas Commons and Canvas Course Card Images. Plus, if you’ve enabled the new RCE in beta, you’ll find it there in image options.


Watch for more information about the RCE being available in the production environment coming soon!

We all know education is about more than just learning long division and how to compose a sentence. Education is also about fostering thoughtful and respectful human beings. As a platform for learning, it’s not often that we get an opportunity to help with the latter. While at SXSWedu this year, I saw a film called “The R Word” (which I highly encourage you to see) and I saw a different kind of opportunity for us. One of the things I learned from the documentary is that people can grow when they have the opportunity to learn more about how their behavior (even unintentional behavior) can be harmful. It’s certainly not a new idea, but something clicked for me during the Q&A for the film. It occurred to me that one of the challenges organizations like Special Olympics face is getting their materials distributed into the hands of folks who can make a difference. I just kept thinking, “How can I help? How can I help?” While content is freely available on their website, it still requires instructors to know it’s there, take the time to seek it out, and then customize it for Canvas. We have this awesome tool called Commons. If we could find some Instructional Designers to help us tailor the content for Commons, we could make it so much easier for folks to get this awesome content into their courses. Thus, the idea for “Featured Content in Commons” was born and we couldn’t be more excited for the possibilities this new feature will open up. We teamed up with Designers for Learning to make sure the content looks awesome in Canvas. By the way, if you’re an instructional designer who would like to help with this in the future, you should reach out to them!


We’ve only just begun this new kind of partnership. And while we’re piloting this new feature with Special Olympics (and another organization that we’ll tell you about at Instructurecon), we want to hear your ideas for organizations that you’d like to see us partner with for more awesome featured content. Look for the Special Olympics featured content to appear in Commons during Instructurecon in just a few short weeks!


Speaking of Instructurecon... join us for a chat IRL if you're going to be there!

tl;dr: Newly-submitted ideas will start out in a new non-voting stage: Initial Stage: We are reviewing your idea.


Next week, starting on Monday, June 17, we will change how newly-submitted ideas behave and display. When someone creates a new idea, it will be in a not-yet-open-for-voting status called: Initial Stage: We are reviewing your idea. This should improve the experience for the vast majority of users.


Why the change?

We are aligning the behavior of a brand-new idea with what has long been the practice. A member of the Community Team reviews every idea that comes in. Many of these new ideas turn out to be duplicates of existing ideas, or contain multiple separate requests; when that’s the case, we move the ideas into a non-voting status. While our documentation asks our members to wait for the review process to unfold before promoting the idea, we recognize that not every person has seen that directive before submitting a new idea. And while we strive to review each idea as quickly as possible, the reality is it might be a day or two before one of us gets to it.


What problem does this change solve?

When new ideas arrive in the Ideas forum open for voting by default, we’ve seen scenarios unfold that do not make for a good user experience. For example:

  • If the author and/or proponents of an idea promote it widely and many people vote upon it before the Community Team has performed its review, and a member of our team then closes it for voting, it results in a poor user experience for those who have voted upon the idea, only to find that they are now being directed elsewhere. (In case you’re wondering why we don’t just merge the votes for the new idea with the ones for the existing ideas: yes, we’d love to be able to do that, but our platform does not afford us that functionality.)
  • If the idea has been promoted widely and a member of the Community Team moves it to Moderating status to request clarification, ask the author to edit the idea, or archives it as a duplicate, that too creates a poor user experience for those who have received the idea link and come to the Ideas forum with the intention of voting for it, only to find that they are unable to do so.


What can I expect?

Starting next week, when you write a new idea, it will automatically go into a non-voting status called Initial Stage: We are reviewing your idea. We hope the stage name and its status will make apparent in the UI what has already been the documented practice for ideas.


This small change is part of our continuous review of our ideas process. If you’re interested in the evolution of the ideas process over time, please have a look at Adaptation: Feature Idea Process Changes.


Thanks for being a part of the Community and sharing your feedback and ideas with us!

Enhancing our stylus support in SpeedGrader to include Windows touch-enabled devices has been an exciting and challenging journey. We’ve learned a lot along the way, and I wanted to share a few thoughts. We hope this will provide insight into why we’ve implemented stylus support the way we have.


When a user touches the screen in SpeedGrader, we get touch or pointer events from the browser that tell us if a user is using a stylus or a finger. These events differ from one browser to the next, as well as what we can do with them.


To normalize the behavior across different browsers and different annotation types, we decided to use the physical button on the stylus as the trigger for annotating. When the user was holding down the button, we knew to lock the page (so that it wouldn’t scroll) and to start annotating when they touched the screen. When the user released the button, we would use the touch events to scroll the page.


We genuinely appreciate all the feedback we’ve received on this approach and have made some changes intended to make using a stylus more comfortable and natural. Given the nature of browser interactions (including the difference I mentioned above), this new experience will not be quite as uniform as when the button was required to annotate.


Let me take you through our new approach.


For highlight and strikeout annotations, pressing the button is still required in all browsers. We rely on the browser sending us a section of selected text to know where to place these annotations. This should feel familiar to stylus users, as highlighting text OS-wide requires a button press.


All other annotation types can be used without the button. Simply select the annotation type and touch anywhere on the document to begin annotating. In Chrome users can scroll with their finger while in any annotation mode. This should make it seamless to alternate between annotating and scrolling.


There are two limitations with the current version of Edge. First, pointer events are registered relatively slowly, making it difficult for us to lock the page before a user starts writing with the pen. This can cause the page to scroll as the user is annotating. To prevent this, we’ve disabled the ability for users to scroll with their finger while in an annotation mode. Secondly, there is currently a bug within Edge that prevents users from using the scrollbars with a stylus under certain circumstances. We’ve had conversations with Microsoft around both of these limitations and they’re exploring possible solutions.  


Support for the upcoming Chromium-based version of the Microsoft Edge Browser is already in place. It does not have the limitations that the current version of Edge does, meaning that users can scroll with their fingers in every annotation mode. You can check out the developer preview here.


Firefox continues to have limited stylus support in SpeedGrader. Firefox pointer events are disabled as soon as a user touches the screen, meaning we can only get touch events. This makes it very challenging for us to distinguish between a stylus and a finger. Additionally there are several known bugs that limit our ability to build out stylus support.


We hope that these changes will make it more natural to annotate with a stylus. This has been a collaborative effort with Microsoft and we appreciate their support and feedback.


As always, let us know what you think in the comments.

The Instructure Partnerships Team is in the process of gathering data that could help guide future partner integration strategy for our proctoring service partners and we'd love to hear from you!


If you’re involved with assessment and proctoring at your institution, your feedback is critical in helping us to provide an excellent user experience in partnership with proctoring service providers.  


Please take a few minutes to complete this survey and help guide the proctoring partnership integration strategy at Instructure. We greatly appreciate your participation and may reach out to learn more about your experience with Canvas and our proctoring service providers. 


Proctoring Survey

Karl Lloyd

LTI Advantage

Posted by Karl Lloyd Administrator Feb 20, 2019

Recently IMS Global Learning Consortium announced an unprecedented number of education platforms who have been identified as early adopters of LTI Advantage and have run through early certification testing. The next day Instructure issued a statement in support of this IMS announcement. I have to admit there was quite some time where I wasn’t certain we would get to this point. Looking back over the last 5 years I have been actively involved in the evolution of the LTI standards.  It has been a bumpy, but exciting road. In 2013, after a year of specialized Canvas integration work, I was offered the opportunity by Brian Whitmer to work with a super small team which was focused on supporting LTI 1.1. These were exciting times! Within my first year, we implemented an app listing repository, simplified tool installation in Canvas, polished up resource selection (which ultimately transitioned into the Deep Linking standard) and started to see exponential adoption right out of the gate.


Then came LTI 2.0. We were excited by the possibilities this next generation standard could bring to the market, but highly uncertain of the overall strategy and complexity of this new core standard. With my small team we worked on implementing as best we could for 9 months and I finally had to make a decision. Do we keep plowing forward or do we pause and take a step back? I chose the latter and decided to see what came from the market. Over the next 2-3 years, I fielded many questions about this new standard, but only a few vendors rolled the dice and implemented it. When it came to standards evolution, I felt like we were listening to a broken record, continually finding ourselves witnessing the same conversations over and over. It was exhausting!


Fortunately in late 2017, to IMS’ credit, they were listening to the industry regarding concerns about the continued use of OAuth 1.0a signing and LTI 2.x complexities which opened the door to have new conversations. For me, this is where standards work became exciting again. I started to witness unprecedented collaboration within the working group between various organizations. Many of these organizations are direct competitors in the market space.  It was awe inspiring to see the contributors from these organizations roll up their sleeves and work together with the goal to bring something great to the market.


Fast forward to today. IMS is on the verge of releasing the following standards to the market:

  1. A new core version of LTI (v1.3) built on top of an updated security framework using OAuth 2.0 and Open ID Connect. If these sound familiar it’s because they are widely used today by the software industry. Going forward in our industry we will now be able to focus on improving capabilities instead of figuring out how to authenticate with each other. This is a good thing!
  2. Deep Linking, which the 1.1 specification had before, has been updated to work with new core standard and has a ton of potential to be expanded to provide even better integration experiences.
  3. Names and Roles Provisioning Service will allow a tool to interact with Canvas to capture course enrollment data without implementing our API. This will be important to teachers as they won’t have to manage two separate course lists between Canvas and another tool. It’s also important to Administrators as this is a well known use case that necessitates a tool to use our API to enhance the integration. If tools only need roster data from Canvas API’s, institutions will be able to accomplish this without having to manage an additional API Developer Key for the vendor.
  4. Assignment and Grades Service has a ton of potential and sets a foundation in Canvas to allow a tool to have more options for returning results data. As mentioned in the previous service this is also supported without needing a Canvas API Developer Key. I am also excited to see where this standard goes in the future and how we can expand its capabilities for our Teachers and Students within the Canvas ecosystem.


In other exciting news, I’m witnessing an unprecedented amount of actual integration work being done by both our customers and vendors expanding Canvas capabilities with innovative applications. At IMS bootcamps I’ve seen engineers create a simple application within a day incorporating all the LTI Advantage standards using widely available code libraries and a great reference implementation tool IMS created. This definitely wasn’t the case previously. However, there is still a ton of work to do. If our journey was compared to a climb to summit Mount Everest we’re right between the last two camps and getting anxious about that last leg over the steps and the remaining ascent to the top. IMS still needs to wrap up remaining work and release the final standards to the public which are well underway. From the platform side, although we’ve been through early certification tests, we continue to collaborate with early adopter tools to harden and prove these new standards with our implementation work. In Canvas specifically, soon our customers will be able to beta test implementations with early adopting vendors. We are still working on extending deep linking support to provide parity with our LTI v1.1 extensions and are re-evaluating our current configuration experience.


The future is bright when it comes to education technology interoperability. As we look forward together, our goal should be to remove barriers and provide actual value to those who are most important. For Instructure, these are the students who are the future of our societies around the world. We have a stewardship to implement technology responsibly in the teaching and learning process. Standards development isn’t as glamorous as other really popular education initiatives but has the capability to support and allow us to implement these other ideas with more efficiency and as I look to the future this is where things get really exciting.

Last October we outlined a new security project for Canvas that gives institutions more control over the javascript that is allowed to run in their instance of Canvas through an updated Content Security Policy (CSP). We've been working hard to make this plan a reality and I'd like to post an update on our progress.


This project is comprised of three phases. The first phase changed the way we were serving up files in Canvas. The goal of this phase was twofold:

  • Make it clear that the files are not owned by Instructure, but rather by other Canvas users.
  • Limit how broadly user-granted permission was being applied. For example, if a user grants a file permission to access their webcam, permission will only be given for files in that course, and not for all files in that institution's instance of Canvas.

This first phase was deployed at the end of the year (view release notes here).


The second phase brings an updated CSP option to Canvas. The updated CSP will be opt in from a new Security Tab found on the account settings page. Institutions that don't opt in will have no changes made to their account. If an institution does choose to enable the updated CSP they will be able to restrict custom JavaScript (JS) that runs in their instance of Canvas based on domain.

  • This will be managed by a whitelist of acceptable domains. All JS that attempts to execute in violation of the whitelist will be blocked.
  • The whitelist has a limit of 50 domains. We recommend using wildcard domains (*.domain).
  • We will automatically add all necessary Instructure and Canvas domains, as well as any LTI tools that are configured on the account. These do not count toward the 50 domain limit.
  • Root account admins determine if sub accounts can manage their own whitelists. If so, sub accounts will have the option of either inheriting the whitelist from the parent account or managing their own whitelist.
  • Individual courses can be opted out of the CSP (for example, a computer science class that requires the ability to render student-submitted JS). Only account admins can opt a course out of the CSP.

This phase is currently in development. Our plan is to have this phase completed in the next couple of months.


The third phase adds a log to the UI which shows any requested domains that are in violation of the whitelist. This will allow admins to monitor activity and easily add new domains to the whitelist.

This phase is currently in the design stage and will begin development after phase 2 is released.


We're excited about the increased control this gives to institutions in managing the security for their instance of Canvas. As always, we'd love to hear from you. Let us know what you think in the comments!

We’ve had a few questions about the removal of the rating system in Commons, and we wanted to provide you all with some insight into our thought process.

  1. The rating system didn’t see wide adoption. Only 6.8% of resources in Commons had a star rating. Of those resources with a rating, 88% of them received 5 stars. We weren’t the only ones who noticed that the ratings weren't being used in a way that truly provided value. Here is an actual review of a resource in Commons:
    (rating: 5) "I'm going to give a five star rating to anything I find that is offtopic because nobody else is going to use the rating system in commons and that lets me game the system to ruin everything."
  2. Rating content in Commons is a lot of work and quite outside a normal workflow for most educators. It seems, for the most part, folks weren’t taking the time to import content into Canvas, evaluate its quality, and then return to Commons to rate the quality of the content. And this behavior is pretty understandable! That’s a lot of steps to take as a busy educator, when there is not direct benefit to your own process.
  3. We wanted a shorter route to surface valuable Commons content for you in Canvas. Commons contains some awesome resources to include in your Canvas course. Currently, that process requires that you launch Commons, locate the content, and then send the content to the Canvas course you were building.


So if ratings aren’t proving to be super useful for identifying valuable content, we asked ourselves: What could we do to help identify valuable content in Commons without requiring our users to do extra work? Taking that problem a step further… how can we help identify that valuable content and surface it in Canvas?


From Canvas, very soon you will see an option to pull up your list of Commons Favorites and directly import content that you’ve identified as valuable. First, we’ll give you that option in the Rich Content Editor (RCE). From the RCE, you’ll be able to choose any video, audio, images, or files that are in your list of Commons favorites and directly import them. Next, we’ll give you the option to add content from your list of Commons favorites on the Index and Modules pages. We’ll also be adding feedback about how often things are favorited and imported to each resource. “Most Favorited” and “Most Downloaded/Imported” will be added to the “Most Relevant” sort options in search results.

Because adding resources to your Commons favorites will allow you to keep track of your favorite Commons content and makes it easier to import content into your Canvas course easily and efficiently, we expect favoriting to see greater adoption than the rating system did. We also feel that number of downloads/imports and favoriting numbers provide a better indication of effective content than a subjective and poorly adopted rating system did.

You guys! We invented a thing!

Well, more specifically, our brilliant engineers invented a thing! Why? Because you asked us for it!


You asked for a way to see the contents of the resources that are shared in Commons before importing it into Canvas. We wanted to give that to you, but those Commons resources are stored as “Common Cartridge” files and a web-based “Common Cartridge Viewer” isn’t a thing that existed in the world. Our industrious engineers worked very hard to find a solution that would allow us to crack open those cartridges and show you their contents. And they did it! Seriously. They invented a way to extract and then preview common cartridge files in the browser. That means we will be able to show you a preview of assignments, pages, discussions, quizzes, modules and courses in Commons.


You can try out the Preview technology here, using our stand alone Common Cartridge Viewer. There are a few cartridge examples there for you to test, or you can export a course from Canvas and drag it onto the browser. The Common Cartridge viewer is open source and you can check it out on github.  


Our next release to production (January 5, 2019) will include a feature option for Commons Previews on the Commons Admin page.  Because we invented this thing (did I mention that yet?), we wanted to take a little time to collect feedback on the Previews before turning the feature on for everyone in March 2019. We’ve set up a User Group where we’d love to hear your thoughts, questions and any issues that you find with the Previews.

***Please note updated Flickr Removal Dates, due to Flickr Clarification***

Thank you to Ian Linkletter for pointing out the clarification.

Flickr is Removing Millions of Images

On November 1, 2018, Flickr announced a plan to remove millions of images on February 5, 2019. For Canvas users, this news was quite concerning, as Canvas offers Flickr as an easy way to find and insert images into content and as Canvas Dashboard Course Card images. On November 9, 2018, Flickr clarified their announcement, explaining that material licensed by Creative Commons would not be removed. The good news is, the Flickr search mechanism we implemented for all course content in Canvas will only return Flickr images licensed by Creative Commons. Therefore, images added to your courses using Canvas’ Flickr search are expected to be safe from the February 5 removal of images.


However, the Canvas Dashboard Course Cards may not be as safe. The Flickr search mechanism we employ for this feature uses both Creative Commons search results and Public Domain search results. This combination means there is a chance that images may be removed from Canvas Dashboard Course Cards.

We want to help!

While Flickr didn’t give us a ton of time to find and implement a solution to help our users with this problem, we jumped into action as quickly as possible.  In addition to a short time frame, a few considerations have made it tough for us to have a perfect solution.

  1. Flickr replaces removed images with another image that says “image not found”. While that behavior seems like a nice thing to do, it’s quite out of the ordinary. Normally, when images that are hosted on other sites (like Flickr) are removed, we can detect the image removal. Flickr’s method of replacing the removed image with another image makes normal “image not found” types of detection ineffective.
  2. Flickr is removing images at the very beginning of a semester (February 5). Why is that a problem? Well, it creates a challenge for us because the beginning of a semester is when a lot of classes are just beginning and just ending. Determining which courses are active or soon to be active becomes a challenge.

So what’s the plan?

  1. We very quickly updated the Course Link Validator to detect Flickr’s unusual broken image method. That work went to beta December 10th and will be in our next production release, January 5th.
  2. We will run the link validator globally on February 4th to check for Flickr images. We’ll do the same thing on February 6th after Flickr has done its mass removal of images. At that point, we should have a pretty good idea which courses have been affected.
  3. We will send an email to all owners of the affected content to tell them exactly where we detected a Flickr broken image.

Introducing Unsplash

We’re happy to have come up with and implemented a short-term plan to handle the mass removal of Flickr images on February 9th, but we also saw this change as an opportunity to look for a better long-term, more holistic solution for all of our Canvas users. As many of you may know, we’ve had a history of issues with Flickr returning unsafe images to our “safe search” query. This has led some schools to block Flickr, and some requests that we remove Flickr from Canvas.


The one thing Flickr had over its competitors was a Creative Commons search and a “Safe Search”. For a long time, we couldn’t find anything to properly replace Flickr by meeting both of these searching requirements.

Until now.


In early 2019 we’ll begin the process of untangling Flickr from Canvas and replacing it with a fabulous product called Unsplash. Unsplash provides hand-selected, professional photographs for free. We highly encourage you to go check out their site. They are a fantastic, collaborative company, and we think when you see the quality they provide, you’ll be as excited as we are about what a positive effect Unsplash will have on your Canvas course content in the future.


Watch for future changes to the Canvas Interface to be announced in the release notes, as well as additional information about our new partnership with Unsplash.

Since its inception, Canvas has always been open and transparent about our business and our features. We believe in being open. We believe in allowing you to use Canvas the way you want to use Canvas. And branding is one component that we’ve been working hard to improve, specifically relating to the use of the existing style guide and Instructure UI (InstUI), Instructure’s own component library.


Branding Evolution

Web technologies continue to evolve, and over the last three years, we’ve been able to introduce the Theme Editor at the account level, which helps admins create custom templates without the use of custom CSS and JavaScript files, although those file types are still accepted.


Previously, Canvas engineers implemented a style guide to be used for internal engineering teams and ensure consistency throughout the product, hosted as part of each Canvas account (e.g. Over time, we noticed that some of our customers started to leverage that style guide. We know that you enjoy being able to design your own Canvas-theme projects within the Rich Content Editor. Now, with the evolution of additional technology advancements, we’ve discontinued the use of the old style guide in favor of InstUI.


Why InstUI?

In order to use the styleguide, a developer or course designer would copy the HTML markup for a user interface pattern, such as tabs, and paste that markup throughout Canvas. However, HTML is only part that pattern. The style of those tabs is defined with CSS, and the interaction of navigating between tabs is enabled through Javascript. This architecture quickly became difficult to maintain. If we were to make a style enhancement or fix a Javascript bug that necessitated updating that HTML, every instance of those tabs—whether in Canvas, in a custom tool, or in course content—would have to be updated manually or remain broken.


To combat these maintenance challenges, we made the decision to move Canvas front-end development to React, a library developed by Facebook for creating modular user interfaces. React components encapsulate the HTML structure, the styles, and the Javascript together into a reusable, easily maintainable component. A bug fix to a React component propagates to every instance of that component with little to no effort, only needs to be made in one place, and every user immediately benefits.


InstUI, Instructure’s own UI component library, is built using React, which allows our developers to deliver new features more efficiently and makes all of Canvas easier to maintain and innovate. InstUI ensures consistent, accessible experiences throughout Canvas and delivers custom themes made with the Theme Editor to all interactions, just like the style guide intended. With React, those experiences are better tested, better maintained, and more reliable than ever for our users.


InstUI Availability

If you’re interested in using the InstUI components, InstUI is open source and available for you to use in your LTI tools. To get started, visit If you’re starting from scratch, InstUI works great with React boilerplates like Create React App.


We haven’t enabled the use of InstUI in the Rich Content Editor yet; however, other tools are currently available for integrating custom changes. Some options as noted in the community include H5P and other canvas embed tools.


Future Development

In 2019, the InstUI team will begin work to improve documentation and support for third parties.


Additionally, we recognize we don’t have an ideal solution for making changes in the Rich Content Editor. For now, we’re focusing on building a better Rich Content Editor to give you a better experience and give you more controls to design pages the way you want. This project is in the planning stages, and if you want to get more involved, watch for additional details to be posted in Canvas Studio.


If you’ve been using InstUI, let us know your thoughts in our InstUI Community Discussion.


If you’re not using InstUI but have used elements from the style guide in your pages, please let us know in the comments which elements you used and why they were helpful to you. Style guide feedback may be considered for future development.

We previously posted to the community a proposal for a new security policy in Canvas. In that post, we discussed the open nature of Canvas and our desire to make Canvas as flexible as possible while still implementing good security practices. Balancing security with flexibility is a task that we take very seriously, and we’re constantly reviewing and improving our approach and stance. As the world changes, we make adjustments when needed. At that time, we proposed a change to Canvas that would limit custom JavaScript from running in the Files section of Canvas.


We received a lot of great feedback from the community and we appreciate everyone who contributed. After additional discussion and research, we decided that a more comprehensive solution was needed. We've been working since then on a new approach that we would like to announce today. This new project will be completed in 3 phases:


Phase 1 -  Serve user files from non-application domain

  • Change the files domain from to This will make it clear that the files are not owned by instructure, but rather by other canvas users. Users will most often see this domain when browsing files in the Files section of Canvas, or when a file requests a user’s permission.
  • Change the files subdomain from clusterXX-files to one based on the associated account and course of the file being served. This change will mean that when a user grants a file permission (to access a users webcam, for example) permission will only be given for files in that course, and not for all files in that institution.


Phase 2 - Allow domain whitelisting

  • Allow institutions to restrict custom JavaScript (JS) that runs in their instance of Canvas based on domain. This will be enabled by an updated Content Security Policy (CSP) from Instructure. Institutions will have the option to enable the new CSP as a setting at the account level. The new CSP will be opt-in, and institutions that choose not to enable it will have no changes to their account.
    • Once the updated CSP is enabled, institutions will have a whitelist of acceptable domains that they maintain. We will automatically populate the list with all of the Instructure domains.
    • Individual courses can be opted out of the CSP (e.g., a computer science class requiring the ability to render student-uploaded JS).
    • All custom JS that is in violation of the whitelist will be blocked from running.


Phase 3 - Surface CSP violations to administrators

  • We will present administrators with a log of any requested domains that are in violation of the CSP. This will allow them to monitor violations and update their whitelist as needed.


We believe this approach will give Canvas administrators fine-grained control over the security for their institution while also preserving flexibility. Our preferred approach is to make this change as part of our standard deployment process—first to beta where it can be evaluated by admins, and then to production. We plan on each phase being deployed independently. Work has already begun and we currently estimate that we will have Phase 1 completed in Q4, 2018, Phase 2 completed in Q1, 2019, and Phase 3 completed in Q2, 2019.


As always, we would love to hear your thoughts and feedback.