PunchList

From Digital Scholarship Group
Jump to navigation Jump to search

Remaining tasks, bugs, etc. on Women Writers Online redesign

Bugs and urgent loose ends

Interface:

  • Add genre facets [Fixed by Syd, 2012-03-02]
  • Fix/expand context-sensitive searching in Advanced Search
  • Reinstate page breaks in reading view
  • Add page-level URIs
  • Need a way to clear a search, return to the full list of texts
    • Actually, clicking the "x" next to the search term (under the search box) should clear the current search -- is that not working? Granted, that may not be the most obvious or intuitive way of handling things, so I'd welcome suggestions for improving it. (JM, 2012-03-02)
  • Add link to document metadata
  • Make Help and About links active
  • Relevance sorting behavior is odd: doesn't seem to sort by number of matches (try "wit love" in full text) 
    • As far as I can tell, XTF's "relevance" algorithm involves more than just looking at which text has the most hits -- but Syd will have a better idea of what actually governs that behavior and whether it can be tweaked (JM, 2012-03-03)
    • Indeed. Relevance is calculated by
      • If a term appears many times in a field or chunk of a document, the match will rank higher; if it only appears a few times, the match will rank lower.
      • Rare terms are given more weight than common terms.
      • Any field or section of text in the document can be boosted at index time; hits in boosted sections will rank higher.
      • For AND and NEAR queries, more exact matches will rank higher than sloppy matches. That is, a hit where the terms appear in order without intervening words will rank higher than an out-of-order match with many other words interspersed.
      • Matches in short fields are ranked higher than those in long fields.
      • In an OR query, hits that match many of the terms will rank higher than those that only match a few.
    • See the XTF documentation for details. I'm not sure that we have much control over this, but can look into it if you want.
  • The hit link in the results list doesn't always correspond to the hit in the full text view (try a search for "fool" and then look at some of the Cavendish texts -- the anchor named "hit1" in the full text doesn't match the hit in the results list)
  • Representation of italics isn't happening consistently. I've looked at a few samples, and there are some texts where <mcr> and <emph> are being acted upon (e.g. by generating italics) and others where they are not. I think three things are happening:
  1. renditional defaults are not being acted upon (so defaulted information isn't being propagated to the display--and I note that this is also the case in the old interface, which I hadn't realized!)
  2. <mcr> is never being acted upon, even when italics are expressed explicitly in @rend (see e.g. behn.poems-love.xml)
  3. in some texts, no renditional default exists for <mcr> and no @rend is present either (see e.g. cary-e.edoct.xml)


  • We need to take a look at the treatment of small caps and all caps in title pages and headings; this may turn out to be a transcriptional issue. Because we're displaying the text as transcribed, if the encoder used lower-case (trusting that caps or small caps would be generated on output) the display shows lower-case, which looks very odd. See for instance adams.newengland.xml, subtitle "from the first settlement to the acceptance of the" (better as title case). I know I had seen more examples of this but I can't find them at the moment.
  • Minor thing, a weird character (like a visualization of a non-breaking space) before "do." in the subscriber list to Lickbarrow's Poetical effusions


Features to Add

Interface:

  • Need a way to tell what text you're in (in the Reading pane)
    • Partially resolved: I've added a brief snippet from the title in the full text viewer's menu area (the first 16 characters or so, since that's all that fits comfortably in that space at the moment). I've got some ideas about how to display the full title there (author would be useful too--JF), but it will probably have to wait until after we've launched (JM, 2012-03-03)
  • Add buttons for navigating to top/bottom of pane
  • There's general support for the idea that we need a "reading-only" view (so the "Reader" will be very welcome if/when we can provide it, and if that's a long way off, we should make sure to mention that it's on the agenda so that people can be patient)