Click here to view the embedded video.

The “Novel Idea” Award:

Handy! Check out Quixey, The Search Engine for Apps, it’s the best place to find apps for every device quixey.com via @quixey

— Daniel Fox (@danieldotfox) April 26, 2013

The Quixey Challenge Mention Award:

#Coding Challenge anyone? MT @readyforce: @cal_engineer You guys signed up? @quixey Challenge starts on Sunday: bit.ly/15B2SYz — Stanford Engineering (@stanfordeng) April 26, 2013

The COOL Award:

COOL APP ALERT: Ace the SAT. FREE app which helps students practice math forthe SAT’s! #apps #math #edtech bit.ly/10foVvT — thinkportmpt (@Thinkportmpt) April 25, 2013

The Categorical Award:

@dougpete I like the diff’t categories. RT @teachthought: Quixey | The Search Engine for Apps teachthought.com/technology/qui… #edtech #ipaded — Lisa Noble (@nobleknits2) April 22, 2013

The International Love Award:

RT @monvall: Quixey,eficiente buscador de apps: quixey.com #pedagogiamovil

— Pilar Soro (@pilara) April 25, 2013

The Local Love Award:

Our inventive friends at @quixey bring intuitive #app discovery to #Android via @sprint phones. ow.ly/kifD6 #tech

— TheCounterPaloAlto (@TheCounterPA) April 22, 2013

We love all the support and appreciation sent our way via Twitter, and can’t wait to show everyone what’s coming up this summer! Stay tuned and keep the conversation going!

Fitbit

Fitbit, available on iOS and Android, allows users to track food intake, activity, weight, water, sleep, and most importantly, see the big picture when it comes to how daily choices affect your health. The app connects to a variety of wireless trackers, as well as an Aria Wi-Fi Smart Scale. Wearing one of the wireless trackers allows you to track your activity and sleep patterns, while the Smart Scale helps you monitor your weight and set goals. All the devices connect to the Fitbit mobile app to provide you with reports on your activity and areas of need with respect to health.

Nike+ FuelBand

The Nike+ FuelBand connects with an iOS app to provide users with a gamified method of staying on top of their fitness. Similar to Fitbit, it comes in a wearable wristband that tracks your daily activity, including running, walking, dancing, and all sorts of daily activities. Opening the app allows you to see your progress and receive achievements and rewards as you do more. It also connects through Facebook, Twitter, and Path, allowing users to easily share their accomplishments and encourage better fitness amongst friends and family.

Amiigo

Amiigo combines a tracking wristband and shoe clip with its Android or iOS mobile app to monitor exactly what kind of activity the wearer is doing. For example, the sensors can identify whether you’re using the elliptical, running, swimming, doing bicep curls, squats. etc. Amiigo correlates these activities with heart rate and blood oxygen saturation to give a complete physiological breakdown of your activities. Overall, Amiigo can identify and track hundreds of different exercises, as well as reps, intensity, and more.

Have you come across any other great fitness apps? If so, we’d love to hear about them! Tweet at @Quixey to let us know!

• iOS top grossing apps
• Android top grossing apps

The problem is that gross only measures the direct flow of money from an app’s users. In this post, we’ll see how apps create and monetize value in the larger economy.

Visualizing economic value

We can visualize how economic value is created and exchanged by drawing a diagram like this:

The diagram above represents the economic value created and exchanged when a lego man buys a sandwich from a 7-Eleven. We call it an economic value diagram.

Economic value diagrams have the following properties:

1. Green arrows represent money being exchanged
2. Blue arrows represent non-monetary value being exchanged
3. Solid arrows represent ongoing costs
4. D-a-s-h-e-d arrows represent one-time value exchanges
5. The thickness of arrows represents the amount of value being exchanged

In the diagram above, 7-Eleven pays a one-time cost to create a sandwich, then Lego Guy pays $4.35 for it and gets nourishment value. Pretty cool, right?

Here’s a quiz to see if you understand economic value diagrams:

In the diagram above, circle the part where 7-Eleven creates value.

Here’s the answer:

The thin green arrow represents the cost that 7-Eleven paid to make the sandwich, which is probably less than $2. The thick blue arrow represents the amount of nourishment value that Lego Guy got out of the sandwich, which has to be worth more than $4.35 to Lego Guy, since he’d rather have the sandwich than have his $4.35.

The reason we circled the sandwich – the way we know value is being created – is that the arrow leaving the sandwich is thicker than the arrow entering the sandwich. The difference in arrow thicknesses represents the magnitude of the value being created.

Now that we can visualize economic value, let’s see how apps create and monetize it.

How apps create and monetize value

Selling themselves as goods

Let’s start with the classic value-creation model: apps as economic goods, a.k.a. “paid apps”.

In the age of shrink-wrapped software, all apps were goods – tangible products sold in cardboard boxes on store shelves.

The original Angry Birds app was a lot like a good. Users would buy it in an app store for $0.99, play through all the levels, and then lose interest.

By definition, a good requires a one-time cost from a producer. On the other hand, a consumer might get either a one-time benefit or an ongoing benefit from a good.

In the 7-Eleven diagram, the dashed blue arrow shows that 7-Eleven’s sandwiches provide a one-time nourishment benefit to consumers.

In the diagram below, the solid blue arrow shows that Lowes’ hammers provide ongoing hammering benefits to consumers.

Similarly, the Sleep Cycle Alarm Clock app provides an ongoing waking-up benefit after a one-time $0.99 purchase.

Selling subscriptions and in-app purchases

The app industry has seen a big trend toward freemium apps - apps that are free to download and try, but then charge for subscriptions or in-app purchases. Some recent stats:

• In-app purchases generate 76% of revenue on iOS apps.
• The vast majority of the highest-grossing iOS apps are free.

The Wall Street Journal creates value by writing original news content. It monetizes that value through a classic freemium model.

WSJ charges users a $21.99/month for a digital subscription, which enables a user to read WSJ content inside any WSJ app.

Supporting a larger business

What about apps that aren’t paid or freemium, but simply free?

You can be sure that “free” apps still create and monetize value, but you can’t just look at the direct exchange of value between user and app. You have to consider the bigger picture.

Domino’s creates value, billions of dollars of it per year, by making pizzas. They also created some additional value by developing the Domino’s apps. These apps are “free”, but they help the larger Domino’s business.

The Domino’s app economic value diagram is interesting to analyze:

• If the “convenience” arrow is thicker than the “development” arrow, then the app has created economic value
• If the app causes the “pizza order” arrow to increase its thickness, then the app has both created and monetized economic value
• If the thickness of the “pizza order” arrow increases more than the total thickness of the “development” arrow, then the app has monetized enough of its economic value to recoup its development costs

Increasing brand awareness

The Domino’s app is free to use, but it still asks for your credit card info when you want to order a pizza. What about free apps that never mention spending money?

The Coca Cola Christmas Snow Globes app seems like a fun game that has nothing to do with drinking Coke.

The app creates value by letting users send fun Christmas cards. But how does it monetize that value?

The Coca Cola Company is betting that users of its app will raise their awareness of the Coca Cola brand at least enough to recoup the development cost. In other words, it’s betting that the “brand awareness” arrow will be thicker than the “development” arrow.

Selling users’ attention

Coca Cola’s app keeps users’ brand awareness for itself. But what about companies that monetize their apps through ads? Let’s diagram one of the most complicated examples: YouTube.

To make YouTube work, Google pays lots of ongoing video-hosting costs. It also paid a relatively tiny one-time cost to develop its YouTube for iOS app.

As users watch YouTube videos, they pay some attention to YouTube’s ads. When users pay attention to ads, advertisers receive economic value in the form of brand awareness. And advertisers pay Google a lot of money for that brand awareness, as you can see by the thickness of the “placement” arrow.

Functional Web economics

Last week, we argued that app stores’ concept of “installation” is obsolete. Similarly, we suspect that the concepts of “buying an app” is becoming obsolete.

Economic value diagrams show us that many apps create ongoing value for users. It makes sense to monetize these apps as services rather than goods, so we expect purchases of paid apps to continue declining while freemium in-app purchases continue rising.

Economic value diagrams also show us that economic value exchanges between users and app developers can transcend the boundaries of apps. For example, the Domino’s app has zero gross revenue in the app store, but it’s probably added millions of dollars to Domino’s’ yearly revenue by helping users buy more pizza. So even gross revenue is a narrow measure of monetized app value.

The Functional Web model predicts that URLs will remain constant as function identifiers, while everything else – including monetization models – will become infinitely flexible. We predict that apponomics will become uniformly freemium – just like websites and retail stores are all freemium.

1. Allocates local resources too rigidly

“Shrink-wrapped software” is what we call ’90s-era desktop applications sold as cardboard boxes on store shelves. Shrink-wrapped software is the precursor to today’s native apps.

A shrink-wrapped software application has to set itself up to work 100% offline. It uses a lot of local storage space and computational resources (and requires a lot of up-front installation time on your local machine).

Web apps usually do their computational heavy lifting on server farms in the cloud, so your device only has to provide a tiny fraction of the local storage and computational resources needed to run a web app – often less than 1%.

Are native apps like the 100%-locally-running shrink-wrapped software that originated the concept of installation, or are they more like 1%-locally-running web apps? Actually, both options are overly rigid resource allocations.

A native app can be located anywhere on the local-to-remote spectrum, depending on how it splits the work between its remote servers and your local device. There might even be multiple points on the spectrum for a single app. In principle, every app’s local-to-remote ratio can be in constant flux, dynamically adjusting its local device footprint (e.g. to populate a local cache using predictions about what data the user will want to access next).

2. Has an outdated concept of “updating”

In the age of shrink-wrapped software, when a user wanted to update their version of an app, they had to get their hands on a newer CD-ROM and repeat the whole installation process.

On the web, updates are automatic and completely transparent to users – users don’t have to think about the whole concept of “updating”, nor make decisions about when to update – it just happens silently over the internet. And on the web, updates happen incrementally – users only download the updated code and data necessary for rendering their current page within a web app.

Today’s native apps have the technology to update automatically like websites do – they have access to an internet connection most of the time. And today’s native apps have the technology to update incrementally – they’re often architected as a hierarchical combination of functional components (e.g. a payment-processing component, a map-rendering component, etc), and in principle the individual components of an app can update incrementally just like the individual pages of a web app.

But in many cases, updating native apps is neither automatic nor incremantal today. There’s no technical reason for this, but there is a conceptual reason. Our outdated concept of installing apps is responsible for our outdated concept of updating apps.

3. Is device-specific

It’s nice that you only have to install an app once per device (until an update becomes available, that is). But if you install an app on one of your devices, chances are you’ll also end up installing it on your other devices. And if you want to use your app when you’re at a friend’s house, you might end up installing it on your friend’s devices too.

You’re bound to encounter lots of app-enabled devices in your life. Why should you have to worry about installing your apps on every device you encounter? Device-specificity is just an arbitrary limitation of installation.

Web apps don’t have that limitation because they’re prepared to be launcehd from a state of zero local resources. If you use the OkCupid web app on your laptop, you can go to your friend’s house who has never used OkCupid, and instantly log into your OkCupid account by typing"www.okcupid.com" into their browser.

It’s a good bet that native apps will eventually drop the concept of device-specific installation. They can copy web apps’ incremental downloading solutions, and they can even go a step farther.

For example, one day you might be able to configure the device in your pocket to constantly signal your presence to the other devices in the vicinity that you might be able to use. The nearby devices will silently make predictions about which apps you’re most likely to want to use on them, and preemptively download relevant resources to be ready to run these apps quickly.

4. Adds up-front wait time

Shrink-wrapped software taught users to expect long wait times for mysterious progress bars called “installers”. A shrink-wrapped software installer might take a few minutes to copy an application’s files from a CD-ROM onto your computer’s hard drive, and then run configuration scripts to register it with your operating system.

Nonzero up-front wait times are a fact of life for any kind of app, but at least web apps address the problem proactively. Web developers routinely think about incremental downloading - programming their web apps to always download the smallest fraction of code and data necessary to provide the current user experience.

The web has taught us to expect instant gratification. Point your browser to a web app and you might have a bit of up-front wait time, but the web’s progress bars fly by at warp speed compared to shrink-wrapped software’s.

Today’s native apps have brought back the installation process.

On the plus side, the native app installation process makes life easy for app developers; it saves them the work of figuring out incremental downloading solutions. But developers can’t afford to comporomise user experience for their own convenience.

Just look at how much work Instagram‘s developers put into making a snappy experience for their users. Their native app has a clever scheme for uploading a user’s photo while they’re writing a caption and tweaking various options, so they never have to wait on a progress bar.

Apps like Instagram, with that level of focus on user experience, would do anything to minimize their users’ up-front wait time. Their installation step seems out of place in today’s world of instant gratification.

5. Breaks linking

Web apps have an extremely useful feature that shrink-wrapped software never had: linking. On the web, we take it for granted that Instagram photos and OkCupid profiles have URLs and are linkable.

Native apps installed on your device also have the ability to open certain links, but the installation requirement makes it risky to send around links to apps. For example, if you have one of IMDB’s apps installed on your device, then a link to imdb:///title/tt0114709 will launch it and go directly to its Toy Story entry.

But if you don’t have an IMDB app installed on your device, that same link will take you to a screen like this:

That’s why people share links to web apps all the time, but rarely share links to native apps. Native app platforms have weakened the concept of linking while strengthening the concept of installation. They really should be doing the opposite.

Conclusion

Developers will always try to maximize monetizable value for users. That’s what drives the long-term trend toward a web of high-level functions – the Functional Web.

Native app installation forces users to think about low-level concepts – which device they’re installing on, how much storage space it has, and when to upate. Plus, it makes users wait longer for apps up-front and it breaks in-app linking. In the Functional Web model, native app installation is a low-level implementation detail that gets abstracted away from users.

In a previous post, we saw how the Functional Web abstracts away the native-to-web app spectrum. In the first section of this post, we saw how the Functional Web can potentially abstract away the local-to-remote app spectrum. It’s also a good bet that the Functional Web will abstract away the installed vs. not-installed app dichotomy.

Click here to view the embedded video.

Monthly, DuckDuckGo has been seeing over 45 million users, and more keep switching over as they realize the value of a search engine that doesn’t track their every move. The company stresses a straightforward approach to search, emphasizing privacy and simplifying the results page. Useless clutter is removed from the results page, and their “!bang” feature allows users to search thousands of sites directly through the DuckDuckGo search bar. For example, if you need Python tips, simply enter “!python” after your query to search Python documentation.

We wanted to work with DuckDuckGo because we feel the same way about the technology we’ve built — it shouldn’t throw unnecessary content your way. We’re about bringing relevant app results to users right when they search, regardless of whether they know what they’re looking for. So a search engine that avoids filter bubbles is appealing to us, because relevant doesn’t mean curated. It just means helping the user find what they’re looking for on their own.

On the DuckDuckGo SERP, all app-specific searches will now yield app results powered by Quixey in the instant answers box above regular results, such as “best iphone games for kids” and “app for finding hiking trails.” Because DuckDuckGo stresses finding answers to queries with as few clicks as possible, Quixey’s integration fits right into their simple interface. When apps powered by Quixey appear in the instant answers box, users simply click on an app to view a quick snippet about it and a direct link to download.

As we stressed in our partnership announcement with Ask.com, the web is currently transforming from static sites to apps. An assortment of blue links simply isn’t enough when searching the web today. DuckDuckGo understands the importance of getting a relevant answer to the user as quickly as possible, and this isn’t always just an article with written information. Users are often searching for function and action — a way to help them get tasks done.

That’s why we were excited at the prospect of working with DuckDuckGo — their format allows us to serve apps to more users quickly, easily, and clutter-free.

If you want to know the future of apps and the web, don’t think about short-term trends.

• Don’t think about which new HTML5 APIs are coming.
• Don’t think about which devices have which market share.
• Don’t think about whether mobile websites or mobile apps are getting more eyeballs.

Just think about one thing: the URL.

The URL has been around since 1994, but it’s evolved a lot in 20 years. And the future of apps and the web has everything to do with the URL’s evolution.

Resource Locators

URL stands for “Uniform Resource Locator”. A resource locator tells you where an HTML file lives within a web server’s directory tree. For example, a website called Shakespeare Online lets anyone read the full text of Shakespeare’s Hamlet by accessing the URL shakespeare-online.com/plays/hamlet.html. That URL works because it locates a resource – a file called hamlet.html which lives in a directory called plays on the Shakespeare Online web server.

Function Identifiers

In the last decade, the web has grown to support new functions that aren’t powered by HTML resources – networking with friends, booking flights, gaming, watching videos, using maps, etc. These new functions aren’t powered by your grandfather’s HTML files. They don’t have “resources” to be “located” in the traditional sence.

For example, when you access www.facebook.com/home.php, Facebook doesn’t send you a static HTML file called home.php. Instead, Facebook dynamically pieces together your friends’ status updates and streams them to your browser in realtime.

When you access www.youtube.com/watch?v=dMH0bHeiRNg&t=50s, it plays the video “Evolution of Dance” starting at 50s. The “t=50s” is converted to a command that tells YouTube’s video player to skip to timecode 0:50 in the video.

When you access maps.google.com/maps?ll=21.28,-157.83, it shows a map centered around Waikiki beach, whose geocoordinates are 21.28°N, 157.83°W (the ll in the URL stands for “latitude & longitude”).

Today, the URL isn’t just a resource locator. In fact, it’s rarely used for accessing files like hamlet.html anymore. Instead, today the URL is a gateway to functions like “read my Facebook news feed”, “play ‘Evolution of Dance’ at timecode 0:50″ and “show a map centered around Waikiki beach”. Today, the URL is a function identifier.

The Functional Web

Back when it was a resource locator, the URL was attached to one specific technology – the HTML file. But in the last decade, the URL has been detaching itself from technology and attaching itself to functions. That’s how the URL can talk about Flash-powered video player timecodes and JavaScript-powered map coordinates. By detaching itself from technology, it’s not limiting itself to HTML-file-powered Shakespeare plays.

As the URL evolves from a resource locator to a function identifier, the web itself is also detaching from its implementation technologies. Technologies like HTML, JavaScript and Flash are getting abstracted into a single web of URL-accessible functions – the Functional Web.

When you access a URL on the Functional Web, you get a function like “read Hamlet”, “play ‘Evolution of Dance’ at timecode 0:50″ and “show a map centered around Waikiki beach” – and you get it with an unlimited number of technologies. You might get your function by locating an HTML file, you might get it by running JavaScript or Flash… you might even get it by using a native app.

Apps

Today we have the web, and we have apps. They seem like two separate silos, each with separate functions. Why is that?

Apps are software products, which makes them technologically different from web servers. Apps don’t have HTML resources that old-fashioned URLs can locate. This technological difference is why apps haven’t traditionally been considered a part of the web.

The Functional Web offers a technology-independent view of URL-accessible functions. On the Functional Web, URLs can be accessed either by downloading a file from Shakespeare Online’s web server, or by issuing a seek command to YouTube’s video player, or by launching a native app into a particular state.

Apps fit naturally into the Functional Web. Consider the function “search Yelp for karaoke”. Yelp’s website already has a function-identifying URL for it: www.yelp.com/search?find_desc=karaoke

Now consider Yelp’s iPhone app – one of Yelp’s many device-specific native app editions. It clearly gets you the same function the Yelp website does, namely “search Yelp for karaoke”.

This diagram visualizes how both editions of Yelp can access the same point on the Functional Web, by getting you the same “search Yelp for karaoke” function.

The only missing piece is to make the function URL-accessible to the Yelp app, the way it’s URL accessible to the Yelp website.

Apps like Yelp provide many of the same functions as their web counterparts, but don’t currently support the ability to access the URLs for those functions. It’s time for apps to fully join the Functional Web by making their URL-identified functions URL-accessible.

The Web’s Natural Evolution

Why did we ever separate apps from the web? How did we overlook the idea that URLs could be used to access functions of apps?

Our old-fashioned technology-centric view of URLs is to blame. We assumed that if apps weren’t like web servers – if apps didn’t have HTML resources to be located – then apps must not have functions worth identifying and accessing with URLs.

We didn’t notice that the transition to URLs as function identifiers was already happening. We ignored the fact that we already use URLs to access functions on social networking sites, video sites, mapping sites and other dynamic sites.

But native apps always belonged on the web, together with JavaScript apps and Flash apps. JavaScript and Flash apps always existed on the web – there was never a JavaScript/web dichotomy or a Flash/web dichotomy. Similarly, native apps should have always existed on the web, and there never should have been a native/web dichotomy.

The URL is our key to understanding the convergent future of apps and the web – we just have to understand its evolution from resource locator to function identifier. Then we can understand the decades-long trend toward the new web that brings URL accessibility to website-supported functions, app-supported functions, and all other technology-supported functions – the Functional Web.

Click here to view the embedded video.

The Functional Web is also explained in this blog post.

Phablet Mania Continues

At this year’s MWC, second-tier manufacturers proved that the phablet phad is not yet done. Huawei’s Ascend Mate was the clear winner in size, boasting a six-inch screen, while ZTE and LG weren’t far behind with 5.7-inch and 5.5-inch screens on the new Grand Memo and Optimus Pro, respectively. This trend comes just as tablets are shrinking as well—Samsung also revealed its new Galaxy Note 8, which has an eight-inch screen to compete head to head with the iPad Mini. As phones grow, tablets shrink, and phablets continue to stick around, soon there really will be a wireless device for every size hand(s).

Firefox OS

Firefox debuted its new mobile OS at MWC this week, stating the initial goal is to power mobile phones in the developing world at no cost to manufacturers. At first glance, the web-based OS has proved to be rough around the edges, but it seems to be gaining acceptance from carriers Telefónica and Deutsche Telekom, and manufacturers such as LG, ZTE, and Huawei. Here Firefox is attempting to make the web a standard for mobile app development, potentially stacking up against free standing operating systems such as Apple’s iOS and Google’s Android down the road. Brendan Eich, CTO of Mozilla, even said the company’s goal is to “tear down the walls between apps and the web.”

GSMA Connected City

This year, the organizers of MWC put together an entire city street exhibit to demonstrate emerging technologies that will enhance our every day lives in the home, car, town, and beyond. Among the showcased products were AT&T’s Connected Home, Deutsche Telekom’s connected mobile services (public transport, energy, security, and more), and GSMA’s Aston Martin One-77 road bike with speed, atmospheric pressure, and power sensors connected to its on-board computer. One of the first exhibits of its kind, The Connected City is a great peek into how intelligent wireless connections are driving economic growth, product innovation, and more convenient lifestyles in an ever-evolving world.

With an estimated attendance of 72,000 and over 1,700 exhibitors, the above highlights really only scratch the surface of what Mobile World Congress brought to the table this year. Moving forward, we’ll be monitoring emerging stories from the aftermath of the event—if you attended and want to share something amazing that you saw, send it to us at press@quixey.com. We’d love to hear about it!