Some of that is already in the "Famous Citizens" section.
As always, if someone writes it up, and there's consensus, I'll stick it in.
Do you have problems, concerns or recommendations about the technical side of the Phoenix? Air them here. Compliments also welcome.
Some of that is already in the "Famous Citizens" section.
As always, if someone writes it up, and there's consensus, I'll stick it in.
OK, I'd like some feedback for threadsuck functionality. My feeling is that we should target threadsucking for offline reading and archival purposes. To that end, the sucked thread layout should be fairly stripped-down, including stripping out all the board-generated links (any links within posts would of course still be included). Here's a sample sucked thread.
Two questions:
1. General comments on the layout?
2. Assuming we put a "Threadsuck all" and/or a "Threadsuck new" link on these "showthread.php" pages (i.e. the pages that contain posts), should the Threadsuck update the thread as "read" for the user? I've been going back and forth on this.
OK, I'd like some feedback for threadsuck functionality. My feeling is that we should target threadsucking for offline reading and archival purposes. To that end, the sucked thread layout should be fairly stripped-down, including stripping out all the board-generated links (any links within posts would of course still be included). Here's a sample sucked thread.
I like the way you think. I tend to agree; if they're threadsucking, you're probably talking about high-volume, which would work better in your proposed format.
I'd vote for the thread itself not to be updated to 'read'. I could see situations where it wouldn't necessarily be the case, and if the person does want to update to 'read', they can do so themselves just by going to the end of the thread at the time, or similar actions. They wouldn't be able to mark the posts back to unread, though. (Well, with bookmarks they can get a similar effect. But it's still not quite the same.)
I disagree with billytea. If I suck the threads, it's because I don't want to (or already have) read them through normal means.
Ooh! I get to be a *famous* Buffista!
t preen
And duh, Nilly is a verb. And noun. And so on. Isn't she already in the FAQ? (If not, I'm SHOCKED! Shocked, I tell you. Dismayed at our lack of thought.)
I disagree with billytea. If I suck the threads, it's because I don't want to (or already have) read them through normal means.
Is that the only way you can see the threadsuck being used?
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.