7th September 2011

How To Kill An App: Nagware

Thoughts By 6 years ago

There are many different ways to kill an app, and I will write about them in later blogs, but the one that has been causing the biggest fuss around here lately is the concept of nagware. If you look at it from one point of view, and one point of view only, then nagware will result in more signed up users. So if that is all you after (the only reason I can think of as to why that would be the case would be selling the email addresses to spam agencies), then by all means, go down the nagware path. If however, you are not a robot and have the ability to think laterally then maybe you would like to ponder this for a moment and ask yourself why nagware is not such a good idea. For a generic discussion, I have included the common points that get mooted around in this kind of argument:

People aren’t signing up using the login button

What you have to ask yourself is, why should a user sign up? What benefit are you giving to a user to justify the tedious task of signing up to something on an iOS device? If the user thought there was a benefit to trading there contact information with your service in order to increase their interactivity with it, believe me they would. What you are not doing is giving them a reason why they should do this, and you really think forcing them to do something they do not want to do is going to give your app more users? I’ll let you ponder that for a moment.

But we aren’t forcing people to sign up

That’s true, your app is not as bad as it could be. Having that said, you’ve made it worse by nagging the user every time they open the app. If there is one thing we can learn from Apple it’s that user experience is key to a products success, and you have already sacrificed a large chunk of that for the tiny value a users email address brings. Just before I was asked to review an app, I won’t say which one it was but it had nagware on the front that requested the users login or skip the login page, now what people have to realise is that the eye can only focus on 1 part of the screen at a time, and that part in the case of your average login screen will often be the text boxes and the login button. Despite the fact that you have a “skip” button placed in the lower part of the screen, the user has already profiled your app as requiring a login for use, an example is the following screen:

What do you see?

You’ll notice that it is blurred (except for the text boxes where the brain first focuses), and the reason I did that (apart from trying to protect the app in question) is that this is what the human brain first sees when they open your app. Everyone obviously recognises this as a login screen. They don’t even get to the skip part unless they look at it carefully.

Now I have only discussed login splash page nagware here, I have not gone into Alert View login nagware, however this is just as vile as the login splash page. Instead of just displaying at the start, it will continually pop up in front of the user while they are using the app, and do I really need to get into why using popups are a bad idea? If you are interested as to why they are, ask yourself why the majority of browsers have popup blockers embedded in them.

We need the user numbers

This is the core of the one dimensional argument I was talking about at the top of the page. Ask yourself, why do you “need” users on your system? What is that you are trying to do with them? A common answer to this question is statistics for sales, you may need a strong user number to sell your service to customers. If this is the case I would highly recommend services such as OpenID or Facebook Connect, these will let users who have already gone through the tedious process of signing in on another platform login to your app and start using it as a normal user would, and it frequently enables sharing of your apps output to people in their social network, which results in more exposure for your app. I’m not saying disable your login functionality entirely, just allow people to login using easier methods. A common argument against this is platforms such as Facebook Connect allow no way for the client to connect with his user. This is actually a fallacy since every time a user is using the app, they are connecting with you (especially if its driven by a web service), I often see this as an excuse by people who simply wish to “connect” with their users by sending them what basically amounts to spam email. If this is your bag, then the only way I could see this happening is with a push notification that adds a badge icon to your app whenever a new announcement about your app or service has been announced (note I did not advocate the use of push notifications in text or sound format for this purpose), this is passive, doesn’t interrupt the user and allows them to look at the apps newsletter in their own time. On top of that, it lets you “connect” with every single user of your app, and while I do not deny it would result in some angry users, it would on the whole reduce the amount of anger towards your service due to its passive nature.

Despite the illogical nature of nagware, some people still insist on its use. Here at B2Cloud we used to have a saying: “We don’t produce crap”. I never hear that being mentioned when nagware is discussed.

Recommended Posts

How to create an Uber successful digital product vision

Post by 6 years ago

We at b2cloud play a fundamental role for businesses looking to build successful digital products. We often hear passionate product owners, experienced CEO’s and founders articulate their vision to us saying… “I want to build

Connect With Us

We're trusted by some of the largest businesses and enterprises to build digital products that matter.