Differing considerations are better spoken for by people who subscribe to them.

I can only cast a vote for my usage, just as you cast yours for yours.

it's because I don't want to (or already have) read them through normal means.

I get the "I don't want to" argument, but If you've already read them, then you shouldn't care one way or another.

Differing considerations are better spoken for by people who subscribe to them. I can only cast a vote for my usage, just as you cast yours for yours.

If we expected the membership to remain static I'd agree with you. But I feel we should put some thought into how others who may not yet be reading this thread will use the function.

For me, the decider is that of the people who would like to mark a thread as read, there exists another, relatively fast and simple mechanism by which they can do so; but for those who would like it to leave the current 'read' status unaffected, there isn't such a simple fix available - especially after the fact.

I get the "I don't want to" argument, but If you've already read them, then you shouldn't care one way or another.

When I've already read them, I don't care what the system sets. When I haven't, then I want them mark read. Ergo, if I were casting a vote (as I did) I'd vote for them to be marked read since there is no situation in which I want them left marked unread.

But I feel we should put some thought into how others who may not yet be reading this thread will use the function.

But if an existing majority uses it one way (which is why I'm speaking only for myself), then why make them do two steps x% of the time instead of one? And that's not counting increased bandwidth and server load. I'd rather tailor the usage to the current users, and change later, instead of choosing a side that makes things inefficient for the majority.

I think this boils down to the following considerations (in order): a) current usage b) bandwidth c) server load d) future considerations. Since there is no obvious overriding IA issue that I can determine.

But if an existing majority uses it one way (which is why I'm speaking only for myself), then why make them do two steps x% of the time instead of one?

Because there exists an alternative for them, but not for the minority.

Honestly, I'd rather write extra code for people who can't use the workarounds that one would use today (which is something else I do all the time). I don't know exactly how much money we have in the bank, but I'd rather the opportunity to lighten the load on the server and the bandwidth we're paying for, if a small enough percentage of people are the audience of which you speak.

Since I can't think of a reason to threadsuck that doesn't involve reading, I say that the sucked thread should be marked read.

Since I can't think of a reason to threadsuck that doesn't involve reading, I say that the sucked thread should be marked read.

Two obvious ones are archiving and facilitating searches.

Since I can't think of a reason to threadsuck that doesn't involve reading, I say that the sucked thread should be marked read.

Two obvious ones are archiving and facilitating searches.

And after either of them is conducted, would the user like to return to those posts and read them in the thread and not in the threadsucked version they've already made for themselves?

The way I understand it, the archiving enables the reading in the archived format, so it's OK to mark the posts as 'read' (because they'll anyway be read in another format, and I don't think anyone would use the 'read' mark on the board to determine which of this threadsucked posts they've already read. Of course, I could be completely wrong). And for search facilities, there's the (still beta, but working wonderfully so far) search engine, which shows the relevant posts fully, so using it doesn't mark any posts as 'read', unless the user clicks on the post and goes to the thread where it appeared. We already have (and beta-ing) the 'search' that doesn't mark anything as 'read'.

What I mean is, I agree with ita and PMoon. And - as a catcher-upper - I like your designing of the threadsuck, Jon.

Sorry for being so word-y and not-to-the-point. I've just finished teaching, which consists of saying the same thing several times in several ways, and I still didn't shake that pattern of speech and returned to be me.

t natter If anyone who knows me is going to wonder here by chance, it's going to be quite interesting for me, to try and explain to them about my grammatical status: "um, yes, I'm a verb. I'm also a noun. On rare occasions, I'm used as an adjective. And sometimes I'm even me. I don't know if I'm a gerund, though, and I don't think it's a good idea to try and find that out." t /natter

And after either of them is conducted, would the user like to return to those posts and read them in the thread and not in the threadsucked version they've already made for themselves?

Well, sure. Neither archiving nor searching implies that you're actually reading the threads then and there. Regardless of when a person then wants to pick up reading the thread, why wouldn't they want to do it onsite?

Otherwise, why bother with the site design as is? What value is it adding if we expect people to prefer reading a threadsucked version?

I still don't see any real counter to the point that anyone who wants to mark the thread as read can do so easily, but anyone who doesn't will be shortchanged.