Handling Footnotes

As we contemplate expanding the supported Gospel Library document set (which will involve database schema updates), I think we also need to contemplate our footnotes model (which likewise needs schema updates).

The current approach having lists of footnote items, each potentially with a hyperlink to its associated content, works for the vast majority of cases. However, there are situations where it falls short:

• Some hyperlinks have connecting text (pre or post href)
• Some footnotes are not attached to verses (JST gives different titles to the four gospels, for example -- we don't have these in our database)
• In some cases it's nice for the reader to be able to see all of a verse's or chapter's footnotes together (multiple IE, HEB, GR, OR explanations in a single verse or chapter, or readers need to look through the footnotes for something they vaguely remember but can't quite find)

I recommend we consider an alternative footnote mechanism that works more like the printed text. The iPhone project uses a window at the bottom that auto-scrolls along with the chapter. The panel has a default height, but the user can adjust its height by dragging the separator bar. All footnote material for a chapter is displayed together.

Thoughts?

I advocate investigating the iPhonish approach in the next major release.

I personally find the iPhone approach way too cluttered/cramped.

The WebOS project inlines the footnotes when a user taps on a footnote link. I believe they display vertical red bars on either side of the verse, and footnotes are shown directly below the verse.

I don't know what the most usable solution is, but we have to do something if we're going to faithfully reproduce all the details of the footnotes.

Not having an iPhone, I'm not sure what the issue is. Revel on Android uses the mature Yanceybooks file format. Footnotes appears much like it does in the printed scriptures - with a hyperlinked (blue underlined) superscript letter. Tapping the hyperlink brings up the footnote as a small overlay window which may or may not contain more hyperlinks.

A tap of the "back" button (part of the Android user interface) backs out of the footnote.

RussellHltn wrote:Not having an iPhone, I'm not sure what the issue is. Revel on Android uses the mature Yanceybooks file format. Footnotes appears much like it does in the printed scriptures - with a hyperlinked (blue underlined) superscript letter. Tapping the hyperlink brings up the footnote as a small overlay window which may or may not contain more hyperlinks.

A tap of the "back" button (part of the Android user interface) backs out of the footnote.

The current approach parses each footnote into a list of footnote entries, and then displays that list Reveal-style as a dialog box above the chapter text. For each entry in the list, if it has a hyperlink, the corresponding list item is clickable to navigate to the link target (Reveal style). As I mentioned in the first post, the problems are three-fold, and they're marginal (the current approach works most of the time):

1. The current approach throws away some connective text between scripture-reference hyperlinks. Often this is just punctuation such as semicolons or commas, but sometimes it includes words too.
2. The current approach attaches footnotes to verses, but not all footnotes are attached to verses (out of the thousands of footnotes, only half a dozen are not attached to verses).
3. There is no way to browse the footnotes the way you can browse them in the printed scriptures -- as a group.

The footnotes have been written as if they would generally be displayed in sentence-style lists. So there is sometimes connective text and pre-/post-footnote text that helps it read like a sentence. A good example is Gen. 1:1c:

c HEB shaped, fashioned, created; always divine activity; see Abr. 4:1, organized, formed. TG Creation; God, Creator.

We currently display this as the following list:

• HEB shaped, fashioned, created; always divine activity; see
• Abr. 4:1
• TG Creation
• God, Creator

Close, and indeed structurally correct (the last three items link to the appropriate targets), but missing some of the finer details of the footnote (it's not clear that the list is Gen. 1:1c; it's not immediately clear that "God, Creator" is a TG link; some of the connective text is missing, including words and punctuation; and the surrounding footnote context is not visible -- you have to go back and tap on the other footnotes to view them).

A few possible solutions:

1. Improve the footnote parser so it doesn't throw away connective text (including punctuation) and is smarter about where to break list items (e.g., putting "see" with "Abr. 4:1" and keeping ", organized, formed." in the example above). Also would require changes to handle footnotes not attached to verses. This only solves some of the problems.
2. Use either the iPhone or WebOS approach to display footnotes in sentence style, inlined with chapter text or in a separate panel below the chapter text. (BTW, see the iPhone project screencast for an example of how it works.)
3. Display footnotes in sentence style rather than list style, but still in a floating dialog box above the chapter text. Links would be underlined web-style, rather than being broken out into a vertical list of selectable items. The user could scroll the window to see all footnotes for the chapter.

I mostly like solution 3. But what would we lose if the only contents of the popup were the footnotes for the verse that contained the footnote link that was tapped? The footnote text that isn't attached to a verse? What is an example of such footnote text that isn't associated with a verse?

jackcholt wrote:I mostly like solution 3. But what would we lose if the only contents of the popup were the footnotes for the verse that contained the footnote link that was tapped? The footnote text that isn't attached to a verse? What is an example of such footnote text that isn't associated with a verse?

The five footnotes that aren't attached to verses include the JST title changes for the four gospels and Song of Solomon.

There are also a few "noteMarker" elements in the D&C chronological order of contents and JS--History that are footnote-like, but the referenced notes are inlined with the chapter text. We only process "studyNotes" elements as footnotes stored in the refs table.

If I'm not mistaken #1 is about how we extract the data from the XML and store it in the db, and #2 & #3 is about how we present the data and actually require that we do at least part of #1. Of the presentation options, I much prefer #3.

However, I also lean towards thinking that the current approach, while not perfect, may be good enough - it certainly is for how I use the app, which is only to avoid having to carry around my scriptures on Sunday - though I can see how it might not be good enough for those who want to use the app to do serious scripture study.

svella wrote:If I'm not mistaken #1 is about how we extract the data from the XML and store it in the db, and #2 & #3 is about how we present the data and actually require that we do at least part of #1. Of the presentation options, I much prefer #3.

However, I also lean towards thinking that the current approach, while not perfect, may be good enough - it certainly is for how I use the app, which is only to avoid having to carry around my scriptures on Sunday - though I can see how it might not be good enough for those who want to use the app to do serious scripture study.

Yes, we'll need to do some XML/DB work no matter which option we choose. #1 is the current approach, just with XML/DB fixes. (BTW, I suspect it will be difficult to do #1 right because there's so much variety in how the connective text shows up in different footnotes -- but I could be wrong.)

Since this will be the official LDS version of the scriptures for Android (when the app is approved), we have a high bar to meet. That's why I'm pushing for us to polish this part more.

Here's what I suggest then. Let me work on the XML/DB situation. I think I'll create a new table that contains an HTML representation of each chapter's footnotes. There will be anchors that allow scrolling to each footnote letter. Hyperlinks will be embedded in the footnote HTML where appropriate. When that's ready, we can experiment with a floating web view for footnotes, or the iPhone approach if somebody wants to try that out. If we don't arrive at a superior solution, we don't change the app (or at best we make it a user-selectable preference). Let's treat it as an experiment with the burden of proof on any replacement scheme.

Our interface should remain straightforward -- I think we all dislike apps that try to do too much at once; complex = confusing.

I'm not entirety sure I should post this here, but it seems to be an appropriate place.

As I was using the program today to look at some Conference talks, I was a bit disappointed that I was unable to follow scripture links within the talk. I could click on the link, but there was no further action.

In another talk, the author had used footnotes instead of references within the text itself. This was even more frustrating than the non-functional links in the previous example. The footnote numbering was integrated into the text as regular, full-sized type, with no actual notes at the end of the text.

I would love to see the in-text scripture references clickable and fully functional, taking me outside of the talk and to the referenced text. Also, in talks that utilize footnotes, having an overlay system like that currently used with the scriptures portion of the program would be great. The current implementation of simply having the numbers in there, not even super-scripted, is unattractive and without purpose.