If you missed my post a few days ago detailing the pros and cons of four major social networking tools — AddThis, ShareThis, Add to Any, and iBegin Share — you owe it to yourself to quickly review it and then get to the comments.
First Pat Diven, Founder of Add to Any, responded with some great counter-arguments to my claims. We went back and forth several times comparing Add to Any and iBegin Share, and ended up covering a ton of ground on the best practices for these tools.
Then, David Cramer and Ahmed Farooq, representing iBegin Share, dropped by to offer their two cents, and to let us know that they’ve pushed a new version of both the source version and WordPress plugin.
Here’s hoping Pat chimes back in again, he obviously knows his tech and offered interesting food for thought for any web developer. Plus he had the guts to get down here in the trenches and talk nitty-gritty on his product. Maybe the better question is where’s Tim Schigel, founder of ShareThis, and Dom Vonarburg, Founder of AddThis?
yeah – I use sharethis but recently found another one which i like called crowdsend – really great design for websites in my humble opinion
Is your opinion so humble because you had a hand in it? The Terms of Use indicate that CrowdSend is located in Victoria, Australia and (wouldn’t ya know it?) your IP places you in the exact same region. If you are involved please let me know, as I’d love to have another voice of experience on the matter.
If not or until then, I’m removing your link. If people want to visit they can type it in, as I’m not going to reward abject advertising pushers.
Now onto something substantial. The tool definitely looks slick, but it has the same exact benefits and problems as the other sharing tools. From the CrowdSend FAQ…
Fail.
Hi!
haha – same ip, not sure means same person. probably friend of creators.
tool looks great that frank posts. but as you say – capacity is always the issue. still, doesnt make sense to add capacity unless its warranted.
i always look at it like – if i was them, why spend dollars setting up a bunch of servers if its not warranted. no idea of the b-model for this venture, but seems to me that this is the right approach ?
high capacity sites, high capacity treatment individually ?
Hey Frank,
Apologies, one of the team got a little excited in posting the link and then requested I respond to this article
CrowdSend has been a small “side-project” for a few of the guys in our office. Evidently, we are no where near as large as the other services your previous story points too, as we are quite a new service. It seems that a lot of users of these services tend to integrate more than one content sharing widget, and we encourage anyone to try ours and see if they like it.
As you point out from our quote, we are asking high volume sites to contact us. I would say, kindly
, that its not a ‘fail’ – it’s to stop significant sites slowing down our entire network performance. We would rather be upfront with users than allow say – CNN – to join up for example and crush the site. Primarily, because its easier to deliver the widget over a CDN and segregate the high volume network effect from other sites using our service. I would think this is more prudent delivery practice than a ‘fail’ 
Total network volume can really easily add up, so in the “widget” game – it’s all about size. You take at 50KB widget and deliver to 250K of pageviews and you are hitting 12.5GB of traffic. Optimize it to around 20KB – and your hitting 5GB. Evidently, big sites pump out 250K of pageviews in a few minutes – so you can see the volume of traffic being pushed out for these single sites alone. Compound that across a bunch of sites and 100 – 200GB a day is a pretty easy target to achieve.
Of course, in the collective defense of CrowdSend and some of the other services – we don’t have multi-million dollar backing. So I think it’s fair to ask high volume sites to contact us and let us know if they want to use our services. We can work with them to optimize the service and ensure smooth delivery – case-by-case basis is easier in my opinion.
Either way – feel free to contact me or anyone in the team via the site at any time.
Thanks again,
Tim
Awesome stuff, Tim, thanks so much for following up. I think we can both appreciate excited team members. Always better that than the alternative.
@Original CrowdSend poster: Pitch comments are welcome, but they should contribute to the conversation. When you’re a plant, the real interaction hides your roots and fronds from view.
I stand by my comment — it is ‘fail’ in the same sense that I previously described comparing other sharing tools. If your service goes down, the user’s browser times out on my site. Not good for my users or my site image. However, the context of my comment did lean little to the harsh side, so I apologize for that.
Your assistance offer is definitely a step in the right direction, but I offer the same suggestion to you that I did to Pat Diven of Add to Any: the ability to run the widget in a completely local fashion is the major differentiator. It’s almost single-handedly the reason that I chose iBegin Share over all the other tools.
It also makes all your traffic and monetary arguments non-issues. Instead of trying to manage all that traffic, just get rid of it. What if the tool ran locally and “phoned-home” usage stats every X requests? It could also seek updates in the same time period. You get your traffic stats, and you don’t have to worry about serving up all those requests.
As open source software, iBegin Share has no financial drive to monetize their usage traffic. But they don’t have any staff to keep it constantly up-to-date or directly support users. Profit-based tools can compete on those fronts. I’m certain that whoever gets away from per-page script requests first will quickly surpass the competition.
“…but as you say – capacity is always the issue. still, doesnt make sense to add capacity unless its warranted.”
That’s why I keep suggesting that all these companies move away from per-page requests, Wuan. All the issues of bandwidth, capacity, request frequency, etc. simply go away. When faced with a huge issue, you should always consider how you might operate if you ignored it completely.
Frank – thanks again for commenting
I completely agree with what your saying & I have gotten the whole team to read these posts. We are working on optimising our widget and it’s great feedback like this that we can take on board and improve.
Using principles outlined in http://developer.yahoo.com/performance/rules.html – also greatly helps the process. I would also recommend, if you haven’t already, checking out http://developer.yahoo.com/yslow/ – we are working with this at the moment to tweak our services and improve as well when we have some spare time.
Thanks again for the feedback – we will definitely take it on board and improve. Look to see changes over the next week or so
Cheers,
T.
Whoops you got my name wrong
@Tim: I’m very familiar with Yahoo’s developer network, specifically the YSlow tool and their best practices rules. I outlined them along with all my other must-have Firefox addons — for devs and non-devs alike — in an earlier post:
http://frankkoehl.com/2008/09/my-firefox-extension-collection
I would suggest you take a look at Jiffy, a great compliment to YSlow.
I’ll be sure to keep an eye on your progress. Please check in as things progress.
@David: My bad. Probably that Seinfeld episode I was watching.
Correction made.
Hey guys, my name is Justin Thorp and I’m the Community Manager for AddThis. My apologies for not jumping into the convo sooner. I had seen the post but got busy and it slipped through the cracks. Thanks to Frank for dropping me the tweet.
First, thanks to all of you for your hard work in this space. Together, we’re making this industry better and helping everyone’s content to get shared more easily.
David and Ahmed kudos for your work on iBegin Share. It’s a very cool project. Was playing with it just now.
I totally understand the concern about performance. For us, this is something that we think and talk constantly about. For us, performance is a feature. That being said, we’ve worked hard to keep our total code size down to about 17k, which isn’t bad considering how much functionality we have in there. (We support about 40 different destinations, 18 languages, and adding many many more to each. We just added Slovenian.)
I also understand the desire to keep things locally hosted so that you can absolutely ensure performance. This is why we allow users to host the primary javascript file locally on your computer. More info in our FAQ – http://addthis.com/help/troubleshooting/faq/
All in all we feel like we’ve been able to be pretty successful with this. The AddThis button is loaded about 20 billion times per month.
One thing that reach gives us is we can test ways that we can improve our service and get our users the most shares possible. For example, we tested buttons that had menus come on click vs on hover. We found that on hover increases the share rate about 4x. I could tell you more anecdotes but let’s just say that we’ve been able to learn what works and what doesn’t and optimize around that so that you get the most shares possible.
In the end, that’s what it’s all about isn’t it? It’s about using the tool which is going to get your content shared/viewed the most.
If any of you at any time, have thoughts, feedback, or questions about AddThis, don’t hesitate to drop me an e-mail – justin@addthis.com. I’d love to chat.
Thanks again to Frank for starting this conversation.
Welcome to the discussion, Justin. So glad we got AddThis represented in here as well. These neutral ground discussions are always great for sharing ideas and experiences, so the pleasure is all mine in hosting.
For us, performance is a feature.
That’s exactly what I’m talking about. Your services all have bandwidth issues, but it has to go beyond merely tackling a problem to being so smooth as to be unnoticed.
I also understand the desire to keep things locally hosted so that you can absolutely ensure performance. This is why we allow users to host the primary javascript file locally on your computer.
I read the FAQ you linked, and that’s great. Now, where’s the broadcast of this information on the homepage? How about an option on the /web-button-select page? We both know users go to FAQ when they’re lost. Hell, I wrote a whole article on the matter and I didn’t even bother to check you FAQ to see if local hosting was offered! It’s a great feature, you’re shortchanging yourself (and probably sacrificing users) for not putting it out there.
One thing that reach gives us is we can test ways that we can improve our service and get our users the most shares possible. For example, we tested buttons that had menus come on click vs on hover. We found that on hover increases the share rate about 4x.
I would have guessed that rollover would lead to more sharing vs. click, but I never would have guessed that the difference was so dramatic. I may have to hack up my iBegin install to do that.
I could tell you more anecdotes but let’s just say that we’ve been able to learn what works and what doesn’t and optimize around that so that you get the most shares possible.
These kinds of usability insights extend far beyond the tools you’re building, so please share whatever information isn’t under corporate gag. Same goes for the rest of you!
“Your services all have bandwidth issues, but it has to go beyond merely tackling a problem to being so smooth as to be unnoticed.”
So… can we get you signed up for our code caching program? I’d love to get your prospective on it. I’d be curious if helps to assuage your concerns about performance.
To get signed up, I’d just need your username and the domain of the site that you’d be testing the info on and I’ll pass the instructions on to you. Feel free to e-mail it to me – justin@addthis.com
I would have guessed that rollover would lead to more sharing vs. click, but I never would have guessed that the difference was so dramatic.
We’ve actually done quite a bit to tweak the menu in ways that move the needle for our users (aka get your more shares & views). This is all from insights that we have due to our extensive reach by both large and long tail publishers. We feel that this understanding about what works, our ability to constantly iterate, and deliver continuously better results for our users is a competitive advantage.
Another thought… it would be interesting if you did some testing on your own Web site and then published the methodology and results on your own blog for the world to see. Would be an interesting spring board for discussion…
Thanks again for all of this!
I’m willing to give it a shot. Email incoming.