Category: social networking

subscribe to this category with rss

In reply to Social Readers by James G

Over the years I’ve blogged about what would be an ideal feed reader to me, and also mapped it to how IndieWeb standards might help realise it. In the end it all goes back to how I in 2005 described using feed reading as information filtering, and the inputs, reading and resulting actions it is built out of. That is still my approach, and it is as high friction as it was back then in terms of how well existing readers and tools cater to those needs. Plenty of space for feed reader evolution as you mention!

I would particularly love to hear parts of web readers you like and dislike. If you could build a social reader tomorrow, what features would it have?

James G

In reply to Collective Creativity by Wouter Groeneveld

Interestingly this came up yesterday at the FOSS4G-NL conference I visited, where Amélie A Gagnon talked about scenius as communal genius, a scene that jams together and creates results no single genius could. She also mentioned Austin Kleon’s quote ‘don’t be a genius, create a scenius’ (see his post on scenius, and about mapping a scenius, something I’ve elsewhere seen done based on LinkedIn profiles to see what is missing in terms of capabilities, roles and skills, to make a scene somewhere ‘explode’)

…and call it collective creativity: without a collective, the creativity of each genius partaking in the above meetings would never have reached that far.

Wouter Groeneveld

Posted on
by

Since a year or so the deterioration of the LinkedIn timeline has been very visible to me. Next to an increasing number of people sharing things as if LinkedIn is Facebook, the timeline is not under the control of the user, and presents algorithmically determined items. Sometimes that results in seeing things days or weeks after they were posted when I would have liked to see them the day they were posted, but instead got the rants of someone else. The only way one can shape the LinkedIn timeline is by removing people from it. So I did, and removed all people from it. I came to the conclusion that I’d rather have no LinkedIn timeline, and use it as it was in the past, as a digitised contact list. Of course that brings my LinkedIn experience back to the place where it was when Jyri Engestrom predicted its demise if it didn’t introduce an object of sociality in April 2005. I’ve been using LinkedIn since June 2003 (user nr. 8730), and the barebones ‘digital rolodex’ actually serves me well, to see the background of someone I meet, and to allow others to see the same about me. From now on I can skip the timeline that LinkedIn serves me as a default, and engage with people in my network, and the things they share on my own terms and initiative, seeking them out when I want. Next to keeping my own notes.

To get to an empty timeline I had to unfollow everyone I’m connected to. Which is not a simple thing to do, as LinkedIn provides no easy option to unfollow large amounts of people, and requires you to unfollow everyone one by one. Of course there are work arounds and that is what I used, with a snippet of code in my browser console.


LinkedIn can be nice and quiet, with everyone unfollowed

Posted on
by

I assume that in its most basic form I could redo Dopplr of sorts by announcing travel plans in an OPML file, much like book lists or my rss subscriptions. Then it comes down to how to share such travel plans with a known and limited network only. (You don’t want to announce to just everyone when you won’t be home.)

The IndieWeb efforts concerning travel seem to focus on posting actual travel movements, like planned flights. A sort-of check-in style post. The socially shared Dopplr info was much simpler: a city and a set of dates. Because its purpose was aiding serendipitous meet-ups. Exact travel plans or exact location aren’t needed for it, just a way to flag paths more or less crossing to those involved.

Of course making such an OPML file currently is as easy as posting an empty file, as there’s no significant travel during the pandemic.

Theoretically I could use such an OPML file to announce several things:

  • The various cities I consider as home turf, as they’re within easy reach in an hour.
  • Selected cities I’m willing to travel to at short notice outside that hour travel time if there’s a good reason to.
    From where I am a visit to Antwerp, Brussels, Eindhoven would count in that category, or maybe on specific occasions Düsseldorf or Cologne.
  • Upcoming travel plans, things like ‘Copenhagen, Denmark, 4th-7th September’ (actually a 2019 example)

Such a list would allow comparison with your list to see whether any of your travel plans match with my ‘home turf’ and destinations I’m willing to consider outside of it, whether any of your travel plans match with my travel plans, or whether any of my travel plans line up with your home turf and other relatively nearby destinations you’re willing to consider. Cities and countries are part of schema.org vocabularies and as such usable in OPML as data attributes.

I think there’s a space for location based services, such as Dopplr was, that don’t depend on or use maps, but provide location contextualized information that influences my actions, choices and my relationships to my networks (a quote from a 2012 blogpost on moving beyond the map).

Or this is just me applying my current opml hammer to anything that might be a nail 😀


I couldn’t resist making this mock-up mimicking the colorful Dopplr

Posted on
by

Could one redo any useful app, for that matter, that now fills the start-up cemetery?

I was reminded of this as Peter mentioned Dopplr, a useful and beautifully designed service in the years 2007-2010. The Dopplr service died because it was acquired by Nokia and left to rot. Its demise had nothing to do with the use value of the service, but everything with it being a VC funded start-up that exited to a big corporation in an identity crisis which proved unequipped to do something useful with it.

Some years ago I kept track of hundreds of examples of open data re-use in applications, websites and services. These included many that at some point stopped to exist. I had them categorised by the various phases of when they stalled. This because it was not just of interest which examples were brought to market, but also to keep track of the ideas that materialised in the many hackathons, yet never turned into an app or service, Things that stalled during any stage between idea and market. An idea that came up in France but found no traction, might however prove to be the right idea for someone in Lithuania a year later. An app that failed to get to market because it had a one-sided tech oriented team, might have succeeded with another team, meaning the original idea and application still had intrinsic use value.

Similarly Dopplr did not cease to exist because its intrinsic value as a service was lost, but because everything around it was hollowed out. Hollowed out on purpose, as a consequence of its funding model.

I bet many of such now-lost valuable services could lead a healthy live if not tied to the ‘exit-or-bust’ cycle. If they can be big enough in the words of Lee Lefever, if they can be a Zebra, not aiming to become a unicorn.

So, what are the actual impediments to bring a service like Dopplr back. IP? If you would try to replicate it, perhaps yes, or if you use technology that was originally created for the service you’re emulating. But not the ideas, which aren’t protected. In the case of Dopplr it seems there may have been an attempt at resurrection in 2018 (but it looked like a copy, not a redo of the underlying idea).

Of course you would have to rethink such a service-redo for a changed world, with new realities concerning platforms and commonly used hardware. But are there actual barriers preventing you to repeat something or create variations?

Or is it that we silently assume that if a single thing has failed at some point, there’s no point in trying something similar in new circumstances? Or that there can ever only be one of something?



Repetitions and Variations, a beautiful Matisse exhibit we saw in 2012 in the Danish national art gallery in Copenhagen. Image by Ton Zijlstra, license CC BY-NC-SA


12 stages, 1 painting. I’m thinking the reverse, 1 sketch, 12 paintings. Image by Ton Zijlstra, license CC BY-NC-SA


Normandy Cliff with fish, times 3. Matisse ‘Repetitions and Variations’ exhibit. Image by Ton Zijlstra, license CC BY-NC-SA

Posted on
by

Writing it down may help in getting out of the loop…

I’m continuing my tinkering with federated bookshelves, for which I made an OPML based way of publishing both lists of books, as well as point to other people’s lists and to RSS feeds of content about books. I now changed my XSL style sheet to parse my OPML files to be able to also parse mentions of RSS feeds.

Meanwhile I read Matt Webb’s posting on using RSS (and OPML) a few more times, and I keep thinking, “yes, but where do you leave the actual data?”
Then I read Stephen Downes’ recent posting on distributing reading material and entire books for courses through RSS, and realised it gave me the same sense of not sounding quite right, like Matt’s posting. That feeling probably means I’m not fully understanding their argument.

RSS is a by design simple XML format as a way to syndicate web content, including videos and podcasts. Content is an important word here, as is syndication: if you have something where new material gets added regularly, an RSS feed is a good way to push it out to those interested.
OPML is another by design simple XML format as a way to share outlines. Outlines are content themselves, and outlines can contain links to other content (including further outlines). One of the common uses of OPML is to share a list of RSS feeds through it, ‘these are the blogs I follow’.

In Matt’s and Stephen’s posts I think there are examples that fail to satisfy either the content part of RSS, or the syndication of new content part. In Matt’s case he talks about feeds of postings about books, like my book category in this site, which is fine, but also in terms of lists of books, which is where I struggle: a list doesn’t necessarily list pieces of content, let alone pieces of web content which RSS seems to require. It more likely is just a list. At the same time he mentions OPML as ‘library’, to use to point to such lists of books. Why would you use OPML for the list of lists, but not for the lists themselves, when those book lists themselves have no content per book, only a number of data attributes which aren’t the content items but only descriptions of items? And when the whole point of OPML outlines is branching lists? When a library isn’t any different from a list, other than maybe in size? Again it is different for actual postings about books, but you can already subscribe to those feeds as existing rivers of content, and point to those feeds (in the same OPML, as I do in my experimental set-up now as well).
In Stephen’s posting he talks about providing the content of educational resources through RSS. He suggests it for the distribution of complete books, and for course material. I do like the idea of providing the material for a course as a ‘blob’. We’re talking about static material here, a book is a finished artefact. Where then is the point in syndication through RSS (other than maybe if the book is a PDF or EPUB or something that might be an enclosure in a RSS feed)? Why not provide the material from its original web source, with its original (semantic) mark-up? Is it in any way likely that such content is going to be read in the same tool the RSS feed is loaded into? And what is the ‘change’ the RSS feed is supposed to convey here, when it’s a one-off distribution and no further change beyond that moment of distribution is expected?

OPML outlines can have additions and deletions, though at a slower pace than e.g. blogs. You could have an RSS feed for additions to an OPML outline (although OPML isn’t web content). But you could also monitor OPML outlines themselves for changes (both additions and deletions) over time. Or reload and use the current version as is, without caring about the specific changes in them.

The plus side of OPML and RSS is that there are many different pieces of code around that can deal with these formats. But most won’t be able to deal as-is with adding data attributes that we need to describe books as data, but aren’t part of the few basic mandatory attributes RSS and OPML are expected to contain. Both RSS and OPML do allow for the extension of attributes, if you follow existing name spaces, such as e.g. schema.org’s for creative works, which seems applicable here (both for collections of books, i.e. a shelf or a library, as well as books themselves). If the use of RSS (and OPML for lists of RSS files) is suggested because there’s an existing eco-system, but we need to change it in a way that ensures the existing ecosystem won’t be able to use it, then where’s the benefit of doing so? To be able to build readers and to build OPML/RSS creators, it is useful to be able to re-use existing bits and pieces of code. But is that really different from creating ones own XML spec? At what point are our adaptations to overcome the purposeful simplicity of OPML and RSS destroying the ease of use we hope to gain from using that simplicity?

Another thing that I keep thinking about is that book lists (shelves, libraries) and book data, basically anything other than web published reviews of books, don’t necessarily get created or live on the web. I can see how I could easily use my website to create OPML and RSS feeds for a variety book lists. But it would require me to have those books and lists as content in my website first, which isn’t a given. Keeping reading lists, and writing reading notes, are part of my personal knowledge management workflow, and it all lives in markdown textfiles on my local harddrive. I have a database of e-books I own, which is in Calibre. I have an old database of book descriptions/data of physical books I owned and did away with in 2012, which is in Delicious Library. None of that lives on the web, or online in any form. If I am going to consistently share bookshelves/lists, then I probably need to create them from where I use that information already. I think Calibre has the ability to work with OPML, and has an API I could use to create lists.
Putting that stuff first into my website in order to generate one some or all of XML/OPML/RSS/JSON from it there, is work and friction I don’t want. If it is possible to automatically put it in my website from my own local notes and databases, that is fine, but then it is just as possible to automatically create all the XML/OPML/RSS/JSON stuff directly from those local notes and databases as well. Even if I would use my website to generate sharable bookshelves, I wouldn’t work with other people’s lists there.

I also think that it is very unlikely that a ‘standard’ emerges. There will always be differences in how people share data about books, because of the different things they care about when it comes to reading and books. Having namespaces like schema.org is useful of course, but I don’t expect everyone will use them. And even if a standard emerges, I am certain there will be many different interpretations thereof in practice. It is key to me that discoverability, of both people sharing book lists and of new to me books, exists regardless. That is why I think, in order to read/consume other people’s lists, other than through the human readable versions in a browser/reader, and to tie them into my information filtering and internal tools/processes, I likely need to have a way to flexibly map someone else’s shared list to what I internally use.

I’m not sure where that leaves me. I think somewhere along these lines:

  • Discovery, of books and people reading them, is my core aim for federation
  • OPML seems useful for lists (of lists)
  • RSS seems useful for content about books
  • Both depend on using specific book related data attributes which will have limited standardisation, even if they follow existing namespaces. It is impossible to depend on or assume standardisation, something more flexible is needed
  • My current OPML lists points to other lists by me and others, and to RSS feeds by me and others
  • I’m willing to generate OPML, RSS and JSON versions of the same lists and content if useful for others, other than templating there’s no key difference after all
  • Probably my website is not the core element in creating or maintaining lists. It is for publishing things about books.
  • I’m interested in other people’s RSS feeds about books, and will share my list of feeds I follow as OPML
  • I need to figure out ways to create OPM/RSS/JSON etc directly from where that information now lives in my workflow and toolset
  • I need to figure out ways to incorporate what others share with me into my workflow and toolset. Whatever is shared through RSS already fits existing information strategies.
  • For a limited number of sources shared with me by others, it might make sense to create mappings of their content to my own content structures, so I can import/integrate them more fully.

Related postings:
Federated Bookshelves (April 2020)
Federated Bookshelves Revisited (April 2021)
Federated Bookshelves Proof of Concept (May 2021)
Booklist OPML Data Structure (May 2021)