The Case Against “Installing” Apps

April 4th, 2013 | Posted by Liron Shapira in App Trends | Functional Web - (0 Comments)

We see five major problems with the concept of “installing” native apps.

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.

, , , , ,

The Functional Web: The Future of Apps and the Web

March 7th, 2013 | Posted by Liron Shapira in Functional Web - (0 Comments)

For a detailed video presentation of the concepts in this post, see our Functional Web tech talk.

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.

, , , , , , ,

[Tech Talk Video] The Functional Web: The Future of Apps and the Web

March 7th, 2013 | Posted by Quixey in Functional Web - (1 Comments)

CTO Liron Shapira gave this tech talk about the Functional Web at Box headquarters in Los Altos on Feb 27, 2013.

YouTube Preview Image

The Functional Web is also explained in this blog post.

, , , , ,

The History of Search and How Quixey is Shaping the Future

July 23rd, 2012 | Posted by Quixey in Functional Search | Functional Web | Uncategorized - (1 Comments)

Remember when finding what you were looking for on the web was like winning the lottery, those not-so-long-ago days before “Google” became a verb?  Today, finding an app can be frustrating just like web search used to be.  At Quixey, we think we’ve built a solution.  What Google did for the web, Quixey is doing for app search.

In the early days of the web, the curious web surfer had the choice between using a keyword-based search engine that delivered low quality results and browsing a directory where links were curated and organized by topic; one was inaccurate, the other tedious.  Keywords were far too simple a measure of search relevancy to be effective and directories couldn’t possibly keep up with the explosion of content on the web.  

Today, the app ecosystem is organized much like the directories of old.  App stores categorize apps by topic and offer basic keyword search.  Finding apps like this is tedious and inaccurate.  What can we learn from the development of information discovery on the web that might be applicable to app discovery?

The directory model fit the web in the early 1990s when the number of reputable sites on a given topic was still reasonable.  When Yahoo! was founded in 1994 and built one of the best directories of its day, there were only about 10,000 websites total.  The world wide web was small.  But directories maintained by real people don’t scale well and as the web continued to expand, the model collapsed under its own weight.

By 1998, the web had surpassed one million sites.  The directory model couldn’t keep up.  Enter Google.  Larry Page and Sergey Brin recognized that the web had an underlying structure that could be leveraged to provide accurate search results.  By mapping the way web pages were linked together and quantifying the relative value of those links, they created an entirely new way to find information on the web, one that was accurate and scalable.  This was revolutionary.  The potential of the web to provide useful information on just about any topic, whenever you need it, had finally been unlocked.

What Google did for web search, Quixey is doing for app search.  In 2011, the total number of mobile apps surpassed one million.  This was the tipping point.  Just as the directory model for the web collapsed when it reached one million sites, app directories are collapsing under their own weight.  There are simply too many apps to be organized in a directory.

At Quixey, we believe we’ve found the answer.  Our approach moves beyond the directory model of app discovery and towards an approach that finds apps based on the simple question, “What do you want to do?”  To answer this question, we’ve identified and leveraged the underlying structure to the app ecosystem, what we call the Functional Web.  Every time an app is talked about on the web, in blog posts, reviews, comments, etc, a contextual relationship is created between the app and some type of description.  These relationships can be mapped to provide an accurate picture of what that app actually does.  We’ve also mapped how these apps relate across platforms, so you can find what you’re looking for wherever you need it.

Apps are designed to help you get things done.  Looking for a gas station in a new part of town?  An app can help you find it.  Want to stay up to date on your favorite sports team?  An app has the scores you need.  With this in mind, we designed our search to answer a simple question: “What do you want to do?”  No more browsing lists in an app store or guessing at the most effective keyword to search.  Quixey can help you find the app to do what you want, when you need it.  This is revolutionary.

, , , , , , ,

[Infographic] – The Mobile App Ecosystem

December 15th, 2011 | Posted by Quixey in App Trends | Functional Search | Functional Web | Press - (3 Comments)

Since we have the world’s largest database of apps, we thought it was about time we crunch the numbers, and share some information with the world. We hereby present the first ever Quixey infographic!

We are obsessed with apps, math and everything else infographics. So stay tuned, and let us know what you’d like to see in the next one at @quixey and facebook.com/quixey!

Check out the full story on TechCrunch, “If Freemium Is In, Then Why Do Paid Apps Still Reign Supreme?“

Explaining The App Discovery Problem

July 8th, 2011 | Posted by Quixey in Functional Search | Functional Web - (1 Comments)

Without Quixey, app search often requires knowing the app’s name or  keywords in its app store description. But you shouldn’t need to know an app’s name to find it – it’s hard enough to memorize app names like Uber, Shazam and Kayak.

Quixey lets you find apps just by answering the question:

Apps are solutions to everyday problems like calling cabs, identifying music and planning trips. People know what they want to do, but they don’t know the app that can help them do it. Unfortunately, current app stores aren’t good at searching for apps by function.

For example, “games for 3 year olds” returns nothing in the iPhone app store:

This is most likely because the query “games for 3 year olds” is a long query. The App Store’s search struggles with queries written in plain English and queries longer than three words. This makes it difficult to find what you need.

In contrast, Quixey is designed to process queries exactly how you naturally write them.

For example, see our results for the same query:

Our core technology (functional search) allows us to find good results, even when the official stores can’t. How do we do it? We gather outside data. Since our search engine is constantly scanning the web for descriptions, reviews, and blogs about apps, it learns exactly what each app can do. This enables Quixey to find apps that do what you want, no matter how you describe them.

Let’s take a look at another example on the App Store.

The selection found with this query is seemingly random. The results include 2 video editors, an ecards app and a few other random apps. On the other hand, results for “edit photos” are much better. Despite the fact that these queries are so similar, the average app search engine gets confused with one and not the other.

At Quixey, understanding natural language is one of our specialties and we don’t run into the same problem.

The past two examples represent a universal problem. I can’t tell you how many times I’ve heard “I want to find X and all I get is random apps,” or “I always think there must be an app for that, but my app store doesn’t have anything.” You might know the feeling.

Of course, I don’t mean to pick on iPhone. The same problem exists across all platforms.

So, the takeaway: Quixey is different because you don’t need to know an app’s name or its exact description to find what you want. Just answer the question: what do you want to do?

, ,

The Rise of Mobile Devices and the Functional Web

June 22nd, 2011 | Posted by Quixey in App Trends | Functional Web | Industry News - (0 Comments)

The web used to mean content and static sites. But content isn’t king anymore – the web is shifting from content discovery to functional web use. This shift is clear when we look at the statistics.

Mobile apps are taking over. In a recent analysis, Flurry Analytics found that mobile app use now exceeds desktop and mobile web browsing combined. Take a look at this data:

U.S. Mobile Apps vs. Web Consumption

The change was extraordinarily fast. In minutes per day, mobile app use nearly doubled in the past year.

Flurry’s data illuminates a change the web is undergoing: mobile apps are becoming the preferred way to access the web.  You depend on your mobile phone for the tools you need and the apps you love, increasing the importance of finding apps quickly and painlessly.

GigaOM recently found corroborating data provided by cloud networking provider Meraki. Meraki’s data looks at Wi-Fi use across different devices.

The results are clear. Mobile web use (the green, blue, red, and yellow chunk of the bar on the graphic above) rose 25% in the last year. That doesn’t even include network data like 3G, which would widen the gap in total web use further.

Our growing reliance on mobile apps and mobile devices is a piece of the puzzle the tech world is putting together. App developers, network carriers, software companies, and device manufacturers need to anticipate the specific nature of this shift if they want to own the future.

Flurry and Meraki’s data is yet another sign of the rise of the functional web – the web, broadly defined, that allows us to do things in the digital world. The functional web is finding its way into the homes, cars, and offices of people for whom it was once accessible only on a desktop.

, , , ,

Our Role in the Functional Web

June 14th, 2011 | Posted by Quixey in App Trends | Functional Search | Functional Web | Vision - (1 Comments)

The Web In the 90s

In the last 20 years, the web has changed. In the 90s, the web was static- inert pages describing companies, things, ideas, history, and people. Anytime you needed information you had to search  thousands of static pages.  At the time, the “content web” was the forefront of communication technology.

AppsIt isn’t the 90’s anymore. The content web still exists, but a new layer has emerged. Using cross-platform apps like WordPress, Tumblr, Twitter and Facebook, people generate their own content live. Apps like Flipboard and your RSS reader allow you to choose how you engage with this content. Yelp, Maps, Skype, and Dropbox have changed the way we interact with each other and the world. This new layer of active participation is called the functional web.

You engage with the functional web everyday, every time you check your mail, edit a picture, chat with your friends, or open a document. The functional web links us together with mobile, browser, web and desktop apps. All apps live on the functional web.

As a result, people can develop apps that solve real problems for billions of people. We discover and use this technology on the functional web.

So, what’s the point?

Content SearchTraditional search arose in the age of the content web- it doesn’t understand apps, it only understands key words. Unfortunately, with traditional search, it’s remarkably difficult to find the tools you need without exact phrasing or a recommendation from a friend. The functional web needs to be organized so we can discover the apps we need when we need them.

QuixeyThat’s where Quixey comes in. We understand where apps live, how people are using them, what APIs they are linked to and what they do. This knowledge lets Quixey power search for millions of apps across all platforms and devices.

We work to make the functional web seamless. We envision a world in the very near future, where you can jump between platforms and devices without having to worry about finding the right apps. No matter where you are within the functional web, we can find the apps you want – games, client-tracking software, GPS systems, and more.

With the evolution of the digital world, the functional web is here to stay.

The Digital World is Evolving and Apps Are Changing Our Behavior

June 8th, 2011 | Posted by Quixey in App Trends | Functional Web | Vision - (1 Comments)

We are fast approaching a world where we use apps in every step of our life. A world where every time we need to do something, we just find an app to do it for us.

There are apps for keeping you in-shape, finding cheap gas, tracking your clients, doing your banking, keeping in touch with friends, calling cabs, finding the closest take out restaurant, even waking you up at the best point in your sleep cycle – there are apps for literally everything.

There are millions of digital tools built to help us throughout our days. But right now we can’t always find them at the moments we need them. As Quixey begins to power app search across all platforms, these apps will become easily accessible and change the way we go through our day.

Apps have already started changing our day-to-day behavior.

Shazam App

Remember the days before Shazam? When you wanted to find out the name of a song you would spend 15 minutes searching on a traditional search engine based on the few lyrics you remembered and maybe you would eventually find the song you wanted. Today all you do is press a button on your smart phone and wait for a few seconds.

Picnik App

Before Picnik you would hunt through tons of links related to “editing photos” and hopefully you would find something to help you edit your photos. Today you simply open your one-stop shop for photo editing.

Yelp App

How about the days before Yelp? Finding restaurants was not always as easy as it is today.

There are millions of apps just like the ones listed above, that exist solely to help you throughout your day. By powering app search for all platforms and devices, Quixey will ensure you can find the tools you need at the moment you need them. The digital age will evolve and the way we do things will change.