Back in December, I requested feedback from our one-to-one schools about their experience with the Canvas mobile apps. I have talked to representatives from about a dozen institutions since then, and I’ve received emails from several others. As expected, each institution had unique concerns, but I wanted to report back with some common themes for the benefit of the group. Here’s what I heard, starting with the most pain:
1. Limited teacher functionality
Many respondents indicated that the lack of teacher-specific functionality was their biggest concern about Canvas in mobile (e.g., Teachers can’t edit assignment details, SpeedGrader in mobile is too slow, etc.). We’re in the process of creating a Canvas Teacher app, which will allow teachers to “Canvas more efficiently.” If you’re interested in helping us create something great, fill out the Canvas Teacher App Focus Group form (or forward it to your teachers) to register for the Canvas Teacher beta app and focus group.
2. Integration issues
Openness is a foundation of Canvas. Specifically in this case, I mean that if we can’t or don’t provide some service for you, we want you to be able to fill the gap with some other service of your choice through an integration with Canvas. Oftentimes these integrations happen through the use of LTI.
Unfortunately, openness isn’t necessarily what makes native mobile apps so successful, particularly compared to web applications (see: app approval process, platform-specific programming languages, platform-specific apps, etc.). The LTI standard allows some really useful tools to be embedded in Canvas, but it doesn’t provide much direction for how those tools should be integrated in the mobile world. As a result, native mobile apps today can only present LTI tools in web views and hope for the best. Any particular tool can be made to work, and many do out of the box, but there’s no standard for how all tools should work on all platforms. (I mention LTI because it’s a particularly popular standard for integrating rich tools, but even content as simple as an embedded video isn’t guaranteed to play nicely in the mobile realm.)
Particularly if you expect students to access Canvas primarily through the native mobile apps, be sure to regularly test the content you create as you create it. If there’s a tool that isn’t working in our mobile apps and you can’t immediately find an alternative, know that the only way we hear about those issues is through support tickets—don’t be shy about submitting them. Our iOS and Android teams regularly address tickets about “[tool x] not working in [app y].”
3. Limited student functionality
Here’s the bad news (for some): Native functionality in our mobile apps won’t ever be at 100% parity with web functionality. With good reason, for every mobile engineer, we have four web engineers, and keeping up with every new web project isn’t realistic for us.
Here’s the good news: We don’t have to keep up with every new web project natively to allow students to fully participate from mobile devices. Our new quizzes application, for example, is being built from the ground up with responsive design in mind, which means that the day the tool launches, students will be able to take quizzes on mobile devices without requiring any native mobile work. This is a really, really exciting development.
At the same time, one of the reasons why Canvas is the highest-rated LMS mobile app is because it isn’t just a portal to web views around Canvas—it offers a relatively well-rounded native experience. That’s not going away. In fact, with the development of our teacher app, we’re trying out a new technology that would allow web engineers to crank out native mobile code without needing to know specifics about iOS and Android development. If this process works, our native mobile teams can focus on refining the user experience and building other mobile-specific functionality while web teams focus on functional parity across platforms.
The focus for our student app moving forward is in three areas, starting with the most important:
Closing gaps in functional parity between web and mobile (using whatever technology makes sense, see above).
Closing stylistic gaps between mobile platforms. A common Canvas style is more important to our users than fidelity to traditional iOS or Android styles.
Respecting custom themes within our mobile apps. Many people spend time making Canvas web look just-so, and we want those styles to naturally extend to mobile.
We should make a lot of progress in these areas over the course of the next year.
Lastly, in late 2016, we open-sourced our most popular native mobile apps, and in response, some schools are already in the process of building their own native apps. The Canvas APIs are robust, and our in-house mobile apps use them in the same way as any other mobile app would. So if you hate what we’re doing, it’s worth considering alternative options in the open-source realm. (And hey, a last resort for some is an exciting project for others!)
Our mobile apps hover above 99% crash-free sessions (iOS Canvas is 99.5% crash-free today, and Android Canvas is at 99.62%), so typically crashes aren’t widespread issues. More often—but hopefully not often—students experience non-fatal errors when some piece of the app fails to load. The causes of these errors are diverse, from buggy code to connection timeouts to loss of connection and so on.
There are a couple of things we’re doing to address these concerns. First, we’re auditing our apps to remove stupid errors. For example, if a request fails for a particular reason, we might silently retry the request without displaying an error, or we might display an error message that makes more sense than “An error occurred”, or we might not display an error at all if the failure isn’t user-facing. Second, we’re beginning to automate mobile app testing. Today, we run manual tests on existing and new functionality of every release of Canvas. But Canvas is a huge app, and it’s impossible for a person to catch every issue. Automated testing will help us to reliably and efficiently catch more issues before shipping an app update. Automation is already used in Canvas web today, but it’s a relatively new technology in mobile that we’re attempting to incorporate for the first time in the development of our teacher app before expanding test coverage to our other apps.
Thanks so much to everyone who took the time to let us know how things are going. Your feedback is incredibly important, and it’s diverse, and it’s understood. Keep the emails and phone calls and community posts and user groups and support tickets coming. Whether you bring us good or sad news, your thoughts matters to us, and we use your feedback to try and maximize the utility of Canvas for everyone.