Real Life Social Networks

I just received a beta invite for SkyDeck, a social networking site that uses information from your cell phone bill. I installed the Firefox toolbar, and then set up the toolbar with the login and password to T-Mobile's website. The toolbar stores my credentials, downloads my cell phone logs, and then sends them to the SkyDeck servers for analysis. This keeps my login and password secure, but makes the process of gathering information simple.

The service allows you to attach information to each phone call, including naming and tagging the contact and tagging and taking notes on each call, if desired. They use the information in your cell phone call logs to figure out who you talk to the most. I find the information interesting, but this service hints at some technical concepts that I think are VERY interesting.

Today's social network sites (Facebook, Myspace, etc.) create an online environment for social interaction to take place. They allow messaging, profile pages, and even network supported instant messaging. They work best (and sometimes only allow) communication within their system. They map our real life social connections onto the system of the social network.

SkyDeck's big idea is a reverse of that concept. They map a social network onto our real live social connections. This allows us to communicate exactly they way we want to, using our cell phones. I imagine they want to expand this service to email, instant messaging, and other forms of communication as well.

This concept is huge, and spells the future of the way we think of social networking. New and existing social networks will be forced to work the way we want to work. They will find it necessary to augment our life, rather then try and force our life into a closed system paradigm.

There are barriers to such progress, mostly in the form of secure information sharing between services. I want my social networking software to have access to my cell phone logs, email, and IM conversations without sharing my credentials. OAuth seems to solve this problem nicely. I look forward to the social networks of the future.

(Oh, and I have a few invites to hand out, if anyone is interested...)

Location Aware Cell Phones

Along with widget enabled cell phones, I think that phones need to be more location aware. In short, they need to be able to detect my current location, make that location available to information services, and then use and display location based information. Some of these things are possible in a few of today's phones, but the services need to be more flexible and more common.

Location can be determined in several ways. Most accurate is likely via GPS, while cell tower triangulation and wifi hotspot location can also be useful. In many cases, the precision of the location isn't that important. If I'm within 500 feet of my apartment, that might be good enough to effectively place me at home. In some cases, even city based location would be enough, allowing my phone to update my weather widget to the city I arrive in when I step off the plane.

Publishing my location information enables the location-smartness of my phone to extend beyond my individual device. Publication should allow varying levels of granularity, allowing my wife to see my exact location, while an online profile gets updated with my city or time zone. The system must be permissions based, ideally in complete control of the user. This can protect against undesired uses, such as stalking. Allowing location publication to any online service will allow users to participate in a wide variety of services, including those we haven't thought of yet.

Finally, a device must be able to use location information. It might make the location available to phone software, such as a weather widget or a map showing current location. It would also be able to pull information from online services, allowing easier spotting of the nearest Chinese buffet, and being alerted when a friend is in close proximity.

Allowing my location data to be used like this allows all sorts of things that can make cell phones nicer to use. Imagine a behavior service that watches my current location and my schedule, and instructs my phone to change it's ring settings to match the situation I'm in. I would no longer have to manually silence my phone in theaters, in class, or in church. It would detect my position and understand my activity, and learn to behave accordingly.

Pictures taken with the built in camera can be geo-tagged and auto-uploaded to an online service. Finding the cheapest Gas nearby becomes trivial. Real-time traffic detection and alerts becomes a project within reach of a graduate student research project. What can you think of?

Just as nearly every cell phone today has a camera, soon every phone will be made location aware. A platform as open as Android will easily allow these services. We will wonder how we survived before.

Android Widgets

It isn't hard to tell that one of my interest points is the concept of a non-computer information device. I've previously labeled these devices hardware widgets, after the widgets (gadgets, etc...) that have become so common on desktop computers over the last few years.

The great thing about widgets is that they tend to do a simple task very well. I have desktop widgets that show me the weather, the time, recent pictures from my flickr account, and a month calendar. The month calendar is an interesting widget because of it's usefulness. Pre-Widgets, the easiest way to get a month calendar was to double click the time in the system tray, bringing up the window that allows me to change the date or time on my system. I never actually change it, but just use it for reference and then close it again. Opening up a system time change dialog just to see what day the 17th is this month was a terrible misuse of system utility, but it was the easiest way to get the info. The month widget gives me a way to get the same info without abusing a system utility and risk setting the system time to something odd by accident.

Hardware widgets are cool, as I've mentioned previously, but fresh on my mind is how cool the concept of widgets can be on Google's Android cell phone platform. I frequently turn on the computer in the morning to check the weather forcast. How stupid is that? While thinking about what I would want my cellphone to do, I concluded that many of my items were things currently handled best by widgets of some sort. The Weather forecast, stock quotes, website stats, and sports scores would be handled beautifully well on a cell phone as a widget. I could grab my phone in the morning and quickly see what to wear, how my website is doing, progress of the stock market, and other useful things that are nice to know at the start of my day.

Widgets can really just be applications, but applications specifically designed to solve a single information need. Installing just my favorite widgets on my phone will make it a truly powerful hardware widget, and one that I keep with me all the time. My desire for a Chumby or Widget Station has just been replaced by the desire for a more flexible cell phone.

Android Marketing Confusion

I've read several accounts of people that think Google's Android platform is worthless, including this revealing quote by Scoble:

I didn’t see ONE feature that will get normal people to switch from the iPhone. This comes across like something developers developed for other developers without thought of how they were going to build a movement.

Of course it was built for developers! Do you see any phones for sale? No! What Google is doing is allowing developers to make some seriously cool apps that will draw people to the phones when they are released.

When I look at the API, I can easily see Facebook making an app on the platform that is so seriously cool that millions of users will go hunting an Android handset just because they want to use the Facebook app. It's a pretty smart idea too, because then you have many other companies doing your marketing for you, pushing people toward your platform.

Apple's iPhone is a product, like most other Apple products. Android is a platform, and the difference in marketing that we are seeing is precisely because of the differences between a platform and a product.

Regular users won't be interested now, but you can bet they are interested when they see the apps and features of software designed to run on the Android platform.

Why I'm excited about Google's Android platform

Have 7 minutes? Watch this video.

Google Phone announcement within two weeks

My brother called me recently and asked my opinion on smart phones and if it was worth getting one. My answer was no. I've not been impressed with the phones currently offered, and mostly because I'm not happy with the ability to develop software for them and their limited network access.

I've been generally disappointed with cell phone development in general. My wife and I recently resigned a contract, and got new phones as part of the deal. Neither of us liked the new phones more then the old phones, and we ended up keeping our old phones and selling the new ones on eBay.

Today the NYTimes announced that Google will have a phone available mid-2008 and will be making the announcement within two weeks.

This time next year, I might be looking at actually wanting a new phone.

Adobe CoCoMo vs Adobe Pacifica

I think I finally figured out the difference between Adobe's CoCoMo and Pacifica projects. Pacifica enables communications with video, audio, presence (etc.) in a fully P2P system, while CoCoMo enables nearly the same stuff via the Acrobat Connect infrastructure. What doesn't line up with this idea is that during the presentation, we learned that they would shortly be 'adding' P2P to the system.

I find it interesting to see Adobe working on parallel and competing technologies. I hope that it works out, as I think each has a place in the services infrastructure space, but I worry that Pacifica will get shafted to prevent revenue loss on the CoCoMo services product. Of course, I could be completely wrong on my take of this. We'll just have to wait and see.

Adobe's Services Play

Today at Adobe's MAX Conference in Chicago, they highlighted in a general session some new services that Adobe is getting into. Adobe has long been a software company of the install variety. They announced some services that lead them into a very different model as a company. These new services will likely never be the core of Adobe, but do help it expand into new areas of business.

The most interesting service is what they introduced as CoCoMo. The services expose all the underlying features present in their Connect application as Flex components that can be built into any Flex application. This allows integrating conferencing, audio, video, whiteboard, and screen sharing into any application. They appear to be billing this similar to their current model. The components must connect to a Connect room, which could likely be used with their current interface as well.

They also announced a different product called Pacifica that seemed to have the same set of features, but somehow was listed under a different product name. I'm very confused on the difference between these two products.

In a different space, they released SHARE, an online file sharing service with 1GB of space for free. You add files (of any type) into the system, and then you can share them with anyone or only specific users. I couldn't find the ability to update a file by uploading a new version, but did see several places list both a Created and a Last Updated date for the file. They do have REST APIs for the entire service, so you can build a front end onto this, or mash it up with a completely separate service. I expect to see both an AIR version (with drag and drop upload and download) and file system extensions to have this space mounted as a drive very soon.

I am very much a fan of Amazon Web Services. Amazon's services are very aligned with their core competencies of infrastructure and scale. These services (with the exception of the SHARE service), play very well to Adobe's strengths. I'm excited to see more companies entering the service/infrastructure business.

Telephony Expectations

I had an interesting conversation with a client earlier today that I'm still thinking about. We are in the very early stages of designing and deploying a SIP based phone system that will serve the main location in Northern California, a remote development office in Provo, UT, and several remote workers in the SF Bay Area. Our conversation was taking place using some testing equipment paired with an existing phone system in a Frankensteinish way:

I was talking on an Aastra 53i SIP hardware phone in the Provo Office, which is connected to an Asterisk (Trixbox, properly) server at the main location. The call was routed through a GrandStream GXW-4104 media gateway attached to an analog extension port of a very ancient Panasonic PBX, and the other end of the call was on a extension of the same PBX. The call quality was great. Let me point out some things about the above configuration.

  • The Provo development office is using an iProvo fiber connection, with a business Internet connection through MStar, and the main location has a T1 to a nearby ISP, where some servers are colocated. No special connections here.
  • Each location has a Cisco PIX, and a hardware VPN has been configured between the locations, which allows the hardware phone to communicate directly with the Asterisk server at the main location. This VPN is fully encrypted.
  • The Asterisk server is running on a VMWare cluster, and was installed from a TrixBox ISO image.
  • The GrandStream media gateway is the cheapest 4 port gateway we could find. GrandStream also sells a sip phone for less then $50.
  • There is absolutely no Quality of Service (QoS) measures in place on any leg of this connection.
  • We are using nearly every factory default on the media gateway, Asterisk server, and SIP phone. No special tweaking.

The call quality was great. Not perfect by any means, but great. About every 10 minutes or so I would notice a dropped packet or two, but they didn't interrupt the conversation. By great, I mean that the call quality was generally better then a typical phone line (except for dropped packets), and I've never had a cell phone call that performed nearly so well in terms of garbled speech/dropped packets.

I have talked to a few VOIP guys in the past few weeks, and all of them told me in no uncertain terms that running a SIP call over a non QoS enabled encrypted VPN connection to a virtualized Asterisk box using a cheap gateway to an ancient PBX was simply not going to work well at all. Nobody would touch it with a pole of any length.

This came up in the conversation, and my client (both older and wiser then I) observed that the Bell Telephone Company set a standard of service that is really quite high. People came to trust that the phone system would just 'work' and they would not have any difficulty with it at all. The current breed of telephony services and consultants seem to still ready daily from the gospel of Bell.

Yet, somehow, we all tolerate terrible cellphone service every day. As we have come to accept terrible cell service, other services with 'pretty good' service have made inroads as well, such as Vonage and other home VOIP providers. Eventually, I think VOIP services and consultants will come to grips with the changing expectations of the general public, but until then, progress must be made by those of us willing to just try something, and see how it works.

As a final note, many things in our current configuration will change as we put the new phone system into place. My configuration notes are included to make a general point. Under load, it would be sure to struggle, and our full system will be much better configured to perform well.