Is the website live? No. (Although we’re about to be on the other side of our domain troubles.) Is the dataset complete? Almost! Still, this is the week of finishing touches. It has to be. For me, as outreach and UX design lead, it meant writing website copy and preparing as much as I can for when we do launch the website early next week. 

Our plan was always to re-engage our community via email sends. Some research helped me decide that I wanted that to happen via Mailchimp, which would allow us to add a sign-up field to our website footer. The other half of our outreach strategy consisted of spreading our links — to the website, the GitHub, the Are.na board and (why not, I thought) the email sign-up — like spores in the wind with the goal of planting them in as many high-touch places as possible. If all a link can do is sit there and wait to be clicked, I want that to happen somewhere where it might be found by someone who would appreciate where it leads to. But these seeds needed a package, something to keep them bundled together as we passed around our feeds. I impulsively started throwing together a Linktree page during the last hour of our second-to-last class and I was pleased to learn that it also had a handy QR code generator that offered all the customization features I was looking for all semester. 

All of this was being built with Thursday’s showcase, and nothing else, in mind. I’d been obsessing over how to make the path from presentation to email sign up as frictionless and inviting as possible:The Linktree is the business card; the website is the storefront; everything else is a billboard. The end of our presentation will display our QR code, in our signature colors with our logo integrated. When audience members scan, it will lead them to our Linktree, a visually seamless extension of our website, that will prompt them to subscribe to our newsletter and include links to the website, the dataset repository, and the Are.na board. A welcome email will automatically plant more links into their inbox, for future reference or immediate use.

Turns out, a couple hundred dollars is the difference between future reference and immediate use. Free trials of premium features across both platforms – Mailchimp and Linktree – made sure we had everything we needed to keep it all together through Thursday. To consider the possibility of spending down the budget, meant picturing ourselves a year from now, when the annual subscriptions would lapse and we’d have to decide if the money was well-spent. Would we be telling people to subscribe to our newsletter in May 2027? Would the renewal notice remind us of something we abandoned a year ago?

As I tested the Linktree and added my teammates as admins to the Mailchimp, I documented the passwords, API keys, hex codes used, emoji Unicodes. I downloaded the png’s of the customized QR code in our two main colors into our shared Google Drive and wondered how any of us would be able to navigate it should we find ourselves in need of some link or bit of information at any time in the near or distant future. What kind of posterity was I planning for, and why did this question suddenly eclipse the urgency of being ready for Thursday’s showcase?

As I waited for the group chat to respond to these questions, I found myself adding a “Post-Mortem One-Sheet” to our shared document. One place that would make it easy to ensure that are links remain unbroken, that anything with the words “AI Hallucinations Project” has the right colors and the right emojis, that the QR code always works and that if anything needs to be refreshed or retrieved, it wouldn’t take any digging. All this busywork that required me to refer back to some decisions made over the last few weeks — retrieve links, approved color HEX codes, recall the typefaces we used for the website, etc., — made me realize the bulk of the project was already behind us. Despite the final-mile-stress, most of the work had indeed already been done and, at the very least, we have one long Google doc full of links, blog posts, and meeting notes to prove it. And I can’t think of a better time to start making plans for how to preserve it all.

Preparing the final loose ends for the project has felt pretty smooth overall. I’m genuinely happy that we were able to find a good workflow and communication system early on, one that kept things moving at a feasible pace without anyone feeling too overwhelmed. A lot of that came down to the team being thoughtful and reliable.

I spent some time this week preparing for the presentation. Truly’s slides and notes gave me a solid structure to work from, and from there I edited and put together speaking notes to get ready for my first practice run with the other project managers. I appreciate Professor Maney for setting that session up! The feedback I got from everyone was incredibly helpful,  even just getting inspiration from the other’s presentation structures. I left feeling a lot more confident about how to reframe my presentation.

Trying to fit nearly two semesters’ worth of work into a five-minute presentation is a challenge. But I’m hoping my refinements can highlight A Pretty Terrifying Project’s main goal. This was a project that started from my own personal research interests, and over time I was lucky enough to share and build it alongside teammates who genuinely shared those very same interests in some form of another. I wanted that aspect to come through in my presentation. At its core, this project is about visibility, not just for the horror video game genre, but for the broader shift toward taking video games seriously as a form of media worthy of the same critical analysis we apply to film and literature. Our data puzzle and close reads serve as that start to further exploration. That’s the heart of it, and that’s one of the key ideas I want the audience to takeaway.

It is that time in the semester, at least for me, when everything is happening at once. To top it all off, my task this week for this project was a pretty critical one. A number of data visualizations, links, and images were completely broken on our website, and obviously that needed to be addressed as soon as possible. At first I was worried this would take hours of agonizing debugging like some of the issues I ran into with this project earlier. But this time, thankfully, I managed to figure out what was wrong relatively quickly. Not too long after our last class meeting, I patched up the most egregious bugs, leaving a few small fixes for later in the week, and then promptly switched gears to work for my other class, and the presentation I’m giving at CCNY this Friday. Again, everything is happening at once.

But eventually I did have to get back to the tasks I’d put off: fixing some broken links, ensuring images work, and uploading our close readings to the site with some (now-functional) gameplay pictures to accompany them. The first two parts of this weren’t too complicated – these fixes were similar to the fixes I’d made earlier in the week. But actually posting the close readings – and in particular, choosing and displaying the images to accompany them from the image folder Michael put together – posed some new challenges.

First of all – alt text. Because the images included with the close readings would be add to the analysis by showing a visual example, it’s important that those pictures get their point across, even to people who can’t see. Enter alt text, a description you can add to a website’s code that a screen reader can read when it comes across the image. Like many accessibility features, alt text also has bonus effects that benefit users beyond those who it’s meant to help. In particular, when an image fails to load – due to a slow internet connection or an old outdated website for example – browsers will often display the alt text, as can be seen in the example below. The indented text with the broken image icon to its left is alt text for an image that wasn’t able to load.

An example of alt text. This image itself also has alt text.

Actually writing this text isn’t as easy as it might seem. It shouldn’t be too wordy, or it will break the flow of the actual text. But if it’s too short and vague, it won’t help anyone understand the image. It’s an exercise in being concise, but also creative. How do you get the particular mood of an image across with only words? As obvious as something may seem when you look at it, describing it both accurately and empathetically isn’t easy. For example, in the description above, I could say the tendril “wrapped” rather than “snaked” around the creature’s arm. But “snaked” has a certain eerie connotation that “wrapped” doesn’t really capture. It implies an intentional twist of one living (or formerly living) being around another, an impression the image itself also gives off. It might seem a little pedantic, but knowing that this is the only way some people may be able to perceive the image makes it worthwhile to try describing it as evocatively as possible.

Alt text is all about ensuring people can access any image they want to access. But what about when people want to not access something? For example: arachnophobia is a common fear, and for some people, just the sight of a spider can be extremely anxiety provoking. This is already a known issue in gaming – some games are beginning to include toggles you can use to turn off spider enemies or display them as something else. And even when game devs themselves don’t take this into account, players do, creating modifications for games that make them arachnophobia-safe. For example, see this Skyrim mod which has some fun with the concept, replacing all spiders with… Spider-Man.

What does this have to do with the project? Well, in my Bloodborne close reading, I dedicate a full paragraph to Rom. Rom is a massive spider. Surrounded by smaller spiders. A large part of my analysis is based on how her boss fight in the game functions, the fear that being overwhelmed by many small creatures seeking to harm you can induce. A visual aid goes a long way in showing exactly what I mean. However- my writing may be about fear but I’d rather it not actually make anyone panic. So how can I include the image to support my textual argument while also shielding people who really don’t want to see a spider, let alone eight of them?  The code to solve this problem is surprisingly easy, actually. HTML has two elements called <details> and <summary>. Used together, these allow you to make a summary line that, only when clicked on, shows the full content inside the details block. I was genuinely expecting it to be harder, but I found the solution quickly and implemented it on my first try. It kind of made me wonder- if it’s so easy, why don’t I see this used very often? Online news sites, for example, could put particularly disturbing or gory images in these type of blocks, giving users the choice to see them or not to see them. I suspect the reason this isn’t done lies more in the thinking than the doing. First off, it doesn’t occur to people. It probably wouldn’t have occurred to me to hide the spider image if I didn’t know multiple people with arachnophobia. And second… there is something in our culture that idealizes and encourages “sucking it up”. For this reason, to some people, accommodating others feels unfair- because if they need to “suck it up” why should anyone else have anything that makes their life easier?

But I hope to encourage people to look at things in a different way. If something only costs you a few seconds of your time to throw in another HTML block, but it has the chance to help someone feel a little less anxious, then why not do it? Even if it takes more time and effort than that, isn’t it worth it? Instead of being bitter that others might have it easier than me, I want to give them the support I maybe didn’t have, knowing full well that if I set that example, it might inspire someone else, and someone else. And maybe, down the line one of those people will do something that supports me in a way I never thought was possible.

The way I see it being inclusive of blindness, mitigating arachnophobia, and numerous other small adjustments that aren’t always obvious, all fall under the umbrella of accessibility. And trying to find those small adjustments is a worthy task, an act of kindness, a way to make the world at least a little less hostile.

In preparation for a trip out of town for pre-move business, I spent last week tearing down and rebuilding the slides I’m intending to present at next week’s GCDI Showcase. The kicker is that because I am out of town this week, Natalia is stepping in to present the dress rehearsal tomorrow. Meanwhile, I am turning my attention to the final report and my personal reflection.

For now, we’ve got everything in place on the site, we’ve taken feedback and improved things, and while there’s still more small tidying up to do for consistency across entries, we’re ready for prime time. It has been incredibly gratifying to see the Voces del Lunfardo project develop from conception to some state of done. I hope we have achieved something of a shared vision and that the site serves its target audience well!

Since this is my final post of the class, and probably for this DH program, let me also reflect a bit on my experience so far.

When I started this Digital Humanities program, I had a sense that I wanted to better contextualize the work I’m already doing professionally by working in adjacent spaces, namely the humanities. I have long maintained a broad interest in literature, history, languages, and art, and I have developed interests in archives, libraries, pedagogy, information architectures, and other means of knowledge production, preservation, and transmission. Except for libraries, specifically digital libraries, and information architectures, I am less confident about my depth of knowledge in any of these domains. I saw this program, via in-degree and free electives, as a means of deepening my experience with some or all of these other domains with an eye toward finding my own unique question to ask and explore through an eventual capstone.

Over two semesters, I have gotten a mere taste, and I lament both that I am probably going to have to find another program, and that I hadn’t pursued more humanities scholarship prior to this point. While I don’t feel closer to having a question of my own, I am nevertheless grateful to have taken part, even briefly, in exploring everyone else’s questions. I hope I get the chance to work with any or all of you again in the future, whether I’m able to continue this program or not.

The past week was trying. Apart from dealing with serious allergy flare-ups, I can attest to spending longer time to engineer my prompts – than originally anticipated – before running them across 3 LLMs. The Hallucinations methodology requires each teammate to investigate and create prompts making historical inquiries of details that are attributable to a particular document. In practice, I assumed that the task would be able as simple as finding a letter, advertisement, document, or other source that gives a fact which could easily become the basis of a prompt.  

My assumptions were not entirely wrong, although I realized that I had not accounted for the challenge of arriving at a desired/usable source. More specifically, I had to face the prolonged task of reading and skimming through long manuscripts as well as letters between state officials that were merely conversations. I successfully completed my 15 prompts, though I changed 2 of them – not drastically in the sense that I did not deviate from the original source cited. Next, the algorithms ran the prompts across 3 LLMs – Claude, Gemini, and ChatGPT – until 45 different responses were generated. Attaining my prompt responses evoked a brief feeling of relief, knowing that a significant task was completed… However, not entirely.  

The next objective is to solidify our data by factchecking. I originally had the impression that this task would be accomplished by reading through the responses, identifying the hallucinations next, then describing them, while historically researching what has details about Puerto Rico’s past according to our prompts. Again, like the assumption explained earlier, I am certain this impression of the fact-checking job is not entirely wrong. On the other hand, meeting with GC Digital Fellows Eunah Cho and Lisa Rhody left me with highly provoking thoughts regarding the how in terms of factchecking. One of the points staying with me, Rhody mentioned that AI language models asking questions about clarity, and probably indicating when it does not have a definitive answer for an historical inquiry, is better than giving something wrong in confidence. Moreover, it is better for an autonomous language to be honest about areas of struggle/where it is lacking since it is trying to maintain a sense of trustworthiness as a functioning history-learning source. There is more nuance to these perspectives of course, however, I pondered how these perspectives can be leveraged for the task. I was especially confused on how to segway a history-studying background for fact-checking AI prompt responses. Eunah Cho and Lisa Rhody collectively provided a few questions for the Hallucinations group, one of which asks us to figure out a range of error. In other words, when does error arrive at the point of committing harm in belief, understanding, historical and socio-cultural consciousness, etc.? I wish to start the task of factchecking as soon as possible knowing that I will be out-of-state, but most importantly, I enter it with a clarified idea of how to confirm areas of accuracy and error, regardless of whether an Artificially Intelligent LLM provided desired responses. Hopefully, the Visualization Data Lab will provide me with an additional perspective, especially since I plan to discuss with my teammates how to proceed with the factchecking objective. 

The process of making a project often comes in fits and starts. Little pieces are created one by one, and in the beginning, it’s hard to see the cohesive whole they’ll all fit into.

One of the really fun moments of any creative activity is watching those pieces come together, and finally starting to see the bigger picture come into focus. That’s the stage we seem to be at now, which is exciting. Of course, that doesn’t mean we can just put our feet up and relax. Tying everything together is what separates a collection of interesting ideas from an actual project. No matter how good each piece is, if we can’t grab our audience’s attention, bring them along on some kind of journey, then there isn’t much point in our work. After all, the point of this project is for others to make use of it.

To that end, we’re finalizing the look of our website, and the text that goes on it. I gave some comments on my group-mates’ close readings, and after Naila’s adjustments to the website, I’m excited to give the site another pass to fix the bugs and smooth some rough edges. The website isn’t completely how I pictured it would be at first, but I do really like what we’ve come up with. Initially, we were just going to have charts and text stacked in a long vertical scroll. But now, some elements are also placed side by side. I think this makes scrolling more interesting – you get to see the layout switch up over time – and it also lets the user of the website view two elements together instead of needing to scroll between them. I think having that flexibility is important – even this late in the process, sometimes you need to make decisions that depart from things you decided earlier.

I’m also excited to continue revising the text during our next class and beyond. Bringing our three different writing styles together is another example of making pieces into a whole. It’s not about picking one person’s style to go with. Instead, it’s about making sure each individual’s voice is still heard, but also having a collective voice for the project so our audience doesn’t have to jump around between totally different kinds of writing too much.

Overall, things are moving in the right direction. And even with all these considerations to keep in mind as we begin the end of this process, I’m confident we’ll make something really cool!

On my suggestion, no, insistence, my team had a skill-share meeting where Sasha kindly walked the team through the technicals – the tools we needed to install on our computers and how we would use them to run our queries and store and share the results earlier this semester. My primary interest in this project was based on how it gave me the chance to work closely with a small dataset, nurturing it from its inception. I was also looking forward to a slow, critical encounter with LLMs. I was really eager to spend time with these tools and their outputs so that I can deepen my criticisms. 

But I did not make it to that skill-share on the day it was scheduled. We have a standing meeting on Fridays in order to keep up with our production schedule, that is where I do and share my share of the work on outreach and web design, and where we troubleshoot and make decisions as a group. Most of the time outside of class that I have spent on the project, has been dedicated to doing my part to support Sasha with web design and Chris with research and making sure the workflows I own – design, outreach, etc. — are well-tended to. I have to admit I’ve only been mildly successful in carving out extra time to dedicate to learning about the tools and methods we’re using to actually prompt the LLMs and document their responses. The few times I’d successfully done so was when I stole company time from my day job to spend a bit more time with the AI Hallucinations Project.

But I feel like I made up for it when we met at the library. While Chris was finalizing his prompts, Sasha kindly and generously walked me through the tools we would use: VSCode, Python, Homebrew, and the various APIs for each of the LLM’s we’d test. I realized she could’ve done all of the querying and documenting herself in a fraction of the time it took her to walk me through it all. But it was genuinely enjoyable to troubleshoot together. It also fulfilled the purpose of the project, and I suppose this class too. Being able to contribute to this part of the process ensured this experience didn’t feel like three contractors throwing their work into a Google Doc and onto a website. Now I can say I tested these LLMs myself, watched them slowly respond to my prompts one by one. And they tested me, I already know I will have to revise some prompts and run them again. The project would exist, and likely succeed, without my intervening in this part of the process. But I would’ve learned way less from it all if I hadn’t.

Changing the very nature of time… what horrifying entity could have this power? Why, CUNY of course! Thanks to the archaic time power of our strange institution, this week no longer has a Tuesday, and instead has two Thursdays! This has the effect that after a long break with no class, we have three classes over the course of eight days. Talk about hitting the ground running.

My main task in this chaotic collection of class time was to put together a presentation walking the class through my group’s Pretty Terrifying Project and then present it on Tuesday. …Did I say Tuesday? I mean “Thursday”, obviously.  This is fully my own fault – I volunteered to present, because honestly, I like giving presentations. Having a bunch of people watch you talk about something in a structured way feels a lot easier to me than talking to strangers one on one. Conversations can go any strange direction – a presentation has its core flow. Even if things stray, you always have that flow to return to.

So how did this presentation go? There’s definitely room for improvement, but this wasn’t meant to be perfect, and thanks to you all, Team Pretty Terrifying has plenty of feedback to work with to improve it further. That’s why I think it’s really important that we had a chance to do a first pass like this. It’s a great way to get accustomed to this particular format of presentation and work out all the mistakes now so when the big day comes, the presentation is clean and ready. That being said, I did kind of jump into presenting this week and I absolutely want to keep the door open if anyone else from my group wants to take the lead for the final presentation. I do think any other presenter can learn from my experience and step in if they’d like.

The main thing the feedback has got me thinking about is the structure of our project’s story and how to position it in time while presenting. While our process involved a lot of thinking before actually resulting in any website or data visualization, people clearly wanted to see the website and visualizations earlier on in the presentation. So just like CUNY, maybe we can mess with time a bit. As our professor suggested, it might be worth showing what we did first and then backtracking to how we got there. And there are some other options too – maybe we show the simple bar chart first thing and discuss the early process alongside it – still telling the project’s story mostly in order, but weaving the visualizations in as visual aids rather than as indicators of what work was done when. Another thing to consider is what presentation structure facilitates addressing everything we want to address while still staying within the time limit. So many options, so much to present on, and so little time, both to finish up what we need for this project, and to actually present. But we know what we’re doing, and we now have a firmer idea of our approach thanks to this practice round. As much as we’re getting into crunch time, it’s also exciting, knowing how close we’re getting to the final presentation.

See you all on Thursday! Weird… it feels like we just had a Thursday.

Title translation: Lunfardo Activity: Do you know how to use …?

As we round the home stretch for the semester, I wanted to spend a little bit of time on something that I mentioned but hadn’t yet had a chance to detail, which is the quiz module we have in Voces del Lunfardo. Early in our discussions, Natalia and I were thinking about the interactive components we wanted to include in the project. Given the project’s strong pedagogical focus, we felt that tools to try out the words would be appropriate, and quizzes are a typical way of achieving this goal. We wanted to include some kind of quiz or interactive activity on each term’s page to reinforce learning.

So I set about looking for extensions that would match.

When we were still looking at Omeka, it became clear pretty quickly that there were no existing modules that supported a quiz-like affordance. That was one of the reasons we ultimately chose DokuWiki. The extensions ecosystem for DokuWiki is such that we suffered from the exact opposite problem: for almost anything you can think of, there are several options floating around, each with slightly different operations. An additional problem also arises, though, in that these little extensions vary in terms of their maintenance and compatibility with recent versions of DokuWiki. That can mean they don’t work at all, or it can mean there’s something off about them.

We chose and tested a couple different quiz modules, most of which were geared toward use as flash cards. That’s often an appropriate affordance for language learning, so the extensions seemed promising. The one that worked best, however, had some strange default behaviors that we couldn’t configure away, and styling work would have been required. I scratched my head for a bit about it but ultimately decided to just make a plugin myself. How hard could it be, right?

The main problem here is that my PHP skills are dated. DokuWiki is written in PHP, HTML, CSS, and JavaScript; its plugins are as well. I can read all of these, and I have worked with plenty of PHP before, but I also thought this was an interesting use case to farm out to a LLM. It is, after all, a very well scoped and defined problem, one that I could have spent a few hours or so tinkering around with, and I am well positioned to evaluate the outcome. And if it didn’t work, I could just chuck it in the bin with all the other experimental code I’ve ever produced.

NB: “AI” is not the first thing I generally reach for (never for writing like this, never for summarizing what I can read, and never to make art), but I have found the need to evaluate its code capabilities so I understand its strengths and many, many weaknesses. I have thoughts. In any case, you can consider this my disclosure that for this one purpose, I did use a LLM for assistance.

If you yourself have some experience with using LLMs to generate code, I probably will not surprise you in saying that it worked. Mostly. Even in the best-defined and scoped prompts, there is plenty of room for misalignment and misinterpretation, so it took a few tries to get everything I thought I needed, and I hand-tweaked the 5-10% it didn’t quite get. I have read through all the code in the plugin, and I compared the structure and code with that of existing quiz plugins for good measure. Presently it’s in a GitHub repository but has not been submitted to the DokuWiki community yet; this is under consideration. I set up the repository, including a GPL license, to be shared pending my own review of the DokuWiki’s code provenance policies, if any. Oh, and I suppose I would need to rename it as well to avoid confusion with any existing products or trademarks.

The inclusion of a custom-developed module does raise some interesting questions aside from any ethical considerations of where the code came from. A main concern is that this wasn’t fully accounted for in the data management plan. The code is in GitHub now, and there’s no reason at the moment to suspect anything would happen to it, but it is now an artifact of this project and should be brought under the plan all the same. GitHub is not a repository in an archival sense, but it is nevertheless a convenient place to host a piece of open source software, especially if one wants to both maintain and distribute it. I’m including this concern here for the sake of thoroughness, but the question remains open.

Thankfully, there should be little left to develop or configure. Now on to the other work, entering and revising terms.