I think the biggest hurdle to wider adoption is simply the fact that there are so many individual plugins and this takes up far more mental space for the user than it should.
So, another option which I'd like to suggest and advocate for is to **bundle all the plugins into one big single plugin** instead of sub-plugins. You could almost sell it as "the part of WordPress core you always wished you had" and now you can with two clicks: download and activate. (That's got to sound good, even to your mom who's still figuring out how to upload her profile picture.)
From the user's standpoint, this wouldn't require much more than some slightly better UI/descriptions. (And I'm more than happy to write them.) This could consist of a single main settings page with on/off toggles for Post Kinds, Syndication Links, Webactions(?), Micropub, Hum, and IndieAuth. A tabbed interface on this same page with tabs primarily for settings/set up and usage description for all of these (except for maybe Webactions?) would complete the cycle.
Most of the sub plugins don't have many (if any) actual settings other than installation/activation right now which is creating the biggest part of the (mostly mental) hurdle for every day users. I think the average WordPress user probably wouldn't know that they had Webmentions, Semantic Linkbacks, or Webmentions for Threaded Comments installed because they "just work", require no configuration, but are far prettier than any of their predecessors. Why make them carry the mental overhead of what they are and what they do aside from a few subtle lines that they exist? In fact, treating them as if they should have been in WordPress core all along may actually make it more likely to happen.
Additionally things like Micropub which would only have an on/off toggle wouldn't be noticed or used by many unless they had interest in alternate posting interfaces. (And based on the popularity and growth in Twitter interfaces/apps a few years ago, I'm surprised WordPress didn't do this, though perhaps it's part of the reason they're adding a more robust API over the past few years?)
It also means having slightly better or more intuitive explanations of what the individual pieces are (mostly Syndication Links and Post Kinds) near their on/off toggles to better explain what is being activated. Much of this can be taken from the current interface or from the WordPress wiki pages, or added on the individual tabs for the settings for these portions.
I would suggest that doing this would not only make it easier on end users who then wouldn't have to spend the mental space and capacity to keep track of what 10 individual plugins are doing (in addition to the space these take up on the plugin admin page and the fact that, once activated, they disappear from the IndieWeb plugin's list of plugins), but that it would actually dramatically increase the uptake of the single big plugin and its functionality and simultaneously the use of the all the sub plugins individually.
I'd argue that bigger plugins like Yoast SEO or something like PressForward have huge numbers of options and settings and could have been done as separate sub-plugins (the way IndieWeb Plugin is now), but that their value proposition is such that it's well worth spending the handful of minutes reading through the interface to know what the options are, what they mean, and using them to their fullest advantage. I think that Indieweb (and the suite of tools offered on WordPress) is at this tipping point in terms of offering must-have functionality for the future web and that having a simpler integrated set up would help to push it over the edge to broader adoption. (Certainly simpler than the old WP-Social, which users have indicated that they thought was far simpler than Indieweb plugin, though Social actually required more set up.) Additionally all of the seemingly dense text in the "getting started" page could be moved into smaller bit-sized chunks relating to individual portions on a tabbed-interface, for example.
I come to this in part after having spent part of the weekend revamping a bit of the IndieWeb.org documentation on getting started with WordPress and setting up Bridgy with WordPress. A lot of the description is "get this plugin, install, and activate" which takes up a big piece of mental space for the user as well--particularly for the Gen2, 3, 4 users who want a plug and play experience. Far better would be to install one plugin and then modify these handful of settings.
If this is done, then the only remaining (small) hurdle is making sure that the underpinning rel-me data input required of the user is done in a more explicit manner, because this seems to be the lynch-pin holding a lot of it together and making it work. As a result, I'd recommend unbundling the reliance on the User Profile page and put all the rel-me URL fields on their own page in the settings interface for such a single plugin (with all important links just underneath them to encourage users to visit, for example, Twitter's edit profile page to include their website URL in either the website field or in the bio field to enable the bi-directional rel-me.)
Finally a "Tools" tab in the settings page could provide pointer links to additional things like the H-Card Widget or the IndieWeb-PressThis bookmarklets.
When all of this is done, it could also be a simple manner of adding another settings tab to the interface to set up Bridgy with one button links from the plugin to the set up pages for each of the main backfeed services there. Bridgy then automatically checks for the webmention endpoint and checks for rel-me to do it's work, so that part is already automated and relatively user friendly too.
The one caveat I can imagine is that making it all into one big plugin potentially means some small added overhead in development with maintaining some of them as stand alone pieces. I'd recommend keeping them as standalone objects as I honestly believe that pieces like webmentions and micropub are so fundamental to the web, that they should be part of WordPress core and maintaining them separately could help speed this along.
I'm probably pretty close to being in your general boat on the technical side, though I may have been at it for about 5 minutes longer. Keep pecking away and you'll get there.
I notice that you don't seem to have connected your Instagram account to brid.gy yet, though you're collecting your Instagram posts via Known (presumably with OwnYourGram). Adding your URL links (with rel="me") properly (the Instagram account in your profile on vaviblog and the other in your IG account pointing to vaviblog (either in the website field OR your description field see https:/
Hint: Known already marks up links on your profile with rel="me" so you only need to put in the URL. Instagram doesn't support rel="me", but brid.gy routes around it on your behalf when you put it in one of the two locations described.
Unless they're moderating comments, it looks like there's little chance they actually saw your reply.
In some cases where others don't support webmention, if you want them to see your response, you should @mention their Twitter account directly and syndicate your reply to Twitter, and/or you can manually POSSE your response to their page directly via comments.
Join some like-minded people in building and updating your personal website.
Location: Virtual: Google Hangouts
Time:
Ends:
•Work on your IndieWeb Resolutions for 2017
•Finish that blog post you’ve been working on
•Demos of recent IndieWeb breakthroughs
•Share what you’ve gotten working
•Ask the experts questions
Link to Google Hangouts to come.
Participate: https:/
Live Stream: http:/
Join a community with like-minded interests. Bring friends that want a personal site!
Any questions? Ask in chat: http:/
Optional quiet writing hour starts at 16:30 (Pacific)
Add your RSVP in the comments below, by adding your indie RSVP via webmention to this post, or by RSVPing yes to one of the posts below:
Indieweb.org event: https:/
Facebook event: https:/
Meetup.com event: https:/
The IndieWeb is a growing people-focused alternative to the ‘corporate web’.
Skill levels: Beginner, Intermediate, Advanced
#IndieWeb, #socialmedia, #OpenSource, #webarchitecture, #openstandards, #decentralizedweb
I've been following the conversation on https:/
I'll spend some time in the next two days to see if i can stumble across the "fix" snarfed did and close this out. Thanks for the reminder @pfefferle.
@indiescripter I think you've probably got a pretty good start on the IndieWeb philosophy. And an even better start in that you're writing your thoughts on your own website first and then syndicating them to silos like Twitter.
I think that part of what you're missing about being able to reply to Aaron's original post is that his site both sends and accepts a new web protocol known as Webmention (http:/
I know Aaron also often syndicates copies of his posts to Twitter. There's another IndieWeb related service known as Brid.gy which bootstraps webmentions onto Twitter (in addition to other social silos) so that replies or comments to the copy that got syndicated to Twitter also send copies to the original post. In this case, he only syndicated it to news.indieweb.org, so it was less simple for you to have interacted with his post because there wasn't a Twitter version for you to interact with.
You'll find that within the broader community that different members will support varying levels of functionality (based mostly on what they're interested in), so someone like Tantek (tantek.com) will post on his own site and syndicate to Twitter, but he doesn't yet display webmentions. You can, however, post your replies to him on your own site and syndicate them to Twitter (perhaps using Brid.gy publish?) to reply to his syndicated copy on Twitter where he'll see the notification of your reply. You yourself serve as another example as you don't (yet?) offer a comment field on your own post. Perhaps you may never, but that's your choice. (I'll mention incidentally that many static website owners are using Aaron's Webmention.io for sending/receiving webmentions, see also: https:/
I think that a lot of the goal is to not only have fun with what you're doing on your own website, but do things which you find interesting/useful for yourself. Are you interested in locations/check-ins [http:/
Just be careful, because lurking in IRC or browsing the IndieWeb wiki for a while and seeing what others are working on or doing can make you very "itchy". Though the reverse is true that seeing what others have done (even how silos have done things in the past) can make it easier for you to build it not only better, but perhaps more quickly. Perhaps the CMS or language you're using is being used by others in the community [http:/
Keep up the search, and let us know if we can be of further help/assistance.
Join some like-minded people in building and updating your personal website.
Location: Starbucks, 4430 York Blvd., Los Angeles, CA 90041
Time:
Ends:
•Make your IndieWeb Resolutions for 2017
•Finish that blog post you’ve been working on
•Demos of recent IndieWeb breakthroughs
•Share what you’ve gotten working
•Ask the experts questions
Join a community with like-minded interests. Bring friends that want a personal site!
Any questions? Ask in chat: http:/
Optional quiet writing hour starts at 18:00 (Pacific)
Add your RSVP in the comments below, by adding your indie RSVP via webmention to this post, or by RSVPing yes to one of the posts below:
Indieweb.org event: https:/
Facebook event: https:/
Meetup.com event: https:/
The IndieWeb is a growing people-focused alternative to the ‘corporate web’.
Skill levels: Beginner, Intermediate, Advanced
#IndieWeb, #socialmedia, #OpenSource, #webarchitecture, #openstandards, #decentralizedweb
The IndieWeb plugin does have quite a few related plugins which all interact well, but you don't necessarily need them all. You can obviously pick and choose based on the specific functionality you'd like to have. Their modularity helps to make understanding what sets of functionality each piece provides a lot easier.
In particular the two that will recreate most of the requested functionality of wp-social above are [Webmention ](https:/
The other sub-plugins within the larger IndieWeb suite add supplementary functionality if you want/need it. This also helps to cut down on code bloat which can slow your site down. In fact, if you only want a few in the suite, you can install them separately from the larger plugin. The others also help to not only extend functionality, but to better automate portions of it.
They are all also are being actively developed/supported on GitHub.
@zack06007 It looks to me like this plugin isn't being actively maintained and I don't even see it in the main WordPress.org repository anymore. It's also possible that with the recent WP 4.7 update some of the functionalities have broken further. The last commit to the code was almost a year and a half ago with the bulk of the code being even older.
If you'd like to maintain a lot of this functionality in a better way with some smaller discrete plugins I would recommend the following:
- [**JetPack** ](https:/
- [**IndiwWeb Plugin for WordPress**](https:/
- [**Brid.gy**](http:/
If you need more help in setting these up or using them, feel free to visit http:/
@EatPodcast Saw your conversation in chat earlier: In "Site Configuration" on Known set "Include permalinks" to "No" and you shouldn't get the repetitive Twitter card for things you send to twitter that are under the 140 character limit. If I recall, Brid.gy should still be able to find and backfeed comments based on the rel-me without needing the permalink in the tweet.
If you go over 140 characters, Known will automatically shorten the tweet and include the permalink so the reader can get the rest of the message. (I sometimes use this for longer than usual tweets in reply to people, like this one).
Generally you can include 117 characters + a URL and still always fit in under the 140 total.
If you manually include a URL, and the page has the correct meta data, the URL will turn into a Twitter card. If you include more than one URL, it's typically the last that will show the Twitter card metadata.
Hope this helps!
Shelbydorris, Kevin Marks recently wrote some great stuff about websites and contrast. His article and the comments on it have some great tools you could use to help test things out to improve your contrast settings.
Of course, it probably helps to have a link doesn’t it?
https:/
I tried the same post and didn't run into the same issue:
http:/
Though I also tried liking your original post @danito and got this:
http:/
The post includes the extraneous metadata "Daniel Nixpublished this 26 Oct 2016 0 stars 0 comments" in the title, rather than just the original title. Perhaps you've got some code misplaced that's causing both issues for you?
I've run into the original problem a few times in the past, but it's typically been the target site having issues with http/https or security settings that don't allow the plugin to scrape the page properly. It's been relatively rare and I haven't run across it in a while.
If I recall, the locations module had a (similar?) issue a while back that didn't fail gracefully when the system didn't return a location properly and it just hung. It was changed to allow it to fail and let the user enter/cut&paste the data manually. Depending on the root cause of the problem, perhaps this could be a solution? Is it even showing you the URL field before you approve the post? Could you enter it manually?
@rikmendes I'm not sure what you mean about Twitter URLs, though If I use it to "like" a tweet, I get something like this: http:/
"Kevin writes a plea on Ev’s blog" - I often still think of Medium this way too. Though isn't Backchannel technically a Conde Nast joint now?
Kevin, do you get to eventually "own" the actual post after an embargo period? More journalists should be syndicating content in an IndieWeb-centric way like this, but still able to keep all the likes/comments after-the-fact for their portfolio. (Particularly when they do all the follow up commentary and respond to comments as well as you do.)