Many (news(y)) websites have become highly irritating to browse: when you scroll down towards the end of an article you’re reading they append a next article underneath it, and if you scroll past the end of the article change the URL in your browser’s address bar. Below is an example I encountered today.

That is highly irritating, as the browser is my tool, not theirs.

  • It regularly frustrates bookmarking (if you hit a bookmarklet at the end of an article it saves the url of the next article),
  • it creates an endless scroll experience (a dark pattern copied from the likes of FB), where news sites get an opportunity to present content they selected by algorithm that you weren’t looking for.
  • it doesn’t influence the back button. Hitting that brings you to an unexpected place therefore, as you may not realise you’re in an endless timeline and think you somehow landed in a different article,
  • if you use your browser’s default setting you won’t have noticed that the URL has changed as the address bar will only show the domain, not the full URL.

This behaviour is based on HTML5 pushstate, which allows a site to interact with your browser history. This can be used to e.g. decrease load times of additional pages and content. The endless scrolling however feels like a dark pattern usage of this possibility to me.

In keeping with Doc Searls’ Castle Doctrine of browsers, I’d like to block this behaviour.

Options that are available seem to be:

  • Use a reader view. This seems to break bookmarklets though, which is one of the nuisances I’m trying to fix
  • Block all javascript and use a whitelist. Seems drastic, though it’s something I’m increasingly leaning towards over the past few years. Alternatively I could use a blacklist.
  • Use ad blockers by adding rules for the specific scripts causing this.

Reader view is useful, but not for this specific issue. Adding rules to my adblocker might be feasible, but assumes that I can easily spot a) which sites do this b) which script on their site is doing it, in order to block it. Using a blacklist for Javascript only needs me to spot sites that do this, which is half the hassle of adding filters to my adblocking. Blacklisting some sites for javascript is also less inconvenient than blocking all javascript and whitelist exceptions. So for now that’s the way forward. Bloomberg, the source of the example given above, is now on the blacklist.

Last June I looked in a description of my feed reading habits by social distance I mentioned the number of feeds I currently subscribe to. Now two months later, I was curious to see what, if anything, has changed.

Here’s the table with the number of subscriptions on June 12th:

folder # of feeds
A12 10
B50 14
C150 14
D500 16
E999 129

And these are the numbers for August 8th, two months since:

folder # of feeds change
A12 10
B50 18 +4
C150 22 +8
D500 19 +3
E999 150 +21

About 3 dozen new subscriptions in two months. In reality it is a bit more than that, as I also removed some existing ones. Subscription maintenance is like gardening. There’s been a slow trickle from the outermost folder to more inwards folders. This was expected, as I’ve met-up with various people at events, and that usually means moving their feed to a ‘closer’ folder. Events, such as Peter’s Crafting {:} a Life unconference in June als led to new subscriptions, some of which as they started in intensive conversations immediately moved to a ‘closer’ folder. And there have been a few cases of ‘I’m going back to blogging and leaving Facebook’. (much like I did late 2017, and Peter did much earlier, before severing the connection to FB completely mid 2016) So those subscriptions are more of the ‘welcome back playing outside’ variety.

Btw, I publish my current list of feeds that I subscribe in the side bar of this blog, titled OPML Blogroll. That link is to a file (tonzylstra.opml) you can read yourself, as well as provide to your feedreader for import. As always I am interested in what other people are reading and who’s blog they follow. So if you don’t, I hope you’ll consider publishing your subscription list or turn it into an old fashioned blogroll.

Very unsure what to think about Tim Berners Lee’s latest attempt to, let’s say, re-civilize the web. A web that was lost somewhere along the way.

Now there’s a draft ‘contract for the web‘, with 9 principles, 3 each for governments, companies and citizens.

It’s premise and content aren’t the issue. It reads The web was designed to bring people together and make knowledge freely available. Everyone has a role to play to ensure the web serves humanity. By committing to this Contract, governments, companies and citizens around the world can help protect the open web as a public good and a basic right for everyone., and then goes on to call upon governments to see internet access as a core necessity and a human right that shouldn’t be censored, upon companies to not abuse personal data, and on citizens to actively defend their rights, also by exercising them continuously.

There’s nothing wrong with those principles, I try to adhere to a number of them myself, and have been conveying others to my clients for years.

I do wonder however what this Contract for the Web is for, and what it is intended to achieve.

At the Contract for the Web site it says
Given this document is still in the process of negotiation, at this stage participants have not been asked to formally support or oppose the document in its current form.

Negotiation? What’s there to negotiate? Citizens will promise not to troll online if governments promise not to censor? If a company can’t use your personal data, it will no longer be an internet service provider? Who is negotiating, and on behalf of whom?
Formally support the contract? What does that mean? ‘Formal’ implies some sort of legal status?

There are of course all kinds of other initiatives that have voluntary commitments by various stakeholders. But usually it clearly has a purpose. The Open Government Partnership for instance collects voluntary open government commitments by national governments. Countries you’d wish would actually embark on open government however have left the initiative or never joined, those that are active are a group, (not all), of the willing for whom OGP is a self-provided badge of good behaviour. It provides them an instrument to show their citizens they are trying and doing so in ways that allows citizens to benchmark their governments efforts. Shields them against the notion they’re not doing anything. It does not increase open government above what governments were willing to do anyway, it does provide a clear process to help build continuity, and to build upon other member’s experience and good practices reducing the overall effort needed to attain certain impacts.

Other initiatives of this type are more self-regulatory in a sector, with the purpose of preventing actual regulation by governments. The purpose is to prevent exposing oneself to new legal liabilities.

But what does the Contract for the Web aim for? How is it an instrument with a chance of having impact?
It says “this effort is guided by others’ past work on digital and human rights” such as the Charter of Fundamental Rights of the EU and the EU GDPR. What does it bring beyond such heavy lifting instruments and how? The EU charter is backed up by the courts, so as a citizen I have a redress mechanism. The GDPR is backed up by fines up to 4% of a company’s global annual turnover or 20 million whichever is bigger.

How is it envisioned the Contract for the Web will attract more than those stakeholders already doing what the contract asks?
How is it envisioned it can be a practical instrument for change?

I don’t get a sense of clear purpose from the website. In the section on ‘how will this lead to change’ first much is made of voluntary commitments by governments and companies (i.e. a gathering of the willing, that likely would adhere to the principles anyway), which then ends with “Ultimately it is about making the case for open, universal web that works for everyone“. I have difficulty seeing how a ‘contract’ is an instrument in ‘making a case’.

Why a contract? Declaration, compact, movement, convention, manifesto, agenda all come to mind, but I can’t really place Contract.

What am I missing?

Untitled Forms / 20090924.SD850IS.3202.P1.SQ / SML
Please sign at the dotted line, before you go online?.
Image ‘untitled forms’ by See-ming Lee, license CC BY SA

Fifteen years ago my wife explained in a conference panel at BlogTalk that tools for online expression should really be much easier, and she was only using the tools she was using because I was ‘a geek‘ when it comes to online tooling.

Nothing much has changed it seems in the years since 2004. This morning, as a result from our conversations during our holiday about mobile blogging, we set up her personal blog for better IndieWeb usage. Earlier I had already added Webmention, but now we added IndieAuth, Microsub and Micropub. That way she can now use Indigenous to read feeds and blog on the go from her mobile, using Aperture to collect her feeds. (Indieauth is needed to authorise both Indigenous and Aperture to recognise and use her WordPress site, and Microsub for reading feeds, Micropub for posting to the blog.)

Thank you Aaron, for providing some links to your own blogging work flow in response to mine. Thinking about specific needed parts of such a flow in general, and then a possible mobile version of it makes sense, without trying to come up with a perfect flow. Tools and technology choices change all the time, and perfection likely means stasis. One aspect from your description stands out to me, over time collecting links, remarks and individual on ‘cards’ until they accrue into a posting. Currently that isn’t part of my blogging flow, but very much of how I learn and think, so a gap to address. My current blogging flow supports more a style of primary and first order responses, reacting to incoming links, replies or short observations. Making my basic flow work on mobile in part is intended to be able to already have that out of the way so I can get around to more long form original stuff. Reading your links made me realise that my current information strategies badly support that latter style of blogging.

Replied to On Mobile Blogging by Aaron DavisAaron Davis

You provide an interesting reflection on workflows Ton.
Personally, I spend so much of my writing of late on my Nexus 6P. For longer posts, I still often start in Trello using Markdown, however for my collected posts I utilise the post editor. Although I have tinkered with Indigenous, I have become …

(written by hand on July 16th, in the French country side, typed out and edited on the laptop after returning home)

Some notes on my experience with mobile blogging in the past few weeks that we spent in France. Normally I don’t post at all during our holidays. However it usually is a time I write a lot (because I usually read a lot), and my blog is the logical place for that writing to end up. As an experiment I wanted to see if current devices, tools and IndieWeb components might add up to a frictionless workflow. Results were mixed as you can see from the very first sentence above.

The set-up

  • I didn’t have my regular laptop with me this summer, but did have my phone and had a small 2013 Samsung Tablet (which means it has an old Android version that no longer supports a wide range of Android apps. It didn’t run Indigenous for instance, see below. Oddly my Opera browser also couldn’t do the current Captcha / I’m not a robot thingies, so had to use Chrome to log into my site, and then go back to my preferred browser).
  • The tablet was intended to write on the go more, as it had a bigger interface, and I dislike tapping out texts on my phone. Such writing took place in the webbrowser, being logged into my WordPress website’s console.
  • The phone runs Indigenous for Android, which is a Microsub client, which means it serves as a (RSS-) reader. I had it connected to my Aperture account as the Microsub server, and before leaving loaded it by hand with 41 feeds from sites I follow (which is about a fifth of what I normally follow).
  • The same Indigenous app also serves as a Micropub client, meaning I can use it to directly respond to something in the reader section of the app, e.g. to like, bookmark, or reply to a posting, as well as initiate a posting from the app.
  • I also have the ability to send a new posting by e-mail from a specific sender address, which I have enabled on my phone, to a specific receiver address that my blog can read, using the Postie plugin


  • Posting images is something I had envisioned doing easily. Snapping a picture, add a remark and have it online before you know it. Reality was different.
    • Using Indigenous to upload a photo to the Media section of WordPress wasn’t useful. Indigenous uploads it, and comes back with a URL for it. What it can’t do is come back with the correctly sized and WordPress optimised version of the upload. This is logical because the Indigenous doesn’t know it’s talking to a WordPress site. Writing a HTML image statement by hand using that returned URL can be done, but means an uploaded photo will be shown using the largest file size available (and that you’ll be coding html by hand on a tiny screen).
    • What does work well in Indigenous is posting a photo as the posting type ‘photo’, and add a few remarks to it. This is different from using a photo inside a posting as illustration, because in such a case the photo is the posting.
    • So in two instances (e.g. 1, 2) I uploaded the photo from my phone to my WordPress back-end, and then created the posting directly in WordPress using the slightly larger keyboard interface of the tablet.
    • In one instance I created an image on my phone and posted it as the posting type of an image using Indigenous and adding some remarks.
    • I automatically upload images to Flickr from my phone, and I often embed photos from Flickr into my postings. Oddly that didn’t work on the phone nor tablet, as Flickr apparently doesn’t show the embed code button on mobile versions of their site, nor in their app. So no embedding was possible during our trip.
    • I haven’t posted as many images I would have, had it been a smoother experience. Also because proper 4G coverage in the French country side turned out to be spotty, making ‘quickly upload something without it disturbing the flow of things’ impossible. Which is likely just as well, being in the moment etc, but unexpected.
  • Writing postings was a mixed experience.
    • The keyboard on the tablet I brought was still way too small for my liking. I also have an Android tablet that has an attachable keyboard which would work much better. I didn’t bring that one, as it has a very weak battery, meaning you really should keep it connected to a power plug continuously during use.
    • It wasn’t possible to select a piece of text while in the editing screen of WordPress. This was unhelpful while adding links. Normally I write a posting, and then add the links in later. Now I needed to use the link button in the interface and write the linked text in the link form, where normally I’d select the text to link after which hitting the link button would pre-fill the form. On my laptop I have keyboard shortcuts as well for this type of flow, and they of course weren’t available to me on the tablet.
    • Initiating a posting in Indigenous worked fine, except for the disruptive interplay between my network provider and my hosting provider. My hosting provider shields the login screens of WordPress sites with a captcha to battle automated login attempts. It does this once a month for an IP address, so for me normally it’s not something I come across often. However when roaming in an area with very spotty coverage you end up having different IP addresses multiple times per day. This would break me being logged into both my site and my MicroPub end-point, as my hoster would force the captcha on me again. It meant almost any time I opened up Indigenous it would have lost my connection to my site for publishing (not for reading, as that part resides on a different server). Normally getting it to work again would be one flow, with Indigenous showing me the WordPress login, and then automatically returning to Indigenous. Now it was two flows as the captcha broke the return to Indigenous. So I logged into WordPress by doing the Captcha and then login to WP, and then being already logged into WP had no issue connecting from Indigenous to WP.
    • Initiating a posting from Indigenous does mean it gets posted in ‘visual’ mode rather than in ‘text’ mode. This way HTML I added to a posting, to link or show a photo, would end-up as is on my blog and not be interpreted as HTML. So I opted to write on my tablet in WP’s back-end more.
    • Writing in the back-end of WP itself, which I often do on my regular laptop, was an unpleasant experience on the tablet. Mostly because the interface was still tiny, and kept jumping around to accommodate for the on-screen keyboard. I installed a text editor on my tablet to write locally, and not connected to the internet. A finished text I would then copy over to the posting form WP.
    • After trying the text editor however, I started writing material on paper (like this posting), and only then started typing it into the tablet. Normally, with a full keyboard I prefer typing, as it is faster than my handwriting. With the still too small interface on my tablet, typing was a two-fingers affair and hand writing was a much better experience in comparison. When you already know what you want to type the two finger typing style is less of a burden. Writing as thinking out loud I therefore did on paper first.
    • The fact that I could only use Indigenous on my mobile and not on my tablet meant that I had to cross the divide between two devices if I wanted to write something based on what I had come across in my feed reader. This as URLs and sources weren’t easily shared between devices. This divide was rather cumbersome, and the only way I could really cross it was by sending an e-mail from my mobile containing the links, to the mail address attached to Android tablet.Or type over URLs by hand.
      In practice it meant I didn’t really do that other than a few times. Upon my return my mobile browser had about 70 open tabs, of things I’d like to have shared or used in some form but didn’t.
    • I did not try to post via e-mail, which would likely have worked well. To use it well you have to add short codes to the title and content of the e-mail, adding categories and tags etc. It can’t be used for different post kinds other than regular articles either. I didn’t remember to bring notes on how to do that with me however. My wife did use e-mail to post, and did so exclusively. When posting photos it would often not correctly adjust the orientation, posting photos on its side or upside-down, depending on the position the phone camera was used in.


In 2004 I organised a BlogWalk session in Umeå, in the north of Sweden, which focused on mobile blogging. My recap from 15 years ago still seems relevant now, given my experiences the past weeks. One quote definitely still stands out as true “I’m not a moblogger, I’m a travelling blogger having trouble getting connected.“. Mobile blogging needs to reduce friction, not introduce it. My experiment these weeks surfaced several sources of friction that combined into not finding a comfortable flow.

  • Spotty internet connection was the key frustrating element. I am very much a ‘offline first’ type of person, but mobile blogging depends on connectivity in more ways than regular blogging on my laptop. Spotty internet connection easily turned a normally five minute task of pasting some text into WordPress, adding a link and ticking the boxes for categories into a 45 minute source of irritation. I adapted by doing the connectivity part on moments when I knew it would be more reliable, further fragmenting the flow.
  • Using two devices is inconvenient, if there’s a divide between them.
  • The tablet didn’t provide the bigger keyboard / screen I intended, or at least not big enough. On a future occasion I’d need a more recent tablet with attachable keyboard, so it can run both Indigenous and provide access to my WP back-end. This prevents the divide between two devices, and let’s both devices server their own use case.
  • The phone can be used as a stand alone device to blog photos and short notes that do not need additional linking to sources or associated postings. (Ignoring for now the frequent logging in, because of my hoster’s preventative measures)
  • I like an offline writing process. Writing by hand is a good way, especially when typing isn’t faster anyway. It does introduce the step to digitise it later. Transcribing could be seen as editing though. OCR’ing my handwriting is unlikely to be successful. Maybe writing by hand on a tablet works. I’ve seen others do it, but haven’t tried my hand on it. Or pens that digitise while you write, but that usually creates image files, not text files I think.
  • It’s useful to in more detail sketch out a mobile blogging flow for various types of use, and then test that over a longer period of time during regular working weeks. To land on a ‘settled’ mode for mobile blogging.

Camping in the French country side, relaxing but spotty connectivity. Better to sit back and sip a drink in front of our tent.