Facebook Fan Pages vs. Networked Blogs
Love it or hate it, Facebook is here to stay. Despite challenges around user privacy and an ever-changing interface, Facebook is rapidly becoming THE gateway to content for many users. As a blogger, Facebook can be a great tool to promote and share your content to potential readers. But the real question is…what’s the best way to do that? (…)
Showing posts with label Social networks. Show all posts
Showing posts with label Social networks. Show all posts
Facebook just lunched the "Like" button to be used in any page. To have it in your Blogger blog, do the following steps:
- First, do a backup of your blogger template (see it here: Template actions: download, backup, edit and restore) .
- Then edit your template and find the following text in the XML code:
<data:post.body/>
Tip: if you can't find it, try to search data:post.body until there is something similar and that ends with />
- Place the following code after that line:
<iframe allowTransparency='true' expr:src='"http://www.facebook.com/plugins/like.php?href=" + data:post.url + "&layout=standard&show-faces=true&width=530&height=60&action=like&colorscheme=light"' frameborder='0' scrolling='no' style='border:none; overflow:hidden; width:530px; height:60px'/>
Result:
Changing the Like' button to 'Recommend'
If you prefer that your button says "Recommend" instead of "Like", it is just necessary to change the code of point 3: just change the action=like to say action=recommend. The following code does that:
<iframe allowTransparency='true' expr:src='"http://www.facebook.com/plugins/like.php?href=" + data:post.url + "&layout=standard&show-faces=true&width=530&height=60&action=recommend&colorscheme=light"' frameborder='0' scrolling='no' style='border:none; overflow:hidden; width:530px; height:60px'/>
Result:
- Save the template and that's it.
There are other ways of doing this but the one recommended by Facebook (see here) won't work because it gives an Blogger gives an error when the template is being saved. Also, the approach given by Facebook won't allow individual "Likes" for each post (only for the whole blog).
Finally, If you prefer using the Facebook API ( to leave a comment on the "Liked" item), just have a look here.
Todos conhecem os serviços que tornam os URL mais curtos. Especialmente os utilizadores do Twitter. Escolha no entanto o serviço com ponderação. O goo.gl (da Google) é o melhor nos dois critérios apresentados. Mas não está disponível como um serviço autónomo. Em contrapartida, pode ser acedido através de:
- uma extensão para o Chrome: https://chrome.google.com/extensions/detail/iblijlcdoidgdpfknkckljiocdbnlagk
- Através do Google Toolbar:
http://googleblog.blogspot.com/2009/12/share-any-web-page-from-your-toolbar.html - Através do Feedburner: http://adsenseforfeeds.blogspot.com/2009/12/socializing-your-feed-with-twitter.html
Mais detalhes sobre o goo.gl num post do blog oficial da Google: Making URLs shorter for Google Toolbar and FeedBurner
Gráficos e texto mais detalhado: URL Shorteners Slow Down The Web – Especially Facebook’s FB.me
O Conan O'Brien, agora em férias forçadas, decidiu criar finalmente a sua conta no Twitter e decidiu também mudar a vida de uma follower. Inicialmente, o Conan não seguia absolutamente ninguém, mas na semana passada decidiu seguir apenas uma única pessoa e isso mudaria a sua vida. E foi o que aconteceu a Sarah Killen, que já conta com 19.900 followers. continue a ler
O blog BaseDadosRamiro é isso mesmo: uma base de dados sobre Educação onde guardo toda a legislação, estudos, relatórios e estatísticas.
(…)
A cara nova do blog tem a assinatura do editor do BrasilHighTech e foi construída com base em dois critérios: simplicidade do website e estética. Ninguém gosta de visitar um blog confuso, desarrumado e de cara feia.
Vale a pena manter um design limpo. Por melhores que sejam os conteúdos, a apresentação também conta.
An interesting post from the Facebook engineers about how they made the Facebook twice as faster.
by Jason Sobel (notes) Thu at 11:25pm
Everyone knows the internet is better when it's fast. At Facebook, we strive to make our site as responsive as possible; we've run experiments that prove users view more pages and get more value out of the site when it runs faster. Google and Microsoft presented similar conclusions for their properties at the 2009 O'Reilly Velocity Conference.
So how do we go about making Facebook faster? The first thing we have to get right is a way to measure our progress. We want to optimize for users seeing pages as fast as possible so we look at the three main components that contribute to the performance of a page load:network time, generation time, and render time.Components Explained
Network time represents how long a user is waiting while data is transmitted between their computer and Facebook. We can't completely control network time since some users are on slower connections than others, but we can reduce the number of bytes required to load a page; fewer bytes means less network time. The 5 main contributors to network time are bytes of cookies, HTML, CSS, JavaScript, and images.
Generation time captures how long it takes from when our webserver receives a request from the user to the time it sends back a response. This metric measures the efficiency of our code itself and also our webserver, caching, database, and network hardware. Reducing generation time is totally under our control and is accomplished through cleaner, faster code and constantly improving our backend architectures.
Render time measures how much time the user's web browser needs to process a response from Facebook and display the resultant web page. Like network time, we are somewhat constrained here by the performance and behavior of the various browsers but much is still under our control. The less we send back to the user, the faster the browser can display results, so minimizing bytes of HTML, CSS, JavaScript, and images also helps with render time. Another simple way to reduce render time is to execute as little JavaScript as possible before showing the page to the user.
The three metrics I describe are effective at capturing individual components of user perceived performance, but we wanted to roll them up into one number that would give us a high level sense of how fast the site is. We call this metric Time-to-Interact (TTI for short), and it is our best sense of how long the user has to wait for the important contents of a page to become visible and usable. On our homepage, for example, TTI measures the time it takes for the newsfeed to become visible.First Steps
From early 2008 to mid 2009, we spent a lot of time following the best practices laid out by pioneers in the web performance field to try and improve TTI. For anyone serious about making a web site faster, Steve Souders's compilations are must-reads: High Performance Web Sitesand Even Faster Web Sites. We also developed some impressive technologies of our own to measure and improve the performance of Facebook as described at the 2009 O’Reilly Velocity Conference by two Facebook engineers, David Wei and Changhao Jiang.
By June of 2009 we had made significant improvements, cutting median render time in half for users in the United States. This was great progress, but in the meantime, Facebook had exploded in popularity all across the globe and we needed to start thinking about a worldwide audience. We decided to measure TTI at the 75th percentile for all users as a better way to represent how fast the site felt. After looking at the data, we set an ambitious goal to cut this measurement in half by 2010; we had about six months to make Facebook twice as fast.Six Months and Counting...
On closer inspection, our measurements told us that pages were primarily slow because of network and render time. Our generation time definitely had (and still has) significant room to improve but it wouldn't provide the same bang for the buck. So we devoted most of our engineering effort towards two goals: drastically cutting down the bytes of cookies, HTML, CSS, and JavaScript required by a Facebook page while also developing new frameworks and methodologies that would allow the browser to show content to the user as quickly as possible.
Cutting back on cookies required a few engineering tricks but was pretty straightforward; over six months we reduced the average cookie bytes per request by 42% (before gzip). To reduce HTML and CSS, our engineers developed a new library of reusable components (built on top of XHP) that would form the building blocks of all our pages. Before the development of this component library, each page would rely on a lot of custom HTML and CSS even though many pages shared similar features and functionality. With the component library, it’s easy to optimize our HTML in one place and see it pay off all across the site. Another benefit is that, since the components share CSS rules, once a user has downloaded some CSS it’s very likely those rules will be reused on the next page instead of needing to download an entirely new set. Due to these efforts, we cut our average CSS bytes per page by 19% (after gzip) and HTML bytes per page by 44% (before gzip). These dramatic reductions mean we get our content to users faster and browsers can process it more quickly.
Cutting back on JavaScript was another challenging problem. Facebook feels like a dynamic and engaging site in large part due to the JavaScript functionality we've created, but as we added more and more features, we wrote more and more JavaScript which users have to download to use the site. Remember that downloading and executing JavaScript are two of the main issues we need to combat to improve network and render time. To address this problem our engineers took a step back and looked at what we were using JavaScript to accomplish. We noticed that a relatively small set of functionality could be used to build a large portion of our features yet we were implementing them in similar-but-different ways. This common functionality could be provided in a very small, efficient library that is also cacheable on the user's computer. We set out to rewrite our core interactions on top of this new library, called Primer, and saw a massive 40% decrease (after gzip) in average JavaScript bytes per page. Since Primer is downloaded quickly and then cached for use on future page views, it also means that features built exclusively on Primer are immediately usable when they appear on the screen; there's no need to wait for further JavaScript to download. An example of such a feature is our feedback interface which allows users to comment on, like, and share content and appears all across Facebook.
Another project I'd like to highlight requires a little more setup. As described earlier, the traditional model for loading a web page involves a user sending a request to a server, the server generating a response which is sent back to the browser, and the browser converting the response in to something the user can see and interact with. If you think about this model there is a glaring problem. Let's say it takes a few hundred milliseconds for the server to completely prepare and send a response back to the user. While the server is chugging through its work the browser is just sitting there uselessly, waiting for something to do and generally being lazy. What if we could pipeline this whole procedure? Wouldn't it be great if the server could do a little bit of work, say in ten or fifty milliseconds, and then send a partial response back to the browser which can then start downloading JavaScript and CSS or even start displaying some content? Once the server has done some more processing and has produced another bit of output it can send that back to the browser as well. Then we just repeat the process until the server has nothing left to do. We've overlapped a significant portion of the generation time with the render time which will reduce the overall TTI experienced by the user.
Over the last few months we've implemented exactly this ability for Facebook pages. We call the whole system BigPipe and it allows us to break our web pages up in to logical blocks of content, called Pagelets, and pipeline the generation and render of these Pagelets. Looking at the home page, for example, think of the newsfeed as one Pagelet, the Suggestions box another, and the advertisement yet another. BigPipe not only reduces the TTI of our pages but also makes them seem even faster to users since seeing partial content earlier feels faster than seeing complete content a little bit later.Success!
I'm pleased to say that on December 22nd, as a result of these and other efforts, we declared victory on our goal to make the site twice as fast. We even had 9 whole days to spare!
After hitting the 2x site speed goal the team celebrated with t-shirts. And dinner (not pictured).
I hope that you've personally experienced and appreciated the improvements we've made in site speed and that this post has given you some insight in to how we think about and approach performance projects at Facebook. Stay tuned for more details on many of the projects I mention here in future blog posts and industry conferences. In 2010 look for the site to get even faster as we tackle new challenges!
Jason, an engineer at Facebook, wants to remind you that perf graphs go the wrong way.
A Google decidiu entrar na senda das redes sociais. Fê-lo com o Google Buzz, passando por cima de todas as questões de privacidade dos seus utilizadores. Comecei por usar o Buzz no Fliscorno, para saber do que se trata e por o email do blogue não estar associado ao email pessoal. Sinceramente, é algo que não quero na minha conta pessoal. Vejo-lhe utilidade para a divulgação de conteúdos, tal como o Facebook ou o Twitter mas há uma diferença de nota: neste dois últimos, a adesão não é imposta. Pior, quem aderir ao Facebook ou ao Twitter sabe que o está a fazer numa rede onde as coisas serão públicas. Já com o Buzz, as pessoas aderiram com um certo nível de privacidade e este foi drasticamente alterado com a adição do Buzz. De um momento para o outro, passo a saber com quem outras pessoas trocam emails mais frequentemente, sem que elas tenham tido uma palavra no assunto. "Do no evil" é o slogam da Google. Certo...
Mas nestas coisas, cada qual sabe de si. Se o novo serviço da Google lhe agrada, tudo bem. Se não, segue-se um artigo que explica como desactivar o serviço. Num caso como noutro, convém é que saiba ao que está ;-)
February 11, 2010 10:01 AM PST
Buzz off: Disabling Google Buzz
Updated: February 11, 2010 at 12:15 p.m. PT to share a new rollout that Google implemented to better manage (and block) contacts. Also added a note about profile privacy.
My colleague Molly Wood called it a privacy nightmare, but to many, Google's new social-networking tool Buzz is at its root an unwanted, unasked for pest. The way some of us see it, we didn't opt in to some newfangled Twitter system and we don't particularly want to see updates from contacts we never asked to follow creep up in our Buzz in-box. Call us what you will, but for curmudgeonly types like us, Buzz isn't so much social networking as it is socially awkward networking. We tried it, we didn't like it, and now it has to go.
Here's how we silenced Buzz from the desktop:
Step 0: Don't disable Buzz--yet
The automatic reaction is to scroll to the very bottom of Gmail and click the words "turn off buzz." But all this does is remove active links, leaving your profile still publicly available, along with any public buzzes you might have made while trying Buzz out. In fact, you're still technically following people, and they're following you. Not OK.
Disabling Buzz isn't enough. My previous buzzes are still visible to anyone looking for them.
(Credit: Screenshot by Jessica Dolcourt/CNET)
Step 1: Purge your profile
One way to find your profile is to go to http://www.google.com/profiles and search on your name. Next, permanently delete buzzes in the public timeline by clicking the "Delete" tag. Then get to work unfollowing those that Google has "helped" you automatically follow.
From your profile, (1) click the hyperlink first and then (2) manually unfollow individuals.
(Credit: Screenshot by Jessica Dolcourt/CNET)
However, it's as if the Buzz team never envisioned anyone would want to completely opt out. You'll need to unfollow individuals one by one, which takes some time if Google subscribed you to a long list of followers. Despite what it said in our profile, we had to keep loading pages to unfollow a big chunk of friends.
Also take a moment to make sure that your profile isn't broadcasting anything you don't want it to. Click the "Edit Profile" link to the right of "Contacts" and "About me" to give your profile a once-over.
Note: If your profile was never public (and if you never experimented with Buzz), you'll have fewer privacy concerns. However, if you are getting rid of Buzz, it's a good idea to scan your profile to make sure you're not exposed on anyone's automatic list of followers.
Step 2: Block your followers
If you're serious about removing traces of yourself from Buzz's public record, you'll need to make sure you're invisible to others as well. Go back to Buzz in Gmail (if you already disabled it, you can turn Buzz back on at the bottom of the page to complete this step.) In the absence of an obvious "block all" button, we manually blocked each individual by clicking their picture from the list of followers and then selecting "Block."
Blocking: Another option.
(Credit: Screenshot by Jessica Dolcourt/CNET)
At noon PT on Thursday, we noticed that Google rolled out a better interface that includes some management tools you can use to more easily block users. Prior to that, we noticed a few leftovers that were still visible in our public profile because we weren't previously able to access their profile tab. Thanks to Google's tweak, we unblocked them in a hurry.
Blocking someone won't alert them and you can always unblock them later if you change your mind about Buzz.
A Thursday tweak adds drop-down tools to better manage followers.
(Credit: Screenshot by Jessica Dolcourt/CNET)
Step 3: Disable Buzz in Gmail
Now it's safe to disable Buzz in Gmail, thus removing the offending links and updates from your eyes.
Last step: Unplug Buzz in Gmail
(Credit: Screenshot by Jessica Dolcourt/CNET)
This worked for us, but leave your own tips and travails in the comments.
Related stories:
Rafe and Josh debate Google's Buzz
Google Buzz: Privacy nightmare
Google's social side hopes to catch some Buzz
