Texturing of AR Characters from Colored Drawings

Coloring books capture the imagination of children and provide them with one of their earliest opportunities for creative expression. However, given the proliferation and popularity of digital devices, real-world activities like coloring can seem unexciting, and children become less engaged in them. Augmented reality holds unique potential to impact this situation by providing a bridge between real-world activities and digital enhancements. In this paper, we present an augmented reality coloring book App in which children color characters in a printed coloring book and inspect their work using a mobile device. The drawing is detected and tracked, and the video stream is augmented with an animated 3-D version of the character that is textured according to the child’s coloring. This is possible thanks to several novel technical contributions. We present a texturing process that applies the captured texture from a 2-D colored drawing to both the visible and occluded regions of a 3-D character in real time. We develop a deformable surface tracking method designed for colored drawings that uses a new outlier rejection algorithm for real-time tracking and surface deformation recovery. We present a content creation pipeline to efficiently create the 2-D and 3-D content. And, finally, we validate our work with two user studies that examine the quality of our texturing algorithm and the overall App experience.

iOS Design Guidelines

These guidelines describe how to design apps that follow the official HIG for iOS by Apple, not what you can do with custom controls. Sometimes it makes sense to break the rules. The purpose of this document is to guide you, not to provide solutions for complex and unique design problems.

When responsive design will make sense for your application

A few months ago, I found myself in a Twitter debate over whether or not responsive design can work for web apps.

While it was a fun debate, trying to answer the question of whether or not responsive design makes sense for your app is futile. Let me explain.

We don’t have a common understanding of what responsive means.

I wrote about my struggles with figuring out what is “responsive” recently. People think they know what others mean when they say something is responsive, but our definitions often differ.

The best responsive designs use much more than responsive design. When that is the case, it is easy to find faults with any given responsive implementation that can be used to say, “Well, that’s not really a responsive design.”

What happens when you use responsive web design, but add to it things that seem to be at odds responsive design? Is it possible to add something that make it no longer responsive? If so, where is the line?

What is a web app?

If responsiveness has a murky definition, “web app” is considerably worse. Jeremy Keith has long argued that “like obscenity and brunch, web apps can be described but not defined“.

Chris Coyier recently polled his readers about whether or not it was useful to distinguish between “web apps” and “web sites”.

While people agree that the distinction is important, there was little consensus on what the distinction was. Chris summarized his findings thusly:

I was kind of hoping we could get somewhere close to a solid distinction between these two classifications, but I don’t think it’s going to happen. There is very little agreement and heaps of opinion.

So any time we’re discussing web apps, we’re going to have trouble agreeing on what we’re talking about. Discussing responsive web apps is just asking for trouble.

A case study in different perspectives

Here is a timeline of articles and discussions that illustrates my point perfectly:

June 17, 2013 — Responsive design Web apps – good or bad?

On a content only site it [responsive design] probably is very wise to start small and scale up. But in a highly interactive functional UI the UX will be damaged by the time you scale up. Or vice versa. Take a demanding environment such as online betting or a tipping platform. The users needs are potentially very different between device environments.

July 4, 2013 — Why Responsive Web Design is a Must for Gambling Sites

I personally have no doubts that responsive web design will become an official standard for all good web pages and web content design to comply in the future, sonow is the right time for you to start using it on your gambling and sports betting sites.

June 13, 2013 — Case Study: Betting on a fully responsive web application

Kambi

 is one of the top sports betting providers and their services include popular sports from all over the world…At Kambi 

we went all-in on this bet and decided to build a web application that scales across the board. The value was clear, unified development process and consistent user experience on all platforms…Fully responsive web applications is not just a pipe dream anymore*. With the right mindset, tools and processes it all becomes possible.

July 9, 2013 — I point to Kambi as an example of responsive design being used for a web app. Nick Finck replies:

To summarize:

1. Gambling apps are too complex to use responsive design.
2. All gambling apps should be responsive.
3. A case study of how a popular gambling app was built to be responsive.
4. The gambling app in the case study is too light-weight.

Therein lies the problem. Even when we have a specific niche app/site (e.g., gambling), we can’t agree on the definitions. We have a case study of how a gambling app was made responsive, but we derive different conclusions about how applicable the case study is.

And I’m fine with that. I don’t mind ambiguity. People don’t have to agree.

I just think it points out how futile it is to try to convince others that responsive design for web apps makes sense.

My thoughts on responsive design for apps

For my own part, I believe responsive design for apps is a no-brainer. We’re building apps for clients that use responsive design. I’ve seen large, complex apps for Fortune 500 companies that are in development. I’ve seen what other agencies are working on.

This stuff is coming. And perhaps when enough of these projects launch, we’ll move on from the debate about whether or not responsive design works for apps like we’ve moved on from similar questions about responsive design for ecommerce. (We have moved on, haven’t we?)

But even if I wasn’t fortunate enough to get a behind the scenes look at upcoming responsive app projects, I would still argue that responsive design for apps is inevitable:

Once you start accepting the reality that the lines inside form factors are as blurry as the lines between them, then responsiveness becomes a necessity.

I’m not saying there isn’t usefulness in device detection or looking for ways to enhance the experience for specific form factors and inputs. This isn’t a declaration that everything must be built to be with a single html document across all user agents.

What I am saying is that even in scenarios where you’re fine-tuning your app code and UI as much as possible for a form factor, that the differences in screen size and the various forms of input within a form factor alone will be enough to require you to design in a responsive fashion.

Sure you can build a complex web app without responsive design that only targets tablets, but that app would be limited. There is too much variation in the screen sizes of tablets for a design that isn’t responsive to work on more than a handful of devices.

I’m much more interested in skating to where the puck is going to be, no matter how difficult, than to fixate on what is easiest to do now.

We’re focused on helping our customers make their apps work across devices. And that means taking on many complex challenges. Making apps responsive is just one of them.

So how will you know when responsive design makes sense for your app?

When you decide it does and put in the hard work to make it so. The rest of the discussion is just noise.

Source

BLINKDRINK transforms your phone from “that thing you play with when no one is talking to you at the bar” into a pint-sized party. Open the app, choose your color, and put your drink on top. BLINKDRINK uses the prism of your poison to keep time to whatever song is playing. You’re thinking, “iPhone as coaster? Sounds like a bad idea.” Well we put a lot of drinks on top of phones while making this thing- the only bad ideas generally happened afterward. Source

How much to make an App?
Estimate the cost of an app easily using this handy tool. http://howmuchtomakeanapp.com/

Share life in 3D with Seene. The world we live in isn’t flat, and with Seene, neither is the way you share it. Seene lets you take lifelike 3D photos and share this with other Seene users, on the web and via social networks. Source

One Size Fits Some

“Paid-up-front iOS apps had a great run, but it’s over. Time to make other plans.”

(via Marco.org)

This article from Marco Arment on his pricing strategy for the upcoming Overcast app has created quite a stir. I encourage you as an app developer to read it. There are a lot of valid points in it.

I don’t disagree with most of what he wrote. But when I get to a line like the one I just quoted above, I’m reminded of exactly what bothers me about most blog articles from app developers: “This is true for me, so it must be true for everyone and every other app in the universe.” The one-size-fits-all mentality that caused the race to the bottom in the first place continues.

If I were Marco, making a podcast app for iOS, I’d be considering seriously something other than a pay-once-up-front business model. Of course, I’m not going to be making a podcast app anytime soon, because I have no intention of getting into what’s already a crowded and I think pretty well-served market. Nor would I want to compete with his new app by any means. I’m sure it’ll be good, and deservingly successful.

There are many other kinds of apps where moving to this sort of model might make a lot of sense, too. It’s certainly worth careful consideration. But the problem arrives when you assume that all iOS users think and behave alike, and therefore all apps must be monetized similarly.

If we were to convert Teleprompt+ to the free with in-app purchase model, for instance, the three of us at Bombing Brain would be out of business in a couple of weeks.

Our customers are primarily prosumers and pros—people who wouldn’t trust their business to a “free” app. Our high price is a large part of what has made us successful in this market. (Along with years of cultivating a reputation for being better than our competition.) Converting this particular app to free with in-app purchase now would likely be an unmitigated disaster. We know, because there have been free alternatives that have crashed and burned. Hard.

Our target customers, the few who don’t blink at $15-$20 for an iPad app, are completely oblivious to the entire “free” app market. Free = invisible to them when it comes to finding solutions for their businesses.

To be fair, I don’t think Marco is actually suggesting that companies like ours change business models. But I do fear that too many developers read posts like this and walk away with that impression.

The fact is, there is a whole world of untapped potential on the App Store for developers who can solve real problems for people who are happy to pay. I’ve said it a million times, but it bears repeating: it’s not about price; it’s about trust. People are willing to spend money if they are sure what they are getting will solve their problem.

Is it easy to convince people that your app is worth a fair price? Of course not. Does that mean that you should make your app free in hopes of enticing a small percentage of people to convert to “paying” users? Not necessarily. Not for every kind of app, at least.

Giving a limited app away for free and charging to make it feature-complete is, in theory, one way to build trust. But given the reputation in-app purchase has acquired over the past few years, it’s going to take serious convincing before professionals, prosumers, and small business owners view IAP as anything but a scam in the short term. This is unfortunate, but you will be judged by the unscrupulous developers who have abused IAP before you, whether you like it or not. So you’re going to have to work even harder to gain that trust than you might think when associating yourself with this pricing model.

While it is true that the vast majority of iOS users scour the App Store looking for free alternatives, there is a not-insignificant number of users who wouldn’t go near a “free” app with a ten-foot pole. In their minds, free-with-in-app-purchase apps are all essentially Candy Crush.

So the risk is gaining a large number of users who are unlikely to pay you and who will write tons of bad reviews, while completely turning off the most valuable demographic in the Store.

Users looking to pay a premium price may be few and far between, but each one is ten times more valuable than the “average” iOS user to a developer like me.

Then there’s also the bulk of the education market to consider, which can’t, as a matter of policy, use any app with in-app purchase.

The point is, there are lots of different kinds of users in the App Store. And you need to know which ones are the most likely customers for your app. Don’t go treating them all equally.

Marco’s argument is essentially one of market share. He views total number of users as the primary goal. He wants to target as large a percentage of the total iOS user base as possible. That’s a perfectly valid business model that has worked for many. And for a podcast app, I think it’s a smart way to go. But it’s not the only way to skin this cat.

There are millions of iOS users in the world. I only need a tiny fraction of the right users to be successful.

I guess what I’m saying is, take everything you read from other developers (including myself) with a grain of salt. There’s no one way to be successful at this thing. Different apps in different markets, with different audiences, command different business models. You need to think about how you want to monetize your app long before you start building it. Consider all the options carefully. But don’t dismiss any of them out of hand because of what one or two others have experienced.

I’m happy that more devs are experimenting with in-app purchase as a legitimate way to encourage people to “try before they buy.” Look no further than MoneyWell for iPad as a primary example of IAP being used with positive results. Of course, this is an established company with a paid companion Mac app that already has a reputation for quality. Your mileage may vary. And, as Kevin Hoctor himself admits, his preliminary numbers are likely to be skewed for at least a few more months. But maybe in the long run, in-app purchase will gain the trust of users that currently avoid free apps like the plague. I think it’s going to be a long, uphill battle.

I look forward to seeing how other such experiments from other developers go. In the meantime, be cautious with anyone who tells you there’s only one way to go about doing things on the App Store.

Source

Premium vs Freemium vs Subscription

For mobile apps, there are three dominant pricing strategies: Premium, Subscription and Freemium.

According to a report by app-store analytics company, Distimo, freemium now accounts for 71% of Apple AppStore revenues in the US, up from somewhere around 50% last year, and rising. In Asia, freemium is 90% of App Store revenues.

Is freemium always the most optimal? What factors should you consider when choosing a pricing strategy?

Firstly, here is what these different pricing models mean, as applied to mobile apps:

Premium apps (or Paid apps) have an upfront price before they can even be downloaded. Similar to licensed software, except that the App Store makes all future upgrades to the premium app free once purchased.

Contrast this with freemium (a portmanteau of “free” and “premium”), where the app is free to download and use. However, some features inside the app are unavailable until you pay for them. App stores make it dead simple for developers to charge small amounts of money inside the app.

Subscriptions are a regular fixed fee the user is charged automatically via the App Store for using the app. Magazines in the iOS Newsstand are usually subscription-based. Subscriptions can actually overlap with either premium or freemium models. For example, Spotify requires you to have a subscription to even use the app (premium), while Pandora is closer to freemium where you can pay a subscription to get ad-free and unlimited hours of music.

How do you decide which to choose?

Premium has very limited use today

Perception is a large factor in how high a price is acceptable, and going premium helps create that perception. With premium, every user pays upfront, but the amount each user pays is fixed, regardless of how much utility each gets. Also, users have come to expect apps in the $2 – $5 range (a few niche apps can charge $10-$20) and there is no way to get higher ARPU.

In general, premium works in the following situations:

1. There is a strong demand for your app – niche areas are good candidates here.

2. You have a strong brand already and can establish trust with users where they are willing to pay before they download the app.

3. There is not a lot of competition that will almost certainly drive the price down.

4. You don’t care much about reach – which will be much smaller because of the “pay gate” into your app.

5. There are no ongoing feature or content costs that can drive up the average cost of of supporting a user to levels higher than what the user paid for the app.

Freemium helped create those million-dollars-per-day games

Freemium was popularized by casual games in Japan and Korea and has quickly become the winning model in mobile apps. It works really well in the following situations:

1. There is enough competition that users invariably have other cheaper or free options (low barrier to entry). This has been partly the reason for most mobile apps today moving to freemium.

2. When reach is important. You need large amount of users quickly to create network effects. For example, to drive virality or gather significant data.

3. When there are a small % of power users willing to pay significantly more than the other light users. The pay-as-you-go model facilitates this. Hard core users can drive as much as 100 – 1000 times more revenue than the other users. This is why some free-to-play games are reaching a $1MM per day revenue runrate.

More users in freemium, but a small percentage of them drive astronomical amounts of revenue.

The mobile app economy has progressed to a point today where all of the above usually hold true. Freemium does require some operational effort in managing your free and paying users, converting the former to the latter, and driving repeat purchases. However, this helps create a sustainable business rather than a one-time hit.

Subscriptions: the Holy Grail

A subscription provides a guarantee of repeat transactions and hence, businesses with subscription revenues tend to be valued far higher. The subscription price is usually smaller than the one-time price to incentivize the user into a longer term commitment. As the seller, you make up for the discount by being guaranteed future transactions.

A single issue of The New Yorker costs $6, but a year’s subscription of 52 issues is $70. That is a 77% discount and is still better, revenue-wise, than selling individual copies. Of course, they make a lot of money through advertising, so a guaranteed customer in the future is far more important to them. This may not be the case in all businesses. Amazon gives you a ~15% discount to “subscribe” to certain household items.

The subscription model does have a few drawbacks:

1. Like premium, there is a single price for all users, regardless of how much they use. There is a lot of money left on the table because hardcore users willing to pay a lot more cap out at the fixed price. There is some more money left on the table where the subscription price and commitment is too high for a large number of light users who will not sign up.

2. Tiered subscriptions does let you set different prices, but still creates ceilings on both price and consumption. Netflix has a 1 DVD plan for $8, 2 for $12, all the way up to 8 for $44. The lost opportunity? (a) A user can only do 8 DVDs. There may be a few subscribers who want much more. (b) A $44 price tag for DVD rental has a sticker shock. It is easier to charge $5.50 eight times than to charge $44 one time.

So when should you use subscriptions? Whenever you can. Subscriptions are considered the holy grail of revenue models. But it is important to make sure you are not leaving money on the table just to get a subscription commitment from a customer.

The ideal pricing strategy

Escalators are faster than stairs, even faster if you run up them.

At the risk of over-generalizing, a combination of freemium + subscription is the ideal for most apps.

Not everything being sold lends itself to subscriptions. Impulse purchases typically don’t. For example, a power-up that will help you cross this level in a game, or an Instagram filter that makes this photo of yours look exceptional. In such cases, it is best to start with a freemium model and then offer subscriptions to your  regular customers to drive  purchases further. Content (magazines, music streaming, movie streaming)  has more commonly been a subscription business. For these, it is a good idea to start with the accepted subscription, but remove any ceiling on purchases and consumption by offering more content that can be purchased in-app in addition to the subscription.

The mobile app economy is already large and growing even bigger. Get all the value you can out of it.

Drop in a comment, or shoot us an email if you want to chat about this for your app. We’re happy to help!

Source