Footnotes usability issues and fixes

[willbarton]

We've been using wagtail-footnotes at CFPB for a few months now, and it's so much better than our previous approach of... just maintaining footnotes as content. But our content editors have encountered a few usability issues that we'd like to solve, and I'd like to get some guidance on the ways forward, and changes that you all might be willing to accept.

TLDR: We've identified the following UX issues with footnotes and would like to fix them, and have those fixes accepted:

• Footnotes don't preserve insert-order and so the ordering can change on saving drafts. I have a PR open to make Footnote objects Orderable: https://github.com/torchbox/wagtail-footnotes/pull/74
• Wagtail InlinePanel numeration creates additional confusion by adding an index to Footnote objects listed on the edit page that can change with the above issue, and that has no bearing on the footnote's rendered/citation index. I don't really think there's a fix for this.
• Visually scanning for a specific footnote to insert into content in the footnote modal is difficult on pages with a large number of footnotes. We have a rough fix in this branch in our fork, but while it meets our needs, I'm not sure if it meets the needs of other wagtail-footnotes users, or if there might be a different preferred approach.

---

To set the scene, we have some reports that are published as web pages, written by our researchers, that include a fair number of footnotes: https://www.consumerfinance.gov/data-research/research-reports/issue-spotlight-medical-billing-and-collections-among-older-americans/

The first issue is that Footnote doesn't define any specific ordering, and so when a content editor adds a bunch of footnotes, and then saves a draft, the footnotes appear to move around on the page.

Combine that with the second issue, which is an unfortunate side-effect of Wagtail InlinePanel prefix indexing where each child panel gets an index added. These two issues together makes it appear as though footnotes are changing order.

The index is... particularly unfortunate when it comes to footnotes/endnotes, where numeration is contextually important. I don't think this is easily addressable given that the indexing is hard-coded in InlinePanel.BoundPanel.

Our proposed fix in https://github.com/torchbox/wagtail-footnotes/pull/74 to make Footnote model inherit from Orderable ensures that the ordering on the edit page is at least always a content editor's choice.

Continuing to look at that same page, we have footnotes like these:

When selecting a footnote in the Footnotes modal in content, it can be difficult for content editors to visually scan for the correct footnote, given the nearly identical content. The most readily available visual cue is the UUID, which is... not human-friendly as a mental map between this list and the list at the bottom of the edit page.

A possibility we've been testing is to pull out the inline panel index from the footnotes list at the bottom and add it to the modal, so that there's at least a quick, easy visual cue that maps from that listing to the modal. The code for this is in this branch in our fork (FWIW, that branch is based on the Orderable PR branch).

This has its own problem of re-using (and this, re-emphasizing) an index that has no bearing on the reflect the rendered footnote index, but at least it's not adding another one?

My question for this problem is: is this the sort of change that would be accepted? Are there alternative approaches you all might prefer?

We have a fair number of pages like the example above (many of our recently published reports are now using wagtail-footnotes), and wagtail-footnotes has made creating and maintaining these so much better for our content editors. We're happy to do contribute back the work to address the issues we're finding, but I suspect we're on the extreme end of users with our reports pages and their footnotes.

[zerolab]

@willbarton thank for raising this. Will need a few days to get to it, and I've also asked for some UX/UI guidance from the team.

[willbarton]

@zerolab any thoughts on #74 or updates on this issue? We can proceed by using our fork with the changes I described, but I'd prefer not to diverge too far if wagtail-footnotes takes a different path.

[zerolab]

@willbarton it is on my list for this afternoon to look at

[thibaudcolas]

I got to look into the UX of the footnotes package, and have simple ways to improve it proposed here: #78. I think those changes would help quite a bit, not sure if they’d fully fix the issues discussed here.