In our last blog post, we framed the Student Portal as a digital assistant that helps users organize data that interests them. In this post we will review the interface that is currently under development and take a closer look at one of the many widgets that the portal is comprised of. Please note that the portal is under development and these designs are subject to change over future iterations.
The portal is currently web-based and the aim is for users to have a great experience regardless of the device they access it on. This is achieved through responsive design techniques, which change the site layout and properties to best accommodate the device in use. To achieve this, the student portal front end is built using the Foundation framework, which provides a toolkit for rapid responsive development.
Here we see how the portal would appear on a wide display (likely a desktop computer).
The widgets are arranged in a grid that expands vertically as required. Users can add and remove widgets, change the order that they appear in, and alter the layout itself (2 columns, 4 columns and so on). While the aim is to give users as much flexibility as possible, they should not be able to opt out of some features such as emergency notifications, which are of high importance to everyone.
Here we see the same portal as it is displayed on a narrow device with touch capabilities, such as a smartphone.
A menu appears at the top to aid in navigation, and the widget takes up the full screen so the text is legible on a small device. What you can’t see is that users with touch capable devices can navigate between the pages with simple swipe gestures, just as they do in common native apps.
Now that you know a bit more about how widgets are displayed, let’s take a look at one in particular; the Routes widget.
This widget guides students from their current location to their next class on a map. To accomplish this it needs access to a combination of public and private data including:
- Where the user is – this is achieved with HTML5 given the user’s consent (private data)
- The current time (public data)
- Where they need to be and when they need to be there – a combination of:
- the user’s class enrolment (private data)
- class schedules and room numbers (public data)
- geo-location of rooms and routing data (a combination of public and private data)
- a campus base map (public data)
As you can see, it takes data from many different sources to build a useful widget. The routes themselves are provided by Environment Computing, and we thank them for their assistance.
Feeding additional data sources to this widget could produce even greater value. If we added parking lot locations for instance, new students could find their way back to X lot at the end of a school day.
What other data or features could improve this widget? Feel free to comment and share your ideas. You never know, they might show up in a future release!
Thank you to our portal team for this week’s guest post.