INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: Podcast Titles and OPML  (Read 1240 times)

IlPadrino

  • MC Beta Team
  • Galactic Citizen
  • *****
  • Posts: 496
Podcast Titles and OPML
« on: February 19, 2006, 12:59:41 pm »

It doesn't seem that MC is able to populate the database's feed metadata from feed metadata itself.  I mean:  "rss\channel\title" in the RSS feed http://radio.weblogs.com/0001014/categories/dailySourceCode/rss.xml contains "Adam Curry: Daily Source Code"  Why can't this be automatically put into the "Feed Name" in the "Podcast Feed Properties"?  It would be necessary to be able to override it, but have it default to the feed title if nothing is entered.

Other applications (such as FeedDemon) allow me to enter the feed URL and it "discovers" the rest.

Speaking of FeedDemon, I'm trying hard to make the complete jump to MC.  The purchase of an iPod nano has made me like MC all the more (support is much better - great even - than compared to my Rio Forge).  But I don't want to have to enter all the feeds in manually (I have about twenty I use).  All other podcast aggregrators I've tried allow me to import/export my feeds as OPML.  Please add the functionality to MC so that it lets people make the move into it all the easier.
Logged

Gene

  • Recent member
  • *
  • Posts: 38
  • Mountains Speak to Me
Re: Podcast Titles and OPML
« Reply #1 on: February 24, 2006, 05:57:04 pm »

It doesn't seem that MC is able to populate the database's feed metadata from feed metadata itself.  I mean:  "rss\channel\title" in the RSS feed http://radio.weblogs.com/0001014/categories/dailySourceCode/rss.xml contains "Adam Curry: Daily Source Code"  Why can't this be automatically put into the "Feed Name" in the "Podcast Feed Properties"?  It would be necessary to be able to override it, but have it default to the feed title if nothing is entered.

Other applications (such as FeedDemon) allow me to enter the feed URL and it "discovers" the rest.

We do actually "discover" the name in other circumstances.  For example, from the Podcast web browser, if you click on any sort of Podcast link we discover that, and pop up a subscribe box with the name filled in.  This is our one-click subscription method.

It is only when you "Add a Feed" then fill in the URL that we do not.  I suppose we could wait until the URL entry field loses focus, then read the feed, and then fill in the name.  Then we would also verify that the feed URL was good.  However this leads to a strange delay in the midst of handling a dialog box, which can be rather extended if the URL is in fact bad.  Is this odd delay acceptable?  And if the URL is bad, how do we tell you that?  And what if you are not connected to the Internet at the time?

Should we have a "Check URL" box that pops up a dialog to check the feed and fill in the name?  Should that dialog give you the description, for example?

I have gotten bogged down on the UI issues in this case.  Do you have any suggestions how to handle these issues?

thanks,
gene
Logged

Gene

  • Recent member
  • *
  • Posts: 38
  • Mountains Speak to Me
Re: Podcast Titles and OPML
« Reply #2 on: February 24, 2006, 05:59:29 pm »

Speaking of FeedDemon, I'm trying hard to make the complete jump to MC.  The purchase of an iPod nano has made me like MC all the more (support is much better - great even - than compared to my Rio Forge).  But I don't want to have to enter all the feeds in manually (I have about twenty I use).  All other podcast aggregrators I've tried allow me to import/export my feeds as OPML.  Please add the functionality to MC so that it lets people make the move into it all the easier.

I have written down the OPML import/export on my whiteboard, putting it in the development queue.   It's not at the top of the list, but it is there.  I was thinking that export to HTML would also be nice.
Logged

IlPadrino

  • MC Beta Team
  • Galactic Citizen
  • *****
  • Posts: 496
Re: Podcast Titles and OPML
« Reply #3 on: February 24, 2006, 08:26:57 pm »

Gene,

Thanks for the response.  Here's some more feedback.

The use case of the dialog box is confounded because it tries to do it all-in-one.  Instead, perhaps you could start the "add a feed" with just a box to input the URI.  I also suggest you add a checkbox that says something like "verify the feed before downloading" which lets the user know that MC might have trouble if the feed isn't valid.  Once hitting "OK", the feed gets verified (hopefully near instantaneously) and you can start a new dialog box - populating the Feed Name from the feed metadata as I first wrote about.  This would let users override the Feed Name if they so choose.  This seems an elegant solution because it also lets the user choose not to verify the feed (in what seems to me the rare instance where someone isn't connected to the internet) when they first start.  They'd still get brought to the second dialog box and be no worse for it.

If the above explanation isn't clear, please let me know and I'll describe it with some dialog box mock-ups.
Logged

IlPadrino

  • MC Beta Team
  • Galactic Citizen
  • *****
  • Posts: 496
Re: Podcast Titles and OPML
« Reply #4 on: February 24, 2006, 08:31:55 pm »

I have written down the OPML import/export on my whiteboard, putting it in the development queue.   It's not at the top of the list, but it is there.  I was thinking that export to HTML would also be nice.

Gene,

It is difficult for me to resist getting on my soapbox!  I'll try to be delicate...

Content and presentation should be separated to the greatest extent possible in most applications.  OPML lets the application export the content and then the user is free to create presentations with greater freedom.  It's a trivial transformation to go from OPML to HTML - why make the user succomb to *your* preference for the presentation?

I got a bit passionate about this and became excited by scott_r's MC XML Export plugin.  Unfortunately, he's stopped developing it and without any conviction MC would continue to be able to support robust XML export, I stopped creating transformations from MPL to whatever.

In this instance, it's another example of how MC could be more powerful if the framework allowed for custom XSLT to be applied to the data content (in this case, OPML).

OK...  sorry for the soapbox.
Logged
Pages: [1]   Go Up