Wiki Feedback

[GordonRBurgess]

Wiki Feedback


After you have reviewed and addressed these changes, please respond to this issue and send Gordon and Ed a link. We will provide followup after reviewing your changes before closing this issue.



## MVP List

• [x] 

Please organize this list hierarchically so that your 3 (or more) top-level MVPs are clear.

Schema

• [x] This schema should be simplified - you only need a many-to-many between users to capture relationships between pairs of users - attributes pertaining to the relationship go into the join table. (there is a bit of a normalization issue here, because in a relationship between A and B, A's following of B might not be the same as B's following of A - but presumably they both agree to have a relationship or there isn't much to do in the join table. A simple workaround would be to literally have user_a and user_b (or (user_0, user_1), or whatever) and then track attributes like a_check_b_interval and b_check_a_interval. The more normalized (but not necessary, or even maybe desirable!) way to do this would be to have "relationship" or "circle" as a table, and then have the many-to-many be between the user and the circle, and the attributes on that relationship denoting check-in frequency, etc. (Simple and easy is the target here - I wouldn't make a circles table unless multi-way conversations need to be supported)

• [x] Appointments.date needs to be a TIMESTAMP / datetime field. This probably means you'll also need to deal with timezones, which then have to be part of your profile. Please let Ed or Gordon know if you need help implementing timezones.

• [x] ToDo items probably need a due date (which might be NULL - but for those of us who procrastinate this too is an issue!)

• [x] ToDo items need a status of some sort - at least an is_complete field.



## Back End Routes

• [x] in general - consider organizing your documentation here as:

1. Class A a. GET api/<class a> ... n. `DELETE api/'
2. Class B a. GET api/<class b> ... n. DELETE api/<class b>

This will make it easier to follow what you are doing.




• [x] GET / - you may only need this if you are rendering non-user-specific data on the home page

• [x] there are both _api/... and api/... routes here - are they distinct for a reason? If not, they should app be consistent.



## Front End Routes 


• [x] looks good in general - changes to the BE may change some things here

Wireframes

• [x] In general these look good - you may want to rework following/followed if you change your database schema to a single many-to-many relationship between users

Overall Suggestions

• [x] consider how a user of this site might go about contacting another user, or deciding how much personal information they wish to share, in order to be found in a search. Will you require that a user know the email address or other contact information before they can ping another user? Should a user be able to see a list of user names without any qualification? Don't overly complicate this, but anything you can do to make this app more friendly to persons experiencing the issues you are working to address is going to make this look even better.

[shaieleigh]

I just fixed the check marks and then checked them off, I don't know why they weren't showing up before, strange... anyway I have gone through and did as much as I understood from it, I don't entirely understand every part of wiki yet...

[GordonRBurgess]

it's because markdown is not a language that the PTM knows as well as SQL or Python... :D. Thanks, Shaie!

On Wed, Oct 7, 2020 at 12:16 PM Shaie notifications@github.com wrote:

I just fixed the check marks and then checked them off, I don't know why they weren't showing up before, strange anyway

• [ ]

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/shaieleigh/bestLifeLiving/issues/1#issuecomment-705043600, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJQQBRMAKCEA5FL3NYDVC6LSJSH37ANCNFSM4SGKS7BQ .