Edit: There is a bug in the script (see comments) but somehow Googlecode does not allow me to edit my own file. I will fix it once I got around that issue.The bug reported in the comments is now fixed, sadly enough I also had to re-write the converter as Google code does not allow me to replace an older version of a download (or is there a trick?). The new file is called previewer2.js

As readers of this blog know, I am a big fan of SlideShare as a distribution platform for my presentation slides. However, there are some things that annoy me about it.

One of them is the rather verbose embed code SlideShare offers you:

<div style="width:425px;text-align:left" id="__ss_335941">
<object style="margin:0px" width="425" height="355">
<param name="movie" value="http://static.slideshare.net/swf/ssplayer2.swf?doc=highlandflingbadgesnew-1207296687342384-9"/>
<param name="allowFullScreen" value="true"/>
<param name="allowScriptAccess" value="always"/>
<embed src="http://static.slideshare.net/swf/ssplayer2.swf?doc=highlandflingbadgesnew-1207296687342384-9" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="355"></embed>
</object>
<div style="font-size:11px;font-family:tahoma,arial;height:26px;padding-top:2px;"><a href="http://www.slideshare.net/?src=embed"><img src="http://static.slideshare.net/swf/logo_embd.png" style="border:0px none;margin-bottom:-5px" alt="SlideShare"/></a>
 | <a href="http://www.slideshare.net/cheilmann/building-badges-for-distribution-335941?src=embed" title="View 'Building Badges for distribution' on SlideShare">View</a> | 
<a href="http://www.slideshare.net/upload?src=embed">Upload your own</a>
</div>
</div>

That is quite a mouthful and the main issue is that when you use several slide embeds in one document, you’ll slow down the rendering of your page as each of these Flash embeds need to be instantiated and tries to pre-cache the first three slides from S3.

I’ve analyzed the code a bit, added some other info I found in the RSS feed and came up with a small JavaScript that embeds slides in a different way. All you need there is the following code:

<div class="slideshare">
<a href="http://www.slideshare.net/cheilmann/building-badges-for-distribution-335941#highlandflingbadgesnew-1207296687342384-9">View 'Building Badges for distribution' on SlideShare</a>
<script src="http://chrisslidesharehacks.googlecode.com/files/previewer2.js"></script>
</div>

This gives slideshare the same SEO link love but is a lot less to add. Instead of the full slide include, you’ll get a preview image you can click that gets replaced with the flash movie. The following are examples:

Now, in order to convert one to the other you could do it by hand, or use the slideshare embed converter or install the Greasemonkey script

So far this is a hack, but I talked to Jonathan Boutelle about it yesterday night at the San Francisco JavaScript meetup and he is happy to pursue this idea further. My wishlist:

• A larger preview image
• A rest API call that gives me this information in a readable manner

I just finished my sesssion at BarCamp Brighton about making online video more accessible by allowing for sensible, time-based commenting which could become a poor man’s captioning in a second stage. In general it is just showing off my hack of the YouTube player using their API.

| View | Upload your own

Technorati Tags: accessibility, commenting, hack, slideshare, video, youtube, barcampbrighton, barcampbrighton2, barcamp

Jonathan Boutelle of Slideshare reacted to my slideshare show widget and liked how I hacked around the API by re-using the RSS feed. He now asked in the comments what I’d like to see from an API. Well, here goes:

1. Allow for “hackable” URLs, with definition of the output. Flickr and Del.icio.us are good examples, especially the del.icio.us option of defining a callback for the JSON: http://del.icio.us/feeds/json/codepo8 gets me a JSON data wrapped in a Delicious object, http://del.icio.us/feeds/json/codepo8?raw gets me the raw JSON data and http://del.icio.us/feeds/json/codepo8?raw&callback=foo wraps it in a function call to foo(). This rocks! The same goes for defining the output as the last parameter. Flickr does that well – http://api.flickr.com/...format=json for JSON, http://api.flickr.com/...format=rss for RSS, http://api.flickr.com/...format=lol for LOLCAT
2. make sure that the JSON output is easy to use and does not have any annoying bits (encoded HTML or namespaced attributes – the description property in the flickr JSON to me is pointless weight for example)
3. make the URL as logical as possible, I don’t like to have to use the user ID in flickr for example when the readable user name would be easier to do.
4. it’d be great if you could send a unique ID as a parameter as that would allow you to match returned data to calls (as both dynamically created script nodes and Ajax calls may return in any order)

However, all of this does not replace the real API, which should

1. allow me to define only the data bits that I need (and cut down to the smallest possible feed – no twitter, 150kb JSON is not good!)
2. give me extras when I go through a developer ID. How about offering me free stats (even as an own API) when I build a widget that uses my ID - we do this now to throttle usage anyways. In a second phase this could also be used for a revenue sharing program.
3. offer things like enforced authentication (you know the photos you don’t want to show your mother)
4. allow for local caching methods (deliver the data gzipped for example)
5. allow me access to things that the open REST calls don’t (my sets, my favourites, my contacts, my profile settings)
6. be read and write – I want to build widgets that allow data entry from my blog to your systems, without leaving it.

Anything else?

Technorati Tags: API, wishlist, REST, JSON, slideshare

It is quite cool to see the increase of coverage of the topic of web APIs. It is also very exciting to APIs finally evolving to work across several systems, aggregate and move from a one way stream of retrieving data to an alternative entry point for applications. How cool will it be for example to write reviews for amazon on movie or book sites? Having write APIs would allow us to leverage the knowledge of people on the web at the places they hang out rather than having to lure them into using a web app.

Anyways with this new API interest I had a triple release today: There is a podcast about APIs for .net magazine together with Jeremy Keith, Paul Hammond, Drew McLellan and hosted by Paul Boag, Ajaxian is featuring my ‘hack’ of the Slideshare RSS feed and I uploaded the presentations I gave at the University Hack Day introduction at Dundee, Scotland yesterday.

• Building Web Hack Interfaces
• Introduction to Hacking for University Hack Day

Enjoy!

Technorati Tags: apis, webdevelopment, rss, hacks, hackday, unihackday, slideshare