(((•)))
tech.interfluidity.com
a notebook by steve randy waldman
→ See also top, archive, subscribe, drafts blog, interfluidity main
2024-06-22 ⇒

# Condensing updates that appear in digests

In the previous post, I claimed to be "finished" my exploration of handling updates.

Ha!

I don't like how my update notifications appear in digests — in e-mail newsletters that gather up all the posts over a period of time.

There are two problems:

1. Update notifications appear in digests as separate, cookie-cutter posts, which bury and dilute "real" posts.

   On websites, we can make synthetic update posts visually distinct to help guide visitors past them. We could do that in HTML mail digests too, but I think update posts will still put people off actually reading new material when they are going quickly through their e-mail, particularly when updates are more recent and therefore come before the "real" posts.

2. Updates appear even for posts that are included in the current digest.

   feedletter digests always include the most recently seen version of a post, so from the digest reader's perspective, the "update" notification tells them about nothing that isn't already in the post.

To address this, I mean to do a bunch of things.

1. I'm going to modify the definition of `iffy:synthetic`, reversing course on my my current admonition that

   > Applications that include `iffy:synthetic` as a direct child of channel SHOULD NOT also mark individual `item`s as `iffy:synthetic`, unless there is some meaningful sense in which some items are more synthetic than others. It serves no purpose to mark every item of a feed `iffy:synthetic` when the channel is already so marked.

   Never mind.

   Until now, `iffy:synthetic` has been basically just a marker, so there was no point in marking posts twice. Marking at the `channel` level implied the syntheticness and the types at the item level.

   But now we'll reconceive of `iffy:synthetic` as also the carrier of the data on which the item content (in `description`, `content:encoded`, or `atom:content`) is based.

   The item content, of course, remains the post's HTML, whether it is a synthetic post or not. But we'll want the information we used to compose synthetic posts to be available, in an `iffy:type`-dependent way, inside `item > iffy:synthetic`. So even when a `channel` is marked synthetic, with a type that implies the type of elements, we will want explicitly to include an `iffy:synthetic` element in each item.

   For synthethic items of type `UpdateAnnouncement` — the relevant case here — we've already defined an element that carries most the relevant data, `iffy:update`.

   We'll also need the `guid` of the post updated. So we'll bring back `iffy:original-guid`, with a slightly modified role.

2. I'll define a feedletter content `Customizer` that

   1. filters away upates to `items` already in the post;
   2. combines the remaining updates into a single notification post; and
   3. places that notification post at the end of the digest.

So. We have a plan!

Let's see if it works.

← Updated: Sprouted
↑↑↑
Updated: The 'iffy' XML namespace →