CTO Liron Shapira gives a deep dive into Quixey’s Functional Search™ technology at a Bay Area Search meetup.
The Functional Web: The Future of Apps and the Web
March 7th, 2013 | Posted by 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.
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.
Quixey’s site just got an upgrade!
Over the past few months, we’ve taken a hard look at Quixey.com and feedback we’ve received from users, applying that information to a completele reworking of the site’s interface and experience. As the company continues to move at breakneck speed, a lot of our resources have recently been focused on building our APIs. Now we feel it’s time to match our site’s feel with its status as the central online presence of one of the world’s fastest-growing startups. We
know we still have a long way to go, and this is just the beginning.
First, let’s talk about the homepage. We’ve kept it very simple, acknowledging that users don’t need a flood of options and information thrown at them the second they land on a website. Most people usually have a sense of what they’re looking for, so the first decision they make is what kind of app they want to find—smartphone, browser, desktop, or web. That’s why the most noticeable buttons contain exactly these options. Hover over them and you’ll see the platforms we search—now you can immediately filter your query to the platform that suits you. For example, if you want Android apps, hover over “Mobile” and select “Android.” Easily found, quickly selected.
We’ve also implemented a new feature to show users the full potential our search. Our technology is far more powerful than anything else on the market, but its total functionality is rarely tapped into. That’s why we introduced the “Sample Searches” banner below the search bar. Clicking it brings up common areas of your life to use Quixey, and hovering over one of them will bring up suggested queries. For example, hover over “for Cooking” and queries such as “cook healthier food” and “time the perfect egg” appear. These examples we’ve provided are a good indicator of the kinds of queries you can type into the search bar. 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, like “wake me up with a song” or “study for the SAT” and we’ll return apps to help.
Now that you know what kinds of queries to type, plug one into the search bar. After you hit enter, you’ll be taken to a completely redesigned SERP (Search Engine Results Page). On the left you’ll see a list of apps that cater directly to your query. After clicking anywhere on an app result, information about that app will appear in the empty column to the right. Instead of clicking multiple times to learn about the app, everything you need to know appears in one place, allowing you to make a quick decision. This is valuable because if you don’t like an app, you can simply click on a different one without having to click the back button.
Under “Information,” you can read about the app, view screenshots, and filter by price. Click on the light blue button (which says “FREE” or the price) and you’ll be taken directly to that platform’s app store to download it. Directly below that button is the dark blue editions button, containing a range of prices. Click on it to view the different versions of an app (i.e. free, lite, HD, paid, etc).
When you’re on the results page, clicking on the title of any app will take you to that app’s page. There, in addition to larger screenshots and more detailed information, you can also learn more specifics about the different editions on the left side of the page.
In redesigning our website, we put the experience of our users first. We feel like it’s much improved now, but can’t wait to keep making it better. We’re never satisfied, we know we have a long way to go, and we highly value any feedback received. Give the site a whirl and tell us what you think!
Quixey is the search engine for apps: we help you find apps that do what you want. But what are apps? It turns out to be a tough but important question.
The term “app” became popular with the development of mobile platforms like iOS and Android. As more and more people began to use smartphones, our understanding of apps became focused on mobile apps. This shift makes sense, but it doesn’t give us a complete picture of what apps really are.
At Quixey, we define apps as simple tools that do what you want. Above all, apps are useful and apps are everywhere. Let’s talk about what that means.
Apps are useful
All apps help you do something you want to do. Some inform, some entertain, and some connect. Whatever their purpose, apps add value by providingthe specific functionality you need, when you need it. This is why our search engine asks you the question, “What do you want to do?” At Quixey, we believe that apps are defined first and foremost by how they’re used, by what they can do for you.
Apps are everywhere
Apps live wherever you are. Whether on a desktop or a tablet, on an iOS or an Android smartphone, you can access apps that help do what you want. Let’s look at Dropbox to see how the same app exists on many platforms.
Dropbox is an app. It lets you store your files in the cloud and access them across all of your devices. Whether you access Dropbox from your computer, your iPad, or your Android smartphone, the underlying app remains the same. You are accessing the same app and the same data regardless of what platform you access it from.
Why is this important?
By thinking of apps broadly, as simple tools that add value across platforms, we are challenged to build the most comprehensive app search engine possible. Quixey can help you find apps on platforms as diverse as iOS, Salesforce, and Chrome. Wherever you go, no matter what device you use, Quixey can help you find the right app for what you want to do. We focus on finding the app that you need, then we tell you where to find it.
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.
This post was written by one of our search advisors, Eric Glover. Eric Glover has more than twelve years of commercial web search experience and a Ph.D. in Artificial Intelligence from the University of Michigan. He has held key technical roles at multiple search engine companies and is a recognized expert in web scale machine learning and categorization.
In this blog post, I’d like to talk about the main components of search. Search has five main parts:Step 1: Receive the user’s query. Step 2: Parse the query to construct a ‘database query.’ Step 3: Using the database query, assemble the ‘consideration set’ of results to consider for scoring. Step 4: Score the consideration set. Step 5: Present results to the user based on the scores from Step 4.
These steps are common to all major search engines. Notably, Google, eBay, Bing, and Amazon apply unique algorithms and search different data for different purposes, and end up with different results.
Quixey is particularly unique among search engines. We invented a new type of search – functional search – specifically for apps. In this post, I’ll explain what standard search engines do and what we do differently.
Step 1 – Receive the user’s query.
Receiving the user’s query isn’t as simple as receiving what the user has typed. Sometimes external factors influence the query’s meaning – factors like the user’s country, browser, language, or device.
This is particularly crucial for an app search engine and functional search. For example, whether users search from an iPhone or an Android phone should influence how the search engine understands their queries. Moreover, someone in Russia may want different apps than someone in the United States.
Step 2 – Parse the query to construct a ‘database query’.
The old-school, simple method of parsing a query is to split it into individual words. Sometimes this involves removing ‘stop words’ (the, is, at, which) and the ‘stem’ of the query – for example, “help me to do my taxes” could be simplified into ['do','help','me','my',taxes','to'], or even something as simple as ['tax'].
As you might imagine, this is a dangerous strategy. It ignores the fact that user intent is not always a direct function of the individual words entered by the searcher. When searching for apps, “convert mp3 to flac” is a very different query than “mp3 AND flac.” Likewise, “tax” and “do my taxes” mean very different things. Misspellings, extra words, missing words, and unrelated words will severely throw off a search engine that doesn’t make this distinction.
It is a huge task to properly parse queries for your database. Most other search engines ignore the problem or solve it poorly. A query like ‘restaurants’, when interpreted incorrectly, will return so many results that the search engine won’t be able to score them all. Linguistics, intent-analysis and data considerations make this step extremely difficult.
Step 3 – Using the database query, assemble the ‘consideration set’ of results to consider for scoring.
Once the query has been transformed for optimal searching, you can use your new ‘database query’ to query the database. It is worth noting that the database query might have virtually no text in common with the keywords the user entered.
You can then select a consideration set based on the database query. The consideration set defines which results are worth considering. For example, queries like “paleontology” might generate a reasonably small consideration set, but queries like ‘racing games’ can generate consideration sets so large that scoring is impractical. That means it’s really important to parse queries properly in Step 2, as well as use algorithms that form manageable consideration sets.
Not only must the consideration set be small enough, but the algorithms used to generate it must be computationally efficient.
Step 4 – Score the consideration set.
A CS grad student writing a paper about ranking can win a Best Paper award even if his algorithm takes an hour to run a single query. Unfortunately, a commercial search engine can’t tell the user to wait hours for results. This creates a trade-off, often not discussed in academic circles, between the result response time and quality of results. The quality of results also correlates with the number of results considered.
Scoring is often the most computationally costly part of a search. Scoring results works as follows:
- Map each result to a set of (usually numerical) features, like the keywords’ frequency in the description.
- Apply a function to these features to calculate a meaningful score.
Competitors in the search space are differentiated by the data they access and the algorithms they use to score results. Quixey stands apart because of the wealth of data we use to score apps, and the precision of our scoring algorithm.
This combination is so successful because we invented functional search specifically for apps. Apps have a different set of important features than static web pages, so the standard text features sought by traditional search engines aren’t effective for finding apps. What makes one web page a better result than another is meaningless for apps, which often lack official home pages.
For example, the number of times an app is downloaded is more important than how many people link to its homepage. Likewise, the number of reviews might not be useful, because this metric strongly favors older apps.
Step 5 – Present results to the user based on the scores from Step 4.
It might seem easy to present results to the users by sorting by score. Unfortunately, this problem is more complex. What information should you display, and how do you organize the results? Should a result with a score of 49.9999 really display below a result with a score of 50.0000?
A simple ‘title text-match’ app search works fine when users knows the names of the apps they are looking for. However, our data shows that 86% of queries describe functions, not app names. People need to be able to find apps even if they don’t know what those apps are called.
Any type of ranking system is quite difficult and requires a lot of expertise. Our search requires collecting the right data, analyzing queries, effectively using and building a database, scoring based on the right features, and presenting the results in an intelligent way that helps users determine what they want.
In my next post, I will go into more detail about how Quixey does search differently.
Explaining The App Discovery Problem
July 8th, 2011 | Posted by 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?