I’ve recorded another screencast of the Ringside Social Payment service that demonstrates the use of a multi-friend selector when making social payments. There is an interesting lead-in to what will eventually be part 4 in this series…the multi-network multi-friend selector. For details, watch the video here or click the image below.
As we at Ringside build out our administrator dashboard, I’ve been working on a feed retrieval API and a new social tag for feeds. When developing applications for Facebook, the application can only publish feed entries via the Facebook API, but there is no way to retrieve those feed entries. The Ringside feed tag will enable just such a capability, as well as the ability to import RSS feeds from anywhere online. Here’s how:
<rs:feed-aggregator display="byDateTime">
<rs:feed uid="100042" friends="true"
actions="false" stories="true" />
<rs:feed
url="http://del.icio.us/rss/ringsidenetworks" />
</rs:feed-aggregator>
This example is slightly complicated, so I’ll break it down piece by piece. The first thing to note is the feed-aggregator tag. This tag aggregates feed entries for all of its contained feed tags, and displays them according to the value of the display attribute. Currently, feed entries can be displayed by date and time or by tag.
Next you’ll notice that the feed tag can be used in different ways. The first feed tag in the example reads from the social network’s database and is controlled by the attributes specified. The feed tag will retrieve feed entries relative to the id of the specified user. Alternatively, the ‘actorid’ attribute can be specified for feeds that are relative to pages or applications. If the ‘friends’ attribute is true, only the entries by the user’s friends will be displayed. The Facebook API enables the publication of actions and stories, and those attributes determine whether the feed tag should retrieve actions, stories, or both.
The second feed tag in the example is what you would think it is for - reading and displaying RSS feeds. The feed tag will retrieve the latest feed entries from the specified URL and display them according to the display attribute, which is not shown in this example since the feed-aggregator tag will do all rendering according to its display attribute.
This should be pretty exciting for social application developers, since integrating RSS feeds and social network feeds into their applications will become very easy.
These tags are currently under development, so if you have ideas to make them even better, please share your thoughts via a comment below.
I don’t pretend to know what the future of the Social Web holds, but I have some ideas about the markup language that will power much of it. First though, let me recap the short history of Social Web Markup.
About a year ago Facebook launched their social network with a full application platform consisting of a rich set of social APIs, many of which were wrapped with easy to use tags called FBML (FaceBook Markup Language). Since then, a few things have happened. First, Bebo opened up their social network with their own markup language which they called SNML (Social Network Markup Language), which was mostly the same as the FBML collection, though it included some tags only offerred by the Bebo platform. Finally, Ringside Networks released beta versions of their Social Application Server, which supported many of the FBML tags, and a few only available on the Ringside Platform.
This is all well and good, since tag libraries for specific social networks definitely enable social application developers and designers to create rich social applications quickly. What is unfortunate about the current situation is that these tag libraries are closed in that they are only supported by the platforms that offer them (though the open source Ringside Social Application Server supports many FBML tags). This means that social application developers would have to rewrite portions of their applications in order to deploy to multiple social networks. I’m reminded of the early days of the J2EE application server market, when each vendor offered their own tag libraries in an effort to differentiate their platforms from each other. In the end though, most of those tag libraries did many of the same things via different syntax, and ultimately JSR-52 was established and the JSTL (JavaServer Pages Standard Tag Library) was produced. Now all J2EE application server vendors support JSTL.
I don’t necessarily see the same course of events unfolding in the social web space, but perhaps there will be some similarities. First of all, I’m inclined to believe that social application developers will want to be able to write a social application once and run it anywhere. In order for that to happen, those developers would have to code using standard APIs and tags, which is an argument for a standard for a social tag library. Alternatively, because Ringside offers the ability to render social tags via widgets, I can see a whole community emerging around social tag development, which would in turn enable the rendering of those tags via widgets anywhere across the web.
What do you think? Are you a social application developer? Do you want to be able to write once and run anywhere? If so, how do you see social tags evolving?
Rich Friedman recently discussed the architecture of the Ringside Social Application Server with some new members of the Ringside development team. Watch the video below to see where Ringside started from an architectural perspective, and where the architecture is today.
Last week Jonathan Otto, author of the Run Voomaxer Facebook application, and Eric Pascarello, highly acclaimed author of AJAX In Action and JavaScript: Your Visual Blueprint for Building Dynamic Web Pages, joined the Ringside team and participated in some great discussions with the team. In one of those discussions, Rich Friedman gave an overview of various open source licenses and what they mean, including GPL, LGPL, BSD, and others.
If you’ve ever spent too much time on Facebook, you may be familiar with the ability to declare yourself a fan of a page. For example, I’m a fan of the Philadelphia Eagles on Facebook (see below).
Wouldn’t it be interesting though, to enable people to declare that they are “not a fan” of a page. For example, as an Eagles fan, it would warm my heart to declare myself “not a fan” of the Dallas Cowboys. Such an action enables users to further define their social identities.
This doesn’t seem all that important on the surface, but let’s take a minute to think about a case that may be important to a business. Let’s say that I own a golf course and that I created a page on Facebook for this golf course of mine. Currently, I can see those users that are “fans” of my golf course, but I have no visibility regarding those users who are not fans. Wouldn’t it be great if I could learn about what people don’t like about my golf course via Facebook? Perhaps users could enter comments when they declare themselves “not a fan”. As the owner of the golf course, I could take corrective action based on what I learn from those comments.
Let’s face it, people like to complain. Why not enable businesses to learn from it? I’ve created a new feature request for such a capability to be built in the Ringside Social Application Server (see JIRA item). What do you think? As a Facebook user? As a business owner? As a brand manager?
Last week I started fiddling with UStream. At first it was just a cool new technology that I was trying out, but it has evolved into a daily part of our lives at Ringside Networks. We’ve been streaming live video for about a week, which has been working out very well. For those team members that are remote (we have 3-4 depending on the day), they have been privy to the office conversation that they have always missed. Since we started streaming, those remote teammates have been clamoring for better cameras, and more of them.
You can view our live stream here. Note that there are portions of the day that are very boring. For example, at the moment, anyone that is tuned in will be watching my face as I type this blog entry and listening to Weezer. However, Twitter is a great tool for notifications. Whenever an interesting discussion is going on, I’ve made a habit of turning the camera outward towards my colleagues and the white board and logging a message on twitter with a link to our live audio/video stream. Follow me on Twitter if you’d like to get these updates.
The most interesting part of our use of this technology is that it pairs nicely with our open source development model. For those developers out there using our software, they can watch and listen while we discuss how to resolve a bug, how we will prioritize our work for the next beta release (every two weeks), or just get a feel for where we stand on a daily basis (our daily stand up meetings are at 2:30pm EST). Even better than watching live though, is that the community will have the ability to participate through the chat window in the UStream interface. For our remote team members, we’ve been using Skype to bring them into the live discussion. As users of our software, you could potentially have the same level of access.
To me, live streaming takes open source development to the next level of openness and provides an engaging experience that will ultimately result in better software and faster solution delivery due to the availability of this rich communication medium.
By the way, we also tried Stickam for a day, which offers group video chat capabilities. Our experience has been that Stickam’s availability is not as good as UStream’s. Also, Stickam’s user interface wasn’t very intuitive or descriptive. We have tried on two separate occasions to coordinate three video streams in the same session without success. Regardless, this service has great potential, and I look forward to improvements that are surely coming.
Ringside Networks is working on a social payment service that will enable users to subscribe to real business applications, and in the near future, pay for their friends as well. Application providers will be able to offer payment plans that are specific to social networks such that a user can pay for themselves (say $5/month), themselves plus three friends (say $7/month), themselves and five friends (say $10/month), or themselves and all friends ($25/month). But enough about that - check out the video demonstration.
Ringside Networks has released their Social Application Server’s second beta release, which includes pricing plan provisioning for social applications (amongst other great things). What this means is that Facebook application developers could begin charging their users monthly subscription fees for access to one or more levels of value added application features when deployed on the Ringside Social Application Server. The implementation of end to end payment is not yet complete, but the video below will give you a better feel for what’s coming (click the image to see the movie).
Every Wednesday I leave work at 4:30pm to go to school (I’m going for my MBA at Rutgers). When I get there, the first thing I do is get my $4 latte. Sometimes I stop by a different Starbucks on a major highway on my way to work. When I look around, people are hosting job interviews and business meetings in the seating area of the store. For years, my wife and I have frequented the Starbucks counters that are inside Barnes & Noble stores for a coffee after a dinner out (which was the case this evening). When I look around, people are reading, working on their laptops, or just enjoying conversations together while sipping their lattes.
The point is that Starbucks has found a way to make itself part of people’s lives, and has done so successfully for years. These days however, Starbucks is facing a recession, new competition, and the loss of customers. But not to worry, I have an idea: Starbucks should focus on making themselves part of the online lives of their customers, particularly in a social way.
Starbucks could build applications that enable users to publicize their favorite Starbucks drinks to their friends, to rate drinks (existing and new), or even to send their friends a latte, virtual or real. They could tie their social application to a Starbucks loyalty card…I can foresee a ‘buy five, give one’ type of program that could potentially bring new customers into the store, or into Starbucks’ social network. And these applications are just the tip of the iceberg. Regardless, Starbucks could increase customer engagement with the brand, tap into the viral nature of social networking to attract new customers, and increase brand loyalty by providing a high quality, fun online experience to its customers and their friends. Oh, and let’s not forget, such a solution would be yet another valuable channel for market research.
Starbucks is a very, very strong brand. Everyone knows Starbucks, and they know what they stand for. Therefore, Starbucks shouldn’t settle for a social networking solution that lives behind someone else’s branded look and feel, such as Facebook or MySpace. Nor should they have to invest millions of dollars for a consulting company to build a custom social networking solution on their behalf. Ringside Networks has already provided a starting point, and better yet, the software is free. For little expense (maybe 1-3 consultants) and in a short period of time, they can stand up their own Starbucks branded social network that immediately taps into the Facebook community, and within months the Myspace and Orkut communities as well (pending Ringside’s implementation of OpenSocial support to be delivered in June).
In my opinion, such a move by Starbucks is a no brainer. Customer acquisition is currently expensive, and a social solution, particularly one that requires minimal investment, is likely to have a return on investment that is off the charts.
|