How Instructure Does Mobile

Instructure
Instructure
5 0 492

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!

About the Author
I’ve worked in product management at Instructure for five years. I love my teams, and Canvas, and solving problems to make Canvas better.