diff options
| author | Kumar Damani <damani.kumar@gmail.com> | 2019-03-10 01:51:10 +0000 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2019-03-10 01:51:10 +0000 |
| commit | 0473a9716e07dc8f9ee7d2190e5f8272473a2de9 (patch) | |
| tree | b52032f382fe5820b04a0606a1fb668d099800e3 | |
| parent | e51c4c8b2c7e4b31333feae3fa68510acaaf6cf7 (diff) | |
| parent | c7fbadd32feb1f3b00144545a8e13da3b6bccada (diff) | |
Merge pull request #35 from csc301-winter-2019/master
sync qa with master
| -rw-r--r-- | deliverables/README.md | 28 | ||||
| -rw-r--r-- | deliverables/iteration-02.review.md | 8 |
2 files changed, 18 insertions, 18 deletions
diff --git a/deliverables/README.md b/deliverables/README.md index 753043f..ee9e9f6 100644 --- a/deliverables/README.md +++ b/deliverables/README.md @@ -1,13 +1,14 @@ -# README +# Helpthehome by The Dream Team ## High Level Description Help the Homeless is a web and mobile application that allows homeless shelters to see the locations of homeless people in need of help in real time. Our application consists of two components: a web application and a mobile application for iOS and Android. The web application displays a map that is updated with markers in real time. Each marker shows the location of a homeless person, along with identifying details such as (age, clothing, injured or not, etc.). Markers are displayed on the map whenever a user on the mobile application sends a request for help. The mobile application is intended to be used by the public. It contains a simple form that allows the user to describe the situation to help the outreach workers identify the person in need when responding for help. ## Key Features -* Users can send their location using the app to report where a homeless person is -* Users can fill out details about the homeless person before reporting them -* Users from Street To Homes can view a map and see point markers overlayed on the map which represent where users of the app have submitted locations of homeless people -* Clicking on a point marker on the map brings up detailed information about the homeless person at that location +* Users can send their location using the app to report where a homeless person is. +* Users can fill out details about the homeless person before reporting them. +* Users from Street To Homes can view a map and see point markers overlayed on the map which represent where users of the app have submitted locations of homeless people. +* This map is live-updating, so no refresh required. +* Clicking on a point marker on the map brings up detailed information about the homeless person at that location. * 'Drop Pin' was not implemented in this iteration, although the button was made and added to our app for future use. This button currently has no functionality, but once fully implemented will allow users to select a location on the map themselves and place a pin there indicating there is a homeless person who requires help. ## Basic instructions @@ -18,13 +19,12 @@ Help the Homeless is a web and mobile application that allows homeless shelters 4. You can zoom in and out by clicking the `+` and `-` button at the top left corner of the map respectively. You can also zoom in and out by scrolling up and down on your mouse/trackpad respectively. ### Mobile application -1. Ensure your phone supports location services and it is turned on. To enable location services for iPhone see [here](https://support.apple.com/en-ca/HT207092) and Android see [here](https://support.google.com/accounts/answer/3467281?hl=en). -3. Download the Expo APP [Android](https://play.google.com/store/apps/details?id=host.exp.exponent&hl=en), [iOS](https://itunes.apple.com/us/app/expo-client/id982107779). -4. Scan the QR code below: - +1. In a new tab, or window go to our mobile app presently running on an android emulator at Appetize.io: https://appetize.io/app/4nzk9t6g0h0y9r9ux2zj7d3tpg?device=nexus5&scale=75&orientation=portrait&osVersion=8.1 +2. Press "Tap to Play". +3. Once prompted for location access, press "Allow". +4. Once you see "Welcome to Helpthehome!", you can press the red button "Use Current Location". (Note: this will use the location of the Appetize server where the emulator is running, **not your actual location**) +5. Fill in all the fields on the form with the appropriate information. Although you can leave any field blank, it is **strongly** recommended that you fill in all the fields, as it helps identify the person in need. +5. When all the information is recorded, click the "Submit" button. A popup should say that you are being redirected to the main page. When you dismiss the message, you should be redirected to the greeting page. +6. You should now be able to see your report in the tab or window where you have the web app running without even needing to refresh. -2. When you open the mobile application the greeting page should show up on the screen. Click the `Use Current Location` button. -> If you see a prompt asking for your location access, press "Allow". -4. Fill in all the fields on the form with the appropriate information. Although you can leave any field blank, it is **strongly** recommended that you fill in all the fields, as it helps identify the person in need. -5. When all the information is recorded, click submit. A popup should say that you are being redirected to the main page. When you dismiss the message, you should be redirected to the greeting page. -6. You should now be able to see your report in the web application. +> You can verify that this is indeed the correct location by opening google maps in the emulator and see your current location. It will match what we have on our website map. diff --git a/deliverables/iteration-02.review.md b/deliverables/iteration-02.review.md index eb0d4c6..910f52e 100644 --- a/deliverables/iteration-02.review.md +++ b/deliverables/iteration-02.review.md @@ -9,10 +9,10 @@ #### Decisions that turned out well -1. One process-related decision that turned out to be sucessful was our weekly meetings on Tuesday. These meetings allowed us to review what each member did the previous week and assign tasks for what each member had to do the coming week. +1. One process-related decision that turned out to be successful was our weekly meetings on Tuesday. These meetings allowed us to review what each member did the previous week and assign tasks for what each member had to do the coming week. -2. Another process-related decision that turned out to be successful was using the Trello board to manage tasks. This allowed all the members to see the status of tasks so that people don't end up doing the same thing by mistake. Trello also allowed us to flesh out the details of what is expected from a task by defining an "Acceptance Criteria" (insert acceptance criteria sample from Trello). +2. Another process-related decision that turned out to be successful was using the Trello board to manage tasks. This allowed all the members to see the status of tasks so that people don't end up doing the same thing by mistake. Trello also allowed us to flesh out the details of what is expected from a task by defining an "Acceptance Criteria".  3. Using Slack as our primary communication channel was a good decision as Slack makes several auxiliary tasks easier. With Slack we can easily create and keep track of communication channels that each serve a specific purpose, and record communications that we would need as artifacts (e.g. meetingnotes channel) @@ -28,8 +28,8 @@ #### Planned changes 1. Since all the team members were not fully familiar with the code they were reviewing, we decided that only the team members who are actively involved in that particular part of development should review the code. For example, if a pull request was created that contained changes to the mobile application, then only Andrew and Fahim need to review it since they worked the most on mobile. -2. Because the master branch was always behind the qa branch, we came up with the decision to reserve 30-45 minutes during our weekly Tuesday meeeting to test the qa branch and update the master branch. Another approach we are thinking of is to schedule a 1 hour meeting on another day and dedicate it to perform testing and update the master branch. We have a testing heroku application deployed just for testing. Our testing strategy will be to update the testing app with the qa branch and perform manual testing to see if the functionality is correct. Once we verify that the application works as expected, we will merge the qa branch into master. -3. To address the issue of disconnect between sub teams, we plan on switching the roles for the next iteration, so the people who worked on mobile will now work on web, and vice versa. This will allow team members to better understand different parts of the application and save us time during our weekly updates, as it eliminates the confusion unfamiliar parts. +2. Because the master branch was always behind the qa branch, we came up with the decision to reserve 30-45 minutes during our weekly Tuesday meeting to test the qa branch and update the master branch. Another approach we are thinking of is to schedule a 1 hour meeting on another day and dedicate it to perform testing and update the master branch. We have a testing Heroku application deployed just for testing. Our testing strategy will be to update the testing app with the qa branch and perform manual testing to see if the functionality is correct. Once we verify that the application works as expected, we will merge the qa branch into master. +3. To address the issue of disconnect between sub teams, we plan on switching the roles for the next iteration, so the people who worked on mobile will now work on web, and vice versa. This will allow team members to better understand different parts of the application and save us time during our weekly updates, as it eliminates the confusion of unfamiliar parts. ## Product - Review |
