Design Docs To Do List

[mwmadsen67]

Wiki Page Home

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

---

MVP List

• [x] Should have 7 MVPs.
  • [x] 3 of those are User Auth, Heroku, and Production README.
  • [x] The other 4 are from the MVP List or they have clarified them with you
• [x] Contains a description sentence of the app
• [x] Includes two to three detailed bullets on functionality and presentation of feature
• [x] At least one CRUD feature, which states what CRUD operations are planned (creation, reading, updating, deletion)
• [x] Estimates how long it will take the code each MVP
• [x] Correctly formatted
  • [x] MVPs are listed in an ordered list
  • [x] Each MVP is broken down into bullet points

---

Database Schema

• [x] Contains correct datatypes
• [x] Contains appropriate constraints/details
  • [x] primary key
  • [x] not null
  • [x] unique
  • [x] indexed
  • [x] foreign key
• [x] 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
  • [x] foreign key and table name are lowercased, snake_cased and back_ticked
• [x] Correctly formatted
  • [x] schema is written in a table format
  • [x] the table's name are lowercased, snake_cased and back_ticked
  • [x] the table header column names are bolded
  • [x] columns names are lowercased and snaked_cased and back_ticked

---

Sample State

• [x] State shape is flat!
• [x] State's keys are camelCased
• [x] All keys within the values in the state are accessible in the schema
• [x] Correctly formatted
  • [x] Sample state is rendered with triple backticks, and the language ```javascript...```). This will display the state as a code block instead of a giant line of text
  • [x] Top level slices
    • [x] entities
    • [x] session
    • [x] errors (here or in ui)
    • [x] ui (if needed)
  • [x] Should NOT have nested slices, aka comments inside of posts
    • Some info from other tables is ok, for instance:
    • the author username and imageurl for a post. basically any info that the user can't change
    • like count and a boolean on whether the user likes the post instead of a likes slice

---

Backend Routes

• [x] Contains the following sections: HTML, API Endpoints(Backend)
• [x] Each route has a description
• [x] API Endpoint routes contains wildcard variables written in snake_case
• [x] Routes does not contain superfluous routes
• [x] Have API routes that will allow the front end to get all info it needs and does not have unneeded routes:
  • probably doesn't need a GET likes api endpoint because that info comes through the post show

---

Frontend Routes

• [x] Frontend routes contains wildcard variables written in camelCase
• [x] Correctly formatted
  • [x] Routes are displayed with inline coding text (backticks)

[mwmadsen67]

Hi Wenchong, here are some notes on your design docs:

MVP List:

• I would take out the switch between film strip and grid views for the first MVP
• The second MVP has a lot of features, it might make sense to simplify it to the more important basic features, like loading/saving and scaling
• The text editing MVP makes sense, I would consider this an important MVP which is why simplifying the previous ones is crucial so that you can reach this one before completing those other features.
• After adding image CRUD to your slides, I'm cool with you adding back all the previous features.

Schema:

• why do docs need width and height?
• what is a group?
• you dont need a url/blob column in images, image urls will be stored using associations from active storage

State Shape:

• state shape looks good.

Frontend Routes:

• I think the frontend route naming is a bit off, I might call it something like docs/:docId/slides/:slideId or presentations/:presentationId/slides/:slideId.
• Otherwise this looks good

Backend Routes:

• editing a slide should be PATCH /api/slides/:id
• same for the rest of them
• you will likely need a backend route for the slide index - GET /api/slides
• I dont think that most of those controllers need their GET routes (GET shapes for example). When you get one slide you will be able to grab all the wrappers and associated info in the jbuilder for that response, and you shouldnt have to make an extra AJAX request.

Looking good Wenchong, feel free to comment here on any questions or comments you have for me.

[wenchonglai]

Hi Mike, thank you for all your comments. Your advice is extremely helpful and makes more and more sense as I proceed.

Based upon your comment notes, please let me know if I could change the MVP List to below. Thank you.

MVP List

Doggie Slides, a clone of Google Slides, is a web-based editing and presentation application that supports the create, read, update, delete, as well as rendering of basic slides, texts, and graphics.

Basic Features

1. Hosting on Heroku (04/03/2020, 1 day)

2. New account creation, login, and guest/demo login (04/04/2018, 2 days)

• Users can sign up, sign in, and log out
• Users can use a demo login to try the site
• Users cannot access the slides editing page without logging in

3. Basic editing and presentation interface (04/06/2018, 2 days)

• The user interface of the intro and editing pages are similar to Google Slides.
• Logged in users can add/modify/delete slides
• Logged in users can switch between the filmstrip and grid views
• (Bonus; as advised) Logged in users can switch between the editing and presentation modes

5. Basic text editing (04/08/2018, 2 days)

• Logged in users can type in text boxes
• Logged in users can add/change/remove basic text styles including fill, font family, bold, italic, underscore and horizontal alignments.

4. Text and graphic element management and editing (04/10/2018, 2 days)

• Logged in users can load/save text and graphic elements
• Logged in users can scale/rotate text and graphic elements
• Logged in users can change the orders of text and graphic elements
• (Bonus; as advised) Logged in users can group/ungroup text and graphic elements

6. Image and shape editing (4/12/2018, 2 days)

• Logged in users can create/edit/delete images through Active Storage
• Logged in users can crop images and apply image filters
• Logged in users can create/edit/delete basic shapes including straight lines, squares, eclipses, and straight-line arrows

7. Production README (04/14/2020, 1 day)

Bonus Features

Caching and autosave

• Logged in users can undo/redo a limited amount of executions
• Opened files can be automatically saved to the database

Multi-User collaboration

• Logged in users can invite other logged in users to collaborate
• Collaborating users can edit different slide element simultaneously
• Collaborating users can edit the same slide element simultaneously
• Elements saved and not yet saved to the database are displayed in different styles.

[wenchonglai]

Hi Mike, please see my response to your comments regarding the schema, frontend routes, and backend routes below. Thank you.

Schema:

• why do docs need width and height?

  • So that front end container can reference them to generate slides with a fixed width-to-height ratio (i.e. 16:10).
  • For now, the width and height are default values.

• what is a group?

  • a group contains the id and type of different slide elements. Due to the workload, I would like to know if this could be a bonus feature.

• you dont need a url/blob column in images, image urls will be stored using associations from active storage

  • will do.

Frontend Routes:

• I think the frontend route naming is a bit off, I might call it something like docs/:docId/slides/:slideId or presentations/:presentationId/slides/:slideId. Otherwise this looks good
  • Will do. I am still struggling with the rerouting to the correct url.
  • I also reversed-engineered the session routes a bit.

Backend Routes:

• editing a slide should be PATCH /api/slides/:id; same for the rest of them

  • already incorporated

• you will likely need a backend route for the slide index - GET /api/slides

  • already incorporated

• I dont think that most of those controllers need their GET routes (GET shapes for example). When you get one slide you will be able to grab all the wrappers and associated info in the jbuilder for that response, and you shouldnt have to make an extra AJAX request.

  • already incorporated

[mwmadsen67]

Thanks for the response Wenchong. Yes I am happy with these updates to your MVP list and the rest of your design docs. Also, I agree that groups could be a bonus feature due to the workload.

Feel free to slack me or comment here if you have any questions.

[wenchonglai]

Will do! Thank you so much, Mike!