The final prototype is in the form of web based application that mimics a mobile application. We have created a temporary backend by using the clients local storage (sessionStorage) to create an interactive experience. The future prospect of integrating a database has been thoroughly considered throughout the development of the prototype, with a firm JSON structure being created. The major features include:
- Events that are RSVP’d to appear in My Events
- Full google maps integration
- Ability to change profile badge that is used throughout site
- Events can be dynamically sorted by tag type
- Events are displayed in chronological order
- Imitation chat that provides examples of how badges are earned
- Full mock-up of create event properties
- Lightbox integration
If you would like to reset the prototype to its original state, you must close the browser and reopen the site. We have created a site specifically designed to be viewed on a mobile phone. This is to create another level of immersion. It can be viewed at: Mobile Prototype
User research indicated that a prevalent amount of university students aren’t involved with activities and social events around their campus. The cause for this lack of engagement can come down to a variety of issues, such as a lack of personal motivation or a lack of awareness. This disconnection could also stem from a lack of incentive to participate in activity outside of their classes.
An ideal solution is a central platform that everyone at the University of Queensland uses and is kept up to date by. Such a platform would eliminate the requirement of external social software to create and explore campus events. Coordination of all event services on said platform, allows for extended features, such as any action pertaining to events would occur on this platform whether that is creating events, ¬finding events, collaborating on events, or anything else. With the entire university’s eyes on a singular platform, advertising for events should be much more active, and participation at events should be much higher as well. Overall awareness of what is happening on campus would be much improved. A solution like this would help enhance the entire university community.
The initial research also discovered that students put greater importance in time, rather than location. The majority of the students suggested that they would be willing to become more involved in the UQ community if there was a way of quickly seeing available events. A common example of use that was expressed to us was to fill in the gap between classes. We accommodated this time dependency by having the landing page showing events within the next hour. This would help to satisfy the core user.
We initially had a very detailed display to show all the events. After conducting a heuristic walkthrough, the team realized that this reduce the impact of the system and created confusion. We then decided to revisit our initial gathered requirements and focus on what was most important to the user, time. By stripping the interface back, the tests showed that we created a more efficient system.
When first developing our solution to the problem, we created a development plan. After we received positive feedback of its structure, we decided to stick to its structure. The design process was divided into 4 key stages that were concluded by a stand-up session with an expert (tutor). The completed stages were: (They want images in here)
- Identify Users
- Create Personas
- Survey Users
- Identify Use Context
- Wireframes and Mock-ups
- Paper Prototype
- User Interviews
- Low Fidelity User Testing
- High Fidelity Prototype (InVision)
- User Walkthrough
- High Fidelity User Testing
- Front end Development
- Back end Development
- Deliver Final Prototype (Web-based)
One of the major limitations we retrospectively acknowledge, is the limited exposure we had with clubs managers around UQ. We initially gathered their input within the requirements stage, however as the project progress we used more of a major user-base. This was because we were more concerned with content consumers over the creators, putting the majority of the focus into appeasing their needs. This was evident in the final prototype, having a more comprehensive event and profile component. If we were to develop the application for full commercial use, we would use the same process but focus entirely on UQ clubs and societies.
- Requirements
- User Profile functionality test
- User Interviews
- Web feasibility test
- Web prototype
- Initial Research
- Low fidelity prototypes
- High fidelity prototypes
- User Testing
- Web prototype
A number of university students aren’t involved with on-campus activities and social events within their campus. The cause for this lack of engagement can come down to a variety of issues, such as a lack of personal motivation or a lack of awareness. This disconnection could also stem from a lack of incentive to participate in activity outside of their classes.
Currently, students lack a unified and central platform to set up and organise events on campus. Most students engage with University activity through society email lists, Facebook events or word of mouth. Many of these events remain elusive, either due to Facebook’s strict news feed algorithm or just a contemporary lack of email usage. Ultimately, this leaves many students unaware of or deterred by events because of the inconvenient process.
Our project, titled ‘UQ Lyfe’, is a mobile application that gamifies UQ classes and extracurricular experiences, as a way to incentivise students who wouldn’t normally be involved.
The project the team has chosen to develop is driven by a need to increase student involvement in extracurricular activities and also strengthen the sense of community and lifestyle present at the University of Queensland. Additionally, as the campus community can often feel enormous and disconnected, students can lack incentivisation to participate in social events. This product has been labeled UQ Lyfe.
UQ Lyfe, as a platform, is being developed with the primary goal of unifying and gamifying the way that curricular and extra-curricular activity is participated in at the University of Queensland. This platform needs to appeal to both students who wish to increase activity involvement, and club leaders and teachers who wish to reach out to more people from within the UQ sphere. The application revolves around an experience and levelling system. This system is directly inspired by classic RPG (Role Playing Game) quest logs that allow players to manage what tasks are available for them to complete.
This system is typically broken up into main, secondary and miscellaneous sections and ordered by the amount of experience points gained from the completion. Experience can be earned through various tasks such as attending events, completing tasks, hosting events and having students attend the events you have created. All experience earned contributes to the overall rank associated with the user’s profile. The aim of this rank is to be an overall quantifiable representation of the user’s involvement within UQ. This rank can be compared to other students via a leaderboard system. This app not only aims to motivate students to get involved, but also aims to simply increase awareness of activities on campus and their attendees. Seeing that others are attending an event can spark one’s interest to do the same.
The team personally interviewed a variety of students at UQ. Specifically looking for answers to questions regarding the various platforms currently available for managing events and the idea of incentivising event participation through reward. Answers to the first question were all suggesting that the current platforms that students use to organise and find events are cumbersome and not entirely effective. Almost all suggested that an official UQ platform would be preferred, with one particular interviewee suggesting “an app that works like a flyer on the sandstone pillars, except it’s on your phone wherever you are and at any time”. The second topic generated more varied results, with some students stating that any sort of ranking system would need to be backed up with a tangible reward. Others felt that the sociability of events and their accessibility through an app would be incentivisation enough.
This initial feasibility research showed that there was a clear need for a social application like UQ Lyfe. The broad userbase within the campus introduces some difficulties in defining audience, however it was evident that the target users could be broken down into deferring levels of involvement. Another segmentation level was content creators, those who create activities and content consumers who attend events and level-up their experience. One aspect that the group has determined that needs to be tested further, is the consumers motivation to use the application. As we have hypothesized above, we believe that competition may be the driving incentive to get involved, however a more tangible reward may be necessary. Some initial ideas were UQU gift cards, exclusive events or discounts to food vendors around the University. This will be elaborated on with concrete data as development continues.
Direct access to the target users will be done through the University of Queensland, St Lucia campus. Random participants will be chosen to ensure that the vast array of contextual backgrounds within the userbase are thoroughly represented. Test sessions will also include contextual questions to ensure that the sample size encompasses this diverse environment. As a group, we also intend on having direct contact with those who currently operate and maintain the societies around UQ. This will initial be done using digital means, with later physical interaction introduced to gather results on prototype. By forming these key relationships, it establishes the future content generators as active participants.
UQ Lyfe differs from current methods with the introduction of:
- Gamification
- Leaderboards
- Social Matchmaking
- Integrated Instant Messaging
- Team based cooperation through a faction and school system
- Map and Timetable integration
| User | Applicable Content | Involvement |
|---|---|---|
| Students that would like to fill gaps within their studies with social interactions | Consumer | Low |
| Those who would like to belong to a community within their degree | Consumer | Medium |
| People who want a more social connect to the University | Consumer | High |
| Competitive student that wants to be seen as the person on top of the leaderboard | Consumer | High |
| Student that would like a study group to help on a difficult course | Creator | Medium |
| Societies that want to reach a larger segment of the campus | Creator | High |
- Sense of community with instant messaging, school factions and leaderboards
- Location services suggest nearby events that will start soon for students
- Create a shared information space to provide a centralised system for UQ events
- Increase awareness within the community by representing the students surroundings
- Introduce a new form of context for UQ students by creating the experience point system
- Establish a social mobile environment to facilitate direct interactions
| Team Member | Student Number | Role |
|---|---|---|
| Rohan Singh | 43945126 | Back end programmer |
| Mitchell Kiss | 43915576 | Front end programmer and designer |
| Tyler Beutel | 43956476 | Front End, UX and designer |
| Nicole Huang | 44900775 | Front end programmer, designer and UX |
| Glenn Duguid | 42650272 | Front end, Back end programmer and UX |
-
UX (User Experience)
Will be the main connection to the identified users, developing surveys and running the interview sessions. Will consider best practice protocols and analyze the gathered results. Overall goal is to guide the iterative development process. -
Designer
Will govern the overall feel of the system, creating low fidelity prototypes for user testing. Create initial wireframes and mockups to gain insight from user group and help front end developers govern their design. -
Front end programmer
Design and crate a usable front end system to allow users to seamlessly interact with the product. Will initially be guided by user requirements and low fidelity prototypes. -
Back end programmer
Create the back end component of the application to provide a smooth and usable system. Will work in unity with all other roles to ensure that the created elements consider the context of the intended user.
Large overarching concept ideas will be discussed and decided on in person when the whole team is together either in workshops or team meetings outside of workshops. More minor details of the project can be discussed in person or via Slack. The team must discuss all decisions that were made during the previous week at each workshop to ensure everyone is caught up and in agreement. Should and disagreements regarding decisions take place, conflict resolution measures will be taken.
- Any face to face communication that takes place between individual team members should be conducted in a calm and respectful manner by either party.
- In the case of poor performance or lack of communication from specific team members, a meeting shall be organised within two days (either online or in person) to allow for proposals to be made that will help ensure future performance is up to group standard.
- Further unresolved conflict should be addressed in a following group meeting. All group member positions shall be proposed and considered equally. If a group decision needs to be made, it will be discerned through a vote. Regardless if the group meeting is conducted during or outside of class time, communication must remain civil and respectful.
- If further dispute continues, either in regards to a decision made or the continued behaviour and contributions of specific team members, a tutor shall be immediately notified of the situation and brought into the dialogue. The proceedings will be explained to the tutor and the tutors advice on how proceed will be followed by all team members.
The group will regularly meet during workshops every week. Workshops are held every Tuesday from 12pm to 2pm. Meetings will be conducted during the workshops and if needed, additional meetings will be arranged. Additional group meetings will be organised if the team deems necessary after workshop each week. Meeting times will be discussed in person and over Facebook if needed until a time that everyone can attend is settled on. Additional meeting times should be agreed upon at least 3 days before the decided time. If team members are unable to attend a meeting, an attempt will be made to reschedule the meeting if time permits all members to be contacted early enough. If the team member who is unable to attend advises the team of their circumstances too late, that team member will be expected to follow up with the group on what was discussed and any decisions that were made.
Team communication will be conducted through Facebook messaging and the group’s Slack channel (#barnabees) in the deco3500-2017.slack.com group. Facebook will be used for more informal conversation as well as scheduling meetings. This is a good option for us because it is a quick communication tool, and everyone regularily checks Facebook so we will all be up to date. Slack will be used as more formal communication with the team, tutors, lecturer and other students in the course. Overarching discussion of the project will be carried through slack. Team members are expected to check Facebook at least once a day, and the Slack channel at least once a week. Slack is becoming more and more prevalent in the industry. It is easy to use and efficient for communication. It allows us to not only get connect with our own small team but also with others in the class should the need rise. It is a platform we all associate with this class and its content already, so it will be automatic to turn to this forum to discuss our project.
A Google Drive folder has been set up to store all the documents, surveys, and other files that the team will be creating. Everyone in the group has access to the folder, so all team members are able to contribute to the documents. Folders will be created if two or more documents are deemed related and should be grouped together. All files and folders will be named appropriately and concisely, clearly denoting their purposes and contents.
Github will be used as a collaboration repository to store prototyping code. All team members have access to the repository. Using Github will help the team collaborate code easily, find issues, and solve these issues in an efficient manner.
- Identify users
- Create user personas
- Interview and survey users
- Storyboard of use
- Identify use context
- Identify technical platform to be used
- Minimum Viable Product
- Wireframes
- Mock-ups
- Paper prototype
- System architecture
- Low fidelity user testing
- Front end development
- Back end development
- High fidelity user testing
- Deliver final prototype
The derived plan has been determined with respect to the deliverable standups. This will help to receive heuristic advice from our peers and teachers, who can be considered experts in the problem scope. The short development cycles within the Agile framework provide the ability to rapidly adapt to unforeseen user requirements, receive up to date feedback and encourage collaborative design. The data established form the user test sessions will provide guidance to the development of each prototype iteration, with a reliable test being complete at least a week before final prototype standup.
#activecommunities
#socialtechnology
#interactive
#socialgaming
#competitive
#awareness
#communities