In Part 1, I talked about some of the issues with a portal, and how we might solve them. Now that we've identified the problems, how can we apply the solutions?
In this post, I'll be discussing some different models for constructing a portal, and the pros and cons of each approach.
Portal as knowledge base
The first model we could apply to our portal is that of knowledge base. Under this model, we assume that students are primarily coming to the portal to find information. They have a question they want answered, and we supply that answer.
The way to provide students with the best experience in this model is to make it easy for them to find the answers to their questions. We can do this using the task-based navigation we discussed in Part 1. This is the approach that the GOV.UK website is based on.
For example, we might create a section of the portal called "Get Help". Under this section, we would list various support areas such as Counselling, Chaplaincy, Tutoring, etc. We could also put some more straightforward services like administrative support in your school, or a link to the IT helpline. On each page, we include information about each service, who is eligible to use it, and how to access it.
The main benefit to this model is that it puts the focus exactly where it should be - on student needs and expectations. In order for our knowledge base to be successful, we need to understand how students are talking about and approaching issues.
Throughout this structure, we should focus on using simple language which is understandable to everyone, rather than internal jargon. We also need to do research to understand how students think about problems, so that we know what categories they should go under.
For example, if we are using descriptions like "chaplaincy", but students are actually searching for the term "church", we need to be able to accommodate this difference. One way we could do this is by providing a good search feature and using meta tagging to allow alternate phrasing.
This model also allows us to abstract away from our internal hierarchies and system structures. As I argued in the previous post, students shouldn't need to understand these in order to find information.
The downside to this approach is that the knowledge base solution is fairly non-technical, so we aren't necessarily providing them with any integration into our systems. The emphasis is on restructuring our portal navigation and language to meet user needs, rather than on technical enablers. So, students may be able to find how to do what they want fairly easily, but still struggle to actually complete the task.
We should also be careful in how we display content to users, as it can become quite wordy. We can resolve this by keeping information concise, and allowing users to click through to related websites to read more.
Portal as app store
The second model we could use for our portal is the app store. Under this model, we assume that students are primarily coming to the portal to find tools. To meet this need, we provide a directory of all of our systems and online services for students.
Using this model, we would create an individual listing for each of our services, displaying its name, some information about it, and maybe an icon or screenshot. We'll need a good search functionality for students to find our content. We might even include some functionality for students to rate and review content, as commonly found on most app stores.
For convenience, we should also provide a place for listing top-used services so that they can be found easily. We can even tailor this listing to what we know about the student - for example, undergraduate students may use different services from postgraduate students.
The pro to this model from an institutional perspective is that it is not opinionated:
- It doesn't "prefer" any content over another, all content is presented equally
- It allows lots of content to be easily supported within the interface
- It offers a "hands off" approach where students are in complete control over how to access and use content
From a web development perspective, we also get some other benefits:
- It allows us to use a UI pattern that students are already familiar with through use of mobile app stores
- It allows our team to do quick development and deployment, as each app is a standalone piece
So far this is sounding very positive - the ability to do development work easily is not a negligible point. However, there are downsides as well.
The con to the app store is that, at heart, this is still the same portal as before. We haven't actually changed the way that students access our portal (although we've made it easier for them to do so). We've simply put a prettier skin over it. This means that we will have all of the same problems that we had in our original portal:
- Separated services
- Too much content (the "everything and the kitchen sink" approach)
- Alignment to internal org structure, rather than student understanding
We could improve this by changing our apps to align to student tasks, rather than services (following the same idea as our knowledge base). For example, we could offer students a "My courses" app showing an integrated display of their course content, rather than separate apps for their course details, VLE (Virtual Learning Environment), and LMS (Learning Management System).
Portal as dashboard
The third and final model we could use for our portal is the dashboard. Under this approach, we are assuming that students are using the portal to find their personal information and tasks. To do this, we present a customised display of the student's details to them.
Again, this is a great model for students as they are already very familiar with it from profile pages on social media. Commercial sites such as Amazon also use a similar idea for "your account" page. The common flow for this pattern on most websites is:
- User signs in to the website.
- Somewhere (usually in the top right corner), they are given an option to access their profile or account information.
- On their profile page, they are shown details related to themselves, and given the opportunity to edit these.
It's easy to imagine how this flow could work on our University website as well:
- Student signs in to our University website
- On the top right corner, they see their ID photo and a link to access their dashboard
- On the dashboard, they see their personal information with options to edit certain items.
The pro to this model is that, as with the app store, it's one which students are very familiar with. Because it is so familiar, students enter it as expert users and can navigate around with very little prompting on our part.
It also resolves the issues with our old portal which we raised in Part 1:
- Integrated display of details which are relevant to the student, rather than individual services.
- Natural reduction in content, as we only show related items.
- Focus on the student perspective, with little or no reference to our internal hierarchy.
This model probably best fits our idea of a holistic, cohesive view of the student experience. By bringing everything together, we can give personalised information to our student on what is happening for them at any given time. Students can also see at a glance which items require their attention when they sign in.
Despite this, there are still some downsides to this approach. First, you'll notice that when I was discussing the pattern above, I used different descriptors in each case. For the common commercial pattern, I used profile page or account page. When describing our portal, I used dashboard.
The reason for this is that our portal will probably need to be a bit more than a profile page. We will want to show students their relevant information, tasks, and access to services - as well as their personal details. This gap between dashboard and profile page could be confusing for students, as we're changing the common interaction pattern that they're accustomed to.
There are also some cases where our dashboard can't act in the same way as a social media profile. For example, we may not want students to be able to update their home address directly as it could affect their fee status. Instead, they might have to request the change and have it checked and signed off by a staff member. Again, we have changed the interaction pattern in a way that could be confusing to students. To mitigate this, we will need to be aware of the differences and be careful in how we present this to users. In the above example, we could provide a visual cue by presenting fields which cannot be updated directly differently to the user, and adding some help text.
Another issue we may have with the dashboard is that it only shows a student items that are related to them personally. This is convenient, but it may make it harder for them to find information about services or tools which are deemed less relevant. This will need to be carefully managed to make sure that students are still able to easily find information elsewhere when they need it (for example, through our University website).
The dashboard also requires the most development effort, as we'll need to put slightly more thought into tailoring the presentation and layout. Each page and widget needs to be designed individually, as opposed to a knowledge base or app store where we are using a similar presentation in each section.
Which is best?
The decision of which model is the best for your organisation isn't a straightforward one, as each has its advantages and disadvantages. The best way to approach this is to think about the question that your portal is trying to answer. Why are students coming to your portal? What problem do they want to solve? Is it:
- To find information related to a task they want to do?
- To find appropriate tools?
- To find out what is going on for them at any given time?
The role that your portal will play is most likely dependent on how these needs are being met elsewhere. There are also benefits to using a combined approach. For example, you could use an app store model, but structure it like a knowledge base.
At Edinburgh, we have decided to go down the route of "portal as dashboard" for our upcoming improvement work. This is partly because we already offer detailed information on our services and a service catalogue on our website. For us, the need that is not being met is a place where students' personal information is being pulled together in one place.
What about the technology?
Over the course of these two posts, I've said nothing about what technology we should use to build our portal. The reason for this is that we can deliver an almost identical user experience in just about any technology, language, or framework. We have chosen to use uPortal for our current implementation. This could change. We could decide to use a different framework or product. We could decide to build something from scratch.
This is not to say that it doesn't matter which technology we choose. There are still constraints - we probably want something that we can maintain easily, for example, and will perform well. This decision is also influenced by how our team is structured, what skills we have available, and what infrastructure we are using. There isn't necessarily an option which is "better" than the rest.
When we talk about what type of portal to use, the conversation can often focus too much on technology. It's important to remember here that our choice of technology is fairly arbitrary. The focus of what we build needs to be on how we can deliver value to our users. This is completely independent of any tool. We could be using the fastest, most bleeding-edge framework available, but still be delivering something that is completely unusable.
So, let's bring the conversation back to our users. If we're going to build a student portal, our first question shouldn't be about the technical implementation. We should be asking ourselves, "What do our students really want?"