Capstone Midterm Progress Report (Naimark)

Changes From Proposal

Two big changes have been made regarding the technical specifications of my project. The first is that I have decided to use Python for the underlying game logic and control instead of Processing. I made this decision because I am more comfortable programming in Python, allowing me to prototype and develop more quickly. After doing some research, I was able to find Python libraries that support many of the same features of Processing that are important to my project, including serial communication and openCV.

The other main change I have made is moving away from using rfid to track player locations. After drafting out the board layout, I realized that I would need twelve rfid readers, one for every square. That did not seem feasible to execute. Instead, I will use a camera tracking solution. Leon suggested color tracking to me which sounds like an excellent solution, though I will still do some research into other possibilities.


Game Design

The structure of gameplay has been made totally concrete. This includes the unique abilities of each playable character, the type of actions players can perform on their turn, and how to win the game. After more user testing, I will make small numbers tweaks for balance such as the number of actions per turn or the probability of finding a certain item. However, the core rules and systems will remain the same. I have a few different drafts written of the “Official Rules” that show the progression of the gameplay as it has changed over time. I have also written a short backstory for each of the playable characters.

The premise of the game is that ghouls have been causing mysterious disappearances in Haven City. The players have talked to a priest and learned how to cleanse the city of the ghouls. They must find 3 holy items, and bring them to the heart of the ghoul’s nest in order to cleanse the evil once and for all.

The game takes place over 7 rounds, analogous to a week. At the beginning of each round, the narrator will state the day and then players will take their actions. The flow of gameplay is as follows. 1. Players confer with one another on where to move. 2. Movement occurs. 3. Players choose whether or not to use an investigate action on their current square. These steps are then repeated until players use up all of the movement actions for the round. Then the next day begins. If players don’t cleanse the ghouls within a week, they overrun the city, and the game is lost.

Each location on the board has exactly one thing in it. By investigating, players have a chance to discover what’s in the location. This can be either a holy item or a hint. The hints will help players deduce the location of the ghoul’s nest or a nearby holy item.

Technological Implementation

In Python, I have created a fully functional version of the game. This includes a digital representation of the board layout, a function that calculates the total number of moves it takes to move from one location to another, and verification of whether or not a player is actually able to reach that location. The information for the board layout is described in a JSON file that gives each location a name, a unique ID, a list of which locations it is directly connected to, and whether or not players need to climb in order to reach it. Python then interprets the data from the JSON to instantiate objects of the Location class. The movement calculation function is my implementation of Dijkstra’s algorithm. My Python code also applies the character’s unique abilities, and can now take into account when players are standing on the same square.

I have also decided to procedurally generate the content of each board location. Similarly to the act of shuffling a deck, this adds a bit of randomness to the game’s setup that improves the replayability, with the advantage of requiring less setup from the players. The location of the ghoul’s nest is different every time the game is played, as well as the different hints given when investigating. Some hidden rules are followed in generating the content, which ties into the gameplay. For example, a holy item will not appear in the same general location as the ghoul’s nest. Finally, I have begun to work on the serial communication between Python and Arduino. I have researched and installed the pySerial library, and I have successfully sent data over serial communication to the Arduino. I am currently fine tuning how Arduino interprets the data and how to send data back to Python.

Reactive User Interfaces Midterm Documentation: Commune Address Book WebApp


For my midterm, I created an address book app meant to be used as an internal communications tool for a company. Many large companies have several different departments, such as an HR department, Accounting department, etc. Companies with multiple products will also have separate interdisciplinary teams for each product. I designed my address book with the need to communicate with and across teams in mind.

Recontextualizing the assignment to fit my vision, I added the department that a contact works in to the information displayed on a contact card. I also changed address to be the location of the company’s branch offices. When sorting the list, in addition to first and last name, the user can also sort by department and branch location. The contact list can also be filtered by the department.

Additionally, my address book includes a list of teams to the right of the list of contacts. Using the list of teams allows the user to send a group message to everyone in the team. The user may also use the team list to find the contact card of a single member of the team.

Some use cases that I can imagine for my app include some of the following:

  • The leader of a team wants to message everyone about a meeting
  • A higher up needs to find the leader of a certain project
  • A team completes a prototype and wants to send it off to QA for testing
  • A programmer on one project heard that the programmer on another team implemented a similar function and wants to seek advice from them.

Component Overview

The app’s main component is the Contact component.  This component receives a first and last name, department, address, and image as props. Each Contact also features a message button. The callback function associated with this button causes the app to render the Messagebox component and takes the Contact’s name as an argument.

The Messagebox component consists of 3 input fields. The “To” and “Subject” areas are both normal text inputs, while the email body is a text area. The message recipient is fixed based on the contact that triggered OpenMessageBox function and cannot be changed. The Messagebox component has its own state with separate fields for the subject and the body. These values are set with an onChange function attached to the input fields. The Cancel and Send buttons both call the same onClick function, which resets the state of the subject and body back to an empty string. The onClick also calls the callback function that tells the parent App which button was clicked, and plays a CSS animation of a “message sent” notification if it was the Send button.

The Search component works similarly to previous input components that we have built in that it contains its own state as an intermediary to the value that gets rendered in the actual field. Upon updating, the Search component tells the app what’s inside of it, and sets the parent app’s Search state to that same value. The search is applied in the parent’s render function and searches first and last name. The search is not case sensitive. Originally, I also allowed for searching by department. However, this filtered out a lot fewer contacts when typing in the first few letters, making it more difficult to actually find the contact you want by searching. Additionally, that functionality overlapped with the Filter component, so I eventually decided that it was best to remove searching by department.

The final component is the Team component. This component is very similar to the Contact component and shares much of the same CSS. However, its props vary slightly. Rather than a first and last name, it only receives a single team name. The Team component also receives a list of the team members and their position titles. Like the Contact component, the Team component can also open a Messagebox, setting all of the team members as the recipients. Notably, each team member’s name can be clicked, which will isolate their contact card in the list of contacts on the left side.


  • CSS. CSS and general aesthetic design are two of my biggest weaknesses
  • Figuring out how to structure the messaging functionality. Although the Messagebox is its own component, in the beginning I was unsure what it should be a child of. Because the Contact component is the one that contains the button that triggers the Messagebox opening, I thought that it should belong to that component. However, there are several Contact components and I only wanted one Messagebox. After considering, “what’s a React way of doing things?”, I concluded that the main app should track whether the Messagebox should be open or closed in the state. When the Messagebox field in state determines that the Messagebox component should not render, it adds the “Off” class to the component. This class’ style is set to display: none. The callback function associated with the Message buttons, openMessageBox, removes this class.
  • Allowing for clicking a specific member of a team. Originally, I wanted the teamMembers prop to contain references to the actual Contact component of all of the members, but I had no idea how to do this with dynamic components. First, I tried to give every contact a unique id prop, pass the id as a props to the Team component in lieu of a name, and then somehow derive the correct information from the state’s contactList. This was insanely complicated, and I could not figure out how to make it work. I later realized that my goal was essentially just filtering, which my searching function already does, so I added another callback function that calls the same function that sets the search term in the parent app. In addition to showing only the clicked name in the list of Contacts, the name also appears in the Search bar. This has the added benefit of being able to return to the default state of the app by simply clearing the Search bar.


  • My friends Jamie and Kate for giving feedback on the color palette, side margins, and general layout.
  • Black Panther’s imdb page, which I downloaded all of the images from.

Capstone First User Test (Michael Naimark)

For my first user test, I had 3 players test the action/movement system of my game. I used a cardboard prototype of the board, and tasked the players with travelling to every square and attempting to activate it by flipping a coin. My two main goals were to determine how many rounds it takes to explore the board and to observe what strategies players would adapt with regards to each character’s special ability. First, I verbally explained the rules to the players, and then I observed them playing. The users all played the game with each other twice.

While explaining the rules, all of the players expressed some confusion. However, when they asked clarifying questions (example: “So on my turn, I can take x action?”), they typically had the right idea. One user suggested that it would be helpful to have cards that list everything that the player can do.

The most helpful thing that this playtest revealed is that the balance of character abilities is very off. During the first playthrough, the players decided to give almost all of the movement to one character, so I believe that their ability is too strong. The users also noted that to let the character whose ability is to climb inaccessible locations feel impactful, there needs to be more inaccessible locations on the board. During the second playthrough, I changed the rules from the first. The first time, two characters could not be on the same location on the board. The second time, players could be on the same location, and they could use each other’s special abilities when sharing the location. Although this rule was part of my original conception of the game, I got rid of it because of the difficulties involved in programming it. However, the players definitely had more fun with this rule in place, so my next step is to get that working in the code.

Both of my goals for the play test were met, so I would consider the session very successful. I learned that it takes 3-4 rounds for players to activate every square on the board. Players also communicated and worked together throughout the entire game, which is exactly what I wanted. However, all of my users knew each other beforehand and are friends, so I would like to see how the dynamics are different between people who may not know each other as well. Before my next user test, I want to incorporate all of the feedback that I got from this test. In addition to programming the rules to allow location/ability sharing, I will also work on the design of the board layout. I also want to conduct the next test with written rules instead of me dictating them.

Social Rhythms: Artgame Proposal

With my game project, I want to explore ideas of subculture and social belonging. Many subcultures feature a very distinct aesthetic style that separates them from the mainstream culture. For example, people who participate in goth subculture often dress in dark, Victorian influenced clothing contrasted with a style of pale makeup. Sometimes certain movie or literature genres are associated with a subculture. Oftentimes, music is also a defining attribute of a subculture, such as with the culture surrounding jazz or punk rock. In short, belonging to a subculture influences a person’s entire lifestyle, from the media they choose to consume to the way they express their self to the world.

When someone plays my game I want them to experience the sense of community and belonging that comes with immersing oneself in a subculture and befriending others who are passionate about the same interests. At the same time though, I want to show some of the tension that can arise when you center your core identity around a specific set of things but also like and participate in things that are outside of the subculture.

The existing game that I’m going to adapt is the 2D platformer. However, I’m going to change the example’s coin pickups and scoring system. Instead of coins, there will be sprites that correspond to items associated with a subculture such as pieces of clothing or music albums. In general, the game’s aesthetic will be closely tied into the aesthetic of subculture, and I will probably get most of the assets online and from Unity’s asset store. However, if there is enough time, I’d like to try creating my own with Adobe Illustrator.

The game’s scoring system will have two meters, reputation/popularity and credibility (labeled ‘poser’ in game). When picking up items associated with a subculture that the player chooses at the beginning, their popularity goes up and they make more friends within the subculture. These friends follow the player around as they navigate through the level, but don’t interfere with the gameplay. When picking up items from other subcultures, the player’s credibility goes down, and the ‘friends’ may muse about the player’s authenticity.

The idea for this game came from my experiences in middle and high school, where cliques were mostly formed around specific interests, and people would point to those interests as part of what makes them different and ‘better’ than anyone else. The implication was that if you liked things that those outside of your group were interested in, you were no longer cool. Although that was my thinking in the past, I’ve now realized that people have many rich and varied interests outside of their special interest. I want my game to reflect my feelings from both points in time. During the game, I want players to feel the dilemma of picking up things that they like versus things that they think they should like (and maybe do also like). However, at the end of the game, each of the friends that the player made from their community will come up and talk about a common interest that they share that is outside of their shared subculture.


Project Zip file:

Overall, I think that the end result of my project adhered to the majority of what I laid out in my proposal. In the end, the focus shifted away from specific subcultures and more towards the general concept of social groups. “Subculture”, as it manifests in my game, is mostly expressed through the type of media the player and their friends like to consume, though the usage of different background art based on which interests are picked in the beginning gestures towards how people can orient their whole lives around a subculture. Although I only created content for two different groups (as opposed to my original intent of 4) I feel that the content I do have is developed in a way that drives home my theme.

When watching people play my game, they exhibited the behavior I expected and wanted them to. At first, they would try to pick up everything in the level. However, once they realized that the friends who follow you around disapprove of items from the “out-group”, they started going out of their way to avoid those items, and only picked up the ones that increased their popularity. This perfectly mirrored the real life behavior that I wanted to model, how peer pressure influences people’s media consumption. This was really exciting to observe in playtests.

On the other hand, I feel like I could have done a better job of making the player aware of their own behavior. After the ending scene, players realize the message of the game, but I think there may be more ways to communicate that there’s nothing wrong with picking up the things you enjoy during the game. This is hinted at by the heart that appears above your head even if your friends disapprove. I wonder what could be less subtle than that, but still isn’t immediately obvious in the first minutes of gameplay. Nevertheless, the people who playtested my game seemed to really enjoy the ending and the message it imparted. For the most part, the criticism they gave was on the smoothness of the controls, like the player getting caught on the side of platforms.

The most challenging part of actually creating the game was probably the code for the friends that follow you around. To get them to follow the player, I use the lerp function, with the target being the player’s transform plus an offset. However, once more friends show up, they all kept bumping into each other constantly because they were all trying to be in the same place. To get past this, I had to make a list of all the friends in the player script. When a new friend spawns, they are added to the larger list, and their follow target is actually the previous friend in the list. After finishing all this logic, I realized that it only worked when moving to the right. Then I had to add in lots of conditionals to make it so that the friends properly move and follow you when the player turns around. Even after all of this, I also had to take into account following you on the Y axis. When the player jumps, it also makes the friends jump, but they often do not manage to get onto the same platform. In response, I wrote a function that puts the friends in the same Y position as the player if they cannot be seen. This still doesn’t quite work properly if the player is standing in a spot where the friends are constantly falling down. I have not figured out how to stop the rubberbanding that the friends do in this scenario.

On a more positive note, I discovered a couple of really cool tools within Unity while creating my game. The first is the ability to alter prefab settings from a C# script. Any prefab that you want to change by using a script should go in a folder called “Resources”. Then you can call the really awesome function Resources.Load() which will allow you to load the prefab as a game object. Any changes that you make to the prefab game object afterwards will apply to the entire prefab, not just that current scene. I used this function in the scene where the player chooses their interests in order to apply the correct tag, friend prefab instance, and audio to the player prefab.

To give some background for the other feature that I discovered, when I made a text-based Unity game in the past, all of the UI elements looked perfectly fine in the editor, but when I built and ran the game, all of the text was tiny. This happened again when I made Social Rhythms. Then, I noticed something I had never seen before while I was trying to debug. If you click on the canvas in the inspector, there is a component called Canvas Scaler (Script) with an option called UI scale mode. By default, this is set to Constant Pixel Size. However, it can be changed to Scale By Screen Size, which fixed my aforementioned problem. Discovering this feature felt absolutely revolutionary.


Midterm User Stories and Competitive Analysis

When I researched various examples of address book apps, I noticed that they fell into two broad categories based on the target audience. One group of apps focused on professional usage. These apps tend to list the contact’s occupation along with their contact information. One app, called FullContact also allows you to see when and what your last correspondence with the person was. FullContact and another app called CircleBack also allow you to add a contact from a photo of a business card. By default, these apps tend to sort contacts alphabetically by name and occasionally by most recently contacted.

The other general group of apps is more focused on personal connections. The iPhone address book is an example of this. Typical features of this app type include setting ‘favorite’ contacts, which are always at the top of the list regardless of filtering. The iPhone app also allows you to set a relationship to your contact such as “Father” or “Sister”. The app Ready Contacts also allows you to associate calendar events with contacts like birthdays and set shortcuts for emails, phone calls, and texts. These more personal apps tend to sort contacts by most recently contacted and most frequently contacted.

Many of the personal address book apps are very focused on visuals, with the contact’s picture taking up most of the space. However, in a review of three professional address book apps, which were mostly very clean and text based, the top rated one was boosted in rank because it featured a small photo of the contact to the left of their information. Therefore, I think that having photos in the address book is an absolute requirement no matter what type of app I pursue.

For my app, I want to do a professional app, but on a closer, more personal scale. My address book would be used by a company internally. The primary use case would be for communicating with members of your team. However, it is also important to be able to contact people like the big boss or HR personnel.

User Stories-

  • As a user, when I open the app, I see a list of contacts with their photo, first and last name, address, phone number, email, and department/position.
  • As a user, when I type a name into the search box, contacts that do not match my query disappear
  • As a user, when I click the filter button, a list of filters appears (A-Z, Z-A, Country, Department)
  • As a user, when I click a filter from the drop down menu, the list of contacts becomes sorted by my criteria
  • As a user, when I click the email button, a form appears where I can draft and send an email

Analysis of an Artgame: All Our Asias (Krom)

All Our Asias, which just came out on February 7th, is an artgame created as a solo project by designer Sean Han Tani. The game is about a well off Japanese American man named Yuito, whose father abandoned him and his mother when he was born. Although Yuito never knew the father, he reaches out to Yuito on his deathbed, expressing a desire to meet his son before he passes. By the time Yuito reaches the hospital, the father is still alive but unable to interact with anyone. The doctor then allows Yuito to enter his father’s “Memory World” and learn something of what the father’s life was like. The player is then given license to control Yuito’s navigation pod and explore the visualization of the father’s mind in search of memories.

A lot of what makes All Our Asias an artgame is the creator’s intent and framing. At the beginning of the game, the player meets a character called The Storyteller who explains his intentions for telling this story. Although this technically takes place within the game, it feels like it’s the voice of Sean Han Tani telling us his personal motivations for creating the game. This shifts the play context in a way, moving away from someone sitting in their room and blindly deciding to play a new game towards something more akin to a gallery experience where the viewer is asked to consider a central theme or question.

As hinted at by the title, All Our Asias’ stated goal is to explore notions of Asian American identities. In the intro sequence, The Storyteller points out that Asia has billions of people and hundreds of unique cultures, so is the commonality of being ‘Asian’ really significant enough to bring these people together?

The game’s contrasting art styles help to communicate how the designer feels about that question. While in the real world hospital, the game features a hand-drawn, but realistic, art style. The father’s memory world, on the other hand, is rendered in an extremely low-fi style, evocative of early Playstation graphics. It is both beautiful and abstract. Interestingly, when Yuito is speaking, his portrait is still shown in the hand-drawn style, despite the dreamy landscapes in the background. Furthermore, the memory world is encapsulated by a UI that represents the machine allowing Yuito access to his father’s mind. I believe that all of this is representative of the alienation felt between Yuito and his father. Some of that alienation is a result of the father not having been present in Yuito’s life, but there is also some tension between Yuito’s identity as a Japanese American and the father’s as an immigrant from Japan. The first area in the memory world is some sort of transit station in Japan. When you go to speak to people, everything they say is rendered in Japanese kanji; neither Yuito nor most players can understand what is being said. The effect is a sense of alienation and of being overwhelmed. The player is then forced to consider how something like language factors into identity.

In another memory, Yuito is walking down a highway. If you talk to other characters along the highway, they will make racist remarks about how ‘your people’ are going to kill someone with their bad driving. One women even goes so far as to use the racial slur ‘chink’ which Yuito responds to by exclaiming that he isn’t even Chinese. This is a moment where it is clear that yes, Asian Americans are bonded together by something, even if that something is being the target of racist attacks because of how they look. This scene, where a Japanese man is targeted with a slur against Chinese people by someone who thinks that all Asians look the same reminded me of the story of Vincent Chin. He was a Chinese American man who was beat to death as a hate crime due to anti-Japanese sentiment, an event that initiated the start of an Asian American sociopolitical movement.

In fact, in one of the final arcs, Yuito finds himself amongst one such movement. He meets a friend of his father’s, named General, who asks for a favor in exchange for giving Yuito information about his father. This favor is to pass legislation to help struggling restaurants owned by Asian immigrants. The gameplay that follows feels like what it would be like to be part of a grassroots movement. The player discusses with the Chinatown mayor to get ideas for policies that would help these restaurants, then goes to speak with some restaurant owners who would be affected by the policy to gain their support and get a feel for what their situation is really like. One restaurant owner who Yuito really connects with is a Korean woman, and Yuito later admits to General that he felt more compelled to help her because they are both Asian. General admonishes Yuito, saying that while it is good that their similar appearance helped inspire him, it is overall a ‘flimsy’ reason. Shouldn’t we help people in need regardless of what they look like, General questions. This is left for the player to ponder.

All together, I feel that everything I have discussed makes All Our Asias worthy of being called an Artgame. The creator’s intention to express a certain theme exists, and he uses methods such as the game’s art style and narrative, as well as references to historical and political events to communicate ideas about that theme.

Week 3 Button Component HW

I started out with mostly copying what we did in class on Wednesday, creating components for buttons and the display box. At this point, the only button prop was label. I added in the components to the render function in app.js and wrote the css for everything. Then I worked on adding the interactivity. My first step was to create the state in the constructor. Then I wrote the onclick function in app.js that changes the state to the clicked button’s label. After that, I had to go back into button.js and add in the onclick function as a property.

The hardest part was highlighting only the selected button. The way I solved it uses getElementsByClass function and a for loop and looks very similar to how it would be done in native javascript, so I’m not sure if it is a correct solution.

(Krom) Analysis of A Game: Dream Daddy

Dream Daddy: A Dad Dating Simulator (DDADDS) is a visual novel and dating simulator video game released in July 2017. In the game, the player is a single father to a girl about to graduate from high school. The family moves to a new neighborhood which is home to several other single dads. The objective of the game is to pursue a romance with one of the other dads while also being a supportive father to your child.

As a dating simulator, the game is a representation of the experience of dating. To that end, the main procedure of the game is to go on dates with your romantic interest. At some point during each day in the game, the player is given the option to choose which of the seven potential partners they would like to go on a date with. One important rule in DDADDS is that the player may go on up to three dates with any given dad. If the player goes on their third date with the same dad, that dad is locked in as their romantic interest for that playthrough. The game makes this discernable to the player in two ways. First of all, on the screen where the player chooses who to go on a date with, each character has three hearts next to their picture. The hearts begin grayed out, and after the player goes on a date with that character, the heart is then shown in red. Secondly, when a player selects the option to go on a third date, the game displays a prompt asking the player “Are you sure this is your Dream Daddy?” with the options “Sure” and “I can’t commit”. The player can then make an informed decision on whether or not to make that choice, without locking themselves into a specific love interest by accident without realizing. However, going on dates does not always feel meaningful because they are not well integrated. The player can go on up to two dates with every single romantic option, but who you date and how many times has little to no impact on your relationship with the other characters.

As a visual novel, the gameplay can feel a bit limited. For most of the game, the player is reading dialogue boxes and clicking the mouse or keyboard to progress the text. At some points, the player is given a choice of options to respond to the situation or dialogue with. Some of these choices affect the outcome of the game, but not all of the choices can be considered meaningful. For example, at the beginning of the game, your daughter is trying to wake you up and you can either play dead, mumble ‘5 more minutes’, or just get up. No matter which option you choose, the player character will eventually get out of bed. On the other hand, some choices do have a discernible impact. While on a date, if you say something that a date finds favorable, an animation with flowing hearts will play around them, but if you say something they really dislike, dark coal-like dots will spray out. At the end of each date, the player is shown a letter grade for how well the date went, integrating the choices made throughout the date into the final result. Although the game has programmed rules to calculate the grade based on the choices made, the exact weight of each choice is not known to the player. Exactly how poorly or how well the player must do to get a bad or happy ending with their chosen love interest is also unknown. In my playthrough, I received S, B, and A grades on my dates, so it seemed reasonable that I received the happy ending.

Although the gameplay of Dream Daddy isn’t always great at creating meaning, the game’s context is extremely important when evaluating it as a meaningful experience. The first aspect to consider is the cultural context in which the game was released. Recently, the issue of diverse representation in media has started being taken much more seriously, by both creators and consumers. DDADDS is impressive in the diversity that it showcases. Not only is there the obvious factor that all of the characters are gay or bi, but the characters also come from several different ethnicities and feature various body types. Additionally, because of the personal nature of representation, the profile of the player is also an important context. Seeing yourself represented within the game can be very meaningful. To further this, being able to customize your character in a way that reflects you enables the play to be more expressive.

Week 2 Assignment- Article Listing

For this assignment, I did my best to recreate the article listing in the NYT screenshot using React.js. I created separate components for the date, article title, preview text, author, and photograph. Additionally, the title, preview, and author are encapsulated in a container to form a column.

Response to As We May Think

Much of what Vannevar Bush writes in “As We May Think” can be seen in how the internet works today. His description of linking multiple articles together and creating a system of ‘trails’ is exactly how embedded hyperlinks work. Bush says that “wholly new forms of encyclopedias will appear” and unsurprisingly, the most commonly used and complex network of these links is Wikipedia. Such trails of information exist for all kinds of topics, from a cataloguing of the entire Star Wars universe to information about gardening. One difference between wikis today and the memex system Bush describes is that the memex is more personal; a single person creates and maintains it, and others are free to use and reference it. However, many wikis are huge collaborative projects, seen as a single definitive guide, with the public being able to freely edit them.

Unfortunately, not everything that Bush wrote has become prevalent in the modern internet. Most notably, the idea of being able to annotate webpages does exist but hasn’t really been developed far. Some browser extensions allow users to do this, but they are not commonly used, and there’s no standardization. In order to become widely adopted, the function would probably have to come prebuilt into the browser, though there likely isn’t enough demand for that.