
Long player - bootload
http://www.roughtype.com/archives/2007/05/long_player.php
======
ralph
news.yc really needs the ability to add a descriptive sticky first comment
along with a URL otherwise the RSS feed, and this page, has bugger all on it
to know whether to click on the link or not. Yes, this is already on the
Feature Requests page. I'm just letting off steam.

~~~
bootload
_'... news.yc really needs the ability to add a descriptive sticky first
comment along with a URL otherwise the RSS feed, and this page, has bugger all
on it to know whether to click on the link or not ...'_

To expect the submitter to do this is ideal, but not scalable. (I know I've
tried to add comments in articles as I've posted them, but gave up because of
the number I submit. I do read them but now comment sparingly.) There is a
real problem with generating volumes of information quickly. If you want
speed, there is a limit on the amount of _meta_ information a user can
reasonably generate. If you want usefulness, this requires more time on behalf
of users submitting.

Newspapers have this problem and solved it by training news editors to create
_catchy titles_ that neatly summarises the entire article in a small sentence
- maybe even a few words. But not everyone writing articles on the web is
trained in Journalistic techniques, let alone people who read this site. There
is also the other problem when re-phrasing or changing titles of articles.
Mutilating them into something un-recognisable from the original.

This is where the software has to work harder. By supplying users with the
tools to classify, sort and value the submissions with tags, comments,
summaries (already have ranking). I'm thinking here of delicious where tagging
has allowed users to sort quickly by tag, then if they want to add more data
themselves (descriptions, summary). The other way is to gather meta data from
the source document (tags, microformats) where possible (un-likely as it takes
time to process documents to generate useful things like summaries - even
longer for meta data like microformats). Now the question is, _could_ "pg with
news.yc create some tools to help users or process new submissions extracting
meta-data"?

~~~
ralph
If I wanted volumes of information I know where to find it. This is news.yc.
I'm hoping for quality, not quantity, and if that means a 70% fall in
submissions, who cares?

Besides, having the ability to attach a comment to the URL does't mandate
putting anything in it. It's suggestive to the submitter that they should make
the effort though else their submission might not compare well against those
that do.

And if a submitter thinks "Oh, this article isn't really good enough to spend
my time on summarising" then that's a good test of whether they should inflict
it on the rest of us in the first place.

Rant over. :-)

~~~
bootload
_'... Besides, having the ability to attach a comment to the URL does't
mandate putting anything in it. It's suggestive to the submitter that they
should make the effort ...'_

I've tried now to add title + (summary) on the submissions resulting in a
_more_ descriptive subject line. It actually works at the expense of size & a
bit of time. So I have to agree with this bit and have changed my approach.

 _'... If I wanted volumes of information I know where to find it. This is
news.yc. I'm hoping for quality, not quantity, and if that means a 70% fall in
submissions, who cares? ...'_

This is already automated by users in the _news_ link (
<http://news.ycombinator.com/news> ) and for the best articles in the _best_
link ( <http://news.ycombinator.com/best> ) As for me I'd rather more articles
submitted & gain the benefit of the long tail of submissions (lots), let the
brains filter submissions (users) and see the resultant niches of information
pop up instead of just the _hits_ ~
<http://longtail.typepad.com/the_long_tail/2005/07/how_finely_can_.html>

_'... Rant over ...'_

It was a good one, because it made me think about this & in the process solved
a few problems I was working on :)

~~~
ralph
The _news_ and _best_ links don't help avoid the long tail. _best_ is too
static; it rarely changes. And <http://news.ycombinator.com/rss> presents too
much dross. Dross which is hard to for my brain to filter because each item
has too little info so I end up having to visit every thread and then often
each linked external article.

(Thanks for starting to add (comments) to the title.)

~~~
bootload
_"... (Thanks for starting to add (comments) to the title.) ..."_

Believe me it makes a difference & really solves the _crappy title_ problem.
But it can be improved. I haven't used the the rss feed much (
<http://news.ycombinator.com/rss> ) but doing so I found that there is a cut-
off on the browser I use (Firefox = toolbars = bookmarks ) toolbar cuts the
text off at 40 characters. So If the title contains the most accurate info in
the first 40 characters it even works in the RSS feeds (reader) with readers
truncating the rest of the message. The other problem I noticed with the RSS
feed is the transporting you to the direct link, not the news.yc feed which as
the original link in the title. So rule of thumb: good title in 40 char
<http://www.flickr.com/photos/bootload/587744795/>

~~~
ralph
It's unfortunate that some RSS readers limit the amount of displayed text,
e.g. Firefox's menu items.

As for the RSS linking to the external article, the feed has both that URL and
a "comments" URL. Some RSS readers appear not to show or give access to the
comments URL, others do. For those that give both, I choose the comments one
first to get more of a clue as to whether anyone bothered to comment.

There are posts elsewhere about some RSS readers ignoring the comments URL and
what if anything can be done.

