New idea: minimalist blog editor app

Yet another Chrome1 app idea:

A minimal, no-frills blogging app with markdown editing2, inline tagging support3, and draft auto-sync4 to WordPress and Medium

I find WordPress‘ editor too cluttered (despite the distraction-free mode), and Medium‘s too fiddly-gimmicky. In fact, I write most of my posts these days in another Automattic product – Simplenote, and then copy it to my WordPress blogs, or Medium for final editing, formatting, etc.

My WordCounter Chrome app already supports Markdown Extra. Reusing that code, adding Medium & WordPress API support, and adding a #tag parser shouldn’t take long. The only question is do I care about it enough to prioritise it over all the other stuff that’s on the backlog?

For the last couple of months that I’ve had this idea, the answer has been no.

Continue reading New idea: minimalist blog editor app

AcceleReader – tagging, history chart & beta support

It’s been a good few days of updating all my Chrome projects with various upgrades, and bug fixes. Here’s a quick review of the updates to AcceleReader – one of the newest in my collection.

Update 1 – For the taggers

AcceleReader - Add tags from notification
AcceleReader – Add tags from notification

Add tags to articles from article-added notification when you add them to your Pocket list. The ‘Add Tags’ link in notification opens a pop-up to add tags to that article.

Continue reading AcceleReader – tagging, history chart & beta support

Facebook Android app – a UX minefield

I’m sorry. This is yet another post1 on more UX/UI mess that keeps bothering me.

Starting with something I recently started using after 8+ years – Facebook. FB earned a reprieve from the tech press after its change of heart on native smartphone apps. But their Android app is still way below par for what is the primary user interface for vast proportion of their users.

Here are 2 bits that bugged me right away…

FB Issue #1 – In-post touch areas

Touch Targets - Facebook Mobile
Touch Targets – Facebook Mobile

Facebook states that stories/posts that are posted natively get shared more widely to the followers, compared to those posted as links. Yet, the mobile interface makes it practically impossible to click-through to read those very natively-posted long posts.
Continue reading Facebook Android app – a UX minefield

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

Displaying developer name in Chrome Web Store app listing

Chrome Web Store‘s developer attribution doesn’t seem to be very clearly documented anywhere. It took me a while to figure out how to display my name, instead of my domain name on my app listings. Seeing people ask about this in Chrome-apps mailing list, I thought I’d put the details out here for Google to index.

CWS1 offers two kinds of owner attribution for app2 listings:

  • by domain name, and
  • by developer’s chosen name

Here’s how to set them both up:

Continue reading Displaying developer name in Chrome Web Store app listing

Filter articles in Pocket by length & age

Filtering articles in Pocket, powered by AcceleReader
Filtering articles in Pocket, powered by AcceleReader

I’m happy to announce that the latest update of AcceleReader for Chrome brings article filtering to Pocket.

Articles may be filtered by age or length:

  • By length1, articles can be filtered as Quick Reads (<4 mins), Medium (4-8 mins) and Long Reads (>8 mins)
  • By age2, the articles can be filtered as Fresh (< 1 week), Ripe (1-2 weeks), Ageing (2-4 weeks), and Old (>4 weeks)

The filtering interface is brought up by:

  • clicking on the total time displayed on top left, or
  • by pressing the key ‘.’ (Period).

It can be dismissed in the same manner, or by clicking anywhere on the page.

After reading-time tags for mobile, this is the second big feature I’ve been enjoying using myself, and hope other users like it as well!

Continue reading Filter articles in Pocket by length & age

App Splash Screens – The Good, the bad and the ugly

I’m not a fan of app splash screens. They delay app usage without presenting any useful, or even pleasant, information or interface. To me, they imply either:

  • badly thought out app design requiring loading loads of data before the UI can even be shown, or
  • a pathetic branding attempt that spoils UX by unnecessarily delaying app access

Here’s some thoughts on how to (not) do splash screens in apps:

The Ugly

My pet favourite object of splash screen hatred is the MyFitnessPal app. It has not one, but 2-step splash screen. The first one shows a progress bar, which I assume shows the status of data stored locally on my device.

Myfitnesspal - Splash screen stage 1
MyFitnessPal – Splash screen stage 1

This is followed by another phase of splash screen madness under the Synchronising data title with a rotating symbol this time (so no indication of progress).

Myfitnesspal - Splash screen stage 2!
Myfitnesspal – Splash screen stage 2!

Only after the local data has been ‘loaded‘, and synchronised with the servers, is the user allowed to see the app UI. And despite this, the headline daily dairy numbers they show on landing screen is wrong most of the time. Specially if another app (Garmin Connect for me) has synced exercise calories with MyFitnessPal.

This feels so wrong. Why can’t they just show me the default landing page UI right away, letting me do what I do on most app uses – log food consumption – as quickly as possible. The changes can all be synced in the background.

The multiplicity of logos on the splash screen, as well as several other UI decisions in the app seem to convey that MyFitnessPal has a weak UI/X team being overridden frequently by a politically strong marketing/content team.

Continue reading App Splash Screens – The Good, the bad and the ugly

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