FSP Proposal Feedback

[AAlfarho]

Wiki Page Home

• Is the first page you see upon entering the wiki
• Contains a welcome message
• Contains a link/placeholder for a link to the live page
• All links in the right sidebar should contain each wiki page and link to the correct page
• Correctly formatted
  • each wiki page is listed in bullet points
  • all links route the correct page

MVP List

• Should have 7 MVPs.

  • 3 of those are User Auth, Heroku, and Production README.
  • The other 4 are from the MVP List.

• Contains a description sentence of the app

• At least one CRUD feature, which states what CRUD operations are planned (creation, reading, updating, deletion)

• Estimates how long it will take the code each MVP

• Each App specific MVP needs the following bullet points are added:

  • Adequate styling
  • Smooth, bug-free navigation
  • Seeded with info to demonstrate this feature

• Correctly formatted

  • MVPs are listed in an ordered list
  • Each MVP is broken down into bullet points

Comments:

Great job on the definition of your MVP's and the estimated time. This section is complete!
As for the order of the MVP's, lets discuss this tomorrow on how to address MVP's that rely on each other to be completed.

Database Schema

• Contains correct datatypes

  • WIll the published column on bookbe a string or datetime? Same for the create/updated_at.

• Contains appropriate constraints/details

  • primary key
  • not null
  • unique
  • indexed
  • foreign key

• Contains bullet points after the table that state which foreign keys will reference to which table, or references to the associations which will be made

• Correctly formatted

  • schema is written in a table format
  • the table's name are back_ticked
  • the table header column names are bolded
  • columns names are lowercased and snaked_cased and back_ticked

Comments:

Great job on the database schema, indexes and references look appropriate.

Routes

• Routes accurately reflect MVPs and Component Hierarchy
• Covers the frontend functionality of the site through routes that match to the wireframes
• Contains the following sections: API Endpoints(Backend), and Frontend Routes
• Each route has a description
• API Endpoint routes contains wildcard variables written in snake_case
• Frontend routes contains wildcard variables written in camelCase
• Routes does not contain superfluous routes
  • Will we be able to see other users bookshelves? If no, then we don't really need the :userId on the frontend route, right? If we do, disregard this comment and check.
• Have API routes that will allow the front end to get all info it needs and does not have unneeded routes:
• Correctly formatted
  • Routes are displayed with inline coding text (backticks)

Comments:

Kudos for the attention to detail in your backend routes, they look really solid!

Sample State

• State shape is flat!
• State's keys are camelCased, (check the image_url key)
• All keys within the values in the state are accessible in the schema (Ex: if you create a imgUrl key in the state, make sure your database also has a column that contains an img_url)
• Correctly formatted
  • Sample state is rendered with 3 back ticks before and after. This will display the state as a code block instead of a giant line of text
  • Top level slices
    • entities
    • session
    • errors (here or in ui)
    • ui (if needed)
      • UI will be used as the slice for all things UI, the perfect example would be loading spinners, however, if nothing comes to your mind at the moment, there is no need to add it.
  • Should NOT have nested slices, aka comments inside of posts
    • Some info from other tables is ok, for instance:

Comments:

• We need to decide whether users will have imageUrl or not, I would suggest for time being to go with a placeholder image, as user profile is not part of the MVP.
• The state for entities.users looks a bit funky, take a look at the inline comments.

   users: {
        5: {
       { // extra curly brace here?
         id: 4, // typo here, it should be 5, right?
         username: realreelname,
         email: reallyreall@fakeemailsRus.com,
         img_url: '/path/to/user/img',
         bookshelf: 45 // will users have more than 1 shelf?
     }
   },

Component Hierarchy with Wireframes

• All routes listed in the routes wiki page is also listed in the component hierarchy
• Each component, if necessary, has route, state, and other components it renders example
• Necessary components are wrapped in a container
• Correctly formatted
  • Bullet point hierarchy
  • Component names are displayed with inline coding text (backticks)
• Wireframes included
  • Every component listed in the component hierarchy wiki page has at least one wireframe
  • Every MVPs listed on the MVP wiki page has at least one wireframe
  • Every route listed on the route wiki page has at least one wireframe
  • Contains Containers
  • Correctly formatted
    • Wireframe images display on the page
    • Every wireframe has a header title

Comments:

• Ads are not part of any MVP I would suggest leaving them as a bonus.
• There are certain features/components of the site that are not part of the MVP'; as we should not have a dummy, non-functional placeholders, let's not have anything that is not MVP on our layout, that will include:
  • SiteSpecificItem
  • AdvertisementItem
  • Feed
  • RecommendedBooks
  • BookTriviaContainer
    Reason for taking them out is not only that they are not MVP's but in order for them to look & behave properly, they would have to rely on a heavily seeded DB, which then again steers us in a bonus direction. However that leaves us with an empty home page, let's discuss this tomorrow on how we can address this.

Amazing attention to detail and planning on the proposal, kudos !
Please check the missing checkboxes as you update your proposal.

[ttillotson]

Hey, went over your revisions. Below are my updates/comments/concerns:

Would I include bonus MVPs at the bottom of my current MVP list or move it elsewhere, such as Milestone/Issue?

• Bottom of MVP
• Milestone/Issue
  Note: I will move ads and User img_url to bonus.

User Profile/Bookshelves

User profiles will be their bookshelf. I feel it would remove a lot fo intuitive functionality to not be able to click on other users, easiest way to fix this is to route clicks to their combined bookshelf since this has the most relevant information that is already keyed into my system. With that in mind, users will have multiple shelves (currently reading, want to read, have read, plus the ability to create a new one) and the combined shelf will be a fetched joins table of all their shelves.
With this implementation it makes the most sense to have the shelves associated to their owners and let the database keep its own count for them, yes?

• Yes
• No