Testing the new del.icio.us playtagger - easy streamed audio

23-November-2005

[ middleware2.0 , kind=rough notes ]
This is a test of the new shared javascript from del.icio.us which enhances mp3 links with a lightweight flash object to play the audio, streamed, in the browser, in your page. The enhancement also places a tag-me link to post the mp3 to delicious.

This is just a test of del.icio.us playtagger - the new shared javascript from del.icio.us which enhances mp3 links with a lightweight flash object to play the audio, streamed, in the browser, in your page. The enhancement also places a tag-me link to post the mp3 to delicious.

This could be a great way for ordinary endusers to get the best of both podcasting and in-page playing: posting mp3 files is the open, standards-based way to share audio, allowing real RSS podcasting, permalink-sharing, user-timed listening etc. But some authors like the in-page feature that an embedded flash object provides, and seem unaware of the advantages of simply posting mp3's from the user's point of view. For an example of audio which will play in the page via Flash, but otherwise cannot be used, see this page of 'podcasted' interviews

If this little delicious shared javascript trickery works, it should mean that just attaching an audio file to a knotes blog post makes it playable in the page and usable as a file if the user wants to save it, link to it, or subscribe to podcasts.

I'm attaching a little audio file: please forgive the copyright-busting; if you enjoy it, do by all means look Catfish Keith up and buy some CDs :o)

If this works, you should be able to do streamed listening to the audio attachment (see above for the link - it should have a little arrow nexk to it, like a forward button). I may have to change some templates to get the script include into the head; for this example I'm first trying the script include in the body of this message. I looked over the 3289 bytes of the include and it does not look to me as if it needs to be in the page header.



Mike Malloch; 23-November-2005 08:02:30 forum (0)

A teensy issue to deal with - sidebar collapsed-cookie should hide 'em before they load

07-September-2005

[ dev/knotes/weblogs/features , kind=rough notes ]
I find it annoying that the sidebars are all expanded while the page is loading, and then those which are cookie-d to collapse do so after page load. I recommend having a bit of js-written styling just before the sidebars ( so the main content loads that little bit faster above them ) and having those rules hide the about-to-load sidebar id's.

[ASIDE] - This is an extremely trivial note, of the sort that I write up as firstClass conference messages dozens of times every day. I'm posting it here because I'm trying to experiment with making our development notes more publicly visible, and also because in this case it kind-of documents the sidebar-collapsible feature and some design decisions which other developers ought to know about :O)

I find it annoying that the sidebars are all expanded while the page is loading, and then those which are cookie-d to collapse do so after page load. It makes an odd and suddent transition in what the user sees, and makes 'pre-scrolling' very confusing. In case you didn;t know, the sidebars are each collapsible (click the little box icon to the left to toggle this), and the preferences are kept as a cookie. See the screenshots for before and after views o the sidebars during pageload.

There is no need for this - we could easily set up actual display:none style rules before the page content loads instead of acting on the DOM nodes in javascript after pageload. That is, we dynamically write style rules into a little style block which come above the markup for the sidebars, and which declare that certain of the sidebars have the rule display:none applied to them ( the cookie specifies the id's for the selectors )

There are 2 choices for when/how to create the style rules:

  1. analyse the cookie in zpt at the server, and write in the style rules in the markup, or
  2. write them in javascript dynamically as the page loads in the client but before the sidebars are loaded

Option 2 is best since the cookie only makes sense if js is enabled; otheriwise css-on + js-off could hide content irrevocably

Also ZPT is darned awkward for writing style rules. It is easier to generate css rules as text in javascript and write them into the page than it is to use zpt :O)

I recommend having a bit of js-written styling just before the sidebars ( so the main content loads that little bit faster above them )

I'll do that tomorrow morning.

While I'm at it I'll have an initial look at having the categories sidebar written in js as a tree reflecting the categorical facets hierarchy. We found out today that very long category facet-chains cause a styling glitch in MSIE/win, and I've been meaning to make a js at clientside tree render / drop-down render for the categories for ages.

During PageLoad - all expanded After PageLoad - some expanded
Sidebars-Expanded Sidebars-Collapsed


Mike Malloch; 07-September-2005 14:35:26 forum (1)

1 comments.

Latest comment:
08-Sep-2005 09:44 by mmalloch; Done! - Quisker to do than to describe :O)