The power of a single statistic (to distract)

“I know that major API changes are always a pain for developers and they would rather not have to deal with them, but please keep in mind stats like “42% of malicious extensions use the Web Request API” when you’re considering what we’re trying to improve here.”

—Justin Schuh, on Twitter. (Also stated in Google’s official post here)

Google is using a large number—42% of malicious extensions—in isolation to justify a decision. This number shows that a large proportion of ‘bad developers’ use this API. But this single data point gives no clue about how big is the total pool of developers using this API.

Are bad developers a large proportion of users of this API, or are they a tiny minority? In the latter case, Google’s action to deprecate/restrict the API may be fairly justified. In the former case, they could have chosen a better, alternative approach in dealing with the bad actors, rather than punishing the mostly good users.

An analogy for case 1:

Bank decides to close all doors leading to the street because 42% of all robbers walk-in through those doors.

Analogy for case 2:

Bank decides to close all waste disposal tunnels because 42% of all robbers sneak-in through those doors.

All we know is that 42% of robbers come in through a point. We don’t know if it’s the main customer entrance, or the waste disposal.

If this statistic was a big argument for this decision’s approval inside Google/Chrome-Dev, then they really need to revisit their decision-making fundamentals.

I seriously doubt this though. Googlers are very smart. They are dealing with mostly smart people on the outside. This number is not for them or us. This number is being published solely to turn the narrative, for the common reader, from ‘Google blocking APIs that stop ads and tracking‘ to ‘Google blocking APIs that stop malicious extensions‘.

Continue reading The power of a single statistic (to distract)

Introducing: Done – Chrome extension for iDoneThis

iDoneThis puppyiDoneThis is a unique productivity tool that begins where normal productivity tools finish – after you complete a todo/task. The core idea is very simple – log your completed tasks in (as you go, or once daily), and then track, search, tag, discuss, share them as you want.

To log a task you can either email a specified email address with completed tasks (better: just reply to their daily emails), or go the iDoneThis website to log the tasks.

Users can be part of (and post dones to) multiple teams, say one for each project or department. Completed tasks can be #tagged for easy organisation, and team members can comment on and/or *like* each completed task.

Productivity hack: Close your email client!

The log-by-email option used to work for me till, as a productivity hack, I decided to keep my email client and Gmail tabs in a default closed state *all the time*.

The hack’s worked brilliantly! There’s no notifications, and no more quick-check-if-there’s-any-important-new-email only to spend 15 mins going through unimportant, but interesting ones. I open the email client now only when I want to send an email, or am taking a break so I have time to spare. No more interruptions!

The downside to this successful hack is that now I don’t want to open the email client, more recently the Inbox tab, or the iDoneThis website just to send a one line completed task email. And so, slowly, I stopped logging any dones at all.

The real deal: Done!

Done - Chrome extension for iDoneThis This new extension, Done!, is my solution to this problem – a way to quickly log completed tasks to iDoneThis without sending an email, or opening the website. Quick, simple, single-purposed.
Continue reading Introducing: Done – Chrome extension for iDoneThis

Clutter Free crossed 2000 WAUs

Clutter Free for Chrome
Clutter Free for Chrome

Clutter Free, my favourite Chrome project, crossed 2000 weekly active users today – a year and 17 days since the first alpha version was uploaded on to the Chrome web store.

It’s my favourite because of its minimalism –

  • single purpose (prevent duplicate tabs),
  • bare minimum UI (a browser button to switch it off/on),
  • a single background script that does all the work

The users seem to agree. It has the highest average rating of all my projects (excluding the recent AcceleReader for Pocket which has less than a 10th of the users), and the reviews are overwhelmingly positive (except the one that’s confusing me).

The journey to 2000
The journey to 2000

The growth so far has been all organic – an indicator that there’s a need for this functionality natively in Chrome, like in Firefox. And a bigger indicator of how lazy/miserly I have been about promoting it.

Here’s to the next 10x, hoping I can keep it simple and growing.

Article reading time in Pocket’s smartphone apps

Accele-reader - Power up your Pocket experience

I’m a heavy Pocket user, and a big fan of the service and their apps. However, lately I’d been feeling that Pocket had become more a never-again-opened archive of ‘articles I found interesting’ rather than ‘articles to read later’. My Pocket was bulging with loads of articles from years past by, many outdated, others irrelevant, a few real gems hidden under the tons of hay. It was time to act to save my beloved Pocket1.

After a bit of further study, and borrowing from the maxim – you improve what you measure – I decided that I needed two extra features:

  • Count of unread articles in my Pocket, and
  • Estimated reading time for each article.

Not finding anything on Chrome Webstore, or Android Play Store, that covered both these points in a single app, I decided to get my own hands dirty.

Last December I started work on Accele-reader for Chrome (formerly Pocket Plus). The target was to add to Pocket the few features that I’d been wanting for a long time (but were too trivial/off-focus for the product team at Pocket to develop):

  • Unread article count,
  • Estimated reading time for articles,
  • Trello-like article ageing,
  • Offline add-to-Pocket, and
  • Read a random article (from my then \*huge\* Pocket list)

Accele-reader was, for my own use, a big success. Article counts, offline adds, and random articles were a bonus, but colour-coded reading time estimates were a big, big win!

However, with the good came the bad – the reading time feature was so good, that I desperately started missing it on the phone app2. A number of users also wrote in asking if I could somehow provide the article reading times on the mobile apps as well. I wasn’t alone.

Last week, another user – Konstantin – wrote in with the suggestion of a clever work-around. And here it is – reading time estimates for articles, now in your Pocket phone and tablet apps!

Continue reading Article reading time in Pocket’s smartphone apps