Automatic app updates out, this method in.

Automatic app updates are a bad idea. Apple should recognize this by now. In case you, dear reader, aren’t convinced of that, here are some simple reasons why automatic app updates are just no good –

  1. Software is buggy – how many times have you heard that “we shouldn’t get the dot zero version of that software”? It’s almost a maxim in the enterprise world – unless you deeply trust it to not break your current setup, don’t get that update. So why should we be so cavalier about software updates for our personal devices? We shouldn’t let developers decide the de facto time when we get an update.
  2. It’s a vehicle for disruption – and not the good kind. App updates are great if they’re well thought out, streamlined, and work. But more often than not, they introduce changes which wouldn’t sit well with you and your workflow. How many of us regret updating to some version of iOS that slowed down our devices to hell and there was no recourse? Why do we trust third party developers more than we trust Apple in this instance? If I don’t know exactly what is going to change in the update, why should I update it? Which leads me to the next point…
  3. Automatic app updates are evil – Yes, they’re evil. How many times has Facebook slipped in something nasty and you didn’t even know it till you got the update? There are two types of nasty Facebook has slipped into your devices over time – the first is when they change the user agreement. So often, we would go to the website and Facebook would make us check a box and hit Accept before letting us burst out our Likes and jealousy. We’ve all brushed past those to chat with our friends. The same applies to app updates. You open the app to answer the call of a notification and an annoying pop up tells you to just say YES before you can do what you came here to do. What option do you have other than to stab that yes button? The second nasty is the more insidious version – Facebook has been able to slip in all kinds of dirty code, tracking features, and nasty experiments into our apps simply by adopting frameworks that let them remotely update our apps, and by using vague release notes that just said “making some improvements”, even when they were shipping major changes to your Facebook and Instagram experiences. This must stop, and the easiest way to make them stop (even though we’re too far gone now thanks to their remote app update frameworks), is to stop automatic app updates.
  4. It’s bad for security – This goes against everything you’ve ever heard. “Automatically updating software is great! It keeps things secure!” Until, it doesn’t. Software is eating up our life and yet, pretty much all of us are rather careless about the security of our apps and services. For most technophobes, automatic app updates are both a boon, and an excuse to hide behind. “Hey, I keep my apps updated, but I still got hacked!” Well, did you consider 2FA? Did you try to understand whether you’re using insecure communication over insecure networks? Did your app have the requisite features to protect your privacy, like data encryption? Are you using the same password for fifty services? We would all be more knowledgeable about all those questions if we bothered to understand what goes on in the making of our apps, the design decisions taken by the devs, and the shortcuts they take to ship sooner. Which leads to the next point –
  5. It’s a surprise! – it feels great to open an app the first time in the day and notice that something has changed overnight, but more than once, I’ve been bitten by apps that changed their business models, removed features, and made decisions that affect me, without so much as bothering to explain that a change is coming. This attitude is a right that a developer feels about a piece of code that they’ve written, but it’s a piece of code that I licensed from them and is running on my machine. They should not be able to decide how that code changes for me. By removing automatic updates, we’re forcing developers to explain why we should be getting this new update, rather than letting them get away with “we removed bugs!” or the boilerplate crap big tech companies throw at us.

Until things change and developers become better documentation writers, and tech companies stop lying about the code they’re sneaking into our machines, I have one suggestion –

Don’t do automatic app updates. Do expiration-based ones instead.

Right now, automatic app updates are an all or nothing deal. You either trust Apple and third party devs completely, or your don’t. I fall in the latter category and I couldn’t be happier! I know that I’m gonna get exactly what I paid for an app (especially if it’s free), and it’s going to work exactly as I expect it to for a long time to come.

Well, almost. Apps often have massive API changes, or security updates that are absolutely essential. The only way for devs to push those through is to expire the version of app currently installed on your devices, and force you to update (when you open the app the next time, at the crucial moment when you actually need the app). I’ve seen a lot of important updates like this, like when my banks update their APIs, or my insurance firm tells me to get the update else I won’t get continued service, or my grocer decides that I can’t get to my weekly ‘one dollar off’ coupons until I get the latest and greatest app update they’ve pushed out.

OK, that last one is silly. Apps like my grocer and my insurance app should always work. If I’m in front of a cop who’s asking for my insurance info, it would suck if I have to tell her that I have to update my darn app before I can show it to her. Also, why the heck does my grocer need to update the app once a month? Haven’t they heard of APIs?

Situations like those cause me to propose the solution I’m presenting, though, it’s obvious that it should be taken with a pinch of salt, since it’s not the perfect solution.

Here’s what we should do –

Apps shouldn’t get auto-updated. Instead, this should be a deliberate process. We need to be able to approve everything that goes into our devices. Yet, some apps are essentials, and though I don’t open my insurance app every day, when I open it, I expect it to work instead of showing me a banner to update the app before I can continue. So those essential apps should have two options – either I let them auto update completely, or I let them update only when the app is marked as ‘expired’ by the developer. The benefit of the latter approach is that devs should have a legitimate reason, such as changing their API drastically, that should drive app updates. Does this put more strain on Apple’s app approval process? Yes. Let’s make them earn that 30% they take from the devs, and the hundreds of dollars of Apple tax they collect from us.

I’m not interested in the smaller updates. I’m interested in keeping my apps available when I need them. So if I can skip the small ones and only get the big, breaking news updates, I’ll be a happy camper.

But this may not suit everyone. Some people don’t care about how and what changes are coming to their devices, but that’s what got us into this mess before with Apple and the battery issue which Apple effectively cheated and lied to us about, and Facebook and every privacy scandal they’ve been able to walk away from.

I believe that if you want to remain that kind of person, you have the full right. So I would love to see all of these options incorporated into the next iOS, or the one after that. The future is customization and personalized feature sets for everyone. It’s more expensive due to that, but that’s just where we’re headed. Hopefully, we’ll get to enjoy some good software on the way.

A couple of things about the iPadOS.

To me, this is the most exciting consumer announcement at WWDC today.

Everything, from better copy/paste (that terrible tap UI be damned), to the new Apple ID based app sign-in (it’s been a long time coming), to the fact that you see footnotes on the iPadOS page for the first time at about 70% down the page (when they mention speed improvements, which are already a sore spot for Apple), tells me that Apple has finally accepted that the iPad is not just a ‘bigger iOS device’ but a thing in itself.

Some of the ideas they’re throwing at us are reminiscent of OS X jiggery-pokery (like Today widgets, and App Expose and app spaces), while others, like Apple Arcade (gaming subscription service; akin to Amazon FreeTime Unlimited) seem like good improvements that Apple needs to keep their services business growing.

Apple’s long road to merging Mac and iPad app development is on the cusp of breaking out, and their continuity and handoff features are getting better and better.

The best part was the range of iPads that this new OS supports, which is a good job, well done, Apple.

I realized recently, that we use our iPads horizontally almost exclusively, and Apple should ideally twist the Apple logo in the back by ninety degrees. Perhaps this software change is the first step to embracing this new mentality.

Notes on setting up Freedbin

Here are some notes on how to setup Rachel Sharp‘s Freedbin, which is a docker version of the popular Feedbin RSS feed reader.

I had some trouble setting this up on my Windows 10 machine. A lot of issues I faced had to do with setup and environmental variables. I don’t think I faced any real issues due to my host being Windows, other than the terrible thing that Windows 10 itself is. Anyways.

First of all, I had an already running version of postgres for other docker images, so there was a conflict I was not able to resolve, since Rachel’s docker compose file calls its images directly from Docker Hub which are not easily configurable. If someone can guide me to using the same postgres instance for two docker projects, that would be great! Right now, I have two docker containers running postgres.

So, (real) first of all, I downloaded the repo to my own machine to make modifications.

To begin, in the docker-compose.yml, I changed the name of the service from postgres to postgresfeedbin and changed the port to 5433 instead of the 5432 which was already in use.

I also changed the app image from rachsharp/feedbin to a local name freedbin_app and added the build line, so I could build the changes I’m putting in.

I added the restart unless-stopped line to ensure my containers never stop! 🙂

There’s a discussion on the github repo about replacing Postlight’s Mercury service with our own open source version of the same. Postlight has sunset their own servers, so it makes sense to use our own. One alternative is to use Feedbin’s own extract service, but that is available only in the newer version of Feedbin, which Rachel’s docker container doesn’t use. Instead, I already had a docker image of Mercury from the docker hub that I’ve setup for tt-rss and other projects, which I just connected to, using the MERCURY_HOST environment variable. In this setup, the MERCURY_API_KEY doesn’t do anything. Mercury just ignores it and it seems that so does Feedbin.

All of the above are summarized here, as part of the docker-compose.yml file –

app:
    # image: rachsharp/feedbin
    image: freedbin_app
    build: .
    restart: unless-stopped
    environment:
      - MERCURY_HOST=http://192.168.99.100:3000
      - MERCURY_API_KEY=abcd
      - SECRET_KEY_BASE=abcd
      - POSTGRES=postgresfeedbin
      - POSTGRES_USERNAME=feedbiner
      - POSTGRES_PASSWORD=feedbiner
      - PGPASSWORD=feedbin
      - DATABASE_URL=postgres://feedbiner:[email protected]:5433/feedbin_production
[...]
  postgresfeedbin:
    image: postgres
    restart: unless-stopped
    command: -p 5433
    environment:
      - POSTGRES_USER=feedbiner
      - POSTGRES_PASSWORD=feedbiner
    ports:
      - 5433:5433
    expose:
      - 5433
    volumes:
      - postgres_data_feedbin:/var/lib/postgresql/data
volumes:
  redis_data:
  postgres_data_feedbin:

I further had to make changes to the startup_script.sh file as here –

if psql -h postgresfeedbin -p 5433 -U feedbin -lqt | cut -d \| -f 1 | grep -qw feedbin_production; then

As seen, I’ve just pointed it to the new service name and port.

At this point, the service was able to start. I was able to create an account and get in and add feeds. However, I follow a lot of feeds and importing an OPML file makes good sense for me. But, the import settings page was failing to import due to a failed AWS config. I looked up solutions and one way around is just to disable a connector called CarrierWave, which connects to AWS. Guess what gets disabled if you disable CarrierWave? The import/export page.

So, I went about creating an S3 bucket on AWS, getting credentials, and making the S3 bucket publicly accessible. I don’t know why this is the case. Perhaps if we use a newer version of Feedbin, these issues will not pop up, but in Rachel’s version, this is the case, so I went with it.

After I made my S3 bucket and got the AWS credentials, I added them to the Dockerfile as here. The variables are already there, just need to be filled up –

ENV FONT_STYLESHEET=https://fonts.googleapis.com/css?family=Crimson+Text|Domine|Fanwood+Text|Lora|Open+Sans RAILS_ENV=production RACK_ENV=production AWS_ACCESS_KEY_ID='my_key_id' AWS_S3_BUCKET='my_bucket_name' AWS_SECRET_ACCESS_KEY='sooooo_secret!' DEFAULT_URL_OPTIONS_HOST=http://localhost FEEDBIN_URL=http://localhost PUSH_URL=http://example.com RAILS_SERVE_STATIC_FILES=true

There’s one more catch. The Feedbin code uses its own version of CarrierWave called CarrierWave Direct, which defaults to try to use the ‘us-east-1’ region for AWS. If your bucket is there, you’re fine. Mine is in ‘us-west-1’, so I had to go into the /config/initializers/carrierwave.rb file and change the following to add my region –

config.fog_credentials = {
      provider: "AWS",
      aws_access_key_id: ENV["AWS_ACCESS_KEY_ID"],
      aws_secret_access_key: ENV["AWS_SECRET_ACCESS_KEY"],
      region: 'us-west-1',
}

Finally, I am ready to build and deploy. Running the following command –

docker-compose build

You’ll notice a new image in your docker images list –

$ docker images
REPOSITORY                    TAG                 IMAGE ID            CREATED             SIZE
freedbin_app                  latest              20a0334cd11c        30 minutes ago      1.27GB

and now you can deploy –

docker-compose up

It takes a while, as Rachel mentions somewhere, but all services come up perfectly, and I was able to import my OPML file. I noticed that the S3 bucket holds the lone OPML file, so perhaps it won’t cost me any money? Eventually, once I know that the import is done, I’ll go in and delete the bucket.

Big, big thanks to Rachel Sharp for creating Freedbin. It’s a great way to get started on Feedbin and while I was working on setting this up, I learnt how to use docker, created my first Docker container and uploaded my first project to Docker Hub. Hopefully, I’ll be able to build Freedbin from scratch using the latest Feedbin code and Feedbin’s extract service, and using the principles set down by Rachel.

Words Matter in Interfaces

Visual design is powerful, but the words are what people quote to one another.

And they are the only part of the design that survives across time and media types. They can be held intact in a human mind.

Erika Hall

Source

As soon as I read this quote on Joshua’s blog, I thought about my reluctance to use Snapchat. I once had a conversation with someone who is an ardent user of the social network and after explaining a few basics of the app to me, he grew weary of my inane questions and simply said, “if you’d been with the app since the beginning, this would not feel weird to you.”

Indeed, I see it as this – visual design needs a lot of historical context to understand. If you’ve seen it evolve over time, you can understand it well. But if you are dropped into it anew, it’s all strange and confusing to you. A new user might even be scared of clicking things, if they have no idea what they’re doing.

I love playing a game called Egg, Inc. For the first few months of playing the game, I would notice these cute little drones flying around. I thought they’re just an easter egg by the developer. Unrelated, I would notice that at random times, my resources would shoot up, by random values which made no sense to me.

While reading a post on reddit one time, I discovered that you’re supposed to smack those drones out of the air. See, in the game, you’re running a chicken farm, and you believe those drones are a violation of your space, so you can shoot them down, for a reward. Sometimes, fast moving drones appear and shooting them down is difficult but awards you with an exponential value. All of this would be in the onboarding, but I can never recall there being a specific time when I was told to hit the drones. In a way, that is an easter egg – you’re supposed to discovered on your own that those cute flying objects are actually an annoyance to your character and shooting them is the right thing to do. But I felt betrayed. How many months had I wasted not knowing about this growth hack?

I can’t expect a game of all things to label everything. The elegant interface of Egg, Inc, would only be made more clunky by the addition of ugly labels. But I can expect this from Snapchat. Their job is to make it easy for me to use their interface, specially if I’m a new user.

An interface made up entirely of swipes is revolutionary, but a hindrance to people who have not understood it from the beginning. The same is true for all visual design, and it’s worth remembering for everyone who is involved in the task of designing interfaces.

n.b. Notice how quickly Erika’s ideas were attacked by someone who puts more value in visual design than textual context. I would have expected people to have differing opinions about the topic, but one opinion doesn’t invalidate another. It’s an opinion, not a fact.

My wife asked me the other day – why do you use twitter? Isn’t it full of bile and anger? This is why. Great ideas are often posted to it, and inquisitive minds go where the water of knowledge is.

Reeder 4 is here?!

I’ve been experimenting with Tiny Tiny RSS for a couple of weeks now, to figure out if I’m done with Fever RSS. Part of it is that Fever runs on a Digital Ocean VPS and I’d like to reduce the load on that server as much as possible.

I run TT-RSS on my home PC and get access to it using ZeroTier wherever I am. My app of choice for it on the move is Fiery Feeds. It’s a beautiful app with an amazing, rich feature set. But the main reason I use it is because Reeder doesn’t natively support TT-RSS.

But, I’m learning that I’m set in my ways. the TT-RSS web app feels just as dated as Fever, and there are some features in Fever that I really enjoyed, which I miss in TT-RSS. Since I’m looking at two dated, self-hosted RSS readers, why not go with the one I’ve used more?

Also, Fiery Feeds is gorgeous, but it’s not Reeder. Reeder is familiar and cozy. It’s got matured syncing and great UX. Fiery Feeds comes close, but there are some things which are just irksome, such as the way it opens up articles as a pop up. The cadence of Reeder’s panes is just beautiful to work with.

Today I learnt that Reeder 4 has been out since April 25th. At an absurd cross-device cost of $5, it’s a steal for all the features Reeder gives you.

But here’s the flip side – I only use Fever (and now TT-RSS) and while TT-RSS has a plug-in for Fever, I’m more inclined to just use Fever. Which means I have no space for using any other paid or free RSS reader service. So I’m really restricted in what I’m doing with Reeder. Further, though I’ve started using Instapaper as my read later solution, I’ve never really understood the point of using Reeder for Instapaper. It’s fine to skim through, but wouldn’t you rather use the Instapaper apps to read the content? For me, the highlighting and notes functionality of Instapaper is essential. How does one ignore that to read content on Reeder?

Lastly, there’s the demise of Mercury. Mercury has been my savior in this mess of RSS feeds. My TT-RSS installation has a Mercury plugin that cleans up and extracts content from the feeds. It really just works, and since they’ve made it open source and unavailable as an API, Reeder is bound to suffer. Reeder 4 is now experimenting with something called Bionic Reading and it’s a hit or miss. We’ll see.

So here it is –

  1. I’m tired of TT-RSS and untired of Fever (for now).
  2. I love Reeder 3 and Reeder 4 is ridiculously cheap for an upgrade. I have an older iPad Pro, so Reeder 3 works really well for me. But buying 4 means supporting Rizzi in the amazing work he’s doing.

  3. Fiery Feeds is awesome and pretty and useful, but I don’t pay for the subscription, so I don’t get to use the fancy automatic folders that it creates.

  4. RIP Mercury

  5. I really want to get my RSS feed reader off the VPS and onto my local setup, secured and made accessible through ZeroTier.

How many people reading this have already bought Reeder 4?

How is it?

Have you used Bionic Reading?

Which RSS reader service do you use it with?

Do you read Instapaper articles on Reeder 4? How is that experience?

Jugaad

The Hacker Way is an approach to building that involves continuous improvement and iteration. Hackers believe that something can always be better, and that nothing is ever complete. They just have to go fix it — often in the face of people who say it’s impossible or are content with the status quo.

Rands In Repose: Hacking is Important

Help me find a Read-later / Notes solution

Dear Reader,

I’m looking for a suggestion, or a coalescence of suggestions to drive me towards a solution.

I’m looking for a read later solution that doubles as a notes repository. See, I want to not just read longform articles at peace, I want to also take notes and highlight things and (maybe?) search my notes and recall things over time.

Here’s a list of everything I’ve tried to date –

Mainstream

  1. Instapaper – Of course this is first on the list. It ticks off almost all the boxes. It’s reasonably priced, cheaper ($30/year) than its main competitor, and has been around since forever. It’s also everywhere. Why am I even writing this post? Well…
  2. Pocket – This is the alternative. It’s nice. It’s too well integrated into my current browser of choice (Firefox). It handles video etc well, supposedly. (Ah, that’s why I’m pondering this – should I lean towards Pocket because it does things that Instapaper simply is not capable of?) Flip side – Pocket just looks wonky. It’s like they married Material Design and never looked beyond. I hate that their list view doesn’t show snippets of the text of the article (Instapaper does). Heck, I modify my RSS readers to show me that stuff, who is Pocket not to show it to me? When there’s a banner image available, Pocket prefers to show that, which just shows that their style is more images-visual then text-readable. It gives me pause. Also, expensive! Though it’s just $15/annum more than Instapaper.
  3. Wallabag – Yes, this is ‘mainstream’ because AlternativeTo lists it as a leading alternative to Instapaper. It’s also the one most talked about after the top two. Wallabag is nice, and it makes me pause and wonder whether I want vendor lock-in and data dependency over time. Options like wallabag are what make it difficult for people like me to choose closed source over open source. Damn you French people! The problems with wallabag are more like – their iOS apps don’t support note-taking, and neither do their iOS website versions. It’s really painful that I have almost everything I need, including data independence, and then they lack features on the move. Yikes. Free, self-hosted solutions are nice, if they work. Wallabag has a long way to go because it’s ready for this generation of web users.

Others

  1. Polar Bookshelf – This is an interesting alternative. Polar lets you save articles into their app in a custom format, called phz, which is basically where they load the page in a custom browser, let the JS finish it’s magic, then lock it down and freeze the page as such, without any JS. This becomes a very impressive document that’s not PDF (ugh, I hate PDFs), but not a live doc either. I’ve had some hits and misses with Polar though. Sometimes, when it screws up a document’s format (because don’t devs love to write weird CSS?), there’s no way to fix that. Also, due to it’s use of a custom browser, it doesn’t support ad-blocking or element removal as yet. The devs have said that they’re working on a solution so we can use our own browsers and the attached technologies, but no idea when that will come along. Last nail in coffin? Polar has a web app and desktop apps, but no mobile apps. But it’s not all bad. Polar is supported by a vigorous sync solution that’s free (you can pay for Pro if you want some cloud storage (2GB-5GB) and hang out at their members-only lounge). The desktop apps are just great when it comes to actual use and reading. The problem? Their design is that you click on an article in their list and it opens a special view where you read and bookmark/take notes in a sidebar. This view doesn’t open in the mobile version of their sites, specially on the iPad, which is where it would be super useful. Instead of that, they do weird stuff like syncing flashcards to Anki. I guess the dev was a student at one point? Also, pricey if you go for premium ($5-$8 depending on how much cloud storage you need. Seriously, how much cloud storage do we need?)
  2. Hypothes.is – This is, at the same time, not an alternative, and a great alternative. Hypothesis just works. It’s great for when I’m reading something on my desktop, need to quickly highlight, so I hit the bookmarklet and seconds later, the JS has loaded, logged me in, and I’m good to go to highlight and take notes. An amazing thing – hypothesis even works on the move – while they don’t have an app, if you go to their site and paste in a url (this is in mobile Safari), it’ll load up the article with their JS enabled, on their fancy via.hypothes.is domain, and their Annotation and Highlighting features work pretty well there. Problems – lack of app means I end up using the layout of the site, which is something I want to escape at times using pretty read-later fonts and text-extraction. Also, hypothes.is isn’t positioned as read-later+notes. It’s positioned as read-later+notes for scholars, and to promote healthy discussion on the web. This doesn’t mean that your notes are all public. You can choose for them to be private if you want. Also, they have API access for all, but no data export that I could find. Also, also, they don’t add a page to your account till you first annotate it. So it’s not read-later, as much as it’s “we’ll store your highlights and notes from around the web”. Lastly, hypothes.is is free, and a non-profit, and has big media sponsors… I… dunno what to think of that.
  3. Liner – I got a free sub to this when I first created a Samsung account. It’s… ok? It’s got apps across all platforms. It’s got a good set of features. Frankly, I didn’t use it much. Primarily because damn it’s pricey! $5/mo which reduces to $4/mo when paid yearly. Looking at hypothes.is and even Instapaper, that’s a lot! Heck, even Pocket is cheaper!

Strange experiments of the fourth kind

So, after I mucked around with all kinds of cross-platform services, I dipped my toe into some platform specific, or interesting solutions –

  1. FiveFilter’s Push to Kindle – Yes, this is a neat solution. I like reading on my Kindle app, and Kindle’s note taking abilities are epic! Every book I’ve read in there has it’s notes stored away safely (really?) in Amazon’s vault. I have exported said notes when I needed them. The problem with this process is that my Kindle experience gets cluttered. Almost all the problems with this process are at Amazon’s end – their library management is pretty s-h-i-t-e. I can’t sort stuff into folders, and for mobi files I’ve exported, if I mistakenly delete them from a device, all my notes are gone too (I think). Also, if I send a document to one device, it doesn’t go to other devices. There’s no way for me to tell the system to send this document to, like, my iPhone and my iPad. Also, even if I send it to my iOS devices, I can’t open the document on Kindle Cloud Reader, which would be a nice-to-have. On the FiveFilter’s side, the problem is that I don’t want to send single documents any more. They clutter my Kindle library up. I want to send a few at a time. So, I discovered –
  2. Epub Press – Epub Press is this awesome thing that lets you take a bunch of tabs, combine them into one big eBook and ship it away. Well, not quite. Their email function doesn’t work. So I can download the files to my dropbox and sync away. This suits me because I can then import the file to the Kindle app on all my devices. But the text-extraction isn’t very impressive. There was absolutely no formatting applied to the end-product, almost as if it were an archive.org eBook. (I know, I shouldn’t be shitting on a free resource like archive.org, but seriously, they need to learn eBook creation from Gutenberg). Epub Press is a fair solution because they allow you the choice of creating a mobi (for Kindle) or an ePub (for Apple Books), and because they let you compile as many articles as you want into a weekly/monthly/weekend reads. If it weren’t for the problems with Kindle, this could have been an ideal solution for me.
  3. Mobile Safari’s Create PDF/Save PDF in Books – I hate PDFs.
  4. Mobile Safari’s Send to Kindle – This is supposed to be from the Kindle app itself, but it doesn’t seem to work for me. Hit and miss. Sometimes, it’ll tell me that it’s sending the document to my Kindle app, and will then just… forget.
  5. Using a journal app to take notes – I used Day One as my primary thoughtsbox. I have a journal in there called Quotes that I sometimes add a good quote to. It’s a nice way to recall some thought years later. But Day One is staunchly not-cross-platform. They keep promising a web app, but haven’t delivered a fully functioning one yet. Their Chrome extension is nice, but I’ve yet to see a corresponding Firefox one yet. Not that I need it. I hacked my way to make the Chrome extension independent of Chrome, but it’s still a jugaad and there’s no good way for me to make extensive notes and highlights on it. I also don’t want to clutter it with read-later stuff. Just doesn’t feel like the right use of the technology.
  6. Publicly blogging about it – once in a while, I’ll want to talk about an article publicly and so I’ll make a blog post with highlights, my notes, etc. But it’s not a very easy process. I have to constantly go back and forth between my site and theirs, to copy content over (because WP supports a ‘quote’, but only one quote to begin a post with. After that you’re on your own to copy paste and format). This method doesn’t work well on mobile. I’d rather have a dedicated reading space which lets me highlight stuff, and then export it, sort of how the Kindle does it.
  7. Not-publicly blogging about it – The same as above, but I don’t publish it publicly, I just keep the notes in Private mode. I like private mode.

There are solutions that I’ve tried over the years and not bothered pursuing or listing here. Apps like Unmark, which do a great job of letting you know what’s on your plate to read, but don’t let you read in a clean environment, or let you make notes, don’t count here. Similarly, apps like Evernote don’t either, because they’re not a read-later solution.

I know there are hundreds of solutions I’ve not tried or talked about. Most of them are closely related to what I’ve listed above. For example, TheBrain, DevonThink, Refind, Google Keep, OneNote, etc are all nice, but don’t fit into the box I’m trying to fill here.

So, dear reader (first of all, thanks for getting to this point), tell me what should I do? Should I bite the bullet and go with the top most solution, Instapaper, which is well priced, focused specifically on reading text (which is what I primarily want), but which is run by someone else? Or should I go with some form of open source solution that might cause me headaches but at least I’ll keep all of my thoughts with me over the years? Maybe I should go with a solution like Hypothes.is, which is free, non-profit, and an interesting technology. Or maybe I should be looking at it from a different perspective, or looking at a solution I’ve never even heard or thought much of? What’s your opinion?

I’m so excited! I’ve been waiting to read this book since last year. I thought I’ll go through some other books before coming to this as part of this year’s #readingchallenge but after 6 books that have been highs and lows, I just couldn’t wait any more!
#bookstagram
#cixinliu #darkforest

Falling into Faith — Acko.net

The following is a critique of a post I recently came across in my RSS feeds-

 

This is augmented by the ease of concerted flagging and other public shaming campaigns, which create a guilty-until-proven innocent environment.

Source: Falling into Faith — Acko.net

This is a weird post, and it set off all kinds of alarms in my head. But I read through the author’s convoluted logic till the end. Some of it doesn’t make any sense, the rest of it makes sense, but is faulty logic. It’s clear that it’s a rambling, onerous post about somehow not protecting white privilege, but also not condemning it. It seems to want to put logic above everything else but the relationship between the example and the conclusion is tenuous.

This line above was the one that sprung out to me the most. The author seems to want to say that the constant vigilante justice meted out on social networks stifles free speech. But forgets a couple of things –

  1. Every example the author gives – James Damore, SubscribeStar – is one of extremism from the right. These are harmful rhetoric, and conspiracy theorists whose right to free speech is somehow being taken away by the people. Somehow, the ‘people’ having the right to decide who gets to live in the public sphere is not acceptable to the author. Instead, pure logic and pure freedom are the only things important to the author. This is, of course, the wrong approach, because there is no such thing as pure freedom. All of life is about the exceptions to the rule. The exception to the rule of free speech is one where someone means someone else harm.
  2. The author seems to want to criticize public movements on social media. But here’s the thing – it’s not like there’s a recourse. Elsewhere in the post, the author criticizes the left for controlling the institutions that mediate over ideas on social networks, namely the Trust and Safety Boards –

bootstrapping their own inquisition in the name of Trust and Safety

This means that the author doesn’t trust the devices created to remove negative influencers from social media, and doesn’t accept that people should be able to run their own campaigns to remove such people from there either. So what’s the recourse? What can people do to root out truly evil ideas from the public sphere? The author falls silent on that aspect. As it is, the tools that Facebook and Twitter (and WhatsApp) have created to combat misuse are woefully shortsighted and pathetic attempts at appeasement. That leaves the users to fend for themselves, so why would they not band together and attack the trolls and bad actors? Yes, they would get a few folks wrong and that’s where the author jumps in again to criticize, but not to give solutions –

Nuanceless policing bots and scripts make it trivial for innocent bystanders to get hurt.

All in all, a frustrating read to go through. Why did I? Well, for some reason, I’m subscribed to this person’s RSS feed and this was a recent article on there. Everything else by the author is purely about technology.

Also, it’s a good exercise in spotting every logical misconception that the author has made. Which ones did I miss?

 

Giving up on WordPress embeds

Back in 2012, I wrote a post called Conversations as a future of blogging. Well, I say I wrote, but actually I must have had a conversation on this up-and-coming platform called branch.com with a few people I invited to it from twitter. Using their tools, I embedded the conversation to my blog on the link above. I thought the embed would last forever, because a) where is branch going to go, and b) WordPress usually gracefully downgrades embeds, right?

Nope. branch.com died three years after launch. They gave us a period of time to request backups of our conversations. I remember doing that, but I never received one in my email. Perhaps they expected me to come back to their site to download the files? I asked all the other people involved in the conversation and none of them cared to request a backup of the copy. This goes back to my posts here about the futility of exporting your data from online services, even though in this case, a full backup was exactly what I needed to recover my blog post.

I was further wrong in that WordPress does no such thing with embeds. In the case of officially supported embeds, I’ve seen the system do this once before and I thought that was standard behavior, but in the case of link embeds, there’s no clear way for it to be possible.

Recently, I introduced a random post finder to my blog. With it, I’ve been discovering a lot of great and terrible posts I’ve written over time. It’s my way of getting closer to my blog.

But it has also left me reeling from all the broken links and embeds that I trusted to work forever. The branch.com embed, images and links I’ve linked to, PDF files I thought would never go away. Heck, even Facebook CDN stuff has disappeared and that company doesn’t let go of any data!

Recently, Automattic introduced inline GIFs from giphy through Jetpack. The model they’re following is pretty neat – they shipped the Gutenberg editor within WordPress 5, and have been extending it using Jetpack with blocks that allow various kinds of content, including GIFs. It shows the scope that Gutenberg has in the future.

Coming back to embeds, Giphy, the company Automattic is leaning on, came into existence in 2013, and I suspect will be out the door before its 10 year mark. Such is the way of life on the Internet. All of these are fads and fads can raise millions, but they eventually all die. Automattic will simply pull out the block from Jetpack and replace it with something else, but we users will be left with broken links and missing context on our blogs.

When the block was introduced some time ago, I played with it and added some GIFs to a blog post. It’s a lot of fun to express ourselves visually. But if branch.com is any indication, embeds come back to bite us later on.

Therefore, I’m getting off embeds. I’d rather download the GIF and upload it to my media. I’d rather take a screenshot of a webpage than to iframe it and hope it sticks around a few years from now. Jetpack already has a massive CDN operation behind them, so you’re never really serving your content directly from your site if they can help it. So there’s no need to worry about storage and bandwidth issues.

As I go through my site, rediscovering old posts, I’ll keep coming across these embeds. Whenever I have context, I’ll try to replace it with relevant information. But, as in the case of branch.com, I will just put a note that explains what happened there, some general thoughts on the topic, and move on. Once bitten by embeds, twice shy now.