One of the most confusing parts of Micro.blog is the Account → Edit Sources page. It is also one of the most powerful and unique parts of how Micro.blog was designed. If you’re confused by it, how can we improve it? I’ve made a couple tweaks here and there this year, but need a fresh look.

@manton I only recently realized that the list of feeds are what one chooses to go into the timeline and one's user page. I thought if I deleted the feed then I was deleting the actual feed. It wasn't clear that deleting the feed means I could remove it from the timeline without harm to the feed (something good to know for those with multiple blogs).

For the two choices in Add Source: If I choose "import posts" are they also going to the timeline? If I choose "add posts" will they also become entries on my blog? If I remove the source what happens on the timeline or entries on my blog?

"Import posts" seems to add all previous entries from the source. I thought it would be new ones from then on. "Add posts" seems to be new ones from then on. I'd like to see these two choices made clear about what they do.

Thanks very much.

@manton Why do you think that page is confusing? I'm not confused by that page.

@manton It's indie powerful, and maybe that's why it is confusing. The first time I clicked on that page, I didn't understand its relation to the cross-posting feature. And although I now get it, I think that page should be split into two: cross-posting and feeds. Instead of having the list of cross-posting accounts there, it would be just the blogs RSS feeds.

And talking about the feed, it is not intuitive to have to manually add other Mb feeds there.

Related to that, making the cross-posting options linked to having the blog feed added to that page is sometimes a bad idea. I had to remove one of my blog's RSS because it was in Portuguese and that was making a mess in my main feed that is in English. But now, there's no way to automatically share that blog posts on other social media.

@pratik How is EchoFeed's UI any different? If you remove the parts of Edit Sources that EchoFeed doesn't do, it's essentially the same design, isn't it?

@manton It lets you customize your feed (even category feeds) to cross-post to individual platform and also lets you pick what and how you share it there via its variables. IFTTT probably is more user-friendly but that can be done with EchoFeed later. Admittedly, it's the embracing of the complexity and flexibility that people who would typically use this feature on Micro.blog would already be comfortable with.

@pratik @manton yes, I think it’s basically the same feedback Manton has resisted (I think for good reasons)— routing complexity + some customization of content for cross posting versus “hose in, hose out”.

That said, I’d look to how Segment does Sourced and Destinations for UI/UX. It says “turn on these sources” and “turn on these destinations” and then separately “what source should this destination receive?” And also permits filters on what elements move for each source to destination chain.

@manton This is one of my favorite parts, but it was also something that took me a while to wrap my head around (and I’m still not 100% sure I have it).

I think people are used to the idea of connecting services, not feeds. A blank box is freeing for some people and intimidating for others. Before I learned how it worked, I would have loved a dropdown suggesting some common services (Letterboxd, OMG.lol status, etc.).

@jsonbecker I’m generally for less complexity to appeal to a wider audience. But worth looking into (if available) what type of users are currently using the non-complex hence more rigid crossposting feature. Is this level also still turning off most users and worse, is it also turning away users who need more flexibility even if it’s slightly more complex. Only @manton can/should decide what’s the sweet spot but I think it should be based in user research if he wants the feature to be used. Otherwise they’ll seek other solutions like EchoFeed

@manton I like how it works and looks, but I am probably a more experienced user with those things.

@manton

For me, as someone relatively new to this, it was hard for me to fully understand the difference between posting to the feed and posting to my real blog. And why can’t I cross post when I choose only to post to my blog and not the feed? I think it would make things clearer if the microblog timeline was a cross-post option underneath the importing feed, exactly like Bluesky and Mastodon.

Also, short of being able to deselect individual posts from showing up on the M.b timeline, it would be handy to get JSON feed for categories. That way, I could have instant cross posting and have more flexibility in what M.b feeds to where without compromising on posting delay. If I’m understanding JSON feeds correctly, that is.

@manton Wjhile you redesign this, people could look at this video explaining the whole thing. youtube.com/watch

@manton One of the confusing parts for me is that if I don't have cross-posting enabled for LinkedIn, then I don't have the option to do it manually, as you can with Threads, Mastodon and X. I think we should always have both options: automatic and manual cross-posting

@ivomota Thanks, you’re right I need to make sure the options match up better.

@pratik @jsonbecker Yeah, I’m glad there are other solutions. I only added cross-posting originally because nothing worked well. So I’m more interested in making it easier within the current features.

@jordon Good point, thanks.

@manton I do really think a lot of the micro.blog settings would benefit from having a designer do usability testing on normal (non geeky) people. Micro.blog is a lot of things put together and communicating that well seems both hard and nessesary.

@manton

I agree that Sources is brilliant and a reason why I pay may sub. What I like about Micro.blog is that it up-front assumes the existence of an ecosystem: it is not totalising.

What isn't obvious to me is how to achieve the things that I want to achieve. Maybe I'm an edge-case and not catered for within Micro.blog - but it would be nice if that were clear.

Here's some of the things I want to do:

• Post on Micro.blog -> Send to several Mastodon instances (I am not a monolithic me, but I would like to have a single point of posting).
• Receive posts with fidelity without posting them to the timeline. For me, the main thing is bookmarking - can I receive a bookmark from elsewhere with link, title, description and tags without displaying it on my timeline?
• Receive posts from other platforms that might by publishing posts to even more platforms without creating duplicate posts on my timeline

If you were going to make things clearer, I'd maybe suggest the interface should be step-by-step. First, I'm going to set a source. Next I'm saying where this source is going. I find the journey more approachable than the connectors.

@manton I’ve been beating the drum on fixing LinkedIn for a while. So I’ll take this opportunity to triple down on that. Its implementation right now limits the reach to only my connections on LinkedIn. I’d love to be able to cross post there.

As far as inbound sources, I don’t think it’s as clear as it could be for the less technical user to understand that it can make posts based on one’s work on OTHER websites.

@mmetcalfe Isn’t your first point possible? I believe you can setup multiple mastodon accounts to sent to.

@handy Thank you for continuing to mention the LinkedIn limitations. I’m working on fixing that.

@mcg You can? I must look again.

@manton I’d like the LinkedIn crossposting to be public too. Because of the nature of my work, it doesn’t make sense for me to restrict such (cross)posts to just my connections.

@moonmehta This is coming soon, probably tomorrow.

@mmetcalfe Looks like I'm wrong. I thought you could add multiple fediverse destinations. The most you can do is have posts show up on your M.B fediverse account and one other cross-posted account.

@mcg Okay! Had me going, there. Perhaps because it seems like a natural thing to do as an extension of the existing functionality.