Skip navigation
All Places > Canvas Mobile Users Group > Blog > 2020 > February
2020
*You'll be glad you did.
 
In providing support for faculty and courses, certain best practices have been validated repeatedly. 
One of those is optimizing Canvas content pages to increase the likelihood your students will actually see and use them! 

 

Unpack Course Documents to Become Canvas Pages

When new instructors are transitioning to Canvas, the process can be overwhelming. An unfortunate, frequent shortcut is to simply “link” documents like the Syllabus or assignment instructions. This may appear to be a quick solution—but only for one semester. When the complexity of updating increases, the missed opportunity to apply best practices becomes apparent through extra hassles and files housekeeping over time. 

 
“A shortcut is the longest distance between two points”Charles Issawi
  •  
Bad reasons to Link documents in the RCE or Modules:
  • Seems faster.
  • Lower faculty skill-level or understanding of Canvas. Links to files are all the instructor knows how to do.
  • Instructor already has a big Masterfile with .pdfs and WordDocs that hasn’t been changed in years. 
  • Imaginary threats, like the fear that students will change the Syllabus and argue some detail with the instructor. 
  • Student UX hogwash! Courses have always been a big stack of papers to manage. Why suddenly make life easy for short attention spans?
  • Document was made on an old typewriter (or on MSWord) with lots of tabs and spaces to center the text. It will be a nightmare to learn the Word ribbon tool at this late date. 
 
Signs that .pdf/.doc overuse is an issue
  • The course files area has 6 old versions of the Syllabus from which to choose.
  • Course content is not updated because the instructor can’t locate their original doc for editing. 
  • Students don’t read the syllabus.
  • Instructors don’t understand why students don’t read the syllabus. See hint.

Hint: Students are looking on an iPhone and don’t want to clog up their memory by accidentally downloading that 10-page Syllabus yet again, plus the document opens in a tiny viewer in a 1 pt. font. Instead, use Canvas content pages to stream beautifully!

Upstream Management

Instead of waiting for increased difficulty all around, consider unpacking your .docs into Canvas as a best practice.
  • Accessibility
    • Transitions are an ideal time to use Headings/Styles, alt text, descriptive links, ribbon tools, and correct tables in the pages rich content editor (RCE). 
  • Encourage mobile streaming view for all content, versus documents to download and manage. 
    • Increases the likelihood of students being able to see and use the content on any device. 
  • Copyright
    • Transitions are an ideal time to check copyright, record your Fair Use justifications, and/or update content into safe compliance. 
  • Quicker updates each semester.
    • Compare updating a Syllabus in Canvas (Edit, type, save) with updating a linked document (Locate master doc, make changes, save, replace in Canvas, test to make sure you linked the correct doc, get rid of old doc, preserve link, etc.)
    • Remember, if you don’t do this every day, the workflow is forgettable.  Once a semester, and you’ll forget what you’re doing. 
  • Version control.
    No need to search for master copies on a former employee’s home computer. Everything related to the course lives in the Canvas course. 

 

Process

  • .Docs that are already Accessible easily become Canvas content pages that are accessible, with a simple copy and paste.

    • The transfer process reveals old-school tabs and spaces misuse. Oops.  Those must be manually corrected once the content is in Canvas RCE.

  • .pdfs can be a nightmare. Depending on the complexity of content, you may need to open a .pdf in Adobe Acrobat Pro and export it as a WordDoc, then scan carefully for substitutions, misspellings, and other transcription errors. 

 

Exceptions

Course builders work with what we have. Sometimes you just let one thing go—temporarily—to meet a deadline or inch toward progress. 
 
*Good Reasons to link a document in RCE or modules
  • Students need to download and print an entire document intact. Example: APA or MLA formatted example research paper.
  • Information is not likely to change and is not available another way. Example: an archived out-of-print article. 
  • Information that is already accessibility checked. Example: Government website downloads or official releases.

Ready or Not

Ready or not, increasing numbers of students view Canvas courses on mobile devices. (Numbers may vary by institutions, but the overall trend is upward for mobile use.)
 
Even if your course is designed for desktop/laptop, a quick check on iOS and Android devices will give you a more complete idea of what students see—and why they interact with the course the way they do. 
 

Canvas Parent 3.1 beta for Android and iOS - incoming!

 

Android 3.1 beta link: https://play.google.com/apps/testing/com.instructure.parentapp 

 

iOS 3.1 beta link: https://testflight.apple.com/join/JDVOYyT9 

 

In this version of the parent app, we added support for messaging between parents and teachers. This has been a request since we originally launched the app, and we think we've figured out how to incorporate messaging in a way that benefits both parents and teachers (and in turn, students)! Here's what's new.

 

 

  1. Floating message icon:

    parent_app_contextual_compose
    Parents have access to messaging from several views around the parent app, including the assignment details view shown above.



  2. Pre-filled composition view:

    prefilled_compose_view

    Since the parent tapped to compose a message from the assignment details view, we pre-populate the subject field with the student name and assignment, and set the recipient as the teacher of the course.



  3. Contextual message:

    teacher_receiving_message

    When the parent sends a message, the student name and a link to the related assignment are automatically appended to the end of the message the teacher receives, so absent any other context, the teacher can see which student/course/content the parent was referencing.



  4. Inbox in parent app:

    parent_receiving_message

    The parent receives the teacher's reply in a simplified inbox in Canvas Parent.

-------------------------------

 

A few other things to note:

  • All of this is using the existing Canvas inbox/messaging features that teachers and observers can already access in Canvas web/API/other Canvas apps today.
  • We hope this improves the communication flow between teachers and parents in a way that doesn't introduce unnecessary noise and helps support students. Feedback is welcome.
  • iOS plans to release 3.1 to the App Store this month.
  • Android won't release 3.1 outside the Play Store beta linked above. As per the original plan, Android will release all of the 3.0+ updates to the Play Store as 3.2, and from there the iOS and Android parent apps will be in lock step again. My guess is that 3.2 will ship to the App Store and the Play Store next month.

 

Up next: new calendar for parents (Canvas Parent 3.2) and students (Canvas Student 6.7)!

We’re at nine million monthly active users of the Canvas mobile apps, which is many millions more than when I last posted about Instructure’s approach to mobile. If you’re new to Canvas, or if you’re curious about how and why we do the things we do, this post is for you!

 

We anchor mobile app development to a few principles:

 

  1. Focus on experience. There’s a lot of ground to cover when it comes to making Canvas fit into your pocket. The mobile apps have to be secure and accessible and scalable. They have to be translated into 34 languages. The mobile apps have to evolve with regular changes to Canvas web and mobile operating systems. They have to handle courses with 10 students where every assignment is an LTI launch, and they have to handle courses with 200 students where every assignment is a discussion. The iOS and Android apps have to look and function the same way despite being on two different tech stacks produced by two different teams of people. But just as importantly, the mobile apps have to deliver worthwhile experiences. If regular operations take too long or make you miserable, or if the interface just looks like bad, you might as well be using any other LMS. Canvas has to be better.

    Here's a subset of the 82 polish items to address before releasing Canvas Parent 3.1, for example:

    parent_polish_items

    These polish tickets are usually cosmetic, and they come when we compare iOS and Android side-by-side at the end of developing a feature.

  2. Ship things. Product development exists on a spectrum. On one end, you plan every detail and you never take risks and as a result, you never ship things because you find that details change and risks can’t be avoided. On the other end of the spectrum, you don’t plan enough and you ship quickly and you break things. The outcomes at either end of the spectrum aren’t good. The Canvas mobile teams strive to be somewhere in the middle of that spectrum, always erring on the side of shipping. We can’t deliver the value that we don’t ship. We believe that when we mess up, we ought to listen and learn and ship again.

  3. People over process. In my experience, this is the most overlooked value from the agile manifesto -- which is roughly the constitution of agile software development. Our teams do their best to reconcile what’s planned and what’s right when there’s a gap. We try to keep enough perspective to prevent process from lulling us into doing stupid things. There are scenarios where this principle doesn’t work, but we try to create situations where it does (small teams, smart people, taking on new challenges, limiting recurring meetings, encouraging communication, etc.).

    Here's one of my favorite parts about working at Instructure:

    allen_slack
    This is the mobile support lead's way of saying something is on fire somewherecheck it out. I've worked for companies where people roll their eyes when they see this and say they'll get to it next sprint. That's the worst, and it's what you get with process over people. If there's a fire, we're going to stop regularly scheduled programming to go deal with it.

  4. Prioritize real-life benefits. When you’re planning a project on a platform as versatile as Canvas, it’s tempting to miss the forest for the trees. What happens with our new feature if this course setting is on and this feature flag is off and this sub-account hides this button and this root account has this permission disabled for this role and this ticket hasn’t merged to beta? Concerns like these take up a huge amount of mental space, and to a large extent, it’s the job of product and engineering teams to make sure these cases are hashed out. At some point, it’s also true that 99.723% (see: made-up numbers) of users won’t experience the case you’re worried about, and you’re better off figuring out how to remove extra bits of friction for the average user. This is not a straightforward thing to balance, but in general, the mobile teams will prioritize delivering maximum value to maximum people over checking every last feature box.

  5. Throw a little weird in there. Our software is designed and built by people as quirky as our users, and it ought to reflect that fact for the sake of everyone involved. If you like your software a little more dry and dusty, I’ve had good luck recently with printer utilities, insurance apps, and SimCity 2000 doesn’t hold up quite as well as I expected. Weirdness is especially vulnerable to atrophy over time, but it’s worth protecting. We want to flex those weird muscles.

 

When you mix those principles together, you get role-based apps which are updated regularly and rated best-in-class by users -- with spinning Canvas logos and panda avatar builders to top it off!

 

This definitely doesn't mean everything is awesome. Our approach involves tradeoffs. Let’s use peer reviews as an example. It’s a cool feature, and some people rely on peer reviews, and you can’t conduct peer reviews from our mobile apps today. We consider peer reviews every time we touch assignments in mobile. We have a design, and we know how it would work, and we know what it would take to support it. The problem is that peer reviewing is a relatively lesser used feature of assignments, and it would take a lot of effort to support natively. Instead of working on peer reviews last fall, we focused on things like improving load times on grade lists in student and teacher apps, and increasing the visibility of feedback on submissions, and reducing taps to submit assignments. But if you created those peer review assignments, this is still a bummer, and I get it!

 

I can think of a few escapes for this predicament, in no particular order:

 

  • If you’re on a tablet or Chromebook, Canvas web is fully supported in your native web browser
  • Some schools contract with our professional services team for custom development
  • Our mobile apps are open source, and some schools build their own mobile apps using our repositories as a model
  • You could build the feature yourself and submit a pull request for our mobile team to review
  • We can hop on a call and you can argue that we’re doing it wrong
  • You can submit a feature idea in our community and see how it resonates with other Canvas users


If you want to know more about web/mobile parity, our documentation team has created some guides for the student and teacher apps that you may find helpful. If you have feedback on making those documents better, send it on!

Filter Blog

By date: By tag: