Expanded the section on graphics in linking.xml with more details and examples.
February 27, 2014
February 26, 2014
My apparently simple task to "Ban <lb> in <figure>. Nobody needs it, and using it breaks things" turned out not to be so simple.
I found myself wrestling with some strange markup eccentricities caused by efforts to make pictures and their captions display in particular ways. This is another of those instances in which we've resorted to bending the usage of tags to get around problems with display which are actually easier to solve in the XSLT and CSS.
There were lots of instances of <figure> containing <lb/>, and <head> inside <figure> containing <lb/>, all in an effort to make the caption below the picture wrap to the width of the picture. That's of course doomed to failure because you can't predict the text size on the browser. What I've done instead is this:
<figure>can contain only<graphic>and<figDesc>.<figDesc>is the caption for the<graphic>.-
Neither
<figure>nor<figDesc>are allowed to have<lb>inside them. - Instead, when
<figure>is rendered, it's turned into a<figcaption>element in HTML5, and the<figcaption>element is constrained to be the same width as the graphic it appears below. So the effect is nice and simple.
I've gone through every <figure> and simplified all the code. All the pages display things the way they used to, but the code is much simpler.
<lb/>, and <head> inside <figure> containing <lb/>, all in an effort to make the caption below the picture wrap to the width of the picture. That's of course doomed to failure because you can't predict the text size on the browser. What I've done instead is this:
<figure>can contain only<graphic>and<figDesc>.<figDesc>is the caption for the<graphic>.-
Neither
<figure>nor<figDesc>are allowed to have<lb>inside them. - Instead, when
<figDesc>is rendered, it's turned into a<figcaption>element in HTML5, and the<figcaption>element is constrained to be the same width as the graphic it appears below. So the effect is nice and simple.
I've gone through every <figure> and simplified all the code. All the pages display things the way they used to, but the code is much simpler.
Things to do from today's meeting:
- Ban
<lb>in<figure>. Nobody needs it, and using it breaks things. - news.rss is broken -- fix it.
- Add optional @type on
<change>, with (for now) a single value, "publication". This will be used to record the initial publication date of the document, since it may go through various iterations of document status, and because all the various respStmts have a huge variety of dates on them. When all documents have this, add Schematron to enforce its presence when @status="published". - Consider display of a fourth column for Mayoral Show document table showing relatedItems.
- Begin compiling a list of elements on which we would like to use @resp, for another shot at the feature request.
February 14, 2014
I've updated doc.xql so that it detects the condition where there are multiple documents with the same @xml:id and reports a useful error message. I also switched the Creative Commons embedded image in the footer so that it's called with https instead of http, making all the page contents secure when the page is accessed with https; Firefox was showing an error complaining that not all the contents were secure (quite rightly).
February 13, 2014
Straight-to-live changes requested by the team could not be easily done without publishing the whole set of dev changes from the last month to live, so I've done that. They were stable and tested anyway, albeit somewhat incomplete. Mustn't let the dev and live sites get too far out of sync in future, unless I also spin off a temporary copy for testing urgent straight-to-live changes.
I have a first pass at find_place.xql done and working, but there is a lot of extra refinement I need to do. It's a bit tricky to provide the degree of matching fuzziness required but at the same time provide candidate matches in a sensible order.
From yesterday's meeting:
- Decide whether we need to do anything special with relatedItem, or whether it's sufficient to leave that as metadata, and depend on the explicit linking in LINkS1.xml to provide links between critical work and primary source documents.
- Solve the problem of critical materials appearing on the Library menu, but not on the landing page, because the landing page is constructed of only primary source documents through document type. Do we need a master category that embraces mdtPrimarySource and mdtCritical? If so, what to call it?
- In the case of locations which have an abstract, render that before the boilerplate stub text.
- DONE 2014-02-26: In the location files mdt rendering table, in the final column, in place of the existing "contribution needed", output instead "stub" and "empty", both linking to the Contribution page, with a title attribute perhaps with "contribution needed".
- Possible locations for tying Agas to real GIS: intersections (especially of three streets or more), churches, the Tower, the Wall.
- Create a gazetteer page which shows a table of locations (grouped by letter of the alphabet so it's manageable), and include all variant spellings for the place.
- Also include variant spellings in the form of a link at the top of a location page, and a link to the gazetteer entry for that location.
- Look at the Museum of London "Street Museum" mobile app as an example of what we might do.
- DONE 2014-02-14: Trap the error where two copies of the same file are uploaded to different places, and show a useful error message.
February 12, 2014
I'll enumerate the plans and note which ones are complete when I have time tomorrow...
In addition to the robots.txt file I set up the other day, I've explicitly limited Google's crawl rate using their webmaster tools (the Googlebot ignores the Crawl-delay setting in robots.txt). This should help to avoid what I think caused the substantial slow-down the other day.
February 5, 2014
I've been doing some thinking about how to build the planned cellphone app, and also how we can prepare for it. I'm setting up at home to test the Appcelerator, and I've been investigating Delphi XE5 too (expensive but familiar). These are some thoughts:
Abstracts:
I recently implemented the system of using <abstract> to provide a very short popup info box about locations (so that people don't have to jump away to the full location page unless they want to). On a cellphone, the <abstract> is likely to be the only source of info people use about most places -- reading long documents is not really comfortable -- so I think we really need to craft our abstracts so that they not only give basic info about the place (e.g. which direction the street runs, and which streets it connects and intersects) but we should also try to provide at least one intriguing and significant fact about the location, so people feel they're learning something that's not obvious. For instance, for Abchurch Lane, we might include the sentence "In the early seventeenth century, “the lane was renowned for the cakes referred to in John Webster’s Northward Ho (1607) and sold by Mother Wells who had her shop here” (Weinreb and Hibbert 2)," which is not the most important bit of information about the street but does bring it alive a little.
Stow:
NAP and MLH have been assiduously identifying and tagging all the locations mentioned in Stow, but so far I don't think we've given any thought to identifying the specific part of Stow in which he describes a given location (other than a Ward, of course). For instance, 16 mentions of Cheapside are tagged in the 1598 Stow; but is there a passage in which he most particularly addresses Cheapside, and which we might tag and link from the Cheapside location file? I don't know to what extent Stow does this, but if he does, it would be useful to be able to show "What John Stow says about Cheapside" rather than just "all the mentions of Cheapside in Stow".
Location tagging:
I'm increasingly convinced that it will be practical to offer our edited Agas map as the background to geo-navigation -- in other words, that we will be able to show "here you are on the Agas map" in much the same way we can do that on a Google map. The secret to this will be the combination of real-world geo-locations with pixel offsets on Agas. To do this properly, we need to identify as many common known locations as we can on the two maps. The obvious ones are street intersections, but there are others, such as the centres of known buildings, churches etc. We had originally considered doing this in order to geo-rectify Agas -- a procedure which is actually impractical and would yield horrible results -- but I believe we can use a network of common locations in the following way:
- Your cellphone identifies your geo-location
- It identifies the handful of known points nearest to the geo-location on our common Agas/GIS system
- It triangulates these points to calculate your approximate position in pixels on the Agas map
- It shows you as an icon on the Agas map
Obviously, because of the distortions in Agas, this is often going to be wrong to a greater or lesser degree -- you might appear to be in the river or inside a building when you're on the street. But a second level of correction might be applied to move the icon to the nearest plausible location if that were unacceptable. Meanwhile, it can also show you nearby locations which have information we can provide, located precisely on the Agas map. You could switch at any time to a modern map view which would show the same locations. At the kind of zoom level people might use on their cellphones or tablets, the gross distortions that make the Agas and modern maps incompatible would be minimized, so it wouldn't be too jarring to switch between them.
This would require a fair amount of work in locating all the points that can reliably be mapped on both Agas and modern London, but it would have a large payoff. We could also use it to enable easy switching between Agas and Google Maps in the main web interface, and even allow for coordinated panning (drag one map and the other drags too) when viewing them side-by-side.