dgorley / tcl-test-repo Goto Github PK

AC:

• User is able to tap a checkbox or similar UI element to mark an item in the list as purchased
• Item should be shown as checked for 24 hours after the purchase is made (i.e. we assume the user does not need to buy the item again for at least 1 day)

This is 1 of 2 stories that should be completed in the first week to enable further development of the app.

AC:

• react-router-dom has been added as a project dependency
• Links are present and persistent at the bottom of the app: one for the “list” view, the other for the “add an item” view
• When one of the links is clicked, the browser URL updates to represent the current view and a matching view component is displayed
• Whichever view is selected, the corresponding link should display in bold text

Notes:

• Some pairs have gone straight to wanting to integrate a CSS framework to achieve the “links pinned to the bottom of the page” AC here. You're encouraged to keep it simple at this point. Perhaps look into position: fixed; or perhaps look into a tutorial on CSS grid. There will be time to get fancy later in the project.

AC:

• User is able to tap a checkbox or similar UI element to mark an item in the list as purchased
• Item should be shown as checked for 24 hours after the purchase is made (i.e. we assume the user does not need to buy the item again for at least 1 day)

Notes:

• One challenge your pair may work through is figuring out you they will test this.
• E.g., maybe create a few sample items then go into the Firestore console and manipulate the dates. T
• The wirefrrame shows the use of simple checkboxes for this purpose, which is fine for now. https://github.com/the-collab-lab/smart-shopping-list/blob/main/_resources/wireframes/list-populated.png

AC:

• When a purchase is recorded, the estimated number of days until the next purchase date should be calculated and recorded in the database

The script at /src/lib/estimates.js should be used to calculate the next estimated purchase interval.

Notes:

• Think through the data that is needed as inputs to the function in estimates.js and how to use the output.
• It is likely at this point you'll need to adjust the schema for an item to accomodate the data points required.

AC:

• When a purchase is recorded, the estimated number of days until the next purchase date should be calculated and recorded in the database

The script at /src/lib/estimates.js should be used to calculate the next estimated purchase interval.

This is 1 of 2 stories that should be completed in the first week to enable further development of the app.

AC:

• react-router-dom has been added as a project dependency
• Links are present and persistent at the bottom of the app: one for the “list” view, the other for the “add an item” view
• When one of the links is clicked, the browser URL updates to represent the current view and a matching view component is displayed
• Whichever view is selected, the corresponding link should display in bold text

A shopping list item consists of the following data points:

• Name of item
• How soon are you likely to buy it again?
  • Soon (in the next 7 days)
  • Kind of soon (in the next 14 days)
  • Not soon (in the next 30 days)
• Last purchased date

AC:

• User is presented with a form that allows them to enter the name of the item and select how soon they anticipate needing to buy it again (Soon, Kind of Soon, Not Soon)
• When the user submits the form, the item is saved to the database, associated with the user’s token
• Along with the item name, an integer corresponding to the estimated number of days until next purchase is saved: 7 for “Soon”, 14 for “Kind of Soon”, and 30 for “Not Soon”
• The last purchased date should be set to null initially (i.e. you can create an item without purchasing it)
• Item names should be displayed as a simple, unordered list on the list view after they’re added

This is 1 of 2 stories that should be completed in the first week to enable further development of the app.

AC:

• The following have been added as project dependencies: firebase & react-firebase-hooks
• Make a change in the Firestore database and it shows up in the app
• Make a change in the app and it shows up in the Firestore database

Possible item states are as follows:

• Need to buy soon (fewer than 7 days)
• Need to buy kind of soon (between 7 & 30 days)
• Need to buy not soon (more than 30 days)
• Inactive (when there’s only 1 purchase in the database or the purchase is really out of date [the time that has elapsed since the last purchase is 2x what was estimated])

AC:

• Items in the list are shown as visually distinct (e.g., with a different background color on the list item) according to how soon the item is expected to be bought again: Soon, Kind of soon, Not soon, Inactive
• Items should be sorted by the estimated number of days until next purchase
• Items with the same number of estimated days until next purchase should be sorted alphabetically
• Items in the different states should be described distinctly when read by a screen reader

Notes:

• The criteria for an item being inactive has tripped up teams in the past. It's been re-worded to be more clear, but the gist is that an item is inactive if the time that has elapsed since its last purchase is twice (or more) what was estimated the last time it was purchased.
• E.g., if the last estimate was 14 days and 28 days have elapsed, the item is considered inactive.
• Teams in the past have also overengineered the solution here by breaking the list out into separate groups, but it should be achievable in a single list where the visual treatment is different based on what category the item falls into.
• Be sure to not only to use color to denote how soon the user will need to buy the item, as noted in the wireframe. https://github.com/the-collab-lab/smart-shopping-list/blob/main/_resources/wireframes/list-populated.png
• Good luck, you got this!

The last 2 weeks of the project will function a little differently than the rest. Your team will self-organize around a lightweight design process to come up with a polished look-and-feel for your app.

This will require you to make decisions together as a whole team, then implement your vision. The process outlined here is our best suggestion for how to proceed, but you are free to take whatever approach you see fit!

You’ll notice this is the last issue on the board! That’s because the expectation is for you to write the stories needed to complete the implementation of your design direction.

As always, lean on your mentors for guidance if you are unsure how to proceed!

Design Process

1. What is the tone you’re going for? What feeling are you trying to convey? Come up with 3 to 5 words that best capture how you want users to perceive your app.
   • Examples:
     • Fun
     • Clean
     • Ironic
     • Businesslike
     • Many more example words
2. Create a mood board. A mood board helps everyone get on the same page in terms of the direction in which you want to take your design. Add elements to your mood board that represent the tone you’re trying to achieve.
3. Decide on fundamental elements of your design, including the following:
   • Typography ← Google Fonts is a good choice for finding web fonts you can use in your app. They have hundreds of typefaces to choose from, but consider usability in whichever one(s) you choose!
   • Colors ← Make sure these are accessible!
   • Iconography / imagery ← Start here to find free icons you can use in your app!
4. Decide whether you want to code your CSS from scratch or integrate a CSS framework. There are pros and cons to each!
   • Vanilla CSS gives you more control, but it can be harder and/or take more time to achieve a given effect.
   • Frameworks help you get things done faster, but often at the cost of not giving you full control of the design.
5. If you choose to use a framework, evaluate your options to make sure you pick one that will suit your needs.
   • Consider the following:
     • Quality of documentation
     • Ease of integration
     • Built with accessibility in mind
     • Activeness of the community
   • Quality frameworks you might consider include the following:
     • Bootstrap
     • Chakra UI
     • Material UI
     • Semantic UI
     • TailwindCSS

It’s possible our users may make an error when entering an item or may decide they won’t be buying a certain item again in the future. Let’s help them keep their lists tidy!

AC:

• User is able to delete an item from the shopping list
• Before deleting, prompt the user to confirm that they really want to delete the item to prevent accidental deletions
• Deletion should cause the associated record(s) in the database to be deleted

A shopping list consists of a set of items associated with a user’s token. Creating a new list consists of the following sequence:

• Generate a new, unique token
• Save the token to localStorage
• Show the user the list view

The following script should be used to generate a suitable token: src/lib/tokens.js

AC:

• For users who do not already have a token/list, a button or link exists on the home screen that allows them to create a new list
• Clicking the button/link generates a new token and saves it to localStorage
• Once the token has been created and saved, the user is redirected to the "list" view
• For users who do have a token already saved in localStorage, they should be shown/redirected to the "list" view

AC:

• The list view, when there are no items to display, should show a prompt (e.g., a button) for the user to add their first item

• Notes:

• The wireframe is a little short on the "welcoming" part of the story, but otherwise is functionally complete for the purposes of the AC. https://github.com/the-collab-lab/smart-shopping-list/blob/main/_resources/wireframes/list-empty.png

Possible item states are as follows:

• Need to buy soon (fewer than 7 days)
• Need to buy kind of soon (between 7 & 30 days)
• Need to buy not soon (more than 30 days)
• Inactive (when there’s only 1 purchase in the database or the purchase is really out of date [the time that has elapsed since the last purchase is 2x what was estimated])

AC:

• Items in the list are shown as visually distinct (e.g., with a different background color on the list item) according to how soon the item is expected to be bought again: Soon, Kind of soon, Not soon, Inactive
• Items should be sorted by the estimated number of days until next purchase
• Items with the same number of estimated days until next purchase should be sorted alphabetically
• Items in the different states should be described distinctly when read by a screen reader

AC:

• Display a text field above the top of the shopping list
• As the user types into the field, the list should narrow to display only items that contain the text the user entered in the filter field
• When the field has text in it, the user should be able to tap a UI element (e.g., with an "X" button next to the field) to clear the field
• The filter text should match any part of the item name (i.e. it should not only match from the start of the string)

Notes:

• The wireframe shows the filter field, but not it being used. https://github.com/the-collab-lab/smart-shopping-list/blob/main/_resources/wireframes/list-populated.png
• The following example app from MDN is a great example of providing feedback that is accessible to screenreaders when things change on the screen. https://moz-todomvc-react.netlify.app/

A shopping list item consists of the following data points:

• Name of item
• How soon are you likely to buy it again?
  • Soon (in the next 7 days)
  • Kind of soon (in the next 14 days)
  • Not soon (in the next 30 days)
• Last purchased date

AC:

• User is presented with a form that allows them to enter the name of the item and select how soon they anticipate needing to buy it again (Soon, Kind of Soon, Not Soon)
• When the user submits the form, the item is saved to the database, associated with the user’s token
• Along with the item name, an integer corresponding to the estimated number of days until next purchase is saved: 7 for “Soon”, 14 for “Kind of Soon”, and 30 for “Not Soon”
• The last purchased date should be set to null initially (i.e. you can create an item without purchasing it)
• Item names should be displayed as a simple, unordered list on the list view after they’re added

Notes:

• The add item form has the potential to be a lot of scope. The wireframe https://github.com/the-collab-lab/smart-shopping-list/blob/main/_resources/wireframes/add-item.png has several notes related to accessibility and UX.
• Eventually, the list will look like the following wireframe: https://github.com/the-collab-lab/smart-shopping-list/blob/main/_resources/wireframes/list-populated.png
• It's good for your team to look at the wireframe now, but be sure not to try to implement all of the visible functionality at once. There will be future stories to add all of those features.
• For this story, it's sufficient just to get a simple list of the items displaying.

AC:

• The list view, when there are no items to display, should show a prompt (e.g., a button) for the user to add their first item

It’s possible our users may make an error when entering an item or may decide they won’t be buying a certain item again in the future. Let’s help them keep their lists tidy!

AC:

• User is able to delete an item from the shopping list
• Before deleting, prompt the user to confirm that they really want to delete the item to prevent accidental deletions
• Deletion should cause the associated record(s) in the database to be deleted

Notes:

• As noted in the wireframe https://github.com/the-collab-lab/smart-shopping-list/blob/main/_resources/wireframes/list-populated.png activating the "Delete" link should pop-up a confirmation dialog because this is a "destructive" action.
• Many teams jump to a modal as the solution here, but modals are fraught with accessibility concerns, so consider using a simple JavaScript confirm dialog.

AC:

• Display a text field above the top of the shopping list
• As the user types into the field, the list should narrow to display only items that contain the text the user entered in the filter field
• When the field has text in it, the user should be able to tap a UI element (e.g., with an "X" button next to the field) to clear the field
• The filter text should match any part of the item name (i.e. it should not only match from the start of the string)

AC:

• Show an error message if the user tries to submit a new item that has the exact same name as an existing item
• Show an error message if the user tries to submit a new item that has the same name as an existing item, where capitalization has been normalized and punctuation has been removed
• The user’s original input should be what gets saved in the database

The last 2 weeks of the project will function a little differently than the rest. Your team will self-organize around a lightweight design process to come up with a polished look-and-feel for your app.

This will require you to make decisions together as a whole team, then implement your vision. The process outlined here is our best suggestion for how to proceed, but you are free to take whatever approach you see fit!

You’ll notice this is the last issue on the board! That’s because the expectation is for you to write the stories needed to complete the implementation of your design direction.

As always, lean on your mentors for guidance if you are unsure how to proceed!

Design Process

1. What is the tone you’re going for? What feeling are you trying to convey? Come up with 3 to 5 words that best capture how you want users to perceive your app.
   • Examples:
     • Fun
     • Clean
     • Ironic
     • Businesslike
     • Many more example words
2. Create a mood board. A mood board helps everyone get on the same page in terms of the direction in which you want to take your design. Add elements to your mood board that represent the tone you’re trying to achieve.
3. Decide on fundamental elements of your design, including the following:
   • Typography ← Google Fonts is a good choice for finding web fonts you can use in your app. They have hundreds of typefaces to choose from, but consider usability in whichever one(s) you choose!
   • Colors ← Make sure these are accessible!
   • Iconography / imagery ← Start here to find free icons you can use in your app!
4. Decide whether you want to code your CSS from scratch or integrate a CSS framework. There are pros and cons to each!
   • Vanilla CSS gives you more control, but it can be harder and/or take more time to achieve a given effect.
   • Frameworks help you get things done faster, but often at the cost of not giving you full control of the design.
5. If you choose to use a framework, evaluate your options to make sure you pick one that will suit your needs.
   • Consider the following:
     • Quality of documentation
     • Ease of integration
     • Built with accessibility in mind
     • Activeness of the community
   • Quality frameworks you might consider include the following:
     • Bootstrap
     • Chakra UI
     • Material UI
     • Semantic UI
     • TailwindCSS

AC:

• Show an error message if the user tries to submit a new item that has the exact same name as an existing item
• Show an error message if the user tries to submit a new item that has the same name as an existing item, where capitalization has been normalized and punctuation has been removed
• The user’s original input should be what gets saved in the database

Tokens can be shared with other users to allow them to co-manage a given list.

Joining an existing list consists of the following:

• User enters an existing token
• Save the token to localStorage
• Show the user the existing list

AC:

• When the user does not already have a token in localStorage, on the onboarding/home screen, a simple form is displayed that allows the user to enter a token
• Entering the token and hitting submit saves the token to localStorage, effectively giving them joint control of the list
• On submit, show an error if the token does not exist
• If they get an error message, allow them to try again or create a new list

Tokens can be shared with other users to allow them to co-manage a given list.

Joining an existing list consists of the following:

• User enters an existing token
• Save the token to localStorage
• Show the user the existing list

AC:

• When the user does not already have a token in localStorage, on the onboarding/home screen, a simple form is displayed that allows the user to enter a token
• Entering the token and hitting submit saves the token to localStorage, effectively giving them joint control of the list
• On submit, show an error if the token does not exist
• If they get an error message, allow them to try again or create a new list

Notes:

• As of this story, the welcome/home screen will be feature complete, as reflected in this wireframe: https://github.com/the-collab-lab/smart-shopping-list/blob/main/_resources/wireframes/welcome-screen.png
• For accessibility reasons, use a <label> tag for the share token field.
• You can assume that users will only be sharing a token if the list has actual items on it. So, let's say I create a New Shopping List, but never add any items to it, and haven't saved that particular token to Firestore, we can assume that's a list that doesn't exist.
• If you would like, you can save the token to Firestore immediately when creating a list, and then a user would be able to share an empty list (see issue 5).

A shopping list consists of a set of items associated with a user’s token. Creating a new list consists of the following sequence:

• Generate a new, unique token
• Save the token to localStorage
• Show the user the list view

The following script should be used to generate a suitable token: src/lib/tokens.js

AC:

• For users who do not already have a token/list, a button or link exists on the home screen that allows them to create a new list
• Clicking the button/link generates a new token and saves it to localStorage
• Once the token has been created and saved, the user is redirected to the "list" view
• For users who do have a token already saved in localStorage, they should be shown/redirected to the "list" view

Notes:

• Eventually the welcome/home page will look like the following wireframe: https://github.com/the-collab-lab/smart-shopping-list/blob/main/_resources/wireframes/welcome-screen.png
• It's good for your whole team to look at the wireframe now, but be sure not to try to implement all of the visible functionality at once. There will be future stories to add the other features such as joining an existing list.
• For this story, it's sufficient just to have a simple "create list" button. Although you are not required to save the token to Firestore, some teams have opted to also save the token to Firestore when generating a token.

This is 1 of 2 stories that should be completed in the first week to enable further development of the app.

AC:

• The following have been added as project dependencies: firebase & react-firebase-hooks
• Make a change in the Firestore database and it shows up in the app
• Make a change in the app and it shows up in the Firestore database

Notes:

• Don't do too much here. In past, pairs have built the whole add item form in the first week. The best approach is just to make a throw away view with a <button/> and a <div/>. Click the <button/> to send some data to the database. Have the data show up in the <div/>. Simple!
• Also, if you need more direction on how to use react-firebase-hooks, you can reference this commit from Alejandro: alejandronanez/smart-shopping-list-demo@d590adc and/or watch this Loom video where he explains how it works: https://www.loom.com/share/0dffa1a63bf24b449d6565c76606bbd9