Commentary, Development, Ideas, Prototyping, Research

Project Summary

Leave a comment

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).

Gunnar Petzäll on Google+
Uncategorized

Student Survey

Leave a comment

Group 4 (Rachel Borkala, Cameron Brown and Chad Adams) of the ID module were nice enough to let our group use their survey result data if we helped them get some more answers.

Survey

The system used was SurveyMonkey, which has its limitations (but is free!). I have summarised the data in these two files:

Their survey is not ideally designed for our use, but creates a nice addition to student insights besides our own interviews and, primarily, our own experiences. Primarily, it’s very hard to get a lot of answers (something we know from previous assignment work), so even though there is some redundant information in this survey it is still useful for us.

Among its flaws include questions about alumni (primarily focused on their app’s research) and that each question is a free text field rather than a tick box. The drawback with the latter is that the summary will have to be subjectively categorised to make any sense: the raw data is hard to overview or digest. Naturally, the biggest flaw is a lack of spread over the years, freshers as respondants and the low number (16). However, it is hard to find respondants, and the result is still useful.

An advantage of the free text answers is that the topics chosen likely are things that the students remember more vividly, and can bring us additional tips for development we had not considered.

Summary of findings

16 individuals answered the survey questions, and the only question where a participant skipped was for if they knew any famous UWE alumni, which has been interpreted in the summary as a “no”.

All of the respondants are UWE undergraduates where most are on their last year. Three freshers and one second year responded. All of them study at Frenchay.

Problems encountered starting uni

Corresponding with our general questions of peers, the most prominent issue students found upon arriving to university is to navigate the campus with its different buildings and floors: 2/3 students brought this up as a primary concern and many only said this. After that issue there is an even spread of concerns, where social themes rule.

For our app it’s worth noting they mention finding bus times and free computers; something we had not previously considered.

Important when starting uni

Under this topic, it was again a prominent idea to have help navigating the campus. Some specified that this wasn’t so needed after the first year or the first few weeks but the emphasis is here.

The second big theme is about the social context at UWE, like finding roommates, classmates, new friends, parties and about life at uni. The third main theme are the practical details like course material requirements and how to deal with these in a new environment.

Would a navigation app be useful?

Even more respondants than for defining problems at uni (13/16) felt this was a good idea for an app, especially in first year: Two out of the three that disagreed would have liked it in first year, meaning 15/16 respondants would have liked it when first starting university and two positive answers said they would like it even in the last year.

Takeaways

A couple of extra possible features were identified, and our own ideas about useful apps at uni was confirmed by a decently sized amount of fellow students. The fact that many of these were third years and still felt navigation was useful is notable as is the focus on a need for better socialisation and time management.

The fact that many were third year students could possibly mean they had forgotten more about being a fresher, but as our own team has felt, navigation, social interaction and time management (and event notifications) really are the key points for new students at UWE Frenchay.

Seeing as the other campuses will eventually merge with Frenchay means we put less emphasis on these at the moment, but it is likely at least the social side and time management would be equally important to them.

 

Gunnar Petzäll on Google+
Planning

Interstudent communication

Leave a comment

The over-all idea of the app is to create a feeling of confidence and comfort. Practical problems should not be issues and dealing with time, place and parties (through the calendar) should help with that.

One idea that I am really excited about, however, is to use an IRC-like functionality that is based primarily on locations. It is a simple idea, but could be a lot of fun. The reason this feature would be strong enough to make people use it instead of using WhatsApp is that it comes with a lot of preset lists and the localisation functionality.

Channels: rooms, courses, modules, societies, groups etc…

If a user is in a particular location, the local chat room (or “channel”) for, say, the Hive would be available, and the user can see how many people are “active” in the Hive and join with a single tap. This captures a lot of the excitement of IRC chat rooms from when Internet was a bit younger (though thousands of people still use IRC!), but adds the slightly random variable of where a person is located, physically. The additional advantage here is that you and another person may speak in private (in the app this shows as another channel) and can stand up at the same time (or not!) and meet a person you have already spoken to.

(to be continued)

Gunnar Petzäll on Google+
Ideas, Prototyping

Wireframe sketeches scanned

Leave a comment

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.

Gunnar Petzäll on Google+
Storyboards

About Storyboards and Social

Leave a comment

Storyboards have been one of our primary inspiration so far for ideas, following our initial brainstorming sessions and the Extreme/Expert interview with User N. So far we have made three, which each deals with an aspect of the app’s features.

It’s worth noting that from a chronological perspective, they should really go like this:

  1. Storyboard two – What are the feelings and aspirations of coming to uni; how can the app help in an early stage of the university process, especially for an international student? The focus is about provding confidence and perhaps even comfort. Everything will be fine.
  2. Storyboard one – Arrived at uni and settled in student accomodation; how to get to places in time. This story board highlights features more, but a heavy focus is still on taking care of the student, dealing with practical issues and possible “catastrophes”. This gives a brief insight into the more social aspects of the app, communicating to students who are physically in specific places.
  3. Storyboard three – This may even take place the same day as storyboard one. The student student has had lunch, either way, and is going to the next lecture, but doesn’t know the way. These are focused on Q-block both because we know it fairly well, but also because it actually is a bit of a labyrinth, especially for new students. Primarily this highlights the usage of the app when the primary technology (GPS) fails. This is also about confidence and keeping the user in a mindset where details like where to go isn’t actively part of any conscious worries.
  4. Storyboard four – One we haven’t yet decided if we are doing or not. It would entail social interactions like speaking to a person in the same room (like the Hive) and meeting a new friend and/or creating a custom group or the like. However, a lot of this would simply be lots of pictures of the interface of the app, so it doesn’t seem perfect for this medium. Something we may explore further in prototyping.
Gunnar Petzäll on Google+