Page Functionalities
Much has happened since the last post: The Latin text and the translations display seamlessly with the help of CETEIcean and by now the project has a decent looking page layout. I am no web designer and my CSS skills are limited, so there are a million papercuts and I have no idea whether anything I do is truly ‘up to code’, but I do like the general vibe and my limited understanding is that CSS is easily changeable later on, so lets keep it like it is for now and hope for the best.
Most of my time has gone into adding functionalities to the text via CETEIcean behaviors. Some of them are always accessible, such as transliterations of greek words and phrases. Others, such as buttons that toggle a translation of the current paragraph or editorial comments and marginal notes, are available only after the user has checked the corresponding box in the page settings. My reasoning here was that I wanted to offer a reading experience that was clean and distraction-free by default and only offer aids and features if the reader explicitly demands them. For the same reason, there is no constantly visible menu, sidepanel, ribbon, everything folds away at the screen edges, so that you are completely alone with the text - I quite like it, and the design takes its queues from Matthew Butterick’s web-based book Practical Typography, which generally was a major inspiration for me when it comes to reading and writing online.
As to the inner workings: The HTML-form that contains the options from which the readers can choose are processed with PHP. I am on the fence about this decision, since it introduces a whole host of backend processing which was so far completely out of the picture, and which I chose mainly because I happen to know some PHP. So maybe it would be smarter to handle this with JavaScript as well – let’s see. If checked, Marginal notes are printed on the metaphorical page, while translations and commentary are visually separate in the right area of the screen. They are displayed as individual widgets that can be closed individually. The idea behind this is that you can click on whatever editorial element you want, and they just stack up on the right, like a bunch of note cards, waiting for you until you give them attention and the close them once you no longer need them. The problem with this is that there is no horizontal coordination between an editorial element and its target – the more notes are open, the further they get pushed down the page. So far, I don’t see this as a big problem, since it is pleasantly uncomplicated and my assumption is that when you click on a note / translation, you want to read it immediately. It might get more complicated once you have multiple available translations and want to compare them, but at this point, that is a complete hypothetical. A possible solution to the whole situation would be to introduce links in the notes that link back to their original target.
Over the course of the past weeks, I of course learned a ton about JavaScript. Promises in particular proved to be a challenge, but I definitely needed them for fetching comments and translations from the server. Eventually, I more or less got the hang of it. They also proved to be the solution for my most vexing problem: Only one MEI-file would ever render on screen. It turned out that the for-loop I wrote for checking for all the instances of music examples in the text did not wait for the fetch
-calls to return. So, pleasantly, that is fixed now as well, which is neat, since I will have time now anyways to transcribe some more musical examples.