Week Nº 24

Session Recordings

Eric’s Feedback

Michael’s Feedback

Eric’s Chrome Extension Demo

Eric’s JSON in HTML Demo

“AI,” for the last time 🤞

Welcome back! We’ve thought about our discussion from last class, and have two proposed approaches for acceptable LLM use moving forward:

~~Option Nº 1~~

~~“Zero-tolerance”~~

~~Based on the widespread, unconsidered, and profligate use in our last project⁠—our first instinct here is “none.”~~
~~Students would attest to their understanding of this, and agree to not use these tools for the remainder of the semester.~~
~~Any indication that LLM⁠s were used would be considered academic dishonesty, which would be reported (and result in a failing grade).~~

OR:

Option Nº 2

“Aides to our understanding”

LLM⁠s can only be used in “ask” mode, and then only via their own web/app “conversation” interfaces.
This means any/all “agent” use is be forbidden⁠—including IDE/CLI and other integrations (such as Claude Code or GitHub Copilot).
You are still expected to write your code⁠—you are not just copying/pasting the LLM output and commenting on it.
In the attribution for each LLM use, you must include a link to the actual, corresponding “conversation” with your questions.
Your questions there should clearly demonstrate the tool is being used to aid your understanding, not as a shortcut.

Think: these are questions you would ask your instructors.
If you cannot furnish a link to your “conversation” and questions, you cannot use the tool nor its output.
Students will attest to their understanding of this, and agree to use the tools only in this prescribed manner.
Any other uses/edge-cases require prior instructor approval.
Finally, any indication that LLM⁠s are being used outside of these rules will be considered academic dishonesty, which will be reported (and result in a failing grade).

The LLM is there to help answer your questions⁠—not write your code / do your work.

Project Check-Ins

We’ll be in our same groups from last class again, today:

Group Nº 1

Ali
Zarah
Sooim
Evgenii
Sophia
Mia
Riya
Lucy
Kinza
Trenton

Group Nº 2

Michael
Soko
Chareese
Amanda
Katie
Melody
Maika
Kimaya
Noor
Cason

Today’s structure

You’ll each see one of us, today⁠—just a few minutes each.
Have your filled-in roadmaps up to take us through.
We’ll open each others’ FigJams to go through together⁠—feedback for one is feedback for all!
Then tell us where you are at! Brief background on how your project has evolved and take us through your roadmap.
We want to make sure you are “unblocked” on your project: do you know what you are doing overall, and then for next week?
And think about what you want to get most from us⁠—is it conceptual or technical feedback? Where to start in code?

Some Overall Notes

This is not, primarily, a content project⁠—if you are burning your time here, we want you to refocus on the function!
Likewise, for assets (separate of content)⁠—you might think of an illustration or icon as an asset. This also not primarily an asset project, but leave some time (towards the end) for these.
Shift your mindset to code! Focusing on the core functionality of it⁠—don’t overindex on how it looks, right now. Maybe don’t write any styles this week (nor any Figma)!
Model any data that you will need⁠—starting with local data (“hardcoded,” below) before moving to an API! Akin to how we started statically for Project 4.
Don’t check any API keys/tokens into your repos! They shouldn’t be public . If you have an API that needs these, talk to us.
As you get into the technical aspects of your MVP, ruthlessly trim your scope! All things equal, a thoroughly working project is worth more than any particular taste/design.

A Couple Examples

We have a couple example/demo repos that can help with some functional (and conceptual) aspects of your projects.

Working With Data

This is similar to what we did with Are.na⁠—but now working with a JSON file within your project. You could use this as a model for an “API” of your own data/content:

local-json

Remember JSON (JavaScript Object Notation)?
- Before we asked Are.na for data/content, but you can also include it yourself “locally”
- You can write/edit your own .json files by hand, though the syntax is pretty easy to mess up!
- Instead you could start your data from Google Sheets, and use an extension to export⁠—or download a .csv and convert it
- There is also a better add-on, but New School IT doesn’t want us to have nice things⁠—use a personal account to try this out!
Just like with our Are.na projects, we can generate DOM from this data!
- IRL, you’d probably have some kind of templating framework or library⁠—but you can use vanilla JS for repetitive DOM
- We’ll again use a forEach loop to go through our array of data
- We can use the same template literals/strings, in our JS file
- Using if/else conditional logic to apply a class
- This still uses the fetch API to get the data⁠—but now from our local .json file!

Keeping Track of State

And an example of saving state. This is a little more advanced, but it shows some ways you might retain a visitor’s preferences/selections within your project (within what our free GitHub hosting allows):

forms-params-storage

Briefly, static vs. dynamic websites (in a build/hosting context)
- We have been writing static sites⁠—meaning that only you can change your pages, in code
- GitHub Pages (our hosting) does not allow server-side languages (PHP, Ruby, Go, Next.JS, Node, etc.) nor databases (My⁠SQL, Postgres, etc.)
- These are how most sites are made dynamic⁠—constructing pages, storing information, responding to visitor requests, allowing sign-in
- But we can approximate/suggest some dynamic behavior with JS!
Then onto <form>, <input>, <select>, and <buttton> elements

Comment out the form-state.js to start!
- <form> / <input> / <select> / <button> are semantic indicators of in-page interactivity
- The type= attribute is used to show different types of controls, made by the browser⁠—here with user-agent styles
Comment in/out the reset.css !
- The required attribute makes them… required!
- <label> elements are connected to these with matching for=, id=, name= attributes
- You can (and should) style them from these defaults!
Onto search (aka: query strings) and URL params (for parameters)
- By default, forms add their query string to the URL (in JS, called the location) on the submit event
- This is a way for your request to the server to be more specific⁠—what did the visitor input on this page?
- In a URL the query follows the trailing ? , each parameter is name=value , appended with an & :
```
						https://example.com/?param=something&another-param=else

			
	
```
- We can use these to track our page’s state⁠—what the visitor has done⁠—via the changes in the URL
- Using URL⁠s also makes these shareable⁠—you could bookmark/text message/⁠QR⁠-code to different states!
Comment form-state.js back in and go through!
- preventDefault stops the form from submitting (which would refresh the page)
- We’ll instead use the combined FormData to construct our own parameter string
- Then we’ll update the current URL on the input event (meaning any change to the form)
- The visitor’s changes and URL are then in sync!
Finally web storage, to keep our state!
- This API persists data across reloads/sessions⁠—but it is still limited to a single device/browser
- Cookies (cross domain, visible to server) vs. sessionStorage (this session) vs. localStorage (this browser)⁠—are all just ways to keep track of things
- These are visible/editable in a DevTools panel: Application → Storage → Local Storage

For Next Week

As they coalesce, we want a new set of “fresh eyes” on your projects⁠—so we’d like you to each weigh in on a classmate’s plan, from the other group.

Find the planning doc for your peer with the same number in the other group, up above.

Go through their overview, features, and roadmap. Does it make sense to you? Does it seem feasible? What is missing? Put yourself in their shoes. Add comments in their FigJam with your feedback!

We’ll be checking for these, as we do!
We’ll likely have absolutely breezed through our demos today, so glance through each of them and think about how they might inform your own project:
- local-json
  A.k.a. working with data/content.
- forms-params-storage
  A.k.a. keeping track of state.
You’ll be continuing on to the next milestone of your project, identifying and beginning to implement the primary features of your concept:

Project Nº 5: Core Functionality
Keep us updated with your links and progress:

Submission Form