The following video shows my attempts to use the mobile versions of Facebook and Twitter with Lynx, the textual browser. Facebook fails, while Twitter successfully logs me in and lets me publish a tweet. I hope you find it useful.
In this post I will show you how to create a Facebook-like tooltip menu with the aid of CSS and the jQuery Tipsy plugin. As you will see, the jQuery code required to accomplish this task is very few when compared to the length of the CSS code used to lay out our menu. As always, let's start with our markup first.
Forty minutes ago I received a message from Facebook where my good friend Ivan asked me his Facebook friendship again. I asked him what was going on and he simply said that he did try to reset his password but he failed because he couldn't remember his very first password. In short, the system simply blocked his actions because he exceeded the limit of attempts. This is a normal procedure due to the prevention of malicious attacks against one user's credentials. However, this
also happened because the application's password recovery works only on a single level, not on multiple levels. In this post I'm going to explain you why a multilevel approach is a better way to handle password recovery.
Facebook is a PHP-based web application over a MySQL database. As such, Facebook must face two basic problems. First, there's the security of user information. Second, the visibility of user information on the web. Basically, Facebook deals with these problems using URL rewriting or, more precisely, a well-known architecture of URLs. As a rule of thumb, when Facebook has to handle user information simply as mere settings, data transaction or, more broadly, as internal preferences, it uses the form facebook.com/script.php?parameter=value, that is, a "dirty" URL with several parameter/value pairs attached to it. On the contrary, when Facebook has to display user information publicly (that is, in a way that search engines can handle), URLs are always treated in an human-friendly way, such as www.facebook.com/username.
Bear in mind, however, that Facebook URLs change depending on the user's status, that is, if a user is or is not logged in. For example, when you're logged in and you run a search for a person, then his/her public profile URL is displayed using a SEO-friendly URL. Conversely, if you're not logged in, URLs are often returned using the ID of the profile, such as 11099990, for example. From a server-side scripting perspective, there are a few things to bear in mind:
Working with a database, you may find the latter solution easier, because you don't have to deal with string formatting, for example when you have to turn the first and last name of a person into a username such as gabrieleromanato. But if you want to preserve a good level of visibility on the web for your users, the former is always a good solution.
Either if you're using an MCV architecture for your application or a mixed one, you should define several rules in your web server configuration for handling URL rewriting. As a rule of thumb, try to split your URLs into two main categories (e.g. internal URLs and public URLs) and then write your rules accordingly.
Facebook Social is a jQuery plugin that allows you to insert some of the most popular Facebook's buttons to your site. It's the direct descendant of the earlier Facebook Widget Plugin. You can find everything here.
As you can see from the above picture that shows the Facebook's diffusion in December 2010, Facebook is the most used and widespread adopted social network in the world. The secret of Facebook is simple: applying a key concept of information architecture (namely findability) to people, thus turning every single user into a human resource that can be found and shared. Turning the human experience into a resource is simply a revolutionary approach to the IT world. Every single bit of an human life has been reformulated in terms of resources, which is different from assets. In fact, an asset necessarily implies a job, a career, a working position, whereas resource is a broader concept that ranges over a great variety of possible contexts, from daily life to emotional life and so on, thus encompassing all possible aspects of a human life. Findability is another key aspect of this secret: surfing the web, in its essence, means simply looking for something. In the past, people used to surf the web to search for electronic resources (files, documents, images etc.). Now, Facebook offers the opportunity to search for other people, other human resources. This is something that cannot be overlooked if we want to understand the secret of Facebook's success.
I was developing a web site which required the addition of some Facebook buttons. So I said to myself: "What about a jQuery plugin that makes this job for you?". And here's the plugin called Facebook Widget.
This first version supports both the Like and Sharer widgets, but I think that in a not too distant future many other widgets will be added.
$(element).FacebookWidget(options);
fb-widget.fb-widget-wrapper.sharer.Facebook.Added support to the Activity button. New options include:
false (no header).light.false.false.jquery-facebook-widget-15.html
No kidding. If you take a look at the source code of any Facebook page (for example, your home page), you will see something quite shocking: the 80%-90% of the page is made up by JavaScript code! That's why Facebook doesn't work with assistive technologies: there's very few actual content to parse and render in such pages. Facebook seems to embrace the what-you-see-is-what-you-get philosophy or, as they put it, we're not cool enough to support your browser (said to a Lynx user).
Fine. So they don't care if many users can't access their web application. But there's another thing that needs to be emphasized: by relying so heavily on JavaScript and Ajax, Facebook delivers a consistent parsing and rendering load to web browsers. Sure, JavaScript engines evolve, but what about backward compatibility? There should be a certain balance between effective content and JavaScript-generated content. Facebook is completely unbalanced. And yes, this is a mess. No kidding.
Facebook social buttons are an easy way to insert Facebook's features into your website. If you connect to this page, you get for example the "Like" button that we're going to use in this tutorial. The point is: either you choose to use an iframe or FBML (Facebook Markup Language) you'll surely stumble on many validation errors, especially if you're using XHTML 1.0 Strict. So it's better to follow another approach, by using JavaScript and jQuery. So, given this markup:
<p id="fb-like"><iframe src="http://www.facebook.com/plugins/like.php?href=http%253A%252F%252Fonwebdev.blogspot.com&layout=standard&show_faces=true&width=450&action=like&font&colorscheme=light&height=80" scrolling="no" frameborder="0" style="border:none; overflow:hidden; width:450px; height:80px;" allowTransparency="true"></iframe></p>
you get this result, which is not a valid page. The first thing we need to do is to modify our markup by taking into account also the case when JavaScript is not supported, like this:
<p id="fb-like">
</p>
<noscript>
<p><a href="http://www.facebook.com/plugins/like.php?href=http%253A%252F%252Fonwebdev.blogspot.com">Like</a></p>
</noscript>
By using the noscript element we make sure that our resource is still available when JavaScript is not supported or turned-off. Now it's time to add jQuery:
$(document).ready(function() {
var $iframe = $('<iframe></iframe').attr(
{
'src': 'http://www.facebook.com/plugins/like.php?href=http%253A%252F%252Fonwebdev.blogspot.com&layout=standard&show_faces=true&width=450&action=like&font&colorscheme=light&height=80',
'scrolling': 'no',
'frameborder': '0',
'allowTransparency': 'true'
}
).css({'border': 'none', 'overflow': 'hidden', 'width': '450px', 'height': '80px'});
$iframe.appendTo('#fb-like');
Simply put, we've assembled our iframe by adding its own attributes and CSS styles. You can see the final result here.
Check out this SlideShare Presentation:
I just typed social markup language on Google and I got this. Excellent. So what's the point here? The point is, rather surprisingly, that the W3C is actually ignoring the social network phenomenon or, more explicitly, neglecting the actual needs of web users and developers. There's no SNML (Social Network Markup Language) standardized in any W3C specification. Too bad. So the W3C seems not to care very much about what is become a de facto standard of many web platforms. It seems to delegate to specific social network owners the task of creating a common set of tags to handle their documents. But this is exactly what happened a long time ago before the creation of the W3C itself, that is, the proliferation of proprietary and not-interoperable tags in the HTML. So what? The W3C should get more interested in the real web, now and not in a remote and distant future. The alternative is simply a jump back to the age of incompatible markup and the resulting chaos of platform wars.
Interesting conference.
My little niece Matilde now has her own public page on Facebook! You can join this page as a fan. Hail, hail Matilde!
I found an interesting article dated about two years ago where it's said that Facebook is slow and unresponsive. Well, not always. The fact is that with more than one million users is not always easy to maintain good performance rates. However, Facebook sometimes is really slow. This might be due to two key aspects. First of all, database transactions, because Facebook is a really complex web application that needs a lot of work and maintenance when it comes to query a database. So here's the first problem: server-side maintenance. Second, Facebook relies mostly on JavaScript and Ajax to perform its multiple tasks (update, delete, post etc.). This means that a web client (usually a browser) has to do a lot of work to parse and cache properly all this code. Further, more work is needed to display informative messages to the user. So here's the second problem: client-side implementation. Honestly, I don't think that Ajax and JavaScript are the only feasible alternative to ease the application's load. I think that most of the work should be tweaked up on the server-side, while using JavaScript and Ajax only in a supportive way. These are, in my opinion, the two key aspects that still need a lot of work on Facebook.
Facebook, as I said in an earlier post, is almost inaccessible for people who use assistive technologies. Here's a screenshot taken while trying to connect to Facebook using Lynx, the textual browser:
As you can see, Lynx is not supported, so trying to log in results in a frustrating experience of redirections. I hope that Facebook will start to take into account this kind of users and their needs, because it's too bad that a web application like Facebook doesn't support assistive technologies.
I've been involved in accessibility studies for almost three years and I have to say that Facebook is not exactly the perfect prototype of an accessible web platform. This is due to the following reasons:
Instead of using Microformats, Facebook's APIs rely on proprietary markup to make the application work. This leads to poor interoperability betwenn different user-agents.
Without a proper fallback mechanism, these two technologies can actually make life very hard for people with disabilities or people who use assistive technologies.
I hope that in a near future Facebook will take into account these issues more seriously. Meanwhile, people with disabilities may experience a genuine frustration in trying to use this platform.