3 ms·

While the author proposes a solution, I don't believe his solution would provide the user with any more value from the pared-down stream. Instead, it would just

While the author proposes a solution, I don't believe his solution would provide the user with any more value from the pared-down stream. Instead, it would just minimize the deluge of information. Assuming that one is always interested in the most recent message from a user makes a conclusion that most recent = most important. As we all know from experience that isn't the case. A better solution would systematically rank incoming message types based on prior determinations of importance of related messages (bayesian) and weight can be added to a particular user's messages (positive and negative) to help the cream rise to the top. The addition of collaborative filtering would help those that aren't interested in flagging their own incoming messages (up/down vote) still reap the benefits of the crowd.

philipkd 16y ago
Yes, as I was designing this, I thought, okay, 300 updates becomes ~100, fine. But what happens when I'm on even on more networks, and ~1,000 updates becomes ~300? Would then I need another layer on top of that to further reduce the deluge? Maybe a "pin" and "unpin" feature that would pin these people to the top could work.
- calcnerd256 16y ago
  So what we have is a timeseries of user-post pairs, and we want a good view for that, a UI that scales well to handle pathological cases. I like the idea presented in the article, but, as you mention in this comment, it is only the first step. Perhaps a library for creating good views for this model would be good, and it should have some good primitives. Then people can develop and share new views for social news. The article's suggestion would be one view, and maybe some of these views would compose (i.e., after the transformation from the article, a timeseries of user-post pairs becomes a timeseries of user-(timeseries of posts) pars, where a (timeseries of posts) is presented as the most recent post and a control with the cardinality of the timeseries as its label and a toggle-hide behavior, and that thing fits in the outer UI the way a "post" would.)

philipkd 16y ago

Yes, as I was designing this, I thought, okay, 300 updates becomes ~100, fine. But what happens when I'm on even on more networks, and ~1,000 updates becomes ~300? Would then I need another layer on top of that to further reduce the deluge? Maybe a "pin" and "unpin" feature that would pin these people to the top could work.

calcnerd256 16y ago
So what we have is a timeseries of user-post pairs, and we want a good view for that, a UI that scales well to handle pathological cases. I like the idea presented in the article, but, as you mention in this comment, it is only the first step. Perhaps a library for creating good views for this model would be good, and it should have some good primitives. Then people can develop and share new views for social news. The article's suggestion would be one view, and maybe some of these views would compose (i.e., after the transformation from the article, a timeseries of user-post pairs becomes a timeseries of user-(timeseries of posts) pars, where a (timeseries of posts) is presented as the most recent post and a control with the cardinality of the timeseries as its label and a toggle-hide behavior, and that thing fits in the outer UI the way a "post" would.)