@snarfed, no worries; I know you're certainly doing better/more important work in other quarters than this. Besides, I don't just hold my breath waiting for things like this, sometimes I turn blue and fall off my chair... :) maybe I'll finish dusting off some of my rusty coding skills and get around to this myself after a few other itches.
Some of these types of niceties are going to be more "necessary" as IndieWeb Generation 2 starts onboarding heavily...
Support Featured Image (and other common WordPress functionality) · Issue #24 · snarfed/wordpress-micropub https:/
I'm not sure if it's something that would fit in here or quite how -- perhaps a setting toggle?, but for clients that push photos (OwnYourGram.com, https:/
Other potential settings-based functionalities I can imagine being useful (based on experience with Twitter clients) include
* being able to set future posting times
* saving posts as draft, private, pending, etc. rather than automatically publishing
* allowing one to set Post Format (or if using the IndieWeb Post Kinds plugin: Post Kind)
Naturally supporting some of this would also depend on the posting client having support for these options as well.
Congrats @raamdev for supporting microformats2 & better #IndieWeb comments in @WordPress Independent Publisher theme https:/
For example, @WordPress might add microformats2 & schema.org options to encourage developers to fill those niches #indieweb
Hugo, I'd written up some details specifically for Known a while back: http:/
@mjane_h It dawns on me that you might find the #IndieWeb Summit this weekend in your back yard to be interesting http:/
Is it just me or has @sciencemagazine quit showing/allowing comments on articles? Perhaps a response to http:/
About/FAQ missing reference to webmention-endpoint? · Issue #673 · snarfed/bridgy
I'm always a fan of instructions being built intuitively into the UI flow, to guide new users along, especially if they have a solid idea of what they're getting into in the first place. In this particular instance, the reference to the HTML was a tad too nebulous and may confuse many -- especially those who begin reading rather than jumping right in.
Shortly the indieweb will be so big that totally tyro users with no facility with code will be on the doorstep and will need better explanations/instructions. Perhaps I'll take some time in the coming months to put together simple walk thrus for the handful of major platforms? If you think it's worthwhile, can you let me know, based on the current userbase (or even recent growth in the past 6months-year), how you'd rank them in order of priority so we can help the biggest groups first? Or perhaps it's worth starting at the lowest hurdle for the least technical users (Tumblr/Blogger?) and building toward the more technical (WordPress.com)? (I'd presume most above this level are okay with most of what exists now).
I'm presuming that Brid.gy was originally meant as a "code" bridge to connect activity on silos, but I can also see it as taking on a secondary meaning in providing the initial value and impetus to bridge users into to the bigger IndieWeb movement.
Jay, I don't think the author David spends much time in the fora here, and I know he's been diligently developing several other plugins in the https:/
If you have questions or need help, you can find him on IRC via http:/
UX/UI enhancement: Blank syndication links being syndicated · Issue #23 · dshanske/syndication-links
. I'm not sure if I've seen them display on other sources (in most cases I choose to use the icon versions rather than text, but could do a quick test to see if the text at least appears.) Since I'm sure there are others, I'm curious if there's a way to either fix how these show up (or not) or simply move them for POSSEd copies?
Thoughts on UX/UI:
I'm presuming that they're hooked onto the end of the_content(), which then means that they're being syndicated out as part of the body of the content. I would suggest that on most platforms, most people don't/won't care about the fact that there are syndicated copies (though for the near term of advertising the concept for the IndieWeb, keeping them may be valuable), particularly when they can view the primary source which ought to presumably have all the commentary and webmentions (by backfeed or other means).
Interestingly, I occasionally see, though not as often, the "Share This" data flow through in the same manner. In my case the share this appears _above_ the list of syndicated links: viz:
![share this](https:/
Is there some type of processing that Jetpack is doing to prevent this from syndicating as "content"?
The way I typically think about it, knowing about syndicated copies is mostly useful as a function of commenting rather than content, so that if someone comments in Facebook, for example, I go back to that silo to post a response, so their chosen platform can send notifications/emails etc about the interaction, and rely on webmentions to backport my own comment onto my site and to keep the flow of conversation on the original post rather than a separate post on my own site that points back to another. Perhaps then, the best default location for syndication links is within the comments section? This then solves the problem of syndicating out blank versions, but more closely associates the syndicated copies with the "conversation" about the post. Potentially putting them at the top of the comments section could also keep them relatively close to where they currently live as a default.
I pose most of this as ideas/potential suggestions, but I'm curious what others think in terms of what/how they use this functionality.
The 2010 Social Networking Map http:/