CTO Liron Shapira gives a deep dive into Quixey’s Functional Search™ technology at a Bay Area Search meetup.
Time for another batch of the Quixey Tweet Awards. We’re appreciative of all our partners, friends, and fans of Quixey who spread word about us on Twitter, so we wanted to give a shout out to a few of them!
The “Novel Idea” Award:
— Daniel Fox (@danieldotfox) April 26, 2013
The Quixey Challenge Mention Award:
The COOL Award:
The Categorical Award:
The International Love Award:
— Pilar Soro (@pilara) April 25, 2013
The Local Love Award:
— 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!
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.
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.
Today we’re proud to announce our partnership with DuckDuckGo! We’re now powering app search for the alternative search engine that brings privacy, less spam, and immediate solutions to its users via the “instant answers” box at the top of its SERP.
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.
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.
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.
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
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:
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.
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.
Last year, we started the Quixey tweet awards to show our appreciation for the partners, friends, and fans of Quixey who supported us and spread the word about our app search technology throughout Twitter. As it’s Valentine’s Day, we can’t think of a better time to bring them back. Thanks for showing us the love, now it’s time to give it back:
The Helping a Friend Award:
We love all the support and appreciation sent our way via Twitter, and can’t wait to show everyone what we’ve been working on with major upcoming announcements this year! Stay tuned and keep the conversation going!
There will always be distractions and barriers that get in the way of what we want in life. Whether it’s something as complex as finding a cheap apartment in San Francisco, or as simple as a weak Internet connection preventing you from a quick game download, there’s plenty of friction around to slow us from getting to where we want to be.
Luckily, for some of the more minor annoyances in life, apps have popped up to save the day. Here are a few simple, yet extremely helpful apps to help make your life just a bit easier.
Ever had trouble getting your thoughts onto paper and wished there was an app that could do it for you? Well, such an app exists—if you can think out loud. FreeDictate can save your voice in an audio file and transcribe its contents into text using the most advanced speech-to-text software from Nuance (which powers Siri). The app then emails your transcribed thoughts to you automatically, and can also track where you recorded your thoughts, using GPS to show you the location on Google Maps.
If paper mail doesn’t bother you enough on its own thanks to the rise of email and other online communication methods, paper junk mail surely does. Enter PaperKarma, the app that gets rid of your junk mail for you. Simply take a picture of the mail/magazine/coupon book you’re sick of seeing stuffed in your mailbox, and the app will remove you from the mailing list. PaperKarma has built a massive database of company information and submits a request on your behalf after it recognizes where the publication came from.
If you’ve ever tried to take a picture of someone in a crowded area (and you have if you’ve ever been a tourist), this app is just for you. Scalado Remove allows you to take a picture and delete any unwanted strangers in the background of the picture. After taking a picture, the app recognizes which objects in the scene are people, and allows you to remove them one by one, keeping the space behind them completely intact. Say goodbye to photobombers.
“Don’t let anything stand in your way” is the Scalado Remove tagline. With it and the above apps, just a bit of the obstruction in your daily life can be cleared—which can sometimes make all the difference.
These days, we live in a digital age—you’ve probably noticed.
What many are unaware of, however, is just how significantly technology has permeated our everyday lives. Face-to-face interactions now take place less and less, replaced by virtual interactions via desktop computers and mobile devices. These are technically human interactions—but only up to a certain point.
While none of this may come a surprise, taking a look at specific data sheds light on how these trends have been developing and where they might lead us. TIME and Qualcomm recently conducted a study on attitudes and mass mobility, the TIME Mobility Poll, which surveyed 5,000 people in eight different countries. Regarding the workplace, they found that on average, 12% of people said they have fewer personal relationships with clients and/or co-workers as a result of wireless technology. If you’re a member of the workforce, consider this. How often on a daily basis are you on the computer or phone? How often do you speak to co-workers face-to-face? Most likely, the answers are nearly all day vs. intermittently. Similarly, the study found that 26% of people feel guilty for not responding promptly to work-related messages outside of normal work hours. Here virtual interactions have not only replaced the physical interactions, but in a way, also generated legitimate and somewhat virtual emotions. Outside of the workplace, the TIME Mobility Poll shows that over half of people almost always use their mobile devices during other activities such as attending a party, eating, and watching TV. Our physical lives are enhanced from instant connectivity to the virtual world, and this trend doesn’t seem to be slowing down—“filler” time such as waiting in line, pumping gas, and taking public transportation is now dedicated to staring at one’s phone. According to Flurry, of the apps we spend time using, over 79% are attributed to Games, Entertainment, and Social Networking. Looking at the physical scenery around us and having a full conversation is no longer adequate—our virtual lives have become more interesting. The interactions taking place in the virtual world are increasingly falling under our control as well. CNN recently found that Americans age 18-29 send an average of almost 88 texts per day. TIME’s Mobility Poll similarly discovered that 22% of respondents actually screen nearly all their calls so they can just reply by text or email—mediums that let a person dictate exactly what they want to say, when they want to say it. Following this tendency, the randomness and uncertainty of regular interactions seems to be fading.
What do these trends mean, though? Are we in the beginnings of a transition into a fully virtual world? Will traditionally physical interactions cease to exist? Moving forward, mobile devices and the “Internet of things” (smart capabilities infused into more and more ordinary objects) will continue to alter the way we live our day-to-day lives. How our perception changes as a result of this, with respect to virtual and human interactions, remains to be seen.
How is this game so good at killing my productivity?
Many know the feeling. Angry Birds. Fruit Ninja. Tiny Wings. Draw Something. Words With Friends. Temple Run. Temple Run 2. The list goes on. What starts as a harmless romance turns into quiet determination, then blatant obsession, and most inevitably, a messy break up.
Mobile game addiction has always been somewhat of an enigma from a consumer standpoint. When it comes to developers, however, a proven method for success has started to emerge. According to a study by Flurry, the most successful companies in the new mobile economy very closely monitor consumer behavior differences by game genre, enabling them to make informed decisions when it comes to developing apps with high retention rates and solid monetization strategies.
Based on the x-axis (90 day retention) and y-axis (Frequency of use per week), landing in quadrant I is the goal of all mobile game developers. This symbolizes games that build a loyal following through social means (Words With Friends – 15.1 Million monthly avg. users), or catch fire on their own and succeed monetarily through the ever-popular freemium model (Temple Run 2 – 20 Million downloads in four days). Let’s be real—you’ve at least been tempted to buy more gems after falling off the edge in TR2. Don’t worry, we won’t judge if you did.
Quadrants II-IV are the genres that either fail to maintain longevity with users, don’t engage users enough short-term, or both. Strategy games often capture a fan base well, but for only a short time—i.e. Letterpress. It’s fun, but the charm wears off quickly. Quadrant IV represents genres that are the opposite—poker games, Solitaire, and “endless” games like Drop7 (think Tetris with numbers)—which don’t have a lot of depth, but users return to over a long period of time. Finally, Quadrant III represents genres of games that along with a low frequency of use, don’t present as many opportunities for monetizing the user because the content and game mechanics can be more involved (i.e. “skill” games like The Walking Dead).
Taking this data into account, it would seem that the best practice is to abandon genres such as action, card battle, and casino, and focus on implementing a social element into whatever idea strikes one’s fancy. This is not necessarily the best course of action to take — what it really comes down to is leveraging this information about genres and applying it to a few key golden rules when getting down to the dirty work:
- User experience is crucial: Mobile game developers (MGDs) that ignore the in-app experience ignore both their potential user base and the prospect of gathering revenue. If users aren’t attracted to the experience of using your app, they’ll spend less time in it. This hurts retention rates, which in turn makes it difficult to display advertising to users or engage them with in-app purchases.
- Deliver relevant advertising in a nonintrusive way: If you’re relying on ads to generate revenue, know your user base so you can deliver them ads that won’t detract them from wanting to spend time within the app. Don’t frustrate them by showing ads at the height of the gaming experience.
- Keep them coming back: Regardless of the genre you choose, your game will benefit from rewarding users who come back. Whether that’s the “just one more level to see some cool stuff” effect, or the fact that all their friends are playing (Fear of Missing Out, a.k.a. FOMO, is a real thing), you need to instill some kind of longevity into your game.
So if you’re a developer, it’s valuable to take note of these points if you’re taking a swing at trying to create the next big game. As the mobile industry continues to expand, there’s bound to be a great deal of jostling amongst people like you trying to land a slice of the pie. If you’re a player, it’s important to realize that no matter how sick you’re bound to get of said next big game, there will always be another one ready to draw you back into a tumultuous relationship. Can’t stop, won’t stop.