Fog Creek Software
Discussion Board




Cute :) but what for?

i sure looks cute ... but as a contributor to the Twiki project ( http://twiki.org ) i wonder if it would not be more worthwhile using and extending an existing system :)

hope you don't mind me stealing your nice clean layout though

Sven Dowideit
Sunday, October 14, 2001

I must admit that this is the cleanest clearest design I've ever seen on a DG!

Adam Curry
Sunday, October 14, 2001

"TWiki is hosted and developed here at the TWiki.org web site. You can surf and add/change content a to get an idea of how TWiki works. Start surfing at the WebHome topic, or learn about the platform in the Welcome Guest. "

But if you click on 'WebHome', you got an error... I think Joel is right... :-)

Wan MM
Sunday, October 14, 2001

4 hours! that's what for! It would take me four hours just to read all the interesting links at twiki.org :)

Joel Spolsky
Sunday, October 14, 2001

yeah, the TWiki.org  is dead due to another exploit on sourceforge,  :(

I understand that having what you want up and running in 4 hours feel great, but you are going  to find yourself re-implementing  / fixing things that others have done before. Thats one of the reasons i mentioned it..

for example, do you have a recent changes page that allows you to find out that i have added to this thread?

I would be more interested if you told us that you had implemented the Discussion board using only CityDesk, but i can't find mention of what you used at all :()


oooo and due to my constant misspellings, I'd like a spell checker too :)

Sven Dowideit
Sunday, October 14, 2001

I'm trying to figure out a way to do "recent changes" that makes sense... the key question, of course, is "recent changes since WHEN?"

The board was implemented with IIS 5.0 ASP pages, VBScript and Microsoft Access for the database.

Joel Spolsky
Sunday, October 14, 2001

Why not just pass a cookie to the user that lists the last time they visited. Then when they visit the page which lists all the topics, it can check whether the topic has been updated since whatever time their cookie contains, and make some marking accordingly. If they don't have a cookie your code could skip this. All it would take would be to add an extra field to the table which stores the thread subjects that stores the time at which the thread was last posted to. Since your index page already has to do a SELECT to grab the subjects, you just grab the latest time at the same time. The only real performance cost is going to be an extra UPDATE everytime someone posts to each forum, but really that's not going to make any difference unless you have a huge table with no indexes.

matt
Sunday, October 14, 2001

I considered that. But ... when do you pass the cookie?

Say you come to the site right now. I have to pass you the cookie because for all I know, you're about to go away. That means that suddenly *nothing* is new to you, and I can't show you a list of what you haven't seen. (Or maybe I can show it to you once, then it is immediately invalid).

Joel Spolsky
Sunday, October 14, 2001

now i'm thinking, maybe you can repress the first cookie with a session cookie.

what a tangled web we weave.

Joel Spolsky
Sunday, October 14, 2001

you don't need to go anywhere near that far.

Ward's wiki give you the choice of changes in the last 24 hours (which for a discussion makes alot of sense), and changes this month..  both of these only list the latest change to any one topic...

and the Twiki does a middle 'ish' variation on that theme

Sven Dowideit
Monday, October 15, 2001

or.... just put a latest change time and author after each topic - i generally look at topics that i posted to, and i am not the last poster..

mmmm simplest thing that works :)

<twiki plug>
I defined a custom search on my wiki topic that shows me the recent changes to topics that my wiki name is mentioned. any topic whithout my name / listed more recently than changes i did recently are probably of interest.
</twiki plug>

Sven Dowideit
Monday, October 15, 2001

Hmm, no, I mean: you set the cookie when you read the index page. In sequential order, the index page first reads the existing cookie (if one exists), so it knows when you were here last, and then while it's generating the page it flags the topics which have changed since your last visit (to the index page) in some way. Then when the page is generated and actually being sent to the user, you set another cookie which just overwrites the current one. With this method, a user can bookmark the index page, and just go every little while to see which topics are flagged (by making them a different color, or bold or something) as being updated since their last visit to the index page.

matt
Monday, October 15, 2001

I think when this was originally considered, the objection was that it was heavy magic, and not particularly condusive to using multiple browsers, multiple computers or other non-linear access methods (all of which are typical of heavily used web interfaces.)

this is an example of why i am biased against developing new solutions rather extending existing bodies of open software... there are very few new, unconsidered ideas, and lots of unfininshed implementations of those ideas.

Sven Dowideit
Monday, October 15, 2001

Joel is right!  ("Howard Johnson is right!" - Blazing Saddles)  This cannot be solved by just setting a single cookie parameter.  Doing so seems like a sexy short term solution but it doesn't allow for changes to accrete over time.

Anon Lover
Monday, October 15, 2001

I should be clear: What I'm proposing is a quick and handy solution for a fairly trivial feature (ie. if it doesn't work because someone switches browsers it's not really going to hurt them, they can still read the forums and they'll probably realize "oh yeah this isn't my normal browser"). Considering that Joel's big thing with this software is that it's not a fully-fledged product and just something he's been able to write very fast (and since his big-fixing time is no doubt spent with real products like Citydesk), just throwing a cookie at someone and parsing it quickly (which does not use any significant CPU whatsoever) is a quick, easy solution that will work for 99% of people using these boards in the manner they expect.

matt
Monday, October 15, 2001

The good news is, I fixed the problem.

Michael Pryor figured out something incredibly smart.

If we change the URL for viewing an topic so that it includes the number of followups, then whenever an topic gets a new followup, it will be listed in blue in your web browser instead of purple.

So now you will see new topics, and topics that have followups you haven't read, in blue. If you've read the entire topic, it will be purple. And it's all done without keeping any state on the server.

Joel Spolsky
Monday, October 15, 2001

When do you pass the cookie?
Every time the site is accessed.

More importantly, what goes in the cookie?

As Joel observed, a simple timestamp won't work.  But two would do the job nicely:

Store two timestamps in the cookie, lets call them:
LAST_TIME and OLD_LAST_TIME

The server also knows two other important values:
CURRENT_TIME and TIMEOUT
Now, every time the user accesses the site do:
1. if CURRENT_TIME - LAST_TIME >= TIMEOUT
    then OLD_LAST_TIME = LAST_TIME
2. LAST_TIME = CURRENT TIME

At all times any messages newer than OLD_LAST_TIME can reasonably be considered to be "new" messages.

Only when the TIMEOUT passes without user activity will the user perceive their new message list being reset.  Picking a good TIMEOUT value could be tricky but values between 1 hour and 24 hours would probably all work well.
The first time a user accesses the site is a special case.  (The user has no cookie).  Just default OLD_LAST_TIME to some time prior to the creation of the site, because the entire site is new to this user.

...correct me if I'm wrong...

Shawn Yarbrough
Monday, October 15, 2001

i think you're right. but tell me if the blue/purple trick I'm doing now doesn't work just as well, without cookies :)

Joel Spolsky
Monday, October 15, 2001

I agree that's a very elegant solution!
Much better than cookies for this purpose.  You posted the URL trick message while I was composing the dual cookie message.

I assume you coded the server to ignore and redirect "old" reply counts in the URL.  For example if I bookmarked this thread when it had 10 replies, it would be nice if my bookmark still took me to the thread later when the thread had 11 or more replies.

Shawn Yarbrough
Monday, October 15, 2001

I think there is one tiny problem with the blue/purple trick.  I don't really know how important it is.

Most web browsers don't keep their history forever.  Over time, old threads that the user has read will go from purple back to blue even though no new messages have been posted in those threads.

This tends to be user-configurable so perhaps the answer for users bothered by this is to increase their browser's history-expiring timeout to some huge timeframe like a year or more.

Shawn Yarbrough
Monday, October 15, 2001



>Most web browsers don't keep
>their history forever. Over time,
>old threads that the user has read
>will go from purple back to blue
>even though no new messages
>have been posted in those threads.

>Shawn Yarbrough
>Monday, October 15, 2001


I'll see you and raise you.  After reading all of the then-current message areas earlier tonight, my incredibly unreliable Windows-based PC* rebooted itself for no compelling reason. 

When I returned to discuss.fogcreek.com, ALL of the links were blue again.

I think the only solution is a complete re-write of this discussion board using CGI.pm


*Windows sucks.

Anon Lover
Tuesday, October 16, 2001

*  Recent Topics

*  Fog Creek Home