Sign in or register
for additional privileges

PLATFORM SHIFTS

Media Change in an Ever-Evolving Institution

Angelica Vergel, Author

You appear to be using an older verion of Internet Explorer. For the best experience please upgrade your IE version or switch to a another web browser.

Tailoring Scalar For Beginners





Scalar's Built-In Slideshow Feature




A Lesson in Disappointment by Ari Spool


When I set out last week, I wanted to see if I could build a Scalar slideshow feature. I am not an experienced programmer, and I wanted to try (and maybe fail) in creating a feature that I regarded as basic in an archival website, but seemed to be strangely missing from the system we were using. The idea was to prove that it was extremely difficult to create even basic features in digital humanities web sites – and that this barrier was part of why it was difficult to provide access to digital humanities in any sort of regular fashion.

After a week of failing to code such an object, I refreshed a page and –– It worked.

The secret? Frustrated by my continuing failure late into the night before my assignment was due, I had deleted all of my custom code, and just left a series of image links in the page, planning to return to them later. It turned out that Scalar had a built-in slideshow feature all along. All you needed to do to activate it was nothing at all. 

As you can see above, it retains all the Scalar features I needed: the included annotations, preview images, and the dynamic element. I'm not sure if the fact that it was there all along and is more or less frustrating than the fact that I couldn't build it myself. Surely, if I was being paid to figure this out, I would have wasted a lot of money, which is not something that appeals to many institutions trying to implement digital systems.

My Process


First, I read the documentation for Scalar, focusing on the media display, visualization, and content sections. Nothing mentioned anything about how you would insert media into a slideshow format. It was clear that I would have to use the media emphasis view, but it wasn't clear how the media would be imported in that view, and whenever I attempted to put an image in using the image importer, it was inserted as inline. 

The default media emphasis view did mention "a scrolling display area at the top," but without demonstration, it sounded like that meant the scrolling bar that displays the media on the side of the "Selecting a Page Default View" explainer page, which was expressly not what I was looking for. This scrolling object automatically moves with the page scroll, and is hard to select an image to view.

It is very boring to talk in detail about coding specifics, so I am just going to briefly go through all the methods I tried that DIDN'T work. 

I believed that in order to retain the structure that Scalar uses for its annotations, which I wanted to retain for their value, I would have to retain a tag called the MediaContainer. 

This is a custom tag put in place by the people who designed Scalar. It's the name of that object, and theoretically I could then arrange those objects into a slideshow and retain all the innards that make the object whole.

 I wrote this code, based on another slideshow I had implemented in a personal website I created, meant to collect the Media Containers and make them automatically flip by, like an animated .GIF (I would add the clickable navigation function later):



It returned a bunch of errors and basically broke Scalar. Whoops!

Basically, I did a lot of trial and error with that code and couldn't get it to work. I went back and read the documentation some more, and couldn't find anything that was causing my problem in the actual code that I wrote.

I reached out to my brother, who suggested I simplify my process and use jQuery instead, my skills in which are even more basic than those in Javascript. But jQuery requires that you simplify your pages as well I wrote this code based on some code I stole from a web site my brother made for my boyfriend, which had a slideshow functionality that was appropriate:


My brother also said that even though I was trying to get the entire mediaContainer, I should try and start with gathering the images. Once I knew I was manipulating one element, I could figure out how to get everything in the picture.

When I implemented this code, the site changed. I had a slideshow, but I also had these weird image errors coming up, like so:



I yanked the code and refreshed. Because of the way I was operating on the images in jQuery, I had placed all the images on the page without any classes in their links. I removed the code so I could work on it easier. When I refreshed, I got the slideshow you see above. I was a little angry!

Conclusion


This experience of working really hard to fail at figuring out something that already existed, is very common within programing. It's a little difficult to analyze and extrapolate from, but here are some things I've learned from the experience.

1) Documentation is essential, and it must be both simple and comprehensive.

If I'd understood what the Scalar documentation was trying to explain to me, I wouldn't have been in this pickle in the first place. Of course, this is definitely, partially, my fault – I should have investigated further – but I am only human, and so are most others who are trying to learn to use new tools to make their own digital humanities web sites. There is a reasonable expectation that any platform, when documenting itself, should present a reasonable explanation of what it does.

Self-documentation is a difficult process, but perhaps chronicles like mine (or maybe slightly cooler ones) where people actually try to implement the tools, not simply dry explanations or even demonstrative screenshots, are a useful idea. When people read this sort of article, it will give them a good idea of how Scalar is built, and also how it is NOT built, which is sometimes just as useful for developers.

2) Every Digital Humanities CMS needs a preview function

In code-based online tools, like, for instance the Javascript/Jquery testing platform JSFiddle, it is commonplace to use a split-screen preview. Your changes are updated instantly, without the odious process of having to select "Save" and then "Edit" in order to preview a round of changes.

Here's an example of JSFiddle's simple interface, with the code that I built to make this slideshow: 


It may seem like a small aspect, but being able to see the changes you are making in real-time makes custom-coding a much quicker process. This functionality exists in the main text editing field of Scalar: you can flip from the HTML tab to the Visual Tab and back, but those panes don't show updates in code or style. This is also an issue in Wordpress and other common CMSs, and it seems like a fairly easy change to implement.

Comment on this page
 

Discussion of "Tailoring Scalar For Beginners"

Add your voice to this discussion.

Checking your signed in status ...

Previous page on path Experimental Digital Archives Lab, page 3 of 3 Path end, continue