I'm thinking that clicking on the Mark should cause the reset since everyone has that available, while only Premium users can click on the NewPost counter?
That's true only of PeopleMarks, right?
SubjectMarks: Clicking on NewPosts clears the counter. Clicking on the SubjectMark does not clear the counter.
PeopleMarks: Clicking on NewPosts does not clear the counter. Clicking on the PeopleMark clears the counter.
A case can be made for it to be appropriate to work that way, and I think it was probably intentional based on my own usage patterns. But it's very easily changed if the consensus leans one way or the other. I won't be making anything else user-configurable for a while until I do a rewrite of user-config, including db structure.
My usage pattern is that if I click the subjectmark, I might not necessarily be reading the posts. I might just be looking to see who's posted there. And if I do decide to read, I've got "Mark as Last Read" available to me while reading.
However, if I click a peoplemark, though there's a "Mark as Last Read" there, it doesn't work in the "Person" context. Which should be changed. Or the option shouldn't display if the below is true.
I was thinking I had it set up so that if you click NewPosts under Peoplemarks, the counter was decrementing with each "Next". Not so?
Probably would be easiest to just have both clear the counter. We had a very long and drawn-out discussion on the workings of this on iHub a long time ago and opinion was split right down the middle as to whether clicking the Subject/Personmark should clear the counter, so either way, half the people won't like it. There were also a lot of people who wanted it to work in a way that the counter was changed on each read (in a Subject), but that threw in the problem of perhaps having hundreds of unread posts in a thread that you wanted to later read, and a link in another post took you to the last post in that thread and reset your count. Which is what gave birth to "Mark as Last Read", and no while-reading decrementing taking place.
However we approach it, I want it to be very cut and dry and simple. And not put any extra cost into readmsg, which is by far the most frequently-used routine. |