Fred Wilson wrote about signing up to Pocket, and requested suggestions for becoming a power user. Naturally, I wanted to comment with a plug for my Chrome extension for Pocket. I also wanted to offer my 2c on why I found Instapaper better than Pocket 1.
Navigation in reader
- There are no visible cues hinting at ability to navigate from one expanded post to the next (or previous).
- Navigating back to the post list (using back button), and then to next post makes it slow, and click heavy.
- Keyboard shortcuts work, but there are again no visible cues indicating even their presence.
- No visible hints that any keyboard shortcuts exist
- Keyboard shortcut discoverability is solely by trial and error, or ‘Google’
- Traditionally, pressing ‘?’ (in, say, GMail or Pocket) brings up relevant shortcuts modal. Doesn’t work in reader.
- One suggested hint could be to place a keyboard icon next to the help (?) icon, at the bottom, in the left navigation bar.
- Navigation shortcuts
knavigate to next/previous post as expected. However, the more ‘lay’ user-friendly
esckey works the same as browser’s back button – navigating back through history stack (i.e. going back to last viewed post).
- A better (expected) implementation would be to jump out of expanded-post view to the posts list view, ideally scrolled to the last viewed post.
- Like keyboard shortcut,
l, works as expected. Adding
fas an additional activator would be useful – a lot of platforms use favourite as an alternative to like, and some users may be more behaviourally trained to press
By integrating ‘reading’ and ‘writing’ in the same app, you’re forcing the bigger user group1 to also confront tools designed for the smaller user group.
On mobile – skewed by design more towards consumption, than creation – I assume the disparity in these two user groups is even bigger.
Having a standalone reader app, allows it to reach a much larger use case – ‘Help people follow, read, discover’.
Compare this to current use case – install it if you…
- post to WordPress frequently from mobile, or
- love reading in WordPress reader, despite having little use for other three tabs – write, manage, and notifications?!
A really good standalone reader helps plug in a singular user need2 – reading. That need, in terms of following blogs and websites, only rarely overlaps with the other need that the app currently fulfils – writing.
Though it will place it in competition with feed readers like Feedly, it also has 2 unique benefits as well:
- Close integration with a writing platform (related posts, comment & like directly from reader),
- The abandoned Google Reader audience that just wants to follow and read feeds, without being overwhelmed with magazine interfaces and more.
A good, successful reader mobile app with large user-base will, eventually, help close the RoI loop: suggest (through ‘discover’) other WordPress/Jetpack blogs, creating an incentive (or delivering reward) for creators using WordPress.
One definition of readers and writers:
– Writers: 7-day active writers – users who posted at-least once a week.
– Readers: Unique visitors per week – including logged-in users, not-logged-in readers, and from feed readers.
Another definition (more relevant to determining use case ratios):
– Writing: Posts /week.
– Reading: Page views /week – again, including not-logged-in readers, and from feed readers. ↩
Should some day also write a similar, smaller, post on WordPress Calypso’s interface – how it needs to be split from current two, into three sections. Currently, the ‘write’ and the ‘manage’ use cases are mixed into the same tab, while ‘read’ is in its own.
Ideally, ‘write’ and ‘read’ – each a singular, frequent use case – should have their own tabs. ‘Manage’ can be in a far-removed tab, or behind a ‘manage’ button. ↩
Yet another Chrome1 app idea:
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.
For consumers of content tags, or #tags, serve two primary functions:
- The Follow function: To follow news of interest (e.g. a column with #lbl tweets showing latest updates from the race without me having to follow it live on TV), and
- The Filter function: To filter out specific content from the stream for various reasons, such as
- to either avoid listening news before we want to (match scores, movie spoilers), or
- to avoid getting drowned in updates during big events (SXSW, Google IO, WWDC, IPL, SuperBowl tweets taking over the timeline for brief periods), or
- to remove news from the timeline that we’re not at all uninterested in.
Content & platform companies all love the follow function, and have tried to make it as easy as possible for users to access it.
It’s understandable. Apart from allowing easy search, this also presents a straightforward way of targeting advertising to users based on interests. This ability to show relevant advertising – Specialized Shivs to users following IronMan world championships, and the latest BAAS to developers following Google IO – is extremely valuable to these companies.
The filter function, on the other hand, is almost universally neglected. None of the content consumption platforms that I use – Twitter, Google+, WordPress and Pocket – offer any easy built-in way of filtering out content. All of them make it trivially easy to follow specifically-tagged content using tags or #tags.
A large number of popular 3rd party Twitter clients have the feature to filter out specific content, indicating the strength of user demand for the filter function. That 3rd party clients have this feature, also indicates that technical complexity isn’t the reason holding back content platforms themselves from providing this function.
Users want to cut out noise & irrelevant info from their content streams, yet none of the content serving companies make it easy for them.
Are there any technical, UX, business, or legal reasons for most content companies not providing filtering functions, or is it just a conscious, unfortunate, neglect of end user needs?
I’d really like to know.
My dear Google & WordPress overlords,
We need to talk about something. Keyboard Shortcuts.
I like both your products. And even if you refuse, despite all the frustration, I will keep using both your products. Yet, I request you, as I must, to please spare me, and thousands of others, the misery of trying to recall two different sets of keyboard shortcuts. Please, our dear software overlords, shower us with some of your infinite kindness, and reconcile your keyboard shortcuts for compose boxes/areas/windows, and anything else they may be used for.
As a frequent user of Gmail, Google Drive Documents & Sheets, as well as WordPress, I’m quite tired of remembering 2 different sets of shortcuts. I’m bored with pressing Ctrl-K in WordPress, expecting an insert/edit link box to appear, and of pressing Alt-Shift-O in Gmail and wondering why an ordered list wouldn’t appear.
So I, your devoted user, humbly request you to please have pity on my puny brain, and reconcile your respective sets of keyword shortcuts for text composition.
Yours, and yours only,