The Daily Parker

Politics, Weather, Photography, and the Dog

Busy day

Tonight the Apollo Chorus of Chicago has its first in-person rehearsal since 12 March 2020, almost exactly 18 months ago. We're in a new rehearsal space with lots of new people and new challenges (like mandatory mask-wearing while singing). Poor Cassie won't see me for several more hours.

Tomorrow I expect a little more breathing room. Today, though...yikes.

Fun times with non-profit contracts

Local restaurant review show "Check Please," which was to begin its 20th season on the local public-television station WTTW, will instead end its run after the station proposed contract terms that the producers couldn't accept:

I'd like to say our upcoming 20th milestone season will be our best one ever!  However, WTTW/11 and I want to go in different directions and pursue other opportunities, so it's just not to be.

Crain's has more:

The show's last contract ended in the spring of 2020, just as the pandemic forced restaurants to close. Manilow said they started new discussions about a month ago and in the last week, WTTW presented him with a new contract and he said it was so different, it didn't make sense for him to continue the relationship.

"We talked about some different ideas they had. They were so drastically different that I'm not going to get into the details," Manilow said. "There wasn't much room for negotiation. We tried but it didn't work out. If they had done what we've done the last 19 years, we'd be in production now. That's just a fact and that's their prerogative. From a fundamental standpoint, every other renewal was kind of pro forma and they'd renew."

My guess, informed by years of dealing with non-profit arts organizations, is that WTTW misunderstood how pricing and microeconomics work.

Arts organizations have a tough time making money, because (let's face it) most people don't value them highly. So there's a large supply of arts organizations and small demand. If you graph supply and demand, where they meet is the equilibrium price (where curve D1 and S meet):

If you charge more than P1, you will sell less, and probably make less money. In order to sell more (move from Q1 to Q2), demand has to move first (D1 to D2).

Unfortunately, many arts organizations try to balance their budgets by increasing prices, believing demand to be constant. Someone whips out Excel and plugs in some numbers, and voilà! Instant revenue!

But that doesn't work, and it's easy to see why.

We sell tickets to Händel's Messiah for $35 to $70, depending on the section. We have a good idea how many we sell every year in each section, so we have some confidence in our budgeting. But imagine we found out that, say, a deadly disease would require us to have an empty seat between each person in the audience, meaning we could only sell half the number of seats.

So we plug everything into Excel and figure that we can sell half as many seats for twice as much money. Cool!

Except no one wants to pay $140 for a seat at our performance. They might pay $75, but at that price would many other people would shift from the orchestra level to the balcony, so we'd wind up with even less money.

I imagine that WTTW looked at their budget and figured that they needed to pay "Check, Please!" a lot less in order to keep their books in balance. And the producers of "Check, Please!" said no, we're not adjusting our prices to help you balance your books; we can take our product elsewhere.

We'll see. It's sad when this sort of thing happens, and I wish more arts organizations would recognize that they need people with business skills in management. I expect "Check, Please!" will do just fine online.

Getting the band back together

In a few minutes I'm hosting only the second in-person thing my chorus has done in the past 18 months: our last board meeting of the summer. We're all set to start in-person rehearsals on the 13th, though we will probably have to wear masks until our performances. That'll be weird—but at least we'll be in the same room.

Other choruses in Chicago have the same challenges:

“COVID shut us down completely because singing is a superspreader event,” said Jimmy Morehead, artistic director for the Chicago Gay Men’s Chorus. Immediately, they canceled all shows and in-person rehearsals.

But they set virtual rehearsals for the same time, hoping to provide connection.

“The twofold reason why people join the chorus is to either just sing, or make friends, and so we wanted to make sure that people didn’t feel alienated and didn’t feel isolated,” Morehead said. Everyone shared what they did that week, what they watched on Netflix or what they cooked.

In person, Morehead was used to being able to give quick feedback. On Zoom, “I have to trust and hope and pray that they’re learning and doing everything correctly.” The Chicago Gay Men’s Chorus pulled off live online shows, where people performed from their home.

Some of our singers also perform with CGMC, and I've talked to Jimmy a couple of times during the pandemic. We are all overjoyed to get back to rehearsals, even if it means proof of vaccination and big ugly masks.

In praise of boring

On my horizontal monitor, I'm watching Apollo After Hours 2021, our chorus's annual benefit. Last year we deployed the 7pm video about now. This year we deployed it yesterday.

I've spent the last six years working very hard to spread the gospel of boring software deployments. I'm overjoyed that we had one this year with Apollo After Hours.

One video done for today...

...and I still have another one to do, though I'm not sure if today's the day for it.

This year, the Apollo Chorus of Chicago annual benefit cabaret/fundraiser Apollo After Hours will once again go virtual, necessitating a lot more individual work and a lot less fun than doing it in person. I've just completed the easier of the two songs I need to record by yesterday. With rehearsing it, learning it, recording the audio, setting up the video, and uploading the audio and video files to Google Drive for our editor, it only took me...about two hours. The song runs 2:15; I sang only 21 bars out of 81, for about 40 seconds of singing; so the ratio of work to performance is about 50:1—including the 3 minutes where I videoed myself lip-synching to the accompaniment track and smiling benificently.

For comparison, we rehearse Händel's 2½-hour oratorio Messiah for about 12 hours total, for a 5:1 ratio.

And we have one more recording to do after After Hours, which I'll describe as we get closer to the "performance" date. Once that is in the can, I don't care if we have another pandemic, I'm never doing one of these again.

But hey, After Hours will be fun!

Sunday not-so-funday

Bit of a frustrating day, today. I spent 2½ hours trying to deploy an Azure function using the Az package in PowerShell, before giving up and going back to the AzureCLI. All of this to confirm a massive performance issue that I suspected but needed to see in a setting that eliminated network throughput as a possible factor. Yep: running everything completely within Azure sped it up by 11%, meaning an architecture choice I made a long time ago is definitely the problem. I factored the code well enough that I can replace the offending structure with a faster one in a couple of hours, but it's a springtime Sunday, so I don't really feel totally motivated right now to do so.

Lest you worry I have neglected other responsibilities, Cassie already got over an hour of walks and dog park time today, bringing her up to 10½ hours for the week. I plan to take her on another 45-minute walk in an hour or so. Last week she got almost 14 hours of walks, however. I blame the mid-week rain we got.

I also have a 30-minute task that will involve 15 minutes of setup, 10 minutes of tear-down, and 5 minutes of video recording. I will be so relieved next fall when all of our chorus work happens in person again.

Before I do that, however, I'm going to go hug my dog.

How lazy usability can make your day harder

This morning I posted about some frustrations in getting our CRM system to import donations from our fundraising events so that we can then match donations with addresses to send out end-of-year tax letters. The frustrations have grown to the point where naming names seems appropriate, if only because Neon One, the CRM company, has a web-based ticketing system that doesn't really handle the level of detail their developers will need to (a) understand the problem, (b) understand the frustration, and (c) understand the features needed to solve (a) and (b).

As you read this, keep in the back of your head that I'm a software developer with 25 years of professional experience and another 15 of hobby experience before that. In other words, I've been writing software longer than almost everyone at the CRM developer has been alive.

Neon will probably consider this a feature request, though on any of the product teams I've run in the past 15 years, this would be a usability bug report.

tl;dr: Neon's import feature is software-centric, not user-centric. Instead of the feature helping the user, it expects the user to help the software. This causes grief for any user who is not a piece of software.

The simple problem

Because Neon doesn't have adequate (or, it seems, any) support for silent auctions and other day-of-event realities, we use a different system for our fundraising events. The other system spits out perfectly reasonable Excel documents with all the information we need to track donations along with the fair-market valuations of silent auction winnings. We want to import that information into Neon so that we (a) can print out end-of-year tax letters and (b) accurately track giving in the long term.

The obvious path, which doesn't work

People have studied usability for almost as long as I've worked in software professionally. Jakob Nielsen has written about since 1998. The first principle of usability has never changed: make the obvious path work in an obvious way.

Neon has an import function that appears, at first glance, to import exactly the kind of data our event system produces. It seems like one should be able to import a flat file containing the donor name, address, email, and phone number; the date and amount of the donation; maybe a note or other optional information. You would think you could map the columns on the file to fields in Neon, and the software would read the data file and import the data. Maybe you'll get one or two spurious donor records when the information in the file doesn't exactly match an existing record's data, so maybe you'll have a few minutes of clean-up that you can do right from the import report after it's done.

Anyway, that's how I'd design it. That's how Jakob Nielsen would design it. That's how the 22-year-old newbie with a still-wet bachelor's degree in design would do it.

That's not how Neon designed it.

OK, so there may be an extra step

The first thing the Neon import feature asks is: does your data have Neon account ID numbers? If not, it warns you it won't be able to match your data with existing donor records.

Wait, what? The CRM already has a decent "find duplicate records" feature, so why can't this run automatically on new or imported entries? (Seriously, Neon: why do we spend time after every concert de-duping our data because your software doesn't think to match existing records with new ticket orders even when all of the data are the same in both records? More on this in a moment.)

All right. I'll spend 15 minutes adding Neon IDs to all the donation records in the exported file that correspond to existing donor records. It's an extra step that the software should be able to accomplish on its own, but whatever, no one likes writing record-matching code.

Now what I expect is that Neon will add the new donations to the existing records, and add new account records if I don't supply an ID.

Nope. My first pass through this process looks only at the exported records whose IDs I've provided and updates those donor records, while completely ignoring the new records. And it then takes me to a screen that looks suspiciously like it will make a total hash of the donation records in the same export file if I click "next." So I abort.

Maybe a few extra steps?

I think, perhaps I should give Neon a little extra help now. Let me scrub the data going into the import so that we have the best chance of good data getting into the CRM. So I separate the export into two files, one containing Neon IDs and one with all the new donors who came to the event. Then I go through both to make sure mailing addresses conform to USPS standards, phone numbers are uniformly 10 digits without separators, and email addresses are validly formed.

Next, I import the file that does not have Neon IDs, hoping it will create new records for me. It does! And it even exports a report containing the new IDs it created, albeit with only the donor's full name and not the donor's first and last names, which creates a bit of extra work as now I have to manually map them to my donor export.

So after I add the new IDs where needed in my donation export file, I'm ready to import the donations. I start the donation wizard, it accepts that my records have valid Neon IDs, and I map the donation date and amount columns to Neon fields. And then it tells me that I don't have a "donation type" mapped.

I'm not going to go through the steps required to figure out what a valid "donation type" is. Suffice to say, I add a column to the export called "Donation Type" and fill every row with the value "Donation". (Why can't we just specify constant values for required fields at import?)

I go through the import wizard again, map everything required, and hit import. Oof! Error! Apparently, dates are hard. The export file has donation dates in the format "Jul 17, 2020 7:27:19 PM", but Neon says "Time field must be a date;now it supports 'MM/DD/YYYY','MM-DD-YYYY' and 'MMDDYYYY' format."

Now, without going into the rabbit hole too deeply, a few things immediately occur to me as someone who has successfully parsed dates for a quarter century in a half-dozen programming languages. First, why the fuck does Neon only accept those three formats when the format presented is unambiguous and can be parsed by nearly every programming language out there? Second, none of the formats presented or accepted in this case conform to ISO-8601, the international standard for date and time representation, so everyone is on shaky ground here. Third, I got all the way to this point and now it tells me I have to go all the way back and change the date format by hand? Because it turns out, Excel can't parse the dates either. Good work, 3rd-party event package. Nicely done.

Once more unto the breach, dear friends, once more;
Or jam the import with our ISO dates.

After entering all the dates by hand (made easier by 90% of them being the date of the event), I re-exported the file to .csv and tried the import again. (Oh, yes, Neon can't read XLSX files, so I have to export to CSV every. Single. Time.)

Success! Finally!

And now I get to do it again with the silent-auction winners list. All of it. Again. This time I just entered the 9 new accounts by hand, and discovered 7 duplicate accounts that had to be merged, and thanked the universe we only had 60 silent-auction items.

So I go to import and...Goddammit I forgot the "donation type" field.

So I go to import again. And it mostly worked. Except even though I specified which field contained the fair-market value to map against the donation, Neon ignored that. It appears nowhere in the individual donation records. Why even present the field as an option if...I mean...what the hell, Neon? Yet more shit I have to map by hand later on.

But wait, it still doesn't work

After all that effort, I did some spot-checks on various accounts and found that even though none of the donation records shows fair-market value for auction items, at least all of the donations that I expect to see in each record appear in each record. So now it's time for the 2020 donor report, and...

Um...you're fucking kidding me.

None of the imported donations shows up in the donor report's "2020 Donation Amount" field. After checking a few donor records, I promote my hypothesis (that Neon groups by the record-creation date for the annual sum instead of the actual donation date) to a theory. Neon support case #00316491 is born.

How Neon should have coded this

Many, many developers have solved this problem before. Importing donations should require only one pass through the Import feature, and follow this heuristic:

  1. As soon as the user selects "import donations" from whatever UI control offers the choice, Neon presents a page of simple documentation explaining the process, listing the required fields, and offering some insight into how it will work.
  2. The user selects the import file, which can be CSV, Excel, or any other common delimited format.
  3. The user maps all of the relevant columns from the import file to Neon fields. Neon does not present the user with fields that it will ignore for no stated reason later on.
  4. The user provides constant values (from drop-downs if necessary) for required fields that do not appear in the import file.
  5. The user clicks "upload."
  6. For each record:
    1. If the imported donor account has an ID that matches an existing account by ID, use that donor account.
    2. If the imported donor account matches the name and email of an existing account (or some other criteria), use that donor account but flag the row for review.
    3. If the imported donor account does not match an existing account on either criteria, create a new donor account.
  7. Stage the donation record with the specified, found, or new account ID, including all of the fields that the user mapped in step 3.
  8. Present the list of "for review" items to the user before committing the import, allowing the user to make edits to the imported data, or move back a step in the process.
  9. Once the user is satisfied, the user clicks "commit" to write the data to Neon.

I get it: Neon's dev group have process problems

I mean, guys, this really isn't that hard. You want hard? Write an IBM360 to MS-DOS import, complete with different endian values, and where mapping has to be hard-coded because configuration files haven't been invented yet.

I know how software development works. I expect any Neon folks reading this may think this is unfair, that the devs told management the features weren't finished, that management told leadership the devs weren't 100% finished but the stuff works well enough, and that leadership looked at the growing list of must-have features for the brochure and forgot to finish the must-have features for the users, that "it's not my fault." I'd also bet you a dollar that any dev reading this will think "I told you so" (unless they think "it works on my machine, you DFU," in which case you have other problems.)

In other words, you guys have a process problem. Somewhere the definition of "done" that passed QA for the import features didn't match the definition of "done" that users need.

For this we're paying $3600 a year. NB: we're willing to pay a lot more for software that works the way we need it to.

Meanwhile, though, I'll have to hand-correct what all this automation should have given me already, and get the damn tax letters out.

And Neon CRM support incident #00316497 is born.

So much not fun about this

I'm president of the Apollo Chorus of Chicago. One of my jobs is to send out letters to all of our donors acknowledging their donations for the previous calendar year. These letters should have gone out by January 31st, but...well...OK, I'm a little delinquent. And for no other reason than I really, really did not want to merge all the data by hand.

You see, we use a smallish CRM system for all of our institutional data, which works pretty well, especially with our membership and tech-savvy donors. Many people have set up recurring donations through the CRM portal (please donate!), which happily bills their credit cards each month and creates new records for us to merge later. (It's really, really dumb about preventing duplicate records, but its merge feature works well enough.) Other donors make ad hoc contributions through the CRM as well. The CRM then sends a report to our treasurer which he imports into QuickBooks, and all is good.

You know there's a "but." See, we use a different system for managing our annual fundraiser, because our CRM sucks at event management. This system records all of the donations received for each event, plus silent auction winnings, and produces its own reports that we import into QuickBooks.

The upshot is that the CRM is not the single point of truth for donations, though it muddles through as the single point of truth for membership and music purchases. The Development Committee therefore doesn't want to use the CRM, even though it's why we have the CRM in the first place. The treasurer doesn't want to enter or reconcile all the event donations by hand either. Nor does our IT Director want to merge all the duplicate records that would result from importing the event data.

I hope to have a solution for this by next year. This year, however, I'm banging my head onto my desk as I try to reconcile QuickBooks' list against the event software's list against what should be the single point of truth for all of it.

Christmastime is here, by golly

Thank you, Tom Lehrer, for encapsulating what this season means to us in the US. In the last 24 hours, we have seen some wonderful Christmas gifts, some of them completely in keeping with Lehrer's sentiment.

Continuing his unprecedented successes making his the most corrupt presidency in the history of the country (and here I include the Andrew Johnson and Warren Harding presidencies), the STBXPOTUS yesterday granted pardons to felons Charles Kushner, Paul Manafort, and Roger Stone. Of the 65 pardons and commutations he has granted since becoming president, 60 have gone to people he knows personally and who have committed crimes on his behalf. Maggie Haberman and Michael S Schmidt say he's at his most unleashed as he tries to avoid leaving office the loser he is.

In other news:

Finally, enjoy this performance of the "Hallelujah" chorus from Händel's Messiah released just a few moments ago by the Apollo Chorus of Chicago: