rubyyyt/cogs-121-project

cogs-121-project's Issues

Milestone 1 Feedback

At the moment, this app idea is a bit unfocused. I'm not sure how your group intends to distinguish who qualifies as "less fortunate," and are deserving of receiving funds. Furthermore, another potential issue could arise when considering the disparity between the number of people rich enough to be philanthropists, and the number of people in need of some kind of aid. While the tagging system in prototype 2 could be a good way to add some organization, at the moment I still think the idea is too broad. Maybe your group could look into constraining the population to somewhere local, or focus on one of the two populations (for example: focus on getting resources to the less fortunate).

The current APIs or data sources that you've provided are also a bit too general for the task you're trying to do. While linkedin may be a good way to potentially find philanthropists, again, I'm not sure how the app will determine who the "less fortunate" are. There may be databases provided by charity organizations that could potentially have more information on people in need of aid.

The two storyboards that your team has submitted feel pretty close to one another. In either case, the philanthropist and the person in need are connected and are able to get a bit happier through a transaction of funds. However, since the details are a bit different, I think that this does show some other potential uses of the app.

The paper prototypes that your group has submitted just show different functionality from the same interface, rather than showing the same functionality with a different interface. From what I've read from your description, in the end product, both the donator and the beneficiary screens should be part of the app. As a result, the two paper prototypes that you've submitted would be part of the same interface. Furthermore, while prototype 1 has some interaction flow visible, prototype 2 is just a single page, with no indication of what the other buttons and navigation will do. The interface looks pretty clean and organized, but I do need to see more on how the app functions.

Rubric items fulfilled:
Full Points: [1,2,3,4,6,8,10,11]
Deductions: (5,7,9,12,13)

You are in: Group B
Your TA is: Aaron

On the CORS issue you guys were asking about in class.

I did some additional digging on the CORS error you guys mentioned at grading today. From the looks of it, this error could potentially be occurring because the google maps api expects these types of api calls to be from the server (backend) instead of the client (frontend). In real world web programming, it's generally bad convention to make api calls from the frontend, since it means that your api keys will be viewable to anyone accessing the site, making it a huge security risk. As a result, many web apis will require that you make your api calls from the backend, denying any client-side requests. Unfortunately, for the purposes of this class, since you're only demo'ing the code to the TAs, this is somewhat glossed over in lecture.

Here's a stackoverflow link that outlines a similar problem: https://stackoverflow.com/questions/42180788/how-to-use-cors-to-implement-javascript-google-places-api-request

For making ajax calls from the server, you can use node's built in http request methods, which allow you to make GET or POST requests from the server itself, or you could install an npm module that makes the process simpler, such as request or unirest

Milestone 4 feedback

Milestone 4 score: 6/15

-5 points were lost for the milestone4.md submission

Please remember that this class has a no late submission policy, especially for the md files. Unfortunately, since the md file wasn't present in the directory until days after the due date, I can't give credit for it.

-1 point lost because the map feature was still statically locked, and not intractable.

-1 point lost because the first feature didn't really have an in-depth code explanation

-1 point lost because there was no additional code implementation other than the static html tag.

Notes: Even if a feature is broken, please upload it into the submission. Being able to look through the "broken" code can still get you extra points for the complexity and walkthrough portions of the rubric.

-1 point lost because the login function was not completely functional in uploading the the information into the database.

Milestone 3 Feedback

Milestone 3 Grade 13.5/15

-1 point lost because the Milestone3.md file was submitted after the due date. I pulled the version of the milestone that was before the due date, but that one doesn't have the skeleton images embedded in it.

-0.5 point lost because the ajax interaction displayed was still a hard-coded function, even though it correctly called the api.