Category Archives: Planning

Interstudent communication

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)

Pre-prototype notes

Before starting to draw the prototype interface pages, I tried to figure out how it would fit together. This is a very rough idea of layout and used immediately to figure out one bad idea (to have two different map views). It is based on the ideas presented in all three story boards (one, two and three) starting with the login screen, the map functionalities, how the schedule ties in and how the social aspects would work. The social bit could be developed further in storyboarding, but I feel it probably will be a lot of screens with mainly text…

A point that was made was to adda “QuickMap” feature (or at least link) from the front page could be useful even if the user is not logged on. A third point is that it makes perfect sense to allow a user to manually enter room number as starting point if they want to view a path other than from where they are (or in the unlikely scenario where both NFC and QR code may be vandalised).

The flow diagram was for the “sat nav” functionality and immediately made it obvious that the most user-friendly way would be to ask for destination first, and then check if GPS is working, falling back on other solutions if it is not. This is why the diagram is a little oddly designed.

App function schematic

 

User Personas

Download PPT: User Personas

Corey Anderson

  • 18 years old from Dorset
  • Coming to UWE as a First Year student of Law at UWE
  • Likes video games, Pikachu, movies, chocolates, his childhood friends
  • He is shy but friendly person and trying real hard to prepare for the big change
  • He is not sure about what kind of people he is about to meet and that keeps him awake at night.
  • He is still in process to sort out living arrangements on Campus
  • A new city and a big campus looks a bit intimidating to him

Sidharth Malhotra

  • 21 year old International Student from Delhi, India
  • Coming to UWE for Masters Degree in Computer Forensic Sciences
  • He likes Indian food, Bollywood movies, making new friends and his mobile phone
  • He is very organised in planning for long term goals and for him everything has to be defined clearly before taking any decision
  • This is a very stressful period for him as he is looking forward to sort out his new life in a new country in terms of food, friends and housemates.

Freya Stealey

  • Freya is 19 year old first year student of Early Education coming to UWE
  • She is friendly but keeps her guard on all the times until she knows her surroundings and people well
  • She is a very lively girl who is very excited about the new life at UWE.
  • Freya is an athletic person who likes to play multiple sports and enjoys exercising as a part of her regular routine
  • She wants to learn more about the sports clubs and activities available on campus from the people who are already in doing it.
  • She likes socializing with new people but feels odd to be in company with strangers where there is nothing in common to talk about.

Primary Concerns

  • Cory: They say it is a huge campus with multiple blocks of classrooms. I am not sure how easy it will be to find the right classroom? If only I can find a classmate or some easy way of getting directions on campus?
  • Sidharth: If only I can figure out how many students there are in my class and which events they will be attending will ease a lot of pressure. And of course, if I can find Indian students, I have so many questions to ask!
  • Freya: I do not want to join multiple groups on social media to learn all about activities which will spam the timeline and not sure how to find people who share interest or class?

Tentative Questions

  • Cory: Is there a guidance app available to find people in my class or the classroom?
  • Sidharth: Is there any easy way to find other international students or people who are in my class to go to social events with?
  • Freya: Can I find one stop communication solution for everything university related chatter??

Final Action Plan

Supplementing the project plan, here are the final details in achieving the project objectives.

Based on the deadlines and deliverable, here is a individual task break-up for the team:

WP_20140308_008

  1. 4th Story Board – Dushy
  2. Drawing Lo-Fi Prototype – Gunnar
  3. Editing Project Requirements Analysis Document – Ben / Gunnar / Dushy
  4. Deliverable :  Lo-Fi Prototypes to POP Prototype – Ben
  5. Photoshop Hi-Fi Prototype – Dushy
  6. Deliverable : Powerpoint presentation – Gunnar
  7. Deliverable : POP prototype with Hi-Fi screens – Ben
  8. Deliverable : Personal Reports (2000 words each) – Ben / Gunnar / Dushy
  9. Deliverable : Functioning Prototype – Ben / Dushy / Gunnar

Project Plan

Introduction

A plan for this project was drawn this afternoon after a long tailed (which lasted over a few days) discussion among the team fellas.

With the focus on user centered design process, it was critical to cover the base rules set-up for a task of this proportion.  The team realizes the importance of the methodical approach required in approaching the subject in real world and in academics.

The task distribution also focused on fact that every member of the team is allocated suitable tasks to form their ‘Individual Research Contribution’ report at the end of the first phase of the project which ends on 20th March 2014.

A few tasks were broken into sub tasks and some of them require equal team participation.

Project Plan

The Process & Roles

  1. Conceptualization of Ideas – Team
  2. Primary Research – Team
    1. Extreme User Interviews
      1. User N (Tentative stakeholder) – Ben
      2. Web Designer – Gunnar
      3. Recently Arrived International Student – Dushy
  3. Secondary Research – Team
    1. Expert Opinions
      1. User A (Engages in Freshers’ Social Media ) – Ben
      2. User T (Elected Representative at SU) – Dushy
  4. Persona Creation – Dushy
  5. Storyboards – Gunnar, Dushy & Ben
    1. Peer reviews & individual contributions – Team
  6. Competitor Analysis – Ben
  7. Requirements Definition – Dushy
    1. Tools & Technologies Research – Ben
    2. PACT Analysis – Gunnar
  8. Information Architecture – Team
  9. Initial Sketches – Gunnar & Dushy
    1. User Feedback
  10. Paper Prototype – Team
    1. User Testing
  11. Lo-Fi Prototype – Team
    1. User Testing

Brainstorm workshop (etc)

20140225_brainstorm_wip

After a long session of going through all the planned features and the intended use of the location app, we have a lot of interesting insights into this project; both in terms of a preliminary set of features/topics that we intend to research further and also what we intend to develop (at least to the point of a high fidelity demo). Today we also managed to have an expert interview covered here as a sort of extreme user interview.

20140225_brainstorm_mindmapThe brainstorming started around a mind map of the current state of the project and its parts to identify stakeholders of possible issues we need to deal with as well as helping us decide exactly what research needs to be done for the it. It naturally became quite a complex network of ideas.

Potential Stakeholders

From the ideas we had, we knew there was a number of stakeholders that we’d need to communicate with or even get engaged and involved with in order to create this app. The brainstorming session and puttign things on paper (whiteboard) has helped to clarify which are the main ones and what we can provide for them and what we need from them.

Freshers

The main group of stakeholders that we are interested in serving is of course students, and more particularly freshers. The ideas we brought together originally were intended for this audience and though today’s meeting has developed these ideas a little bit away from freshers, it’s still a great  demographic to help and doing so could mean we could get help from the Students’ Union and possibly develop the app further after the end of the Interaction Design assignment deadline.

One of the main issues with using freshers is that we can’t research freshers needs directly through talking studens through the experience, but we’ll have to rely on our own or other students’ memories of their experiences. Naturally, first year students would have these more memories fresh in mind but we are aware of a slight drawbback here. As part of our idea was a “social hub service” of the app, one way to get around this is to look at the most asked questions as well as the volume of interest in the official (originally unofficial) Facebook group run by Alex Noble. To some degree, we may also be able to get information from StudentRoom, the pre-uni social service.

Societies, sports, networks & housemates

Especially as a social app, Students’ Union members in societies, sports, networks and student accomodation housemates would be great organised groups of stakeholders that could provide useful feedback on how we could make an app they would find useful.

There are no serious issues with the first three here, but accomodation information would provide greater-than-normal amounts of consent to be provided by the users. It’s possible this part, which has been identiefied by Dushyant (in his role at the SU over the past two university years) could meet significant administrational hindrance.

The UWE Students’ Union

The main people within the UWESU would be User N at the Media and IT department (who previously has shown interest in UWESU app development) as well as the SU Presidents and a contact we may need is the administrator who started the official (originally unofficial) Facebook group. Out of these, User N is probably the most important, being of a technical mind and doing a lot of app research for the SU’s needs and general app preferences in general.

MSL

Membership Services Limited is the hosting company employed by the UWESU. They are a stakeholder insofar as we’re primarily planning a web-based app, and permissions on the server side of things (ie: at MSL’s servers) may be essential, and administrative or security issues here could be a major road block.

UWE

We hope that UWE will welcome a student app that make life (and navgation) of UWE easier, especially for freshers. Though there isn’t a situation where we’d seek funds for it (even if we extend the development until after the ID assignment deadline), their help may be essential in terms of gettign access to relevant UWE systems.

Accomodation

As part of UWE, but slightly more private in terms of sharing data about their customers, accomodation is one of the areas that are both potentially very useful as well as hard to deal with. In theory, it should be enough to get user consent to use the accomodation data, they may be more reluctant to share than this.

CETTS

The Central Examinations, Timetabling and Technical Services is of course also part of UWE. If we’d need to get access to information here directly, this project would probably be declared infeasable immediately because of the delay in simply getting administration to agree to it. However, through the UWESU and User N etc, many of these hurdles have already been dealt with. This is another reason we’d really need UWESU support, as it’s an organisation that is far less rigid in its administration.

Having said that, we’d likely need additional assistance from CETTS in order to get our own code to work and pull/show data correctly, so they are definitely one of the more important stakeholders from a practical point of view.

Research

Especially with the help of the mind map, we have found many additional fields we need to research than just user testing and opinions.

User demographic

This is the biggest part of the research, naturally. Not only to find out more specific needs to decide on features and to possibly make personas or other design tools for the development of the app, but also for direct usability testing and a means to gauge our success for the assignment presentation.

We are currently in the process of ironing out specific research methods, but among others we’re definitely using existing social media tracks and experts (Alex Noble).

Alumni

Though first considered, there is no point in brining in alumni into the research process. A possible exception could be if there is a shortage of regular student contacts for research or testing.

App shell

We are assuming that it will be a minor issue to produce a web-based application that we can simply use a “web shell” app on each of the major smartphone operating systems (Windows, Apple, Android). However, we don’t know the specifics, and these have to be explored.

Ben has a developer’s license for Apple and making a student app we won’t have to deal with the very stringent (and sometimes irrational; more here and here) approval system of apps.

Over all, we’re very optimistic about this technical solution but we are aware that we need to find outhow it works exactly.

oAuth

The absolutely best way to solve privacy would be to tie the app’s authentication system with the UWE login system. We don’t think UWE actually REALLY follows the oAuth standards, but we use the lable to talk about their authentication. Regardless of if this is a non-issue since this would be an UWESU app and the SU already use UWE’s login system, we will definitely encounter issues getting it to work. It’s one of our larger concerns and we’ll need to have a good relationship with UWE as well as UWESU to find out how it can be sorted and then implement it.

Consent

Possibly our biggest concern comes from acquiring consent while informing users of what we will use their data for and to make sure that data is not shared with people they have not consented to have it shared with.

The main issue if we had not been aiming to launch the app through the UWESU would have been to handle student data. However, the UWESU has an agreemet with UWE that they can handle the data of all students and students can opt-out from this, so the app could HANDLE data without much issue and our only concern would be to DISPLAY data in any way shape and form. However, to be useful as a social locational app, it needs to be allowed to show data, so the issue still remains. This issue can be more or less solved by having the user check a terms of service box which will give the app the user’s consent in order to proceed.

The second issue would be accomodation data, as explained above, and event data. Part of the features planned would be to show users which of their peers (and/or friends) have purchased tickets to what freshers’ events or general SU events and perhaps also who has arrived there. We realise there is a big difference between consenting to share which course you are attending to your peers and to tell people which party you are currently attending. This could be for personal, social or cultural reasons. The way to solve this issue would be to allow a user to customise what data sharing they consent to. However, some minimal amount would be mandatory to make the app useful at all and the intended purpose of this is to protect sensitive individuals, not for the average user to opt out of all the app’s features.

User N

Being very knowledgeble abotu apps, having done previous research about students apps and a gatekeeper of using UWESU resources to develop this app, User N is essential as a source of how to improve the app or even decide in what directions it should be taken.

Sid Baldwin

As head of the current UWE Mobile App (web version of app), Sid will be a good source to fins out what is currently brewing in the official app development and whether certain features will enhance student experiences or not. Part of this is the Policy for Mobile App Development at UWE, but keep in mind that the claimed “five stars” in the first link is from when the app had less than the eight reviews it has now (after its silent launch over the summer of 2012) and considering the latest review on iTunes only gives it one star, and even positive reviews have negative comments on Google Play. Also, out of roughly 40,000 students that have had the option to download it, Google Play shows 5,000 – 10,000 have downloaded it and have significantly more eviews than iTunes. More research can certainly be doen in this, but other than talking to Sid, it’s not essential.

The UWE app is important primarily because it’s important to UWE and that’s why it’s important to us.

Features

Please note that this is the full list of features we could think of, and some revision has already been made, and we’re coing to revise it further before prototyping.

Flatmates

The ability to link up with Accommodation Services and automatically determine whom your flatmates are for the forthcoming academic
year.

Coursemates

The ability to link up with new and current students who have confirmed a place on your degree.

Sports/Societies/Networks

The ability to become members of the Students’ Union sports, societies and networks.

Interests

The ability to register your personal interests and find associated sports/societies/networks and other Users with similar interests.

Whatsapp-like chat environment

Allows Users to communicate with each other, without the sharing of private information such as phone numbers or email addresses. Just names and photographs.

Location-themed features

The more location-based features we have considered are decently well documented in the first storyboard we posted. The idea is to make the interface to be the actual UWE campus map and the user, as well as a selection of features/amenities, represented on the map. The user can go into settings to set what sort of items he want on the map, and (if any) alerts to use. Some highlighted possible features:

  • Your location
  • Block names
  • Toilets
  • Cafés
  • Vending machines
  • Your next lecture*
  • Events*

The lectures and events would tie in to the social side of the app and take data from scheduling and the SU events. The idea with all amenities would be that the icon should be pretty small, and tapping it once would show more information and, if needed, the second time would take you to the actual item that you then could add to calendar, add a reminder for or editing the item somehow. Naturally, this isn’t needed for items such as vending machines, so they only have the details displayed on one tap.

To be able to display the right level map, getting the app to realise where the user is on the z-axis, look at the considerations at augmented campus. In short: It will try to figure it out depending on where you are and how you got there, but failing that you can simply tell it which level you are at, or which room you are near (see navigation).

Navigation, including 3D map

One of the main features, especially for freshers, would be a 3D navigator which will take you from your location (or a manually entered one) to where you wish to go.

For finding your way to the upcoming/current lecture, much of this will be automatic (as per the storyboard) but it also includes the option of manually setting starting point by entering the name of the room you are nearby or the QR code that will be attached to each room. The main reason for this would be when a phone’s GPS can’t find satellites indoors, or the user doesn’t have time to wait for it to sync.

An option for UWE for later would be to install NFC devices, that would help the app localise itself without wasting a lot of battery on GPS.

Regardless of HOW the app finds out which level you are on, the map in the main interface will update to show features of the one you are on.

Also regardless of where you want to go and where you want to start (regardless of why you may want to alter your start position from your current position), the app will show you the most direct route to where you out the destination in a 3D diagram (again have a look at the first story board). More research will go in to this feature idea, but it’s one we very much like and it may well be a static picture that only shows your position if GPS is on and working and otherwise stays static as a guide.

Timetable & events (who’s where)

As mentioned briefly earlier here, the back end of the app will also include timetable information that can be used with the map or as alarms on its own and will point out upcoming SU events (or custom events). An idea is to make it compatible with iCal feeds so the user can add custom events as well, though they may not be as compatible with the location features.

Additional: Blackboard info, recommended reading & staff availability

A secondary back end of the app, adding information to each lecture such as Blackboard information, reading that the lecturer has recommended or staff availability (both for the lecture or to see the lecturer).

Semi-conclusion

We are probably just looking in to the four last features for this assignment, and any additional social features beyond a more simple approach may come after the end of this assignment.

We need to really decide exactly what research to perform and to schedule time to do it.