Football Celebrations – some cool historical football goal celebration clips

posted by robert | filed under social media

With the World Cup coming, it would seem a good time to get all football-focused… and, while I’m not the World’s biggest football fan, this little widget from FIFA/Coca Cola caught my eye.

FIFA WC 2010 Celebration Inspiration

The theme is “football celebrations” – with videoclips from some of the most famous football celebrations ever – whether it be Bebeto’s cradle-rocking goal celebration in the 1994 World Cup (brilliant!) or US Women’s footballer Brandi Chastain’s famous “Sports Bra” incident… All moments that marked football history.

Click the image above and you can watch the clips for yourself and even add the widget to your facebook profile if you wish… Something for all football fans

Enjoy!!

(ps. no, not my work )

 

read more | comments off | May 28th, 2010

A Dialog with Facebook

posted by robert | filed under social media, tutorials/samples

Well, not actually – more a “how to” for those of you looking to use Facebook’s fb:dialog FBML tag.

As usual, the documentation is not perfectly clear. It is, in this case however, actually pretty much spot on if you read it through properly – something I, of course, didn’t do at first.

The documentation states that the fb:dialog tag is in beta. It’s been in beta for a long time as I first used it in the “Beach Fit in 30 Days” application back in January (post) to show measuring chart information in the diary:

Beach Fit in 30 Days Measuring Chart

That was, however, a simple use and involved only showing an information popup with a close button.

What about more complex dialogs? How would you use what Facebook call “Mock AJAX” to take the contents of a form in your open dialog, send them to your server and then display a response from the server in the (still open) dialog?

How about then going a step further and redirecting to another page when the user closes the dialog?

That’s what I’m going to show you here.

The example I’ll go through is one of showing a dialog to obtain name and email address from an application user (remember that you can’t, however, store this information in a database – it’s against the Facebook TOS – although you can use it transiently), calling a server script to do something with the information and then returning a success or failure response. Upon close of the dialog the user will be redirected.

Firstly, as usual, I’m going to assume you’ve set up an application and are familiar with the basic principles of Facebook API coding. The example I’ll go through is for PHP. If you use a different programming language then I’ll leave it to you how you translate what’s written here

So. First step: Set up the dialog form and the fb:dialog tag:

PHP:

This is pretty close to the sample they give you in the documentation, just with my form added. Note that the path to the script you call is a path to your own server, not to your Facebook app!

Save this as your initial canvas page – in this case, test_dialog.php.

Next, code up the server script to do it’s thing:

PHP:

Right. The first line ensures that my Facebook app configuration is loaded so that I have access to all variables I need and can also instantiate the Facebook class if needed here. $appurl will contain the path to my application in Facebook – i.e. the apps.facebook.com one – with a trailing “/”.

Save this as dialog_response.php (as per the clickrewriteurl attribute of the submit fb:dialog-button on your form).

The form parameters will be POSTed to the script and can be retrieved and used here. If all is fine, return the expected format to Facebook as above. If you omit the fb:dialogresponse, fb:dialog-title or fb:dialog-content tags your output in the dialog box will look pretty sparse – probably just plain text surrounded by the grey border. Not what we need.

Sending back the content correctly formatted will ensure that your users see what you expect them to see, all nicely presented in the “same” dialog.

Note the line:

PHP:

This is important as it’s the line of code that will render the close button on the dialog response shown and ultimately ensure that the user is redirected to the page you want – in this case, thanks.php.

In the error processing I’m going to leave the user where they were.

The last thing we need is to open the dialog. Bear in mind that what we’re working with here is the FBML tag and not FBJS or javascript. We therefore need a link of some sort.

For the sake of simplicity we’ll add a link to the test_dialog.php canvas page to open the dialog:

Code:

Now, assuming all is coded up nicely, your user will see the link when he/she visits your canvas page. Clicking the link will open the dialog:

The initial dialog opened

Clicking “send” will call the server script which, in turn, will do it’s thing and return the nicely-formatted response. The response is shown in the dialog:

The response shown in the dialog

Closing the dialog by means of the “close” button (there isn’t another way other than reloading the page) will cause the user to be redirected to the thanks.php page:

Redirected after closing the dialog

That’s it!

You can use this approach for adding extra security to “log in only” areas of your application or to provide any other interactivity you need. Dialogs opened with fb:dialog will also hold SWFs, Images or other forms of content BUT be aware that the width of the dialog seems to be fixed at about 465 pixels.

Have fun with your dialog(ue)s!

Robert

 

read more | comments off | August 26th, 2009

Twitter formalises the retweet – evolution?

posted by robert | filed under social media

I spotted this today, via @swissmiss and @GuyKawasaki: “Project Retweet” is underway over on the Twitter Blog.

Retweet Concept Sketch – by Biz Stone

The post, by Biz Stone, explains how Twitter are working on a new way to adopt and formalise the “Retweet” (forwarding somebody else’s Tweet onto your own followers) by building Retweet functionality into the Twitter web interface (as per the concept sketch by Biz Stone above) and also to build the same functionality into the API for developers.

“Cumbersome” is the word he uses to describe the current procedure that the community has adopted – placing the contents of the original tweet in quotes and preceding it with “RT” and the original poster’s name. OK, so it’s a little messy

The main benefit of an integration of Retweets into the platform is, for me, not that it’ll be any easier to Retweet, but that there’ll be extra characters available from those precious 140 to make an extra comment – assuming the approach taken in Biz’s concept sketch (very nicely drawn, by the way) is taken.

Now that’s cool! No revolution, but certainly a nice example of evolution.

Biz: I stole your sketch – thank you

 

read more | comments off | August 15th, 2009

Ich, Hier, Jetzt! Me, here, now!

posted by robert | filed under general, social media

OK, here it is: My first bilingual blog post!

Me at work today

pixelfreund started a Jekami (German: Jeder kann Mitmachen – means anybody can join in) today. I joined in. Here are the instructions, get that camera ready!!!

pixelfreund hat heute zu einem Jekami aufgerufen:

1. Take a picture of yourself right now.
(Fotografiere Dich genau jetzt)

2. Don’t change your clothes, don’t fix your hair…just take a picture.
(Zieh Dich nicht um, richte nicht Dein Haar … mach einfach das Bild)

3. Post that picture with NO editing.
(Veröffentliche das Bild, ohne es zu bearbeiten)

4. Post these instructions with your picture (in your Blog).
(Veröffentliche diese Instruktionen mit dem Bild (in deinem Blog)

Mach mit und poste deinem Link als Kommentar!

Join in and post your link as a comment!

Happy Friday all

 

read more | comments off | August 14th, 2009

Facebook AS3 API: Creating Events

posted by robert | filed under social media, tutorials/samples

Facebook Events – can’t be completely defined via the API

If you’re developing Facebook applications using the AS3 API you’ll eventually need to be able to create Facebook Events. That’s where you’ll need to be aware of another of Facebook’s restrictions for application developers: You cannot completely define an Event and it’s Invitees via the API.

Due to Facebook’s antispam rules, you can create an Event with some basic information – name, location, timings, etc. Your application’s user will then need to log into Facebook and complete the Event details and invite friends themselves. Great, I hear you say.

Well, being able to create the Event in the beginning and to automatically pass over information from your application to the new Event is going to be a big help to your application’s users anyway.

So, how do you create the Event?

Firstly, you’ll need to have established a valid Facebook session for your application and thereby have caused the user of your application to log into Facebook and grant your application access to their profile and information.

Here’s a previous post with a working example and video tutorial link if you haven’t gotten this far…

Then, you’ll need to firstly create the Event data that is needed to set up the Event – of class CreateEventData:

Code:

OK, let’s go through the above:

• name is clearly the name of the Event.
• host is usually the user who has created it.
• locn is the location of the event – this can be freeform, such as “my office”.
• desc is a description for the event – not essential but it makes sense!
• city is going to have to be a valid town or city. If not, Facebook will try to guess what you meant and come up with the closest match – can be fun!
• UTCstart and UTCend are UTC versions of the start and end datetime values – both Date variables

Calculate values for these dates so:

Code:

• “OTHER” is the category for the Event. Facebook has numerous predefined categories and the one you use has to be valid.
• The ” ” empty String after “OTHER” is the sub-category.

See here for more about category and subcategory values…

I’ve found that ” ” works too for subcatgegories, should you not find a predefined one that fits your needs.

• The null values are those parameters which are not absolutely required to create an Event.
• privacy is an interesting one. When an Event is created in Facebook you have a choice of privacy settings – OPEN, CLOSED or SECRET. In my opinion there’s not much point of specifying anything other than OPEN when creating an event via the API as there are no attendees at the point of creation anyway! Add to that the fact that only the user who created the Event will be able to see it and all is fine.

The user can then set the appropriate level once they have added attendees in Facebook.

Once you’ve created the CreateEventData you can call the API method to create the Event itself:

Code:

That’s it!

in the eventCreated function you can detect the created Event’s ID or dispatch events as needed. Don’t forget to check that the call was successful as per this post.

For more information about the AS3 API CreateEventData class check the documentation here and the general Facebook API notes here.

One important note: If you don’t want to waste hours of testing, wondering why this doesn’t work, make sure that your application prompts the user to grant it extended “create event” permissions when they first use it. the easiest way to do this is to specify the following in the “Post-Authorize Redirect URL” of your applications settings in Facebook:

www. facebook.com/authorize.php?api_key=<your application key here>&v=1.0&ext_perm=create_event

As soon as they’ve given their approval for your application to create events, nothing else should prevent it. Just remember they can always change their minds!

Happy coding!

 

read more | comments off | August 3rd, 2009