Lab 2: Museum Extended Pass

Objectives

• Further exercise your JavaScript skills.
• Learn to make API calls and parse the results of those calls.
• Generate more dynamic user experiences.

Overview

This week, you’ll extend the implementation of your Harvard Museums webpage with additional functionality building off of different portions of the Museums API and relying on JavaScript’s local storage. You are welcome in this lab to build off of your own implementation of Lab 1, or you may use the staff’s functional (albeit perhaps not as aesthetically pleasing!) implementation as the basis for this lab. Whether you use the staff’s implementation or not, we do encourage you to look it over, as it’s been written to maximize use of JavaScript methods to manipulate the DOM. Again, as before, you’ll use Harvard Art Museums API.

Users will be able to visit your site, see a list of all galleries into which the Museums have organized their collections; search for galleries, objects, and artists; view the results in paginated form, limiting the number of results they see; mark objects as “favorites” and then see only those objects; and more.

Collaboration

Per the syllabus it is permissible to collaborate with one other classmate on this lab. If you do, both partners must still submit their own repositories, and both partners must turn in identical work. You should use the README.md file to note that you worked with a partner and state clearly who your partner was (name and GitHub username).

Getting Ready

Like Lab 1, we’ll be using GitHub Classroom to distribute projects and collect submissions. To begin Lab 2:

1. Click here to go to the GitHub Classroom page for starting the assignment.
2. Click the green “Accept this assignment” button. This will create a GitHub repository for your project.
3. Click on the link that follows “Your assignment has been created here”, which will direct you to the GitHub repository page for your project. It may take a few seconds for GitHub to finish creating your repository. You should then be able to clone on your machine the cs276/lab2-username repository (CS276 is the course identifier for this course at Yale, by the way, if curious where that organization name comes from!): always push your code to your cs276/lab2-username repository.
4. If you’d prefer to use your own implementation of Lab 1 as the basis for Lab 2, simply delete the distribution code, copy your implementation of Lab 1 into your Lab 2 directory, and commit and push that to your cs276/lab2-username repository. (Though this solution is not exactly elegant, it is necessary because of the GitHub Classroom wrinkle.)
5. Inside of the static/ directory you should see two subdirectories, css/ and js/, inside of which you should find one CSS and one JavaScript file, respectively, to get you started. You are free to (and, indeed, should) create additional .html files, and you may also create .js and .css files as needed, storing them in the appropriate directories.

Getting Started

Requirements

Alright, it’s time to extend your Museums application! Here are the requirements:

• Search Page: Create, in a separate file called search.html, a page containing (at a minimum) a form whereby users can type text into a text field and view search results regarding objects that match the typed information. It is up to you whether the results view updates dynamically on each keystroke or only when the user clicks the “Search” or “Submit” button (or its equivalent). In addition to the text box, the form should contain a radio button selection option for which type of search the user is performing; and the search should only be run comparing those particular fields. At minimum, your supported search types must include:
  • title
  • culture
  • person
  • keyword
  • And at least one other search parameter of your choosing, based on the documentation.
• Favorites: When accessing an individual object, a button should be presented to users to “Mark as Favorite” (or, if already marked as a favorite of theirs, “Unmark as Favorite”). When marking an object as a favorite object, that should be stored somehow, maintaining a list of all of the marked objects in localStorage. Users should also then, when visiting a new page that you create called favorites.html, see all of the objects marked as favorites, and only those objects marked as favorites.
  • Beware… localStorage can only be used to store strings! As such, you’ll need to be creative when storing the list of objects the user has marked as favorites. Allow us to recommend you take a look at the JSON.parse() and JSON.stringify() methods as a way to start thinking about solving this challenge, though others are certainly possible.
• Navigation Bar: At the top of (or on the left side of) all HTML pages you should create a navigation bar that will allow users to easily move between (at a minimum), index.html which by default should be the gallery list; search.html which contains your searching functionality; and favorites.html where users can view only those items marked as favorites.
• Limit Results: On all pages showing lists or tables (including favorites.html and search.html) should be a drop-down menu where users can limit the number of results they see, rather than seeing all results as was done in Lab 1. At a minimum, options for limiting to 5, 10, and 20 results should be present. Whenever a user changes the value of this dropdown, the page should update to reflect a view with n entries visible, where n is the number the user selected (unless the number of matching list/table items is less than n.)
• Pagination: If the number of list/table items exceeds the limit specified by the user (see the previous feature), results should be paginated in some way. Acceptable options include either:
  • “Next Page” and “Previous Page” buttons that, when clicked, replace the current view with the next n or previous n results
  • Numbered pages such that, when clicked, that set of n results appears in the current view. For example, if n is 10 and page 7 is clicked, results 61 through 70 are shown in the view.
  • A “Show More” button that merely appends an additional n results, as we did in the books3 example from Monday’s lecture, does not count for this requirement.
• Error Handling: Endeavor to seek out situations where things don’t exactly go according to plan (through no fault of your own!), and make a more user-friendly experience. You should at least handle two specific errors, and any others you might encounter along the way:
  • Create and display a small “NO IMAGE” thumbnail or image and plug that in when the API does not return an associated image (e.g., if that property is null).
  • If a gallery contains no objects, instead of displaying a blank page, display a “Gallery contains no objects.” message.
• Your Own Feature: Implement at least one other functional extension to the site, comparable in scope to the features delineated above. If unsure of whether it is substantial enough, write to the course staff for guidance.

FAQs

Reload periodically to see answers to common FAQs! Be sure to use the lab2 tag on Piazza when posting questions. Please be sure not to post questions containing more than a small snippet of code publicly.

Hints

• Be sure to look at some of the metadata parameters associated with each API! Some potentially useful ones here include q, size, page, and potentially sort.
• Don’t forget that you can test your API calls in the browser by pasting the link directly into your browser address bar. By default, the Firefox browser will render the results as relatively readable JSON; similarly can extensions be added to Chrome that will accomplish the same goal.
• You are allowed to use features of JavaScript and/or jQuery not discussed in class to help you in implementing some of these specifications, though it is not required or expected. jQuery, in particular, has modules for some of these features! For instance, interested in using data tables?

How to Submit

Step 1 of 2

1. Make sure all of your latest changes have been committed and pushed to your cs276/lab2-username repository.
2. If you collaborated with a partner on this lab, be sure you’ve clearly identified who your partner is in the README.md text file, and be sure each of you individually submits, where your submissions should (other than the README.md file) be identical.

Step 2 of 2

Fill out this form.

Congratulations! You’ve completed Lab 2.