I love the training concept, and I’ve been using it heavily. However, I’d like to see more fine tuning or customization of the algorithm that’s used. It appears that if a given article has 3 tags “red” and 1 tag “green” it still categorizes as a green article. I’d really like if it only showed articles with a net-positive, or at least a way to define the behavior. Any chance of that?
11 Likes
I would definitely like to see something like this, too!
Yeah, we’ve had discussions about net-positive vs. green-takes-all. It comes down to the fact that because you chose to subscribe to a feed, you probably want to read it. So green takes all.
1 Like
Funny thing is that it would be a 2-3 line code change to make it work the other way. This is 100% a design decision.
My take on this is that, if I subscribe to a feed, I want to read *some* of it. The only feeds I read every single post of are comics and some low-volume UI showcase blogs.
Everything else has varying degrees of things I don’t care about in any way (especially any of the Gawker blogs - there are always some gems, but also a loooot of …not gems).
In the case of tag color conflicts, making them yellow seems like a reasonable compromise.
Yeah, my usage is a lot like that too. I’d like to use the training tags to filter out topics I don’t care about as much as I use it to feature topics I do care about, but it doesn’t work so well, since there is so often topic overlap on high volume feeds.
I agree with Karen though, making mixed-tag articles yellow would be nice. 
Too bad I’m not willing to introduce more colors. Like orange or light green. I always wanted a 5 point scale: -2, -1, 0, +1, +2. The 2’s were for consensus and 1’s were where disagreements went, with ties going to the runner (green, of course). Maybe this is what we really want. +2 would just be a deep green, and -2 a [barely] deeper red.
But the intelligence slider/control would suffer greatly, unless I just kept it to the standard -1, 0, +1, and both +1 and +2 would show up on the +1 setting. You’d see the stories, but they would be differentiated by the intensity of the color. Hmm.
Has any more thought gone into this? It remains a daily annoyance, and really prevents the intelligence trainer from being as useful as it otherwise could be. Many high-volume feeds tag their posts extensively, which means I might have as many as 7 “red” tags but 1 “green” tag on a given post.
I think the problem is that as it stands, a green tag indicates a tag or topic your are interested in, but a red tag is effectively meaningless if, like me, you use green tags to pare down a high-volume feed. The only alternative I can think of is to switch to using only red tags, so that I can exclude items but not prioritize items (since prioritizing would negate any red tags I’ve had). This forces me to “black list” topics instead of “white listing” them. This, in turn, doesn’t really get me any closer to what I want, which is a system by which I can prioritize some tags, ignore some tags, and have a pool of posts for which I have not expressed an opinion.
This is definitely something I still want as well! Gets me all the time…
Would a simple majority, with tie going to green, work? Every match = 1 point. Title, tags, author, publisher.
Yes, absolutely!
Yes, that’d be precisely perfect!
Hi,
I totally love the training based on tags/authors/etc. as it reminds me of the old sort by magic feature on Reader but on steroids.
I was going to post this in a new thread but saw this here, so would just like to say I would love a bit more information on how many tags had been hit by a story, possibly using colours to indicate as suggested above.
Not sure how you would display this, but just an idea.
As an aside, how about being able to sort based on how many shares etc on newsblur/facebook/twitter an article has had so you can see what stories are really hot?
Thanks for all your work,
Neal
Ooh, I just saw on the dev version, when you go to the statistics per blog, you can see the number of people who have liked or disliked specific tags. If you were to use this to count the total number of tags hit by each article you could use that to try and recreate the old sort by magic feature.
Say a blog has the following tag-like profile
cats: 10 likes
dogs: 8 likes
trees: 5 likes
rocks: 1 like
Then an article tagged dogs, trees, rocks would get a score of 14, one about cats and dogs would get 18, etc.
You could then use this to do a sort by score…? Maybe?
The trainer can definitely use more intelligence. Im not entirely sure how and what but the current impletation does not serve a selling point of the service.
Is there any hope for movement on this suggestion? I get hit all the time with something in green when it really should be red or yellow. Red + Green should equal yellow, ideally…
I made that green rules decision a long time ago and I’m still quite pleased with it. Remember, by subscribing to a feed you are implicitly saying you want to read it. So a green wins out every time.
But if there’s a post in that feed with 3 reds and one green, it shouldn’t show up in green. For instance, if I like a particular author but hate 3 topics that she occasionally writes about, I don’t want to see her posts on that, even if I have given her as writer the thumbs up.
For what it’s worth, I still totally agree with Karen. I subscribe to Kotaku because I “want to read it”, but I routinely see posts in the green category that have (I kid you not) 13 red tags and 1 green (I am not a fan of sports games, it turns out).
I think the problem is that the yellow category (or… gray now I guess?) as it is now just means “You haven’t trained this”, and red means next to nothing (on any feed I actively red/green tag, the odds of a pure red are incredibly small).
Of course, if I had know all this beforehand I would have done the thing that actually works pretty well: never green tag and only red tag. Using negative filters exclusively allows you to actually use negative filters, whereas trying to use both results in only being able to use positive filters. The More You Knooooow.
1 Like
The real problem is that this it too late to change. A bunch of apps have this logic built in. And unread counts are computed server-side, so I’d have to recompute site-wide unread counts, which would mess up everybody’s counts for a day. It would be madness, and then I’d have to figure out how to get that logic on ios and android (and the third-party clients).