Category: Uncategorized

This year at Vivero was not as fast paced as it felt last year. This is mainly because of being a returning fellow and having less frequent on-the-job training, which allowed me to put more focus onto the tool I was working on in a given month. I was also able to explore newer tools that were not part of the usual training schedule, like Elementor and CollectionBuilder. I think in my first year at Vivero I was worried that I was learning so many tools that I would not be able to recall the information to be able to help peers. However, now I realize that there are always opportunities to revisit past tools as a refresher, and I do take advantage of that with the more flexible training schedule I have as a returning fellow.

I made a lot of progress on the TDPS Archive this year compared to last year, in my opinion. To be fair, the project was still in its infancy when I joined, as we were just trying to gather information on archival resources and content hosting. Toward the end of that year, we found answers to those questions and we were able to get started on actually creating something tangible. Building the framework of the archive website with CollectionBuilder was definitely the highlight of my project work because I was working with a new tool and incorporating in directly into my project. I’ve discussed this a lot in other reflections, but I really enjoyed using CollectionBuilder and diving deeper into more of the source code to solve problems I had with the default template. The most challenging part of the project has been filling in the metadata sheet purely because of the volume of shows and show information that needs to be collected. This is a task that, sooner or later, will need more hands attached to it. At the moment I am writing documentation that involves filling in this spreadsheet, so at least the task will be more manageable for whoever it falls to when I do leave.

My last training involved using wget, a program for saving webpages as html locally. I have had a passing interest in preservation of digital projects ever since taking DST-295 last year, so it would be nice to explore the topic in the future.

For my final training, I decided to do some python exercises on LinkedIn Learning. I have coded in python before, but since coming to Grinnell I have not revisited it in favor of languages like Java and C. The exercises I did revolved around string manipulation, which I have done plenty of in computer science classes with other coding languages. I realized that since python is a dynamic language, a lot of operations on strings can be done as if they were any other data type (e.g. comparing if two strings are equal). Getting used to this change was a little weird, and I think overall I prefer other object oriented languages, but I think I will still pursue learning more about python in the future.

While looking on Programming Historian for potential trainings to do, I found a program called wget. It primarily allows someone to download webpages directly to their local machine for preservation. I was mainly drawn to it because it works entirely in the command-line interface. I always enjoy building up my skills with using the command-line, so it was fun to use wget in this way. Otherwise, the program itself was pretty simple to use and worked well with downloading the webpages to my computer. I don’t think it will be particularly useful to me in the current moment, but site preservation is always important, so it’s nice to know about an option to save entire pages.

Elementor, compared to the classic WordPress editor, has a lot more to offer at first glance. I really like widget-based editing in general, so I felt pretty comfortable with how elementor functioned. I do think that the UI is a little weird to navigate because there are so many different sub-panels that can appear on the left side, and there is not any clear feedback that that pane changes when you select a new widget. I spent a lot more time trying to change global factors of my website (overall colors, typography, etc.) and this is mainly where my issue with the left panel’s lack of feedback really showed sicne I often couldn’t tell what exactly I was editing. Still though, I think Elementor is a very solid editor that I enjoy using, and I would be fairly comfortable with helping someone work with it.

In watching the accessibility stories, I was mainly struck by how much accessibility concerns were really about engaging multiple senses in case a user is unable to engage one or the other. This came to mind when I watched the videos on text-to-speech and video subtitles because both involved engaging with visuals (text) and sound (voiceover). The idea of having both instead of just one or the other includes a wider amount of users without drastically affecting the delivery of the content.

Programming a website to allow for text-to-speech bots to read it would be a technical feature. A more conceptual design feature would be general layout of the website, such as where navigation bars are placed and whether that placement changes depending on the viewing device.

To be honest, I hadn’t really considered labels for text boxes as accessibility features. Because they’re ingrained in most websites so people know what they’re supposed to type where, I just thought of them as basic web design principles. 

My portfolio website is already in good shape according to the accessibility checker. The only issues came from some of my alt text for images, or lack thereof in some cases. There are not a lot of images on my website anyway, so this should be a quick fix.

Even though I’ve been a Vivero Fellow for 3 semesters, I still feel like I’m learning more and more about the process of digital projects. I think that’s helped by my project being so early in development, so everyone involved is learning as we go. I think my best advice would be to embrace the process of learning and researching.  I feel like I get frustrated when there is no known answer about something, so being a fellow has helped me with finding answers out on my own.

The training structure was more laid back since I was a returning fellow, but I did enjoy revisiting some of the programs I learned before. I don’t learn as well when I only visit something once, but on that second look after some time I start to connect what I did before to its actual effects. I also liked the trainings that focused on broader Vivero topics. This allowed me to really delve into what I hoped to gain this semester with my project.

Using CollectionBuilder for the archive project has been the highlight of my Vivero work, and I think it’s mostly because of how much I could play around with the code within the project (I am at my happiest when I get to use Visual Studio Code). I really liked figuring out ways to break down the website functions into pieces that, once implemented, will almost never need to change later down the line. It was great digital humanities work as well as the general programming that I always look forward to. There are still some kinks that need to be ironed out for the general website, as well as setting up metadata and transferring everything into the proper website, so these are my next steps along with poster scanning. I wrote out the documentation of our progress this semester, and have been working on documentation specific to the CollectionBuilder site, which also needs to be updated as I continue to work on it.

I think content management projects are something I would always like to explore, not only because of the project but because of the relation to web development as a whole.

I’ve been using CollectionBuilder a lot these past two weeks for the TDPS archive, so I think it’s appropriate to reflect on that process. I’ve honestly been having a lot of fun using it. There was a bit of a frustrating point starting out when trying to get the right versions and making sure the spreadsheets were set up correctly, but after that it was smooth sailing. I also love that the entire project is open source because I was able to make edits to the template’s source code itself. This gave me so much more freedom to experiment and change parts to feel more like what I think the Kate and Erik wanted from the website. I think in general I like looking into templates like these and figuring out how they work, so this was pretty fun to do. The main obstacle for this and the project as a whole is transferring from the small test site I made into a larger one to hold the archive materials, but that is not a step we can take until those materials are hosted.

I think the most important part of writing good documentation is being descriptive in your steps. If someone reading a particular piece of documentation is left confused about where something is or how to access it, then that means there may be something missing from the documentation that should be included.

My project already has some amount of documentation, but so far that has really amounted to detailing the steps we have taken so far in gathering resources for the archive. Now that we have been zoning in on potential solutions, and I’ve been moving to testing websites, I’ve been thinking about what to document. Both Omeka and CollectionBuilder require certain steps with setting up spaces for images, and with the amount of content the theater department has, I have to consider the quickest ways to get the content organized both before it is added to the website and once it is already visible. This would most likely look like creating detailed steps for organizing test spreadsheets and setting up website pages once I figure those things out myself.

The TDPS archive project, while still in planning, has had some pretty significant progress this semester. A new avenue for hosting our pictures has opened through Digital Grinnell, and if we decide to commit to that route, we can start gathering our digital materials to send into it. There are still some questions regarding the creation of a separate site using Omeka to display the TDPS specific collection, as well as next steps for sending materials to DG. We talked about getting access to the library subscription of Omeka, with the only main downside being that we couldn’t edit themes or other visual aspects of our website, which I am fine with personally. I haven’t spoken to Kate and Erik about this just yet since we are still waiting on word from Mark McFate. I think my next steps would be to review Omeka and it’s page setups, so that if we do get access to a domain for the archive, we can work on how to display the content in a way that we think is feasible.

There is also the matter of digitizing the content that we do not have in the drive yet, mainly the show posters. We do have access to the scanners for them now, so scanning the posters is a task for me. I would need to sort through the posters in the recording studio before bringing them up to the offices to start scanning. I haven’t gotten around to it, but this will be my main goal after break.

I revisited the training for WeVideo this week because I was curious about how much more it had to offer. Ever since I first used WeVideo, I have learned how to use Adobe Premiere Pro and have edited a few videos using it, and I wanted to see how similar the offerings in WeVideo were to it. Something I didn’t realize the first time I used WeVideo was that you could edit the video itself by clicking on it. The options for color editing and masking and the like are there, and they work pretty well. The masking is pretty bare bones, using a simple color key system instead of allowing the user to create one from a shape. I still think WeVideo is pretty fun to use, and I may revisit it to create videos.