Caitlin Cacciatore (she/hers) graduated from Macaulay Honors at Baruch College, CUNY, in 2021 with a degree in Artificial Intelligence Studies. She comes from a background largely grounded in theory and the ethical implications of the proliferation of automation, machine learning, intelligent agents, the Internet, the inherently problematic nature of the digital divide, issues of accessibility, and the problem of machine bias. Caitlin also took courses in Python, C++, and SQL, as well as Excel, Access, and other database management tools.

During her time at Baruch, Caitlin became a published author, and possesses copyediting skills as well as website design and maintenance skills borne of administrating her own blog since 2016. In light of her intimate familiarity with WordPress, she will serve as the Sounds of Music team’s Technical Coordinator and Website Administrator. She will also work in a secondary capacity as a Copy Editor. Her duty is to polish content produced by herself and her colleagues, and transfer this content to a public-facing website. Her role is also to ensure that everything is running smoothly behind the scenes, and to co-create a seamless user experience for anyone visiting the website.

Caitlin is also responsible for co-creating a manifesto of best practices for music enrichment and engagement programs, as well as co-authoring a Sound of Music Workshop Toolkit, ideal for allowing individuals, groups, nursing homes, hospitals, daycares, schools, and other public and private facilities to create their own music enrichment programs. Additionally, Caitlin will brainstorm and iterate with her team members to launch a virtual synchronous Sounds of Music trial program, as well as a pilot program for the team’s target population of homebound elders.

Last Friday, I had a great experience attending the Accessibility Design Workshop, run by Heather Hill, an instructional technologist at Fordham University. It seemed relevant for me to join this work because of the Sounds of Music project, which is the project I’ll be developing throughout this course. As presented last week, Sounds of Music aims to provide an accessible online musical experience to foster a sense of community among its participants. Even though anyone interested can join the experience, the project’s focus for this course is making it accessible for disabled people or anyone unable to leave their homes for some reason. With that said, it is evident that having a clear idea about accessibility design is a must for our group.

The first part of the workshop was more theoretical, in which Heather explained what accessibility design is and why we should care about it. She talked about universal design, a concept related to accessibility, including some of the principles and guiding ideas.

In the second part of the workshop, she introduced us to the best practices related to accessibility so that we could have explicit instruction on how to apply those practices in our projects. By the end, we were divided into breakout rooms to use some accessibility checkers on websites of our choice. I used Wave, and It was an excellent hands-on moment that could reinforce many topics presented earlier.

To sum up, I’d like to highlight two bits of advice Heather gave during the workshop, which by the end I considered the most important ones.

1. Think about accessibility from scratch

When designing a new project/product, thinking about accessibility is its beginning is better than making it accessible after it is built. Not just because it will avoid reworking on things, but because when we make the experience more accessible for some unabled individuals, we have the chance of provide a better experience to the average user. This is the concept of designing for extreme users, which is a great design tool to have insights.

2. Universal Design is an unreachable goal

When designing to make things accessible for specific audiences, always have in mind that your design might not be adequate for some people. You can see that in the image below, the solution enables blind people to understand where they are but at the same time gives a bad experience for people in wheelchairs.

Photo Credits: oregonlive.com

If you are interested in knowing more about Accessible Design, I recommend checking out the recorded version of the workshop, as well as the resources presented in this handout.

F. Howlett

On Tuesday, February 8, Robin Miller, who we are fortunate to have as a classmate and as an Open Educational Technology Specialist and librarian at CUNY GC, led a workshop on Manifold, an open-source platform that is available for all at CUNY to use. An online CUNY description snatched from Google is: “an intuitive, collaborative, open-source platform for interactive scholarly publishing created by a collaboration from the CUNY Graduate Center, the University of Minnesota Press and Cast Iron Coding.”

Robin explained its origins as follows: Matt Gold, in 2011, was looking for a Digital Editor—something more than a website. It was important for it to be accessible and responsive, and what they came up with is a product that can be operated successfully even from a phone.  She explained that Manifold was built with the workflow of a university press in mind, so it can handle large projects but the intention is for it to have greater flexibility and applicability than a traditional literary press.

Manifold operates as a container. My understanding is that the container is essentially a  library,  or similar to a building with adjoining sections—a wonderful space to store not only your project but everything related to it and even things that may not be used but might be considered important connections and reference tools.  The opportunity to have everything you need to reach out for contained in one place. It is not intended for writing. Writing takes place outside the container and imported in without reciprocity. That is, if you amend something once it is inside Manifold, there is no synchronicity with the related documents outside the container.

Text may be brought in by 1) importing text; 2) bringing in a Google doc; 3) importing from Word; 4) texts can be built out from HTML or 5) from HTML Lite (LiteHTML), a function to give developers an easy way to show HTML in their applications.

Robin reported that Manifold is being adapted for a variety of purposes.  For example, at Brown, the freshman student body reads together from it as a book club.

A Manifold installation is called an instance.  That instance can contain several, dozens, or even hundreds of projects, and there is an established hierarchy as to who has permission to do what to whom within each project. Each project has a home page that may contain many content blocks or just a few, depending on how many different categories (paths to take, areas to explore) one wishes to provide. The core block is called the “Hero” block. It appears directly below the title, describes the project, defines its creators and other essential information, and cannot be removed.  Everything else on the home page can be manipulated as desired.

It is possible to include video and audio files and bring in items that would be very difficult for a traditional publisher.  Various content blocks can be hidden as long as wished and released when deemed ready.

The Manifold documentation that I have explored so far is thorough, well-written and easily available both on the CUNY Academic Commons and on Google. Examples of how it is used for projects—whether for classrooms or research or archival purposes—is also plentiful both at CUNY and on the internet.  It gets compared to resources such as Press Books or Pub Pub. In its relatively short lifespan, it seems to have become an integral part of the life of digital publishing.

I attended the Moacir P. de Sá Pereira presentation on GitHub. I got as far as creating an account, and I am very interested and fascinated by its connectivity with Zotero, but it’s going to take more than a couple of hours for me to digest all that I heard there.

The NYC Digital Humanities Week event that I will be reflecting on was entitled “DH Project Management”, a talk organized by Jesse Merandy and Kimon Keramidas. I chose this talk more generally because of the projects we are all embarking on this academic semester, but also because of the specific questions I had regarding the specificity of the project my partner and I are embarking on. We are doing a collaborative text analysis, a digital methodology that I have been having trouble conceiving of having a group dynamic. What will project management look like in this context?

The speakers started by going over three basic paradigms with which digital humanists usually approach their projects. The first do are mutually exclusive, but the third will fall into one of the first two categories. The first two are that of original collection and existing collection and are related to the kind of data to be used for the project. For a project with an existing collection, there is a pre-existing data set, so it is a question of data aggregation more than data collection. However, plan still needs to be set up for a data repository for the project. The repository must be compatible with the incoming data. The tool selection also has to be compatible with existing data structures.

For a project with an original collection of data, there is no pre-existing data set, and thus it must be gathered. The question that must be first thought through is what needs to be gathered and how will it be gathered? The same rules apply for the repository, but in this kind of project, there is more of a dialectic between tool data. As with the pre-existing set, the tool selection must be compatible with the data, but the tool can also drive the data collection. This is the kind of project that my team will be working on this semester.

The third paradigm is a team-based project. This was the most important portion of the talk for me, given, as I said, that we are working on group projects this semester, but especially because the elements of team work that were stressed were very much at odds with the way I was planning on approaching my own project. The speakers emphasized that organization should be the number one priority of team-based digital humanities work. There must be clear project goals derived from the project proposal/description, and a plan must be built around this that his focussed and communicated with all members of the team. Scheduling is more complex and crucial for groups than for individual projects, which have the liberty to be more fluid with less moving parts and thus less variables. This upset the expectation that I had of my two-person team project being loosely organized, working at whatever pace felt right, having an amorphous work plan that would evolve as it went. The speakers made it clear that this kind of orientation was surefire way to not get what we want accomplished. The project goals must be as clear as possible so the tasks can be made as discrete as possible so as to make sure that we are staying on track. This will also allow a team to build in space for failure, course correction, and other constraints of working on a project.

I am indebted to these speakers for this insight, as well to the opportunity to do this group-oriented work in the first place. The collaborative spirit of digital humanities is one of the elements that drew me to the field in the first place. As one of the speakers said, despite the challenges (or maybe because of the challenges) that come with collaborative work, what it offers is the chance for a work that is more of the sum of its parts. I am grateful to be able to surrender this idea that I had which led to the creation of a project proposal, and allow this project to be individuated in a way which is social and goes beyond what I would be capable of alone.

As intended, my engagement with NYCDH Week began with the Kickoff Event on February 7th, which allowed some of New York’s most active Digital Humanists (I really should’ve taken down more names, I apologize) to introduce attendees to the theme of support that would pervade the week’s subsequent workshops, lectures, etc. Rooted in the ongoing impact of COVID-19, this commitment of support from the broader Digital Humanities community struck me as particularly salient, not purely because of its obviously apposite application in the wake of a global pandemic that impacted each person in some way, but also due to its relevance to my experience as a first-semester Digital Humanities student navigating the common challenges associated with acclimating oneself to any new academic endeavor. The Kickoff Event and its ensuing roundtable discussion introduced me to the existence of a network of brilliant minds, each in the pursuit of developing unique and innovative digital projects, that I was entirely unaware of prior to entering this program, providing me with a sense of the city’s Digital Humanities community and the potentialities inherent in cultivating relationships and support networks with such a tight-knit web of inspiring folks.

I was especially interested in Jim Groom’s Reclaim Hosting platform, which, in their words, “provides institutions and educations with an easy way to offer students domains and web hosting that they own and control”. Despite the fact that my interest in Groom’s service might be heavily influenced by Reclaim Hosting’s landing page including references to bands such as Mission of Burma and Minutemen, the support provided through this web hosting platform, allowing for both students and educators to “take control of their digital identity,” acts as another appealing example in a long line of Digital Humanists undertaking the project of the democratization of technology. If interested in reading further about the story and motivations of Reclaim Hosting, Jim Groom wrote an interesting blog detailing its history here.

The second NYCDH workshop I attended was hosted by DHUM 70002’s very own, Robin Miller, and detailed the “intuitive, collaborative, open-source publishing platform” that is Manifold. Developed as a novel medium in which academic books can be published online, Manifold allows authors to supplement their work with the traditionally unpublished elements existent beneath the text (“conversations, research, exploration”), providing an opportunity to expand the breadth of each text in an accessible, unbounded, aesthetically-slick digital space. Robin did a fantastic job enthusiastically detailing the scope of Manifold’s capabilities, such that Digital Humanities “freshmen” like myself came away from the workshop with a practical understanding of a program that feels simultaneously approachable and sophisticated. There’s nothing I can say about Manifold that hasn’t already been said more effectively by those involved with its production (i.e., CUNY Graduate Center, the University of Minnesota Press, & Cast Iron Coding) so I encourage everyone to take a look at the provided linked materials, should this application be relevant to your DH pursuits.

When I first entered the Digital Humanities field I knew I wanted to gain more knowledge and experience within the realm of programming and coding. Skills attained in this discipline will not only help me with future projects but will also open the door for more opportunities in tech.

However with no prior experience in the mechanics of computing I knew early on this would be quite the arduous task for me to take on. I mean lets face it, data programming is not something you can learn overnight with a few YouTube tutorials and google searches. I do wish that were the case but seeing as though it’s not it was obvious to me early on that I had to take things slow to really ease myself into this meticulous field.

This is where Python: A Gentle Introduction comes to play. Hosted by Fordham University Science and Technology librarian, Katie Wolf, this workshop walked students through the general use programming language known as Python. Wolf began the workshop by giving us a basic run through of the general functions and usability of the app. Below I have listed a few in case anyone is curious and/or interested in using it.

-Interpreted language (Does what user tells it to do)

-“Object oriented”- Almost anything put into Python is considered an object

-Can visualize data

-Can be used to edit and create files

-Can interact with web (scrape website, parse html etc.)

Afterwards she brought up her version of Python as well as a text editor to give us live demonstrations of different ways a user can code on the app. Prior to the workshop we were all told to download Python on to our computers/laptops so that we may follow along using her examples. The version I installed was 3.10.02 (64 bit) for Windows (different version for Mac OS users).  As far as my text editor is concerned I did not have any of the ones Katie recommended on hand but she reassured me that was fine as long as I had a program I could write on. I ended up just using my notepad app.

Text editor Recommendations– SublimeText (TE), Atom (TE) or Atom-IDE (IDE), IDLE (IDE) for Windows, Visual Studio Code (IDE)

Once we had both open we opened up a command line interface where we were able to run our python scripts. In my case I had to use Powershell which was already available to me as a Windows user (Mac OS users use Terminal). Now that we had all the appropriate applications opened Katie was able to walk us through a variety of basic operations we can perform using Python. We started off first with variables. Variables can store information and be assigned any data type, however the user has to input the variable correctly in order for Python to understand. The variable must start with a letter or underscore (NO NUMBERS) and can’t contain any special characters or spaces. For example if a user wanted to type in the word “hello” it would have to be typed in as A= “Hello” or A_variable= “Hello”.

Once we finished with variables we moved on to basic data types such as strings, integers, floats, operators, lists and dictionaries. At this point the workshop turned more into a viewing than a follow along for me as Katie had premade strings made from previous coding attempts. I made the decision to watch rather than perform because my first attempt at coding while listening turned out to be a fail (I kept missing information and got hit with multiple unknown and syntax errors).  Here are some notes I took during the demonstration if anyone is interested:

Strings are always surrounded by quotes, loop able and countable, ex – a=”hello, world!” print (a.split (“,”)) – > [“hello”, “world”]  integers are whole numbers both positive and negative, floats are positive or negative numbers with decimals

Operators are used to perform operations on variables or values Arithmetic ex (+,-,=,*, /,%, etc.) Assignments ex (=, += ,-=, *=, /=, %=, etc.) Comparisons ex (==, !=, >, <, >+, <=) Logical, Identity and Membership (and, or, not, is, is not, in, not in)

Lists can store multiple items in a single variable with the use of square brackets [ ] and are indexed at zero. You can use method append () to add things to a list remove() to remove things from a list clear () to empty list completely, sort () to organize a list alphabetically and numerically etc.  Tuples have the same function but use round brackets/parenthesis ( ) Example:

Dictionaries are able to store multiple items in key: value pairs and use curly brackets { }. They can be ordered and changeable but don’t allow duplicates. Dictionaries can only be ordered in Python 3.7 and newer versions. Use keys() to see all keys, values() to see all values items () to get all key: value pairs and update() to change the value of the key: value pair. Example:

These are only a few of the items you can perform on Python. Hopefully my notes are clear but I can understand if this may look foreign to someone who has never coded before. That was certainly my reaction over the course of the workshop. There were several moments throughout the session where I found myself getting lost and falling behind. But that’s ok! Like I said coding is not something you learn overnight, it’s a skill you keep working on until you get comfortable-something even Katie made sure to mention during the demonstration.

With that being said my first baby step into programming has definitely been an impactful one.  Overall this workshop was highly informative and helpful. I left having a basic understanding of what Python is able to do and how I’m able to make it perform as a Windows user! I want to also give major props to Katie who not only answered questions along the way but also took the time out to stay behind on the zoom call in case anyone needed further assistance or explanation.

Here’s the simple code I created with Katie’s help:          

Emily Fairey talks about her journey in her process of archiving all the photos she collected over her 1 month internship at Columbia University, specifically in the Treasure Room of Diamond Law Library. In there she became fascinated with the ‘printers mark’ of the books, or the frontispiece– the decorative or informative illustration facing a book’s title page. Over the course of a month she collected over 200 photos of 50 books. (link to full presentation here)

After collecting these photos she wondered how to showcase them to the world, in order to explain why these are of importance. The frontispiece is thoroughly integrated into the context of the book– so it would only make sense to extract it as an ‘artifact’ of the book. They were complex self-definitions, sometimes to individuals printers themselves and other times of fraternities. Stating in clusters of symbolism what values they held preeminent.

---

Antonio Pinelli, A River God-The Tiber? Wolf with Romulus and Remus. Papal hat with tassels, coat of arms. 1610

---

Continue reading →

On Wednesday, 2/9/22, I attended a workshop, Publishing with GitHub Pages, given by Alex Gil. I attended this workshop because I was familiar with using Github as part of a software versioning workflow, but I had yet to explore GitHub Pages — a way to easily create a static website hosted by GitHub. In this workshop, Alex walked us through building a static website from a repository created on GitHub. I was impressed at just how easy it was to create a static website. The GitHub Pages sites are built using Markdown, which I was already familiar with, so I was able to build my site fairly quickly. Markdown is pretty accessible, even for folks who had never used it before, so everyone in the workshop was able to get a GitHub Pages site up and even add an iframe to stream content from YouTube. Alex spoke a bit about how GitHub Pages uses Jekyll to power the static sites and he also briefly introduced us to Wax, for those that might want to create a site that uses image collections or exhibits. In addition, he covered the ideas behind Minimal Computing — “computing done under some set of significant constraints of hardware, software, education, network capacity, power, or other factors.”

GitHub Pages is a really great way to get a simple, or complex, static website up and running pretty quickly. I would recommend that anyone with an interest, check out the GitHub pages site and starting playing around with it. I think you will be surprised at just how quickly you can put together a really nice looking website.