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