Mobile First & Declining Usability

Mobile App Design is Fashion

Mobile app design moves very quickly, and with “mobile-first” thinking becoming the mantra of designers of all kinds, it is a leading indicator for design of just about everything else. So, I think it’s important to take a step back and analyze how apps are designed today. In this I break down the most recent mobile app design trends that I believe are actually hurting us, and making our software worse.

The way mobile app designs is very much a fashion-of-the-week type of situation where the target changes on a nearly daily basis. What was cool a month ago is stale in comparison to today, I use the term “fashion” to generally describe this reality. Before we dig in to the specifics of modern app design, let’s talk a little about fashion itself.

Fashion is irrelevant

I recently found myself reading an essay by Milton Glaser, one of the world’s most celebrated designers. In the essay he talks about “The Bull” by Pablo Picasso. In the work, Picasso renders 11 different variations of a bull each in differing styles. The work ranges from the realistic rendering, to a cartoon rendering, then to a more abstract cubist rendering, and finally simple line art.

Picasso: The Bull

As Glaser puts it, “What is clear just from looking at this single print is that style is irrelevant. In every one of these cases, from extreme abstraction to acute naturalism they are extraordinary regardless of the style.” – Ten things I have learned, Milton Glaser

I thought this line of thinking was very interesting. Glaser makes the point that “Style is not to be trusted”. Or another way to think about that, is that style is fashion, and it comes and goes with the tide. In demonstrating that the style of the work is actually irrelevant to it’s quality, we could draw the conclusion that style in ap design (the aesthetic) is also irrelevant, except for one small problem…

Fashion is of utmost importance

Back in the early days of smartphones the designers at Apple had a clear design goal: Familiarize people with touchscreens. So the style was glossy buttons with shadows, and controls that seem like they want to be touched. If there was a real-world analogue that could be used to symbolically represent a 3D interactive object, they would use it. This is known as skeuomorphism in the design communities, and I won’t rehash why everyone decided they hate it in the past few years here. What I will say however is that there was value in those old ugly interfaces. What we were able to do with skeuomorphism is train users to use our apps with visual language. The best example I can think of from those days is the picker view (called a UIPickerViewController in programmer speak).

UIPickerViewController

Nothing about the design of the picker view makes much sense, really. The only thing it does well is it looks like a spinning wheel, which encourages you to spin it like a contestant on The Price is Right. It’s kind of fun, in fact. But, this interface actually kind of sucks to use. You can only see about 4 or 5 options at any given time, and selecting a specific option requires a fine-tuning sort of interaction where you slowly and carefully align a value with the center of the view. A much simpler approach would be to just put options in a big fullscreen list; which is actually what Apple ended up using more often in their own apps. (Also known as a UITableViewController.)

UITableViewController

While these types of interfaces have many drawbacks, I have to wonder if my elderly friends, or my infant nephews would have been able to use smart devices so readily where they not using these metaphors for reality. Would smartphones have become as successful as they are now without skeuomorphism?

It wasn’t just this picker either, skeuomorphism informed the iBooks interface, designed to look like an actual bookshelf:

iBooks

It inspired the Calendar interface, to look like an actual calendar:

Calendar

And just for fun: Designer Meng To posted this skeuomorphic version of Facebook that looks like an actual book. on dribble.com

Facebook by Meng To

2016

Fast-forwarding to 2016, we have completely abandoned the idea that people don’t know what to do with touchscreens. I think we actually have gone too far. Have you ever tried to use Snapchat? It’s like they have made it intentionally confusing to use. Everything is hidden using gestures and invisible buttons you are supposed to know to tap and hold, and weird things like that. Some of the apps most interesting features are completely hidden from view.

There was a lot of positive reactions to the app Clear from a few years ago. It was a huge hit because of it’s unique UI animations. But here’s my question: How many of those downloads translated in to regular users? I don’t want to sit here and hate on the Clear app because I think it was a brilliant design in terms of being unique and fashionable. What it was not however, is usable.

Clear

Okay, so I swipe to the right to finish a task… Oops wrong one, how do I undo that? Do I just re-add it? Wait, how do I add a task again? Oh, I take two fingers and separate two existing tasks, and that makes a new one appear in between my existing ones? That’s odd… what if I don’t have two tasks? Do I just sort of “unpinch” the negative space where my tasks would be if I had two?

Yep.

That’s exactly what you’re supposed to do, and that sucks…

To clear a task swipe to the left, to finish a task swipe to the right. Wait, what’s the difference? I’ve cleared some of my tasks, but deleted others. Either way they get removed from my list…

If you go look at the app store reviews for Clear, you’ll see a lot of people complaining about the same thing, and I can’t even fully explain it to you because I don’t understand it either. But apparently if you perform a swipe gesture up (or down?) it will delete the entire list. How’s that for a fun and wacky gesture! So fun! You just lost your entire task list, which is the entire point of the app! That dismiss animation was sick though, so the app must be great, right?

Clear Reviews

The tutorial for Clear says I should “Pinch together vertically” to collapse my current level and navigate up. So instead of tapping a back button to navigate up, I have to perform a two-handed unpinch gesture for that too? I thought that was the gesture for creating a new task? HOW DO I USE THIS APP I DONT UNDERSTAND!? ARGGGH!!

deletes app…

Fashion sucks

As disappointing as it is, this seems to be the new fashion in apps: I summarize it basically as intentionally terrible user experience. I was talking to a prospect recently about an iOS App we were planning to help them build. They showed me a mockup that involved quite a few hidden buttons and gestures to control the UI. I carefully explained that users were unlikely to find these gestures and that we should move these things in to buttons that are more obvious. As a compromise, we needed at least a quick tutorial to show them these features. The response I received was surprising, to say the least:

We want this to be a secret

If we were designing a video game level this would maybe make some sense. It’s typical to “hide” some areas of play so that it’s rewarding when they are discovered. This is basically what they were going for. But for a mobile app, this is just a poor UI decision that is going to leave people confused. This wasn’t some kind of special easter egg hidden feature. This was basic functionality for switching to a friends list in the app.

You want to hide the friends list from users? This kind of thinking is now fashionable. Whether we like it or not, fashion influences the way we write software. As someone who is going to spend hours of my life building out these features, I hate the idea that most users simply will never find them. That’s why I declined that particular project. I left money on the table, but saved myself from spending time on work I didn’t find meaningful.

It’s our responsibility to fix it

I could sit around critiquing popular app’s designs all day (and I might), but this post wouldn’t be much use to anyone if that was all I did. So, let’s talk solutions…

1. Recognize that you can fix things

First, I think it’s important to accept that application developers have the final say in what their work ends up producing. You may think the decisions are simply made by your client, your boss, your partner, or your dog. Blame who you want, but your apps are the output of your efforts. If you are being boxed in to a corner and being asked to do something that sucks, you should stand up against it. You should learn to say “no” more often. At the end of the day, if you deliver what you think is best to solve the problem at hand, and you do your best work, no-one can complain about that. If they do, then they’re probably not worth working with anyway.

2. Do hallway testing

Hallway testing is the kind of testing you do when you grab some random person “out of the hallway” to test your app. You may have NDAs or similar agreements that make this a challenge, which is why it’s important to make sure agreements like this permit hallway testing. You may not be able to place an ad and have dozens of testers come to your office, but you can at least get family member or friend to try things out.

There are two very important aspects to hallway testing that are required for it to work. The first is that you absolutely can not explain things to the user while testing. It will be your first reaction to want to explain away any rough edges, defend your work, or try to help move things along to avoid embarrassment. This no longer represents a real hallway test though, this represents what it would be like if every user of your app was accompanied by you with your explanation, which obviously is not happening.

The second thing you must do is take notes of any stumbles. If you watch a user struggle with a component of your app for several minutes, and then finally figure it out, you could very easily write it off and say “oh well, they eventually figured that out so it’s not a priority”. WRONG! Your testers will have infinitely more patience than real-world users. If a tester is struggling, you need to make a note of it. Make several notes in fact, you’re going to forget if you don’t, and then those issues won’t be addressed.

3. Don’t hide anything inside of non-obvious gestures

If you are making a feature that involves swiping, pinching, or any other gesture, you should make sure it actually is intuitive to do so. For example, panning on a map (like an Apple Map) is very intuitive… it’s obvious that you would want to scroll the view and it’s obvious how you would go about doing that.

You’ll have to use your judgement on this one, but one way to confirm that your gestures are clear is by doing hallway testing, as mentioned above. You can trust your instinct with this stuff, but you also need to confirm you were right. Often something that seems intuitive to you will not be obvious to your testers.

4. Don’t be clever

There’s a famous quote often cited in software development projects.

Everyone knows that debugging is twice as hard as writing a program in the first place.
So if you’re as clever as you can be when you write it, how will you ever debug it?
“The Elements of Programming Style”, 2nd edition, Chapter 2

The same thing applies to user interface design. If it was a really clever idea, you should always be wary. Often the dead-simple obvious solution is the best one. This is basically just Occam’s Razor restated, which is often quoted for a reason: it’s true.

5. You tell me

What are the other takeaways here? How do you make sure your apps are highly usable? Tell me in the comments or on Twitter.

P.S. As an interesting side note, “The Bull” is also reportedly the subject of Apple’s training materials on their design thinking, for entirely different reasons.

Did this tutorial help you?

Support my Patreon

Your support on Patreon allows me to make better tutorials more often.

Subscribe via RSS

Your Parse backend was always a bad idea.

So if you haven’t heard, Facebook is shutting down Parse, the backend as a service (BaaS) that was acquired by Facebook a little while ago. Lots of developers are feeling a little lost, and even betrayed by Facebook. I tweeted this screen cap someone made from the Parse homepage before the shutdown, and it pretty much says it all:

I didn’t need to add the emphasis there, they already did that. Thousands of developers TRUST US. You can see from this type of presentation of their image why developers are feeling so betrayed. Why would anyone continue using React Native, React JS, HHVM, Relay, or any other Facebook technology knowing that they may just randomly decide to pull the plug on it?

Sure, these are open source and the community can take over, but open source projects need maintainers and corporate backers are a huge boon. Facebook has proven that we can’t trust them, but this shouldn’t be that surprising to anyone who has worked with Facebook APIs in the past, or any third party social media API for that matter. I’m going to get in to that later, but let’s completely change the subject for a second to talk about the other elephant in the room, Twitter… and more importantly Twitter Fabric, which now owns Crashlytics and has integrated a bunch of the amazing work done by Felix Krause.

But to understand how Twitter has treated it’s development community in the past, I think we should talk about a little app called Meerkat. I promise we’ll get back to talking about Parse and Facebook, but this story falls under the same umbrella, so bear with me.

Meerkat

So a little backstory: I live in Austin, TX which means every year at SXSW I get a front-row seat to the startups that are going to be big over the next year. Twitter, Foursquare, GameSalad, and even the Four-Hour Work Week were all launched at SXSW. These are some of the bigger successes, but every year tons of wide-eyed founders show up to Austin to present their work, and hope it takes off with people at the festival. In 2015 there was an extremely clear SXSW winner called Meerkat. meerkat-app-tweet-live-video-twitter

 

Meerkat is basically a live streaming P2P platform for people to stream directly from their iPhones to other users, and it took SXSW by storm. Just walking around Austin last year at SXSW you would see Meerkat shirts everywhere. Everyone who was anyone was streaming live music, SXSW sessions, their lunch, or just about anything they were doing. Then, suddenly… it all stopped, for a very specific reason:

At the height of Meerkat’s launch, Twitter yanked API access right out from under their feet with only 2 hours notice.

If you’re familiar with the iOS App Store process you might understand how this is sort of an issue, considering even if the Meerkat folks could somehow rewrite their entire app to not rely on the Twitter APIs they could not get an app approved and on the app store with an update within 2 hours… Actually it’d probably take more like 3 weeks or so.

At the height of Meerkat’s launch, Twitter yanked API access right out from under their feet with only 2 hours notice.

Personally I was not that surprised, but many people were wondering why Twitter pull such a move… Did they violate the terms of the API agreement? Where they doing something illegal?

Well, no…

Actually it turns out the whole reason Twitter decided to handicap the most successful Twitter-based app in years is because they had their own competitor in the pipeline, called Periscope, which I refuse to link to.

So here we are, having Twitter once again asking for the trust of the development community. Sigh…

Parse

See, I told you we would get back to Parse!

Seeing as how Twitter and Facebook are basically just two sides of the same social media coin, It seems to me that trusting either of them has similar implications. When I wonder about how a tech company will proceed in to the future I always repeat the mantra, “Follow The Money”. This generally tells you how large companies will behave well in to the future, especially publicly traded ones (both TWTR and FB are public). American public companies answer to their shareholders regarding quarterly earnings reports, sometimes to the detriment of their customers and/or partners. When I saw Parse had such a huge threshold for their “Free Tier”, it really worried me. It seems to me 99% of apps (or more) would never cross that threshold, and if they did they would only do so by a few cents. What exactly are Facebook’s motivations when it comes to their developer tools, and in particular the backend as a service? I think the answer is pretty simply that they wanted your data, but it turned out to be worthless. So they decided Parse wasn’t worth their time any more. They can’t turn a profit by providing a free backend to hundreds of thousands of developers; so they shut it down. In Facebook’s own words:

We’re proud that we’ve been able to help so many of you build great mobile apps, but we need to focus our resources elsewhere.

Translation: “You aren’t making us enough money”

Facebook generates all of it’s bottom line from advertising, just like Twitter, just like Google who is now the most valuable company in the world, surpassing Apple. In fact there is only one major platform vendor who doesn’t make the majority of their profit from advertising, and it’s Apple.

Following The Money

I tweeted this earlier today:

It’s true, you really can’t trust these social media companies with your backend so blindly. You have to Follow The Money to find the motivations of the parties involved. If their motivations are not to provide you with a great service that benefits their bottom-line, it’s unlikely it’ll stick around for very long. This is also a great way to analyze your own business if you are a startup founder or CEO. When you work with anyone, you must be certain their financial motivations align with yours, otherwise there will always be a disconnect. This applies to employees, co-founders, partners, and vendors alike.

The Facebook API

Back in the early days of the Facebook API, you could easily retrieve a list of a user’s contacts. This is what led to the mass-spamming from Facebook games, and the rise of Farmville. But Facebook decided they didn’t like that, so they yanked that privilege to the detriment of many apps, and Zynga’s stock. Seriously, check out what that did to Zynga’s stock:

If your business depends on an app, then your backend is an extremely important business asset that you absolutely must control. It took almost a decade for the likes of Salesforce and other cloud-based enterprise companies to make their way in to large corporations, and even today most of them are using on-site hosted versions of the software. The reason is that in a well run business you will own anything that is mission-critical. This increases the maintenance cost as well as the cost to initially deploy, but without this control your business is dependent on the whims of some shady figures who are mining your data to serve ads. Is that who you want in control of your server? How much do you trust Facebook, Twitter, and Google?

Build Your Own Damn Backend

The only real answer to providing your mobile app with a stable backend that you control is to build it yourself. I know this sounds hard, but it really isn’t that difficult to use Ruby on Rails or NodeJS to produce a simple API to power your mobile apps. Frankly, the Parse backend with it’s javascript-based events is not all that different from writing a NodeJS app in express, grabbing some node modules for easy API delivery, and backing the whole thing with a MongoDB database. If this sounds really hard, just take a few hours reading some tutorials online, and you will realize how easy this all is to do yourself. Alternatively, you can just hire my company who does this routinely *end shameless plug*.

If you do hire a vendor to build your backend, make sure you are getting the source code, and the tools necessary to load it up on whatever server you need. Docker is a nice way to contain all the environmental requirements for an app, and services like Heroku make deploying Rails apps easy.

Fun Fact: About 95% the way through writing this post, my ironic Twitter embeds trashed all the formatting and I had to reformat the entire thing. ^_^

Did this tutorial help you?

Support my Patreon

Your support on Patreon allows me to make better tutorials more often.

Subscribe via RSS

Should I learn Objective-C or Swift first?

“Should I learn Objective-C or Swift first?”

I get asked this question a lot. Sometime’s people will also ask about learning C or C++ first. So, I want to take a moment and give you the low-down on how I feel as a professional iOS & Mac developer, six months after Swift’s introduction. If this is your first time here, here’s a little background on me:

About me…

I’ve been developing software for as long as I can remember, at least 20 years now. I never was really the Mac guy, but I liked Linux and was always looking at new technologies. So, when the iPhone came out in 2008, I got myself a Mac and entered that ecosystem. Around that time I learned Objective-C, and that became my primary development language. It has been since then, and I’ve seen the language and Mac/iOS APIs twist and turn this way and that for the past 6+ years. In June I picked up Swift for the first time like everyone else, and although I still won’t call myself an expert, I will say I’ve done extensive study on the language. I’ve developed (and released) 3 apps using Swift since the announcement. Learning Swift is something I think is really important to iOS developers now, in fact it’s critical. To help people out I decided to write my Swift Book. This also serves as a way to help me learn the language, but I have already seen what a valuable resource it is for others; it’s exciting to be a part of… Additionally I’ve worked on an SDK that uses Swift, which will be used as part of a major platform worldwide in 2015. It’s very exciting to ship something like this that so many other developers will be using.

So, that’s my Swift-related experience in a nutshell. Now, here’s how I want to answer your question…

So… Swift or Objective-C?

Part of me wants to say, “Yes, go learn C first and then Objective-C. That’s what I did, so that’s what you should do.”

But here’s the thing: Just because that’s the path I took, doesn’t mean it’s the best path today. When I was first learning C, people told me I needed to learn Assembly to really get what was going on. They told me that without an underlying understanding of Assembly, I was going to be forever writing code and not understanding it. I ended up ignoring this advice and was very happy and successful as a developer without Assembly knowledge. In my college years, I finally picked up Assembly as part of my Electrical Engineering degree program. It helped enlighten some things, but for the most part I don’t feel knowing Assembly had much of an effect on my day-to-day programming. It had no effect on how I separate objects, how I decide what gets encapsulated, where to inherit, or where to compose. Most importantly, it didn’t help me to build better software. It was basically just academic, and as interesting as it was and is, the only place it’s even remotely relevant day-to-day is in debugging or reverse engineering; and only in limited capacities.

There’s certainly some sort of fear in me, like if we don’t all learn Assembly it will become a lost art. But, I don’t think that’s a realistic concern, honestly. The more I think about the idea of Assembly becoming a lost art the more I realize it will never happen. A single preserved book on the topic can get anyone where they need to be to be productive in Assembly, you just probably don’t want to.

Computer Science is an industry where we need to let go of the past, and we need to do it as quickly as we can. This industry is not going to wait for you to learn all the languages leading up to the latest and greatest. The marketplace certainly won’t reward that. What it will reward though, is knowing how to write code to make working software. That’s sort of the general thesis of this site, and it’s why I produce it. I don’t want to teach you to write code; I want to teach you to make software.

So here’s my answer to your question:

Swift

You should learn Swift first. You should learn it first because it’s the future of development on Apple platforms, and frankly it’s just easier to understand than Obj-C or C. What you may find as you learn it is that the Cocoa framework is getting a little stale. It’s starting to look very much like an Objective-C API in a Swift world. But that’s probably going to change. This wouldn’t be the first time Apple made a major change to their underlying APIs. Back in the days before Cocoa developers used Carbon, a C-based API that had some interoperability with Objective-C.

Apple is well-known for making swift (get it?) changes to their development stack. The move from Mac OS 9 to Mac OS X is a great example of their commitment to innovation. As a developer on Apple platforms, it’s important to understand this fact. Apple is about building the future of technology products, and they are not afraid to forego backwards-compatibility in order to achieve that. If you are still writing Objective-C day-to-day, you’re writing legacy code at this point. If you are writing Swift, then welcome to our world, you are the future.

Did this tutorial help you?

Support my Patreon

Your support on Patreon allows me to make better tutorials more often.

Subscribe via RSS

Apple Watch Announced. Here’s what we know so far

Apple Watch

Apple Watch Announced. Here’s what we know so far. This page is a work in progress.

There are three versions of Apple Watch:

  • Apple Watch
  • Apple Watch Sport
  • Apple Watch Edition – 18k Gold

The price starts at $349, and will be available early 2015

Apple Watch

An iPhone required to use Apple Watch

The device uses a Crown as the input device in addition to two types of touch detection. A ‘tap’ and a ‘force push’. The difference being how hard you push on the screen.

The Apple Watch provides support for Maps, Calendar, iMessage, Siri, Dictation, connects to wireless speakers, and a variety of other Apple ecosystem features.

The battery uses a wireless charger that attaches magnetically to the back of the watch. The watch uses haptic feedback for navigation and other use cases.

The second button on the watch will bring up your list of contacts. Digital touch allows you to ‘tap’ someone remotely using their watch, then drawing back and forth will wirelessly sync to other Apple Watch wearers.

User’s can also share their heartbeat, making the other user feel their heartbeat, or chat using the walkie-talkie feature.

 

Apple Watch Edition

WatchKit is used to allow developers to create glances, apps, and notifications.

The device can be used to track heart rate, and makes use of accelerometers.

Built-in activity app measures standing, moving, and exercising. These categories are referred to as rings, and hitting a quota visually fills the ring.

Move
Measure calories burned

Excercise
Measures brisk activitiy, at a brisk walk or above

Stand
Measures how often you stood up from sitting.

Did this tutorial help you?

Support my Patreon

Your support on Patreon allows me to make better tutorials more often.

Subscribe via RSS

Mobile Gaming: The Next Frontier for Online Gambling Sites

From poker to blackjack, developers are taking to the mobile market

Last year, the International Data Corporation reported that growth in the worldwide mobile market grew 6% in the second quarter of 2013 (2Q13), with vendors shipping upwards of 432.1 million mobile phones to markets across the globe. Thanks to new vendors entering the market, smart phones and mobile computing have become more accessible to a wider audience.

 

There was also a 52.3% year-over-year growth in smart phone sales, with vendors shipping 237.9 million units in 2Q13, compared to the 156.2 million units shipped in 2Q12. Studies by Super Monitoring also show that 91% of the global population now own mobile phones, with 56% owning a smart phone. If the growth and prominence of the mobile market wasn’t apparent before, it sure is apparent now.

Mobile markets have allowed many new developers to begin offering gaming at all levels, from casual to hardcore. Research by MobiThinking revealed that games account for 145/300 of the top apps available on iTunes, and 116/300 of the top apps on Google Play. Revenues for apps and games are estimated at $25 billion in 2013 alone – a figure that’s set to triple by 2017.

 

Thanks to this, even companies and developers who had previously seen success in other industries have begun closing in on the mobile market. The online gambling industry recently made great strides when some companies were granted licenses to operate in New Jersey, Nevada, and Delaware, but the expansion hasn’t ended yet. Online gambling companies have already released simple slot game simulations and other games that rely on luck, but the push for better quality mobile games is felt across all sectors. Some companies have been successful in this endeavor, while some have not.

 

Bwin.party, who released their partypoker iPhone app last year, says that one of the main points hopefuls needed to develop for any mobile app to be successful was ease-of-access. Connectivity remains to be one of the best features of mobile gaming, and with mobile games, players expect faster, smoother gameplay and results. To address this, bwin.party decked out a Fast Forward type of game specifically for their mobile users – a feature clearly lacking from the apps that had failed.

 

Could the mobile market be the next frontier for online gambling? Ness Software sure seems to think so, saying that as the number of mobile users go up, the only thing left for a smart company to do is join them and go mobile. Nowadays, consumers want something that lets them do their business – be it banking, emailing, or gaming – on the go, and lets them do it fast. And if online gambling companies want to stand a chance, they’d better take their business to the app stores.

 

Infographic 2013 Mobile Growth Statistics

Infographic 2013 Mobile Growth Statistics

Did this tutorial help you?

Support my Patreon

Your support on Patreon allows me to make better tutorials more often.

Subscribe via RSS

The user is a customer. So why doesn’t software treat them like one?

So this may sound obvious. You may be thinking, yes of course the user is a customer. We treat them like customers by providing them with support, pitching to them our value in our sales and marketing materials, and a host of other things. But what about in our software itself?

The fact is, our software tends to be designed as if it were going to be used by a computer interface. When an update is available for example, it may prompt the user with something like this:

“Acme Analytics v2.31 is now available, click here to install.”

Let’s draw a comparison to a real-world business. Let’s consider a gym whose modified it’s membership plan. Ultimately, the situation is similar. A change has taken place that (hopefully) improves the experience for customers. A gym may send out a letter or an email stating what’s new in the facility. For example:

“We’re proud to announce that we are now offering free Yoga classes with your membership. Classes will begin January 1, 2014, and take place every Monday at 8:30am.”

This announcement could be improved by reminding customers of other products, upselling additional services, or just thanking the customer for their continued support. But the important part of the message is that it clearly relays what has changed and demonstrates it’s value. Why would a gym naturally do this? Because it thinks of it’s subscribers as customers, and wants to keep their business. In our software example shown above, we are doing a similar thing, introducing new features. But, we are introducing the new features not as a new valuable service or product addition, but as a technical task that must be performed in order to receive the benefits. What if we instead thought about this in the context of value instead of the technical details? Our update message could be rephrased to sound more like this:

“We’re proud to announce that Acme Analytics now supports multiple users. The update is available immediately and can be installed by clicking here.”

 

This example communicates the value of our update much more clearly, but more than that it represents a shift in how we are thinking about the user. Instead of thinking of them as users who need to interface with our product, we are thinking of them as customers with whom we need to communicate value.

This is not limited to updates for our apps. Let’s take a look at a few more examples, and how we might modify them to both feel more human, and be sure we are treating our users as customers.

“You have 3 new followers! Click here to log in.”

becomes

“Three new people are interested in what you have to say!

Click here to find out who.”

“Download finished. Click here to open.”

becomes

“Your video is now ready, click here to watch.”

 

“Error: File Not Found”

becomes

“We couldn’t find the content you were looking for. You could try refreshing the page, or come back later, and see if that works. We apologize for the inconvenience.”

 

In all of these examples, because we are trying to be helpful to our customer, we deliver a better experience. We can use these opportunities to explain new benefits, apologize for problems (while suggesting solutions), or remind the customer they are appreciated.

If we can remember to treat all messaging in our software as if it were a personal phone call from our companies representative, or a mailer sent out to all customers, I think we gain a huge advantage in the sense of customer service our users perceive.

Related article: 5 things I wish I knew when I released my first iPhone app

Did this tutorial help you?

Support my Patreon

Your support on Patreon allows me to make better tutorials more often.

Subscribe via RSS

5 more things I wish I knew when I released my first iPhone app

Haven’t read the first part? Read Part 1 and then come back, we’ll be waiting.

Okay, read that? Here we go!

 

6. Wise SEO choices can have a huge impact on sales

iOS App SEO is not exactly like web SEO. The rules are much more simplistic, based on fewer factors than google search for example. I’ve found that the App Store ranks search terms on a few key factors:

– Title

– Company name

– App description

– Keywords

I would venture to say they are even prioritized roughly in that order. To get started optimizing your keywords on the app store, you can check out your competition using https://sensortower.com/. It’s a free and easy site to quickly get a good estimation of the keywords other apps are using. This may give you some ideas for keywords to use in your own app. Testing it with some of my own apps, I can say the results are fairly accurate.

7. Piracy is a very real concern

I remember the first day I released in-app purchases for one of my apps, PhotoGoo. Users could now purchase “stickers” to place on their photos to make funny faces and pictures. When my analytics reports started coming in I could see there were many purchases being made! I was thrilled. The minimum cost of all these purchases to deliver content to the device would surely be lower than the amount users were paying, except one problem:

The next morning I woke up to find nearly 1% of the purchases actually showed up in my iTunes reports. Upon further investigation I discovered mass piracy causing my analytics to disagree with my iTunes reports, and it was costing me money.

Now, in this case it wasn’t costing much. All I was doing was delivering some png files to the users, and not very big ones. But, it’s important to note that the cost of bandwidth and other such services may be impacted by piracy if you are selling premium content through IAP, or just using your bandwidth to serve customers who you *assume* are paying you.

8. App development is expensive.

This one gets asked often, “How much would it cost to build and app that does xyz?” I may do a full follow-up post on this help people asking this question find a rough answer. But in short, the simplest of the simple apps will be a few thousand dollars to pay a developer to write, and anything substantial could be $30k, $50k, or more depending on the app. The technology is pretty recent, so there is also not much competition in the space of app development. If you want to get an app developed, contact some developers with your idea (and wireframe it as well as you can.) See what their average prices are, but just know it’s a relatively big investment.

9. Planning is key

This is one if the most common problems I find in app development. Now, I’m not advocating that we all abandon agile development processes. In fact I’m not talking about programming right now. What needs to be locked down before beginning a project is a solid business strategy. This strategy may change over time, but the developers and stake holders need a goal. It goes beyond technology, because technology is just implementing features, and feature are just implementing business logic, which are usually just selling points for a product. Most software development can be traced back to it’s original business value, and if it can’t… well then why are you building it?

Having great planning can be the difference between the MVP you need, and the bloated unpolished product nobody wants. Yes, I group early product testing in to this category as well. It’s important not only to plan the technical details of your product, but trace it back to marketing objectives. What do the customers really want? Hint: They don’t know.

10. The apps in the top 10 aren’t the only ones making money

Based on my own apps, and many conversations I’ve had with other app developers, I can tell you that being in the top 10 doesn’t neccessarily need to be the goal. Sure, it would be great to have a top 10 app, but there is plenty of money to be made in the 300th spot on the iPad Photography charts. I think it’s important to remember that you can make money without being the biggest app in existence. If you set your goals to be slightly less lofty, it will increase your odds at being successful in the development process. You may even find that you end up making plenty of revenue this way.

 

Did this tutorial help you?

Support my Patreon

Your support on Patreon allows me to make better tutorials more often.

Subscribe via RSS

4 Steps to Design Marketing into your App

This guest post written by Mike Davis, CEO & Founder of StoryPress

1. Think through the whole sale process before you write any code, in fact it should be a critical component of your UI.  Many people just “know” that it will be an IAP or ads and completely ignore it until the end.  Designing the sale process is as important as anything else and deserves the same level of attention as your apps unique or differentiating feature.

2. Think about social sharing in the UI stage as well.  When people are registering can you ask them to invite their friends?  Maybe show their contacts and/or Facebook friends with 1 click to invite all?  Designing this type of social impact can be critical to your success and not something you want to throw in after the fact.

3. Where will your app be sold?  Is it only inside the app or on the app store?  Many of the leading app brands leverage their website and social media to generate sales.  With tools like AppKeyz now available, you can create a product page on Facebook and a mini-site capable of generating sales to promote on social media, including Facebook and Twitter.  Use these mini-sites to reward social sharing with 2 for 1’s or discounts on your apps.

4. Don’t waste your money on posters and t-shirts at trade shows.  It’s too much clutter and too expensive to stand out from the crowd.  Similarly expensive and extravagant launch parties almost never generate enough buzz or sales to come close to paying for themselves.  A better investment would be a PR person and several way placed interviews or articles.

Related article: Making Apps That Spread

Did this tutorial help you?

Support my Patreon

Your support on Patreon allows me to make better tutorials more often.

Subscribe via RSS

5 things I wish I knew when I released my first iPhone app

I’ve been writing mobile apps for roughly 4 years. I’ve seen dozens of apps come from concept to completion, and I’ve learned many lessons along the way. Here are the top 5 things I wish I knew when I first started out making iOS apps.

Ready? Let’s go!

1. Your icon and name will make or break your app.

You heard it here first. The most critical factor of your app’s success is not your beautiful algorithms, your revolutionary ideas, or even a great marketing campaign to drive initial customers. No, the most important factor is the icon, and the name. This is all most of your prospective customers see before making the decision to learn more. I’ve been able to measure this first hand by using two different icons and names for two otherwise identical apps, and I’ve repeated the experiment several times. I can say without a doubt that this is the most critical factor to getting downloads. In my last experiment, the app with a brighter and louder icon results in an average of 263 downloads per day, while an identical app with a softer and more toned down icon results in only 2 downloads per day. Wow.

2. Apple provides no way to keep in touch with customers.

So what happens after you get your first 10,000 downloads? What if you want to create a spin-off app leveraging your existing audience, or offer new products within your app? Well, you can always introduce an update, but who knows if your customers will actually download and run it. Furthermore, maybe they have already deleted your app? Previous behavior is the greatest indicator of future behavior, and the previous behavior of your customers is that they *bought something from you*. If you want to grow your audience and generate more revenue from your apps, it is critical that you offer a way to keep in touch with your customers. Set up a Mailchimp list, have them subscribe for push notifications, or have them make an account. Whatever route makes the most sense for your product, just make sure you have a way to keep in touch. You will be glad you did on your next app launch. Apple does none of this for you, they don’t even provide emails or names of the people who purchased your app, so this one is on you!

3. Apps that are too simple will be rejected.

Apple has a lot of rules concerning what is “fit” for the App Store, and what isn’t. One of the most difficult to resolve is an app being “too simple” by Apple’s standards. They are very directly telling you to go spend more money and bloat up your app with features you didn’t think were necessary. So what do you do? Well, my advice is to make sure you are not making an app that only does one simple thing. This is something that needs to be resolved before any development begins, or else you may be faced with a product that you simply can’t release.

4. The app store is not the gold rush it’s touted to be.

There is certainly money to be made on the app store, but don’t expect to publish your first app and rake in millions of dollars in free money. Making a successful app takes a lot of time, money, and great intuition about what people are going to like. Be reasonable with your approach in producing apps, and don’t bet the farm on a single strategy. Even if you are working with only a single app, you should make sure you have other distribution mechanisms outside of simply being on the app store.

5. Analytics are crucial.

Without some basic analytics, you will quickly find yourself wishing you knew some things about your users. This will probably hit you immediately after publishing your app. How many users are using the app? If you don’t implement analytics, all you will get are your daily iTunes sales figures, and I know we’re all more OCD about what’s going on than that. This is your baby after all. Take the time to invest in integrating a good analytics platform. There are some decent free options out there such as Flurry or Google Analytics for iOS.

In the spirit of keeping this post short, I’ll continue with the rest of my list in a later post. To get it delivered straight to your inbox, subscribe for free.

Continue to Part 2

Related article: Top 10 Lessons learned from launching iPhone Apps

Did this tutorial help you?

Support my Patreon

Your support on Patreon allows me to make better tutorials more often.

Subscribe via RSS

Microsoft wants to own the living room with the Xbox One

Today Microsoft announced their new console, the Xbox One. The demo relied on heavy integration with cable television, multi-tasking, mobile phones, kinect, and voice commands.

Controller

Guide

A demo of the product introduced “Snap mode”, a side-by-side multi-tasking type interface that allows the user to simultaneously watch television, play games, have a Skype call, use Internet Explorer, or even look at your fantasy football stats. They spent a lot of time talking about how easy it is to switch between apps, games, and live television. We’ve seen a push in this direction from Nintendo as well with the Wii U TV capabilities. It must all be part of the overall business objective, to own the entire living room. To replace your set-top boxes with one, all-inclusive Xbox One.

Xbox One

Skype

Every Xbox One has a new sensor that can respond to your voice, and understand who you are, and the Kinect has been improved to understand even finer inputs such as the movement of individual wrists. It can even read your heart beat for workout games, or so they say. All these things seem to be designed to be the “everything device”, similar to how the iPhone is the everything device for mobile. It’s clear Microsoft’s goal is to do the same for the living room.

XboxOneConsole

There is also a big move towards a much more cloud-based gaming and app environment. Think Steam meets iCloud, except Microsoft is running the servers (which incidentally went down during their presentation)

XboxOneConsole2

It’ll be interesting to see how this affects console development, and how nice Microsoft is going to be treating indie developers with this new console. I certainly am eager to learn more and find out if it’s possible to publish my upcoming game Miree on the console.

 

 

Did this tutorial help you?

Support my Patreon

Your support on Patreon allows me to make better tutorials more often.

Subscribe via RSS