@pfefferle And there in a small nutshell is both the power and the drawback of part of the movement, particularly on a platform that powers 25% of the internet. I'm in the same boat with you (though my coding skills are far behind), but I thought I'd write down the blue sky idea as a potential target for the future. Perhaps we should follow Manton Reece's lead and create a Kickstarter campaign to fund such a thing? (_Said in half-jest/half-seriousness_).
I suppose the thing to continue focusing on is steady improvement of what already exists. Eventually a group of developers will join us all and separately or together we'll have the free time to bundle it all up the way we all imagine it sould be done on a salaried basis.
If I (or we, speaking on behalf of the rest of the community) don't say it often enough, **THANK YOU** again @pfefferle and @dshanske for your heroic efforts on behalf of the IndieWeb within WordPress.
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.
@100daysindieweb Hooray for helping out the less Indie-capable!
From a UI perspective, some might not quite know what you mean by IndieNews URL, to put in the proper one. I suspect it's there to differentiate between the various languages, in which case perhaps a dropdown with the different language versions instead of a more ominous empty box might be better? Gen2+ are more likely to be confused.
Additionally, how many do you suppose will find/hit the endpoint this way? Perhaps updating news.Indieweb.org to have the submission box on the submissions page like the one you added on day 9 (https:/
I can't believe it's been 40 days already!!! Kudos again.
@megarush1024 If you have a moment, could you add yourself to https:/
@jbjohansson Congrats! Feel free to join us in chat if you have questions or problems. #indieweb http:/
Want to know who's talking about #indieweb on Twitter? I've got a "bot" that compiles a list: https:/
@keithjgrant That's a well worded synopsis. Welcome to the IndieWeb!
I'm curious if, as a CSS expert--which I am assuredly not, your book has a section that differentiates "semantic" and "styling" classes? One of the quirks I've run into while playing in the Indieweb is that some designers use microformat classes (like hentry/h-entry, e-content, etc.) to style their pages rather than simply allowing them to be used for semantic mark up and instead relying on secondary classes for styling. I've seen many instances, particularly within the WordPress and Drupal communities, where themes (including heavily used template themes--_s, I'm looking at you!) rely on styling using microformats or other semantic classes and this tends to cause problems with decentralization to opening up the web to movements like Indieweb. I have a feeling if more developers were educated about this "quirk" that large swaths of the internet (WordPress apparently runs 25% of the web) would be more easily/automatically converted/upgraded to support the decentralized web. Thoughts?
Weird Flickr URL Trick http:/
There's a related issue for this: https:/
@Chronotope I'd be curious about ones which also (or separately) support microformats v1 or v2. #indieweb
Glenn, Congratulations too on your new IndieWeb enabled WordPress site! Looking good. Let us know if you need any help. http:/
@jbjohansson It's hidden away in the code of WithKnown. Reference here: http:/
Jeremy, Like you, I had some of the same issues and questions when I first started. I'd had a primary website for a while that was a bit more blog-ish on WordPress with a few other subsidiary sites for work related things. When I got into IndieWeb, WithKnown had a great plug-and play set up for almost everything, so for me, it made a nice easy place to start. I also wanted to play with Known and use it to get my feet wet. I was particularly interested in owning a lot of the shorter form posting/microblogging like Twitter without overwhelming my prior subscribers on my WordPress blog with a lot of shorter "fluff". Once I'd gotten a few things working, Known was also incredibly good at quick short posts using bookmarklets (or this mobile solution I'd come up with: http:/
Slowly over time, as I've been adding bits and pieces here and there to my WordPress set up, it has been owning more and more while somewhat less lives on my Known Install. There's also been a huge amount of community development on the WordPress side, so that it's tremendously better now than it was when I started and continues to grow. I think I hit a bigger turning point after IndieWebCamp LA when I was able to work out a bit more about how I want to own and syndicate things from my primary hub (on WordPress). (See also: http:/
Ultimately, I'd recommend doing what works best for you at the moment as there are literally hundreds/thousands of ways to pull it off. Do things one at a time in small bite-sized chunks until you have it the way you want it. There's no reason to do everything all at once. Sometimes I've found that creating posts literally by hand in raw html has been a great way to start to see both how it looks/works, and then use that experience to figure out how to best/most easily automate it going forward.
I'll also note that my coding skills were old and rusty and have been slowly getting better over time as each piece evolves. Another nice part of the process is that you'll have a chance to see how others are doing things with examples from the wiki to help you figure out what might work best for you. Over the process I've also seen others stop, change gears, and even platforms, and try out something totally different. The key seems to be to start with something you know and begin working from there based on your particular "itches" and needs [http:/
Your post was certainly a good start for taking stock of what you've got and where you might like to go. Now just make a list of your itches and do things a step at a time. I know there's an IndieWeb Cat [https:/
Good luck!