Summary and Reactions
Doug Kaye
that's good. It gives me the time and and excuse to summarize and
respond with the perspective of the overall ideas.
On Jul 23, 2009, at 4:17 AM, Jon Udell wrote:
> Wow. Evidently not. Problem (for me) seems to be that some controls
> are bound to the list -- follow, subscribe, show -- while others,
> including the one I was wanting, are bound to the right column where
> I don't expect them to act on the list.
There are two problems: (1) There's too much information to display.
I'm not suggesting we get rid of any of if. We just need to figure our
where and when to show it. Previously *everything* about an object was
in the main column and people found it even more confusing than the
current design. Most of you can remember that version. Maybe we need
some way to expand/contract the display as desired. But that brings me
to: (2) We need a designer. And unfortunately we have little or no
money. I've exhausted my meager skills as a UI designer, and trying to
do it as a committee would be a disaster. So if any one you know
someone who would like to take this on for beer money, let me know.
Oh, they have to be good, too. (High on the list will be to make a
link to a program's feed more obvious.)
On Jul 23, 2009, at 4:31 AM, Thilo Planz wrote:
> I think we should take this chance to re-think the following
> collections feature...I propose that we remove the feature to add
> whole collections automatically...I am thinking that you can follow
> a collection, and it would just count that. It would not add
> anything to any collection, in fact you do not need to select a
> target collection when following. This works just like "digg"ing a
> story. We would need to work out how it differs from the rating
> feature, though. Maybe we could combine these two; no following at
> all, use the rating data for this : "these users like this feed (3
> stars or more)"
Maybe I'm missing Thilo's point here, but if Following a collection
doesn't *do* anything, why would you Follow one?
Idea: When you follow a collection or subscribe to a feed, suppose
there was an option that implied "Keep the <#> most-recent programs
from this collection/feed in my target collection." When we received a
new program from the source collection feed, we'd add it to your
collection. If after doing so there was more than <#> episodes from
that source, we'd remove the older ones. If you've already downloaded
them from your collection's RSS feed, you'd have them. No problem.
(And they would still be in your History collection.) Used this way,
your collection would automatically prune itself. And you could set
<#> to any number for each feed you subscribe to or collection you
follow.
On Jul 23, 2009, at 9:54 AM, JulioTijuana wrote:
> It takes several hours for the collection's feed to update on Google
> Reader when you add a feed to the collection.
Outbound RSS feeds are cached for ten minutes, so it could take that
long for a newly added item to appear in your feed. There's a to-do
item to flush that cache and update immediately whenever a change is
made to the feed. (http://bit.ly/11IZrp) The caching is there because
some nasty RSS clients are hitting our servers way too frequently.
On Jul 23, 2009, at 12:04 PM, Ken Kennedy wrote:
> I seem to remember from very early on when I was adding feeds that I
> hit one that didn't import correctly, b/c it included programs that
> were already in the system with another parent. The "dupes" were
> just skipped over. I'm almost positive I remember an email
> discussion with you about this, Doug, but I haven't been able to
> find it today to use as an example.
Your memory is correct, Ken. If you subscribe to a feed that isn't the
first source for a program, you won't get that program. (See http://bit.ly/cCy3r)
> The most recent episode of Dave Slusher's EGC worried me as well, as
> he's actually "transcluding" an episode of Thomas Gideon's "The
> Command Line Podcast". But again, even though it's the same file
> (same download URL for enclosure, even), it's a different RSS item
> guid, so it's coming through correctly.
This is the problem we're *trying* avoid. If multiple sources submit
the same audio file, we're just cluttering up the database with
duplicates. Ratings of multiple copies don't get aggregated. Comments
that should appear together remain segregated. What needs to happen is
to allow multiple sources to submit the same file and have them refer
to a single entry in our database. That's going to require s nasty
database change, but even that won't solve the case of two feed
submitting the same media file using a different URL and GUID.
On Jul 23, 2009, at 2:26 PM, brave1 wrote:
> I think that some way of marking podcasts as listened-to (and a way
> of filtering out listened-to podcasts) would be helpful for my use
> case.
There are currently two ways to do parts of this: (1) rate a program,
(2) Un-Collect a program. One option would be to specify that whenever
you rate a program it is also un-collected automatically. It would
have to be optional, though.
On Jul 23, 2009, at 5:24 PM, Pedro Palhoto wrote:
> Setting up smart playlists in iTunes is time consuming at first, so
> for new users, an iTunes helper plug-in could come in handy.
What would such a plug-in do?
For those who don't know, we're working on a SpokenWord.org/iTunes
syncing tool. It's being discussed here: http://groups.google.com/group/spokenword-itunes/
> I'd gladly pay $15 each month for a service that would solve the
> listening speed issue. I usually get 30 real time hours each week by
> using parallel time. This means that at 1.8x I'd get an extra 24
> hours of content consumed every week.
This is one I can honestly say we won't do. The model of
SpokenWord.org is never to store or process a media file, and that's
quite fundamental to the mission.
On Jul 26, 2009, at 4:17 PM, Ken Kennedy wrote:
> If we had a ratings choice of "no opinion", or "not rated" /
> "NA"...that might work, at least for me. But I just checked, and the
> widget doesn't appear to allow that. It might under the covers
> somehow, though...I don't know the data model exactly.
I've added this here: http://bit.ly/DeS1K
I look forward to your continued feedback and input. This is already
quite helpful.
Thanks.
...doug
Doug Kaye, Executive Director
The Conversations Network
A 501(c)(3) Non-Profit
do...@rds.com
v: 415.868.5461
twitter: dougkaye
facebook.com/doug.kaye
Thilo Planz
> On Jul 23, 2009, at 4:31 AM, Thilo Planz wrote:
>
>> I think we should take this chance to re-think the following
>> collections feature...I propose that we remove the feature to add
>> whole collections automatically...I am thinking that you can follow
>> a collection, and it would just count that. It would not add
>> anything to any collection, in fact you do not need to select a
>> target collection when following. This works just like "digg"ing a
>> story. We would need to work out how it differs from the rating
>> feature, though. Maybe we could combine these two; no following at
>> all, use the rating data for this : "these users like this feed (3
>> stars or more)"
>
>
> Maybe I'm missing Thilo's point here, but if Following a collection
> doesn't *do* anything, why would you Follow one?
Well, it does *do* something.
It does the same thing a digg does on digg.
That information can be used in many ways.
For one thing, we could then show the list of feeds that
a user follows on his profile page.
Every time I want to rate a programme on SpokenWord right now
(and most programmes are not in my queue, they come directly from
iTunes), I have to go to the search page, type the name of the feed
(because the programme itself is sometimes not yet indexed),
click in the result page on a programme of that feed,
click on the programme page on the link for the feed,
and then can finally give out my stars.
This is too many clicks, and more importantly also involves the keyboard.
> Idea: When you follow a collection or subscribe to a feed, suppose
> there was an option that implied "Keep the <#> most-recent programs
> from this collection/feed in my target collection." When we received a
> new program from the source collection feed, we'd add it to your
> collection. If after doing so there was more than <#> episodes from
> that source, we'd remove the older ones. If you've already downloaded
> them from your collection's RSS feed, you'd have them. No problem.
> (And they would still be in your History collection.) Used this way,
> your collection would automatically prune itself. And you could set
> <#> to any number for each feed you subscribe to or collection you
> follow.
Sure, that is a way,
but more complicated (UI-wise and on the backend)
than just marking the feed.
I think there is value in keeping the "data collecting" part
separate from the "interesting, automated actions derived from that
data" part.
>
> On Jul 26, 2009, at 4:17 PM, Ken Kennedy wrote:
>
>> If we had a ratings choice of "no opinion", or "not rated" /
>> "NA"...that might work, at least for me. But I just checked, and the
>> widget doesn't appear to allow that. It might under the covers
>> somehow, though...I don't know the data model exactly.
>
> I've added this here: http://bit.ly/DeS1K
This seems to be a duplicate of
http://feedback.spokenword.org/pages/25024-enhancement-and-new-feature-reguests/suggestions/273963-ability-to-withdraw-a-star-rating
> I look forward to your continued feedback and input. This is already
> quite helpful.
Setting up the uservoice forum was a great idea.
Thilo
Thilo Planz
> (and most programmes are not in my queue, they come directly from
> iTunes), I have to go to the search page, type the name of the feed
> (because the programme itself is sometimes not yet indexed),
> click in the result page on a programme of that feed,
> click on the programme page on the link for the feed,
> and then can finally give out my stars.
>
> This is too many clicks, and more importantly also involves the keyboard.
>
>
>> Idea: When you follow a collection or subscribe to a feed, suppose
>> there was an option that implied "Keep the <#> most-recent programs
>> from this collection/feed in my target collection." When we received a
>> new program from the source collection feed, we'd add it to your
>> collection. If after doing so there was more than <#> episodes from
>> that source, we'd remove the older ones. If you've already downloaded
>> them from your collection's RSS feed, you'd have them. No problem.
>> (And they would still be in your History collection.) Used this way,
>> your collection would automatically prune itself. And you could set
>> <#> to any number for each feed you subscribe to or collection you
>> follow.
Actually, I what I could do right now is to set up a collection
and "collect" all my feeds.
I would not subscribe to this collection, since I am already directly
subscribed to the feeds.
I could use that feed to find the programmes I need to rate.
I do not need the option to delete older programmes, because it does not
bother me if the older programmes are still there, the first page
would only show the newest programmes anyway.
My main point was that the existence of this kind of "collection"
dilutes the value of the curated collections.
The "social intelligence" of its collections makes for the value
of SpokenWord itself, I think.
If so, we should strive to ensure that for every programme that appears
in a collection a human being specifically made the decision to put it
there.
Simple RSS aggregation is also a nice feature, but if we have it,
let's keep it apart from the curated collections.
Thilo
Ken Kennedy
On Jul 23, 2009, at 12:04 PM, Ken Kennedy wrote:
> I seem to remember from very early on when I was adding feeds that I
> hit one that didn't import correctly, b/c it included programs that
> were already in the system with another parent. The "dupes" were
> just skipped over. I'm almost positive I remember an email
> discussion with you about this, Doug, but I haven't been able to
> find it today to use as an example.
Your memory is correct, Ken. If you subscribe to a feed that isn't the
first source for a program, you won't get that program. (See http://bit.ly/cCy3r)
Contact info: http://kenzoid.com/me/contact
Thilo Planz
> > I seem to remember from very early on when I was adding feeds that I
> > hit one that didn't import correctly, b/c it included programs that
> > were already in the system with another parent. The "dupes" were
> > just skipped over. I'm almost positive I remember an email
> > discussion with you about this, Doug, but I haven't been able to
> > find it today to use as an example.
>
> Your memory is correct, Ken. If you subscribe to a feed that isn't the
> first source for a program, you won't get that program. (See
> http://bit.ly/cCy3r)
>
>
> In that case, I'd never use SpokenWord as a front-end to any
> podcatcher/iTunes, and wouldn't suggest that anyone else do it either.
That is a bit harsh (though I agree that it is a problem).
Note that this is only an issue with subscribing feeds through
SpokenWord, instead of directly from the source.
It is not a problem with collections.
> The aggregation of ratings data for individual programs is great and
> very useful, but this behavior wrt feeds is broken. I could never rely
> on it...a feed could "lose" programs just based on the order in which
> various feeds were submitted to SpokenWord.
A temporary remedy (that Doug could implement) would be to just redirect
to the source feeds and not use the (lossy) internal Spokenword
reconstruction.
We would not have Spokenword meta-data in those feeds (at least for the
time being).
Thilo
Thilo Planz
>> first source for a program, you won't get that program. (See
>> http://bit.ly/cCy3r)
>>
>>
>> In that case, I'd never use SpokenWord as a front-end to any
>> podcatcher/iTunes, and wouldn't suggest that anyone else do it either.
>
> to the source feeds and not use the (lossy) internal Spokenword
> reconstruction.
On second thought, that would only fix it for iTunes (and other RSS
subscribers). The programmes would still be missing on the Spokenword
page for the feed.
:-(
Ken Kennedy
> > I seem to remember from very early on when I was adding feeds that I
> > hit one that didn't import correctly, b/c it included programs that
> > were already in the system with another parent. The "dupes" were
> > just skipped over. I'm almost positive I remember an email
> > discussion with you about this, Doug, but I haven't been able to
> > find it today to use as an example.
>
> Your memory is correct, Ken. If you subscribe to a feed that isn't the
> first source for a program, you won't get that program. (See
> http://bit.ly/cCy3r)
>
>
> In that case, I'd never use SpokenWord as a front-end to any
> podcatcher/iTunes, and wouldn't suggest that anyone else do it either.
That is a bit harsh (though I agree that it is a problem).
Hope that makes it a LITTLE less harsh. *grin*
Thilo Planz
>> > the
>> > first source for a program, you won't get that program. (See
>> > http://bit.ly/cCy3r)
>> >
> mileage may vary. I'm all about choice; I'm just personally not interested
> in dealing with those edge-case scenarios...I've already had the issue come
> up.
I wonder with how many programmes/feeds this (different feeds including the same
enclosure) has happened?
FWIW, we also have the opposite effect (the same programme appearing
in separate feeds) with the TWiT network programmes.
They are all both in the network master feed and in the individual show feeds.
http://www.spokenword.org/program/376912
http://www.spokenword.org/program/377891
I suppose that they have different download URL.
If they did not, and programmes on TWiT would sometimes appear
and sometimes not, depending on which source was scanned first,
that would have been nasty...
Thilo
Ken Kennedy
I wonder with how many programmes/feeds this (different feeds including the same
enclosure) has happened?
Dunno, but it has happened to me. Again, not to sound harsh, but even one disappearance is too much for me. I'd like to avoid dupes as well...but you don't LOSE anything with a dupe. You can even (with some work) fix the duplication, merge the ratings and comments, etc. Nothing is "gone".
FWIW, we also have the opposite effect (the same programme appearing
in separate feeds) with the TWiT network programmes.
They are all both in the network master feed and in the individual show feeds.
http://www.spokenword.org/program/376912
http://www.spokenword.org/program/377891
I suppose that they have different download URL.
Nope!
TV:
http://www.podtrac.com/pts/redirect.mp3/aolradio.podcast.aol.com/twit/TWiT0206H.mp3
(full enclosure element:
<enclosure url="http://www.podtrac.com/pts/redirect.mp3/aolradio.podcast.aol.com/twit/TWiT0206H.mp3" length="53482544" type="audio/mpeg" />
Twit:
http://www.podtrac.com/pts/redirect.mp3/aolradio.podcast.aol.com/twit/TWiT0206H.mp3
(full enclosure element:
<enclosure url="http://www.podtrac.com/pts/redirect.mp3/aolradio.podcast.aol.com/twit/TWiT0206H.mp3" length="53482544" type="audio/mpeg"/>
The items have different GUIDs, however
TV:<guid isPermaLink="false">6907 at http://twit.tv</guid>
Twit: <guid isPermaLink="false">twit-206-mold-happens</guid>
What's happening (it looks like to me), is that we're conflating a couple of db entities here. There's the "item", which has a guid, and an enclosure for the download, and ultimately, mean the same program. BUT...the actual file (which, at the end of the day, IS the program...that's what you're listening to) is referenced ultimately by the enclosure element's URL, which is the same here. However, there are tricky issues with people reusing filenames, etc. in the enclosure urls...I know Doug has been trying to catch those.
So ideally, you'd like to automatically "know" that these are the same thing. (why rate the same program as two different things?) The crappy thing is that it's really tough...the item pubdate is different, the guids are different, etc. Really the only thing that you can rely(?) on in the feed is the enclosure url and the enclosure length (which is supposed to be required, but I've seen feeds that set them all to 0, for example) match. One _could_ say that enclosures with the same url and same length are the same, even if they're in different items, in different feeds. You might get some false matches, but I don't think there's any way to do this without getting false matches, dupes, etc. somewhere.
If they did not, and programmes on TWiT would sometimes appear
and sometimes not, depending on which source was scanned first,
that would have been nasty...
Agreed. Again, though...we're defining some entities wrong in the db if there's even a chance of that happening. An item in a feed is an item in a feed, and even if 100 feeds carry the same item, every feed should still maintain a reference to it if they are rebuilt out of the db. The "program" only exists once (ideally), so that ratings, comments, etc. all reference the same thing. But feed <item> elements can't belong only to one feed. That's back to why I won't use feeds reconstituted out of the SW db; I don't want to risk losing shows because I don't subscribe to the "right" feed.