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.
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.
iDoneThis 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.
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:
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:
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.
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).
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.
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 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.
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):
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!