Tag Archives: university

Top Mobile Apps Adopted By US Universities

The launch of the iPhone a decade ago in combination with the app-store-based distribution model set in motion the conditions for mobile applications to become mainstream in an easy, user-friendly way. However, it was since even before this development that colleges and universities have seen both the potential, and the necessity, of adopting mobile applications to better serve their student populations. Our newest research affirms the growing pervasiveness of mobile technologies on US campuses.

For the first time, we are publishing data on the mobile apps that schools adopt at an institution-wide scale. To appear in this data set, the app must have some official or material connection to a university and be adopted or implemented in such way that it would be useful to a broad user base and contain content or functional capabilities that are relevant to that specific school’s needs (that is, not generic in nature). What we are measuring is the number of mobile apps adopted by institutions, not the number of downloads by individual users nor the number of downloads or popularity of consumer apps among college students.

Types of Mobile Apps

What we found is that over 700 institutions have implemented one or more mobile applications of this type. We clustered the types of apps into these 5 categories based on their primary purpose:

  • The “Campus App” –  a “one-stop-shop” for information, including information only accessible with a specific student login, typically designed for currently-enrolled students
  • Events/News/Alerts/Outreach apps that contain a calendar or content targeted at external audiences including local communities, sports fans, or for recruiting prospective students
  • Tour/Map/Transit apps that focus primarily on navigation around campus
  • Educational/Student Support apps that focus on serving some direct, unique, educational purpose (largely excluding LMS mobile apps) or student advising
  • Dining/Payment apps for displaying cafeteria menus and supporting mobile payment options specific to a given campus

The mobile applications adopted by each institution vary widely.  Smaller universities tend to implement a single, single-purpose app. Larger universities tend to implement several apps including a campus app that connects to and integrates with multiple other campus systems.

As you can see in the graphic below, the campus app is the category that has experienced the largest adoption in US higher education. Together with apps that support outreach to local communities and prospective students, these two categories encompass more than 75% of all mobile applications. It is worth noting that the mobile applications experiencing the most adoption are largely not focused on meeting purely academic needs, often containing multiple capabilities such as registration, student communities, social media updates, a phone directory, and event calendars. The majority of widely-adopted campus apps also have the ability for individual students to log in to display information relevant to that specific student. 

Notable Platforms

Focusing specifically on the campus app category, only a minority of schools self-publish their own app under their own institution’s vendor name even when using an app framework or codebase provided by a consultant, vendor, or open source community. The majority build on top of, or integrate with, one of several major mobile platforms that are branded as being provided by that vendor.  OOHLALA and Blackboard Mosaic capture almost half of these type of campus app implementations with DubLabs, Unifyed, and Modo Labs all tied for third-place.

Note: We have adjusted this graphic since the original post to include self-published apps. It is, again, important to be aware that self-published apps are more-often-than-not created by a specialized mobile application development shop or by one of the vendors mentioned above. Most institutions do not develop their own apps.

Other popular mobile platforms include Guidebook, which provides a platform that can be used to display relevant information to prospective students and YouVisit, a popular mobile platform for providing virtual tours of campus (including VR tours).

Other Findings

While performing this research, we also came across a number of other findings that relate to mobile strategy on campus.

Quality Matters

Apps that are rated the lowest in each app store are correlated with a poor first experience opening the app, generally caused by a technical glitch or a slow or inconsistent load time. The student expectation is that each app “just works.” Conversely, apps that are rated highly generally feature content that is kept up-to-date and features that are relevant to their needs.

Responsive Design Versus “M dot”

While there has historically been a convention of hosting mobile web content at m dot school dot edu (for example, m.psu.edu), this is a significantly less popular approach than using responsive CSS design on the institution’s regular home page. Most modern mobile phones can correctly render web sites in ways that were not possible in years past. Our recommendation is to design for the default browser on each mobile platform (Chrome for Android and Safari for iOS) and consider Firefox mobile.

Official Apps Versus Unofficial Ones

When searching each app store, it is actually somewhat difficult to distinguish a “real” university mobile app from an unofficial one. While most unofficial apps are written by enthusiastic students or alumni, many appear to be suspicious in nature and built on top of advertising platforms. Our recommendation is that universities should attempt to control their brands however possible to prevent confusion, or worse, while supporting sanctioned innovation.

App Proliferation

Many universities appear to have decentralized funding sources for mobile apps and lack a unified mobile strategy. Particularly among larger universities, this results in multiple official apps that lack consistency or defined purpose. Our recommendation is to differentiate apps based on audience (e.g.: internal vs external) rather than function.

VR (Virtual Reality) Mobile Apps

While many experts have suspected that Virtual Reality would take off in the classroom, VR’s largest impact in higher education appears to be to support virtual campus tours. Using this technology allows potential students to more-fully understand the physical campus experience without the expense of travel.

LMS Apps

Our latest LMS data set suggests that almost all universities are currently running a LMS that supports a corresponding, free mobile app. Unless a school went out of its way to actively promote the LMS mobile app as a core part of the student experience, we did not include it in this report. Generally, we did not find institutional adoption of apps that focused specifically on learning or learning content separately from the LMS app.

Dead Apps

During our research, we found quite a number of broken links to discontinued mobile apps. Blackboard’s recent decommission of Mobile Learn in favor of a pair of separate student and instructor-focused apps, for example, leaves a trail of broken links. Smaller mobile vendors or independent consultants that have ceased operations or gone out of business are also correlated with this condition.

For inquiries, please contact marketdata@clientstat.com

Flipping the Model: The Campus API

Note: While I generally prefer to keep work and life separate to the extent possible, this is one of those occasions where my professional experience, personal interests, and graduate student coursework happen to intersect. This post reflects neither the thoughts nor opinions of my employer.

Though I found out about it too late to attend, I was excited to learn about the recent University API workshop hosted by BYU. It’s the first time I’ve heard of such an event having a distinct focus specifically on APIs and universities. Thank you to those institutions who are providing some initial momentum here. One of my previous jobs was as a developer who helped educators and software engineers to use APIs to integrate with LMSs, and over the past two years I’ve been fortunate to work for UMUC where I do very much the same on a much more local and meaningful level. Over this time, the team I work on has replaced the university’s home-grown LMS with a commercial one, and in doing so rebuilt and rewired integrations with many new and existing back-and-front-end systems.

Needless to say, open standards have played a critical role in achieving this vision. But while they help in many ways, they aren’t best-suited for every application that we want to build, and a standards-compliant LMS alone does not an online student experience make. To address these needs, one of my team’s more recent projects has been to develop a REST API that could be used by anyone at the university to build apps. It slurps in data from a whole array of back-end systems – including those that don’t currently and don’t ever plan to support open standards. For example, these APIs can retrieve user profile data from the identity management system, enrollment data from the SIS, and even the balance due from the financial system. By unifying all of these systems behind the facade of an easy-to-use API, other teams around the university (ie: not just “central IT”) have been experimenting with rapid prototypes of apps and portals that will soon modernize a number of random legacy applications and begin to facilitate the creation of new ones.

Previously, getting at this data required clunky point integrations with the SIS, LMS financial, authentication, identity management, and other administrative systems. These integrations often require designing for complexity and specialized skill sets to use each vendor’s API. They are also brittle and prone to breaking with each upgrade, increasing risk and the level of ongoing QA effort required.

current_state
Legacy architecture. Point to point integrations mean increased QA efforts whenever any one system is modified or upgraded.

By inserting an API into the architecture, we can now provide logged-in users all of these details using simple calls that abstract away the behind-the-scenes complexity. It is enabling us to find ways not only to build new applications but also swap out legacy back-end systems behind the scenes without changing the nature of how these APIs are used on the front-end.

future_state
API-based architecture. Systems can be built on top of stable APIs and upgraded/replaced independent of each other with reduced QA effort.

There are many universities including Berkeley, University of Michigan, and University of Washington that have been experimenting with API efforts recently. Perhaps the most interesting ones I’ve come across are the efforts undertaken by BYU and University of Waterloo.  Their designs offer (what I think at this time are) the most complete assemblage of useful data aggregated across all of the systems a university would typically use.

Which brings me to my next thought.

What would happen if a university flipped the model of integrating its systems and instead of writing individual connectors to each vendor’s system, the university itself provided a standardized API for each of its vendors to use? This changes the dynamic of the relationship significantly. No longer does a vendor need to ask which SIS or LMS a particular institution uses. Rather, it only needs to know which version of the “campus API” or “university API” it implements. It also means that you don’t need to wait for a specific product to implement a specific version of a specific standard to move forward with an integration. You just write your implementation to the interface using whatever capability a given product offers and in doing so provide a facade that avoids this factor altogether.

Suddenly, universities can become much more flexible in how they can swap in/out, upgrade, and rearrange all of their systems behind the scenes. The overhead of implementing and QAing product integrations decreases by shifting the development responsibility for the integration to each vendor. Vendors benefit from a uniform way to connect to any university that implements the API.  Universities become better positioned to supply and control access to application data. Students receive an easier way to access their own data. The API itself then becomes a platform for innovation rather than any specific vendor’s product. Imagine different vendors offering competing course catalogs that adapt to a student’s major, academic progress, and personal interests – or the ability for students to slurp data feeds into any mobile app, not just the one offered by the university. Or imagine an enterprising capstone project team building the cafeteria menu app that your students always wanted but never received high enough priority to build – or even the ability for a student (or adult professional) to register for a specific class using a “Take My Class” button on a professor’s personal blog rather than logging in and searching through the cumbersome UI of most SISs. (Also imagine a university with a business model where you don’t need to become a full-blown student just to audit one class.) This is exciting stuff.

There are many resources to help universities understand APIs better. First, the EDUCAUSE ITANA Constituent Group hosts a subgroup focused solely on APIs and API governance. Kin Lane has written a helpful white paper that describes some of the above university API efforts (and their benefits) in greater detail. (Seriously, consult with him if you consider going down this path.) Finally,  the notes from BYU’s recent API workshop are hosted here.

There are also a pair of organizations who appear best-poised to tackle this challenge specifically in a higher-education-focused context.  Lingk is a very new startup that is focused on building a SaaS-style product with the ability to interoperate with a number of systems typically used on college campuses and expose their data in different, more-modern ways. Apidapter is a more-established startup that centralizes LTI launch requests within a single management framework so that usage details and error messages can be logged and trended. Apidapter also allows standards-based transactions to be transformed “mid-flight,” sometimes to augment the capability of the standard and other times to pull in additional data from other systems, such as an LDAP server, and adding these as LTI launch parameters before reaching the target system. (Disclosure, UMUC uses Apidapter under-the-covers for some of its LTI-based integrations. This is not a product recommendation. But seriously, it is cool, and you should go check it out.)

In my opinion, administrative systems are one of the greatest limiters of IT agility at colleges and universities specifically because of their complexity and inflexibility, whether real or perceived. Universities will face continued pressures to adapt more quickly to constant change, and an API could provide a stable, unified approach to better support innovation and accommodate IT change more easily so that we can collectively free ourselves from legacy IT challenges. Let’s get to it.

This post written by George Kroner