Skip to content
This repository has been archived by the owner on Jul 19, 2023. It is now read-only.

deco3500-2017/packed-to-the-rafters

Repository files navigation

Packed to The Rafters

This is the Github repository housing the project assets for Travel Pack. These assets include back end and front end programming, graphical assets and documentation.


Travel Pack

Introduction

Travel Pack is a social mobile and computing app that aims to bring together travellers from around the globe. Travel Pack provides users with a platform that allows them to discover various local events, wifi hotspots and other individuals touring the area.

A link to the prototype can be found here: travelpack.uqcloud.net A video explaining Travel Pack can be found here: https://www.youtube.com/watch?v=ymtS1vYpPSI&feature=youtu.be

Concept

Travel pack aims to connect travellers with others who are doing the same as them. To do this, the concept is an application that not only tells travellers of the different events around the area but creates events for users and automatically invites people of similar interests together. The concept allows travellers to meet like-minded people while travelling, increasing the chance of creating quality travel buddies who would be interested in doing the same things.

How Does TravelPack Achieve This?

The app requires users to create a profile for themselves in which they specify their age and interests. The app then filters through all travellers in the area and creates events based on the common interests. Travel Pack then displays all these events on an 'Events' page in the application. The application uses an algorithm so that that events most relevant to users regarding interest and place appear at the top of the list of events. Users can also search for events using tags or location. Each event creates an event chat so the users can do further planning with others attending the event. The app takes all the hard work out of organising tourist events and meeting friends while travelling. Travel Pack additionally marks venues, restaurants and locations on the map with a built in star rating system for users to leave feedback.

What Makes this Unique from Existing Solutions?

Travel Pack differs from existing travel applications as it creates events for the users and personalises these events to user interests. Other applications exist that work towards the same goal of bringing people together during travelling and creating a travel community. An app that does this is called ‘Backpackr’ (backpacker.org). These other apps although require the users to organise their own meetups and manually look through the other users interests to find likeminded people.

Target Audience

Travel Pack aims to reach out to travellers of all kinds. Domestic and international; women and men; adventurous and conservative; the features of this application cater to many demographics and allow travellers from all different backgrounds to come together. Travel Pack can be used by solo, pair or even groups of travellers wanting to find other travellers to explore and socialise with.

Personas

In order to gain a better insight as to what features would be included within the platform, personas of potential Travel App users were created. Examples are shown below:

Hilari Makae

Gender: Female

Age: 19

Origin: California, United States

Relationship Status: In a relationship

Background

  • Hilari loves being around other people. She is very extroverted, loves to meet new people, is currently planning a 2 month holiday around Europe with her friend and likes to post pictures of the destinations she goes to. She prefers hanging out with boys because less drama. When traveling Hilari prefers to stay in a hostel share room with 6 or more people and is always looking for the next adventure; whether it be skiing in the Swiss Alps or skydiving in Austria.

Interests:

  • Sightseeing, photography and thrill seeking.

Goals:

  • Do as many touristy things as possible.
  • She wants to be able to make meeting people when travelling easier
  • She wants to be able to share images of the places she’s been with other travellers
  • She wants to go to party events at night in different countries
  • She wants be able to find information on her current location without going to a information centre

Challenges/Motivations:

  • Does not have knowledge on where to go to find good tourist locations.
  • Wants to make a group of travel friends without going on an organised tour.
  • Wants to travel with people who have the same interests as her and want to do the same types of things.
  • Finds it difficult to find information and locations because of the language barrier

Questions:

  • How can we allow Hilari to find tourists with same interests as her?
  • How can we help her find other travellers travelling with a friend?
  • How can we lessen the language barrier for international travellers?

Damien Kistanza

Gender: Male

Age: 26

Origin: Melbourne, Australia

Relationship Status: Single

Background

  • Damien is a free spirit traveler that loves hanging out with people for a short period of time and considers himself to be an introverted extrovert. When travelling Damien is looking to experience new cultures, food, the party scene and tourist attractions. Damien is currently embarking on a solo 6 week backpacking holiday around Southeast Asia hoping to immerse himself in the cultures of Indonesia, Thailand and Vietnam.

Interests:

  • Food, parties and foreign cultures

Goals:

  • He wants to enjoy the never ending party of life
  • He wants to try authentic traditional food
  • He wants to see not only the big tourist attractions but also how the locals live
  • He wants to meet new people at each new place he travels

Challenges/Motivations:

  • Language is often a barrier he has to overcome when travelling between tourist attractions
  • Finding the best places for traditional food
  • Meeting other people looking to party at each point in his holiday
  • Using all his data while navigating each destination

Questions:

  • How can we provide Damien with wifi hotspots in foreign countries so he doesn’t use up all his data at once?
  • How can we help him find other travellers that are looking to party?
  • How can we help him to find the all authentic traditional food in each destination?
  • How can provide tips or common phrases to help him communicate with locals in their native language?

Design Process

The creation of Travel Pack consisted of an iterative process of empathizing, defining, ideating, prototyping and testing.

1. Constructing A Base Solution

The team together worked to empathize and flesh out the features to incorporate into Travel Pack. Packed to the Rafters elaborated off of the basic concept idea from Kirstyn's poster. The group started off by listing appropriate features neccesary to implement and generated user personas and stories. User research was completed in a survey/interview form. The users that were interviewed were young people who had been travelling either international or domestic and some of which had backpacked. From this research more features and scenarios were made. Feedback was gathered on whether users thought certain features and aspects would be useful in a travelling situation and whether they could see themselves using the app. Documentation on User Research can be found at this link: https://github.com/deco3500-2017/packed-to-the-rafters/wiki/User-Research During this stage, the group wasn't too focused on the flow and site-map navigation of the application. We focused on including all neccesary features. Wireframes were created as a group, this was the first time the group really considered the flow of the app. The wiki on wireframe creation can be found at this link: https://github.com/deco3500-2017/packed-to-the-rafters/wiki/Wireframes Soon after creating wireframes, the first mockups were created based off of the wireframes. Documentation and images of the mockups can be found here: https://github.com/deco3500-2017/packed-to-the-rafters/wiki/Initial-Mockups. Further information on this sprint can be found in the meeting notes: https://github.com/deco3500-2017/packed-to-the-rafters/wiki/Sprint-2-,-Meeting-2-and-Contributions

2. InVision Prototype 1.0

During this sprint the team created an InVision prototype using the mockups made. This is wear the flow of the app was implemented and the app was to some degree testable. User testing was completed on this prototype in order to find feedback and results on how users liked the look and flow of the application and whether they understood the purpose for each page and feature of the app. The findings from this round of user-testing were that users were generally confused with the re-use of certain symbols for different features. There was confusion in the event group chat on what it was and what its purpose was. Users wanted more information on each event. It happened to be so that in testing the prototype a mockup feature of additional information for each event was accidentally nto included and therefore not tested. This was then put straight into the second iteration of the prototype. More information, raw data and evaluation on user-testing can be found on the wiki at this link: https://github.com/deco3500-2017/packed-to-the-rafters/wiki/User-Testing

3. Making Changes and Web Prototype 1.0

In completion of one full iteration of creating and testing and evaluating, the team started back at the beginging of the design process and made some changes to the app. The group got together to re-design the problematic aspects of Travel Pack. Icons were changed to all be unique to their functions, a more obvious link was made for the event chat within the individual events information page, the 'people in the area' function was removed and replaced with 'popular attractions'. The create event functionality was discussed as a group as one of the main functions of the app as well as the design of the app flow overall. The documentation from this group discussion can be found here: https://github.com/deco3500-2017/packed-to-the-rafters/wiki/Meeting-4-1---New-app-flow These changes were then implemented into new mockups. These mockups were then used to create the second iteration of the InVision prototype. The documentation, changes made and link to the prototype can be found in this wiki: https://github.com/deco3500-2017/packed-to-the-rafters/wiki/Invision-Prototype---Iteration-2 The group, while implementing the InVision prototype, made a start on the web prototype and foundation layer of the application. Link to the progress on this can be found here: https://github.com/deco3500-2017/packed-to-the-rafters/wiki/Web-Prototype-Progress

4. InVision Prototype 2.0

Once the InVision prototype was completed a second series of user-tests were completed. This testing's purpose was to evaluate the changes made to TravelPack and whether the aspects of the app that were negative in the first round of testing are no longer an issue. Testing documentation, raw data and evaluation can be found here: https://github.com/deco3500-2017/packed-to-the-rafters/wiki/Invision-Prototype---User-Testing-2. Again we tested the prototype on young travellers of all backgrounds. The findings from the testing were overall very positive. The small problems associated with the testing were mainly due to limited functionality. Some users had difficulty knowing the purpose of aspects at first glance, but once they played around with the prototype they understood the use for each feature and completed all tasks in the user tests. The results implied a successful change in the prototype to ensure a usable and understandable application for travellers. The web-based prototype was built apon with regards to the mockups and all aspects were implemented after feedback from user-testing was positive. All main pages were added to the prototype as well as styling of the site. No functionality was implemented yet. Progress and documentation on the web-prototype can be viewed here: https://github.com/deco3500-2017/packed-to-the-rafters/wiki/Web-Prototype-Progress-2.0

5. Web Prototype 2.0

In the last stage of the project, the final verson of the web-prototype was coming together. All map and event functionality was added into the prototype so users could see markers on the maps and read about attractions as well as create their own events to appear within the app. The main function of the prototype is to be able to view and create events. Users area also able to search locations on the map. A link to the progress wiki for the web-prototype can be found here: https://github.com/deco3500-2017/packed-to-the-rafters/wiki/Web-Prototype-Progress-3.0= The final and completed version of the prototype can be found here: travelpack.uqcloud.net

The Team

Packed to The Rafters consists of five team members:

Team Member Student Number Description Responsibilities
Chris Fuller 43184493 Final year Multimedia Design student. Experienced in graphic design and front end. Content and Design
Kirstyn Jozefowski 43936517 Final year IT student, majoring in UX Design. Back end, Front end and Design
Coleen McKay 43927252 Final year Multimedia Design student. Experienced with graphic design and front end. Front end, Back end and Design
Domenico Poutanen 435742188 Final year IT student, majoring in Software Design. Experienced in front and back end. Back-end
Emily Toniotti 43921317 Final year Multimedia Design and Marketing and Advertising Student. Experienced with graphic design, user experience and front end. Front-end, Research and Content

Domenico Poutanen has been designated the role of scrum master. Where his job is to make sure that all team based communication and problems are dealt with.

Dominico will deal with back-end code development. Chris, Kirstyn, Emily and Coleen will together deal with both front-end development and UX Design of the application. Where needed, team members will cross over into other areas.

Coleen McKay is responsible for logistics, such as meetings minutes and coordination. When creating content and code, all team members will be responsible for their own documentation (i.e. User testing, standardisations or JavaDoc)

Decisions will be made based on a democratic vote, assuming all alternatives of the decision have been researched, tested and reasoned. There cannot be cases in which the vote results in a draw, as there are only five team members; however, if there are valid reasons the minority believes the majority decision should not be carried through, and is accompanied with valid research, the case will be looked into further.

Meetings

Meeting Schedule

Meetings are scheduled to occur every week in the workshop (W03). This time slot was chosen as it is the only feasible time we are all able to meet during the week. Each workshop will begin with a brief stand up to ensure everyone is aware of what we are all currently working on. If required, the meeting will then follow on from the stand up to talk about everyone’s workload more in-depth, as well as any research undertaken since the last meeting and testing results.

Meeting Guidelines

Meetings should have a clear purpose and agenda Meetings will not occur if the stand up has adequately informed all team members of new material, testing and/or research Team members must provide reasonable notice to the team if extra meetings are needing to be organised

Communications

The primary method of communication will be via Slack. Slack will be utilised for checking project progress, sending specific files, links, etc. We chose Slack as we not only have easy access to the DECO3500 channel, we are also able to implement various integrations and services, such as Github and todobot. Whilst Slack will be our primary method of communication, Facebook Messenger will be our secondary method of communication regarding quick updates or letting other team members know you may be late to a meeting. Email will be used for formal communication, such as emailing organisations for research or testing participants. In cases of emergency, phone calls will be used to contact other team members.

Communication Method Use Case
Skype/Facebook Call For auditory communication
Slack Primary communication and collaboration
Facebook Messenger Quick communication
Email Formal Communication
Phone Calls Emergencies
Github Version control/asset management

Rule Breaches

Breach Conflict Resolution
Team members not attending meetings without prior notice Team resolves conflict through communication with team member. If conflict is not resolved and breach keeps happening, the team will bring conflict to tutors attention.
Team members not communicating with team All methods of communication will be used to try and get in contact with team member. After three instances where a lack of communication by a team member occurs, a team meeting will be scheduled to resolve the issue in person. If the team member is ultimately uncontactable tutors will be notified and the issue will be dealt with through the teaching staff.
Team members wanting to work on the same tickets If team members wish to work on the same tickets, workload will be divided equally. No team member is allowed to claim a ticket as their own and only theirs. Workload will split evenly between everyone to ensure working hours are fair. Another instance example is if two people want to work on a small design issue, and one of those people is already working on a design issue, the new design issue will be delegated to the other person to ensure it is fair.
Team members not contributing adequately to the project Instances where a team member is not contributing, a team meeting will be held to resolve the issue. Perhaps the problem lies within the team member not knowing what to contribute; therefore, during the meeting certain tasks will be delegated. If there is no improvement of contribution or effort, another team meeting will be held to see if there are underlying issues regarding the lack of contribution. If there are no underlying issues and contribution does not improve, teaching staff will be notified.
Team members plagiarising and not referencing If a team member chooses to plagiarise in order to increase their contribution, a team meeting will be held to resolve the issue and revert the project to a version without the plagiarised content. As all team members are students of the university, we should all be aware that plagiarism is a breach of the code of conduct; therefore, teaching staff will be notified.

Project Plan

The plan for implementing Travel Pack will be a hybrid version of agile and waterfall methodologies where instead of the waterfall original steps of design build and evaluation they are replaced with sprints for features being implemented. Where the hierarchy will be based on the priority of said features. The first step being the most important feature and so on. The overall development due date will be 23rd of October where we will prepare for the final presentation and submission.

Within the sprint steps, we will use agile methodologies to ensure the product is built correctly. As the given implementation is as intended and doesn’t impact the overall application negatively. The agile methods will repeat within the sequence of building then testing. Where testing will ensure that said goal is met. If not repeat the build process until it does. The Sprint Breakdown will contain the deadlines of said sprints. However below are a few dot points of said features that will be implemented and tested: Note: This is just a rough list of features. Throughout development more points might be added or modified to benefit the overall development of Travel Pack.

Navigation / Map functionality Personal profile and information sharing Event creation Pairing users

Features will be combined when going through sprints. This is a decision made either towards a limited timeframe or positive combined testing. Where testing and developing with said features will produce positive outcomes towards the overall application. For example this could be either towards faster testing evaluation correlation or both features conflict/ work in correlation with each other.

Sprint Breakdown

Below is the brief breakdown of all upcoming sprints.

Sprint Start Date End Date Tasks
0 9th August 20th August Group Formation, Idea and concept generation
1 21st August 3rd September concept development, personas, user interface design, paper prototyping, creating testing plan, conduct user testing, documentation
2 4th September 17th September prototyping, front end and back end development of prototype, user interface redesign based on feedback, user testing and documentation
3 18th September 1st October Prototype development, front-end and back-end code development, user interface development
4 2nd October 15th October UX testing and changing designs accordingly
5 16th October 22nd October Conference poster creation and finalising designs and documentation
6 23rd October 27th October Finalising product, preparing for presentation, product submission

Showcase

The showcase is now completed and so is our project. It was a great evening and TravelPack group pitched our product concept and prototype to numerous visiters and classmates. We had our posters, our web app, our video playing and a link for people to access the prototype on their own phones to try out. The group walked the people through the prototype and the concept of the application giving examples of when they might use each specific function. Overall our group recieved an extremely positve response and interest towards TravelPack. Many people claimed that this would have been great for them when they went travelling and they wished they had an app like this. There were stickers given to everyone that attended the event and our project recieved around 17 stickers which our group is very pleased with.

Tags

travel backpacker community active communities social awareness interaction shared-information-spaces social-translucence conversation