4.3.3: Current Implementation

One of the problems that Kalani and I ran into when working with the platform in the months following the IDAH Summer Incubator was a difficulty regarding the translatability of the JavaScript code for the reading options available on the Opaque Online Publishing Platform (OOPP). Out of the incubator, Kalani developed a long-scroll approach to organizing the dissertation’s markdown (.md) files, which allowed a chapter, and the dissertation in its totality, to be viewed in a single page. While we moved away from this functionality because of other technical issues,¹ this decision forced us to shift our approach to the image opacity function.

The issue that arose with Sagar’s code came about because of the way it nests the important information into a script footer. Every image needs its own unique identifier, references, and different information. Look at this example code, which I had simplified in the previous section (4.3.2), and how it creates information for three separate images:²

<script>

function toggleOpacity(mode) {

const partialLines = document.querySelectorAll('.partial-lines');

const opaqueLines = document.querySelectorAll('.opaque-lines');

const HenryReport = document.getElementById('HenryReport');

const henrydetail = document.getElementById('henrydetail');

// Remove the "active" class from all buttons

const buttons = document.querySelectorAll('.toggle-button');

buttons.forEach(button => {

button.classList.remove('active');

});

if (mode === 'partial') {

// Toggle partial lines

partialLines.forEach(line => {

line.style.backgroundColor = '#000000'; // Set background color to black

HenryReport.src = "/diss/assets/img/ReportoftheHenryPhippsIns3_1905-1906158_Partial.png";

henrydetail.src = "/diss/assets/img/ReportoftheHenryPhippsIns3_1905-1906158_Resize_Partial.jpg";

});

// Ensure opaque lines are fully visible

opaqueLines.forEach(line => {

line.style.opacity = '1';

line.style.backgroundColor = ''

});

        

} else if (mode === 'opaque') {

// Toggle opaque lines

opaqueLines.forEach(line => {

line.style.backgroundColor = '#000000'; // Set background color to black

HenryReport.src = "/diss/assets/img/ReportoftheHenryPhippsIns3_1905-1906158_Full.jpg";

henrydetail.src = "/diss/assets/img/ReportoftheHenryPhippsIns3_1905-1906158_Resize_Full.jpg";

});

// Ensure partial lines are fully visible

partialLines.forEach(line => {

line.style.opacity = '1';

line.style.backgroundColor = ''

});

}

else if (mode === 'non-opaque'){

HenryReport.src = "/diss/assets/img/ReportoftheHenryPhippsIns3_1905-1906158.jpg";

henrydetail.src = "/diss/assets/img/ReportoftheHenryPhippsIns3_1905-1906158_Resize.jpg";

partialLines.forEach(line => {

line.style.opacity = '1';

line.style.backgroundColor = ''

});

opaqueLines.forEach(line => {

line.style.opacity = '1';

line.style.backgroundColor = ''

});

}

// Add the "active" class to the clicked button

const activeButton = document.querySelector(`button[data-mode="${mode}"]`);

activeButton.classList.add('active');

    

}

</script>

The problem is not the code itself, so much as the fact that the code does not take into account the way that Jekyll-based sites are built. The dissertation is composed of a few dozen separate markdown (.md) files, which are used as data inputs to templated pages. A static webpage, Jekyll builds the site by cross referencing these markdown files with the associated hypertext markup language (.html) files, generating a unique .html file which is accessed when the site is engaged by a web browser. For the long scroll dissertation chapter to function, it would build the sections by joining the text in the associated markdown files. So, a series of files that read like this,

File name: Fileone.md

-----

[header]

-----

Text for file one.


File name: Filetwo.md

-----

[header]

-----

Text for file two.


File name: Filethree.md

-----

[header]

-----

Text for file three.

When these markdown files are compiled for web, they would read for the user like this:

Text for file one.

Text for file two.

Text for file three.

The problem that arises with Sagar’s code is that it depends on the use of footers, which would be inserted in between the lines of text. So, if I have those same files, but instead they include a footer, they would read like this:

Fileone.md

-----

[header]

-----

Text for file one.

<Footer1>

Filetwo.md

-----

[header]

-----

Text for file two.

<Footer2>

Filethree.md

-----

[header]

-----

Text for file three.

<Footer3>

And they would produce a scroll that has, in the HTML, multiple footers:

Text for file one.

<Footer1>

Text for file two.

<Footer2>

Text for file three.

<Footer3>

I am not sure if this would just break the whole site, as I am not an expert in HTML, but at the very least it becomes extremely unwieldy as most of the chapters in this project have more than a dozen sub-sections.³

The issue was not necessarily a nail in the coffin for this approach, at least if this platform was only aimed to be used for an individual dissertation. I am certainly capable of cross referencing, at the end of the project, each image file and making sure the proper identifier and file is demarcated. It would be a lot of labor, but probably an afternoon or two of close work. The problem is that Kalani and I wanted to make sure the OOPP could be shared with others for their own use, and the code as it was written is a bit too difficult for someone new to the platform to implement, especially if it needs to be placed in multiple files across a project. GitHub pages has its own learning curve, which can be intimidating enough for some users, and we did not want to create a bigger barrier to entry; moreover, if we are practicing a minimal computing approach, with its eye directed at keeping the processes of computation open to as many scholars as possible (4.2.2),⁴ then we needed to make sure that the workflows for the vital features were not a problem for our users.

The change to this , Kalani wrote new code. The first was a change to the button code:⁵

<div class="toggle-buttons">

<button id="opaqueBtn" class="toggle-button">Opaque</button>

<button id="transparentBtn" class="toggle-button">Transparent</button>

<button id="partiallyOpaqueBtn" class="toggle-button">Partially Opaque</button></div>[^fn5]

And the second is a change to how images are defined on the site. Here is an example of the first implementation of this new code in December 2023,

<img id="Barlow_1922_0001_cropped" class="opaque" src="/diss/assets/items/Barlow_1922_0001_cropped_opaque.jpg" style="max-width:60%;height:auto;">

<img id="Barlow_1922_0001_cropped" class="transparent" src="/diss/assets/items/Barlow_1922_0001_cropped.jpg" style="max-width:60%;height:auto;">

<img id="Barlow_1922_0001_cropped" class="partially-opaque" src="/diss/assets/items/Barlow_1922_0001_cropped_partial.jpg" style="max-width:60%;height:auto;">

The change is a shift from where the files are referenced in the code. The older code does this work in the footer, but the newer code does so in the body of the text. The basic idea was to shift what the code is looking for: instead of the ID, it is looking for a class, which interacts based on which button has been clicked. Each of the images loads when the web page is loaded,⁶ and then the site checks which one should be visible and which ones should not.

What is most helpful, and which I will go into more detail in the next section, is that this means that I can add images with a little less cognitive overhead in both the writing and finishing phases, because all of the information is placed at the same moment, and because all of the information is standardized (X.2.3; X.2.4).