So, last night, I took some time to add a bunch of items to my internal bug tracking system for SlackerTalk (the Mantis system I referred to earlier)
Posted by
Beryllium (aka grayman)
Dec 9 '09, 15:11
|
There were about 14 feature suggestions and bugfixes from my own notes that I want to look at.
Something similar to what Mop is talking about is included, based on an email he sent me several weeks ago (and based on my early planning for the Favourite flagging system), but there's no plan to make it as integrated in the main board interface (the jumper bar filter) as Mop is suggesting, and it will be a long time before I consider making a user-fed flag input box.
As long as I stick to defining the flags myself (currently limited to Fave and NSFW), I can modify the system to attach a functional significance to each new flag I add.
For example - what if I added a "Spoils" flag? It could act like the NSFW flag, but if enough people click it, it could block out the subject line with "subject line spoilers" or something. That would be a useful feature, right? But then you have to think about things like ... how would people know what the spoilers were about, before they clicked? And what if it became abused?
So, before I add any new functionality like that, I have to dwell on it and ponder the best way of implementing it.
For Mop's suggestion, of having a filter beside the board jumper, that's technically implementable. I could do that. But then I have to dwell on dozens of questions and coding problems. For example: If a post matches, should the entire thread be shown? Or just the thread from that post down? Or just that one post, thus negating the threaded conversations of ST?
And then we get to how it breaks boards. Right now, "boards" are not some special value calculated by how many posts are returned. It would be nearly impossible to architect ST in that way, because every post can have children, and each post's children affect how many posts are returned per board. No, right now, boards are actually a separate entity altogether. A tangible entity, timestamped, catalogued. To have a "board" concept while at the same time having a "filter" concept would break the display. This is why Search results are not nested; the sheer amount of processing to do that would be overwhelming to the system. I've already had to modify searching several times to prevent it from crippling the server, and that's without nesting.
|
Responses:
|
