Skip to main content

Overcoming Application Fatigue

How many apps do you have on your phone right now? I have 178. Of these, I have used 45 in the last month - that's 25.2% of the total. What's happening here? Clearly I thought these apps had some merit or I wouldn't have installed them in the first place. But at some point (or several points), I reached app overwhelm and abandoned all but the tried and tested ones.
Not another app!

To give you an example, I must have tried out over 20 project management systems. I started with Evernote, graduated to Zoho Projects when I had to involve other people, then moved to Podio, then moved to JIRA, then started using Trello as well plus a bunch of Google Spreadsheets. Eventually it all became too much and I returned to the killer app: paper..

As a software developer, I feel like a bit of a traitor to the cause. If I can't handle lots of apps, then how can anyone else? I occasionally come across lists of '99 MUST USE APPS!!!' and feel almost nauseous. I'm barely coping with the apps I have right now, how am I meant to handle more?

Apparently I'm not the only one. A month or so ago, an industry connection told me that he'd abandoned a CRM rollout because his staff were suffering from application fatigue. They were already using three different apps and the thought of struggling up another steep learning curve was enough to have them ducking for cover back to a simple Google Spreadsheet.

So what are we to do about it? There's obviously utility in having lots of apps otherwise people wouldn't make them or buy them. I genuinely do prefer the user interface of Podio or Zoho Projects over paper (my handwriting is terrible, it's easy to lose bits of paper and it's hard to reorganise tasks without squiggling and crossing out everywhere).

Wah? What was I meant to buy from the shops again?

But I really don't like the overhead of having to wait for an app to load. It might only be a couple of seconds, but that's enough time to lose my train of thought.

Plus I'm likely to get distracted if I open another window whereas the only popup ads you'll see on paper are from those delightful children's books.

What's more paper allows me to have a 'multi screen' effect. I can have my code editor open on my laptop and my task list next to me on a piece of paper.

How might app developers draw lessons from paper?
Here are three ideas I have:
1. Explicitly encourage people to use your app in a multi-display environment: research backs up my preference for having a notepad next to me. According to Microsoft, NEC and Apple (no bias at all I'm sure!), people with multiple monitors are far more productive. To make things more objective, this 2014 study (not funded by monitor manufacturers this time) found that researchers could be 36.5% more productive when using two displays to conduct systematic reviews. Most apps have an introductory tutorial that explains how to use them. Why not say outright: "You'll find it much easier to use <insert-awesome-app-name-here> if you get a second monitor or set up your iPad next to you so you can glance across rather than having to switch windows on your laptop." I've never seen a piece of software that has explicitly suggested this.

2. Focus on interoperability: the great thing about paper is that you can slot it inside a notepad or punch holes in it and stick it in a 3 ring binder. Men may be their own islands but apps should not be. What annoys me is when I can't get my data out of an app to connect it to another tool. I like Google Spreadsheets because it's so easy to copy and paste data out.

3. Don't be unique: I get put off apps when they have unique user interfaces that I haven't seen before. Notepads come in all sizes and colours but the fundamental process of writing on them is exactly the same. All I need is a pen or pencil and I'm sorted. With apps though, it can be incredibly confusing if the developers haven't followed good UX practices. This is where trends like Google's material design standards are so useful. Even if the standard isn't optimal (e.g. material overlay buttons can be annoying), at least everyone is used to using it.

How might users avoid application fatigue?
1. Get a second display. As mentioned above, it's a lot easier to use multiple apps if you have more than one display. If you don't want to use a second monitor, take advantage of your phone or tablet. One example could be to have your task list open on your phone and your main activity on your computer. If you have an idea while you're working, don't switch tabs on your computer, just open up your phone and put it in there.

2. Slow down: just as you shouldn't try to master more than one habit at a time, nor should you try and learn several apps at the same time. I've done this on many occasions and what ends up happening is I get overwhelmed and ditch all of them. Better to choose one kind of app (e.g. book keeping), experiment with a few options, choose one you like and then focus on learning the traps.

3. Customise your apps: out of the box, most apps won't meet your needs. It's impossible for the developers to get everything perfect for every kind of user. You'll need to spend some time yourself (or engage a system integrator) tweaking the settings and integrate them with your other systems.

4. Connect the dots: the bane of anyone's existence is double entry. If you have to type something into two places, chances are you'll ditch the software in short order. Look at using services like Zapier or Cloutex to synchronise your apps so they play together nicely.

Interested in your thoughts. Have you experienced application fatigue? How do you avoid it?


Popular posts from this blog

Getting current time in a specified timezone using Deluge script

Recently I was working on a custom function for Zoho CRM which required me to get the current time in a specified timezone. I assumed that zoho.currenttime would give me the time based on the timezone chosen in the organisation settings but discovered that it always gives it to you in PST. The Zoho Partner team gave me this snippet to solve the problem: current_time_in_timezone = zoho.currenttime.toString("yyyy-MM-dd'T'HH:mm:ss", "Australia/Sydney").toTime("yyyy-MM-dd'T'HH:mm:ss"); If you need the current date, do: current_date_in_timezone = zoho.currenttime.toString("yyyy-MM-dd'T'HH:mm:ss", timezone).toDate(); To figure out what you can put in for the timezone part, refer to

searchRecords with multiple criteria in Zoho CRM API

NB: this blog post is no longer relevant as API v2 lets you use searchRecords with multiple criteria :) I discovered something really cool tucked away in the Zoho CRM forums today. For the history, check out this thread . In summary, the searchRecords API task in Zoho CRM is impossible to use if you have multiple criteria and in general it's pretty annoying to get the single criterion right. In the forum thread, Zoho Support advised that you can actually use getRecords with a view name. This feature is not documented on the getRecords page at all but I can confirm it works:D This is really, really cool. It's going to make my life as a Zoho dev much easier! Instead of having to do something really inefficient and ugly like: leadRecords = zoho.crm.searchRecords("Leads","(Created Time|<|" + yesterday_date +")",fromIndex,toIndex); for each ele in leadRecords { lead_source = ele.get("Lead Source"); createTime=(ele.g

Debugging Deluge script in Zoho Creator/Zoho CRM

Deluge is a powerful language that simplifies a ton of things, e.g. database lookups. But I have to say, it's very painful to debug. Interpreting longish scripts takes ages, error messages are obtuse if they exist at all and even the hints in the IDE don't always help (ever tried using containsIgnoreCase based on the auto-complete suggestion?). Here are my tips for debugging code when it's not working. 1. Split your code up into small custom functions. Nothing's more painful than waiting 30 seconds for a really long (say 1000 lines) HTML page to save and only then get feedback on a syntax error. I've got a few apps that are like this and it's not fun to work with at all. I haven't seen any improvements in the compile speed over the last few years, so my conclusion is that it's always best to write most of your logic code as small custom functions and then build that up in the HTML page so that you'll get quick feedback on syntax errors. 2. If