captsolo weblog

The new behaviour of a location bar in Firefox 3 might have come as a surprise to some users. And not always a pleasant surprise. It may be “smarter” but it can also ruin the user experience.

Here is some advice how to tweak it “back to normal":

9 tweaks for Firefox 3’s location bar

Firefox extensions which can help:

• OldBar extension (recommended)
• Old Location Bar (still experimental)

OldBar has a more solid feel to it and I will probably keep using it. But I would love to have the old URL lookup algorithm back (these extensions change the look-n-feel but not the algorithm). The one where only the URL is matched and not the page title.

Ian Davis wrote a reply on FriendFeed: “Stick with it [the new location bar], it’s changed how I bookmark (or not) completely.”

With the appearance fixed / improved (using OldBar) the location bar feels more useable already.

Currently it leaves me with mixed impressions: I like that you can enter multiple words in the location bar and they will be searched throughout the URL (and title). For example, enter a part of the hostname and refine the search by adding a part of the name of the file or wiki page. That’s nice.

Still do not like that it is searching in page titles. This is mostly garbage to me because page titles (1) do not uniquely identify the page and (2) do not always properly describe content of the page. Users relying on searching in page titles for locating the webpage of their internet bank can also be a tasty target for phishing.

P.S. Also check out user reviews to the OldBar extension.

42

Update: Thanks to tm who found that there is also a CSS score test:

22

Twitter “hashtags” (such as #www2008) have given users an easy way to tag Twitter messages or “tweets".

“Hashtag” convention has emerged from the Twitter user community and is not yet supported by Twitter itself (this was the case with @replies - a way to address other users and engage in conversations with them - which also emerged from users’ behaviour and only later was granted special handling by the microblogging service). This creates an opportunity for external services for using Twitter APIs to create websites for tracking conversations that use “hashtags".

#www2008 is a tag used by many participants of the WWW 2008 conference to tag their short messages. See below for some of these services which will show you twitter conversations and reports from the conference.

Hashtags: www2008 => http://www.hashtags.org/tag/www2008/

This site provides real-time tracking of Twitter #hashtags. It includes a nice “sparkline” showing the history of popularity of the given tag. This is an opt-in service and in order for your messages to be shown on it you must add @hashtags user as your contact on Twitter.

Summize Twitter conversation search => look for keywords www2008 and “www 2008″

Summize lets us perform keyword searches on Twitter conversations, updated almost in real-time. Using it you can find conversation missed by hashtags search. For example, when someone just used a phrase “WWW 2008″ or did not opt-in to hashtags search service.

There must be other services like this. It was interesting to follow conversations on Twitter and occasionally bump into other authors of short messages seen on Twitter. What someone could do now with these conversations (apart from reading them and maybe finding something interesting) is extract and visualize a community of Twitter message authors at WWW 2008.

There are cases when you need to use JavaScript closures and there are cases when you accidentally create closures when you don’t need to. Here are some articles to help understand them:

“JavaScript Closures for Dummies” [blog.morrisjohns.com]

“JavaScript Closures” [jibbering.com]

“AJAX in Action: Appendix B - JavaScript for Object-Oriented Programmers” [java.sun.com]

Interesting & related:

“Closures and executing JavaScript on page load” - Simon Willison on chaining multiple onLoad events

“Private members in JavaScript” - Douglas Crockford on implementing private class members

TrimBreakpoint - a tricky use of closures to let you inspect local variables for a function from a popup breakpoint window.

A JavaScript closure preserves references to all the local variables after the function has finished.

If a function is defined within another function, a closure is created. Then the inside function (e.g. when called later, using a reference to it) can still access and modify variables of the outside function, even after the outside function has quit.

Note: this explanation is a very simplified view and you may want to consult articles referenced here for more detailed information.

When Dopplr announced importing your social network from other sites the single most requested feature in comments was FOAF import (with CSV import being second).

Note: Please add your feedback. Comments are working, but may be held for moderation and will appear after being approved.

So - what’s the use of FOAF for Social Network Portability?

1. Existing FOAF data

LiveJournal is one of the largest sources of FOAF data and every user automatically gets a FOAF profile (http://username.livejournal.com/data/foaf/, same works for communities). It creates a large amount of data which other application can make a use of. Exporting FOAF is a simple task and other community sites may start exporting it should they see a good reason to do so (which is what this article aims to address).

You don’t have to look at “raw” data, though. Let a computer do the job and take a look at a more human-friendly rendering of FOAF (and navigate the data by following links indicated with arrows) using one of the many RDF browsers. This will show you what data are in there, but can still be quite nerdy.

In the end it will be other applications and sites like Dopplr that can use FOAF and other structured data to provide better services to its users. E.g., Apple Safari RSS reader uses FOAF to display a list of person’s friends when browsing her LiveJournal feed (a screenshot here).

P.S. If you want to be aware of web pages containing FOAF, SIOC and DOAP machine-readable information while browsing the web, the Semantic Radar extension for Firefox may be for you.

2. What about hCard + XFN ?

Many may think that vCard or hCard + XFN is the only / best choice for this. As a format for representing structured data they are a good thing, but at the same time are only and not always the best solution.

Most of the entries in a list of Services with hCard+XFN supporting friends lists start with “login and …".

A public hCard+XFN usually will not contain enough data to identify your friends. It would need to provide information for linking their identities across sites, such as an email address. hCard expresses it in clear text and this is something that spammers will like but your friends may not.

You could require a user to enter a login name and a password to access a private profile with all the required details. (An alternative is to only use public information, but this is mainly limited to exact nickname matches.) Will you always trust a site enough to give it passwords for all other sites you want to port your data from? Really?

Also, once the sites are talking directly, they don’t necessarily need an HTML-based data format and can as well use the APIs provided by these sites.

3. Useful properties of FOAF

FOAF has some useful properties that make it particularly interesting for social network portability.

FOAF was created with identification of objects in mind. It is built on RDF, which is a generic format for linked data on the web. As such, it gives us some flexibility on how pieces of data can be distributed across the web. We’ll use that later. (But enough about RDF)

Take a look at any LiveJournal FOAF profile (or a human-readable rendering of it). You will notice there some basic information about the page (title, feed, …) and quite a lot of information about its author. This includes core FOAF properties (name, homepage, birth date, image, interest(s), …) and LiveJournal extensions to it (city, country, school, bio, …). foaf:knows allows to link together people and their friends.

There vocabularies may use different namespaces, but FOAF + RDF allows to freely use them together and make sense of this data. What matters it that this is some rich data applications can work with.

4. Identifying objects in FOAF

We need a way to identify people (your friends) based on the public FOAF profile. While you can express an email address in FOAF we don’t want to do that on a public web page. Take a look at foaf:mbox_sha1sum instead.

It is a unique hash generated from person’s email address (using SHA1 algorithm). There is a one-way correspondence between an email address and its SHA1 hash, but no way to recreate an email address using a hash.

This makes foaf:mbox_sha1sum very useful when you need to identify a person by her email address, but do not want to put this email on the web in clear text. Many LiveJournal profiles (but not all) contain a foaf:mbox_sha1sum. This information can be used by other sites to show you if your friends are already registered there. All they have to do is compare email SHA1 hashes of registered users (which can be easily calculated) with those of your friends.

P.S. There are other ways to identify a person (e.g., via a homepage URL), but let’s concentrate on email and its hash now.

5. What’s stopping Dopplr ?

If people are asking for FOAF import and if this format is worth considering, what is stopping Dopplr and other social media / network sites?

Best if they can share insights into what the real problems are. While waiting for comments, here’s what I think: it’s practical data access issues. It makes sense to start with large sources of FOAF data and look how they are structured.

LiveJournal is probably the largest of them. Notice that a LJ FOAF profile contains a lot of information about a person itself, but not that much info about friends. Fear not - reference to every friend contains a link (rdfs:seeAlso) to the full FOAF profile and you can follow it to retrieve all the details required.

And that is a problem. To check for all your friends a site will need to make (n+1) HTTP requests where n = a number of your friends. LiveJournal policy for bots requires not to make more than 5 requests per second. Doing those many requests takes time and bandwidth and may be something that the sites you are migrating want to avoid.

6. Solution

How to make LiveJournal FOAF data more useful?

Let’s just take all the properties needed (foaf:mbox_sha1sum in this case) from friends’ FOAF profiles and copy them to where they are referenced to in your FOAF profile. Remember the flexibility of FOAF and RDF? That makes it perfectly valid - just copy’n'paste.

This would require a simple change at LiveJournal’s side, but would make using this data much more efficient - now just 1 HTTP request is needed to move a network of all your friends to a new site.

What about other FOAF data sources? Many already contain information needed to identify their contants. For example, every person in FOAF profile of Tim Berners-Lee has an email address, its SHA1 hash or a unique identifier (URI which is another option how to identify objects) assigned. These sources are rich enough for our needs, but may not provide the critical mass needed to get the ball rolling.

That’s why we need to get better FOAF data from large social media sites. And to get a clear understanding of how FOAF can be best used for social network portability.

Related links

“Thoughts on the Social Graph” by Brad Fitzpatrick

… will add suggested links here …

Comments

I would love to hear from you - is this information interesting or useful? Is it all wrong, perhaps? Do you want to add something or ask a question? Go ahead!

P.S. This is not an attack on microformats. Some of the things described (e.g., a hash of the email address) can be easily added to them, if needed. Data can also be converted from one data format to another. The goal of this article is to provide some information about using FOAF for social network portability. I hope you will find that it has some power we can use.