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.

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?

Right. And on the rare occasion where a thread might be archived by someone who hasn't read it yet, wouldn't they ("they" probably being DX in this case) just archive it as "Admin," rather than using their own user id?

In terms of facilitating searches, I'd say that getting the search engine out of beta should probably have priority over writing a threadsuck utility.

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.

Sure you are -- "That post needs a good Nillying!"

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.

What about the pending request for one to be able to mark posts unread?

Right. And on the rare occasion where a thread might be archived by someone who hasn't read it yet, wouldn't they ("they" probably being DX in this case) just archive it as "Admin," rather than using their own user id?

I've been archiving using my Lt. Charpe ID. If the threadsuck leaves in all the extraneous admin links and stuff, as a direct download of an entire Phoenix thread does, archiving while having admin privileges would really leave the thread looking kind of messy, all those delete and edit links on every post, etc.

What about the pending request for one to be able to mark posts unread?

That would help matters, though it would still be problematic after the fact. Say a person's read up to post 7386 and they threadsuck when it's reached 7621. After they've done so they realise that the facility has now marked all their posts as read. How do they work out where they were up to, in order to mark the right posts as unread?

The read/unread thing is primarily a placemarker. I don't think it's reasonable to move that placemarker for anything other than posts actually being read.

How do they work out where they were up to, in order to mark the right posts as unread?

Using the back button.

Honestly, people seem to skip ahead and go back quite a bit, and it's not hard. Not taxing on the server either.

Using the back button.

That kind of presupposes they're still have the same session loaded up. There's no reason to assume that the person is planning to go on to read posts at the same time as their threadsucking activities.

I'm aware we're talking about a smaller subset of likely usage here. But I think that's the case either way. I would expect most threadsucking to be done on threads that have already been read to the end. So as I see it, the issue is simply one of flexibility. The only point on which I see the two options differing in any significant way is the ease with which a person can replicate the option they personally favour.

Honestly, people seem to skip ahead and go back quite a bit, and it's not hard. Not taxing on the server either.

How much do you actually expect to save off the bandwidth from having the threadsucker mark posts as read? Do you really expect it to make any sort of noticeable dent in usage? I'm having trouble imagining it wiping even a percentage point off current usage.

Honestly, if 95% of people want it to not mark read, then I'm good with it. If 95% of people want it marked read, I'm good with it.

That's my major POV. I don't think a solution that puts more load on the server or uses more bandwidth should be architected for people who don't exist. Once the demand is identified, then sure. But why start out that way if not many people care?