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:
The Ugly
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.
MyFitnessPal – Splash screen stage 1
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).
Myfitnesspal – Splash screen stage 2!
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.
Clutter Free, my favourite Chrome project, crossed 2000 weekly active users today – a year and 17 days since the first alpha version was uploaded on to the Chrome web store.
It’s my favourite because of its minimalism –
single purpose (prevent duplicate tabs),
bare minimum UI (a browser button to switch it off/on),
a single background script that does all the work
The users seem to agree. It has the highest average rating of all my projects (excluding the recent AcceleReader for Pocket which has less than a 10th of the users), and the reviews are overwhelmingly positive (except the one that’s confusing me).
The journey to 2000
The growth so far has been all organic – an indicator that there’s a need for this functionality natively in Chrome, like in Firefox. And a bigger indicator of how lazy/miserly I have been about promoting it.
Here’s to the next 10x, hoping I can keep it simple and growing.
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:
Count of unread articles in my Pocket, and
Estimated reading time for each article.
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):
Read a random article (from my then \*huge\* Pocket list)
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!
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.
There’s a small difference between his order and mine – it’s not just the ‘please’ or the ‘curry’.
He was speaking the lingo of a regular – each word of his order meant something specific – dish (Chicken katso), size (small), base (rice), and optionals (curry). Mine was close, but my server had to separately ask me if I wanted curry on top (yes).
His order statement wasn’t just about efficiency, it was also about signalling – that he was a loyal customer, one who spoke their lingo.
Next door to Kokoro is my favourite coffee shop in town, Harris + Hoole. They’re a chain, owned by Tesco, but with a very independent, neighbourhood coffee shop vibe. You place your coffee order any way you want1 and they happily make it for you. You can even walk over to the Baristas and chat about your coffee, any special mods, day’s weather, or anything else that suits your fancy.
Contrast this one of the most successful marketing & loyalty schemes ever – the institutionalised coffee ordering terminology at Starbucks. It communicates loyalty, gives the customer a feeling of being on the ‘in’, is flexible to let the customer tweak and be unique, all the while being extremely efficient at communicating the order to the Barista. By opening up their internal coffee lingo to the customers, Starbucks created a word-of-mouth marketing & loyalty program that money couldn’t buy.
And they insist on getting customers to learn it2 – by repeating your order in the correct manner when you don’t order it in the lingo. So that when you get it right after that 5th coffee, you’ll feel the quiet joy of accomplishment, of finally belonging to the clique. Welcome to Starbucks elite!
Does anyone know of companies / brands outside retail who have created marketing assets out of their insider lingo? Any startups who’ve created, or tried to create customer loyalty by creating a niche clique?
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.
1. Easy switching between accounts
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.
Swipe on action bar to switch between different Twitter profiles.
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.
Swipe on the list to switch between columns of current profile.
2. Add ability to post same tweet from multiple accounts
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.
Multi-account posting
3. Better muting / filtering functionality
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.
1) Apply new filters to both new tweets and the tweets already downloaded
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.
2) Filter out tweets sent using specific apps
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:
Tweet source app name
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:
Mute/Filter tweets based on source app
3) Create filters using regular expressions, or even clear text.
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.
Allow regex based mute/filter
4. Better image previews in timeline
Fenix currently offers 3 options for image previews in timeline – large (left screen below), small (middle screen), or none.
Image preview needs a medium/cropped option along with the current large & small ones.
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.
