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. ↩
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.
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.
Text screenshots on Twitter are a desire path across the wall gardens around content in apps and platforms, and Twitter’s text-dominant streams.
Twitter cards, though a handicap on pure, free sharing of content, provide a way through the content wall gardens. But even the cards don’t provide the break through text clutter that images do. Specially, on 3rd party Twitter clients.
Trello, probably my favourite software out there, implemented an awesome new feature today – unlimited labels. Before today, users were restricted to the 6 system defined labels. We could rename them to what they meant for us, but couldn’t add new ones. This handicap was removed today.
Thanks for the unlimited labels, team Trello!
However, this upgrade also breaks a very useful keyboard ui pattern.
Earlier, I could press L (shortcut for label interface), followed by digits (codes) of all the labels I wanted added, and be done with labeling a card in one go.
Now, I need to press L, followed by label digit, followed by enter, for each label separately. Adding 3 labels to a card went from 5 key strokes to 9 strokes. Makes it harder, tiresome.
I understand the need to break the earlier pattern because of the possibility of double digit label numbers. These would make it impossible to decipher if L13 meant apply labels 1 & 3, or apply label 13.
My suggested alternative: reduce the number of custom labels from UNLIMITED to 26. Then you can use alphabets as codes for custom labels. Now L1C could mean apply labels 1 & C, while L13 would continue to mean apply label 1 & 3.
I hope 26+6 labels would be sufficient for most use cases though the teams at Trello would have better data to check the hypothesis.
Would love to hear views of Trello UX, design teams.
Summarising what I’ve been tweeting about my early impressions of Inbox.
Started off being surprised by the app speed, both on the laptop and Nexus 5. The Gmail app had become laggy on the N5 recently, and has been slow for a long while on the web. Inbox was pleasantly, surprisingly fast. (Aside: Gmail on N5 may be slow because of the amount of email that I’ve marked for offline storage. No such setting in Inbox).
Getting used to the new sorting concept takes a little effort. While I’ve been using, and loving, Gmail’s automatic labels, they were always hidden away from the view in the main Gmail apps. In Inbox, by default, they’re right there on the main screen, with older email from the primary inbox shoved further down. This can, and needs, to be fine tuned for each user’s taste, but I wonder how many regular users will know how to, or even bother?
After more fiddling around with Inbox: I like it on the phone. It’s fast, it’s clean, and gets right to business. On the PC, I still prefer the good old Gmail. Mainly because I’m over dependent on keyboard shortcuts for everything – actions and traversal – which Inbox doesn’t support very well yet.
Another observation – people like me who delete unwanted emails, instead of archiving them, might have a few OCD issues with using Inbox. The default ‘mark-it-done’ action just archives the email. Doesn’t even mark it read before archiving. Very bad for my inbox hygiene OCD.
Inbox feels like a great tool for people who get large volumes of email. Those with fewer mails may find it an unnecessary complication of the simpler Gmail client.
Which makes me wonder, is the Google Inbox a product that answers the need of valley/tech users, or did Google actually research ALL its Gmail users’ behaviour?
Treatment of email inbox as a to-do list, and focus on quickly dealing with larger volumes of email, shows Google is trying to respond to the chatter around ’email overload’ and ‘disrupting email’, and building up on work that apps like Mailbox are already doing.
My worry is are the chatterati who this app responds to really that big a target market1, or could Google be ignoring the silent masses? The pickup of Inbox, and continuing development of default Gmail app might help answer these questions.
.@julykatrae on Inbox: Google is solving the problem it created by giving away so much space with Gmail. Before it we kept our inboxes lean.
I abandoned the Inbox web app on laptop after the first night. It’s become my default app on the N5, though. The UI of the Android app still feels a bit broken, though.
The first big negative, for me, was discovering that we can’t share links (using Android’s share intents) in emails using the Inbox app. The default Gmail app allows this nicely. It’s sad that Inbox had to break this link sharing facility – can’t add articles directly from newsletters to Pocket anymore, and so can’t quickly mark them done! :(
Another UI fail that slows me down quite a bit: Can’t quickly run through emails by swiping right-left from an open email to next-previous email. This swipe-traversal made quickly running through the updates folder so easy in the Gmail app – start at first email, and quickly read through all before archiving/deleting them all. Doing the same in Inbox app, requires a lot more tap actions!
A final, small hiccup – In the Gmail app, users could save any attached photos directly to Google Drive. This too seems to have been broken in the Inbox app.
I like the direction Google has taken with the Inbox app. It may not suit all Gmail users, but for those like me who get a lot of email (and are willing to tune the app to their needs), it’s perfect. It also helps that it isn’t replacing the original Gmail app, which may still be a better option for a lot of users. There are still quite a few UI gaps, which I hope will get filled quickly since the app is still in its early roll out phase.