An XForms case study, part 1 (look and feel)

[16 January 2012]

In a previous post, I mentioned the evaluation forms we put together for the Balisage conference last year, using XForms. This is the first of a series of posts discussing some aspects of the design and development in more detail.

One of the first requirements for these forms was that if at all possible they should have the same look and feel as the pages on the main conference site. In XForms, this turns out to be remarkably simple: XForms is designed to be styled using whatever styling mechanisms are usual for the host document vocabulary. In the case of XForms in XHTML, running in a Web browser, that means the form can be styled using CSS. And because the form is embedded in a normal XHTML document, any necessary logos or graphic apparatus can be embedded in the normal way.

The forms pointed to http://balisage.blackmesatech.com/ do three things to maintain the Balisage look and feel:

  • They point to an appropriate CSS stylesheet, in the usual way.

    <html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:xf="http://www.w3.org/2002/xforms"
    xmlns:xhtml="http://www.w3.org/1999/xhtml"
    xhtml:dummy="Help the poor user of Mozilla
    evade the Mozilla namespace curse"
    ...
    >
    <head>
    <title>Balisage Speaker/Presentation Feedback</title>
    
    ...
    
    <link href="lib/feedback.css" rel="stylesheet" />
    
    ...
    

    [The xhtml:dummy attribute is a work-around that helps XSLTForms compensate for the bug in Mozilla’s XSLT implementation: Mozilla does not support the XPath namespace axis, so the only way XSLTForms can discover what namespaces are in scope is to walk around the tree collecting namespace bindings from elements and attributes in the document. The value of the attribute doesn’t matter; I use a value that reminds me of why I have to have the attribute there in the first place.]

  • They use the same overall document structure as the main Balisage pages: three divs of class header, mainbody, and footer, respectively,
    with the second in turn divided into navbar and body.

    <body>
    
    <div class="header">
    ...
    </div>
    
    <div class="mainbody">
    <div class="navbar">
    ...
    </div>
    
    <div class="body">
    ...
    </div>
    </div>
    
    <div class="footer">
    <hr />
    <p>Last revised 26 July 2011.
    Copyright &#169; 2011 <a
    href="http://www.blackmesatech.com/">Black Mesa
    Technologies LLC</a>.
    <a rel="license"
    href="http://creativecommons.org/licenses/by-sa/3.0/">
    <img alt="Creative Commons License"
    style="border-width:0"
    src="http://i.creativecommons.org/l/by-sa/3.0/88x31.png"
    /></a>
    <br/>
    The <span xmlns:dct="http://purl.org/dc/terms/"
    href="http://purl.org/dc/dcmitype/InteractiveResource"
    property="dct:title"
    rel="dct:type">Balisage 2011
    Feedback Forms</span>
    by <a xmlns:cc="http://creativecommons.org/ns#"
    href="http://balisage.blackmesatech.com/2011/feedback/"
    property="cc:attributionName"
    rel="cc:attributionURL">Black Mesa Technologies
    LLC</a>
    are licensed under a
    <a rel="license"
    href="http://creativecommons.org/licenses/by-sa/3.0/"
    >Creative Commons Attribution-ShareAlike 3.0
    Unported License</a>.</p>
    </div>
    
    </body>

    [Note: strictly speaking, as those who go and look at the HTML coding of the main Balisage site will discover, this is not “the same overall document structure” as the main Balisage pages. For reasons I won’t go into here, the main Balisage site uses XHTML tables to lay out the pages. I usually try to avoid tables, so the forms use div elements with CSS style rules to govern the layout. Apart from avoiding invidious comments from those who disapprove of using tables for layout purposes, I find the documents somewhat easier to navigate and edit this way.]

  • They embed the appropriate material. The header embeds the Balisage logo:

    <div class="header">
    <a href="http://www.balisage.net/">
    <img src="bflib/Balisage-2011-logoType.png"
    width="35%"
    alt="Balisage 2011 logo"/>
    </a>
    </div>

    And the navbar embeds a suitable set of links.

    <div class="navbar">
    <p class="upbutton">
    <a href="http://www.balisage.net/">Balisage 2011</a>
    </p>
    <p class="upbutton">
    <a href="../../">Balisage at Black Mesa Technologies</a>
    </p>
    <p class="downbutton">
    <a href="http://www.balisage.net/2011/Program.html">Program</a>
    </p>
    <p class="downbutton">
    <a href="index.xml">Balisage 2011 Feedback Forms</a>
    </p>
    <p class="downbutton">
    <a href="conference.xhtml">Conference Feedback</a>
    </p>
    <p class="downbutton">
    <a href="symposium.xhtml">Symposium Feedback</a>
    </p>
    <p class="downbutton">
    <a href="speaker.xhtml">Speaker Feedback</a>
    </p>
    </div>

It turns out to be psychologically helpful to have the form appropriately styled, both for me in developing it and for those whom I ask to review draft versions of the form. It’s so helpful, in fact, that one of the first things I do, in developing a form for a particular site, is to create an XForms template for the site, with

  • the namespace declarations for XHTML, XForms, XML Events, XSD, and any other namespaces that may be needed (extra namespace declarations cause no trouble, and missing ones cause a lot);
  • a link to the standard site stylesheet, or (if the standard site stylesheet uses tables) an equivalent stylesheet that provides the correct look
  • the high-level document structure needed by the site stylesheet
  • dummy headings and body text, using Greeking (‘lorem ipsum …’)

XForms is designed to allow forms to be integrated nicely into a site’s normal look and feel; the template makes it easier to do that consistently across all the forms used on a given site.

Another example of XForms

[9 January 2012]

In recent years I’ve spent a fair amount of time telling people about XForms as a method for making special-purpose XML editors. From time to time people ask me what sorts of things it’s possible to do in XForms, and by implication what sorts of things don’t fit very well in XForms. It’s a good question, but I don’t know a good way to answer in words. The only way I know to answer is to show some examples of things done in XForms.

In that connection, perhaps it’s worth while to point to an XForms application I put together last year for Balisage 2011. The organizers of Balisage place great weight on feedback from participants, and we’ve always used paper feedback forms distributed to participants on the last day of the conference. Paper forms have the drawback of only being in one place at any given time, and since the organizers don’t all work in the same location, most of the organizers only got a chance to look at the feedback forms on the afternoon after the conference ended, before everyone went home. (Yes, we could have had them photocopied, but we never got around to it.) So last year I suggested we do electronic forms, in addition to the paper forms (which we entered into the electronic system by hand, afterwards).

The forms we ended up with (all pointed to from http://balisage.blackmesatech.com/) illustrate one kind of application it’s easy to do in XForms. To answer, up front, a frequently asked question: no, they don’t do anything you couldn’t do in Javascript or HTML Forms plus a little bit of Javascript. (Javascript is a Turing-complete language; how could any technology do anything that could not, in principle, be done in Javascript? Asking if XForms can do things you couldn’t do in Javascript is like asking whether the XForms spec contains a refutation of Gödel’s Theorem.) Doing them in XForms made these forms easier to develop and debug, and XForms provide XML output, which means the forms are easier to summarize and analyse than they would otherwise be. I have written conventional HTML forms interfaces to generate XML, so I know it’s possible. I also know it’s tedious; XForms is much much more convenient.

These feedback forms posed a few interesting design challenges, and I went through several iterations, bugging my colleagues on the organizing committee for feedback until I suspect most of them were heartily sick of the whole thing. The various alternatives are worth some discussion; in subsequent posts I’ll discuss the issues and some of the alternative ways of handling them in XForms.

Pierazzo on digital diplomatic editions

[2 January 2012]

A new issue of Literary and Linguistic Computing arrived not long ago. I’ve been meaning to note that it contains an article I hope will become standard reading for anyone involved with the digitization of texts and manuscripts: Elena Pierazzo’s thoughtful essay under the title “A rationale of digital documentary editions”. (LLC 26.4 (Dec 2011): 463-477.)

Dr. Pierazzo is a member of the team responsible for the Jane Austen’s Fiction Manuscripts Digital Edition and she has used her experience with that edition to reconsider the question are digital editions different from printed ones? … Do they represent an advancement of textual scholarship or just a translation of the same scholarship into a new medium? My own inclination is almost always to stress the continuity of scholarly concerns here as more important than the discontinuities of the technologies pressed into the service of scholarship, but Dr. Pierazzo reaches the different conclusion that digital editions are “substantially different” from print editions. She begins her argument by defining her terms and discussing some central questions (“What is a diplomatic edition?” “What does a diplomatic edition contain?” “Once you start identifying features to encode, where do you stop?”). She takes a firm stand against the view that it’s possible for an edition to encode everything about a source document (so what does an edition contain? A selection of the available information. She concludes her survey of recent thinking about the topic with the remark that

It is only with the advent of digital editions that we have started to understand that what we need is scholarly guidance …, that we need to rethink the reasons why we make our transcriptions, and that this approach should apply to print and digital editions alike.

She then proceeds to make a start on the task she has identified, listing a number of features (or rather, classes of features) which may be recorded, or elided, in a digital edition, and proposing five criteria for deciding whether to include or exclude them:

  • the purpose of the edition
  • the needs of prospective readers
  • the nature of the document
  • the capabilities of the publishing medium
  • cost

In the section on the purpose of the edition, she uses the decisions made by the Austen project to illustrate the kinds of considerations that arise, and devotes a useful couple of paragraphs to “What was not encoded”. As the last two items in her list of criteria suggest, while she argues that we need scholarly guidance about what information about a manuscript can usefully be recorded, she also takes a pragmatic view of the limitations imposed on any project by finite resources. The essay is, in the nature of things, overtly concerned only with text-bearing objects like manuscripts. But many of the concerns addressed will bear also on other forms of cultural artefact.

A wonderful piece; no one engaged in digitization of cultural heritage materials should miss it.