AC:

• Create our own Firestore database
• Share access to our own database with the rest of the team
• Update to the new database in our code
• Check that the behavior (read/write) remains the same

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

AC:

• style the "Add Items" page according to the mockup

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

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:

• 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:

• convert all <div> tags to updated semantic tags (see resources below)
• seek all opportunities for WCAG best practices

https://levelup.gitconnected.com/getting-in-the-habit-of-writing-semantic-html-c7e507606385
https://www.w3schools.com/html/html5_semantic_elements.asp
https://medium.com/swlh/semantic-html-for-better-accessibility-a54d0742033f

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

• add sass into project as a dependency
• create a variable.scss file that will hold common reusable variables outlined in our wireframes/mood board: https://www.notion.so/Mood-Board-5f62f8cd9a5a45359a32dd7b901151f5

AC:

• Home page should be styled per mock up using colors and fonts as indicated in our Sass file

AC:

• should include colors and type treatment of wireframe
• should tweak timers and copy for best UX

https://sweetalert.js.org/docs/#theming

AC:

• Nav bar should display the following icons:
• adding a new list item -> directs user to add item component
• viewing list -> directs used to list view component
• "logging out" -> removes token from local storage and brings user back to home page
• Icons noted above should only be visible for users who are currently logged in (not on home page)
• Nav bar should be rendered across the entire app
• Nav bar should match style/colors from wireframe and sass file

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

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

AC:

• create folders and .scss files for all necessary React components
• refactor code where possible to include pertinent selectors to the corresponding file

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.

AC:
Update the following meta tags:

• page title
• favicon
• description
• Open Graph (image, title, description, url, and type)

Helpful resources to reference:

• https://www.w3schools.com/tags/tag_meta.asp
• https://neilpatel.com/blog/open-graph-meta-tags/
• https://ogp.me/
• https://medium.com/@weberzt/how-to-add-a-display-image-to-your-react-app-using-meta-tags-1b84fd50f57

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

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

AC:

• clicking on either "share token" or "log out" the user will remain on the same page

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
  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

The nav bar already has the icons to "log out" and "share token" so this is mainly to add the logic/functionality for them.

AC:

• "log out" -> removes token from local storage and brings user back to home page once they click on the icon
• "share token" -> using sweet alerts (which is already added as a dependency), show the user their token with a message once they click on the icon (i.e. “Share this token with friends or use it yourself to access this list again: mark marks swipe”

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 implemenation 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:

• Name of App
• Description of App
• Links to video demo and deployed site
• Visuals (screenshots and/or gifs)
• Installation steps
• Features (what the user can do)
• Tech Stack & Tools
• Contributors
• Acknowledgements
• (Optional) Resources used

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)