Why I removed most of the social icons off Travelfish.org

Prevailing wisdom holds that you should make it as easy as possible for people to share your content through the various social networks and there’s a gazillion plug-ins and services built around helping site owners to do this.

Save a few stragglers, I’ve just finished removing all the social icons off Travelfish save one — Facebook.

Google+: DOA.
Twitter: Annoying extra tags that get added in – Mashable and NYT I’m talking to you!
Delicious: See Yahoo!
Flickr: See Yahoo soon.
StumbleUpon: Junk traffic. (to be fair we didn’t have SU, I just wanted to take the opportunity to say it is junk traffic).
Instapaper: Nearly all regular users (like me) use a toolbar button or widget on the phone. Very very few websites have an Instapaper button as we did.

In slightly more detail
Google+ I removed perhaps a month ago, though not for the same reasons as detailed in this amusing post — I just think it is way too complicated. I’ve removed clickable icons for Twitter, Delicious, Flickr and Instapaper, and have also removed the Facebook icon we had and instead have placed the Facebook Like/Send button at the top and bottom of much of the content. Instapaper is removed, but the clipping is still coded in, so you still get the best bits – you just need to use your toolbar widget.

This was partly informed by my personal use (as with many others, I never use buttons as I perfer to cut and paste the URL and add my own titles and blurbs.)

But it was also as a result of observations I made during a recent trip to Thailand where, over a few weeks, the ONLY social website I saw open on a traveller’s laptop was Facebook.

It was also a result of conversations with my family and some friends — most of whom, while not technophobes, are most certainly not rabid users of technology. Despite this, they all have Facebook accounts and use it semi- to regularly. None have Twitter, Delicious nor Flickr accounts.

Travelfish.org is a travel planning site – we are not a technology or social networking site. Our readership is wide and varied and for sure we have some members who are very active on social media, especially Twitter, but most members are either not into it, or have chosen not to share that side of themselves.

Why keep Facebook?
Because just about everyone has an account.
Because despite the regular moaning (including from me) it is pretty easy to master – just don’t start farming.
Because it is now our #2 source of traffic (after Google) having recently surpassed Yahoo!
Because the seamless way it allows people to share content is miles ahead of the other networks.
Because it loads asynchronously by default.

What about the other networks?
I’m a heavy Twitter user and it is absolutely my preferred network. So just use it as I do:

Cut and paste the URL into whichever client you use.
Shorten it.
Think about a suitable title.
Compose some snippet to sum up your thoughts to go with it.
Hit send.

Your followers will love you for it.

To those who may say, but now it’s too difficult to share your content, I reply, well, if the above is too taxing, perhaps the content really isn’t worth you making the effort to share it.

If you do want to share it, you still can — and we’ll love you for it!

Why Triberr is crap

Just to be upfront, I’m happy to say I’ve never used Triberr — I’ve only had the misfortune to have been on the receiving end of it. From the first moment I heard of it, the spam implications were obvious and today I continue to believe it undermines the social foundations of Twitter. My view is simple: if someone tweets something and I read it and like it or think it is worth retweeting, then I retweet it. That’s how and why Twitter works.

Now that I’ve got any questions of bias out of the way…

For those unfamiliar with it, Triberr describes itself as a “reach multiplier”, declaring that it “solves the No 1 problem 99% of bloggers have. How do I get more eyeballs on my content?”

“Triberr is crap” – Gary Arndt.

Sounds good right? In broad strokes, what it does is allow Twitter users to create or join “tribes” of like-minded people. The tribe then becomes a repository of tweets from the members and these tweets are then sent out on an automatic or manual basis under each member’s Twitter username.

Triberr appears to consider this to be a form of tweet curation.

Tha attraction is obvious. In the traditional model, you’re relatively new to Twitter and have 50 followers. If you post a link in Twitter, in theory each of those 50 people may see it and perhaps retweet it. That road be the slow road.

“I’ve always been really well supported by the Twitter community, and specifically other travel bloggers who have retweeted my stuff — sometimes nearly every post I wrote — for years now. I wanted to repay the favor and perhaps in my small way, highlight the travel writing that I felt was the strongest.

At first, it seemed to work great within our niche. But as more and more people began using Triberr, and maybe retweeting people they didn’t really feel strongly about, people within the community got sick of seeing the same content retweeted, without merit, dozens of times.

If I was the only one using it, then it would probably still be great with our niche. But instead it became like this wall of content with mixed levels of quality and I think people have largely begun to ignore it or even to block it completely in Tweetdeck.

Finally I had to turn it off. It’s disappointing because I felt it had potential, but as it grew, there wasn’t any attempts to address the issues of over tweeting, quality and volume.” – Christine Gilbert

With Triberr, the same person gets invited into a tribe that has someone with a far larger following in it — say 50,000 or 100,000 followers. Every time the new member posts a link, (assuming the larger player is on automatic) that link goes out to 50,000 or 100,000 followers. This be the highway baby!

There’s no denying that as an amplification tool, Triber works. At least initially, your tweets will reach far, far more people — many of whom will have no idea who you are.

And that is the problem.

“At first triberr seemed like a fantastic idea. Automatically tweeting the posts of other bloggers who I enjoy reading, without me doing a thing!

After a few days I saw the truth – my feed was filled with impersonal tweets I had no control over. I tried to swap to manual in Triberr so that I could read the articles first and add personal comments. It didn’t work, the tweets continued to go out automatically. I removed myself from the group but tweets continued to flow. Deleting my triberr account had no effect. Another group member accidentally deleted the whole triberr group and even that didn’t stop my tweets. Someone else recreated the group and added me back in. I realised then Triberr was alive and possibly possessed.

Eventually I blocked triberr from within Twitter, stopping my tweets but not the other group members from tweeting my posts. Now I’m just left with feelings of guilt that they’re still tweeting my posts and the realisation that there’s no escape … ever! ” – Tracy Burns

The Triberr Experience

The Triberr Experience

The Twitter stream I follow day-in day-out is my Twitter stream. I select who I want to follow and who I don’t want to follow. Of course people who I follow may RT others into my stream — that’s how it works — and I assume that, for the most part, these RTs are done on a manual rather than industrial basis and the retweeter has either read or at least skimmed the post they’re retweeting.

When Triberr hit the travel blogging scene I suddenly started seeing tweets in my stream from people that I was not especially interested in, and in some cases that I had blocked. How was that happening? How was my stream being polluted?


What happened was people who I did follow had joined Triberr and that was the source of this sudden wave of oft-duplicated tweets I had no interest in.

While there’s no doubt that the people whose tweets I was suddenly seeing were not specifically targetting me (they weren’t actually targetted to anyone), the conduits, or people I did follow and whom were also part of Triberr, were effectively allowing them to bypass my own efforts of “stream curation”. I was being spammed.

“Triberr is a successful tool if you are looking at Twitter as a means of projecting your voice. It’s a megaphone for your own posts, and an agreement to use that megaphone for the others in your tribe. But the utility of Twitter – and why I love it as much as I do – is its ability to be used as an RSS feed of news and information and a way to stay up to date in the world.

Triberr directly detracts from this curatory usefulness as it auto-RTs posts that people haven’t even had a chance to read. While some might manually RT using Triberr (to me this is tantamount to reading and scheduling the post – why do you need Triberr then?), most end up automatically retweeting the same fixed group of sites. This completely undermines the honed voice that Twitter lets you have, to make your stream into an extension of your brand.

And as a result, I don’t usually click through links sent “via triberr” as I’d rather know that there’s a personal endorsement behind what someone posts to their feed.” – Jodi Ettenberg

Triber is a tool to get your tweets, en masse, in front of people who have not asked for them. Think of that description in terms of email. Rhymes with ham.

Initially I just blocked Triberr on Tweetdeck, but then as Twitter for iPhone has no block function, the only way to take my stream back was to unfollow Triberr users.

“It’s a festering turd stuck on the shoes of social media.” – Dave Dean

It didn’t matter who you were — if you used Triberr, you were off my list. Some were friends, others were people whose travels I had followed closely and had linked to extensively from Travelfish.org — it didn’t matter who you were.

I like my Twitter stream far more now.

PS. You’ll note the above opinions from others on Triberr are generally quite negative. Unfortunately as I’ve unfollowed everyone who still uses it, positive opinions didn’t come knocking.

There are a few other good posts I will direct you to though. Stubbornly Clinging to the Organic Web by Pam Mandel is a great post and one of the first I read on this topic. Far more recent, Twitter is Dying — and it’s all your Fault, by Neicole Crepeau, is solid and, as with Pam’s post, the comments are well worth reading — in both cases they include comments from the creators of Triberr. Then just today, new travel blogging site Travelllll.com asks Can we blame Triberr if we’re tweeting like robots? Seems it’s a bit of a topic for now.

If you’d like to learn more about how to spam your friends on Twitter, the Triberr site is here.

Why deal websites using dodgy discounts are BS

Tonight I received an email from the Australian arm of Livingsocial — a deals website. It offered a seemingly amazing deal.

If it sounds too good to be true it is probably BS

If it sounds too good to be true it is probably BS

Sounds good. $1,556 reduced to $425 for a deluxe room at the Samui Buri Beach Resort near Mae Nam Beach on Ko Samui.

So then I went to the Agoda site to check for a comprable rate. They’re offering Samui Buri for $109.32 a night (before tax).

That's a pretty good rate too!

That's a pretty good rate too!

The $23.20 tacked on in taxes on the booking screen brings it to a total of $132.52 per night — or $397.56. So about $30 cheaper than this Livingsocial deal.

Gotta pay the taxman.

Gotta pay the taxman.

Though to be fair, the Livingsocial deal includes airport transfers and a couple of massages, so you’re going to save a few dollars with Livingsocial I guess.

But that’s not really my point. What I’m curious about is the $1,556 — the purported full value of this glorious deal.

Agoda listed the non-discounted rate as $234 per night, Add 21.5% for tax and you get around $280 per night — or $840 for three nights — just over half the supposed Livingsocial value.

Hmm, perhaps Agoda has some special discounted rackrate or something. So I went to the official website for the hotel.

Cheaper as well!

Cheaper as well!

They list the room as costing 4,200 baht for one night and 12,600 baht for three nights. That equates roughly to A$140 and $416 respectively.

So in summary, here are the rates:

Original rate: $1,556
Discounted rate: $425

Original rate: $840
Discounted rate: $398

Rate: $416

So perhaps Livingsocial is working off one of those wishful thinking ratecards that has absurd rates that only the United Nations pays, but it’s pretty dodgy to be offering a rate that is discounted off a rate that nobody with a brain would actually pay.

One note, the photo on the Livingsocial page displays a pool access deluxe room, which costs roughly 20% more, but given the Livingsocial copy specifically states “Deluxe room” rather than “Deluxe pool access room” I went with the text over the glossy pic. The math is similarly dodgy.

One more note, the Livingsocial deal does include airport transfers and massages — perhaps it is a very pretty car and an especially special massage.

So next time you get an offer from Livingsocial — head to Agoda — lowest rate guaranteed!

If someone from Livingsocial happens to stumble across this post, I’d really appreciate it if you could add in the comments where you got the $1,556 from. Thanks!

How high do you bounce?

Bounce rate is defined by Google as “the percentage of single-page visits or visits in which the person left your site from the entrance (landing) page.”

What this means is it measures the number of visitors who arrived at a page and went no further into your site.

A bounce need not mean something bad. The visitor may have landed on a page that completely answers their question, may have clicked on an advertisment or perhaps just got up to go make a cup of coffee and forgot to come back.

It can though also reflect a poor reader experience — people arriving at your site and finding the content just doesn’t answer their question, or perhaps your website doesn’t look right in their phone or browser, or stories are overly paginated, or the colour scheme is awful or any number of other reasons that would generally connotate a “thumbs down” experience.

Some site styles, such as blogs, often have a higher bounce rate due in part to a combination of reader behaviour and poor site architecture, with others though, for example affiliate landing pages, the whole purpose may be to send the reader elsewhere.

So keep that in mind.

For a general content site like Travelfish.org, bounce rate matters. It matters because reading a single page on Travelfish is not going to answer every question you have about travel in Southeast Asia! There is always another question that can be answered or further information that can be imparted.

With that in mind I’m going to write a bit about three areas where we see a bounce rate that is significantly higher than the overall site bounce. I’m slowly making changes to address some of the worst offenders!

But first, how to measure it. We use Google Analytics for most of our statistics needs and, with a bit of refinement you can get some useful bounce data out of it.

You can also use this data to pick your battles. There is less value in spending 12 hours rewriting a page that gets 4 visitors a day and has a bounce of 80% than a page that gets 4,000 visitors a day and has the same bounce rate.

Note also that not all bounces are equal. A bounce with an average time on site of five seconds suggests “Recoil, evacuate!!!” while a bounce with an average time on site of five minutes suggests “Thanks, that really answered my question.”

So pump up GA and click on the “Pages” tab under “Content”. This will give you a chart showing you your ten most popular pages with time on site, bounce, exit etc.

Then click on the advanced filter, make the average time on page less than say 90 seconds and the bounce rate over say 60%. (Obviously select variables that fit with your readership).

This will give you a list of pages that people spend an average of under 90 seconds on, with over 60% of them leaving your site. Order the result by pageviews, increase the number of results to 50 and you’ve got your homework for the week!

Each of the pages may be bouncing for a different reason, but in Travelfish’s case, three of the main reasons (in no particular order) are:

1) Question is answered
2) Unanswered forum questions
3) Blog pages

Question is answered
Just one example area for this, we have hundreds of FAQ questions on the site. Stuff like “Are the ferries in Thailand safe?” or “Can I use ATMS in Thailand”, or “Can I use drugs in Cambodia?”

Each of these can be answered with about three words. (in the above cases, Mostly. Yes. Yes, but don’t.) What this means is if the person Googles “Are the ferries in Thailand safe?” and they get sent to our page, then they’re going to get the answer in about 6 seconds, and unless we do something about it, they’ll leave.

So what can you do?

We’re in the process of expanding pages like this to try to second guess other questions people may have. Again staying with the above, we could suggest “Extra reading” along the lines of:
Popular Thai ferry routes
Photos of Thai ferries
What ATM fees are there in Thailand?
What cards do ATMs accept?
Are drug overdoses common?
What penalties are there for drug use?

And so on.

Obviously this can be a bit hit and miss and not all topics can easily have more topics associated with them, but you’d be surprised just how many can.

Assumming the extra answers you’re providing are accurate, useful and value adding, then you should start to see bounce rate reducing.

Unanswered forum questions
We’ve got around 15,000 questions and 70,000 answers on the Travelfish forum. And while most questions now eventually pick up an answer or three, some don’t, and this was especially the case with the older questions, when we didn’t have quite as many active readers as we do now.

The “problem” is that many of these unanswered questions have been well indexed by Google, and visitors continue to Google “How do I get from A to B on a Tuesday by horsecart”, and get sent to us, where there is a question that exactly mimics the search query, but unfortunately has not been answered.

This is a poor reader experience. I find it annoying when I Google something only to be sent to a page that asks the same question but has no answer — and I find it doubly annoying to be subjecting others to that same problem.

There are two obvious approaches to this:

a) Mark as NoIndex/NoFollow any forum thread that doesn’t have at least X number of answers. This means Google will not index the question until someone answers it.

b) Go back through and answer the unanswered questions.

I’ve slowly been following the second option. Adding a post at the bottom saying something along the lines of “This is an old thread but if you end up here, here are some links for further reference. If they don’t help. please ask the question again on the main forum” And then I lock the thread, meaning no more comments can be added.

With the first method, the bounce should drop off severly as you’ll stop getting any search traffic to these pages, with the second you’re trying to steer readers to other parts of the site. If we don’t see a significant drop in bounce we’ll switch to the first method, but for now, answering and locking seems to be helping.

Blog pages
Trying to drag blog readers onto other entries or further into the Travelfish site, has been somewhat of a struggle, but we’ve been lucky in that with ten nearly identical looking blogs layout wise, we were able to test different features and plug-ins to see what worked and what didn’t.

Currently we’re doing the following:

Interlinking blog posts with in-context links
We do this both within each blog but also across to the greater Travelfish site.

Related posts
We use YARRP and it is excellent. Easy to configure and doesn’t use images. We position it at the end of the story and in early testing, saw an 8-10% clickthrough rate.

We use search-meter with it positioned after the related posts and before the Facebook dialogue. Search Meter allows you to easily track what people are searching for which in turn can be very helpful for new story ideas and highlighting gaps in your coverage.

Popular posts
A simple Top 10 plug-in in the left column that displays, you guessed it, popular posts. If others liked them, perhaps the next reader will too!

The above are but a handful of means to approach bounce rate. The “correct” approach will depend on your style of site and what you’re trying to do with it.

Every reader counts and if it is raining outside and it’s tackling bounce rate or doing month-end accounts, I know which I’d rather be doing.

Got a suggestion? I’m all ears!

PS I know I said I was going to be writing about sprites, but I put my back out through the week and wasn’t up to figuring all that out. Will do soon though!

Speeding up Travelfish.org part 1

A common refrain regarding Travelfish has been that the site is slow. People using the site would complain, Google would tell be at every possible opportunity it was slow (apparently about 80% of the sites on the web were faster) so over the last couple of months, as time has allowed, I’ve been reading up on what’s involved and slowly making changes to the site.

This is a bit of a work in process, but I thought I’d blog it as others may have some useful suggestions … plus the power is out so I’ve got nothing else to do but run down the laptop battery.

Broadly speaking there are four main choke points:

A picture says a thousand words
And a picture is about a thousand times the size of a single word.

Getting close to your readers
Using a Content Delivery Network (CDN) to make sure that your files are being served from a data centre close to your readers.

Don’t ask too many questions
An average browser is configured to request no more than 8 files simultaneously.

Doing the loop the loop
Optimising your database code and following best practises in your scripting. Caching is your friend.

But what’s the point?
Well if someone is motivated enough to email me to complain about the site speed, then it just needs to be addressed. How many others just left.

Travelfish.org is in part an advertising-supported website. What this means is that in some cases the more pages people look at, the more they learn and the more we earn. For a content site like Travelfish, the mantra seems to be the faster the pages load, the more pages people will read. Makes sense really — do you look forward to returning to a restaurant with glacial service?

Since we added the destination blogs earlier this year, the overall site bounce rate has increased significantly. In part due to their design, but also reader behaviour, blogs tend to have higher bounce rates than a “normal” site. Again this is something I hoped to address through speeding up the blogs — the faster I can load a page, the more chance I have they’ll see something else of interest. I also made some changes specific to the blogs to assist readership, I’ll be covering that in the coming weeks.

So in summary, in speeding up the site we’re hoping to address an issue readers have complained about to help them get the most out of the site. While simultaneously improving our bottom line.

So what have I done so far?
I signed up with Amazon’s S3 and Cloudfront Content Delivery Network. This allows me to store files on their servers (which are considerably more powerful than my setup) and make use of their CDN.

This is a double whammy in that S3 is fast and Cloudfront, with data centres in the USA, the EU, Tokyo and Singapore means that my files are being served a good deal closer to you. (The actual Travelfish.org server is in Texas, USA.)

While I haven’t shifted all the files yet, I have moved a lot, including many of the images, all the Javascript and all the Stylesheets.

Making this change alone, improved load time on my main testing page (https://www.travelfish.org/country/thailand) from over 11 seconds to under 3 seconds.

Not bad.

S3 and Cloudfront take a bit of getting used to, but Labnol has a fabulous set of S3 tutorials that were of immense help. There’s also a S3 Firefox plugin that is very helpful. And, for WordPress users, Tan Tan Noodles has a near perfect WordPress plugin for S3 image uploads.

I am stuck on one thing though in this area. When I upload an image to S3 I can set an expiry date long in the future (this assists with caching) and when I request the image from S3, the header is correct. BUT when I request it from Cloudfront, no expiry date is set. I’ve been trying to find an answer to this problem to no avail — suggestions welcome 🙂

Update at end of the entry regarding the above point.

Don’t ask too many questions
If you look at the output from Pingdom for the subject page, you’ll see there is a stack of files being requested. This was my next target.

I started with the javascript files — there used to be four — and combined them into just two files (one needs to remain separate as it is not always loaded).

That was easy.

I also looked at some of the third party javascripts that were being loaded. A World Nomads one related to their select box was a bit sluggish so I grabbed the script and uploaded it to S3. One note on this is I’ll have to check back occassionally with Nomads to make sure I have the most up-to-date file to keep this working properly. I’ll probably do the same with AWeber which can sometimes really bog down the load, while Reinvigorate I plan to stop using, so will just remove it.

The other third party scripts, Quantcast, Facebook, Google Analytics are better left on their respective servers.

In reducing the number of requests I’m not only building a faster site, I’m also saving myself money. Amazon charges for the S3/Cloudfront service in part by request and my last bill charged me for almost four million requests. (Don’t panic, the bill was under $10). But essentially what Amazon is saying it is in everyone’s interests — mine, Amazon’s and Travelfish.org readers — to keep the total number of requests down.

Talking about requests, the next step (which I’m starting on this week and will write about next week) is all about reducing them even further — with Sprites.

So many pretty pictures
Many of the icons (stars, checkboxes,flags etc) on Travelfish.org could be combined into a single file and displayed using CSS. The process is called sprites and there’s an old but good general wrap on sprites at alistapart.

Basically if you have 30 images that are common on many pages, you combine them into one and reference different parts of the single image to display the icons it contains. In this example this effectively reduces the number of files you are requesting from 30 to 1 and probably results in a lower overall filesize as well.

Optimal images
There are a number of online services you can use to optimise your web images. This generally revolves around stripping out data that isn’t needed (eg EXIF blah blah) and making the image file as compact as possible. Travelfish.org has around 15,000 image files on it, so I’ll be saving this one for the wet season.

Often the file saving is nominal (in hundreds of bytes rather than thousands), but every little bit counts — especially when you have an image being served thousands of times a day, 365 days a year.

Code reworking
Travelfish is all handmade, by me, and it generally works. I’m not bragging, but rather saying I could make a glider as well, that would probably fly — but it sure as hell wouldn’t be the Concorde.

I’ll be the first to say there is significant grounds for improvement in this area, especially with regard to caching — but as this will be different for every site, there’s little point in going into it here. The other points above though are applicable to any website.

Amazon S3
Amazon Cloudfront
Labnol’s tutorials
S3 Firefox plugin
WordPress plugin for S3 image uploads
alistapart on sprites
Pingdom results on the sample page

Next week, sprites and WordPress readership helpers.

Thanks to Carl Hancock for pointing me to this entry regarding Cloudfront and S3.

It points out that Cloudfront doesn’t rerequest the file from S3 unless the filename has changed. I’d been updating the Expire Headers on the image on S3, but the file had already been called across to Cloudfront – so the revised image wasn’t being called.

What I need to do is upload a renamed version of the file to S3, change the expire header, then upload a new version of the HTML file that requires the image, using the new image name — this (in theory, I’ve not tested it yet) should result in the new image being pulled over.

Tedious, but better to learn this now rather than after I’ve uploaded the other 10,000 images!

Second update
So having tested the above, it does indeed work — so I wish I’d posted this entry before I uploaded all the images I did — as now I have to rename all of them… doh!