No matter how much work you put into them, blogs are inevitably ephemeral, and it is a brave blogger who tries to build complex structure into them. Having just completed writing a series of articles on the history of oil painting, I realise that there is no particularly useful account available elsewhere (please correct me if I am wrong) – a void which is worth trying to fill.
Like most histories, this contains many threads, which interlink in complex ways. There are quite different readings available: Vasari, in his book describing the lives of artists, made many statements which assemble into what is the closest that we have to a contemporary account. But research since has shown that his account has many errors, and needs to be carefully interpreted. Others since Vasari have made bold claims about the materials and techniques used by Old Masters, which have subsequently been refuted by physical and chemical analysis of their paintings, but which explain some of the materials and techniques used by later artists such as Sir Joshua Reynolds.
This series of articles follows my project of turning the linear series of articles published here using WordPress, into what I intend to be a full-blown hypertext to be read using the new Storyspace Reader.
I compose my blog articles in Red Sweater’s MarsEdit, although I only use it to manage the HTML content. So my starting assets are the HTML source for all thirteen articles in the series, together with JPEG images of the paintings used to illustrate them.
MarsEdit is a wonderful environment for blogging, and has its own media management even though I choose not to use it. But it is not particularly helpful when it comes to exporting your content to anything else. Its only real feature to support that is to open that article using the text/HTML editor of your choice: in my case, the all-powerful BBEdit.
So my first task was to select each of the thirteen articles in turn, open them as HTML source in BBEdit, then save them from there into my working folder. It’s quick and simple, but I don’t understand why MarsEdit cannot export articles directly as HTML files.
Although it is technically HTML, my WordPress article source usually contains very little markup. Rather than waste time stripping out that markup, I decided to leave it where it was. This means that I will have to remove it when I paste it into writing spaces, but least I will then know which phrases to set in Italics, for example.
I prepare images with captions, which are embedded in the article source, and a good size and quality JPEG which is normally larger than 1000 x 1000 pixels, and compressed at 80% quality. In previous articles I have explored several ways to use those images in Storyspace hypertext, including putting those same images, unaltered, into a single folder and opening them from Storyspace using Preview. That is easy to do in Storyspace, but it also takes those images out of context. For this sort of history, context is all-important, so I want to keep my images in writing spaces.
Doing so comes at a cost: the hypertext document is going to be quite large, so I need to optimise image size and use. Most, perhaps all, of the images will be used in more than one place, so rather than embed two copies of the image, I want to use more efficient means. I also don’t want to overburden the reader with large images where smaller ones will work as well.
So I decided to have each image embedded in two writing spaces, one at a maximum dimension of 512 pixels, the other at 1024 pixels. They should enable acceptable quality and detail, but a fair compromise on the space required. I use GraphicConverter for this type of quick image processing, as it is far more efficient than more elaborate image editors.
Working with an assortment of free-to-use images (mainly the vast and invaluable Wikimedia Commons), one of the most important steps is to ensure that they are all set to a common resolution, for which I arbitrarily use the old display standard of 72 dpi. When I download them, they range from 10 to 300 dpi, although that normally makes no difference when rendered by a web browser. If you don’t set all the resolutions to a common value, you can find that embedded images, added by drag-and-drop from the Finder into a writing space, vary widely in size.
The other task is, of course, to generate the two sets of images scaled at different sizes, and kept in separate folders.
I now have all the ingredients I require to start building my hypertext in Storyspace, although later I’ll be adding others such as translated sections from Vasari, for example. If you are unsure as to how to perform any of the steps which I mention here, you’ll find links to all my other tutorials on Storyspace in this index (which opens in a new tab, so that you don’t lose your place here).
As is traditional, I am going to start building this hypertext backwards, using the last article in the series (13, to appear here next week) as the spine, as it puts together the historical narrative that is (my version of) the history of painting in oils.
Before I add any writing spaces to make up that spine, I define some prototypes – which will inevitably evolve during the project – which I can use for my first writing spaces. I am going to try to be well-behaved and follow good style as much as possible, so I first create a writing space to act as a container for those prototypes, named Prototypes (with a capital P, which is the convention used in Tinderbox). I also follow Mark Anderson’s wise counsel, and make the $OnAdd attribute a key for the Prototypes container, adding the script
$IsPrototype=true
This ensures that, should I forget to make a writing space a prototype before I add it to that container, that $OnAdd script will automatically make it so.
The three prototypes which I want to start off with are for smaller images of paintings, large ones, and milestones in history. Each will have two key attributes: $StartDate and $EndDate, which are essential if they are going to appear on a timeline. I make those key attributes by clicking on the + tool at the top right, and selecting each in the Events attributes as shown.
I make each of these a prototype, using the Inspector, change their colours, and by clicking in the top right-hand corner of each tile, I give them an appropriate badge. As you can see from the breadcrumb bar above, these prototypes are all safely tucked away in the Prototypes container.
I am now ready to try out those prototypes, and add my first writing spaces to the document. The initial milestone, matching my article, only contains text, so I create it, name it Drying Oils, enter the dates covered, and copy and paste the text from my article.
Sadly, because the dates in this hypertext are all long in the past, I cannot use the natty new calendar tool for entering dates, but just type them in as previously.
My next milestone requires a painting, so I create first its smaller image version, using the PaintingSmall prototype, and drag and drop the image into that, followed by its caption.
All the paintings are to be put in another container named Gallery, which will later serve as a browsable gallery of those images, as well as keeping them out of the way of the main structural writing spaces. Here is the PaintingLarge version of that same image, with a similar but slightly smaller caption at its foot. I have also linked the small and large versions together, using a text link from the smaller image, so that the reader can click on that image to be presented with the larger image; the link back to the smaller is a normal link for simplicity. I will revisit this later in the series.
In the next article I will look at ways of using those images in the milestones which form the spine of the hypertext.
Happy hypertexting!
