Design Docs Review #1 - MVP List & Schema

mmcnulty20 commented 4 years ago

Good start so far with your design docs!
A few changes to make going forward:

MVP List

[x] What functionality can be accessed without being logged in? What requires being logged in?
[x] What can a Demo user not do that a normal user account can?
[x] What will the index page use to determine the order videos are displayed?
[x] What are "watching capabilities"?
[x] Might want to move rating (or thumbs up/thumbs down behavior) to a separate or bonus MVP - especially as they aren't even viewable unless you've completed your Bonus User Profile MVP
[x] Work on Genres before search - you'll need to have genres to search or sort by genres, which will be a really common way to search through the app

[x] This setup seems to only exist for movies, not shows or other forms of video, just check in with me to verify that's the intention.
[x] Correct table names to follow conventions (lowercase, pluralized, camel case)
[x] genre_id exists in multiple tables, but there is no corresponding genre table.
[x] Break apart the joins table or remove it completely - the current film_info table is doing way too much. Think about what pieces need a joins table at all, and don't duplicate information that isn't necessary to be duplicated (like genre_id and director_id being duplicated across the casting of each actor).
[x] Don't bother with the actors/castings at all - those could be a bonus, but will be far too much work in creating the initial project
[ ] Does a video only have one genre or possibly have multiple genres? Set up tables accordingly
[x] Thumbs up could be a bonus, but either way shouldn't need a boolean - the presence or absence of the entry in that table could handle that.
[x] Add created_at/updated_at columns to each table
[x] Index on all foreign keys, as well as something you might frequently search by (like the title of the movie)
[ ] An entry in the queue should have a unique combination of user_id and movie_id

mmcnulty20 commented 4 years ago

[x] Users that are not signed in would only be able to view the splash page
[x] If you want to add preferences based on viewed films, you should probably clarify that a bit further, but that also sounds like functionality that should be a bonus feature! :)
[x] Will the index page group by genre like Netflix?
[x] It would be more accurate to refer to the page that displays results as a "Search landing page," and would distinguish it from the earlier Index page MVP (as search results and the initial display are handled differently)
[x] Searching as you type is impressive functionality, but how will you keep it from slowing down the page too much? Using some technical phrasing here would be more specific, and also would reflect better on the project
[x] Where is the queue used/accessed? (minor)
[x] Total timeframe for MVPs is longer than the allotted time.
Schema
[ ] Films can have multiple genres (rather than storing a genre_id on the films table) and there is still no genres table
[x] What purpose does the thumbs up | ??? column serve?
[x] Should write schema for bonus profiles MVP (low priority for the moment)
[ ] The unchecked boxes from the previous set of issues still need to be addressed at least in some form

mmcnulty20 commented 4 years ago

Just reviewed the MVP issues as requested for the moment:

[x] Still need clarity on how the site would track/utilize films you'd viewed to considered that a "preference" - this is something that could get complex, and I'd really recommend bringing it out to a bonus feature.
[x] It's definitely a bit pedantic, but the search MVP itself should probably still be called "search," the issue before was that you referenced individual index pages for genre/title searches and, while they will go through the index controller action, the distinction of them displaying a search landing page helps clarity.
[x] Look into debouncing and other ways to reduce server load for searching while typing - the concern is less in the frontend side, and more in how frequently that makes requests to the backend and the amount of results that can possibly return. It'd be wise to limit both of those, but at least one would be necessary.

mmcnulty20 commented 4 years ago

[ ] Debouncing, in my opinion, shouldn't be a bonus but instead incorporated into functionality of the search MVP, but we will discuss this later in a 1-on-1
Schema
[ ] Films can be associated with multiple genres - use a joins table rather than the single genre_id on a film
[ ] Queues still need a movie_id, it just needs to be unique in the scope of the user_id