Home - Stay N Alive

With New API, Twitter Attempts to Kill Autofollow Apps

Posted on June 21, 2013 by jessestay

Just this last week Twitter retired their long-lived 1.0 API for developers. This API was the first “versioned” release, a breath of fresh air in many ways for developers that were tired of API updates breaking their code. On June 11th, Twitter forced all devs to upgrade to their 1.1 API however, breaking many developers’ apps in the process (mine included). What hasn’t been said yet is that autofollow apps (apps that automatically follow people that follow you) seem to be out of luck with this new update, and no word yet from Twitter.

The problem with 1.1 lies in a new set of rate limits. Developers are allowed to make a certain number of calls per API method, meaning each method can only be called a certain number of times within a given time frame. This, I’m sure, is freeing up all kinds of resources and money on Twitter’s servers.

However, for apps relying on regular updates to a person’s social graph (their followers or friends), this reeks havoc on those apps. The rate limit currently for just getting the ids of a single user is 15 API calls per 15 minutes. Here’s the problem: you have to make a single API call for every 5,000 friends or followers that user has. Twitter’s API requires apps to “page” through a user’s friends and followers 5,000 at a time. This is great if a user has under 75,000 friends, but once you make that API call over 15 times to get a user’s friends, you’re stuck waiting another 15 minutes to get the rest of their friends. Now imagine if that user or brand has over 100,000 friends or followers! Or what about over 1 million! It’s impossible for an app that is trying to evaluate a person’s social graph to always know a person’s followers or friends in that rate limit, rendering apps like auto-follow, or even simple social graph analytics, impossible.

When you think about it, this might make sense per Twitter’s current business model. For users and brands with over 75,000 followers, I’m willing to bet Twitter would love to have them as customers. Many of those can afford an account rep that can take care of custom requests. In addition, Twitter now has their own analytics to track a user’s social graph growth over time. So maybe Twitter is discouraging these types of apps. I’m fine with that as long as they are open about it.

If this is the direction Twitter is going, I have to say I’m used to it. To be honest I haven’t been putting much effort into my own service that has focused on the social graph of Twitter users, SocialToo, because of it. In many ways it has just become another “hole” filler in Twitter’s API history. As a developer though, this is certainly discouraging, and even further driving me away from Twitter’s developer platform.

I hope I’m wrong. I’ve asked in the Twitter developer forums with no answer yet. Is there another solution I’m missing? Let me know in the comments and I’ll do another post showing how to do it.

2012 Google I/O – Is This the 2007 Facebook F8?

Posted on June 21, 2012 by jessestay

All eyes should be on Google’s Annual Developer Conference, Google I/O next week. As the first Google I/O with the Google+ Team, and a serious read/write API yet to launch, I predict we are about to see an explosion of social apps at a level we haven’t seen since Facebook’s F8 Conference in 2007 when they launched their platform to the world. The parallels are very similar.

Let’s look first at the original APIs for both. Some may not be aware of this, but previous to Facebook’s 2007 F8 conference, they too had an API very similar to the state of Google+’s API today. Called “Facebook Developers”, the original API in 2006 was limited to a small number of requests per day, very similar to Google+’s current platform. It was mostly a read-only API, with, eventually, the ability to create widgets that could be embedded as apps on a person’s Wall – a new feature of Facebook at the time. You could also access very limited data about a person’s friend graph and wall posts. It wasn’t until F8 of 2007 that Facebook really opened the floodgates for this, increasing API requests, opening up the ability for “Canvas apps”, and giving full access to integrate apps into multiple “integration points” within Facebook itself. In fact, it wasn’t until years after that that developers could really start integrating this data into other websites and mobile apps. Just like Google+, Facebook took baby steps to launch their API, but when they were ready, they launched big.

Google+ is in a very similar state today. Their platform is limited in the number of requests you can make per minute, and per day. They only allow a few select enterprise partners write access to the news feed. They’ve opened up a few elements, such as games, to a few partners to integrate right on Google+, but in very limited form. They’re in a very similar state to Facebook in 2007. When Facebook launched though, developers came in droves, seeing user growth in the millions in a matter of days. Facebook itself grew significantly during this time.

It was during this time that I met Paul Allen, who was looking to launch his company, FamilyLink (originally called We’re Related). He and I both saw eye-to-eye on the power of this platform, and while we both took our separate ways we saw first hand the power of platforms like these.

While I’m sure Google has had the opportunity to learn from Facebook’s mistakes (Facebook has had to change their platform quite a bit since they originally launched), I anticipate we could see a similar flood when Google+ finally launches their full platform to the world. Will we see a Canvas Page-like approach? I’d guess we will – OpenSocial supports this and much of Google+’s current platform bases on OpenSocial standards.

I anticipate a number of integration points, a raised request limit, and as a result an increase in apps, and developers coming to the Google+ platform. There’s one advantage Google+ has over Facebook though: Google+ has Google. Remember always that Google+ is just a social layer over all Google products. That means even their platform will likely some day extend across all of their products. This is exciting, and what will bring similar success to developers in the same way Facebook did back in 2007.

Next week is a very exciting week for Google+ and Google as a company! I’ll be there every day of the conference, and I can’t wait to see what gets announced. To me this is one of the most exciting conferences in the history of Google, and it will be fun to have a front seat to this moment in history. Keep watching my stream on Google+, and on StayNAlive.com to keep updated of the event!

(Disclosure: FamilyLink is a former client of mine)

Originally posted on Google+!

Facebook Posts New Dashboard API Methods, Prepares New Interface

Posted on December 5, 2009 by jessestay

Early today Facebook posted a series of new API methods to their Developer Wiki enabling developers to post updates to what was previously called the “Application Navigation”, but what would now appear to be called “the Dashboard”. The Dashboard API aims to provide an easier interface for users to find updates to their favorite apps without cluttering the stream. At the same time, the Dashboard API tries to encourage more users to bookmark applications and provide applications on Facebook Platform another means of sharing information with their users.

The Dashboard, which will appear on the left-hand navigation either in place of or near the Friend Lists, should launch to users in the next week or two according to a vision statement posted by Mark Zuckerberg recently and the current developer roadmap. When launched, users will be able to bookmark their favorite applications on Facebook or on their favorite Facebook Connect-enabled site and those applications will appear in the left-navigation in the new Dashboard. Applications can then send updates, incrementing a counter when new updates are posted, enabling users to know when new updates are available from their favorite applications. When the user clicks on each application they are taken to a page with the updates.

In addition to traditional applications, according to the new developer documentation there will be a games category in the dashboard. If applications have categorized themselves as a game in the Facebook App directory, their app will appear underneath the Games category. This category appears to try and make it easier for users to manage all their games under one easy navigation so they can focus on the more productive apps beyond just gaming. Other applications appear under an Applications category, and there is also a “Friends’ Games” and “Friends’ Applications” category enabling users to view applications and games their friends are using, I assume.

The new Dashboard API enables developers to do all the things mentioned above, and comes alongside the 6 month developer roadmap announced earlier by Facebook. The roadmap comes with mixed criticism from developers, with some excited for new integration opportunities and better organization, while other developers mad at the removal of some features in the planned changes. One developer I talked to today was frustrated with the frequent changes Facebook makes on the Facebook.com site itself, opting to begin moving his development efforts more over to Facebook Connect where he has more control. I believe that is exactly where Facebook wants him.

The new Dashboard API should provide new opportunities for developers to update their users and easily notify users of changes within their apps. The API, according to the documentation, is available for development and testing now. According to the documentation there is no sandbox for the new API, but developers can start testing these methods on their own servers. It is unclear how developers will be able to begin testing the UI for the new methods.

Kynetx Kills the Portal, Launches Identity Platform for Developers

Posted on November 18, 2009 by jessestay

Today at Kynetx Impact Conference Kynetx is changing the future of Web Identity and privacy as we know it by taking the power away from the server and moving it over to users’ desktops, mobile phones, or other client-based technology. Dr. Phil Windley, company CTO and co-founder in his keynote shared that the web client is the “forgotten edge” when it comes to open software development and identity management. Currently the traditional model in identity has been one of location base, instead of purpose-based, as Dr. Windley has suggested is the future of internet activity. Today Kynetx is releasing a developer platform which intends to enable that purpose-based identity on the web.

About a year ago I wrote on LouisGray.com about how sites like Twitter have become the “portal” of Web 2.0. The idea is that users are starting to use Twitter as a gateway to post content to the other sites that they actually use. Portals have been around for awhile, Yahoo perhaps being one of the most prominent and brings content all into one location, intended to personalize the aggregation of content to the user. In that sense, sites like FriendFeed are also modern portals.

Identity Solution #1: The Silo

The weakness of the traditional portal is that it is Location-based. Dr. Windley suggested that users that visit websites aren’t there to visit a location – they have a purpose as to why they visit the website and portals can’t solve this problem. Server-based solutions cannot determine the purpose of users visiting each website, as they are only capable of tracking an IP address for that user, which in and of itself isn’t even always reliable. Sites like Facebook have tried to resolve this problem by bringing the user into a Silo, enabling them to tell others in that Silo about themselves, allowing better privacy since it is all controlled in a Silo.

The problem with the Silo method is that one single entity owns the user’s data in that case. Users are at the mercy of the Silo to get their data out of the Silo and if the Silo ever goes away or the user ever leaves the Silo, so does their identity. What Kynetx is doing is working to remove the need for that Silo, hopefully enabling sites like Facebook that intend to respect user privacy and user choice (something I defined earlier as another definition of “open”), taking the user’s identity information and allowing them to store that information on their desktop or in the browser itself.

Identity Solution #2: The Client and “Information Cards”

Currently through an open technology called “Information Cards”, users are able to store identity information for the various websites they visit on their own desktop. This information is owned by the user, does not get stored on a developers server anywhere, and gives an even more detailed view of the user than any other source can give. Kynetx is looking to bridge these Information Cards to the browser via an API through which developers can utilize these cards, and customize the browsing experience a user has as they have a purpose they want to accomplish on the web.

One example Dr. Windley shared was that of AAA (triple-A) automobile service. Using the Kynetx engine, a developer can take AAA data, and mesh it with search results on Google.com and Yahoo.com, and based on a user’s Information Card identify the search results that might be pertinent to that user in relation to AAA. Another example of this is on the actual wireless network they are using at the Kynetx Impact Conference, in which they are placing various markers to give more information about the conference. For instance, as I type this, I am seeing a little “Schedule” tab to the right that I can click any time and have the schedule for the conference pop up. Anyone can implement this technology, and Kynetx is enabling any developer to write their own layer to the web utilizing a user’s true identity and bring that identity on top of the web itself. This stuff is powerful!

Imagine these applications in the mobile space – what if a developer could take this similar conference technology Kynetx is using at this conference, and apply it to a mobile browser, showing the location of everyone else in the conference on a map, but also showing their identities, perhaps grouping people together by experience and what their interests are. Or, if you take this to the shopping experience, a vendor could cater a completely customized shopping experience that is completely controlled by the user. With Kynetx, the customer truly is the boss.

Kynetx is doing some amazing things in the identity space. It’s amazing to watch as the leaders of this space – Phil Windley, Craig Burton, Doc Searls, Drummond Reed, and Kim Cameron are all here working to change the way we view identity. True identity belongs on the client. True identity belongs in the hands of the user. Kynetx has just changed everything with their new platform. I encourage you to check it out. You can learn more about Kynetx at http://developer.kynetx.com.

Here’s an interview I did at a dinner they invited me to last night with Phil Windley where he explains the concept:

[youtube=http://www.youtube.com/watch?v=IyC3fUbo3X0&w=425&h=344]

"X" Marks the Spot for New Paypal Development Platform

Posted on November 4, 2009 by jessestay

“X”. It’s a common variable used in many a code base. It’s one of the most common variables of any code base. It’s what counts. That’s what Paypal wants to become in the hands of developers, as they stated in their kickoff Keynotes this morning at the Paypal X Innovate developers conference in San Francisco this morning. Paypal is bringing back the name of their original developer platformed, called “X”, to introduce new, easier, and better ways of facilitating transactions for developers.

Paypal has big visions for their new payments platform. As Ebay CEO Jon Donahue stated, “I believe Paypal will be bigger than Ebay because Paypal can power all e-commerce”. It would appear any rumors to Ebay selling off Paypal may be bunk in the eyes of their CEO. Together, Paypal and its customers are working to release the next wave in payments integration. Today Paypal announced a new adaptive payments platform in which developers are now going to have the capability to integrate into their own applications. Among the examples shared:

Integration of Paypal into your online banking experience — an example was shared of a bank enabling you to pay your friends by simply visiting your bank’s website, entering the e-mail address of your friend, and sending the transaction to that friend through Paypal. (I wish my banks allowed this!)

Facebook Integration – Payvment did a presentation of their software that enables developers and website owners to integrate an entire shopping cart experience via just a simple snippet of Javascript code. They also announced that they are open sourcing this software for Facebook developers to also integrate this same shopping cart experience into their own Facebook apps. (This is very valuable!) I’ll try to do an interview with them tomorrow.

Sun and Java Integration – Sun Microsystems did a demo of their own sharing how they were using Paypal’s X Platform in their Java store

Mobile – With the launch, Paypal is launching new mobile SDKs. They did a demo on the spot integrating a simple payment code using Paypal’s iPhone SDK in XCode. A couple drags and drops and copies and pastes and they had a fully-integrated payment experience on the phone.

In addition to the launch of their new platform, Paypal announced a series of new payment standards. The payments will be adaptive, depending on the amount being charged, making a very appealing option for micro-payments to even very large payments depending on the size of the transaction. In addition, developers will be able to decide who pays the commission, something different from their current developer platform, meaning the business itself does not have to pay the commission. The commission can be paid by either the seller or the buyer, ensuring new creative ways of facilitating payment transactions.

Paypal’s new X platform of course compares with Amazon’s Flexible Payment System. Tomorrow I’ll do a post comparing the two as I’m able to gather more data. With the new platform it would seem that Paypal is putting the pressure on Amazon and stepping up the game of finally getting rid of the cash in your wallet in favor of much easier payment services in the cloud.

I look forward to sharing more from the conference. I’m very intrigued by some of the Facebook solutions, as well as Twitter payment systems and I’ll share those as I get them. I’ll also be watching the various ways other companies are utilizing the platform.

I truly believe we’re on the cusp of an entirely new wave of payments. The competition is on in full strength at Paypal X Innovate and I can’t wait to see what comes of it.

Here are a few Cinch recordings I did of the keynotes in case you missed them:

“X”. It’s a common variable used in many a code base. It’s one of the most common variables of any code base. It’s what counts. That’s what Paypal wants to become in the hands of developers, as they stated in their kickoff Keynotes yesterday morning at the Paypal X Innovate developers conference in San Francisco. Paypal is bringing back the name of their original developer platform, called “X”, to introduce new, easier, and better ways of facilitating transactions for developers.

Paypal has big visions for their new payments platform. As Ebay CEO Jon Donahue stated, “I believe Paypal will be bigger than Ebay because Paypal can power all e-commerce”. It would appear any rumors to Ebay selling off Paypal may be bunk in the eyes of their CEO. Together, Paypal and its customers are working to release the next wave in payments integration. Yesterday Paypal announced a new adaptive payments platform at x.com in which developers are now going to have the capability to integrate into their own applications. Among the examples shared:

Integration of Paypal into your online banking experience — an example was shared of a bank enabling you to pay your friends by simply visiting your bank’s website, entering the e-mail address of your friend, and sending the transaction to that friend through Paypal. (I wish my banks allowed this!)

Facebook Integration – Payvment did a presentation of their software that enables developers and website owners to integrate an entire shopping cart experience via just a simple snippet of Javascript code. They also announced that they are open sourcing this software for Facebook developers to also integrate this same shopping cart experience into their own Facebook apps. (This is very valuable!) I’ll try to do an interview with them tomorrow.

Sun and Java Integration – Sun Microsystems did a demo of their own sharing how they were using Paypal’s X Platform in their Java store

Mobile – With the launch, Paypal is launching new mobile SDKs. They did a demo on the spot integrating a simple payment code using Paypal’s iPhone SDK in XCode. A couple drags and drops and copies and pastes and they had a fully-integrated payment experience on the phone.

In addition to the launch of their new platform, Paypal announced a series of new payment standards. The payments will be adaptive, depending on the amount being charged, making a very appealing option for micro-payments to even very large payments depending on the size of the transaction. In addition, developers will be able to decide who pays the commission, something different from their current developer platform, meaning the business itself does not have to pay the commission. The commission can be paid by either the seller or the buyer, ensuring new and creative ways of facilitating payment transactions.

Paypal’s new X platform of course compares with Amazon’s Flexible Payment System. Later today I’ll do a post comparing the two as I’m able to gather more data. With the new platform it would seem that Paypal is putting the pressure on Amazon and stepping up the game of finally getting rid of the cash in your wallet in favor of much easier payment services in the cloud.

I truly believe we’re on the cusp of an entirely new wave of payments. The competition is on in full strength at Paypal X Innovate and I can’t wait to see what comes of it.

Here are a few Cinch recordings I did of the keynotes in case you missed them:

http://www.cinchcast.com/user/default.aspx?albumUrl=Paypal-X-Innovate

I Should Have Heeded My Own Advice About Twitter

Posted on April 21, 2009 by jessestay

About a full year ago, I wrote of developers leaving the Twitter development platform due to Twitter consistently removing features, making changes without warning developers, and effectively putting developers out of business with just a single change of policy. I advised other developers to be careful building a business model around Twitter, adding that it was a risky move, much more risky than many of the other platforms out there. It would seem I should have taken my own advice.

It was this time I started SocialToo, a service that originally we built around the auto-follow concept. I named it such because I did not want it to work solely on the Twitter platform. It was clear Twitter was on an unstable architecture, and their relationship with developers was also quite shaky. For this reason, I added in features like Facebook profile redirects at the time (a simple “yourusername.socialtoo.com” which redirects to your Facebook profile). But Twitter, at the time, was the easiest solution to build around, and made the most sense for where we had started so I figured we had to make what we did with it perfect. Here we are, one year later, and I’m still trying to make it work perfect, but not because our code sucks – it’s because Twitter keeps changing their system, and the rules that go with it!

Today Twitter pulled the rug out from under its developers once more by, with absolutely no notice, announcing that (paraphrased, in my words) since their way was the right way, they were discouraging auto-following, and would only allow a user to follow 1,000 people per day. What Twitter neglected was that, while not many, myself and others were building business plans around the users that would need this. A little notice would have been helpful, but is very consistent with the way developers have been treated over the past year or more by Twitter. Yes, I’m a big boy and we’ll survive, but that’s besides the point. You can read more about what developers are experiencing over on LouisGray. Put lightly, I’m not happy.

Twitter Needs a Firm Terms of Service

I know I’m not only one to say this when I say that I don’t have a clue what to expect from Twitter any more. Any developer out there is prone to this type of treatment, and I can pretty much guarantee it will affect every Twitter developer out there at some point until something is done about it. The reason for this is that Twitter really has no firm Terms of Service around its platform. I am not required to agree to any way of using their platform when I write software for them.

Some might see this as a good thing, but what they are neglecting to see is that a Terms of Service gives developers a vision of what to expect, something we don’t have now. This needs to change, and soon – we as developers need to know what we can and can’t do on the platform. Can we write apps that auto-follow? Can we write apps that auto-DM? What about mass-DM? Can I store data and what data can I store on my servers and for how long? What is the definition of spam? There are lots of rules for Twitter users that we agree to, but nothing a developer must agree to when writing apps. This is why you’re seeing so many apps out there gaming the system, causing these ridiculous rules to have to be made, when it can realistically all be settled before-hand with a simple agreement all developers must agree to before developing apps for Twitter.

If I knew what I could or couldn’t do on Twitter I could avoid it in the first place. Unfortunately Twitter hasn’t defined that and it’s pretty darn confusing, not to mention extremely risky, to write apps for the Twitter platform right now. With Facebook, on the other hand, I’m required to agree to a very specific agreement, and they’re very clear when they’re going to change any of the terms, giving developers plenty of warning. It’s well written out and well defined. It’s a platform with little risk and high reward for businesses because they give developers time to work with any changes they make to it.

We need notice, Twitter!

These “day of” announcements are very immature and something a 15 million user company with millions to billions in the bank shouldn’t be doing. They were doing this type of stuff a full year ago, and even today they haven’t changed their ways, even though they said they would. Twitter needs to start notifying developers of these changes or a lot more are going to be put out of business at the drop of a hat.

Every day on the developers mailing list I’m seeing other things like this happening – OAuth technology being removed without notice (I recognize it’s beta, but we still need to know!), no notice to developers on what’s happening when site slowness happens, when things are fixed on the platform, and when they’re broken, and more. As a developer with 12-15 years of experience in these things, the entire Twitter platform is a joke! You just don’t do these types of things in the real world of software development! I worked at places I would have gotten fired for this type of activity!

Developers will continue to leave if this doesn’t change

I have to admit, I’m re-evaluating my strategy to stop working on what I was doing in the Twitter environment, and move more to other platforms at the moment. When I do that, no, I won’t remove the existing Twitter technology, but I will admit it will be very easy for the users on my service to get the same value they’re currently getting on Twitter on other services, and as they experience similar treatment by Twitter they’ll be leaving as well (as I’m already seeing). I know I’m not the only developer in this boat right now – there are a lot of frustrated developers out there with almost no signs of change from Twitter. I know developers that now refuse to develop on the Twitter platform because of the way they were treated, and that will continue to happen.

I have to admit I had to send out e-mails to 20 or 50 or so of Twitter’s very top users today telling them that Twitter wasn’t allowing them to auto-follow. Those are tough e-mails to write, especially considering the influence Twitter has allowed these individuals to have and the audiences these people are capable of engaging. I’d like to make Twitter look good for these people, but Twitter isn’t making it very easy.

Twitter, it’s time to get your act together. Hire some more smart people, get people in management that know how to make these decisions right, and make us believe, not by words alone, but by actual actions, that you’re going to do something about it. If you don’t, as I’ve said before, when the developers leave, so will your users.

Come follow me over on FriendFeed over at http://beta.friendfeed.com/jessestay or over on Facebook at http://jessestay.socialtoo.com.

5 Features Developers Will Like in the New Facebook Design

Posted on September 16, 2008 by jessestay

I recently covered 5 general features most people may like in the new Facebook redesign being rolled out to all last week and this week. One of the biggest complaints of the new design is that it is bad for developers, reduces traffic to apps, and discourages users from using apps they have installed. While this is true for apps that haven’t adapted, there are still some very good features introduced by the new design, that, in my opinion, bring even more integration points to developers, and allow for more creativity to developers while still maintaining the user experience. I’d like to cover 5 of my favorites.

1. Your Application Now Gets an Entire Tab on the User’s profile

While profile boxes still remain, developers now have an additional option to create an entire tab devoted to your app on a user’s profile page. While you can’t advertise on this tab or monetize it in any way, the user profile page is the most traffic’d page on Facebook, and if you can grab a user’s attention by offering a little more information about your application and about the user themselves, other users are much more likely to engage and use the parts of your application you can monetize. More space to do this is a good thing, and the tab appearing on a user’s profile makes it appear as though your app is actually a part of their profile page. Consider this one giant advertisement for your application.

2. You can now allow users to share additional information about themselves via your application

Some of the most successful applications on Facebook are those that allow users to express themselves in certain ways. Applications that can allow a user to share more about themselves tend to be more engaging, and have a much more likely chance of a user sharing that application with their friends. Let’s face it – the days of an app spreading itself due to the new nature of the Facebook platform are long gone. Now, it is the developer’s responsibility to employ traditional marketing techniques to get the users to share these applications with their friends themselves.

The “info” tab is one way they can do this. Your application can give users an option to click on a simple button that allows them to add additional information to their “info” tab, provided by your application. Again, the profile is the most traffic’d place on Facebook, and this is an excellent way to get your app in front of a lot more people.

3. The new design is more organized, therefore giving your app more potential to be “one of few”

With the new design, most applications get organized into a “Boxes” tab on the user’s profile. This requires an additional click to learn about a user’s applications that they use. However, for applications that enable it, a user can optionally add any of those application boxes to their “wall” tab, putting it among just a few of their favorite applications for their friends to see and use.

If you can create an application that users will like, use, and want to share with their friends, the chances of your app appearing among those few are greater. I don’t have any numbers, but I really think there are only a few applications utilizing this feature right now, upping your chances even further of being one of those users like to feature on their “wall” tab. To me, this actually makes the potential for your app being successful even greater.

4. There are now 3 types of News/Mini Feed items your application can post

While your application can’t necessarily force news feed items to Facebook without the user’s explicate permission any more, you can utilize “feed forms” to allow the user to share one line posts to their mini feed, small summaries to their mini feed, or an entire story to their mini feed. If you can make your app useful enough to encourage the users to share the larger feeds (which were not available before), your app has a far greater chance of getting in the face of your users’ friends, encouraging even further virality. Not only that, but good marketing shows that when a user actually wants to share something, their friends are more likely to listen and participate. Giving your users choice is a very good thing, and will result in a much more devoted audience in the future.

5. With the new design, you can now deploy FBML, right in an iFrame

A new feature established in Facebook Connect enables any website to utilize the Facebook Javascript Client Library to allow a developer with an app set up to parse and load FBML on any page on the web. This means that you can now load FBML right in your iFrame’d pages.

Why use FBML? FBML will guarantee, as Facebook changes their look and feel, that you don’t have to change your look and feel with them. It all happens automatically. Before this, Facebook required all FBML to be loaded and parsed on their servers. Now you can load it directly on your own servers, which means greater flexibility with Javascript, more options when integrating with other platforms like OpenSocial, and less coding overall since Facebook takes care of the details for you. Best of all, you can implement this on any website, even outside of Facebook, and with Facebook Connect, you can even authenticate and retrieve data from Facebook for users, right on your own website! You can learn more about FBML via my book, FBML Essentials (shameless plug).

While I understand the frustration of developers with the new design, and especially the fact that applications aren’t quite as in-your-face as they used to and can’t do things as easily on behalf of users, overall I think this is a good thing for the overall Facebook experience. Now Facebook has provided more integration points for developers than ever before, while at the same time making the experience better for users, making users want to continue coming back to the network. Users coming back is always a good thing for your application on Facebook.

What are your favorite features, as a developer, within the new design?

Identi.ca Will Succeed Because Its Technology is Viral

Posted on August 14, 2008 by jessestay

Yesterday I guest-posted on LouisGray.com about how the technology behind Identi.ca, Laconi.ca, could pose as the launching platform to brand many smaller microblogging services. Today I’d like to share one more power of the service – its working API. Identi.ca/Laconi.ca seem to have introduced a new ideology to Web 2.0 with this code, viral software.

Now, when I mention “viral software”, I’m not necessarily mentioning software that can make things viral. I’m instead meaning software in which the underlying code itself is viral. This could change the face of the way developers write code in the future, and open source is only part of it.

Today I noticed (through Steve Gillmor on identi.ca) another new interesting thing that I knew was coming – Brad Williams (@williamsba) wrote a bridge that essentially allows you to post on identi.ca and have it automatically post to Twitter, prepended by “identi.ca:”. Interestingly enough, “Hippy Steve” (@exador23) pointed out now one of the top trends on Twitter as of today, according to http://search.twitter.com is “identi”. Now, many of the posts you see on Twitter are going to become posts prepended by “identi.ca:”, and many more are going to feel pressured to join identi.ca where they are seeing all their other friends post from. I guess you could consider it competitive micro-advertising, created and distributed on purpose by the users themselves (as Charlene and Josh would put it, we’re seeing a “Groundswell“).

It should be noted that you can remove the “Identi.ca:” from being prepended, but as long as you’re on identi.ca and want those on Twitter to know you’re posting from there and not Twitter, why remove it? You are posting from the competing team, after all. Would anyone want to pretend they’re not posting from Twitter? I’d like to know where my friends are posting from.

Now, onto the viral part. Why did Brad Williams implement this bridge? I’m sure there are preferential issues of trying to get his network onto identi.ca, but the fact of the matter is, from a development standpoint these applications like Brad William’s bridge are simply easier to write for Identi.ca. The lack of limits and plan to keep off those limits on Identi.ca are just one more thing that make the software behind Identi.ca viral. Developers want to develop for Identi.ca. With an API that also supports Twitter (I mean literally, it is simply a change in the hostname for your Twitter code), developing for Identi.ca is just too easy! Again, developers jumping ship could very well mean the demise for Twitter.

I can only hope that developers of the future learn from this experience – in a social era such as today, even your software has to remain viral and easily shareable and distributable. Laconi.ca is the prime example of this – completely open source, based on open protocols, and your software should be able to talk to other instances of itself in some way, preferably using standard protocols. In addition to that, a completely open API is a must – the minute you start closing your API you begin to lose your code’s virality. Brad William’s bridge is only the start of apps that make the transition to Identi.ca much easier. I imagine you’ll see many more of these things in the coming days and weeks.

Looking to learn more on how to make the jump to identi.ca? Check out my friend, Marina Martin‘s site, ohidentica.com for some great howtos and tips all in one place. You can find me at http://identi.ca/jessestay.

Well Done Guy! Chris DeVore is a Cheapskate

Posted on March 21, 2008 by jessestay

I just caught this article from Mashable and I just had to pipe in. In the article, Mashable’s Kristen Nicole claims Guy Kawasaki paid too much for the development of AllTop, at $10,000. They compare it to Askablogr.com, claiming Chris DeVore only paid $7500 for the development of Askablogr, with its rich feature-set.

I was blown away by this! Not that Guy Kawasaki paid $10,000, but that Chris DeVore only paid $7500 for Askablogr. Now, I don’t know Chris, so take this with a grain of salt, but some call it a deal. I say he’s a cheapskate! For something that will be your primary revenue source and your main line of business, $10,000 for something like Alltop.com is a steal! The fact that Chris DeVore only paid $7500 for his development means he’s either hiring offshore, doing the development himself (in which those costs are way under-inflated), or he’s very much underpaying a bunch of gullible developers that probably don’t believe much in the product they’re working on.

As a business owner, when supporting a technology-based business, it is of utmost importance that you put your developers and IT staff at first priority. They are your bottom-line, and should be the superstars of your business. You have to keep in mind that for top notch developers and technology, you’re competing with the likes of Google, Facebook, Yahoo, and others to get the best talent. By not paying your developers, you will either a) lose your developers very quickly, b) have a revolution at one time in your future and your developers will all back out on you in rapid succession, or c) not get the best work and skills you could be getting, and you’ll definitely run into scalability issues as your site grows in the future.

I recently finished the book, “My Startup Life“, by Ben Casnochas. I bet Guy’s read it and Chris hasn’t. In it, Casnochas talks about the lessons he learned by not paying his lead developer well. He quickly had threats of the staff to leave, and they quickly ran into scalability issues due to the unexperienced offshores they were hiring overseas. In building a technology-based business it is of utmost importance that you pay and treat your IT staff well or it will come back to bite you in the future.

So, Kristen, I say Guy is the smart one in this case. I am willing to bet his site scales better, his developers are happier, and more likely to work with him in the future. Guy’s likely to get millions for Alltop.com in the future, should it succeed, so $10,000 is a very small price to pay to get good developers on staff.

UPDATE: See Chris’s comment here: http://staynalive.com/articles/2008/03/21/well-done-guy-chris-devore-is-a-cheapskate/#comment-2126. I probably inappropriately labeled Chris a cheapskate while trying to defend Guy. It turns out (and I should point out, unless I read it wrong, that the Mashable article did not make this very clear either) that Chris’s project was a project built simply to point out how cheap something could be developed. In that case it would make him an intentional cheapskate, not that there’s anything wrong with that. As I mentioned, I’m a cheapskate too – I just don’t see the reason to short projects in development costs when it is the core to the business. It is an interesting experiment regardless. Thanks for visiting Chris!