We hadn't planned on that for the other streams but I certainly see the benefit. Our original idea was to treat Communications differently since it's a read-tracked queue with the expectation that the user will view every item. For the streams, that's not always the case and the user may only be interested in a subset. But, I can see arguments to the contrary and will discuss it with our designers.
Thanks for the feedback! If anyone else has opinions on this I'd love to hear it too.
Brian when you implemented the new Comms scrolling did you consider anchoring (is that the word?) to the bottom of the thread? After all it is the post at the bottom that has caused the content to appear in Comms.
Alternatively, if you don't auto-jump to the bottom then can you give us a button that allows us to get there. On a long thread it can be lots of thumbing.
And BTW I remember you teaching me ages ago that you can jump from the bottom to the top by clicking the bar with the time, battery level etc on iPhone which I didnt know.. So you can get back to the top in another click in order to continue scrolling. However I can see some possible benefit by 'tailing the thread' with duplicate scroll controls?