I made a logo. I was not expecting to make one, and I didn’t think we needed one. But I was putting together the first batch of public-facing materials (a Google Form to gather emails, a QR code for Sasha to include in her presentation) and I caught myself wanting for a little glyph or icon that could add levity to all the text. This is usually when I look through the emoji library and do some selects of color-coordinated emojis and add them to the “brand book” along with colors, typefaces, etc. I was putting together for Sasha’s presentation, and would eventually become the DNA of our website and other visual assets.  But I couldn’t find any that worked. In other contexts, I would find or make new emojis and add them to the library I’m working with, and this made me wonder if I couldn’t customize one to match our color scheme and, boom logo! We’re going with an adapted, or perhaps “darker” version of the sparkle emoji that so many commercial AI projects use to align themselves with magic and instant satisfaction. So I ended up with a logo, I don’t know how I’ll use it but I’m glad we have it.

I can’t say I am fully satisfied with the work I’ve contributed to my project so far. Bills have to get paid and work got in the way of everything this month and my coursework has definitely suffered. I missed Sasha’s walk through of AI prompting and API usage, which I had asked for because my priority in joining this project was getting close to the datasets and developing my technical proficiencies. I won’t beat myself up over it, but during the upcoming break, I plan on making up for lost time: Sasha was kind enough to record her workshop and I will sit with it quietly and start trying my hand at prompting these models. This will be my first contact with LLMs and I plan on savoring it and really learning from it. In short, I hope to immerse myself in the world of the AI Hallucinations Project so that I can actually prioritize my intellectual curiosity and let go of my fixation on producing and delivering rushed contributions. Time, unfortunately, is the only thing keeping me from getting the most out of this project.

During the upcoming Spring Break, honestly, I am going to catch up on all the work I haven’t done for this project.

Though it will probably sound silly, I debated with myself heavily whether to write down a prompt engineering guideline that strongly encourages use of the 5 Ws and 1 H for questions. It is generally understood that learning about history involves asking questions that begin with those terms. In addition, the Black Knowledge Erasure Dataset was already built, primarily using such questions. Making that guideline didn’t make sense at first because of my perception that it’s already the expectation, and that it would do little to serve bigger objectives.  

After reviewing the BKED multiple times, as well as the prompt engineering phases and methodologies followed by Sasha last semester, this initial dilemma pushed me to figure out a rationale for the 5 Ws/1 H. I entered the task with the intention of creating a sense of simplicity, or rather, setting up my teammates to sufficiently conduct their own research without any complications in understanding how it would be done. From the perspective of an undergraduate history major, one of the most important objectives as Research Lead is building a data-gathering guide that prevents members from unintentionally slipping into the realm of historian. In other words, I don’t want my groupmates to think that they’re required to learn about a figure then form connections to a broader trend within Puerto Rican societies, to the degree the details of individual research must be reflected in the prompts.  

Paying attention to these intentions, I decided to concentrate on what shouldn’t be done while researching. Therefore, I made a written section titled ‘Avoid,’ which advises against grammatical inconsistencies – the name of a historical subject remains the same if used in another prompt. That is just one pointer since the next one tackles broad, vague questions. In history, this is the type of question that has multiple possible answers because a distinct subject was not mentioned. For example, “how was their life, what happened in it?” Many correct answers are possible because the questions did not reference any particular detail regarding a point in their lives, who was involved, hobbies, interests, and any other detail considered personal to said individual. An ideal question for the Puerto Rican hallucinations dataset, in this respect, is asking, “When did they make the decision to [insert whatever], especially after [relevant detail].” In addition, I put down a recommendation, stating that members could prepare historical questions by inserting an important detail which would force each of the LLMs to consider that fact when answering a prompt.  

As of today, the prompt guidelines have been shared, but I have yet to discuss with my team. Nonetheless, at least for now, I feel that the pointers written down already provides a sense of how our prompts may look, especially since they encourage prompts that can be effectively engaged with by the three AI models in this project.

This week I got to dust off some graphic design skills. I’ve been drawing since I could hold a pencil in my hand, and I’ve had some luck applying that skill to digital work here and there. I know we aren’t at the logo design phase yet, but I wanted to get a head start on rationalizing some of the design elements before we did get there. Or maybe I just wanted an excuse to make some art!

Strictly speaking, Voces del Lunfardo is the content itself, but as we all know, the way a website looks communicates something about it as well. Thanks to Natalia’s guidance, the visual stylings I’ve chosen are inspired by filete porteño, an art form that originated in and around Buenos Aires. It is included in UNESCO’s lists of intangible cultural heritage. UNESCO describes it as “a traditional painting technique used for ornamental design that combines brilliant colours with specific lettering styles”.

I started my search for anything usable by just searching the web for images. That gave me a good starting point for the kinds of letters, shapes, and colors used in filete porteño. I quickly realized that if I wanted to make something myself, the best approach would be to find something freely licensable and available as vector graphics. I ended up on freepik.com, where I found this, available as a scalable vector graphics file:

From there I fired up Inkscape, where I could recolor, select, and ungroup all the components. Vector graphics are preferred here because they can be resized without losing quality, and recoloring them is as simple as choosing from the palette. Or in my case, finding and applying the colors of the flag of Argentina.

I cut apart the image from freepik.com and reconfigured pieces before applying a simple filter. The resulting header image on the site isn’t what you’d call brilliantly colored, but I’m happy so far with the multi-tone blue that pulls from the Argentinian flag. Is it the final design? Who knows? And we still have the logo to do.

The remaining aspect was to find a font that likewise evokes filete porteño. I stumbled on a Google Font in the form of Milonga. I originally intended it just for the site title text, but I thought it added something when used as header text as well (HTML h1, h2, and h3 tags). So I dropped it into the site and updated the CSS to use it.

Milonga (the font) is named after an Argentine dance of the same name, which is related to tango. It seemed a fitting choice.

I will use these same elements when we start on our logo design.

Our project seems to be moving in a distinct direction – examining which themes tend to occur together in horror video games as our primary data focus, and then using Barbara Creed’s framework to dive deeper into a few games – which ones to be decided – for close readings.

The website is also becoming more distinct – I’ve started adding first drafts of the data visualizations to it, and each chart now fades in as you scroll down, which makes things look a little cooler. There is surprisingly more than you’d expect to making things fade in and out of existence. I went down a little bit of a rabbit hole involving scroll driven animations, only to discover they aren’t actually supported on a lot of browsers. Including Firefox, which was especially amusing because I got the documentation on that from… Mozilla, the developers of Firefox.

Web design is confusing! And also full of random standards that not every browser supports. Making a functional, minimal-computing-style website that prioritizes access over bells and whistles means trying to use the most widely accepted standards to reduce any obstacles to someone viewing the site as it’s intended to be viewed. So I found another way to produce the effect I wanted. The code itself for it may be more complicated, but the final product is closer to the standards of more browsers, and thus better supported.

I’m looking forward to beginning to work on the close readings, because like making webpages viewable by various browsers, we want our ideas to be understandable by various people. The text we write to scaffold and expand upon the visualizations will be the heart of that human connection. It’s our chance to speak directly to our audience, to give them a reason to care by making our work relatable to them. It’s our chance to let our own interests and personalities shine through, letting our audience see why we care, and understand the project better themselves through that. Web design has standards, and so too does writing, but the topics we explore, the things we describe? There’s no limit, really, to what direction we can go with it and who we can reach.

It’s scary, but the good kind of scary. Like realizing how small and fragile you are compared to the whole wide universe… and then realizing that just means there’s a ton out there for you to explore.

Apologies. This took longer to compose than I intended.

Recently while evaluating the top system choices for the Voces del Lunfardo project, I was reminded how a set of surface assumptions about system selection might be proven false once those assumptions are tested. The main test of those assumptions is the affordances of the system in question.

Early on in the project, we assumed Omeka would be our system. It is a powerful exhibition-focused content management system with an active community and numerous features, plugins, and other tools. From that perspective, there was no immediate reason to question the assumed system choice. But as I began to install, configure, and use the system for the project’s articulated purpose, it became clear that our goals with the project were misaligned with the design of the system.

While there are certainly times one might want to push systems beyond or against their design constraints, this is not one of them. Or, rather, it could be, but one should understand that there will be a cost in terms of time and maybe scope while cajoling the system into meeting the basic project requirements, with the major caveat that ultimately the system may not meet them at all, and the time attempting to make it do so will have been lost in the pursuit of something irreconcilable.

When evaluating and selecting systems, you’ve got a choice between established systems that you can configure or customize and bespoke systems developed for your purposes. If an established system meets 90% of your needs (the precise threshold is yours to determine), then perhaps the best use of time and money is to configure or customize to meet the remaining percentage. If nothing gets close (I’d suggest < 80%), you’re likely to need a bespoke system. But before you go off and develop something new, it’s worth really sitting down with the requirements, asking yourself “what will this look like when the credits roll” (so to speak), and working back from there, just like we’ve done with our work plans. Not only will this allow you find out if there are systems that just need a little work or maybe even match exactly what you’re doing, you will save time and money that you can spend on other activities that are more substantive for the project.

So let’s look again at the Voces del Lunfardo project in terms of what we’re trying to do.

1. We have a page for every term. Originally conceived as an item in an exhibition, the page itself affords some interaction with the textual material and will offer additional pedagogical approaches, like quizzes, teaching materials, and maybe even some interactive digital narrative tools.
2. Each page has a common set of metadata that allows it to be cited on its own.
3. Each page can be edited as necessary to account for bit/link rot, accommodate updates to system components, etc.
4. The remaining boilerplate of the site can likewise exist as pages that form the structure, provide navigation, and otherwise describe the tools the site contains.
5. Crucially, we are offering Voces del Lunfardo in Spanish first with an English translation as a secondary means of access. This means we need to be able to switch easily between languages, and/or detect the user’s language from their browser settings, *and* it means that the entire interface and all of our boilerplate text needs to be both translated and available upon language selection.

Omeka’s affordances vis-a-vis these basic requirements are as follows:

1. We can build a site that contains rich text pages detailing our terms. But Omeka’s design principle is to use deposited items in an archival or semi-archival manner so that the exhibitions themselves can provide contextual information around an item or collection of items. Notably, these rich text pages are limited in their interactive affordances.
2. Omeka allows extensive metadata and metadata sets, including custom and imported vocabularies. Dublin Core is standard, but much more is possible. Notably, however, the metadata applies to items and not the rich text pages, unless there is a plugin somewhere I have missed.
3. Omeka does allow the pages to be edited. It has a good enough content management system, but it is clear that this is not its primary focus.
4. As a digital exhibition system with an adequate content management system plugged or built in (depending), it is possible to create and edit pages that help provide structure and navigation, but…
5. I didn’t see easy ways to localize it or offer translations. And while I’m sure there is multilingual support somewhere in Omeka, it wasn’t entirely clear to me how to make it work.

What this amounts to is that while Omeka affords many things, its design principles are not quite aligned with how we’re attempting to work.

Enter DokuWiki

A wiki system became an option fairly early, and of the wiki platform options available, I chose DokuWiki for its relative ease of use and very low system requirements (remember our discussions last semester about minimal computing?). It helps that I am both familiar with and (full disclosure?) a fan of it, having used it for many years for my own personal knowledge management purposes. I installed both Omeka and DokuWiki, and DokuWiki won out in the evaluation because it neatly hits all of the above requirements, or gets > 80% of the way there. Specifically:

1. Every page is an object or item in DokuWiki’s view. And each page can be enhanced via a wide array of community sourced plugins to provide the particular interactions we want, or, if one doesn’t already exist, we could in theory hire someone to make one (or make one ourselves).
2. Metadata in DokuWiki is minimal, consisting of the 15 Dublin Core Metadata Elements. This is sufficient, though I would be happy to enhance it slightly to account for multiple authors. Again, this kind of development could be a worthwhile use of time and money. Additionally, a citation plugin allows every published page to be cited and offers (in English, for now) citation blocks in many common formats. Metadata sufficient for citation at the (rich text) page level was not available in Omeka, only at the item level or site level.
3. Every page in DokuWiki can be edited. A full history of edits is retained, which aids in maintaining things like provenance.
4. Structure is not automatic, but there are means of enforcing it and then surfacing it. The learning curve is slightly higher than maybe expected.
5. It has full multilingual support, both at the page level and the interface level. Page level translations require (of course) that we write the translations. Each translated page exists as a separate page from the base or default language page it is translating, which is where the structural learning curve comes into play. Additionally, making the multilingual navigation available required some code tweaks, but nothing significant.

For us, this means we can concentrate on relatively simple or tightly constrained configurations and customizations through the use of plugins, templates, and small code changes that take us from > 80% to 100%. This is only possible because of what the system already affords, and because our efforts work with its design constraints rather than against them.

I hope walking through my thought process here is helpful for others in evaluating their system selections, this term or in the future.