Fog Creek Software
Discussion Board




Some bugs, fixed

I fixed a bunch of the bugs that my faithful readers found in the discussion board. Elapsed time: 2 hours; total time to implement this board: 4 hours :)

Here's what I fixed:
* If somebody typed a really long word, it would screw up the formatting for the whole page. Now it just gets chopped off.
* Email addresses are now optional. Spam-haters, rejoice!
* Paragraphs work better
* Administrators (that is, me) now have a method to delete off-topic postings. This is intended to remove abuse but not to censor.
* We now track IP addresses of posters, which provides a modicum of accountability. Maybe not much, but helpful if someone actually uses this discussion board to commit a felony. (Yeah, right!)
* You can't accidentally post something twice just by hitting Ctrl+R. We'll just ignore it the second time.

Thanks a zillion to everyone who provided feedback in such a short amount of time!

Joel Spolsky
Sunday, October 14, 2001

By the way, there are a few features we're not going to have here:

* HTML will always be escaped. The convenience of using bold or italic or <a> links does not justify the risk of somebody doing something sneaky, like typing <!-- without --> and thus breaking the page. And I don't have time to write a smart parser which would eliminate the risk. That means that URLs are a pain in the buttocks, but there's always cut and paste!

* I'm not going to have threading any more sophisticated than what you see here... again, going for ease-of-use over power!

Somebody asked about the ugly fonts in the edit box. For an explanation of why I always try to use ugly fat fonts in edit boxes, read

http://joel.editthispage.com/stories/storyReader$91

Basically, when editing, it's easier to select characters with the mouse and to see that you didn't make a typo if you have big fat fonts.

Someone else (or maybe the same person) mentioned that it's weird that when you hit "reply" to reply to a thread, the subject line of the thread is pushed through in the URL. Yes, of course, I could pull it out of the database again, but I decided that in this case I would rather optimize and not do another database query. Anyway, since headlines are only used for topics, not replies, in this case the headline is going to be used for display only and there's no risk of the user tampering with the URL.

In general, my approach here has been to go with the HTML flow. I use raw cookies to keep your name and email, instead of keeping users in the database. And instead of keeping track of which postings everybody has seen, I decided to just let HTML do the usual purple / blue thing, thus distributing the load of who-read-what to the web browsers instead of the server.

Joel Spolsky
Sunday, October 14, 2001

Hi Joel

The board looks good. There is a cool regular expression /server side Javascript function that I use in an ASP based forum to recognize URLs and automatically convert them to hyperlinks.

If you would like, drop me a line and I will mail it to you.

Damian
Sunday, October 14, 2001

Awesome. =)

Mark Paschal
Sunday, October 14, 2001

test.

anonymous
Monday, October 15, 2001

Just trying to see what escaping HTML means -- does that mean you ignore anything that looks lkie HTML, you print it as is, or what?

Some tests:

<H3>This might be a heading -- it is surrounded by "real" HTML tags</H3>

&lt;H3&gt;This is enclosed with the & lt thingies&lt; \H3&gt;

Does using an escape character help, like backward slashes in front of the less than sign?

\<H3\>Backward slash escapes\< \\H3\>

Randy Kramer
Monday, October 15, 2001

I guess "escaping" HTML means igoring it.

And, I wish I could edit my posts, either with a preview feature, or just an "edit last post" feature.

Sort of like twiki.  (Which, unfortunately, has been down for almost a week -- SourceForge has failed to restore from backup in a week??)

Randy Kramer
Monday, October 15, 2001

While it would make the interface less 'clean', it would be nice if you noted on the 'new message' page that html will be escaped...that way people (such as myself) wouldn't try to get fancy and put in href's since it won't work anyway and will make the post difficult to read.

You could treat URL's as various non-web applications do, and just look for 'http', when you find it make the whole string a hyperlink. I think it saves people a significant amount of time to be able to click on a link directly from what they are reading. It is also unintuitive not to be able to do so when you are on a web page.

Of course, this all detracts from the 'simplicity' aspect of the discussion board...

Steve Bronstein
Tuesday, October 16, 2001

Nice simple board. Well done.

Dan Petitt
Tuesday, October 16, 2001

In response to:

* I'm not going to have threading any more sophisticated than what you see here... again, going for ease-of-use over power!

There can be a simple threading mechanism using tags(#).

0. Add a field replied_to to your db.

1. Give the user the possibility to reply to a certain message (add a link that contains a msgid or so) and to the main message

2. Start a message with: <a href="blabla#msgid> in reply to</a> that is a link to the message (on the same page)

This solves the problem when In a long thread I want to comment on a specific remark: Readers have to look through all the message to find the context of that remark

When I read this over, it sounds complicated but it realy isn't :-)

Just a suggestion...

Tjipke A. van der Plaats
Wednesday, October 17, 2001

Joel wrote:
> Somebody asked about the ugly fonts in the edit box. For
> an explanation of why I always try to use ugly fat fonts
> in edit boxes, read
>
> http://joel.editthispage.com/stories/storyReader$91
>
> Basically, when editing, it's easier to select characters
> with the mouse and to see that you didn't make a typo if
> you have big fat fonts.

But should it be you who makes that decision, or the browser makers? How will it help people if your page looks different from lots of other pages?

Shouldn't browsers instead be preconfigured with better fonts, or people be taught to make good selections if they have a hard time editing things?

Anonymous Coward
Thursday, October 18, 2001

Anonymous Coward,

If you can do something to make your app better than what is out there, you should.

Who gives a hoot if is it different from the crap that is already available, especially if it is better!

This is what we call progress.

Babak
Thursday, October 18, 2001

> Shouldn't browsers instead be preconfigured
> with better fonts?

Yes, they should. But they're not.

Joel Spolsky
Thursday, October 18, 2001

*  Recent Topics

*  Fog Creek Home