A PowerPoint presentation should have ten slides, last no more than twenty minutes, and contain no font smaller than thirty points.
The “or else” implication, in Mark Twain’s words:
I didn’t have time to write a short letter, so I wrote a long one instead.
j/k navigate to next/previous post as expected. However, the more ‘lay’ user-friendly left-arrow/right-arrow versions don’t.esc key works the same as browser’s back button – navigating back through history stack (i.e. going back to last viewed post).
l, works as expected. Adding f as 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 f instead of lGreat art makes you wonder,
great design makes things clear.
John Maeda, in ‘The laws of simplicity’
Yet another Chrome1 app idea:
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 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 recently switched my primary twitter app from Plume to Fenix. On UI and features, both have their pros & cons, but Plume’s usability had taken a massive dive recently with long delays and freezes. Fenix, on the other hand is as fast as they get. Probably, even faster than Twitter’s own app!
While Fenix is faster, prettier, and generally more pleasant to use than Plume, it also has a few serious drawbacks – especially for users like me, with multiple Twitter accounts.
After 3 weeks of using it, I’ve even come to like some of its drawbacks (no multi-account integrated timeline – allows focus), and been desperately hunting/craving/begging for others to be removed.
This post is a list of those nettlesome issues, and my suggestions on how to remove them.
Currently, switching between timelines on two accounts requires: an edge swipe and a slightly problematic tap1. While this is an improvement from the earlier edge swipe + 2 taps, it’s still not fast or efficient enough.
Suggested solution: Swipe on action bar to switch between accounts.
Swiping on the list of tweets currently switches between various columns – timeline, mentions, DMs, favourites, etc. Swiping on the action bar would switch between accounts in a similar manner. In fact, this UI pattern is already used by Chrome for Android – we can switch between adjacent browser tabs by swiping on location bar / action bar2.
The compose tweet function in Fenix is better than the timeline feature – user can start composing from either account and switch, with 2 simple taps, to another account. It also has the best integration of ‘drafts’ functionality that I’ve seen across any twitter app so far3.
However, it lacks a very important feature for multi-account users – ability to post the same tweet from multiple accounts in one go. Plume accomplishes this quite well (3rd screen in the image below), and it would be really great to see a similar functionality come to Fenix.
The changes requested so far are (mostly) UI tweaks that enhance experience for multi-users. The muting/filtering feature upgrade requests below, however, are highly relevant for all users. Also, of all the functionality in Fenix, this is one area where I feel it really needs to improve by quite a bit.
The current implementation of muting in Fenix works by applying the set filters on new, incoming tweets. While this works for long-standing filters, it’s not very useful when you wake up in the morning to see your timeline full of tweets with a random, useless hashtag, say #ReplaceAMovieTitleWithGoat.
Now, even if add a new muting rule to filter out that #tag, it only prevents new tweets from being added to my timeline. I still need to hurdle past the 100s of unwanted tweets with that #tag already in.
Suggested solution: Every time the filter/mute list is updated, run the filter function on all the tweets in the current timeline. Just as it would be run on incoming tweets.
My hunch here is that the filter function is being run when the tweets arrive from Twitter’s backend to the app, and only the unfiltered ones are sent for storing locally to the content provider4. For filtering (and unfiltering) of already downloaded tweets to work, the code needs to be changed so that it stores all tweets, and filters them when the content resolver/adapter4 fetches them from content provider to populate the list.
Twitter’s API provides, for every tweet, the source app used to post that tweet. Fenix uses this information in the detailed tweet display mode:
While this may be marginally useful from information perspective, it’s far more useful if the app could also provide a filter to mute tweets published using certain apps. Plume did an excellent job on this front, and prevented cluttering of timeline with automated tweets published using some very unsocial apps:
Creating simple word based filters is quite straightforward in Fenix. However, that’s all it supports. There is no support for defining filters as regular expression. Furthermore, due to a possible snafu in the app code, some text-based filters don’t work either.
As an example, I have been using ‘.@’ as a filter for a while on Plume. This filters out the tweets that begin with ‘.@twitterhandle …’, which I rarely find useful or entertaining, on Plume.
It also filters out an occasional valid tweet, which could be avoided if Plume supported regex filters, in which case the filter would have been: ^.@\S
Fenix, sadly doesn’t accept either. There’s no support for regular expressions in filters. And using ‘.@’ produces a confusing result – filtering out a lot of tweets, both those beginning with, and not beginning with, ‘.@’. My guess is that the text string provided by the user isn’t sanitised by the app before being added to the filter regex in the code.
Fenix currently offers 3 options for image previews in timeline – large (left screen below), small (middle screen), or none.
The large screen option looks beautiful! However, most images take up so much screen real estate that browsing through the list becomes a bit of a chore.
The small screen option makes the list quite nice and compact – perfect for quickly scrolling through. However, the size is so small that for most images, the preview doesn’t even offer much of a hint of the full image’s content. Result is user opening a lot more images in full view mode.
I really like Plume’s approach here:
full-column-width preview, cropped to a standard height.
Cropping by height ensures the image leaves space for more tweets, while the full-width preview gives a much better idea of the image’s content. It would be wonderful to have a similar middle-path image preview option in Fenix.
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.
A few weeks back when Trello announced their unlimited labels update, I wrote a post about how it broke my usage pattern by significantly increasing keystrokes required to label cards.
Just discovered, by mistake, an even faster way to label than I’ve ever used before. Not sure if this is new, or I was just doing it the harder way all this time.
When hovering over a card, or with a card open, just press the number(s) of all the labels you want to toggle. No need to prepend it with ‘L’ at all!
Here’s how the keystroke count (from the earlier post) looks now.
Target: toggle labels 1 & 3.
My old usage pattern: 4 keystrokes (L + 1 + 3 + Enter)
Forced usage pattern after unlimited labels update: 6 keystrokes (L + 1 + Enter + L + 3 + Enter)
New usage pattern: 2 keystrokes (1 + 3)
Simply put, the number of keystrokes to toggle N labels has gone from N+2, to 3N to just N.
I’m not just pleased, I’m positively delighted! My love, respect, and addiction, for Trello just keeps on increasing!
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.
And, thanks for an awesome product!
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.
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.
Posted from WordPress for Android
Continue reading A caution, while redesigning the old, boring credit card form
