[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Β 

Comments

  • Eli Evans (Logos)
    Eli Evans (Logos) Member, Logos Employee Posts: 1,404

    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
    Dave Hooton MVP Posts: 35,770

    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.

    Dave
    ===

    Windows 11 & Android 13

  • Lawrence Rafferty
    Lawrence Rafferty Member, Logos Employee Posts: 243

    β€œ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
    Dave Hooton MVP Posts: 35,770

    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).

    Dave
    ===

    Windows 11 & Android 13

  • Reuben Helmuth
    Reuben Helmuth MVP Posts: 2,485

    Eli Evans said:

    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)
    Eli Evans (Logos) Member, Logos Employee Posts: 1,404

    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. [:)]

    Reuben Helmuth said: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
    Reuben Helmuth MVP Posts: 2,485

    Eli Evans said:

    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.

    Eli Evans said:

    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.πŸ˜ƒπŸ˜‡

  • Eli Evans (Logos)
    Eli Evans (Logos) Member, Logos Employee Posts: 1,404

    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.

    That's the number we settled on, too. (Here's hoping for the best!)

    BTW, thanks for taking my pokes in stride.πŸ˜ƒπŸ˜‡

    You, too. A sense of humor is essential!

  • Reuben Helmuth
    Reuben Helmuth MVP Posts: 2,485

    Eli Evans said:

    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?

  • MJ. Smith
    MJ. Smith MVP Posts: 53,409

    Eli Evans said:

    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?

    Reuben there's this word that is critical in programming - patience. It's right up there with the phrase "don't assume". More releases have been tanked thanks to a 5 minutes patch that doesn't need thorough testing 'cause it doesn't effect anything. So hang back and encourage Faithlife to stick to a disciplined approach that gives us stable results. 'sides my missing liturgical date in the Sermons Section is more important. [:P] Just teasing [:D]

    Orthodox Bishop Alfeyev: "To be a theologian means to have experience of a personal encounter with God through prayer and worship.";Β Orthodox proverb: "We know where the Church is, we do not know where it is not."

  • Eli Evans (Logos)
    Eli Evans (Logos) Member, Logos Employee Posts: 1,404

    I checked the source control system and this change was committed to the central code base on the 22nd, along with 21 other commits from Lawrence that day, most of which were not five minute jobs. [:)] The code cut-off for a release is normally the Thursday before (Jun 18 for RC1, tomorrow for 6.4 Stable), which means the soonest it could possibly release is the stable release.Β 

    The main reason we waited was to give anyone else a chance to object to reducing the content in that section. Nobody did.

    The parameters we landed on were the next 5 footnotes within the next 500 characters. This means that in densely populated areas such as Bibles, we'll get no more than 5 footnotes, and in sparsely populated areas such as commentaries, we won't go hunting ahead any more than the length of this paragraph to find more footnotes. 500 characters should include every Bible verse regardless of formatting, which addresses the OP's complaint. As such, the results should now be more predictable and even.Β 

    To MJ's point: Steady as she goes.

  • Angela Murashov
    Angela Murashov Member Posts: 1,532

    Eli Evans said:

    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
    Dave Hooton MVP Posts: 35,770

    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"

    Dave
    ===

    Windows 11 & Android 13