[ACK] BUG(?) Info panel: footnotes not verse specific.

In the release notes for beta 4 it mentions "Fixed issue that caused the resource links in the Translation section to not be verse specific."

The footnotes section, however, is still not verse specific. When hovering/clicking a word the footnotes appear for anything from that point onward, to the end of the pericope (it does not cross pericope boundaries, thankfully). This behavior is most problematic when "insert reference text" is selected, especially if the footnotes section is not at the bottom! Choosing not to insert text and keeping the section at the bottom is the current best solution, but this should be addressed before the 29th. I've attached a screencast to demonstrate the current behavior.

http://screencast.com/t/KLVuE3Dr

Find more posts tagged with

Comments

Eli Evans (Logos)

Hi, Reuben. The section is doing what it always has since Logos 4.0: It shows footnotes from the current word forward to the end of the paragraph, up to a limit of 50. This algorithm has the virtue of working for both Bibles and non-Bibles. We can consider just ratcheting down the upper limit to something much smaller, say, 5 or 10.

I personally agree that 50 is too much, but because it's been like this for so long and because it's arguably a feature (though I'm not going to argue that) I'm loath to just change it without giving others the opportunity to object. I'll put a case in, and if nobody objects, we'll go ahead and shrink it.

Dave Hooton

It appears not to work as advertised e.g. ESV Lk 2:32 "light" ---> j is shown. To get k & l I have to click on "glory" in the same verse. But j and k are before the word and v.32 is not the end of the pericope (although it might be the end of a paragraph?). vv 33-35 appear to be a paragraph, as with vv. 36-38.

I find that to be confusing and would settle for all footnotes in a bible verse, and a limit of 5 for non-bibles.

Lawrence Rafferty

“Paragraph” is used in the technical sense, which does not correspond to what you expect in this case. j is in the same paragraph as “light”, while k and l are in the following paragraph. They are separate paragraphs because they wrap to a different level of indentation.

Technicalities aside, you have a point about how the experience is inconsistent.

Dave Hooton

Technicalities aside, you have a point about how the experience is inconsistent.

Further, v. 32 appears to be two paragraphs and you only get j from clicking either of the first two words. Depending where you click in the second paragraph you get zero, one or two footnotes (k & l).

Reuben Helmuth

This algorithm has the virtue of working for both Bibles and non-Bibles

Could you please verify in which way you consider this to be working?! 😳😠😡😆

In the Footnotes section settings, I want to have "lookup references" checked so that I can quickly glance at any of the (full) footnotes. With this checked however, and the footnotes section not at the bottom, Info becomes totally frustrating and clunky to the point of unusable. This is especially true when close to the beginning of a long pericope. On the other hand, when reading in poetic sections, only one or two footnotes is common because most verses are divided into multiple "paragraphs." I've made a short screencast to show how impractical the current algorithm is in Bibles. For the sake of argument I moved the footnotes section to the top.

Is it unreasonable to say that Bibles should use an algorithm that goes by verse instead of paragraph?

Eli Evans (Logos)

Could you please verify in which way you consider this to be working?! 😳😠😡😆

Sorry to be unclear. I should have said, "is computationally valid to apply in all cases" instead of "working." Just because an algorithm can be applied to all cases doesn't necessarily mean it generates great results in all cases. When we start talking about engineering, sometimes I revert to talking like an engineer. I think it was pretty clear that I agreed with you that the current results are less than desirable in some cases, but maybe not. Apologies, mea culpa. [:)]

Is it unreasonable to say that Bibles should use an algorithm that goes by verse instead of paragraph?

Not at all. I never mean to imply that it's wrong to want what you want.

It is also reasonable for us to want to stick with an algorithm that does not require special case code for Bibles, if possible. I am deciding between a one-line five minute change (adjust the thresholds of the current algorithm, which is valid for all cases but clearly needs some fine tuning) versus a five hour (which really means two days when all is said and done) change that will require a new algorithm (well, two -- keeping the old one and adding a new one) that introduces special case knowledge of resource types (it's a Bible) and milestones (don't go past the current verse) into an area of the code that previously had no working knowledge of either of those bits of information (because of encapsulation).

I think the most prudent course is to try to tweak the parameters first, and then see if the special case for Bible verses really is necessary -- especially since I want the developer in this case to move on from this particular molehill because I have a mountain for him to climb next. [:)]

Reuben Helmuth

I think the most prudent course is to try to tweak the parameters first, and then see if the special case for Bible verses really is necessary

I'm fine with that for now. I totally understand needing to prioritize! My feeling would be that the max should be no more than 5.

I want the developer in this case to move on from this particular molehill because I have a mountain for him to climb next.

I understand that with the Cantillation interactive to fix, the Morph Charts to fix, the Psalms explorer to fix, adding Manuscript attachment points to notes, etc...it really is a mountain to think of getting all that done before the 29th! 😜😜😆

BTW, thanks for taking my pokes in stride.😃😇

Reuben Helmuth

a one-line five minute change

Apparently five minutes could not yet be spared? 😉 I expected this to "ship" with the next update, but 6.4 RC1 is still the same. Did it perhaps slip through the cracks?

Angela Murashov

I'll put a case in, and if nobody objects, we'll go ahead and shrink it.

This has been fixed in 6.5 Beta 1.

Updated Footnotes section to display the next 5 footnotes within the next 500 characters.

Dave Hooton

Updated Footnotes section to display the next 5 footnotes within the next 500 characters.

Well, it also gives the previous fn if within 2 words - which is fine. It works better than previously with my Lk 2:32 "benchmark"