Search 'archive' for: #indieweb
Page 2 of 9
<<     < >     >>
#

03/09/2017, 18:11

When writing about ownership I explored the difference between comments and replies and that part of it was context.

I started thinking about that again but in a wider sense.

I've never really liked that Medium turned all replies into full posts so that they showed as standalone items in your feed.

It didn't matter if it was an essay length response or just a quick one-liner; they all became "posts" in their own right.

Wrong!

But, thinking about it, this is what's mirrored, and encouraged, by the #indieweb where a reply is designed to be written on your own site and replicated as a comment on the original via a webmention. Regardless of length.

I can't complain about one but countenance the other.

"There are different types of reply and they should be treated accordingly."

There has to be a line, a point where a comment is just that and not a reply. It's a question of semantics but not everyone's answer to "what is a comment and where does it belong?" will be the same.

#

11/04/2018, 15:36

When taking the decisions I have about leaving the major social networks over the past few years (LinkedIn, Instagram, Google+, Facebook, Twitter) and moving towards a more #indieweb online existence I am aware that I am placing myself within a certain community with certain ideals.

James Shelley's farewell to social media and Andrew Canion's post about replacing social media are two cases in point. They echo my thoughts but that's only to be expected, we gravitate towards the similar and gather in places like micro.blog, refuges from the abuses elsewhere.

However, we must not allow these refuges to become echo chambers like those we claim to abhor and have left behind.

I'm happy and comfortable with my position but have to be equally comfortable with the decisions of others, have to hear other opinions, and not close myself off saying that "this is the only way."

It's the way that works for me and that's all I can be certain of.

While James removed all the data from his Twitter and Facebook accounts (something I also did a while before finally deleting them) he has opted to retain them as "living directories" and a last ditch method of contacting people when no alternative exists. It's a clever use of the system - the utility without the futility - and always provides the option of a hassle free return should he want it, should things change for him.

Social networks provide a lot of good for a lot of people and this can't be dismissed out of hand even if some choose to demonise those very same networks.

We can educate and warn but we cannot, and should never try to, choose for others. We should not force our decisions or our reasons on them, for they are not us and have a different perspective.

#

Bridging the gap

Eli Mellen wrote a great post about how the #indieweb needs to be more accessible to non-developers. It prompted some considered response including this post from Jeremy Cherfas in which he points to a response from Peter Molnar. And then there is "An Indieweb Podcast" from David Shanske and Chris Aldridge.

Eli linked to the indieweb generations page (the suggested adoption path) exclaiming that much of the current technology is rooted in generations 1 & 2 (the more technical users) but needs to be accessible to those in generations 3 & 4.

He espoused micro.blog as an example of pushing things towards the later generations suggesting it's 'time to update some of the tooling" to bridge the gap.

Having written previously about the need for easier implementation I didn't want to just repeat myself, or Eli, so wasn't sure how to respond or what extra I could add.

But then two posts cemented my thoughts.

Firstly, Manton Reece (creator of micro.blog) highlighted that the much sought after ownership of content doesn't just mean owning the server and having direct control over the source code. Instead, it's about "portable URLs and data. It’s about domain names" so that a site can outlive any platform.

Micro.blog as a service definitely straddles generations 3 & 4 as it works just as well with existing blogs as a blog hosted on the service itself. But If you opt for the latter then Manton has made things considerably simpler for you.

A CMS, webmentions, publishing by micropub, it's all built in, nothing else required apart from a micropub client - of which the native iOS and Mac micro.blog apps are perfectly functional and more than adequate examples.

This is exactly what Eli alludes to when he says you can't assume that users will care about the tech or the specs - they just want the tools.

Peter Molnar argues that "people should care, they should be at least be aware of what's happening when they press a publish button" and that "providing the tools only is not a goal I can align with."

I have to agree with Eli here.

People don't have any idea how Twitter and Facebook work but are willing to throw themselves at it despite warnings. Merely a fraction of the population has ever heard of MX records, and wouldn't know their POP3 from their IMAP, but billions still use email.

This is why ecosystems and adoption curves exist; some blaze the trails and develop solutions so others can use them without having to.

WordPress users, for example, load plugins to get the functionality they require with no idea of how that's actually achieved. It's taken on faith because the creators and the standards organisations have done their jobs.

And that is the generational gap

Next, Jason Kottke's linked to Dan Cohen's post "Back to the Blog" in which he talks about the importance of writing on one's own domain but suggests many don't because we are social animals and social networks provide "a powerful sense of ambient humanity."

I've previously described micro.blog as a social layer or glue but I think "ambient humanity" sums it up perfectly - the feeling that "others are here" as Dan puts it. This is absolutely what micro.blog helps to achieve: that connection between people, between blogs, even if you have set up on your own.

You don't have to be isolated.

The aim of the indieweb is that we can do our own thing, or join something like micro.blog, and that our sites and services are portable and interoperable because the technology is platform agnostic. For this to happen the ecosystem needs to be mature with tooling simple enough that anyone can plug and play, or have it built in to their platform of choice, without needing to know how it works.

It needs to be invisible.

#

Indieweb replacements

With a view to replacing Workflow with Drafts (at least as far as is currently possible) I decided to look at posting #indieweb like and replies directly from the app itself.

I was wondering how to pull in the post title using JavaScript but then realised this would just be duplicating effort as my Likes and Replies plugin already does the heavy lifting. All I would need to do was pass the URL as part of the HTTP request so it could be used as the relevant custom field.

The catch, however, is that custom fields are not exposed via the API by default.

Luckily, we can extend the API response and expose extra fields.

Hooking into rest_api_init and using the register_rest_field method you can add a field and specify the callback functions for retrieving or updating that field via the API:

add_action( 'rest_api_init', 'slug_register_like' );
function slug_register_like() {
  register_rest_field( 'post',
    'Liked',
    array(
      'get_callback'    => 'slug_get_like',
      'update_callback' => 'slug_update_like',
      'schema'          => null,
    )
  );
}

The above sets up the "Liked" custom field for items of type "post" then defines the functions used to retrieve or update. I've not done anything special, just taken it directly from the API Handbook.

This means that I can update the post data as seen before with the custom field, where url is the web page to be liked or replied to:

"data": {
  "title": draft.title,
  "content": draft.content,
  "status": "draft",
  "format": "status",
  "comment_status": "open",
  "Liked": url
},

I've then created new actions in Drafts which take the URL from the clipboard, or prompt for one if the clipboard doesn't hold one, and submit a post as before. The only difference is that I have to update the post after submission for the Likes and Replies plugin to trigger.

Performing likes or replies using Workflow meant that I was typing into a small, plain text box. The new aproach means that I can type what I want to say in advance, with the benefits of Markdown support, and then trigger the process.

<<     < >     >>