How does OneRiot Determine the Pulse of the Internet?
Posted: November 12, 2008 Filed under: ADSO, Browser Add-ons, Me.dium, oneriot, Search, Toolbars, User Experience 1 Comment »First Who is OneRiot?
As of today, Me.dium is now OneRiot. With this name change, the company is also changing it’s focus from sidebars/toolbars to a destination web site. OneRiot still leverage’s browser Add-on’s, but the company is switching the primary input to it’s system from implicit to explicit. The core technology remains the same with one major modification, we have added full text indexing to our behavior graph.
This change is dramatic and the use case for OneRiot.com is search. Like other search engines, we keep a running record of the contents of the Internet. However, unlike other search engines, we prioritize that information based on its current popularity with our community. This makes OneRiot’s search results relevant, fresh, friendly, and pulsing with the real-time energy of the web.
How does OneRiot Determine the Pulse?
OneRiot sensors currently collect between 25 and 30 million browser minutes per day.
OneRiot users vet between 12 and 15 million URL’s per day.
4 % of the daily URL’s visited by OneRiot users are search related.
OneRiot collects these signals and others in real-time, processes them and outputs the Pulse for the terms/phrases entered.
For example, if you wanted to find out what is happening right now with Jennifer Hudson, click the link. Also, OneRiot decorates the Pulse results with additional metadata. You will notice a new section, ‘Today’s Pulse On’.
In addition, The Pulse indicators shown above illustrate how active a specific URL is at this exact moment and the Average Visit Duration communicates how long people spend on this URL.
If you download the PulseChecker you can see this information for any URL you visit in the bottom right hand corner of your browser. Also by installing the PulseChecker you are helping OneRiot understand the Pulse of the web.
Try it and let me know what you think.
Why are sensor based applications popping up everywhere
Posted: August 5, 2008 Filed under: Activity Context, Design, Me.dium Leave a comment »Wow! In the past week, 2 new companies that want to leverage a sensor started making noise in the tech blog press. Very cool and welcome.
The History of Me.dium
I thought this would be good time for a history lesson on Me.dium. When we were brainstorming the concepts behind Me.dium we were coming from a very different space than most would have expected, enterprise publishing.
We built a technology that focused on sharing information in large work groups. Our experience told us that when people in large work groups created information they usually started from existing documents or templates and not from scratch. We developed an application that made it easier for people to reuse information.
This was initially accomplished by adding some code to our proprietary application. The code monitored and stored the actions people took, like copy, paste, drag, drop and save as.
The monitoring application or sensor also captured the offsets into the documents or the location on the disk, the user name, date, and time the action occurred. We stored the information externally from the document and added additional meta data. This allowed us to update the content from one document to another based on business rules or explicit user actions.
We built two graphical tools to interact with this new meta data. The first was a visual differencing engine that understood structure, content and the new meta data. The second was a hyperbolic tree that allowed the user to crawl around the meta data and see all the local and global relationships. They both offered tremendous value to the end user, but the hyperbolic tree provided an aggregate picture of the system we were not expecting. This became the original idea for Me.dium.
We started putting monitors in all types of applications, Microsoft Word, Adobe Acrobat, Internet Explorer an open source XSLT parser and the Windows OS. Quickly, learning that most applications were great at being automated and terrible at describing what they were doing internally, I called this new type of information activity context.
The activity context was a new piece of meta data that could be stored and leveraged by any user, not just the original creator. Once we were aware of the Activity Context, we were able to do things we could never do before and the most impressive one was connect people in real time based on their current interests.
We envisioned sensors everywhere, all creating activity context, and Me.dium’s Matching Engine gluing it all together. Everything from consumer software applications, internet applications, proprietary enterprise applications, hand held GPS devices, mobile phones, home appliances, computer games and automobiles could operate more efficiently if they had access to Activity Context.
Part 2 of Me.dium’s history comming soon.
