mirror of
https://github.com/cse110-fa22-group29/cse110-fa22-group29.git
synced 2025-09-08 23:57:21 +00:00
Arthur Lu
@@ -1,16 +1,20 @@
|
||||
# Final Project Topic Decision
|
||||
- Status: accept
|
||||
- Deciders: team members and TA
|
||||
- Date: 10 / 27 / 22
|
||||
|
||||
- Status: accept
|
||||
- Deciders: team members and TA
|
||||
- Date: 10 / 27 / 22
|
||||
|
||||
## Decision Drivers
|
||||
- Needed to develop a local-first, CRUD application that would be simple enough to implement in the next few weeks
|
||||
|
||||
- Needed to develop a local-first, CRUD application that would be simple enough to implement in the next few weeks
|
||||
|
||||
## Considered Options:
|
||||
- Social Media Archive
|
||||
- Resume Builder
|
||||
- Copy/Paste
|
||||
- Food Journal
|
||||
|
||||
- Social Media Archive
|
||||
- Resume Builder
|
||||
- Copy/Paste
|
||||
- Food Journal
|
||||
|
||||
## Decision Outcome
|
||||
|
||||
Chosen Option: Food Journal, which allows users to hold their thoughts and ratings on meals and restaurants that they have been to. It is local-first, CRUD app, and fun. Therefore, we decided to choose this.
|
||||
|
||||
@@ -1,15 +1,19 @@
|
||||
# Finalized App Design on Figma
|
||||
- Status: accept
|
||||
- Deciders: Isaac Otero
|
||||
- Date: 11 / 08 / 22
|
||||
|
||||
- Status: accept
|
||||
- Deciders: Isaac Otero
|
||||
- Date: 11 / 08 / 22
|
||||
|
||||
## Decision Drivers:
|
||||
- Needed to figure out the wireframe and flow of our app
|
||||
- Needed to visualize the different features
|
||||
|
||||
- Needed to figure out the wireframe and flow of our app
|
||||
- Needed to visualize the different features
|
||||
|
||||
## Considered Option:
|
||||
- Different feature option
|
||||
- Color Scheme, font, spacing, and other design options were discussed
|
||||
|
||||
- Different feature option
|
||||
- Color Scheme, font, spacing, and other design options were discussed
|
||||
|
||||
## Decision Outcome:
|
||||
- Chosen Option: Design can be found at this link: https://www.figma.com/file/Qhugp1Dd0gPnJTbmmUIvsa/Wireframe?node-id=36%3A2
|
||||
|
||||
- Chosen Option: Design can be found at this link: https://www.figma.com/file/Qhugp1Dd0gPnJTbmmUIvsa/Wireframe?node-id=36%3A2
|
||||
|
||||
@@ -1,19 +1,19 @@
|
||||
# Use multiple CI/CD pipelines in parallel
|
||||
|
||||
- Status: accept
|
||||
- Deciders: Arthur Lu, Marc Reta
|
||||
- Date: 11 / 12 / 22
|
||||
- Status: accept
|
||||
- Deciders: Arthur Lu, Marc Reta
|
||||
- Date: 11 / 12 / 22
|
||||
|
||||
## Decision Drivers
|
||||
|
||||
- Need to perform many different CI/CD tasks
|
||||
- Need pipeline to be durable against any single failure
|
||||
- Need to perform many different CI/CD tasks
|
||||
- Need pipeline to be durable against any single failure
|
||||
|
||||
## Considered Options
|
||||
|
||||
- Single deep pipeline
|
||||
- Multiple short pipelines in parallel
|
||||
- Single deep pipeline
|
||||
- Multiple short pipelines in parallel
|
||||
|
||||
## Decision Outcone
|
||||
|
||||
Chosen Option: Multiple short pipelines in parallel as any one failure will not prevent code from being developed and deployed.
|
||||
Chosen Option: Multiple short pipelines in parallel as any one failure will not prevent code from being developed and deployed.
|
||||
|
||||
@@ -1,19 +1,19 @@
|
||||
# Use eslint for JS linting framework
|
||||
|
||||
- Status: accept
|
||||
- Deciders: Arthur Lu, Marc Reta
|
||||
- Date: 11 / 12 / 22
|
||||
- Status: accept
|
||||
- Deciders: Arthur Lu, Marc Reta
|
||||
- Date: 11 / 12 / 22
|
||||
|
||||
## Decision Drivers
|
||||
|
||||
- Need linting to work with multiple style standards
|
||||
- Need linting to be fast and informative
|
||||
- Need linting to work with multiple style standards
|
||||
- Need linting to be fast and informative
|
||||
|
||||
## Considered Options
|
||||
|
||||
- JSLint
|
||||
- eslint
|
||||
- JSLint
|
||||
- eslint
|
||||
|
||||
## Decision Outcome
|
||||
|
||||
Chosen Option: eslint for its low configuration complexity.
|
||||
Chosen Option: eslint for its low configuration complexity.
|
||||
|
||||
@@ -1,19 +1,20 @@
|
||||
# Use mocha for JS unit testing framework
|
||||
|
||||
- Status: accept
|
||||
- Deciders: Arthur Lu, Marc Reta
|
||||
- Date: 11 / 12 / 22
|
||||
- Status: accept
|
||||
- Deciders: Arthur Lu, Marc Reta
|
||||
- Date: 11 / 12 / 22
|
||||
|
||||
## Decision Drivers
|
||||
|
||||
- Need specification on how to write unit testing assertion statements
|
||||
- Need framework to perform unit testing quickly for immediate code feedback
|
||||
- Need specification on how to write unit testing assertion statements
|
||||
- Need framework to perform unit testing quickly for immediate code feedback
|
||||
|
||||
## Considered Options
|
||||
- JUnit5
|
||||
- Jest
|
||||
- Mocha
|
||||
|
||||
- JUnit5
|
||||
- Jest
|
||||
- Mocha
|
||||
|
||||
## Decision Outcome
|
||||
|
||||
Chosen Option: Mocha because it was significantly faster to run than Jest (1s vs 30s), and can use a variety of assertion styles unlike JUnit5.
|
||||
Chosen Option: Mocha because it was significantly faster to run than Jest (1s vs 30s), and can use a variety of assertion styles unlike JUnit5.
|
||||
|
||||
@@ -1,19 +1,19 @@
|
||||
# Use Stylelint for CSS linting framework
|
||||
|
||||
- Status: accept
|
||||
- Deciders: Arthur Lu, Marc Reta
|
||||
- Date: 11 / 14 / 22
|
||||
- Status: accept
|
||||
- Deciders: Arthur Lu, Marc Reta
|
||||
- Date: 11 / 14 / 22
|
||||
|
||||
## Decision Drivers
|
||||
|
||||
- Need linting to work with multiple style standards
|
||||
- Need linting to be fast and informative
|
||||
- Need linting to work with multiple style standards
|
||||
- Need linting to be fast and informative
|
||||
|
||||
## Considered Options
|
||||
|
||||
- Stylelint
|
||||
- Prettier
|
||||
- Stylelint
|
||||
- Prettier
|
||||
|
||||
## Decision Outcome
|
||||
|
||||
Chosen Option: Stylelint for its easy installation and unopinionated.
|
||||
Chosen Option: Stylelint for its easy installation and unopinionated.
|
||||
|
||||
@@ -1,19 +1,19 @@
|
||||
# Use HTMLhint for HTML linting framework
|
||||
|
||||
- Status: accept
|
||||
- Deciders: Arthur Lu, Marc Reta
|
||||
- Date: 11 / 14 / 22
|
||||
- Status: accept
|
||||
- Deciders: Arthur Lu, Marc Reta
|
||||
- Date: 11 / 14 / 22
|
||||
|
||||
## Decision Drivers
|
||||
|
||||
- Need linting to work with multiple style standards
|
||||
- Need linting to be fast and informative
|
||||
- Need linting to work with multiple style standards
|
||||
- Need linting to be fast and informative
|
||||
|
||||
## Considered Options
|
||||
|
||||
- HTMLhint
|
||||
- HTML-validate
|
||||
- HTMLhint
|
||||
- HTML-validate
|
||||
|
||||
## Decision Outcome
|
||||
|
||||
Chosen Option: HTMLhint for its low configuration complexity.
|
||||
Chosen Option: HTMLhint for its low configuration complexity.
|
||||
|
||||
@@ -1,19 +1,20 @@
|
||||
# Use puppeteer for JS unit testing framework
|
||||
|
||||
- Status: accept
|
||||
- Deciders: Arthur Lu, Marc Reta
|
||||
- Date: 11 / 16 / 22
|
||||
|
||||
## Decision Drivers
|
||||
|
||||
- Need end to end testing framework which runs headlessly and quickly
|
||||
- Framework should integrate well with Mocha, the existing unit testing framework
|
||||
- Framework should be easy to implement end to end tests with
|
||||
|
||||
## Considered Options
|
||||
- puppeteer
|
||||
- selenium-webdriver
|
||||
|
||||
## Decision Outcome
|
||||
|
||||
Chosen Option: Puppeteer for its ease of use with mocha.
|
||||
# Use puppeteer for JS unit testing framework
|
||||
|
||||
- Status: accept
|
||||
- Deciders: Arthur Lu, Marc Reta
|
||||
- Date: 11 / 16 / 22
|
||||
|
||||
## Decision Drivers
|
||||
|
||||
- Need end to end testing framework which runs headlessly and quickly
|
||||
- Framework should integrate well with Mocha, the existing unit testing framework
|
||||
- Framework should be easy to implement end to end tests with
|
||||
|
||||
## Considered Options
|
||||
|
||||
- puppeteer
|
||||
- selenium-webdriver
|
||||
|
||||
## Decision Outcome
|
||||
|
||||
Chosen Option: Puppeteer for its ease of use with mocha.
|
||||
|
||||
@@ -1,17 +1,18 @@
|
||||
# Use JSDoc for JS documentation
|
||||
|
||||
- Status: accept
|
||||
- Deciders: Arthur Lu, Marc Reta
|
||||
- Date: 11 / 29 / 22
|
||||
|
||||
## Decision Drivers
|
||||
|
||||
- Need simple way to publish documentation for code
|
||||
- Already documentating infile using JSDoc style
|
||||
|
||||
## Considered Options
|
||||
- JSDoc
|
||||
|
||||
## Decision Outcome
|
||||
|
||||
Chosen Option: JSDoc. Will run by generating docs in /source/docs/ before publishing /source/ so users can enter the URI /docs/ to see documentation.
|
||||
# Use JSDoc for JS documentation
|
||||
|
||||
- Status: accept
|
||||
- Deciders: Arthur Lu, Marc Reta
|
||||
- Date: 11 / 29 / 22
|
||||
|
||||
## Decision Drivers
|
||||
|
||||
- Need simple way to publish documentation for code
|
||||
- Already documentating infile using JSDoc style
|
||||
|
||||
## Considered Options
|
||||
|
||||
- JSDoc
|
||||
|
||||
## Decision Outcome
|
||||
|
||||
Chosen Option: JSDoc. Will run by generating docs in /source/docs/ before publishing /source/ so users can enter the URI /docs/ to see documentation.
|
||||
|
||||
@@ -1,17 +1,18 @@
|
||||
# Use Prettier for generic style enforcement
|
||||
|
||||
- Status: accept
|
||||
- Deciders: Arthur Lu, Marc Reta
|
||||
- Date: 11 / 29 / 22
|
||||
- Status: accept
|
||||
- Deciders: Arthur Lu, Marc Reta
|
||||
- Date: 11 / 29 / 22
|
||||
|
||||
## Decision Drivers
|
||||
|
||||
- Other linters (HTML, CSS, JS) are sometimes too permissive
|
||||
- Need to enforce style on other files like markdown, json
|
||||
- Other linters (HTML, CSS, JS) are sometimes too permissive
|
||||
- Need to enforce style on other files like markdown, json
|
||||
|
||||
## Considered Options
|
||||
- Prettier
|
||||
|
||||
- Prettier
|
||||
|
||||
## Decision Outcome
|
||||
|
||||
Chosen Option: Prettier
|
||||
Chosen Option: Prettier
|
||||
|
||||
@@ -1,16 +1,20 @@
|
||||
# Backend Storage Structure
|
||||
- Status: Accept
|
||||
- Deciders: Rhea Bhutada, Kara Hoagland, Gavyn Ezell, George Dubinin, Henry Feng
|
||||
- Date: 11/29/2022
|
||||
|
||||
- Status: Accept
|
||||
- Deciders: Rhea Bhutada, Kara Hoagland, Gavyn Ezell, George Dubinin, Henry Feng
|
||||
- Date: 11/29/2022
|
||||
|
||||
## Decision Drivers
|
||||
- Needed more efficient way of storing reviews that are created, for more efficient testing, updating, accessing, and deleting.
|
||||
|
||||
- Needed more efficient way of storing reviews that are created, for more efficient testing, updating, accessing, and deleting.
|
||||
|
||||
## Considered Options
|
||||
- localStorage
|
||||
|
||||
- localStorage
|
||||
|
||||
## Decision Outcome
|
||||
|
||||
Using local storage to maintain the "local first" requirement.
|
||||
Moved away from array of objects for storing reviews, reviews are stored individually as keys in localStorage, under the "review{id}" format. Each key
|
||||
Moved away from array of objects for storing reviews, reviews are stored individually as keys in localStorage, under the "review{id}" format. Each key
|
||||
corresponds to object containing review data. We also have an array stored in local storage, named "activeIDs" which keeps track of id numbers that are attached
|
||||
to created reviews.
|
||||
|
||||
@@ -1,15 +1,18 @@
|
||||
# Opening Specific Reviews
|
||||
- Status: Accept
|
||||
- Deciders: Rhea Bhutada, Kara Hoagland, Gavyn Ezell, George Dubinin, Henry Feng
|
||||
- Date: 11/29/2022
|
||||
|
||||
- Status: Accept
|
||||
- Deciders: Rhea Bhutada, Kara Hoagland, Gavyn Ezell, George Dubinin, Henry Feng
|
||||
- Date: 11/29/2022
|
||||
|
||||
## Decision Drivers
|
||||
- When opening up a review, browser needs to know what review ID to use for loading the review page data
|
||||
|
||||
- When opening up a review, browser needs to know what review ID to use for loading the review page data
|
||||
|
||||
## Considered Options
|
||||
- sessionStorage
|
||||
|
||||
- sessionStorage
|
||||
|
||||
## Decision Outcome
|
||||
|
||||
Review cards have event listeners that will add their associated review ID number to session storage so
|
||||
when the review loads, the browser will use the id stored to pull exact data corresponding to the review.
|
||||
|
||||
|
||||
@@ -1,13 +1,17 @@
|
||||
# Organizing Review Under Tags
|
||||
- Status: Accept
|
||||
- Deciders: Rhea Bhutada, Kara Hoagland, Gavyn Ezell, George Dubinin, Henry Feng
|
||||
- Date: 11/29/2022
|
||||
|
||||
- Status: Accept
|
||||
- Deciders: Rhea Bhutada, Kara Hoagland, Gavyn Ezell, George Dubinin, Henry Feng
|
||||
- Date: 11/29/2022
|
||||
|
||||
## Decision Drivers
|
||||
- Needed to keep track of reviews under certain given tags for filtering feature.
|
||||
|
||||
- Needed to keep track of reviews under certain given tags for filtering feature.
|
||||
|
||||
## Considered Options
|
||||
- localStorage
|
||||
|
||||
- localStorage
|
||||
|
||||
## Decision Outcome
|
||||
For every tag create a key under that tag name in localStorage. They will store an array of IDs that correspond to reviews that contain that tag.
|
||||
|
||||
For every tag create a key under that tag name in localStorage. They will store an array of IDs that correspond to reviews that contain that tag.
|
||||
|
||||
@@ -1,19 +1,20 @@
|
||||
# Use a network first cache second for service worker architecture
|
||||
# Use a network first cache second for service worker architecture
|
||||
|
||||
- Status: in consideration
|
||||
- Deciders: Arthur Lu, Kara Hoagland, Rhea Bhutada, George Dubinin
|
||||
- Date: 12 / 01 / 22
|
||||
- Status: in consideration
|
||||
- Deciders: Arthur Lu, Kara Hoagland, Rhea Bhutada, George Dubinin
|
||||
- Date: 12 / 01 / 22
|
||||
|
||||
## Decision Drivers
|
||||
|
||||
- Need to balance the need for user ease of use and local first priority
|
||||
- Users should expect to update their app easily when they have network, but may not be expected to know how to perform a hard refresh
|
||||
- Local first priority means we should avoid unnecessary network activity when possible
|
||||
- Need to balance the need for user ease of use and local first priority
|
||||
- Users should expect to update their app easily when they have network, but may not be expected to know how to perform a hard refresh
|
||||
- Local first priority means we should avoid unnecessary network activity when possible
|
||||
|
||||
## Considered Options
|
||||
- Network first cache second
|
||||
- Cache first network second
|
||||
|
||||
- Network first cache second
|
||||
- Cache first network second
|
||||
|
||||
## Decision Outcome
|
||||
|
||||
Chosen Option: Network first for automatic app updating.
|
||||
Chosen Option: Network first for automatic app updating.
|
||||
|
||||
@@ -1,2 +1,3 @@
|
||||
# Overarching Decisions
|
||||
_We will eventually capture these as an ADR in markdown Links to an external site.(/specs/adrs will contain an individual document per major decision. There will be some initial ones that have to do with general project plan and approach, but more may be added as the project goes on. The main point of this capture is to explain why choices are made. As brainstorming may have your team settle on choices quickly capturing them in a document may be better than just mental consensus)_
|
||||
# Overarching Decisions
|
||||
|
||||
_We will eventually capture these as an ADR in markdown Links to an external site.(/specs/adrs will contain an individual document per major decision. There will be some initial ones that have to do with general project plan and approach, but more may be added as the project goes on. The main point of this capture is to explain why choices are made. As brainstorming may have your team settle on choices quickly capturing them in a document may be better than just mental consensus)_
|
||||
|
||||
@@ -1,64 +1,75 @@
|
||||
# App Pitch - Food Journal
|
||||
|
||||
## Summary
|
||||
<p>
|
||||
Our pitch is an app that allows users to store information about their recent restaurant experiences, including the restaurant name, location, date, dish, picture of the food, price, comments, ratings, etc. This app will allow individuals to document their food habits and track past meals. The app will then provide suggestions based on the users preferences and habits.
|
||||
</p>
|
||||
|
||||
## Narrowing Down the Problem
|
||||
<p>
|
||||
People don’t have a place to reflect on their food adventures. Whether it’s trying a new cuisine or looking into new restaurants, it is useful for people to have a place to record their restaurant experiences. In our research, we found that there is no app designed for people to journal their food related experiences and we feel that this app will offer a new and exciting avenue for people to enjoy and reflect on their meals.
|
||||
</p>
|
||||
|
||||
## How is it CRUD?
|
||||
* Create: Users create reviews of specific foods at any restaurant
|
||||
* Read: Users read reviews that they’ve created
|
||||
* Update: Users update their reviews when their ideas change about the food
|
||||
* Delete: Users may delete their reviews
|
||||
|
||||
## Visual Representation
|
||||
- User Flow Diagram:
|
||||
|
||||
<img src="./diagram.png"></img>
|
||||
|
||||
- Home Page: Users sees all their reviews and can perform CRUD actions
|
||||
|
||||
<img src="./wireframes/home_page_wireframe.PNG"></img>
|
||||
|
||||
- Review Page: User can see an induvidual review that they created previously
|
||||
|
||||
<img src="./wireframes/read_review_wireframe.PNG"></img>
|
||||
|
||||
- Create New Entry Page: new page with a form is opened up
|
||||
|
||||
<img src="./wireframes/new_entry_wireframe.PNG"></img>
|
||||
|
||||
## User Personas
|
||||
### Persona 1: Tom
|
||||
Tom would often face the issue of not knowing where he should go for his next meal. As someone who is new to the town, Tom does not know the restaurants around his place by heart, let alone the details on each restaurant like the price range, cuisine, and specific dishes likes and dislikes.<br>Tom’s problem is one that can be solved by our app. Whenever he visits a restaurant, he can use our app to note down any relevant information from that visit. And when Tom would need help on deciding where to eat, he can refer to the notes on his food journal to help him make that decision.
|
||||
|
||||
### Persona 2: Ben
|
||||
Ben is trying to make sure that he watches what he eats. He doesn’t mind eating somewhere unhealthy once in a while, but he wants to make sure the majority of his purchasing decisions are healthy.<br>If Ben uses our app, he can place tags on the meals he eats depending on whether they’re healthy or unhealthy. Then, he can look back over the past weeks and months and make sure he hasn’t been eating at too many unhealthy places. If he’s ever looking for something to eat, he can filter by tags on the app to find only healthy places that he’s given high ratings to in the past. This way, he can stay consistent with his dieting goals.
|
||||
|
||||
### Persona 3: Claire
|
||||
Claire noticed that she’s spending more than she would like to on eating out and made a resolution to try to budget how much she’s spending on restaurants. Claire has a general idea of the restaurants in her area, but it’s difficult to keep track of the details of each location.<br>If Claire uses this app, she can note down the price of each food she tries when eating out and how she thought that the quality compared to the price with her budget in mind. She can narrow down foods that she finds worth the price. When craving a certain type of food, Claire can also look for cheaper options in the same category of cuisine based on her previous entries.
|
||||
|
||||
# Similar Apps and Competition
|
||||
* Social media allows users to technically post their own food reviews (food accounts, food review posts), but sites are not specialized for food reviews
|
||||
* Yelp known for specifically food, but still branches
|
||||
* Our app differs in scope (focus on food exclusively)
|
||||
* Our app offers food review-specific features like specialized templates and formats
|
||||
|
||||
# Statement of Purpose
|
||||
Ultimately, the purpose of this app is to allow users to keep a food diary. Having a place that allows individuals to journal their favorite meals, restaurants, cuisines, pictures, and more can be beneficial for people who are looking to know more about their eating habits and tendencies as well as try out new foods.
|
||||
|
||||
# Risks and Rabbit Holes
|
||||
* Technical Unkowns
|
||||
* How to implement CRUD related features?
|
||||
* Is there a limit to storage? How to store large amounts of data locally?
|
||||
* Unsolved Design Problems:
|
||||
* What features we want to prioritize?
|
||||
* How much data will be collecting?
|
||||
* How many fields should we have for each meal?
|
||||
* Misunderstood Interdependencies:
|
||||
* N/A
|
||||
# App Pitch - Food Journal
|
||||
|
||||
## Summary
|
||||
|
||||
<p>
|
||||
Our pitch is an app that allows users to store information about their recent restaurant experiences, including the restaurant name, location, date, dish, picture of the food, price, comments, ratings, etc. This app will allow individuals to document their food habits and track past meals. The app will then provide suggestions based on the users preferences and habits.
|
||||
</p>
|
||||
|
||||
## Narrowing Down the Problem
|
||||
|
||||
<p>
|
||||
People don’t have a place to reflect on their food adventures. Whether it’s trying a new cuisine or looking into new restaurants, it is useful for people to have a place to record their restaurant experiences. In our research, we found that there is no app designed for people to journal their food related experiences and we feel that this app will offer a new and exciting avenue for people to enjoy and reflect on their meals.
|
||||
</p>
|
||||
|
||||
## How is it CRUD?
|
||||
|
||||
- Create: Users create reviews of specific foods at any restaurant
|
||||
- Read: Users read reviews that they’ve created
|
||||
- Update: Users update their reviews when their ideas change about the food
|
||||
- Delete: Users may delete their reviews
|
||||
|
||||
## Visual Representation
|
||||
|
||||
- User Flow Diagram:
|
||||
|
||||
<img src="./diagram.png"></img>
|
||||
|
||||
- Home Page: Users sees all their reviews and can perform CRUD actions
|
||||
|
||||
<img src="./wireframes/home_page_wireframe.PNG"></img>
|
||||
|
||||
- Review Page: User can see an induvidual review that they created previously
|
||||
|
||||
<img src="./wireframes/read_review_wireframe.PNG"></img>
|
||||
|
||||
- Create New Entry Page: new page with a form is opened up
|
||||
|
||||
<img src="./wireframes/new_entry_wireframe.PNG"></img>
|
||||
|
||||
## User Personas
|
||||
|
||||
### Persona 1: Tom
|
||||
|
||||
Tom would often face the issue of not knowing where he should go for his next meal. As someone who is new to the town, Tom does not know the restaurants around his place by heart, let alone the details on each restaurant like the price range, cuisine, and specific dishes likes and dislikes.<br>Tom’s problem is one that can be solved by our app. Whenever he visits a restaurant, he can use our app to note down any relevant information from that visit. And when Tom would need help on deciding where to eat, he can refer to the notes on his food journal to help him make that decision.
|
||||
|
||||
### Persona 2: Ben
|
||||
|
||||
Ben is trying to make sure that he watches what he eats. He doesn’t mind eating somewhere unhealthy once in a while, but he wants to make sure the majority of his purchasing decisions are healthy.<br>If Ben uses our app, he can place tags on the meals he eats depending on whether they’re healthy or unhealthy. Then, he can look back over the past weeks and months and make sure he hasn’t been eating at too many unhealthy places. If he’s ever looking for something to eat, he can filter by tags on the app to find only healthy places that he’s given high ratings to in the past. This way, he can stay consistent with his dieting goals.
|
||||
|
||||
### Persona 3: Claire
|
||||
|
||||
Claire noticed that she’s spending more than she would like to on eating out and made a resolution to try to budget how much she’s spending on restaurants. Claire has a general idea of the restaurants in her area, but it’s difficult to keep track of the details of each location.<br>If Claire uses this app, she can note down the price of each food she tries when eating out and how she thought that the quality compared to the price with her budget in mind. She can narrow down foods that she finds worth the price. When craving a certain type of food, Claire can also look for cheaper options in the same category of cuisine based on her previous entries.
|
||||
|
||||
# Similar Apps and Competition
|
||||
|
||||
- Social media allows users to technically post their own food reviews (food accounts, food review posts), but sites are not specialized for food reviews
|
||||
- Yelp known for specifically food, but still branches
|
||||
- Our app differs in scope (focus on food exclusively)
|
||||
- Our app offers food review-specific features like specialized templates and formats
|
||||
|
||||
# Statement of Purpose
|
||||
|
||||
Ultimately, the purpose of this app is to allow users to keep a food diary. Having a place that allows individuals to journal their favorite meals, restaurants, cuisines, pictures, and more can be beneficial for people who are looking to know more about their eating habits and tendencies as well as try out new foods.
|
||||
|
||||
# Risks and Rabbit Holes
|
||||
|
||||
- Technical Unkowns
|
||||
- How to implement CRUD related features?
|
||||
- Is there a limit to storage? How to store large amounts of data locally?
|
||||
- Unsolved Design Problems:
|
||||
- What features we want to prioritize?
|
||||
- How much data will be collecting?
|
||||
- How many fields should we have for each meal?
|
||||
- Misunderstood Interdependencies:
|
||||
- N/A
|
||||
|
||||
Reference in New Issue
Block a user