Since the last article, I have been populating my hypertext with more artists and their paintings, ready to start joining them up with links.
I am also very grateful to Mark Anderson for making some suggestions to improve what I did last time.
1. The name of the container for prototypes
Mark points out that Tinderbox defaults to a container named
Prototypes, with a capital P, and recommends following this convention for compatibility. So I have changed the name of my container.
2. Making writing spaces which are added to the Prototypes container prototypes by default
It is sometimes easy to forget to enable the flag to make a writing space a prototype. Mark suggests a neat way to prevent that: add an
OnAdd action to the
Prototypes container which sets the
$IsPrototype flag to true:
which is an excellent solution. Indeed, it is a valuable technique for other situations where all the writing spaces in a container need to have a common attribute setting like that.
3. $TextFontSize and inheritance
Mark has reported a bug in Tinderbox, which does appear to apply to Storyspace 3.0.1 (b004), whereby adding text to a writing space which has a non-default setting for
$TextFontSize (inherited from a prototype) will result in the text font size being reset to the default, not that set in the prototype. Hopefully this will be fixed shortly.
In the meantime, Mark recommends selecting all Text in an affected writing space, and using the Standard Size command in the Style section of the Format menu, which should ensure that the correct size is applied.
However, he points out that font face and size settings are fixed in the Rich Text typed into the text box of each writing space, and changing
$TextFontSize afterwards will not change pre-existing text which has already been ‘crystallised’ as it were.
4. Rules or edicts?
Mark recommends that the scripts used are placed as edicts rather than rules, as they are more efficient for this sort of situation. This is because edicts are run when first entered, and about once an hour thereafter, imposing less overhead than a rule. Rules are more appropriate where such updating needs to be more frequent, and where you need to force an update at any time. This makes edicts scale much better, whereas rules can start imposing significant runtime overhead.
The slight snag with using edicts is that they are not run when you have just edited a writing space. To see changes take effect, you will need to save the writing space, close it, and open it again: the edicts will then be run, and content updated. This is no big deal once you realise what is happening.
I have therefore changed the scripts from rules to edicts, in my prototypes.
5. To hide the main map or not?
This is more of an open question, in which there are pros and cons each way. Mark suggests putting the current top-level chain of writing spaces inside a root container, so that its features are hidden away rather than exposed. For the moment I think that giving the reader open access to the top level is advantageous, as it allows them to choose where to start or resume, and gives ready access for the currently unlinked
References & Further Reading. However I will revisit this when the hypertext is nearer completion.
I have laid out the top-level Map view rather better, with more in the
start writing space now, to welcome the reader. I will need to add simple navigation instructions before this is complete.
start space takes you to a short Introduction as before, and on to the main container for the hypertext,
The First Impressionist Exhibition. Here I have listed all the participants, and am linking their names using text links through to their individual container within.
The individual artist’s container has at the top one or more text links to their biography within that container, then a short summary of their importance to the Impressionist movement, and a list of all the paintings and other works included within the container. This is then linked back to its container,
The First Impressionist Exhibition. So the reader will by default be taken back to the list of participants, once they have finished browsing this individual artist.
Following the text link to the first biography enters the artist’s container, which is one of the most beautiful views that I have seen in an application: the example paintings are tiled here as adornments using the
painting prototype. One disadvantage is that, as adornments (created simply by copying and pasting a thumbnail image of the painting onto the Map view) they cannot have links. However the reader can click on the paintings which they wish to see in detail, and they will be opened at full size in Preview, and the citation details of the painting are then shown in the text.
There is one odd quirk with this at present, that the individual adornments cannot be locked; locking them in place makes it unlikely that they will remain fully selected when clicked on in Read mode, so that the details of the painting are not displayed. This may be addressed in a future revision of Storyspace. In any case, I rather like the idea that the reader can rearrange these painting thumbnails.
I have also wondered whether to remove the badge from the prototype for paintings. However it does distinguish between those for paintings and other forms, such as sculpture, so for the moment I am going to leave it in place, but may revise that later.
If I could have linked the paintings (if they were normal writing spaces rather than adornments), then I would have made text links from references in the biography. Although that sounds attractive, I think it would have resulted in a large number of links which would do little more than the reader can achieve by simply clicking on the thumbnail of a painting in the Map view.
The default link out from
The First Impressionist Exhibition then takes the reader on to
The Outcome, and so towards the end.
Overall I like this: it is clean, uncomplicated, and unlikely to take the reader to unwanted places. I am pondering whether it might also be useful to provide a rule-based linkless browsing system within the paintings, but I suspect most readers will much prefer to click on those which they want to see properly.
I am also pleased with the size of the Storyspace 3 document at present, which is only 6 MB, to which must be added the 20 MB of full-sized images. The end result looks as if it is going to be sufficiently compact for easy electronic distribution.
Your comments are, as ever, very welcome, as I continue to add more artists and images to bring the document up to its full size.