Deep Links Yield Deep Data—But They Will Also Know A Lot About You
Deep linking is hot, and for good reason: it can make mobile search much more powerful by making it more predictive. In a world governed by small screen sizes and large intent, that's a huge asset.
And it's why deep linking startup URX recently introduced AppViews, a product with the not-so-modest goal of "understand[ing] what a user is doing and what could make them happier."
To better understand not only AppViews but the innovative deep linking marketplace, and whether the increased intelligence buried in deep links will lead to privacy concerns, I sat down with URX marketing chief (and former Googler) Mike Fyall (@mikefyall).
Going Deep On Deep Links
ReadWrite: Why is deep linking important? And is there more to it than people generally think?
Fyall: Deep links help users travel directly inside of an app to the right place, similar to a URL on the web. They help users save time, marketers create better campaigns, and developers build cross app experiences.
Deep links will also usher in much needed new tools for app discovery and engagement. The deep link itself is just an address; however, as companies like Google, Facebook, URX, and others build an understanding of the content behind deep links we'll be able to recommend apps to users when they are most relevant and useful.
This is happening today. For example, Google is showing app content in search results, and companies like URX are building products (AppViews) that recommend relevant apps based on a users context. We'll see lots of innovation here in the coming years, particularly as daily transactions inside of mobile apps continues to increase.
Everything Is Connected
ReadWrite: What sort of data does URX glean from deep linking?
Fyall: When URX crawls webpages with deep links on them, we capture information about the page content—for example the headline, keywords, images, and other metadata—using similar techniques to how search engines index webpages today. This helps us understand where the deep link goes so we can recommend it at the right time.
URX can also check to see if a user has a given app installed before deciding which AppViews is most relevant.
ReadWrite: When announcing AppViews, you talked about building an understanding of the entities inside mobile apps and how they relate to each other and the physical world. What does that mean?
Fyall: In order to show relevant AppViews for a given context, we need to understand how people, places, things, and concepts relate across apps.
For example, the "Beyonce" that you can listen to in Spotify is the same "Beyonce" you can also listen to in SoundCloud, or buy concert tickets for in Stubhub. Without this understanding, "Beyonce" is simply a 7 letter word to a computer and you can't figure out what a user might want to do next.
We've have a team of data scientists working on our knowledge graph (short explanatory video) for over a year. We utilized the Freebase project to kick it off and continually enhance it as more data flows through our system.
Today, if a user is browsing a story about Beyonce we have a host of possible destinations a user might be interested in visiting.
ReadWrite: You talk about suggesting the "next action" to make users "happier," but how can you discern what they really want from deep links?
Fyall: AppViews are about giving users a relevant recommendation for what they want to do next. To them, we aren't offering a deep link: we are helping them discover content or take action. We named it "AppViews" as the goal is to give the user a glimpse inside other app before deciding to leave their current experience.
The higher the user engagement is with AppViews, the better job we've done for users.
ReadWrite: Who pays for this? Meaning, a developer might want to surface content to me in her app, but presumably you're not going to show it to me unless it will make me happy, right? How does this work?
Fyall: To date, we've seen the majority of developers implement AppViews to add functionality to their site and getting paid is secondary.
Nexercise, the developer of the Sworkit fitness app, told us they've seen a host of positive reviews and feedback when they added the ability for users to listen to music before they workout.
In terms of the business model, advertisers will be able to pay for "Promoted AppViews" which will appear alongside related content. For a promoted AppView, the developer receives a majority of the revenue and URX take a cut as well. Developers have complete control over the format and types of recommendations shown.
All The Pieces Matter
ReadWrite: With AppViews you're getting into big data-type applications, not merely mechanical "Click here to go to the right place in an app." Where does this lead? (And will it be a privacy problem?)
Fyall: Deep links are the required infrastructure to build the new mobile discovery platforms that are so desperately needed on mobile. For as powerful and amazing as apps have become, we're still stuck browsing through app stores and can't move intelligently between apps. URX is one of several companies trying to reinvent how we discover and engage with content on our phones.
Most mobile ads today, for example those shown on Facebook or exchanges like MoPub, are targeted toward users based on demographics or previous behavior where privacy is a strong concern. However, AppViews are shown purely based what someone is doing right now— it doesn't matter who you are, just want you might want to do.
So privacy shouldn't be a problem for AppViews now or in the future.
Lead image courtesy of PicBasement
from ReadWrite http://ift.tt/1JDhCKj
via
Windows Wants Apps! Specifically, Android And iOS Apps
Turns out Windows 10 isn't going to run Android apps, as some rumors held going into Microsoft's Build developer conference on Wednesday. But the company promises that it will be easy for developers to port their existing Android and iOS apps to work on Windows.
It's part of Microsoft's much larger play to turn Windows into a developer ecosystem that can go toe-to-toe with Apple and Google. Windows 10, scheduled for launch this summer, is Microsoft's first attempt at an operating system that will run on a wide variety of devices, from phones and tablets through PCs and its forthcoming HoloLens holographic computer.
A unified Windows 10 potentially offers developers a single big market for their apps. Microsoft executive Terry Myerson, in fact, promised that within "two to three years" following the launch of Windows 10, the operating system will be running on a billion devices worldwide.
How To Get Apps
Key to that vision, though, is getting developers to write more "universal" Windows apps that will run across all those different devices. Windows has long trailed both Google and Apple in terms of the number of apps it offers.
To get from here to there, then, presents a challenge. It's one Microsoft plans to meet in part by convincing developers to reconfigure, or "port," Android and iOS apps to the Windows universal-apps platform.
Porting can be a tremendous pain for developers. At worst, it means rewriting an application from scratch in a new language, using new code libraries and APIs, in order to make it work on a different platform.
Reuse, Recycle and Reduce
Microsoft's answer to this problem is to let developers reuse code from their existing apps in Windows. In particular, Windows 10 will support Java and C++ code used in Android apps. And Microsoft's development suite, Visual Studio, will also be able to work with Objective C, the language traditionally used to code apps for iPhones and iPads.
This doesn't, of course, mean that Android and iOS apps will work on Windows out of the box. Developers will still need to tailor their apps for the Windows environment. Presumably Windows will offer new APIs (see our API explainer) to replace ones that are native to iOS or Android, and devs will still need to rewrite their apps to use the new APIs.
Such porting efforts can be fraught with unexpected difficulties, no matter how simple companies claim they'll be. Amazon's App Store, for instance, requires developers to do some reworking of their Android apps before it will accept them, mostly to ensure they use Amazon APIs instead of Google's).
Even though you'd think Android is Android, that hurdle alone has proven a major impediment for many app developers. The Amazon store had only 293,000 apps as of January, compared to an estimated 1.4 million in Google's Play Store.
There's one further wrinkle, too; Microsoft said nothing about Swift, the new Apple language for iOS app development that's quickly supplanting Objective C.
Lead image courtesy of Microsoft
from ReadWrite http://ift.tt/1bVp5qz
via
This Robotic Odd Couple May Soon Run A Warehouse Near You
Sometimes two is better than one—and faster and cheaper, too. That was the thinking behind Fetch Robotics' new robot helper duo.
Meet Fetch and Freight, two models that work together to make e-commerce shipping more efficient by dividing up the work. Fetch is an intelligent humanoid designed to identify and pick up products from a company’s warehouse shelves. Freight looks like a mobile ottoman that can travel up to 4.5 miles per hour to deliver the products from Fetch to shipping.
See also: Why We'll Have Robots In The Workplace Before Robots At Home
“There’s a lot of energy spent moving goods around a warehouse and we’d like to use Fetch and Freight to do all that repetitive transportation and have people do what they’re good at,” Fetch Robotics CEO Melonee Wise told me.
Robots From The Past
Fetch and Freight are the first robots to come out of Fetch Robotics, but if you consider Wise’s work history, they’ve been years in the making. Many of the robots' features recall Wise’s previous work as a roboticist and founder at both Unbounded Robotics and Willow Garage. For example, both Fetch and Freight can dock themselves at their respective charging stations autonomously when they detect their batteries running low, using technology that was pioneered in Willow Garage’s PR2.
Likewise, Fetch looks like a blue version of Unbounded Robotic’s orange UBR-1—too much so to be a coincidence. You can think of UBR-1 as the very first prototype to indicate the need for a robotic duo instead of just one helper. Wise said that while humanoids like UBR-1 and Fetch can pick up items and deliver them elsewhere, they simply aren’t very speedy.
See also: Your Robot Butler—Or Factory Worker—Just Got A Lot More Affordable
“When you look at a robot that has high complexity like Fetch, you have a really high center of gravity, so that robot can’t drive very fast,” she said. “We wanted to have a much faster robot that could move through the warehouse very quickly.”
Robots For The Future
That’s how Freight entered the equation. It's actually the more versatile of the two, as it can work with both Fetches and people. Fetch can lift up to 13 pounds, which covers many but not all of the goods you'd find in a typical e-commerce warehouse. When the goods are too heavy for Fetch, Freight can pair with a human to receive and deliver bigger items using an application called Follow Pick. It’s a manifestation of Frederick Taylor’s Scientific Management propelled into the digital age.
It’s cheaper, too. Since Fetch and Freight aren’t monogamous, a company can purchase, for example, 30 Fetches and 60 Freights to scale up the amount of work.
“That’s another reason why we looked at having two robots,” said Wise. “You can drastically reduce the overall cost by having more of the much simpler, lower cost robot.”
See also: How To Build Soft Robots
The obvious downside of having two robots instead of one is increased technical complexity. The company’s roboticists have had to program tracking into both units so each robot knows where the other one is and when the other one is in position to deliver or receive an item.
Freight also needs to be able to navigate the warehouse without running into anything and to follow a human worker around without that person having to wear some kind of identifying beacon.
Fetch and Freight will be on display at at ICRA, the IEEE Robotics and Automation Society's flagship conference, this May. Fetch Robotics has yet to specify a price.
Research and Development versions of the pair will begin shipping to researchers this June, where Wise predicts roboticists will come up with far more than simply warehouse applications for Fetch and Freight.
“Yes we’ve targeted this one application, but in the long term we see Fetch and Freight as platforms,” she said. “When we talk about developing applications for the robots, we’re talking about expanding their capabilities. One day maybe they will have the capability to get a drink from the fridge or do your laundry, but that’s very far off in the future. If people do develop capabilities like that with the R&D platform, I strongly encourage it.”
from ReadWrite http://ift.tt/1OEAa09
via
Welcome Back To ReadWrite, Jolie O'Dell
I'm very pleased to announce that ReadWrite has brought back Jolie O'Dell, one of our most distinctive voices, in a new role of special projects editor.
We don't often gaze at our navel here at ReadWrite, but when we do, all the lint comes out.
As you know, I've been thinking a lot about ReadWrite's future. We just turned 12, which is a long time for a digital publisher. Our industry always faces forward, yet those who cannot remember the past are doomed to repeat it. I've always believed that we need to draw on the heritage of deep thinking and analysis we owe to our founder, Richard MacManus. At the same time, we must keep embracing the very technologies we write about to transform ourselves.
I've relied on ReadWrite's alumni network for advice and counsel as I've led this site for the past two years. Now Jolie is going to help us plan our next steps. Enough from me—here's Jolie herself:
TL;DR: The bitch is back.
When I left ReadWrite in 2010, it felt more like a traumatic breakup than a giving of notice.
ReadWrite had become my spiritual home. I came of age here, got my first gray hairs here, built a family here, both within the readership community and with my fellow writers and editors. I'm not ashamed to say that in my final conversation with ReadWrite founder Richard MacManus, I cried like a baby.
Today, we're announcing that I'm coming back home to my beloved ReadWrite family, and I want to explain why.
I won't immediately be contributing to ReadWrite's daily editorial—at least not in a way that will be evident to those outside the newsroom. What I will be doing is bringing back a little of the old ReadWrite magic, that blend of thoughtful analysis, careful reporting, and a deep love of technology and its creators.
Editor-in-Chief Owen Thomas is a wonderful friend, and his vision for what ReadWrite will become is beautifully aligned with Richard's original mission, and with mine. Ultimately, we all want to make the Internet in all its forms accessible—readable and writable—for our community.
Back in the day, we were obsessed with teaching our readers how to code, how to manage newly social communities, and how to best participate in a Web that was transforming from static to real-time.
Today, we're forging a future where you all can be participants, not just consumers, in the new Internet of Things and wearable (or even implantable!) technologies and devices.
Want to build a robot? You can learn how on ReadWrite! Want to program a drone? ReadWrite. Want to master responsive design for the mobile Web? Want to figure out how to maintain your humanity in a machine-dominated world? We're here for you.
Want to know why you should care, why any of this matters? We will work through these issues alongside you.
As at the old ReadWriteWeb, we understand deeply that we're all in this together, as users and as creators. We all have a responsibility to understand and help build the Internet we want to exist.
My job is managing special projects for Owen and for Wearable World CEO Redg Snodgrass, also a good friend of mine. The first of these special projects is already underway, and it's a hot-damn doozy.
I can't wait to tell you more very soon, and I hope to talk more with each of you as we work together to make today's ReadWrite the best blog and the best community it can be.
I'm also curious: What special projects do you think I should be tackling next? I'd love to hear your thoughts. After all, you're the “write” half of this whole endeavor. It doesn't work without you.
With much love and deepest gratitude, I remain your humble correspondent and faithful servant, Jolie O'Dell.
from ReadWrite http://ift.tt/1EvS3d4
via
Developers Can Now Have Their Own Box, Says Box
The big news coming out of Box Dev 2015 was Box Developer Edition, a new offering that lets app developers build on top of Box's storage and other services without making it obvious they're using Box.
The new product allows developers to use the parts of Box they want—file storage, content previews, and so on—under the hood of their own applications. Users can just use the developer’s app without having to log into Box separately.
In a demonstration of the product in San Francisco at Box Dev 2015, Box’s annual conference for developers, a sample user logged into a dummy healthcare app and gained access to different folders which had content in them. The experience appeared seamless—and Box's role wasn't obvious.
Later, Box engineering executives showed off an administrative dashboard. Developers using the product will have full access to information like all the users of the app, their folders, usage data, and more analytics.
“It doesn’t just integrate with our APIs,” said Box CEO Aaron Levie in a press Q&A following the keynote presentation. “You can actually build on all the technology we have. That’s what the Dev edition is all about. It’s a developer-owned instance of Box. They can store and manage all the content on their platform.”
Currently in a limited beta, Box Developer Edition will have a cost based on the number of users, according to Levie. Data storage will come free since that isn’t the focus, he said.
Most other cloud providers, like Amazon and Google, charge developers based on storage or bandwidth used. This could make Box Developer Edition appealing to certain kinds of developers, but without details on the pricing, it's hard to know how competitive the offering will be and for which apps Box will end up being cheaper or have more of the right features.
“[The value of Box Developer Edition] has far less to do with storage and way more to do with workflow in your app that Box is enabling,” said Levie.
Formal pricing for the product will come this summer.
Photo by Owen Thomas for ReadWrite
from ReadWrite http://ift.tt/1HmoM4N
via
ReadWrite Turns 12: Now, To Map Our Own Future
The tween years are turbulent, and ReadWrite, which turns 12 years old today, has been no exception. In the past year, we've gotten a new publishing system, a new office, and new owners and colleagues.
What has not changed is our commitment to exploring the new world of technology and making its complexities accessible for everyone who wants to reap its benefits.
As I wrote a year ago, on the occasion of ReadWrite's 11th anniversary, just making it this far in the fast-moving world of digital publishing is its own accomplishment. Now that we're part of Wearable World, with new resources behind our mission of democratizing technology, I feel like it's time to lift our sights and not just chronicle the effects technology is having on our world, but dive into the maelstrom of change ourselves.
Respecting History, Celebrating The Future
ReadWrite began life as ReadWriteWeb, with a special focus on the newly open world of Web publishing. Having largely won the battle to make the Web both readable and writable, we saw something happen that broadened the ambit of our journalism and the intensity of the challenge we faced: The Web has become the world.
The simple protocols advanced by Sir Tim Berners-Lee to link together documents have now become the basis of the Internet of Things. Connected devices speak to other machines through application programming interfaces that run on what are, in essence, Web servers. It is now the world that we must make readable and writable, and hence open to all who seek opportunity and the realization of their creative potential.
See also: Should We Crowdfund ReadWrite?
I am convinced we can't do this alone. We need to rally our community of readers. We're now building some tools which I hope will connect our readers far more intimately into our process of reporting and storytelling. Here, too, we have an opportunity to take something that is presently broadcast-oriented—our own digital publication—and make ReadWrite itself far more read-write in nature.
We're on the brink of announcing more details about this. If you want to stay informed, you can follow us on Twitter or Facebook or subscribe to our email newsletter. In the meantime, I'd love to hear your ideas on how we can let our community participate in ReadWrite's next chapter. Tweet at @owenthomas or leave a comment here to tell me what you think.
Photo by pagedooley
from ReadWrite http://ift.tt/1GbLFF9
via
Mind Your Interviews
This post is sponsored by Greenhouse, a maker of recruiting software. It reflects the views of the sponsor, not ReadWrite's editors.
Employers have an almost unlimited number of channels for connecting with candidates—from the traditional job boards, to social media pages, to the word of mouth of their own employees. And it should come as no surprise that some of these methods are better than others in delivering the right candidates.
Greenhouse is a recruiting optimization platform that helps companies, such as Uber, Pinterest, Airbnb, and many more, build and scale their recruiting processes. Our software makes it easy to create job campaigns that use multiple sources and to track where the most qualified candidates are coming from (referral, job boards, campus recruiting, etc.)
Last week at our first Customer Summit, we launched this video. The goal was to activate the conversation about how to optimize recruiting. The video gives us a humorous view of a company recruiting the wrong way ... and the pitfalls so many of us can relate to, just less dramatically!
This post is sponsored by Greenhouse, a maker of recruiting software. It reflects the views of the sponsor, not ReadWrite's editors.
from ReadWrite http://ift.tt/1GFl30q
via