A web app where foodies and home cooks can recreate restaurant dishes at home by searching for inspiration on restaurant menus and finding recipes by dish name
MIT License
1
stars
2
forks
source link
Overseeing navigation and click listener functionality throughout the application #25
USER STORY: As a user, I want the freedom to navigate back to the search pages from the results pages, to navigate to the favourites list from p 1 and p 3/4 and to navigate back home to the landing page from the favourites page. When I click any button I want it to accomplish what it looks like it's there to do.
ACCEPTANCE CRITERIA:
-- It is done when I have gone through the code for the whole project ensuring that all navigational buttons and clickable/sortable functionality is working as intended. (The back button on p 3/4 may be particularly tricky since "back" is a different location depending on if the user is on p. 3 or p. 4. When clicked on p. 3 it should link to the landing page. When clicked on the fourth screen it should show again the populated accordion and p. 3 text. The accordion should only be cleared at, the start of the function which renders new content to it), not as soon as the page is switched. Those working on other issues will probably put the click listeners on the buttons they in their sections of the code, but some may get missed out this way. I don't know if anyone is responsible for the nav button at the top of pp. 2 and 3/4.
-- It is done when some thought has been given to whether the click interactions require a validation or error message to be sent to the user (eg. "Your recipe has been saved to favourites"). The client has requested that NO use be made of the browser's built in alert feature, so other options would be modals or tool tips (see JQueryUI's tooltip widget and Bootstrap's modal component).
-- It is done when index.html performs its role as an entry point for the entire application. Index.html may not end up being much used, but it is important to have it there or else the README will be what gets deployed.
-- it is done when the js has a function init to control what the application should be set up like on page load.
For reference: A description of the overall program flow:
User enters an ingredient (eg. halibut) or dish name (eg. fish tacos) in the form input from the landing page (search.html) and hits “search.” From the landing page they also have the option of clicking on the “See favourites” button to be taken directly to the last page of the application. (Click listener and Document.window.replace favourites.html)
A click listener is attached to the search button. The event handler function captures the form input and uses it to construct two query urls, one for OpenMenu API (by menu item) and one for Spoonacular API (complex search endpoint, requires menu item). Fetch requests are sent. Data received back is structured into three different data objects for render ability
— First works with the OpenMenu data and structures it for rendering to the list group on menu.html (the second page of the application)
— Second works with the Spoonacular data and structures it for rendering to the accordion on results.html (the third page of the application) — the list of recipe details
— Third works with the Spoonacular data and structures it for rendering to the results.html page as a recipe card.
The results.html page can do double-duty as the recipe card display page. (Ie. when the user clicks “get” on a recipe from the list displayed in the accordion), the accordion is hidden and the recipe card replaces it. New text is pushed to the h1, byline and p.
In terms of the UX, when the user hits “search” from the landing page (search.html), the window.document.location is switched to menu.html. On the menu.html page they see the results of their search for restaurant menu items that use their ingredients or feature their dish. This may inspire them to refine or change their search terms. They can also click the hearts within the restaurant-menu-items-listings to save to local storage and display on the last page.
IMPORTANT: In looking at the data the APIs give back I noticed that when a search is for a very specific dish name eg. “Halibut with citrus and ginger” Spoonacular often gives no results back. The most effective searches that yield the most results seem to be those that use one or two ingredient keyword terms eg. “Halibut,” or “halibut and ginger.” The reason we will offer the user the opportunity to refine their search after looking at the restaurant menus is to make sense of why we have included the restaurant menus at all (purported for “inspiration”). But we will also appear to have a pretty lame application if the user is encouraged to enter a complicated search term and 90% of the time they get no results back. SO…we are going to offer the user the opportunity to refine their search on p. 2, but we already have in hand the data response from their original less complicated search on p. 1. IF no results are received for their second search we push the original ones to the accordion, and a message in the byline that says “sorry, we couldn’t find an exact match. Try these recipes instead.” If we do get a match for their more refined search (eg) one result, we can still fill up the remaining spaces in the accordion with the results from the more general search.
When a click is heard on the search button from menu.html, the page location is changed to results.html. the input is captured, request url constructed and fetch request made again to Spoonacular API. IF there are results (many times there won’t be if the user has entered to complex a search string), construct the data object and get the rendering function to push it to the results page. We can push an icon that will distinguish this result as the closest match. The logic here should also push the results for the first more general search to the other spaces in the accordion. ELSE IF no result, just push the first set of results and a message to the byline saying “no exact match, but you might enjoy these…”.
On the third page (results.html) which is going to serve both as the holder of the recipe results list (the accordion) and the recipe card, the user can click on a “get” button within the recipe’s detailed description. On click the old elements are cleared out and the new ones h2 “Get Cookin’!”p: “Here’s the recipe you requested. If you like it, don’t forget to add it as a favourite.” This page also has a subtle nav button at the top left which will take the user back to the search page (search.html) (link needs to be added), and a “See Favourites” button at the top right which will need to have a link added to favourites.html. Click listeners are needed on all the get buttons, and on the hearts to save in local storage.
When the recipe card appears the formatted data for the recipe will be pushed to it. A heart will also need to be added to the recipe cards with a click listen for capturing these items into the recipes array in local storage. On click of the “See favourites” button (from either the home page or the results page). The user is taken to the fourth page of the application (or fifth page if you count the two iterations of results.html as two), favourites.html.
The last page (Favourites) has two columns, a carousel at the top of the left one, with a list of restaurant menu item underneath, an h1, byline, p and 2 buttons at the top of the right one (home and clear all). This content needs to be dynamically generated when retrieved from local storage and updated whenever a new favourite is added. Each list item should have a button for removing the list item (or maybe a cross could be included in the dynamic generation according to some bootstrap source code), and the JQuery UI sortable utility would be a nice addition so the user can arrange their favourite recipes (eg. Soups at the top, then main dishes, then desserts). A link to search.html should be attached to the “home” button and a click listener should be attached to the “clear all” button, which clears all items out of local storage.
USER STORY: As a user, I want the freedom to navigate back to the search pages from the results pages, to navigate to the favourites list from p 1 and p 3/4 and to navigate back home to the landing page from the favourites page. When I click any button I want it to accomplish what it looks like it's there to do.
ACCEPTANCE CRITERIA: -- It is done when I have gone through the code for the whole project ensuring that all navigational buttons and clickable/sortable functionality is working as intended. (The back button on p 3/4 may be particularly tricky since "back" is a different location depending on if the user is on p. 3 or p. 4. When clicked on p. 3 it should link to the landing page. When clicked on the fourth screen it should show again the populated accordion and p. 3 text. The accordion should only be cleared at, the start of the function which renders new content to it), not as soon as the page is switched. Those working on other issues will probably put the click listeners on the buttons they in their sections of the code, but some may get missed out this way. I don't know if anyone is responsible for the nav button at the top of pp. 2 and 3/4. -- It is done when some thought has been given to whether the click interactions require a validation or error message to be sent to the user (eg. "Your recipe has been saved to favourites"). The client has requested that NO use be made of the browser's built in alert feature, so other options would be modals or tool tips (see JQueryUI's tooltip widget and Bootstrap's modal component). -- It is done when index.html performs its role as an entry point for the entire application. Index.html may not end up being much used, but it is important to have it there or else the README will be what gets deployed. -- it is done when the js has a function init to control what the application should be set up like on page load.
For reference: A description of the overall program flow:
User enters an ingredient (eg. halibut) or dish name (eg. fish tacos) in the form input from the landing page (search.html) and hits “search.” From the landing page they also have the option of clicking on the “See favourites” button to be taken directly to the last page of the application. (Click listener and Document.window.replace favourites.html)
A click listener is attached to the search button. The event handler function captures the form input and uses it to construct two query urls, one for OpenMenu API (by menu item) and one for Spoonacular API (complex search endpoint, requires menu item). Fetch requests are sent. Data received back is structured into three different data objects for render ability — First works with the OpenMenu data and structures it for rendering to the list group on menu.html (the second page of the application) — Second works with the Spoonacular data and structures it for rendering to the accordion on results.html (the third page of the application) — the list of recipe details — Third works with the Spoonacular data and structures it for rendering to the results.html page as a recipe card.
The results.html page can do double-duty as the recipe card display page. (Ie. when the user clicks “get” on a recipe from the list displayed in the accordion), the accordion is hidden and the recipe card replaces it. New text is pushed to the h1, byline and p.
In terms of the UX, when the user hits “search” from the landing page (search.html), the window.document.location is switched to menu.html. On the menu.html page they see the results of their search for restaurant menu items that use their ingredients or feature their dish. This may inspire them to refine or change their search terms. They can also click the hearts within the restaurant-menu-items-listings to save to local storage and display on the last page.
IMPORTANT: In looking at the data the APIs give back I noticed that when a search is for a very specific dish name eg. “Halibut with citrus and ginger” Spoonacular often gives no results back. The most effective searches that yield the most results seem to be those that use one or two ingredient keyword terms eg. “Halibut,” or “halibut and ginger.” The reason we will offer the user the opportunity to refine their search after looking at the restaurant menus is to make sense of why we have included the restaurant menus at all (purported for “inspiration”). But we will also appear to have a pretty lame application if the user is encouraged to enter a complicated search term and 90% of the time they get no results back. SO…we are going to offer the user the opportunity to refine their search on p. 2, but we already have in hand the data response from their original less complicated search on p. 1. IF no results are received for their second search we push the original ones to the accordion, and a message in the byline that says “sorry, we couldn’t find an exact match. Try these recipes instead.” If we do get a match for their more refined search (eg) one result, we can still fill up the remaining spaces in the accordion with the results from the more general search.
When a click is heard on the search button from menu.html, the page location is changed to results.html. the input is captured, request url constructed and fetch request made again to Spoonacular API. IF there are results (many times there won’t be if the user has entered to complex a search string), construct the data object and get the rendering function to push it to the results page. We can push an icon that will distinguish this result as the closest match. The logic here should also push the results for the first more general search to the other spaces in the accordion. ELSE IF no result, just push the first set of results and a message to the byline saying “no exact match, but you might enjoy these…”.
On the third page (results.html) which is going to serve both as the holder of the recipe results list (the accordion) and the recipe card, the user can click on a “get” button within the recipe’s detailed description. On click the old elements are cleared out and the new ones h2 “Get Cookin’!”p: “Here’s the recipe you requested. If you like it, don’t forget to add it as a favourite.” This page also has a subtle nav button at the top left which will take the user back to the search page (search.html) (link needs to be added), and a “See Favourites” button at the top right which will need to have a link added to favourites.html. Click listeners are needed on all the get buttons, and on the hearts to save in local storage.
When the recipe card appears the formatted data for the recipe will be pushed to it. A heart will also need to be added to the recipe cards with a click listen for capturing these items into the recipes array in local storage. On click of the “See favourites” button (from either the home page or the results page). The user is taken to the fourth page of the application (or fifth page if you count the two iterations of results.html as two), favourites.html.
The last page (Favourites) has two columns, a carousel at the top of the left one, with a list of restaurant menu item underneath, an h1, byline, p and 2 buttons at the top of the right one (home and clear all). This content needs to be dynamically generated when retrieved from local storage and updated whenever a new favourite is added. Each list item should have a button for removing the list item (or maybe a cross could be included in the dynamic generation according to some bootstrap source code), and the JQuery UI sortable utility would be a nice addition so the user can arrange their favourite recipes (eg. Soups at the top, then main dishes, then desserts). A link to search.html should be attached to the “home” button and a click listener should be attached to the “clear all” button, which clears all items out of local storage.