School Portal

McIntire needed a refreshed information strategy – one that would facilitate discoverability, distribution, and relevancy. To power that strategy, we built a robust portal system that features custom user experiences, streamlined content management workflows, and smart integrations.

Tools
  • React
  • Drupal

The Challenge

Before the portal, there was a long-running joke at McIntire: where do you find a policy or document? If you didn't work here on the day it was emailed out, then the answer is nowhere. Information storage was de-centralized and inconsistent: some departments used Google Drive, others used Box, Dropbox, G Drive, stone tablets...you get the picture. Exacerbating the problem further, the chief mechanism for disseminating information was email, or posting material to the public website.

While not abnormal in higher education, these tendencies gave way to something akin to the Cygnus X-1 black hole: information was created, and then immediately sucked into an infinite void, never to be seen or heard from again. Not surprisingly, the effects trickled down to students.

During focus group sessions, students unanimously indicated that the “information sprawl” created friction: it was cumbersome to find what you needed when you needed it, assuming you were even aware of its existence. On top of that, most participants reported that they had to log into at least 9 different systems to complete the required daily functions.

To remedy this problem, we embraced internal information creation and communication workflows as a foundational piece of our overarching mission to Netflix the students' digital experience,which meant we had to make the process and product intuitive, flexible and calibrated to the individual.

And thus the portal took shape.

System Design

Streamlined workflow and a modern stack

There are two primary players: a headless Drupal CMS and a React web app. All content is generated within the CMS and served up to the frontend via the JSON:API. That setup is actually pretty gnarly under the hood, largely because of the way Drupal handles entity relationships, but we wanted to use a system that content authors were already accustomed to working with, so Drupal fit the bill. We've also wired up a super flexible query builder that can pull in data from any number of external sources in order to centralize content created from within other systems.

System Feature

Simplified sign-on and calibrated content

To eliminate the need to create yet another set of login credentials, we decided to leverage the University's single sign-on protocol (SAML). As an added bonus, this approach gives us direct access to some base user data in order to conditionally render a dashboard tailored to the individual. Combine that with a robust taxonomy system and voila, we created 14 customized “portals” within one app.

System Feature

Search and discovery

Given the volume of content, we needed to come up with clever ways to guide the user toward the information they’re looking for. We wired up a Swiftype search engine that can crawl the protected content (using a custom user agent) and returns only the results that are tagged with the user’s affiliation. But it doesn’t stop there… A couple of other useful mechanisms include sunset dates, related content feeds, and weekly digest emails.

System Feature

Masquerade mode

We’ve worked hard to make the content management process as smooth as possible. Authors are creating content for other users, but they’re also portal users themselves. Masquerade mode allows designated users to toggle back and forth between their own portal and that of any other audience type -- a feature that has been particularly helpful for advisors and faculty members working directly with students.

Related Projects