CTO Liron Shapira gives a deep dive into Quixey’s Functional Search™ technology at a Bay Area Search meetup.
The Case Against “Installing” Apps
April 4th, 2013 | Posted by 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.
Why Functional Search Makes More Sense
December 14th, 2012 | Posted by in Functional Search - (1 Comments)Is there an app for that? Increasingly, this has become the go-to question for solving everyday problems in our lives. Typically, when users search for apps, they enter keywords like “tools” or “productivity” into their phone’s app store search bar. This is the model Apple started with the App Store in 2008, and others have followed suit with a categorical-based search ever since. Well, it turns out this search method misses the point of finding apps that do what you want.
We invented Functional Search® to allow users to find apps without even knowing exactly what they’re looking for—all you have to do is type what you want to do, and we’ll return apps to help. As a case study for why Functional Search® is a better app search, we’ve decided to showcase a few head-to-head examples. So let’s jump in.
Imagine you’re anticipating an important email (college admission letter, important client response, etc.) and you’ve been checking your inbox religiously hoping to see it pop up. After a couple days, you get irritated with how much time you’re spending clicking the refresh button, so you consider if there’s an app that can just notify you when the email shows up. Searching “alerts for email address” in Google Play yields results like eWeather HD, WhatsApp Messenger, and Bank of America. The same query in Quixey produces results such as Mail Alert, Mail Alert Pro, and Mail Tones. Which ones seem more valuable?
It’s time to get rid of that blaring alarm clock and wake up to something a bit more soothing. So you search “wake me up with a song,” hoping to find an app that can help you do just that. Google Play gives you results that make no sense—Piano Melody Free, Motivate Me to Exercise, and an artificial voice control app, to name a few. The same query in Quixey gives you just what you wanted—Playlist Alarm Clock, Smart Alarm Clock, and Alarm Rock, for example.
“Share content between devices”
You’re sick of dealing with files, photos, and music on all the different devices you own—phone, tablet, and computer. So you type “share content between devices” into the Google Play search bar. Now, what’s interesting about these results is that relevant apps like Evernote and Hoccer show up. But, hang on a second, what are Adobe Reader, textPlus and Pulse News doing above them? Isn’t Google Search all about instantly bringing you the most relevant content for your query? Try the same search in Quixey and you’ll see Hoccer at the top of the list, followed by Box and other data sharing apps such as DropCopy and Bump.
In a test of keyword-heavy search vs. a search that knows exactly what the query is asking, Quixey clearly wins every time. But why?
The answer lies in Functional Search® . The technology we spent over a year and a half building before it went live is a search engine catered specifically toward the current transformation the web. Google is fantastic at searching a web composed of static sites, but not one that’s evolving to be a web of function and action due to the dynamism of apps.
With its keyword search, other search engines can currently only take you to the doorstep of an app—and it’s often the wrong one. What Quixey does is recognize the inner workings of each app, so that when you search functionally, we open the door to just the right app and usher you in.
The History of Search and How Quixey is Shaping the Future
July 23rd, 2012 | Posted by 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.