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.
First impression
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?
Second impression
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.
Aside
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.
Aside:
.@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.
Summary
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.
This post refers to my work with a startup. Like with all work and consulting projects, I wait at least 6 months before writing/tweeting about them.
I’m not a fan of the usual sign-up flow that most web products & services employ. In its most primitive form, the the flow goes something like this:
New user visits website
Clicks ‘try/sign-up’ button; is asked to fill a form providing certain details1
On successfully filling up the form, shown a message asking to verify email address
User goes to their email, clicks on the link
Shown a page saying email is verified. Asked to login to continue…
As a part-time marketer, more than as a user, I hate this flow. It is filled with user drop-off opportunities/hurdles (#2, #4, even #3 & #5 occasionally), and sacrifices quality for quantity (of captured user details).
Instead, here’s an alternate flow for an imaginary developer-focussed API service/platform:
Visit the website
Click ‘try/use’ button
Go straight to new user’s custom dashboard (create a temporary random user id for them)
Let the new user play around with the dashboard, with the api playground (similar to what google has) – get to know the platform
When they want to generateanapi key for their apps, show them the simplest sign up form which gives them immediate accesstoapi keys (without email confirmation).
Inform them on the page that they’ll need to confirm email within X days, or keys will be disabled.
Separately, send them an email confirmation link saying they need to confirm email in x days, or keys will be disabled.
As a precaution, set really low, check-features-out level api limit on the keys till email is confirmed.
Even if users leave after playing with the dashboard, but without trying to create a key (and providing an email address), store a cookie in their browser with details of the temporary user id. So, if they come back, you can still let them continue from the same state they’d already explored instead of starting again.
Now, here are some benefits from the marketing perspective:
Fewer / later hurdles for user, higher user engagement
Users get to experience a lot more of the product, and get engaged closely with it, even before they’re asked to do uncomfortable things like fill a form or confirm an email address. Playing with the dashboard, or creating API keys and testing the API also create a small lock-in for the user, by making them comfortable with your API.
A lot more of the funnel becomes visible.
Instead of seeing a large set of users drop out without signing in, and wondering why, you’ll see some of them filtering in to later sections of checking out the dashboard, using api playground, and signing up for keys. This is valuable feedback in refining your product, as well as the sign-up funnel.
Higher quality user data The user data (mostly, email addresses) you’ve now gathered, are of users who checked out your product at a deeper level than just some marketing literature, and decided they wanted to play with it so needed the API keys. A much more relevant target audience to engage, and likely to upgrade, than the current one – where everyone who even wants to know what your product looks like has to first sign up. Also, no more dealing with lists of [email protected] email addresses.
If you’re using advertisements to increase sign-ups, Isn’t it even more imperative that you reduce all possible hurdles, and create all possible incentives for the new visitor to spend as long as possible on your product, sign-up and continue using your product? (Side note: Could I have created a longer sentence?)
We’re living in an era of creative disruption, and no thing – however big or small – is immune.
A small one, out of the millions of things being disrupted, is the credit card form. After years of suffering the old and boring credit card input form, I’m glad to see designers and developers attempt new UI patterns for the payment form.
Brad Frost’s Single Field CC FormKen Keiter’s Skeuomorphic CC Redesign
Some of the new attempts are really beautiful. Others make filling the forms much easier. A few manage both. I like them. I like the attempt to remove a painful hurdle to payment (as a user) / conversion (as a business manager).
Yet, could they be just creating a new hurdle while removing the old ones?
I use LastPass everywhere. Including to fill in credit card forms for purchases (from an almost always empty bank account).
While I’ve disliked the old credit card forms ever since I first encountered them, with LastPass, they aren’t much of a hindrance any more. Just click a button, enter a long, meaning-less password, and voila! LastPass fills the form, I get new running shoes and sink deeper into bankruptcy.
I’m sure quite a few other people too, irrespective of their bank balance status, use software like LastPass, 1Password, etc to fill in their credit card details on web, and, maybe, even in apps.
The newer variants of the credit card forms need to ensure that they’re not just easier to fill for those who type in details manually, but also for users like me who use other software to fill the forms for them, specially on the desktop. They could do this by the showing a new or old version of form, after checking whether Lastpass, 1Password, or other similar Chrome extensions are installed. Or they could have a full form hidden on the page, with fields only made visible one at a time. There must be quite a few technical solutions. All of them more elegant than the two I just shared.
But my point is that care needs to be taken. Else a variant that was meant to slightly ease the pain of one set of credit card form fillers, would end up significantly increasing the pain for another set.
