There are three aspects I would add to your thoughts on location. Even when the location layer becomes ubiquitous, we’ll still have to think in terms of specificity, frequency, and context. Different methods of updating and privacy settings can mean location as specific as GPS or as general as a zip code, which may or may not be useful depending on the consuming service. We’re constantly moving, so frequency of updates determine the social usefulness of location data. Also, if location sharing becomes more ubiquitous and automated, it will probably be in the form of GPS or cell tower information along the lines of the iPhone’s “Locate Me” feature. This is great for certain kinds of location sharing, but horrible for contextual information like “in conference room A” or “Ted’s pub.” Mapping GPS->venue will be a big deal.

This leads me to my worries about the location layer.

I foresee applications that allow users to tag their GPS locations with venue data, but store that data in a closed way so that the company owning the app can claim it as IP.
I really want to see the location layer implemented correctly before we go too crazy with services. That will require more thought and lots of openness+standards. We need more apps like Fire Eagle that take privacy seriously and offer users robust control of their data. If companies like Facebook try to claim your location history is their property the way they claim your contact list is their property…well, I don’t even need to explain how bad that would be for everyone.

A week ago, I declared information bankruptcy.

Information bankruptcy is a more generalized form of email bankruptcy and RSS bankruptcy. I have too much content to keep up with. I have 96 people I follow on twitter (low by most affluent standards). I have 73 friends on facebook (again, low). I follow the life streams of a dozen people. I’m on livejournal, flickr, yelp, upcoming, eventful, tumblr, delicious, wordie, pownce, linked in, myspace, last.fm…the list goes on.  By declaring information bankruptcy, I stayed away from all of these things for a week with the intention of rethinking how I consume data when I return.

There are usually one or two mechanisms offered to control what comes to our attention: source and keyword. We can control what RSS sources come to our feed readers, and we can control what users we follow on twitter. We can track topics by keywords, or block in the same fashion. The problem with this approach in a web 2.0 world is that every user produces so much content. White listing all of a user’s content or all content of a certain keyword is too much to consume.

Lately, several aggregators have come on the scene attempting to help this. FriendFeed, AlertThingy, and Twhirl come to mind.

Aggregation is not the answer.

Aggregation solves the wrong problem. It operates under the assumption that we can handle attention management just fine if we get all our information on a single page. Really, the problem with these apps is that all information is considered equal. In FriendFeed, a blog post and a tweet have equal standing. Visually, equal space is given to each. No one presumes these two things have equal value. In fact, many would argue that they can’t even be compared; it’s apples and oranges. Yet, since we consume all kinds of information, how do we arrange this content for maximizing consumption?

Really, we’re talking about something Lisa and I choose to call attention management. Arranging data to be consumed when it does us the most good, and limiting our interaction with data that isn’t useful. Thankfully, ranking content is something computers are very good at, as long as you give them the right metrics. Give them the right metrics, and they can identify what I choose to call the two axises of attention management: immediacy/staleness and stickiness/transitiveness.

Using these scales, I can define thresholds for what kinds of content I want to see and how quickly I want to see them. These are also style guidelines. Content needs to be presented differently based on these characteristics.

It all comes back to reducing noise from the signal. There are many approaches to this problem, and Technarium will be competing in this space soon. I want to think Lisa and I have the answer, but the answer will come from anyone who executes properly on this question: how do you prevent information bankruptcy?

• Discussion fragmentation
  Multiple services have been spending a lot of time implementing comment functionality, but all they’re doing is creating more places I have to check for feedback.  I’ve already been noticing this problem thinking about lifestreaming in general.  When I post a picture to my tumblelog, should people post comments on my site or on Flickr?  I love how Alert Thingy enables people to comment within the flow, but until those comments become directly associated with the original content they’re only making life harder.  The last thing I want is to have yet another conversation to manage.
• Dealing with Twitter whores
  I used to abide by the “what are you doing” mandate pretty strictly and limited myself to 1 or 2 messages a day, but a few months ago I started getting too involved to hold back.  And of course, I’m not the only one.  The example I always use here is local Twitter hero Nate Ritter.  He’s one of the most insightful and engaging users I know, but sometimes I just don’t have time for as much insight as he generates.  He was the source of inspiration for this post I made months ago on Get Satisfaction that lead to the concepts of user controlled squelch (put someone on mute for a while) and automatic rate limiting (aka Nate limiting) when someone is communicating faster than your desired threshold.
• Identify only important messages
  But how do you know which messages are still important?  Dave is the numbers guy who is thinking about how to do this algorithmically, but one of the key methods he’s identified is based on how many replies a message stimulates.  It sounds pretty obvious, but implementing this functionality in such a way that it generates individually useful results is actually a bigger challenge than it looks, since it also requires knowing each user’s baseline engagement and some FOAF analysis (a conversation is more important when your friends are participating).
• Filtering
  Everyone’s focus is on getting more messages so you don’t miss anything.  What about the messages you already know you don’t care about?  SXSW was a perfect example of this.  I had real friends stop following me because the messages generated by this event were overwhelming and irrelevant, so I can’t say I blame them.  I did the best I could to use the #sxsw hashtag…if only track had the converse functionality of block, a bulk of attention management problems could be avoided without doing any other messy priority analysis.
• Contact management
  I don’t have one big cloud of friends in real life, so why do I still have to interact with Twitter the same way?  I want to keep track of what’s going on through defined groups to provide a better context of who they are, or hell…implement some better functionality to remind me who they are in the first place.  And with the exception of turning notifications on or off, everyone on twitter is considered equally important, which isn’t sustainable without severely limiting mobile functionality.  Sean Bonner recently posted some good ideas around this, too.  Some people I want to get updates from 24/7 wherever I am, some people I’m content to hear from when I happen to be at my computer.  Other people (and especially most track messages) I just want to stay abreast of in a daily digest email.
• Twitter is ignorant
  Regardless of what I happen to be doing any given day, Twitter continues to blast away.  I’m already publishing my availability information in the cloud via Google Calendar and my IM status, and somebody desperately needs to start taking advantage of this information.  If Twitter were smart, it could be so much more than a glorified IM client.  Not only would the service know better than to send me notifications when I’m in an important meeting, it would also behave more like a mobile command line for users to ask “What is Lisa doing?”.  Although nowhere near ready for public consumption, Dave wrote a Twitter bot with the AI to answer such a question with “Well Dave isn’t in front of IM, but he has class in 10 minutes, so he might be in transit. But his phone is in the charger, so he either forgot his phone or is oversleeping.”  Now that’s revolutionary.

I confess, Dave and I have spent hours whiteboarding, wireframing, and debating these ideas.  We’re consumed with it.  We know how to address some of the issues we’ve raised, but for others we either don’t have the resources or can’t cleanly implement a solution without being Twitter.

But information wants to be free, and I’ve been about to pop for three months thinking about all this.  We’ll still be working on our own solution, but there’s sadly only so much a statistics student and a girl with big ideas can do to change the world.

So as always, if Technarium can’t get to it first, I damn well better have an invite to the beta.

This may change to github in the future, but for now the project’s current home is http://code.google.com/p/fireeaglenet/

Some things I want to see added that will come down the pipe:

• More robust error handling
• Documentation could be better
• Release the Eagle Perch source as a demo application that uses this library
• Windows CE support

If the community can come up with other ways they’d like to see this library improved or would like to contribute, we’d be happy to hear it!

Last week, Yahoo launched Fire Eagle at ETech. Fire Eagle is a platform for sharing location information about yourself. The most powerful piece of this service is its privacy consciousness. Users who publish their location via this service have very robust controls regarding how third party applications access to their data. While not much value on its own, Yahoo is hoping that community developers (like Technarium!) will step in to provide novel uses of the service via their API.

While experimenting, I developed Eagle Perch. This small application will sit in the background of your PC. Whenever you return from idle, it will update Fire Eagle with whatever location you specify. Presumably, when you return from idle on a PC, you will be at that PC’s location. For machines that don’t change location often, this can be a good alternative for location sharing for those who don’t have GPS-enabled devices. Put it on your home and work PCs. Combine this with other location publishing applications that are sure to emerge, and you’ll have an alternative to GPS that’s pretty strong.

Eagle Perch can be downloaded here.

I’d love to see how this chart changes in six months to see which users are growing their social networks, how fast they’re growing, and who’s staying the same. I also want to see how this data is distributed by location or how many people in each percentile are following others +/- XX% from their own rank. Since this is along the lines of the research David is going to present at BCLA, I don’t think I’ll have to wait too long.

With that said, I’m really confident that we’re providing something empowering to give users the control of their data that they deserve.  I’ve been able to learn and explore and research and play so much since the inception of Liberatr last summer that just backing up metadata seems like only a tiny puzzle piece of what this application can become, but the data architecture that Dave established with Liberatr is the critical foundation to build on for Technarium’s future.

This is just the first baby step.  But we still have to nail it.

• Why the crap isn’t this a social network?

  Rather than trusting the participation of strangers to determine who gets my next invite, I want to make sure my network of friends has access first.  Yes, this will make the service less fair since invites will be distributed through the popular cliques first.  But since those are the people I’ll want to use these new services with anyway, the overall experience to actually experience what the site is like will be more realistic, which means better feedback for the companies involved.

• Speaking of social networks, just make it work with Facebook

  My friend network is already in Facebook, so don’t make me create another one.  Facebook also has existing infrastructure to make it easy to see what betas are becoming popular among your friends. 

• Help me track what I’m participating in

  I have a folder in Outlook dedicated to confirmation emails for services I’ve signed up for, which is where I currently start to see which websites to visit to check what I currently may or may not still have invites to.  When I first sign up for something, I’d love to be able to tell InviteShare how many invites I’m given so I only have to scan one page to see what’s in my account.

• Blog widgets

  Admit it, twittering that you have invites to the latest exclusive beta du jour is a status symbol.  Why not enable users to show off what they have available?  One-click invite requesting through the widgets adds value for both blogger and reader as well since it would mark the end of combing through and decoding scrambled email addresses left in comments.

• Make sending invites easier

  Going through InviteShare actually adds a layer of complexity to the invite distribution process since all email addresses are displayed as images.  This is important to prevent harvesting by spammers, but I want to define a list of people I trust to at least have plain text or click to copy access to my email address.  If you had many friends with emails like sh4v3nw00ki3@obnoxiousdomain.com, you’d appreciate this functionality, too.

• RSS feeds for the tumbleloggers

  InviteShare already has big, pretty logos for all the companies in the service…put this in a feed that updates every time I join a new beta and I would be a happy girl indeed.

• Ratings and reviews

  Is the beta you’re interested in worthy of all the attention it’s getting, or is it just a slow news day?  Let users rate the services to help determine if it’s even worth their time to get on the list.

• Get widespread buy-in

  Once companies see how much of a value add these social features are to the invite process, it would be an easy sell to establish partnerships to integrate the process even further.  This could be accomplished without too much pain by extending the existing invite code system (note: this is where someone like Dave steps in to figure out the necessary APIs and architecture).

If InviteShare (or whoever takes this free advice) implements any of this functionality, they’ll be sitting on a marketing opportunity better than gold.  And I damn well better have an invite to the beta.

What worked

The UI. Creation of the UI was a collaborative effort between myself, Lisa, and a white board for three hours. The final interface did not change from what we drafted in those three hours. Very rarely does that happen in development, and we created a flexible interface that accentuates our feature set.

XML files for storing metadata. Taking advantage of .NET’s built-in serialization techniques, we were able to quickly make human readable files for each downloaded set that contains all the metadata we pull from Flickr (or any other source in the future). This was another early design decision that turned out well.

Design Philosophy. Technarium is built on the principle of “apps you love to use.” We create small, innovative apps that fill an essential need in the community they target, and we wrap these features in elegant interfaces. The conception phase of this project worked perfectly.

What didn’t

Inefficient testing pipeline. Testing many features was a slow process, and because of the nature of flickr accounts, testing upload functionality was difficult at times. We also had no written test plan, and several times encountered regression bugs. We didn’t have a very efficient flow or schedule for builds, and getting them to the testers took time.

Object hierarchy isn’t as clean as it should be. Image management is deceptively complex. We originally built our object hierarchy similar to Flickr, but we discovered later that this model didn’t easily support certain operations. We wasted a lot of time recoupling objects. This could have been avoided if we spent more time in the beginning exploring the actions we’d need to perform, both in this iteration and in the future.

Confused purpose. Our feature set got a little muddled toward the end, because this Liberatr is part synchronization tool, part backup tool. We’re also waiting to see how the community receives the app before we decide which way to continue developing: sync or backup.

API. Liberatr relies on the Flickr API and the Flickr.NET wrapper. The wrapper behaves badly in some cases, like when Flickr’s API returns null sets. For future work, it will be worthwhile for us to lend some development muscle to the API projects. It benefits us, and it’s a way of saying thank you to the projects that assist our work and the work of others.

Final Thoughts

As a rehearsal, Liberatr is a success before we even release. We confirmed that our design philosophy is solid. From here, we will release to the public for feedback before deciding the next step. In the meantime, we will move forward with other applications using the same design principles while keeping in mind the mistakes we made.

Working on this project was a great experience. Thanks to everyone who helped make it happen!

Exposure on Get Satisfaction is a marketing opportunity in itself
As much as I would love to build a flourishing user and support community who lives on this site, it’s hard for a little guy to get started while being that self-contained. Using Get Satisfaction instead of a hosted forum creates an ad-hoc partnership with a fast growing community of folks who have proven that they love fun applications and participating in a knowledge base. Each user’s tumblelog-inspired dashboard creates a golden opportunity to showcase your real product (for better or worse) to an even wider audience.

I’m a big fan of Rubyred Labs
After my experiences with these guys during the brief life of Valleyschwag, it was easy to see that these guys understood customer support. They proved that for all but spaceships and FDA regulated products, it’s better to be open and honest than miss a ton of great marketing opportunities by only owning up to perfection or catastrophe. Anything they believe in is worth a fair shot in my book.

Theming bbPress to look like the site was going to be a pain in the ass
Ok, I’ll admit it. I’m too lazy at the moment to learn how to make a bbPress theme. Get Satisfaction saves the day with easy to embed widgets and RSS feeds for just about everything.

Considering these points, the decision to test the waters of THE Web 2.0 support site was an easy one to make. I would still love to find an application for bbPress (forum brat, remember?), but right now Satisfaction is a force more worth taking advantage of.