This minor NarraFirma release fixes one small bug that applies only to older projects.

Too many remarkable patterns

A helpful user told us about a strange problem. On the “Explore patterns” page of NF, when they double-clicked on a pattern, NF was setting the “remarkable” flag of that pattern to “yes” – on its own – and they could not set it back again.

What caused the problem was a bit of code we wrote to update legacy data back in 2019. It was supposed to add a “remarkable” flag to any pattern that had at least one observation but no “remarkable” flag. That’s because, prior to version 1.4.0 of NF, there was no remarkable flag.

The problem was that this update was creating a circular interaction because it was (accidentally) being done while the page was being redrawn. Changing the data caused the page to redraw, which changed the data, causing the page to redraw, and so on. Double-clicking was not the only way to get the cycle going; it could also happen by clicking the arrows under the table. But double-clicking made the cycle more visible, which is probably why we never noticed it before. (Double-clicking has no actual meaning in NarraFirma, so we’ve never done it.)

To fix the problem, we changed the code so the updating only happens when the user changes the “remarkable” flag by hand. This does mean that people who have legacy data (created before NF 1.4.0) will have to manually update their remarkable flags. But that is probably few people at this point, and now it won’t happen “on its own.”

Thank you, user! And as always, if you find any bugs – or find anything in NF confusing or hard to use – please tell me on the GitHub issues page.

This minor NarraFirma release adds one nice-to-have thing, but mostly fixes little bugs.

Hiding “not through the story” graphs

When I’m helping people work on catalysis, I often advise them to save time by ignoring graphs that don’t go “through the story.”

What does that mean? Well, say I asked people to share stories about a topic, and I also asked how old they are and where they live. This means that, among all the graphs generated by NarraFirma, there will be a graph of age versus location. That graph has nothing to do with the stories people told. Once in a while a graph like that will be useful, but not often. Not-through-the-stories graphs are worth a quick look, but I wouldn’t put a lot of time into considering them, since they are not why you did the project.

So I have added an option, on the “Configure catalysis report” page, to hide graphs that involve no questions about stories. You might find this option useless. However, if you happen to have a lot of questions about people, especially if you threw in a lot of demographic data you happened to have handy, hiding not-through-the-story graphs could save you some time.

Reset messes

When you reset a project, NF makes a backup copy in case you change your mind later. (We really don’t want you to lose your data.)

In the WordPress version of NF, I had recently (like a few years ago) found out that our scheme of adding the date to the backup table name was breaking the MySQL database, because MySQL table names have a character limit. So I changed NF so the backups just put a “b” in place of the “j” (for journal) that was usually in the name.

When I did this, I had assumed that the “rename” MySQL command would overwrite any existing table with the same name. It doesn’t. It throws up an error. So if you happened to reset the same project twice, NF would refuse to do it.

I have now changed this so that any NF reset backup table – for any project in your NF installation – is called

[your WordPress prefix]narrafirma_reset_backup_[date/time]

So in the unlikely event that you need to recreate a NF project from a reset backup, you will need to find the table by its date, not by the project name. Since (as far as I know) this has never actually happened, I think it is acceptable to remove the project name from the table name to make space for the date and time.

Note that the date/time in the table name is in UTC, not your local time zone.

No both/and

People never use software the way its developers think people will use it.

Funny story: One of the first pieces of software I wrote for money was a database system for a former professor. He told me what he wanted, and I built it. Then we met so he could look at what I had built. He sat down at the computer, put his hands on the keyboard, and somehow accidentally typed – in perfect sequence – the three keys that would immediately exit the entire database system. He said, “I broke it!” and I think my mouth dropped open. Anyway, after that, I added a special prompt to make sure the system would ask the user if they really did want to exit the system, just in case that ever happened again (though it probably never did).

NarraFirma has more users than ever, and they keep doing things I never do. Recently a user typed in a question short name with a forward slash in it, something like “Preference/choice.” It seems obvious – now – that people might do that, but I never thought of it before. The problem is that it creates a conflict.

The NF module that looks things up, the “valuePathResolver,” uses a forward slash to separate data identifiers in a lookup sequence. For example, when you are on the “Configure catalysis report” page, and you click on a type of graph to show, the code for that page saves your choice with the “valuePath”

/clientState/catalysisReportIdentifier/graphTypesToCreate

Meaning: ask the “clientState” module (which remembers what’s going on in your browser client) what the currently selected catalysis report is. Then save your choice in that report under the field name “graphTypesToCreate.” That’s why you can see the same types of graphs when you come back to the “Explore patterns” page again, even if you closed your browser in between.

The surveying code does not use the valuePathResolver, so a question with a slash-containing short name does not cause any data to be lost. But the table widgets throughout NF can’t find the data. They all use the valuePathResolver, and it chokes on the slash. (It thinks the question name must be the first part of the name, before the slash.)

I decided not to change how the valuePathResolver works, at least not yet. I didn’t write it, and it’s used all over the system, and I don’t want to create any new bugs. Instead, I wrote an extra validation step. You can no longer include a forward slash in any short name identifier. It’s not a beautiful solution, but it should fix the problem. If we ever get enough time to transition the badly-designed short-name-identifier system into a more robust all-UUID-identifier system, this conflict will go away.

As I told the user who discovered and then helped me track down this problem – and I want to say a huge thank you to that user – the “price” of free software is that its users and its testers are the same people. I would love to hire a dedicated tester to find other conflicts like this, but I don’t think anybody would work on it for the same salary I’m getting (nothing). So there will continue to be surprises like this – hopefully fewer and fewer as we go.

Clearer import & export

While I was messing with the Reset functionality, I decided I hated the Project admin / Import & export page, so I cleared it up a little.

Smaller bugs

I also fixed a few more bugs that were reported by users (or that I happened to notice while fixing other things).

• In the CSV import process, there was a bug while reading the specification for a scale question in which the “Does not apply” label was being ignored.
• Also in the CSV import process, you might have seen a browser error if one of the headers in your story-collection CSV file was not what NF was expecting to see. I’ve now moved that error message to its proper place in your “check import” readout in the browser console.
• The HTML page title for printed story cards was an ugly long UUID instead of the project name.

As always, if you find any bugs – or find anything in NF confusing or hard to use – please tell me on the GitHub issues page.