Blog Posts

I’d like to propose a self-guided SQL training (perhaps via Programming Historian’s ‘Introduction to Populating a Database with SQL’ or SQLZoo) to build database skills that would help me support Fellows working with structured data in Omeka, ArcGIS attribute tables, or survey datasets. Querying and cleaning data is a recurring need across Digital Humanities projects, and some courses use SQL directly, so this would let me offer more technical peer support both in Vivero and more broadly on campus!

I decided to focus on WeVideo this year because I still hate it with every fiber in my being.

WeVideo’s built-in stock library is massive, which leads to total decision paralysis (for me). It would be great to see a “best practices” segment on how to filter and curate these assets so student projects end up looking cohesive, rather than generic or tacky.

Adding a clear, step-by-step guide on how to actually generate and edit auto-captions could be a valuable addition as well.

Students might be interested in shooting footage on their smartphones. We can have explicit section showing them how to record video on their phone and cleanly pull it into the WeVideo editor.

I would say future Vivellos should focus heavily on the specific technical bottlenecks that frequently ruin student projects (in my opinion).

First, they should move away from the generic “fade in and out” buttons and master multi-track audio mixing. Learning how to create multiple audio keyframes to manually adjust the blue volume line (dipping the music precisely during a voiceover and raising it back up during transitions) makes a big difference in production quality.

Track management is another huge skill, as students can get confused by layers and accidentally hide their text overlays behind their background footage. Vivellos should focus on how to effectively stack tracks with text on top and main footage in the middle, while also learning how to use the crop and scaling tools to create polished picture-in-picture layouts.

Finally, they should practice restraint with motion graphics and transitions. If students throw in random, flashy effects or mismatched fonts, that makes academic projects look incredibly messy. (I do welcome them in informal projects though because it’s entertaining to watch!) Fellows need to learn how to deep-dive into the text engine to standardize font families, colors, and spacing, while sticking to clean, subtle transitions like basic crossfades.

The biggest area of growth I’ve experienced so far as a Vivello is definitely handling physical things. I’m usually a software person, so getting comfortable with 3D printing, sanding, and all the hands-on tools in the Burling basement was a real shift for me. It’s been a surprisingly nice change of pace to work with something tangible instead of just staring at a screen, and I’ve learned way more from just messing with the equipment than I expected to.

As for weaknesses, I’d say I’m a bit of a perfectionist, especially when it comes to things I’m writing or creating for other people to see. I’ll rewrite a display description five times because it doesn’t sound quite right, or spend way too long tweaking something that was probably fine after the second draft. It’s not necessarily a bad instinct to have, but it does slow me down, and I think I could be more efficient if I trusted my first or second attempt more often.

My favorite thing about being a Vivero Fellow has actually been helping other Vivellos. Because there’s a new batch of them I’ve been getting a lot of questions (and 3D printing requests). I enjoy it when someone comes to me stuck on a problem and walking them through it until it clicks!

Looking at all three of these together, I want to focus my training and professional development on data skills going forward. This might seem like a disconnect from my growth area, since that’s been more about physical making, but I’m a senior now and thinking hard about my post-grad job search (especially when it’s been eating up so much of my time). My CS and Math background, plus my research experience with data processing over the summer, makes data skills the most useful thing I can build on right now. I want to be intentional with my remaining time as a Fellow to set myself up for what’s next.

For October and November, I’m proposing PySpark and SQL as my two trainings. PySpark connects directly to the data engineering work I did during my research internship, and going deeper into it will help me talk about that experience more confidently in interviews. SQL is one of those skills that shows up in basically every technical job posting I’ve seen, so building it up now feels like a practical investment. Both trainings should give me concrete, resume-ready skills while I still have the structure and support of the fellowship to learn them in. And who knows, maybe one day someone will come down and ask for help with one of them!

I was surprised to find a new guide!

The guide mentioned that the Editoria11y Accessibility Checker should be installed by default, but it actually wasn’t for me, so I had to install it myself. (I’m wondering if it would be useful for the guide to clarify that the plugin is only default if you created your website after a certain date, just to prevent confusion for others!)

Once I got it running, I actually really liked the UX of this plugin. It’s not cluttered at all and is super simple to use. It immediately flagged that I didn’t add alt text to my images, so I went back and fixed those.

Moving forward, I’ll definitely keep using Editoria11y as part of my regular routine to maintain the site, since its simple notifications make it so easy to catch those quick mistakes while I’m working.

For my project this year, I anticipate needing to look closer at how my design choices impact users. Since I know I missed alt text initially, I’m expecting to ask myself more questions about formatting, contrast, and structure as the project grows. I want to make sure I’m building it with accessibility in mind from the start rather than just catching things at the end.

Reflect in a blog post on your portfolio site: with a year of Vivero experience under your belts, what advice do you have for new Fellows about the idea that this job involves learning how to do your job on the fly?

Looking back at my time as a Vivero Fellow, the biggest takeaway for me is that a huge part of this job is learning how to do it as you go. When you start working on a project, whether it is building a website for historical research or managing tech logistics, you are rarely going to know how to do everything right away.

If I could give any advice to new Fellows entering the program, it would be to not be afraid to try new things and make mistakes.

When you are learning a new tool or coding a new digital space, things are naturally going to break. In my experience, making mistakes is actually the best way to learn. Figuring out why something didn’t work teaches you much more than getting it right on the first try.

You also need to be confident in your ability to figure things out. No one expects you to be an expert on day one. Half the job is just having the confidence to look at a software, platform, or problem you have never seen before and trusting that you can learn it. Don’t stress when you run into something unfamiliar. Just take it one step at a time, and you will adapt!

The most important thing I’ve learned this semester is that being a Vivero Fellow is way more hands-on than I expected. Coming in as a CS major who’s more interested in software than physical objects, I thought I’d mostly be helping people with coding or website stuff. Instead, I spent a lot of time learning how to use 3D printers, sanding prints, and writing descriptions for a physical display. I realized that digital scholarship isn’t just about the digital part.

If I could give advice to past me, it would be to not be afraid to just mess around with things. I was really cautious at first with expensive equipment, worried I’d break something. But you learn way more by actually using the tools and making mistakes than by just reading about them. Also, ask for help sooner. I wasted time trying to figure things out on my own when I could’ve just asked someone who already knew (aka Max).

Another advice I would give is to not sand too quickly because otherwise your hand will burn… lessons were learned the hard way.

I think the training model worked pretty well overall. I liked having a task every month.

I will be abroad next semester so I won’t be here unfortunately… but I do plan to come back afterwards!

For future exploration, I’m considering learning Blender more seriously. 3D modeling seems like a natural next step after all of the 3D printing I’ve done! I think being able to design my own models instead of just printing other people’s files would be pretty cool. I’m also interested in accessibility and inclusive design, especially after writing those display descriptions and thinking about how to make technical information approachable for everyone.

This semester pushed me outside my comfort zone in a good way. I came in thinking I’d mostly do software stuff, and I’m leaving with actual making skills and a better understanding of what digital scholarship really means.

The documentation I created are the descriptions for the 3D print display items. This is a different kind of documentation than the usual “here’s how to use this tool” because these descriptions are meant for anyone walking by, not just future Vivero Fellows.

My approach to documentation is honestly pretty chaotic. I write things when I feel like it, which isn’t the most systematic approach but it works for me. For this project specifically, I put a lot of thought into making the descriptions actually interesting to read because of my personal experience. To be honest, I get really bored from art museum labels… I read a couple, maybe some, and then just start looking at the art without reading anything. I didn’t want that to happen with our display. That’s why I tried to make each description quirky and approachable. For example, instead of just saying “this is a mathematical surface,” I’d explain why it looks like a sombrero and how you could make your own. The goal was to make someone walking by actually stop and read, not just glance and move on.

The struggle is that I make a lot of edits. I’ll write a description, think it’s okay for now, then rewrite it three times because it sounds too formal or too casual or not interesting enough. I also ask for a lot of feedback — I sent revised descriptions to the students whose work I was describing to make sure I wasn’t misrepresenting their projects. That back-and-forth helped me find the right balance between being accessible and being accurate.

Looking back at my documentation now, trying to imagine I’m someone new seeing these descriptions, I think they do a pretty good job of capturing what each print is about while keeping things engaging. Some of them might need tweaking once we actually put them up and see how people respond, but overall I’m content with how they turned out.

My general approach to documentation is to write what you’d want to read. If I’m bored writing it, someone else will definitely be bored reading it. For these display descriptions, that meant adding personality, asking questions, and connecting the prints to real-world applications people might care about. It’s not the most efficient process since I revise so much, but I think the end result is worth it.

The hardest part is knowing when to stop editing. At some point you just have to accept that it’s good enough and move on, which is something I’m still working on. (This is why I don’t like writing papers and have never taken an English class here).

Sample

This month, I focused on researching Blender. I wasn’t able to start hands-on work because I lost my mouse, but I spent time learning how Blender actually works and what I’ll need to be comfortable with before diving in.

Through my research, I learned about Blender’s core workflow: model -> material -> light -> render. Understanding this pipeline helped me see how projects move from a simple mesh to a polished final image. I also explored the basics of viewport navigation, common shortcuts, and the importance of using modifiers like Mirror, Subdivision, and Solidify to speed up modeling.

I looked into Blender’s two render engines (Cycles for realistic lighting and Eevee for fast previews) and how each is used in different types of work. I also learned that lighting (especially using HDRIs) can really improve a scene even when the model is simple. Finally, I got a better sense of what beginners typically tackle first, e.g., modeling basic objects, setting up simple materials with the Principled BSDF shader, and creating clean, well-lit renders.

Even without hands-on practice yet, this research gave me a solid foundation. Next month, once I have my setup ready, I’m hoping to apply what I’ve learned and start building my first small scene in Blender!

For this month’s deliverable, I chose to peer review and build out additional sections for the Audacity training. After going through the training again and thinking about what would actually help future Fellows, I added three new sections — keyboard shortcuts, troubleshooting, and file format guidance.

The keyboard shortcuts section is basically a cheat sheet organized by task type so you can quickly find what you need. The troubleshooting section covers all those annoying beginner problems like your mic not being detected or audio sounding muffled. And the file formats section explains when to use MP3 versus WAV and what all those bitrate settings actually mean.

Writing these taught me that creating training materials is way different from just knowing how to use a tool. You have to think about where people will get stuck and explain solutions in a way that’s actually helpful. I tried to keep everything straightforward without being too technical, which was harder than I expected. It took me much longer than I expected.

I’m still not totally sure if the sections I wrote are too long, but my supervisor liked them, so hopefully they’ll be helpful for future Fellows working on podcasts or oral history projects!

I revisited the Audacity training.

The training already covers the essentials—navigating the toolbar, recording audio, selecting and trimming tracks, adjusting volume, copyright, etc.

The training itself is pretty solid. It has a clear, logical progression from installation to export, good visual aids, and a practical focus on tasks Fellows will actually need. I especially appreciate that it includes an accessibility section since that’s often overlooked. That said, I think it could use a more robust troubleshooting section specifically for recording issues – microphone not detected, audio sounding muffled, that kind of thing. These are super common first-time frustrations. Adding a quick reference guide of keyboard shortcuts would also be helpful since they save so much time once you learn them (e.g, Ctrl+Z for undo). Maybe you could also include a brief section on file formats too, explaining when to use .mp3 versus .wav and what bitrate settings mean for quality and file size?

For leveling up, I’d recommend future fellows focus on multi-track editing (good for podcast production), noise reduction (this can really improve audio quality!). Also, equalization (EQ) helps make voices sound clearer and more professional. Beyond that, learning to use labels to mark sections of long recordings would be incredibly helpful for oral history projects, and getting used to the Envelope Tool for precise volume adjustments would be good too.

Audio editing is one of those skills where you learn best by doing and by making mistakes, so I’m glad that the Vivero training involves messing around with it! I think overall, the training provides a strong foundation, and with a few additions focused on troubleshooting and intermediate techniques, it would give Fellows everything they need to produce professional-quality audio projects!