Category Archives: Prototyping

Lo-fi & hi-fi non-interactive prototypes

Project Summary

This post is added to summarise what the UWE Life app project has been about. This blog and the project has been done by Ben Argo, Dushyant Kanungo and Gunnar Petzäll.

It started as an assignment but may be taken up and paid for development by the UWE Students’ Union to be a live app. The team received on average over 70/100 marks (a First) for our individual and group work for the module.

Specification

The specification for this assignment of the lvl 3 Interaction Design module of the Web Design BSc (Hons) degree at the University of the West of England (UWE) asked for the design of an application using user-centered design methodologies that related to geolocation and enhanced the student experience.

The Ideas

A number of ideas were created by the three team mates and made into a synthesis that we were bringing forward.

Research

Research started with a big brainstorming using whiteboard and the first story board envisioned by the team and the first big stakeholder/expert interview.  Additional research included:

Prototyping

Prototyping was done continously from the very first wireframes, more detailed ones and into the PoP prototype. Each of the stages and even each of intermittent sketches were improved by feedback from users taken from our peer group for different levels of user testing.

Following a “working app” with PoP, a first version of High Fidelity prototype was made and was presented to the lecturer and the rest of the cohort.

Feedback from the presentation and further user testing was used to create the final UWE Life app demo available to try. This was also presented (video link will be added here).

Wireframe sketeches scanned

These are the four pages of the first try with detailed wireframes:

Making these early sketches of the wireframes made me think of a number of additional changes immediately. As we test it out I’m sure many others will be apparent.

Login (first sketch, page 1)prototype scan 3
I forgot to add the “QuickMap” link, so it is a little lower than it should, and there should be a help button as well. The idea is that even users who are not logged in can use the map if they wish to, but it doesn’t include any social features or link up with your calendar. Since the map feature may be the most attractive feature to start with for a new student who is unfamiliar with the social bit, we realise this may be a very low threshold and could mean some users do not sign in, which in turn be detrimental to the social features and the longevity of the app. However, even just being able to automatically find the way to the next class and peer usage of the app is probably weighing up for this. It just seems prudent to make a solid app that people feel is useful and entice rather than force login.

The login will work on either the UWE welcome ID or their UWE login details. Considering they can get the app before coming to campus, the wayfinder could be used just to check the place out!

Main screen (second sketch, page 1)
This is the main view of the app, showing the location (or approximate, or latest) of the user. The app work best with GPS, but there are two fallbacks (more later).

In this view, the user can see some amenities like food places or water fountains. Perhaps toilets should be added? At the top of the screen is the title and menu button, a universally known icon now. A point that came up as I was drawing is that the page needs to be very free from clutter, so some sort of maximum would be shown based on proximity or some sort of priority order. Either way it seems reasonable to keep these down to about 5 (customisable in settings).

In the upper left is the two most relevant chat groups for the user. R-BLOCK apparently has 58 active members in cinversation(s) and the Sci-Fi society the user joined in Freshers’ Week has five (there are entirely different sets of ideas how the “relevance” should work; more later).

In the lower left is a temporarily button called “Find it”, which is the wayfinder or whatever its final name will be, to quickly find out where some place is and get help to get there (more later).

In the lower right corner is an overview of today’s schedule in clock form. It’s too small to show any details, but it gives a very visual feel for when a particular lecture (or booked meeting) is. This graphical idea was also born as I was drawing the sketch. Tapping on the clock brings up the schedule proper.

App menu (third sketch, page 1)
This is what a user sees if she taps the menu button. It’s an approximate list of the items that would be in it and an approximate order.

Find it / Wayfinder (first sketch, page 2)prorotype scan 1
An idea that became apparent as this was drawn on paper was that under the main options (“Next Lecture” and “Enter room number”) the app could have smaller icons of preset places, places like the SU locations. While WRITING this very sentence (or rather, the previous one) it seems obvious that it should also be possible to edit these presets and add custom ones.

The “Next Lecture” will pick the next one, even if it is hours away. Could be useful to get an idea of where the next is, wherever you are. Room number should be self-explanatory. The advantage of having it is that a person can match routes from places she is not at to places she will not go, to show someone else (for instance), or a route she will have to do in the future.

The back-button would not be available one Android and phones who have a back button. Ben also came with the idea that it could be swiped like on some apps on iPhone where a special function can feel whether you swiped from the VERY edge of the screen or ON the screen. Anyway, that is an issue for later; there may or may not be a back-button.

No GPS (second sketch, page 2)
Having decided where to go, the app will take you there unless your GPS is off or not working (it sometimes doesn’t work inside). If that is the case, this view will be shown, asking the user to either turn GPS on (which should be the top option), touch a NFC device (which every room would have), scan a QR-code (also on every door; the scanner would be built-in and automatically read the data) or manually enter a room number. As I am writing THIS I realise it may be useful to also be able to pick a quick-selection (if a person is outside Escape, doesn’t know the room number and can’t be bothered to move in to read it).

3D overview (third sketch, page 2)
Pretty much taken from Storyboard One, it will show the user a 3D overview of how to get to her destination. Note that this would be a static picture; some people just need a reminder, and making it wholly 3D may be a lot more work. If the user is several blocks away, the image would show a regular map with a route instead, until she came closer to the right block.

In the upper left corner the user can see where she is, and in the upper right a preiew of the schedule. The point here is to have NO OTHER things cluttering the map. It’s possible that block name letters may show, however.

If a user wants a guided tour to the destination, they can start the wayfinder, here called “Prat Nav”, but this is unlikely to be the final name.

Prat Nav / Wayfinderprototype scan 2 (first sketch, page 3)
Starting the wayfinder will show a 3D representation of where to go (with or without arrows). This may be a literal 3D rendering or possibly photographs ala Google StreetView.

The schedule is previewed and if the user does not use GPS, she can manually click herself forward on the screen (or use NFC touches) to move the guide along. If the GPS works, it will instead move this automatically. An idea as I was writing this up is to turn the screen red with a “turn around” symbol if they take a wrong turn like on Storyboard Three.

Calendar (second sketch, page 3)
If the user accesses the calendar/schedule from any way she can do this, a page similar to this would come up, where she can swipe left or right for days or up and down for the day she is on (a lot like any calendar out there). The only difference between this calendar and others is the functionality of actually tapping one of the boxes…

As we were reviewing this, Ben mentioned that we may rethink the technical option we chose: web-based app (shell app with website in it) as things like calendar integration with the device’s calendar wouldn’t work, and it could also be issues with using or turning on GPS.

Lecture (third sketch, page 3)
If a box is tapped, the lecture details pops up together with two chat rooms: one for the module and one for the room, showing how many are chatting there. This is how the Storyboard One meant and how Storyboard Two hints at (though that is for the course, not module).

Though this is likely a function we may drop, the user can also see the availability of the lecturer in this view and/or if there is a substitute this day.

Chat (first/second sketch, page 4)prototype scan 4
Another blog post will shortly be made on the general idea about communication.

Clicking a chat icon at any place or starting chat via the menu would open a view like this one. Focus here is on ease of entering and ease of exiting it. My original idea was to have the list of “channels” be slidable at the top (see the pic next to the first one), however from a conversation with Ben, one of us quite insightfully pointed out that the whole chat could just as easily be slided. It would be the same effort but without having to tap the chat, and may also encourage other social interaction.