Canvas Parent 2.0!

[peytoncraighill]

For the most recent post on Canvas Parent 2.0, check out Canvas Parent 2.0 - Pre-Release Update.

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

This here’s meant for the K-12ers in the house. HE folks are welcome to keep reading, but I bet you won’t find it very relevant.

I mentioned in my recent Canvas Mobile Update post that we’re going to improve everybody’s experience with the parent app by changing the way authentication works. This post will provide a deeper dive into what that means and what you can expect from the parent app in the coming months. It’s nothing scary; I just want to make sure everyone has a proper heads-up and a chance to ask questions.

The Problem

Let’s start with how things work today. Your institution handles parent accounts in Canvas in one of two (or both of these) ways:

1. You provision parent accounts in Canvas -- likely as observers -- from your SIS or some other user import. In this case, you’re either using Canvas authentication or some other authentication system (LDAP, SAML, etc.) to allow parents to access Canvas. You probably also communicate with parents about how to access these things…maybe at back-to-school night, maybe in packets you send home with kids, maybe through email, maybe through snail mail, or whatever else. Provisioning is the method of choice for a lot of larger schools/districts.
   
   AND/OR
   
   
2. You enable self-registration for observers in Canvas. In this case, you tell parents to go to ‘yourschool.instructure.com/login/canvas’ to create an account for themselves. This option enables a little button on the Canvas login page that says:
   
   Self-registration is the method of choice for a lot of smaller schools/districts.
   

In both cases, you end up with parents as users in Canvas. Cool! That means parents can engage in their kids’ education and you can facilitate that engagement depending on the policies and preferences of your school or district.

Okay, now less cool: We created an entirely different user model for the parent app when we launched it two years ago. There were good reasons for it, like wanting registration for parents to be easy from a mobile device -- and wanting parents with kids at different institutions to have an easy way to navigate between those kids/institutions. But in the end, this other user model:

• Doesn’t play nice with SIS integrations
• Doesn’t play nice with Canvas services like inbox
• Means parents (at least until we added support for observer authentication in the fall of 2016) needed two Canvas accounts – one for web and one for mobile
• Necessitates all this duplicate tooling like Canvas Parent Admin Tools and a Canvas Parent feature flag to manage mobile parents separately because Canvas Parent Users aren’t technically Canvas users
• Made the first-time experience for parents worse

That all stinks. And that stench totally outweighs the theoretical benefits of having a separate model for parents.

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

The Fix

In case the solution isn’t obvious yet: we’re going to get rid of the Canvas Parent user model and everyone’s going to authenticate in the parent app with their ordinary Canvas credentials (just like students and teachers do in the apps today). Here’s what the current release plan looks like:

Version 1.3

• When: Likely the second half of April
• What it does: Removes the “Create Account” button from the parent app’s login page
• What parents can expect:
  
  • Won’t change anything for existing users.
  • Brand new users will need to have Canvas observer accounts to log in to the parent app.
• Why: Since we’re getting rid of the Canvas Parent user model this summer, we’re removing the ability to create accounts that won’t work a few months down the road. Instead, new parents will need to be Canvas observers.

Version 2.0

• When: In July, when parent app usage hits its lowest point
• What it does:
  • Forces observer authentication to use the parent app
  • Likely gets rid of Canvas Parent Admin Tools and Canvas Parent feature flag (because they duplicate other Canvas admin functionality)
• What parents can expect:
  • Will need to log into the app again, this time using their Canvas observer credentials, following the same flow they would to log into Canvas web or the student app (No more having two accounts!)
  • Any kids they’re observing will automatically populate once logged in (No more re-adding students you’re already observing in Canvas web!)
• Why: To make everyone’s brains hurt less

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

Here’s a picture of the change:

If you have any questions, fire away!

[Bobby2]

Yet another promising update thanks Peyton.

How do you go about ensuring the correct parents have access?

[MattHanes]

Will parents still be able to self-register within the app or will they have to go to the web interface to create their accounts before they can use the app?

[MattHanes]

Not really a question, but I have a suggestion. In my experience at parent nights, the process for getting in the app is not as intuitive for our tech-challenged parents. The two main things are:

• They have to know to type the name of our school district (and not the name of the school)
• They have to know their child's login information. We don't have access to student passwords, all we can do is reset them so the student has to be nearby to get their login password. Students may not have logged in yet at school and don't remember their passwords either.

I think both of these issues could be solved by giving us the option of activating a "parental join code" that teachers can send parents. Like the teachers could generate a report (or a form letter would be even better!) that has a unique GUID for each student that can be used to sign up in the app. That way Canvas will know which institution to assign the parent to and the students do not have to give out their passwords.

We really appreciate you communicating with us so directly,  @peytoncraighill !

[Bobby2]

Providing schools, then parents, with the correct and easy to follow login information is vital. Making the process as simple as possible is key. Creating a join code sounds like a cool idea  @MattHanes .

Would that be an easy thing to initiate? 

[peytoncraighill]

Thanks  @MattHanes  and  @Bobby2 ! These comments/questions are related.

The ideal join process would be 1) secure and 2) painless, and we haven't figured out a great way to accomplish both of those things yet. Using a student's password is relatively secure -- if awkward -- because only the student and the school have access to know or modify that student's password.

We looked into using email confirmations and codes a couple of years ago and we always ended up with bad hypotheticals, particularly for the self-registration flow. So for a really obvious phishing example: random person self-registers using an email close to a parent's email, student/admin receives email notification saying this name/email wants access to this student and approves it. But there were more nasty ones than that.

We can review this again with the case you mentioned in mind -- teacher invites parent to join with student -- and see if we can come up with something better than today's flow. Could be a code that only lives for a few minutes, could be something else.

Thanks for the feedback!

[MattHanes]

The join code method I mentioned above is the way our SIS system handles their app for parents to check grades and attendance. Each student has a GUID code that parents are given to create their parental account. The system has a letter generator that prints out an instruction sheet that contains the student's name and GUID as well as how to create the account and download the app. Once the code has been used, it can't be used again to create a new account. The parent has to contact the school to get a new code (and show ID) to get a new letter. Or we reset their password if they can remember which email address they used. I can tell you for sure that we would see a huge uptick in Parent app users if it were that easy for my teachers to send home an automatically generated letter with all the information needed to sign up for the app. Because the teachers don't know the student passwords either.

Thanks so much for responding to our feedback! 

[peytoncraighill]

We think we've got a relatively straightforward way to improve the student/parent pairing process. We want to get away from:

1. too much hanky-panky with passwords and
2. requiring a school's students to use Canvas auth for observers to self-register.

Here are some notes on the proposal:

1. create a button for the student to "Pair with Observer"
   • available to students from /profile/settings
   • available to teachers from /courses/courseid/users/userid
   • clicking button creates unique pairing code that student/teacher can share with parent
   • pairing code only lives for an hour
   • pairing code can only be used once
   • only one pairing code can be active at a time per student
2. modify canvas observer self-registration form
   • change form from requiring name, email, child_username, and child_password to requiring name, email, pairing code

The one-hour lifetime of the pairing code is pretty short (maybe too short?), but this gets us closer to secure/painless than today's system. Feedback welcome!

[KristinL]

The proposed change would cut out a lot of information. It would be amazing to only needing name, email, and pairing code; it would be a very welcomed change! I don't mind that the student needs to be involved by creating the "pairing code", and the fact that it would only live for an hour makes the task immediate and collaborative. (No more of the "I had my student write down their password for me" scenarios that I hear about!)

It would be awesome if there could be a guide with visuals for districts/teachers to share with their families. ...when you get there, of course.

[MattHanes]

I can't tell you how happy I am to know that this is being talked about! 

Here is my feedback so far: 

• Pairing code for an hour would be a little short. Maybe let admins decide how long it should be in the Account Settings? Otherwise, I would say 24 hours would be the minimum for a "give this letter to your parents that has the code" kind of situation. Ideally, I would even say give the parent 3 days to use the code generated by the teacher.
• You will probably need a way to prevent a student from generating another code after a parent observer is linked. So they don't just generate another code to kick the parent out of the system.
• Most students higher than 4th grade in our school district have multiple teachers in a day. Therefore they would have multiple courses. What would be the mechanism for preventing teachers from overwriting each other's generated codes for students? Would we need to take this a step higher and make this an account-level feature? I understand you might want to keep it at the course level for the Free For Teachers accounts. The student pairing would get around that though.

I'm so excited about this change! Thanks for listening to our feedback.

[KristinL]

 @MattHanes  - With your second bullet-point, is that so students cannot generate another code during the initial code is active? That makes sense! I want to clarify because I think it's important that the button becomes reactive for additional uses (additional family member, coach, counselor, etc) Also, wonderful idea with the third bullet-point, and I think that would help a little by disabling/enabling the button based on the code's "life span".

 @peytoncraighill  - Would this be something that a Canvas Admin could initiate? I receive calls and emails from family members asking for help connecting accounts with their student's. It would be nice to be able to help with the process without having to masquerade as the student to generate the code.

[MattHanes]

 @KristinL  - Sorry Kristin, you're right. I was thinking that there would only be one observer per student so each code generated would kick the other one out. That's the way it works with our SIS system but I think we would definitely want more than one person to be able to be added.

[MattHanes]

One more note:

There is still the challenge of parents remembering to type our District name instead of the school name which is what they want to type by default. So if the join code could take care of that part of the authentication process as well, that would be ideal.

[peytoncraighill]

Good feedback on the pairing code lifetime. I'll see if the security team is okay with it living for 24 hours.

I think you figured out the second bullet, but just in case: the pairing code would only enable an observer to connect, after that it would expire but the observer would still be connected...generating another pairing code wouldn't kick any existing observers out, it would just allow another one to join. Removing an observer would be the same process that exists today (i.e., removing their enrollments or deleting them).

That "only one pairing code can be active at a time per student" rule is meant to keep someone from pressing that button a hundred times and generating a hundred codes that are all active at once. So that rule would say if you generate a second code right after the first, the first would expire. But it would also mean if two parents want to connect they would either join one after the other using two different pairing codes or else share a login.

One doesn't have to be the limit for active codes per student, but there should be a limit. To Matt's third point, if we restrict it to five active codes per student, we limit the chances of there being conflicts between multiple people creating codes for one parent. In other words, a parent could receive two codes, and they'd both work for 24 hours.

On who can create the pairing codes: as long as self-registration is enabled, a student could create one for herself and a teacher or admin could create one for any student. We could restrict it to just admins, but I feel like there isn't much risk in allowing teachers to facilitate it, too. (I'm open to feedback on this - I just would rather not need to create a Canvas permission to deal with it.)

[MattHanes]

This sounds great, thanks for the clarification! I'll shut up now so you can get back to work and we can have this ready for August :smileygrin:

[joseph_allen]

 @peytoncraighill  and  @MattHanes ,  I'm not sure I see the rationale for a pairing code? Can you explain that a little further?  If the parent is already an observer as established by our SIS and the nightly Canvas sync, why would we need a pairing code? Plus all registrations, pairs, etc really need to go through the system of record which is the SIS.  If we start to put people together, or even register students for classes anywhere other than the SIS, we start to lose data integrity.   

[joseph_allen]

 @MattHanes  and  @peytoncraighill , 

In our environment, the teachers have no control over observers.  I'm not sure I'd go down the road of letting the teacher or student generate codes or pair people.  That seems to be the job of the SIS.   If there is a use case that I'm not aware of that necessitates this, could you please outline that, but also make this idea of codes a feature that can be turn off for those that just want the SIS path.  Thanks. 

[joseph_allen]

 @peytoncraighill , I'm leery of the pairing code as I mentioned in a few other posts on this thread, but we also have the legal issue.  We wouldn't want students or teachers putting observers on any student's account themselves.  Sometimes there are custody, privacy, and other legal issues which are documented and controlled through the SIS, but this would open a back door if anyone (student, teacher, or Canvas admin) could generate a code to enable the student / observer relationship. 

[MattHanes]

Not every school system has the resources for a seamless SIS integration with Canvas. This option allows teachers to proceed with using the app without having to involve programmers and developers. 

[MattHanes]

In our past experience with self-enrollment tools like Remind, Edmodo, Google Classroom, Class Dojo, etc... our teachers seem to be much better at managing those custody and privacy issues than the central office since they see the kids everyday. 

[joseph_allen]

No problem.  I figured that was the case.   I would just want to be sure this is a feature that can be turned on/off depending on your districts needs.  

[peytoncraighill]

No worries,  @joseph_allen ‌! This pairing code idea would only be a feature if observer self-enrollment is enabled in your account. If you're provisioning observers from the SIS, your account probably has self-enrollment disabled.

[SHEBENE]

The difference I see with the educational tools mentioned is that they are less likely to have a ton of FERPA protected data and grades that are being sent to the SIS.  I agree with  @joseph_allen ‌ that I'm leery of going down the pairing road. Unfortunately for us, we're a large district that does allow self-enrollment. If pairing codes are on we would have some security concerns and turning it off will make it impossible for parents to join. Kind of the rock and hard place conundrum there, because trying to tie this in with our SIS and auto-provision all parents would create close to 700,000 observer accounts for us. Yikes.

[SHEBENE]

As commented above, that would still be a pain point for us as we allow self-enrollment but see the problem of generating pairing codes. I foresee some CSS hiding of buttons in our future.

[peytoncraighill]

Feel free to share concerns about security with the pairing code here! It seems very similar to today's solution that requires the student password, but with the proposed solution, the code basically acts as a time-limited, single-use password and works with auth types other than Canvas auth. (That's to say - if you're a school/district using self-registration, the proposed method seems more secure and more flexible.)

[peytoncraighill]

Diverging threads...see my response above 

[MattHanes]

You nailed this answer, Peyton. I didn't even think about it that way. The way it works in our SIS system is we can control who has access to print the SIS portal access letters. The school clerks print them out at the beginning of the year and keeps them on file. A parent has to come to the school and show ID to get their form. Most of them get it during registration or open house. They only have to do it once per child because it carries over year to year. We can revoke access at any time because of custody issues. 

I think that's a little much considering we don't do that for any of the other dozen or so apps that teachers use. But it might be a happy compromise. I make school-wide courses that have every student in them that administrators could use to generate the pairing codes for all of the students at once. 

[kristin_bayless]

Peyton, we're thrilled to hear this.  Due to the issues you describe, we'd decided not to open the app and to restrict parents to the browser version.  Our sign-ups have been minimal, which in part is due to the restriction.  Very happy to hear about your plans!

[Bobby2]

 @peytoncraighill is there any plan in the future for courses to be viewable in the Parent App?

[peytoncraighill]

Hey  @Bobby2 ‌ -

Good question! Presuming you're asking about giving parents the ability to navigate using the typical Canvas flow (select course, then select course component, then select component detail), here are some thoughts. We have tried/will keep trying to be thoughtful about the things we make available in the parent app for two reasons.

First, we want the app to be as immediately intuitive as possible because parents receive a lot less training and guidance in Canvas than most people. This is a big problem today that we think will be significantly improved in 2.0.

Second, in some tension with the first, we're aware of the role Canvas could play in enabling helicopter parenting and we want to minimize it. Here the convenience of a mobile app is a double-edged sword. We want the parent app to simply answer how's my kid doing and what's coming up. It could be that we don't answer those questions well enough today (see: no messaging teachers, no viewing student submissions), but that's the balance we're trying to strike.

We don't have plans to add course navigation to the parent app right now, but we do have some ideas about answering the questions above in better ways. For now, parents looking for the full Canvas experience have the options of using the student app or web browser.

[Bobby2]

Splendid reply  @peytoncraighill 

I'm very aware of teachers and parents LOVING the Seesaw experience and it's detracting from Canvas uptake.

[kristin_bayless]

 @Bobby2 , this is an interesting observation from the parent perspective.  We also use Seesaw in conjunction with Canvas for our elementary schools.  We've found Seesaw to be an excellent pathway to Canvas.  It's very easy for teachers to get started with Seesaw, but soon hit the limits of it's capabilities and begin using Canvas in the LMS capacity.  Do you feel the parents are influencing the teachers in staying only with Seesaw?  We've liked the way the two systems have played together so far, but we're just getting started with Canvas parent accounts.  It would be good to know how the parent dynamic could affect our use of the two products. Thanks for any advice!

[Bobby2]

 @kristin_bayless are you embedding Seesaw into Canvas or are they being used separately? How are the systems 'playing together?'

It's very early Canvas days here. We are noticing primary teachers are reluctant to use Canvas as they are loving the Seesaw experience so much. I'm glad that your people have realised its limitations after a while. Hopefully that will happen here soon. 

[kristin_bayless]

 @Bobby2 No, we don't have any link from Seesaw to Canvas.  We're 1:1 iPad district.  The students use the apps instead of browser versions.  It makes it easier for them to switch back and forth between the two systems.  When I last spoke with Seesaw, they continued to maintain that they aren't attempting to be an LMS.  If that continues, it will be easier to provide a clear path of functionality between Seesaw and Canvas.  Seesaw is such an easy point of entry for teachers to get their classrooms online. Lots more ES teachers are using it than the are Canvas - but we do have quite a few of our ES teachers who use both.

[Bobby2]

That's a cool way to look at it  @kristin_bayless . You have helped me change my attitude to what was previously a 'frenemy'. 

[rseilham]

I'm curious how many helicopter-type parents just have their kid's login information anyways. : /

[KristinL]

*sigh* yes. ...this thought worries me. :smileyshocked:

[bdoran]

In case you missed it... there is now a "Canvas Parent 2.0 Update" post from Peyton Craighill!!