Uncategorized

Keep Bridgy Publish dumb

Bridgy has three parts: listen, publish, and blogs. One of them is not like the others.

Listening for responses to your silo posts and backfeeding them to your web site was the first service Bridgy provided, and it’s still the most popular. It runs entirely in the background. No UI needed.

Blog webmentions run entirely in the background too. Bridgy sends webmentions for you when you write a post, and it receives webmentions and adds them to your posts behind the scenes. Again, no UI needed.

Publish, however, is a different beast. It has a user interface, which is where most people start. Even after that, when they automate it via webmention, they often still want an interface of some sort or another to customize their silo posts, and that’s where the trouble starts.

POSSEing is simple sometimes, complicated other times. You craft tweet text, convert formatting, and translate mentions and tags (or not). These are not one-way operations. Characters need to be counted, formatting iterated, mentions auto-filled. You’ll want to preview your post. You need multiple round trips against the original post using a rich, interactive UI. Honestly, you need all that inside your CMS.

Like the rest of Bridgy, Publish is a service. It has just two operations, publish and preview, which doesn’t exactly lend it to richness or interactivity. We could force the issue and make plugins for the bigger CMSes – Known, WordPress, etc. – but I think that’s a losing battle. I wouldn’t build them myself, and I’d look hard at any new features they needed.

I love that Bridgy Publish lets people POSSE their posts without implementing silo APIs themselves. That’s why I built it! And I’m flattered that they like it enough to ask for more and more user-facing features. It’s just not the right place for them. Fortunately, it’s not the only game in town..

The one concession I’m considering is letting users specify the exact text to publish in their silo post. This would let advanced users craft custom posts for each silo in their CMS, and still reuse Bridgy’s POSSE API code. That’s it though.

Bridgy can and should be a best of breed backfeed service. Bridgy Publish, on the other hand, cannot be a best of breed POSSE service. My strongest inclination at this point is to keep it dumb, define precisely how it translates your original posts to silo posts, and avoid trying to offer UX where none can survive. It’s a mug’s game.

Also on IndieNews.

Standard

4 thoughts on “Keep Bridgy Publish dumb

  1. I’d call the robustness principle to the rescue here: “Be conservative in what you send, be liberal in what you accept”

    This means that it’s ok to be stick to a very simple (dumb) publication API.

Leave a Reply

Your email address will not be published.