CS 106 Winter 2016

Assignment 10: Hierarchical data

---

Question 1 Data McDataFace

The goal of this assignment is to provide an open-ended opportunity to experiment with JSON-based hierarchical data, possibly by accessing a live web-based API.

With that in mind, all I will give you is a set of minimum requirements for your sketch:

• Your sketch needs to decide what to draw based on the contents of a JSON Object (or a JSON array). It's fine if you want to put a static (i.e., unchanging) JSON file in the sketch's data/ folder and always use the contents of that file to drive the sketch. If you're feeling more bold, you can work with live data, by loading a fresh JSON object from the internet when the sketch starts. If you're feeling even more adventurous you can try to update the JSON periodically as the sketch is running, but make sure not to load a new JSON object too often! You'll be using a lot of bandwidth, and putting pressure on someone's server. Don't load live JSON objects unless you know what you're doing, and can control the frequency at which you refresh appropriately. If you want some help controlling the rate of re-loading, you can have a look at sample sketch I have created. It provides a helper class called JSONObjectCache that you are free to use.
• Your sketch should use both text and images. The text and images should be chosen based on the contents of the JSON file. "Images" comprise PImages, PShapes representing both 2D SVG and 3D OBJ designs, or custom art drawn piece-by-piece in Processing. In some cases the JSON will contain the text you want to show, and URLs for the images that go with that text. In other cases the connection will be less direct. For example, you might create a weather app that looks for keywords in the forecast (sun, rain, clouds) and displays a set of stock clipart for different weather conditions. (You can use additional words and images that don't depend on the JSON, as decoration around the "content" of the sketch.)
• Your sketch should change over time. The change might happen automatically, for example by displaying a new random tweet every thirty seconds from a JSON containing a list of tweets. Or it could change in response to user events (selecting an item to display, pressing the space bar to advance, etc).
• Your sketch should do something interesting. Obviously this is the hardest constraint to enforce rigorously, but just keep in mind that you're trying to make a tool that's useful, that provides access to real-world information. The more practical (app-like?) you can make your sketch, the better it will be. Note also that your sketch must not just be a clone of any of the Module 11 sample sketches, or the exercises in Lab 11. If you do want to use an API like Twitter, Tumblr, or the file of Jeopardy questions, make sure you do something new and different from the code provided to you.

One tricky question is how to get interesting JSON files or live feeds, and how to make sense of them. A few tips are offered below. Watch Piazza for other ideas over the next few days.

• Often, the JSON output from a website will be an unformatted mess and very hard to read. You may want to make use of a "JSON Formatter" or "JSON Pretty Printer" that can clean up your JSON for you. For example, paste some JSON into the top window of Vladimir Bodurov's JSON Formatter.
• The university publishes an API with access to a wide variety of on-campus information. See the "Endpoints" section of the page linked above for a list of all the information sources available at UW. In almost all cases you will need an API key to use UW JSON feeds. We have a key that's available for anyone in the course to use. The key will be posted on LEARN, since it's exclusively for the use of CS 106 students. In the many JSON URLs in the documentation for the UW API, just add "?key=KKKK" to the end of the URL, where KKKK is replaced by the complete API key.
• Many, many websites provide JSON APIs. Just do a web search on the name of your favourite site together with "API" or "JSON". The downside here is that most APIs require you to apply for a key (as with the UW API above), so that the site can track your overall usage. I leave it to you to decide whether to obtain a key for your favourite service.
• In some cases, APIs that produce data in non-JSON formats can be converted on the fly into JSON. For example, Google publishes a magic service that eats RSS and spits out JSON. If you know of a blog that has an RSS feed (for example, Boingboing has a feed at http://boingboing.net/feed), then you can slip that URL into Google's service like this: https://ajax.googleapis.com/ajax/services/feed/load?v=2.0&q=http://boingboing.net/feed.
• A natural service for which we'd like to have live data is Grand River Transit's bus information. GRT doesn't publish an API directly, choosing instead to bury it inside of web-based real-time map. But Nathaniel Woodthorpe, a first-year CS student, cleverly reverse-engineered a live API for GRT buses. It takes a Stop ID as a parameter and tells you the forthcoming arrivals at that stop. In theory you could combine the live API with the static data published by GRT in the GTFS format, a standard CSV-based format devised by Google to allow cities to publish their transit schedules in a Maps-friendly format.
• You might be able to find other possibilities by searching the web for "cool JSON", "cool web APIs", etc. That's how I found the list of Jeopardy questions in one of the sample sketches.
• If you know of an interesting service or API, feel free to share it with the class. If it looks interesting but isn't quite compatible with JSON or the tools provided in Processing, share it anyway—someone on the course staff may be able to provide a "band-aid" that will allow you to get legal JSON out of that site regardless.
• In some cases, documentation for JSON APIs will have lines that look like this:

  GET /path/to/the/service

  You can ignore the GET part and tack the rest of the text onto the main URL for the API, which should be obvious in the documentation. (Or just look for examples in the documentation.)
• If in doubt, feel free to ask for help. I'd love to have students try to create sketches based on APIs that interest them. In the worst case, choose a safe fallback like the UW API.

Call your sketch Data.

Submission

Remember to review the Code Style Guide and use Processing's built-in auto format tool. Then review the How To Submit document. At the top of all of your source files, be sure to include a comment with your name and student ID number. When you're ready, zip the Data sketch into an archive called A10.zip and upload that file to LEARN.