Re: Perhaps turn the problem around...

Post #258,535 by admin 6/11/06 6:55:04 PM Reply	Re: Perhaps turn the problem around... When you say "which would then join with the datetime mark forum read post", are you suggesting combining this with a forum mark-read, as we have here now? That might work... I'll give it some thought. It's kind of backwards, though. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #258,547 by ChrisR 6/11/06 8:31:30 PM Reply	Just thinking of the way I'd use it.... ...mostly the mark all read works fine for me. What I'd rather have is the ability to mark a thread that I want to remain active, until I get around to reading it. Ok, so I could use bookmarks to accomplish same (or open it in another window for later processing, etc...). Anyhow, that usage pattern would be my more typical case - rather than marking individual posts or threads as read. What I meant by the join is that a post is selected for display within a page based on either (a) being greater than the last marked time; or (b) auto selected for being in the marked for retain as new. Actually, this has little to do with the Read/Unread framework your trying to get going. This is more - keeping returning this post until I mark it otherwise - sticky post if you will. Anyhow, it was just a different angle that I was cogitating.
Post #258,579 by drewk 6/12/06 10:58:23 AM Reply	Seconded For my usage pattern, all I'd want is "Mark forum read, except: ..." So one timestamp for the forum, and a parent post id for threads I want to keep open. === Purveyor of Doc Hope's [link\|http://DocHope.com\|fresh-baked dog biscuits and pet treats]. [link\|http://DocHope.com\|http://DocHope.com]
Post #258,594 by admin 6/12/06 12:43:11 PM Reply	OK, I'll buy that, but... Here's a wrinkle: Let's say you wanted to have articles, as well. These articles would be put under the same categories as regular posts. Does marking a category read mark the threads under an article read as well? Do articles need a separate mechanism for marking read? Etc. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #258,607 by drewk 6/12/06 2:24:11 PM Reply	Just hypothetically, right? ;-) For articles I'd go for the Usenet model of timing them out after a set duration. So <stream of consciousness> any new articles with no comments or with unread comments would be on the "front page". Anything that never gets a comment after x days drops off the front page. If you have unread threads on an article you'd still see the threads but the article would drop off the front page after x days.</stream> Let's see, your front page would have: Recent articles[1] with no comments. Recent articles with unread comments or "saved threads"[2]. Unread comments for non-recent articles. Unread comments not attached to an article. Once an article falls out of the "recent articles" category, I would move any saved threads to a secondary user page. I haven't spent a lot of time thinking through the usability implications, but the implementation doesn't seem too hairy at first glance. [1] Newer than x days. [2] Threads that have been marked as "saved". === Purveyor of Doc Hope's [link\|http://DocHope.com\|fresh-baked dog biscuits and pet treats]. [link\|http://DocHope.com\|http://DocHope.com]
Post #258,609 by admin 6/12/06 2:29:15 PM Reply	Of course not. But you didn't really answer the question. "Recent articles with unread comments or "saved threads"[2]." So how do you know the article has unread comments? The category that the article belongs to hasn't been marked read? That's the question. :-) Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #258,616 by Another Scott 6/12/06 3:26:51 PM Reply	I would mark Articles and Threads separately. So how do you know the article has unread comments? The category that the article belongs to hasn't been marked read? If you're able to keep track of threads and articles separately, you don't need to keep track of things by category. I would have a separate mechanism to expire articles (based on time and/or user action). (I don't know if you even need a "kill it if < x comments" option. You could let new articles simply push it off the page.) I would have the head article of a discussion thread have a link for the article or articles related to the discussion (maybe like what TheReg does at the end of every story, or like what LinuxToday does in their comments). I think you're asking for trouble if you mix them because they're different entities and are generally used differently. I don't think people would want articles to be as sticky as a discussion thread. (Recall lots of discussion on K5 about the Front Page not changing fast enough.) People read an article and are done with it, but may return to a discussion thread a dozen times. In my case, when I see an article that I think is interesting but don't have time to read, I either e-mail the URL to myself, bookmark the page, print the page, or save the page, and move on. I wouldn't clutter up my browser with it. Discussion, though, generally has a timeliness aspect to it that an article doesn't. It needs to be quickly available or it'll be lost. To answer your question more directly, if you have categories/forums and a user wants to mark it read, s/he would either mark the articles in the forum and the comments in the forum read separately, or would have a user preference to indicate that when an article is marked read, the discussion is marked read too. (IOW, the articles in the forum would be treated like one Usenet group and the discussion in the forum would be treated like a separate Usenet group as far as marking things read go.) I don't think I like the Slashdot/K5 model in which the discussion is hard-wired to the article. It doesn't lend itself to free-form discussion like we have here. Having a softer link between an article and its discussion would help preserve the atmosphere that thrives (to some extent ;-) here. The beauty of your forum software is that it's nicely threaded, fast, NASA-quality, and cleanly laid out. Try not to make it too general too soon. :-) My $0.02. Cheers, Scott.
Post #258,624 by drewk 6/12/06 3:55:59 PM Reply	I see your point about linking discussion to articles ala /. That's what I meant about the intent of the site. If you see a site as mostly free-form discussion, like here, then articles are an exception. For something like LinuxToday or The Register, the articles are the focus. And to the extent that discussion stays reasonably on-topic for the article that spawned it, it will naturally age out as new articles take focus. That's why I suggested a configurable interface, depending on the focus of the site. === Purveyor of Doc Hope's [link\|http://DocHope.com\|fresh-baked dog biscuits and pet treats]. [link\|http://DocHope.com\|http://DocHope.com]
Post #258,633 by admin 6/12/06 4:51:13 PM 6/12/06 4:52:25 PM Reply	Why not both? We basically have both here. Sometimes someone just starts a discussion. Other times they post a link to an article and that starts a discussion. I'd like to formalize that second form. So basically you'd have the standard, always-there categories: Open, News, Politics, etc. Then you'd have an article that someone posts under some set of categories. This article can then have it's own collection of threads, which would "live" under the same categories that the article is posted under. There's no reason at this point not to support journals and private messages using the same framework. My current thinking is this: newsreader-style tuples to track read status on a per-post basis mark a post ID as "first of the current posts". This gets moved up every week, and everything before that ID is considered 'read' no matter what, unless someone has marked it as 'saved' for themselves. This keeps the querysets manageable. Trim up the read-tuples whenever posts are archived. The alternative is to use the current system of marking a category read and allowing saved threads. Article threads would get marked read along with their categories in this approach. Although you could do the same retire trick on old Articles and allow them to be marked read the same as a category. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..." Edited by admin June 12, 2006, 04:52:25 PM EDT Expand All History
Post #258,639 by drewk 6/12/06 5:09:42 PM Reply	What exactly happens each week? Do you pick a date for all users and anything before that which hasn't been explicitly saved rolls off? Or each week you find the oldest unread item for each user and set that as the "mark read" date for the category? I like the second, but I think you're talking about the first. The thing I don't like about that is that I could be away for a while, and when I come back I'd want to see the same state as when I left. (Plus new items of course.) I'm not sure how my preference would affect the queries you're doing. As to "formalizing" the articles, I'm thinking the same thing. But for it to be meaningful, I think you'd have to have some sort of restriction on who can post an article. Whether it's a user-filtered queue ala K5, editorial selection ala /., or list of approved editors ala IWE or other trade pubs. In one sense it's just another launch point, but there has to be some exclusivity to it or it's useless. That's why I suggested three different types of main page. Right now we're a free-form site. Someone using this software for a site like The Register or LinuxToday would want something that sees the article as the main thing, but with richer discussion than they have now, and a place to put open content. === Purveyor of Doc Hope's [link\|http://DocHope.com\|fresh-baked dog biscuits and pet treats]. [link\|http://DocHope.com\|http://DocHope.com]
Post #258,644 by admin 6/12/06 5:19:59 PM Reply	Re: What exactly happens each week? The idea is that posts older than say 6 months would be archived. Mark read tuples are the user ID, the begin post ID of the tuple, and the end post ID of the tuple. If a post's ID is within a tuple's range and not in a save list for the user, it's considered 'read'. So each week: Figure out the highest post ID older than 6 months. That becomes the new limiter ID. For each user, delete all read tuples where end_post_id <= limiter. If a tuple remains that has begin_post_id < limiter, set begin_post_id = limiter. Now all queries looking for unread posts do two things: add a where clause: id > limiter look in the read tuples for that user to make sure it isn't marked read look in the saved list to see if it's saved anyways. For the alternative, each category and article gets a mark read date per user. Then the articles go through the same aging process (but probably something more like the last 50 articles, or whatever) and the mark read stamps get pruned accordingly. And actually what I'm talking about with respect to articles is original content (like one of Andrew's amazing culinary discussions) with trusted users and possibly submission queues. Links to outside articles would have a submission queue as well, with a link and a fair-use quote. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #258,736 by drewk 6/13/06 9:00:48 AM Reply	Guess I was being pessimistic Not having done the math, I didn't think it would be practical to actually keep the tuples you describe for all users for any useful length of time. Now if I'm reading you right, 6 months becomes a hard limit, and if you're away longer than that you lose your history? Seems like plenty long enough to me. I'm just surprised that you can keep tuples that long for the number of users and posts you cite without killing performance. === Purveyor of Doc Hope's [link\|http://DocHope.com\|fresh-baked dog biscuits and pet treats]. [link\|http://DocHope.com\|http://DocHope.com]
Post #258,740 by admin 6/13/06 9:24:21 AM Reply	Tuple space depends on holes. If people don't reliably mark everything read, then the tuple-space will grow very large. However, I think most people keep up-to-date on that sort of thing, but yes, this sort of system can develop some pathological behavior. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #258,635 by admin 6/12/06 4:57:03 PM Reply	On making things general: This is a prototype. I'm past that point now. :-) Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #258,674 by Another Scott 6/12/06 7:46:52 PM Reply	I hope I haven't seen the GUI already. [link\|http://thedailywtf.com/forums/thread/77174.aspx\|FileMatrix]. ;-) Cheers, Scott.
Post #258,678 by admin 6/12/06 9:13:14 PM Reply	My God, it's full of... SCGUI. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #258,689 by Another Scott 6/12/06 10:22:17 PM Reply	:->
Post #258,622 by drewk 6/12/06 3:46:20 PM Reply	I told you I didn't think before typing, didn't I? But to answer your question, if "Category" means the same thing as "forum" does now, then yes, any articles under ... wait ... new thought coming in ... Does an "article" really need to be a different kind of thing? Or rather, what kind of thing does it need to be? Is it simply the root post of a thread, with the special behavior that it disappears within x days if there are no comments? Or is it a sort of ad-hoc category in its own right, with the first comment being "level 1" within that category? (I'm not talking implementation, but conceptually.) I'm still thinking through this as I type, but I'll throw my current thinking out in case it triggers any flashes of inspiration. Let's say you have categories. Within each category, you can have articles and "unassociated" threads. Internally you maintain an "Open Topic article" for each category, which the "unassociated" threads actually descend from. The display can be admin- or user-selected to be one of three styles, depending on forum type and traffic: Only articles on the front page. "Open Topic" is listed as the last article on the page. All articles show an "Unread Posts" count. (Non-logged-in users would just see "Posts".) Open Topic shows "X Unread Posts in Y threads". To create a new open thread you have to click into the Open Topic article first. Articles (except for Open Topic) drop off the front page after x days. After "Articles" on the front page are the unread second level threads under the Open Topic article, each appearing as a top-level article. All topics and Open Topic threads show "Unread Posts". (Or "Posts" when not logged in.) There is a "New Topic" button at the top of the page that adds an "Open Topic" thread. Articles drop off the front page after x days. Similar to option 2, but show all unread threads expanded. I would expect a default view of type 1, so new users would see recent articles. Occasional users might choose option 2 so they can always see what's recent. Daily users would like option 3, which is essentially what we have now. I would think under options 1 & 2 if you are viewing an article "Mark All" should work at the article level, which means all threads under the Open Topic would roll up under a single date. Under option 3, or when viewing the front page under options 1 & 2, "Mark All" would work for all articles in a category. Basically "Mark All" applies to whatever level you're looking at. This might mean setting dates for every top-level article in a category, or having a separate date field at the category level, depending on performance / optimization issues. === Purveyor of Doc Hope's [link\|http://DocHope.com\|fresh-baked dog biscuits and pet treats]. [link\|http://DocHope.com\|http://DocHope.com]
Post #258,637 by admin 6/12/06 5:01:37 PM 6/12/06 5:02:29 PM Reply	The trick is size and performance... Settle down, ladies. I'm using 250K users and 1K posts/day as my benchmark. Size calculations follow from there. Most of this is stuff I'm already thinking of doing, at any rate. I'm trying to lead discussion here along without saying too closely what I'm thinking of in order not to prejuidice the discussion. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..." Edited by admin June 12, 2006, 05:02:29 PM EDT Expand All History
Post #258,640 by drewk 6/12/06 5:11:35 PM Reply	You mis-spelled "laddies" === Purveyor of Doc Hope's [link\|http://DocHope.com\|fresh-baked dog biscuits and pet treats]. [link\|http://DocHope.com\|http://DocHope.com]
Post #258,658 by ben_tilly 6/12/06 5:59:44 PM Reply	ICLRPD (new thread) Created as new thread #258657 titled [link\|/forums/render/content/show?contentid=258657\|ICLRPD] I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
Post #258,843 by static 6/14/06 1:04:39 AM Reply	Thoughts about articles... Perhaps rather than considering articles a special type of thread, an article is instead a type of forum? (Much like how the Forum Guidelines here has an 'article'.) You may want to have a tree-structure for forums, in that case. Otherwise you end up with the problem that we had on EzBoard with my Static Page: an ever-growing list of forums. :-) Of course, that means that the current mechanism for marking forums read would continue to work on a per-article basis, but the storage will expand proportional to the number of articles/forums times the number of users. (You could take shortcuts if you allowed a forum's unread status to override sub-ordinate forums.) This doesn't get you to marking individual messages read, I know. Wade. "Insert crowbar. Apply force."
Post #258,860 by admin 6/14/06 8:26:35 AM Reply	That's how I've been thinking about them. Dunno about the rest of these yahoos, though. ;-) Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."

Welcome to IWETHEY!