You’re better off trying something and having it not work and learning from that than not doing anything at all.
– Mark Zuckerberg
You’re better off trying something and having it not work and learning from that than not doing anything at all.
– Mark Zuckerberg
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.
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.
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
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:
The filtering interface is brought up by:
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!
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:
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.
Continue reading App Splash Screens – The Good, the bad and the ugly
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:
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):
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
Been thinking about using this as a guiding principle in some of my personal projects.
Don’t develop a feature, however trivial or easy to build, till a user asks for it.
That way we know someone wants it enough to ask for it. And, when we deliver, the user will be satisfied/delighted enough to spread a good word about the product.
To help rid the world of bad products, delight the users and help developers, designers, analysts, mgmt work in unison
– Me
A prototype is worth a thousand meetings.
Struggling to fit the product inside time and budget? Reduce the scope, not increase time and budget.
– Laurence McCahill, on Lean Product Management