I am wondering if it is possible for you guys to add threaded view in this forum software? I am in a community where users are accustomed to threaded view and as much as they like this new SMF forum, some are asking if they could get threaded view feature in the forum instead of the current flat view. Is there a possibility that this could be added? Hopefully I have not overlooked this feature in the current version (Version 2.0 3.1 beta).
BTW, this is a very good product as currently designed.
What exactly is "threaded" view?
I don't believe there are any plans to have a threaded view as it would require massive changes to a lot of the codebase.
Quote from: ccbtimewiz on August 13, 2008, 09:08:49 PM
What exactly is "threaded" view?
Check the attached picture of a vBulletin forum which is displaying in threaded view. The user has the option to switch to flat view as used here.
Quote from: Tilla on August 13, 2008, 09:30:02 PM
Quote from: ccbtimewiz on August 13, 2008, 09:08:49 PM
What exactly is "threaded" view?
Check the attached picture of a vBulletin forum which is displaying in threaded view. The user has the option to switch to flat view as used here.
Yeah... it would require massive changes to a lot of the codebase as Dannii said. Maybe you can request this as a mod?
OK, I will see if I can request it as a mod. I am sure you can see the benefit of a threaded view?
One of the reasons I like it is that when you are inside a particular thread, people can be replying to specific persons and that discussion is kept together. This means you do not have to read all the discussions to keep up with someone who is responding to your post or you to them, unlike the flat view as used by this forum.
This is the only thing I see missing from this SMF product. I am sure there are others, but the only change I would like to see for now.
I actually find it very hard to use. I much prefer a flat forum with lots of quoting.
The issue with it is that is would be very bloaty.
The sections affected would essentially need duplicating and rewriting completely.
If you tried to work it into existing functions it would be very heavy and inefficient and slow.
For that reason I find it more likely as a mod.
Not that bloaty, actually. Just a little painful here and there. The blottiest things have to be the extra Javascript (less than a kilobyte), and the extra id_parent field in the smf_messages table. (I don't like adding too much here...)
If you remember, I added that particular feature to my board some time ago -- http://www.simplemachines.org/community/index.php?topic=212576.0 (I even posted a screenshot.)
After the last message in that topic, I modified the Quick Reply feature to actually add a Quick Reply box under EVERY message. Which made it much easier to "build" an actual threaded view.
It worked, really. Very well. I've kept a copy of all the changes I made.
Only, I posted a poll, asking my viewers their feelings about the feature, and only two people shared their enthusiasm -- and that's because they're originally from LiveJournal where threaded view is all over the place.
Everybody else either said they didn't care, or reacted strongly against the feature, saying it would make it more complicated to follow a discussion.
While a threaded view is desireable when you're viewing a topic once and long after it was created (as a guest, from a Google search, etc.), it is not the best possible way to discuss when the topic is active.
Of course, there's always the possibility of not showing any posts, only a complete list of indented subjects, with a "new" icon next to the messages you haven't read yet, and a single click to get to that particular message. But even if using Ajax to retrieve them, that would still require a LOT of clicking, and keeping track of all unread messages, instead of "last unread message"! Oh my, the agony...
Another advantage of threaded views is that you can split a topic with a single click on the parent message that generated a new discussion. That was one of my main reasons for implementing it in the first place, actually.
But threaded view is more or less a thing of the past. More and more people are getting used to flat view. SMF supports backlinks to the original post from within a quote -- as long, of course, as the poster doesn't remove the link itself.
So I ended up removing my code. It just took a few minutes and, although the threaded code wasn't really "in the way", I'd rather not keep unused code in my already messy additional code.
If anyone wants the code, though... Feel free to ask. I'm never going to make a mod out of it anyway (making mods is not my cup of tea), so I might just as well share the code itself, in case someone wants to make a mod.
Trust Nao to do the impossible :P
Lol, it was far from "impossible". The only real thing that I deemed impossible at first, was to add Quick Reply to all posts, because of the overlapping forms. In the end, adding them on the fly via Javascript works fine.
Heck, I should have posted my changes last month, when I *removed* them from my code... It would have been faster and easier than tracking down the changes between an older version of my code and a newer one ;)
I am quite interested in the workings of it. It'd be great if you share it :)
Okay, let's go to work...!!
First of all, add a "id_parent" field to "smf_messages". It shall have the same format as "id_msg", since it will store the same kind of information...
In Post.php, BEFORE "// Start the main table.", add:
if (!empty($_REQUEST['quote']))
echo '
<input type="hidden" name="quote" value="', (int) $_REQUEST['quote'], '" />';
Now go to the Display template...
Add this around the beginning. (Before "is_poll")
if (!empty($context['threaded']))
echo '
<div class="tborder" id="quickreplybox' , $message['id'], '">
<h3 class="titlebg headerpadding">
<a href="javascript:oQuickReply.swap();">
<img src="' . $settings['images_url'] . '/expand.gif" alt="+" id="quickReplyExpand', $message['id'], '" />
</a>
<a href="javascript:oQuickReply.swap(' . $message['id'] . ');">' . $txt['quick_reply'] . '</a>
</h3>
<div class="smallpadding windowbg" id="quickReplyOptions', $message['id'], '" style="display: none">
</div>
</div>';
After "$ignoredMsgs = array();", add:
$increm_list = array();
$increm_list[0] = -20;
$increm_list[$context['first_message']] = -20;
After the "if ($message['id'] != $context['first_message'])" echo sequence, add:
if (!empty($context['threaded']))
{
$increm = $increm_list[$message['parent']] + 20;
$increm_list[$message['id']] = $increm;
}
$sty = $message['counter'] == $context['start'] ? 'margin-top: 0' : '';
$sty .= !empty($increm) ? (!empty($sty) ? '; ' : '') . 'display: none; margin-left: ' . $increm . 'px' : '';
if (!empty($increm))
echo '
<div style="margin-left: ' . $increm . 'px"><a href="javascript:void(0)"
onclick="n = document.getElementById(\'mypost' . $message['id'] . '\'); if(n.style.display == \'none\') { n.style.display = \'block\'; } else { n.style.display = \'none\'; } return false;">Réponse de '
. $message['member']['name'] . ' ' . (is_numeric($message['time'][0]) ? $txt['on'] : '') . ' ' . $message['time'] . '</a>' . ($message['new'] ? ' <img src="' . $settings['images_url'] . '/new.png" alt="New" border="0" />' : '') . '</div>';
(You'll have to replace the "new.png" link, as well as add language strings for "Réponse de" which is French for "Reply by... (author name)")
Now we're starting the main div for each message... Just increment them, something like that:
echo '
<div class="clearfix ', !$message['first_new'] ? 'topborder ' : '', $message['approved'] ? ($message['alternate'] == 0 ? 'windowbg' : 'windowbg2') : 'approvebg', ' largepadding"', !empty($sty) ? ' style="' . $sty . '" id="mypost' . $message['id'] . '"' : '', '>';
Now, right before the end of that main div, add this:
if (!empty($context['threaded']))
echo '
<div class="tborder" id="quickreplybox' , $message['id'], '">
<h3 class="titlebg headerpadding">
<a href="javascript:oQuickReply.swap();">
<img src="' . $settings['images_url'] . '/expand.gif" alt="+" id="quickReplyExpand', $message['id'], '" />
</a>
<a href="javascript:oQuickReply.swap(' . $message['id'] . ');">' . $txt['quick_reply'] . '</a>
</h3>
<div class="smallpadding windowbg" id="quickReplyOptions', $message['id'], '" style="display: none">
</div>
</div>';
Now add the final div.
I usually add a "unset($increm_list);" after the message loop.
In the Quick Reply <form> stuff, I add these among the variables:
<input type="hidden" name="quote" value="" />
Now, AFTER the quick reply code block, I add this:
$a = '';
if ($context['can_reply'] && !empty($options['display_quick_reply']) && !empty($context['threaded']))
{
$a = '
<div class="smallpadding floatleft" id="warning%msg%">
' . $txt['quick_reply_desc'] . ($context['is_locked'] ? '<p><strong>' . $txt['quick_reply_warning'] . '</strong>' : '') . ($context['oldTopicError'] ? '</p><strong>' . sprintf($txt['error_old_topic'] . $modSettings['oldTopicDays']) . '</strong>' : '') . '
</div>
<div>
' . ($context['can_reply_approved'] ? '' : '<em>' . $txt['wait_for_approval'] . '</em>') . '
<form action="' . $scripturl . '?action=post2" method="post" accept-charset="' . $context['character_set'] . '" name="postmodify" id="postmodify%msg%" onsubmit="submitonce(this);" style="margin: 0;">
<input type="hidden" name="topic" value="' . $context['current_topic'] . '" />
<input type="hidden" name="subject" value="' . $context['response_prefix'] . $context['subject'] . '" />
<input type="hidden" name="icon" value="xx" />
<input type="hidden" name="quote" value="%msg%" />
<input type="hidden" name="notify" value="' . ($context['is_marked_notify'] || !empty($options['auto_notify']) ? '1' : '0') . '" />
<input type="hidden" name="not_approved" value="' . !$context['can_reply_approved'] . '" />
<input type="hidden" name="goback" value="' . (empty($options['return_to_post']) ? '0' : '1') . '" />
<input type="hidden" name="num_replies" value="' . $context['num_replies'] . '" />
<textarea cols="75" rows="10" style="width: 95%; height: 150px;" name="message" tabindex="1"></textarea><br />
<input type="submit" name="post" value="' . $txt['post'] . '" onclick="return submitThisOnce(this);" accesskey="s" tabindex="2" />
<input type="submit" name="preview" value="' . $txt['preview'] . '" onclick="return submitThisOnce(this);" accesskey="p" tabindex="4" />';
if ($context['show_spellchecking'])
$a .= '
<input type="button" value="' . $txt['spell_check'] . '" onclick="spellCheck(\'postmodify\', \'message\');" tabindex="5" />';
$a .= '
<input type="hidden" name="sc" value="' . $context['session_id'] . '" />
<input type="hidden" name="seqnum" value="' . $context['form_sequence_number'] . '" />
</form>
</div>
</div>
</div>';
$a = str_replace('\'', '\\\'', $a);
$a = str_replace(array("\n","\r"), '', $a);
}
(a "from_qr" hidden value was added recently for Beta 4, I'm not sure it should be used here as well. Would have to check.)
Now, let's skip to the Quick Reply javascript...
Replace:
sJumpAnchor: "quickreply"
With:
sJumpAnchor: "quickreply"', (empty($context['threaded']) ? '' : ',
sThreaded: \'' . $a . '\''), '
Now, xml_topic.js
Add a new line after this first one:
this.bCollapsed = this.opt.bDefaultCollapsed;
this.bExbox = 0;
Add the first line (and linebreak) below before the two lines after:
document.forms.postmodify.quote.value = iMessageId;
// Doing it the XMLhttp way?
if (window.XMLHttpRequest)
The QuickReply swap function is half-rewritten, so it's best to simply reproduce it completely:
QuickReply.prototype.swap = function (destDiv)
{
if (typeof(destDiv) == 'undefined')
destDiv = '';
document.getElementById(this.opt.sImageId + destDiv).src = this.opt.sImagesUrl + "/" + (this.bCollapsed ? this.opt.sImageCollapsed : this.opt.sImageExpanded);
document.getElementById(this.opt.sContainerId + destDiv).style.display = this.bCollapsed ? '' : 'none';
if (this.bExbox > 0)
setInnerHTML(document.getElementById('quickReplyOptions' + this.bExbox), '');
setInnerHTML(document.getElementById('quickReplyOptions' + destDiv), this.opt.sThreaded.replace(/%msg%/g, destDiv));
this.bExbox = destDiv;
this.bCollapsed = !this.bCollapsed;
}
And finally (for now), we skip to Display.php...
Add this somewhere around the beginning:
function Tri_recursif($msg)
{
global $atrier, $ordre, $parent;
foreach ($atrier as $key => $msg2)
if ($parent[$msg2] == $msg)
{
$ordre[$key] = $msg2;
unset($atrier[$msg2]);
Tri_recursif($msg2);
}
}
(Feel free to rename this function to "recursive_sort" if you'd like.)
Add these to the globals in Display():
global $atrier, $ordre, $parent;
($atrier means "to be sorted", $ordre means "order", sorry for using French-language variable names, I didn't plan to release my code in the first place...)
After the "// Duplicate link! Tell the robots not to link this." lines, add:
if ($_REQUEST['start'] == 'threaded')
{
$context['threaded'] = true;
$_REQUEST['start'] = -1;
}
BEFORE "// If they are viewing all the posts, show all the posts, otherwise limit the number.", add:
if (!empty($context['threaded']))
{
$context['messages_per_page'] = -1;
$context['page_index'] .= empty($modSettings['compactTopicPagesEnable']) ? '<b>' . $txt['all'] . '</b> ' : '[<b>' . $txt['all'] . '</b>] ';
// Set start back to 0...
$_REQUEST['start'] = 0;
}
After these three lines, add the final line in this code block:
// Find out if there is a post before that is double ;)
$context['last_user_id'] = 0;
$context['last_msn_id'] = 0;
$context['last_parent_id'] = 0;
In the SQL request that comes next, add id_parent:
SELECT id_member, id_msg, body, poster_email, id_parent
Before "if (!empty($row['body']))", add:
$context['last_parent_id'] = $row['id_parent'] == $context['topic_first_message'] ? 0 : (int) $row['id_parent'];
Next request, same thing, add id_parent:
SELECT id_msg, id_member, approved, id_parent
Add the third line in this code block:
$messages = array();
$posters = array();
$parent = array();
Immediately after that, replace the whole while() code block with this: (there are 3 extra lines)
while ($row = $smcFunc['db_fetch_assoc']($request))
{
if (empty($first_msg))
$first_msg = $row['id_msg'];
if (!empty($row['id_member']))
$posters[] = $row['id_member'];
$messages[] = $row['id_msg'];
$parent[$row['id_msg']] = $row['id_parent'] == $first_msg ? 0 : $row['id_parent'];
}
BEFORE "// Fetch attachments.", add:
if (!empty($context['threaded']))
{
$ordre = array();
$atrier = $messages;
sort($atrier);
Tri_recursif(0);
$atrier = array_keys($ordre);
unset($ordre);
}
Skip the next request, and the request after that should add id_parent:
smileys_enabled, poster_name, poster_email, approved, id_parent,
Now, in prepareDisplayContext(), add these to the globals:
global $atrier, $ordre;
BEFORE "// Attempt to get the next message.", add:
if (sizeof($atrier) > 0)
{
if ($counter >= sizeof($atrier))
return false;
@$smcFunc['db_data_seek']($messages_request, $atrier[$counter]);
}
BEFORE "// Compose the memory eat- I mean message array.", add:
$new_parent_id = $message['id_parent'] == $context['first_message'] ? 0 : $message['id_parent']; // should id be topic_first_message?
After the 'subject' and before 'time' (but it can be anywhere else), I added this to the array:
'parent' => $new_parent_id,
In the "doublepost" subarray (this is only used in the Merge DoublePost mod, and the reason for some of my otherwise useless code additions to Display.php, so you'll have to remove these manually for an actual mod!), replace the 'postok' line with:
'postok' => !empty($context['last_user_id']) && ($new_parent_id == 0) && ($context['last_parent_id'] == 0) && $Merge_MaxLimitLength && $context['last_user_id'] == (empty($message['id_member']) ? (empty($message['poster_email']) ? $message['poster_name'] : $message['poster_email']) : $message['id_member']) && (allowedTo('modify_any') || (allowedTo('modify_own') && $message['id_member'] == $user_info['id'])),
Before "return $output;", add this:
$context['last_parent_id'] = $message['id_parent'];
Okay, I think we're done...
- As you can see, it's not that big a deal in terms of additions. It can make for a very manageable mod.
- As I mentioned earlier, some of my code was added specifically for Merge DoublePost, and it doesn't work perfectly either. The problem with Merge DoublePost is that you want to make sure one can't merge two posts made in a row, if the posts belong to a different thread in the topic. This is very important. I would recommend on disabling Merge DoublePost if you intend to use Threaded view at all on your board. My code also needs some polishing on this. If you want to remove everything related to MDP, just look for $context['last_parent_id'], I think that's the only related variable.
- I know for a fact that there are a couple lines (small blocks?) of code which I removed AFTER my first uninstall of the mod, so it means they're not mentioned in this post. I will have to find them later. If you're having any problems with the integration, please post here and I will try my best to help you.
Edit -- I found another piece of code I had forgotten. Hopefully this was the thing I had also forgotten to remove the first time around. Look at the beginning of the post.
Nice work nao
Any demo site or screenshots??
Read again my first post in that page... (the first lines)
I've disabled the feature on my website, though, since most users disliked the whole concept (including me). But I believe karlbenson is now working on making my code into a mod. I don't know where he's up to right now, though.
I currently don't have the time to package it up I'm afraid.
Hopefully someone else will.
Yup -- hopefully :)
If I find the time, I might look over it.
I haven't looked at the provided code in depth, so I might have missed it, but how are deleted posts that have children handled?
Don't forget spliting posts that have children.
Quote from: Motoko-chan on September 18, 2008, 11:52:21 AM
If I find the time, I might look over it.
I haven't looked at the provided code in depth, so I might have missed it, but how are deleted posts that have children handled?
I don't remember ever addressing this, actually. I wasn't too sure whether to go the iMDb and LiveJournal way ("this post was deleted by its author", followed by the children still there), or just "reconnect" children posts with their parent's parent.
Thantos> Same here, never implemented (I'm not too familiar with the split code, so I left it for later, and it never happened). But this was actually one of my main reasons for wanting to make this threaded mode. Easy topic split by just splitting the main post and having all of the children come together naturally in the new topic.
That's a big issue that will need to be handled. If I get the time, I'll look at making a mod, but orphaned child posts are not really beneficial.
IMO child posts follow the parent. So if it is split (or moved/merge) then it should only require doing down the line and updating the id_topic (and id_board if needed). Or in the case of perm deletion then just going down the line and removing them.
The thing is that I can't think of a good way to avoid either loading all the posts in a topic (might not be that bad if you don't get the large text fields) or using recursion (recursion the idea not the implementation). So splitting and removal could become very costly operations.
Quote from: Thantos on September 18, 2008, 12:42:30 PM
The thing is that I can't think of a good way to avoid either loading all the posts in a topic (might not be that bad if you don't get the large text fields) or using recursion (recursion the idea not the implementation). So splitting and removal could become very costly operations.
Agreed. You could have a query that doesn't load the actual post text to find out what ones need the update.
Either way, it would require some experimentation to handle this without killing performance.
Perhaps this is a naive question, but what exactly is the conceptual difference between threaded and non-threaded? SMF is considered non-threaded, and I see it as a tree with arrays of postings as the leaves. The levels are
root
category 1
category 2
board 1
board 2
child board 1 (optional)
child board 2 (optional)
topic 1
topic 2
array of posts, entered at either oldest or youngest end
I've seen other boards that apparently are "threaded", but what exactly does this mean, in terms of data organization and how a visitor navigates it? If I want to follow "the thread" of a discussion, rather than the next overall posting, I click on "next in thread". How does that differ from going into a topic and following it in sequence? Logically, is it the same as a very flat tree:
root
topic 1
topic 2
array of posts
presented as
latest post in topic 7
latest post in topic 12
latest-1 post in topic 7
? Personally, I find an SMF-style tree a cleaner organization than a threaded forum. Do people have trouble with a tree because they miss seeing all the latest postings in chronological order? Is it the serendipity that they want of stumbling across something they weren't looking for? Would the SMF feature of listing the 20 or so latest posts fill this need?
(insert joke here about not seeing the forest for the trees)
Quote from: MrPhil on September 18, 2008, 03:16:49 PM
Perhaps this is a naive question, but what exactly is the conceptual difference between threaded and non-threaded?
While the whole board/topic thing is organized like a tree, "threaded" refers to the post display. For a good example of threading discussions, check out any article on Slashdot (http://slashdot.org/).
The general idea is that each post, rather than having a position in time, also has a position relative to the other replies. A post can be the child of a different post, and would be displayed conceptually under that rather than later on based on the time posted.
Also, I just thought of another tricky scenario. What if you want to reply to more than one post (multi-quote)? I suppose you could post multiple times, once to each thread. I believe vB has some feature where you can quote multiple posts and make only one reply with your post showing in the different threads (but that could be confusing). Of course, I've never used a threaded vB, so I could be wrong in my understanding. Either way, it makes multi-quoting a pain in flat mode.
Damn, this "session has expired" bug is driving me mad! How long are they on sm.org? Ten seconds or what?
Quote from: Motoko-chan on September 18, 2008, 03:37:08 PM
Also, I just thought of another tricky scenario. What if you want to reply to more than one post (multi-quote)?
Ah, yes... I didn't think of that one, either. Maybe that's because I never used the feature ;)
Still, I'm not sure it's a problem. You may have noticed that my code actually reproduces a single Quick Reply box for each and every post in the thread. That's both what makes the display so "heavily charged", and much easier to use than any other nested system (I have yet to see a quick reply box on thread-enabled boards, really!)
Any news or something about this???
:)
Well, although I'm a bit more skilled at maintaining mods now, I'm not sure I would want to maintain a mod that I do not actually use on my website... It would be a hassle more than anything else for me. And I already have enough work with Noisen, SMG and possibly AEVAC...
All of the code I posted on page 1 can easily be turned into an efficient mod, but I would recommend putting the extra code into an external file and calling its functions, it would make it easier to update the mod itself... And add more functionality, such as what to do with orphan posts and double posts, etc...
Why not integrate it into the release rather than a mod or extension function? It is a useful option that reduce the cluttering of the screen endless posts after posts, and you have no idea who is replying to who's comment. Thread view completely eliminates that ambiguity with a tree-structure.
The issues about deleting posts is not a problem, because all it needs is relink the parent and child posts, or replace it with a "deleted pseudo post" if you want to maintain the original tree-structure. It is not any different from how you handle deleting a regular flat view.
Besides, there are lots of forums that have both flat, threaded, and hybrid views integrated seamlessly, such as myBB, vBulletin, etc. they don't have any of the issues raised by Motoko-chan.
I don't see why there is such a resistance to threaded view when it allows you to go through the posts much better. If you are following the posts everyday, then you may remember what people are talking about in the previous threads. But if you are a newcomer trying to read through a thread with a hundred replies, it is a nightmare to sort out who is replying to who.
Quote from: nicoladie on January 24, 2009, 08:32:33 PM
Why not integrate it into the release rather than a mod or extension function? It is a useful option that reduce the cluttering of the screen endless posts after posts, and you have no idea who is replying to who's comment. Thread view completely eliminates that ambiguity with a tree-structure.
That depends on your opinion. Quotes help a lot and flat view discourages multiple tangents. Each style has its place.
Quote from: nicoladie on January 24, 2009, 08:32:33 PM
Besides, there are lots of forums that have both flat, threaded, and hybrid views integrated seamlessly, such as myBB, vBulletin, etc. they don't have any of the issues raised by Motoko-chan.
Because they chose a solution from the possibilities. I'm not saying it's an impossible thing, just that there are many things that come up when designing a threaded view where the handling needs to be determined. It gets even more complex when you have a "hybrid" system where you can view in either mode. Look at the rather weird handling of multiple quotes that vBulletin has. It's because it needs to know which branches to put your response on.
Oh, and if you think handling a flat-only topic is difficult where you don't know who is replying to what, try taking a highly-branched conversation and sticking it in "flat view".
Quote from: nicoladie on January 24, 2009, 08:32:33 PM
I don't see why there is such a resistance to threaded view when it allows you to go through the posts much better. If you are following the posts everyday, then you may remember what people are talking about in the previous threads.
A major part of the current resistance is that it's actually a very low-demand feature (we've had maybe 10 requests for it versus hundreds for many other pet features). It would be rarely used (I don't know of any vBulletin boards that use the threaded view as default much less allow switching views) and add a bunch of complexity to code that would make development much more difficult. We have a small development team at the moment, and there are plenty of other features we were looking at providing that would have much more widespread use.
It's not a permanent no, and certainly I can't speak for the development roadmap, but I don't personally see it being added anytime soon (2.0 is feature-locked and future upgrades don't have feature-specific plans currently).
As for flat mode being difficult to follow, It really depends on what you are used to and how much one allows topics to wander into tangents. Active moderation including splitting topics and just keeping things going in a somewhat-unified direction help this.
Quote from: nicoladie on January 24, 2009, 08:32:33 PM
But if you are a newcomer trying to read through a thread with a hundred replies, it is a nightmare to sort out who is replying to who.
It really depends. I have not seen topics degrade into tens of tangents simply because that becomes difficult to follow for even those participating. Usually, it will either die quickly, get split out, or a new topic will be started about that tangent.
Quote from: Motoko-chan on January 24, 2009, 09:08:22 PM
As for flat mode being difficult to follow, It really depends on what you are used to and how much one allows topics to wander into tangents. Active moderation including splitting topics and just keeping things going in a somewhat-unified direction help this.
Quote from: nicoladie on January 24, 2009, 08:32:33 PM
But if you are a newcomer trying to read through a thread with a hundred replies, it is a nightmare to sort out who is replying to who.
It really depends. I have not seen topics degrade into tens of tangents simply because that becomes difficult to follow for even those participating. Usually, it will either die quickly, get split out, or a new topic will be started about that tangent.
OK, I'm still trying to get my arms around the two models: SMF-style flat and Slashdot-style threaded. (Are those two good examples?) It's beginning to look to me like "threaded" takes the flat style:
category > board > [ child board(s) ] > topic (tree leaf) > linear list of postings
and allows users to make an arbitrary "tree" under the topic -- subtopics, so to speak. In a flat model, the tree structure is fixed (by the forum operator) and ends at the [ child ] boards, and users can add to the topics under a board (tree leaves) and to the list of postings (a linear array) under a topic. Whereas, in a threaded structure, users can change subject lines to split off a new branch topic (subtopics). There may be fewer fixed levels above this (possibly just a root, and then topic branches start from there). Is this a fair description of the two models, or have I not gotten it yet?
Anyway, to address the concern over getting lost over "who's replying to whom" within a topic, there are at least two solutions. The first is to insist on some discipline to quote a bit of the responded-to posting, so a reader can see where this reply is referring to.
Using the "Quote" button, which adds a pointer back to the parent post, is a good thing. It's only necessary to quote a few key words or phrases, and not repeat the whole damned thing like some bozos do.
The second solution is to insist that, when going off on a tangent, that a new topic (thread) be started, so that the new thread doesn't get mixed in with the old.
Here, it would be handy to add a button to "Start related topic" at the topic (or posting) level, rather than just a "Start new topic" at the board level. The first post (or maybe an automatically-generated "post 0") could include a pointer back to the original topic (even better, the
posting where the "Start related topic" was pressed). SMF would have no data structure changes -- a child (related) topic would look just like a regular topic and could be manipulated (moved, deleted, split, combined) like any other. If something is done to its parent topic, that might leave a bad back-link, but that might be detected and cleaned up in some manner. If you also want a forward link from a posting to its child(ren) topics, that would probably require a new table and other changes to SMF's internals. It might be better to automatically generate a "see related topic" posting that includes a link to the new topic, and place it right after the topic where the "Start related topic" button was pushed (insert, if a post is being edited). This new posting might be treated like a regular "Quote" posting start, and permit the user to add some text of their own (but forbid removal or editing of the "related topic" link -- that's only for moderators/administrators). The problem there is that a user would be creating two postings (one in the old topic and one starting the new) and might get confused as to which one they're writing to (and SMF might need two editing windows showing at the same time).
Anyway, just some more thoughts on something that might satisfy the functional request for "threaded" without doing damage to SMF's internal data structure. While at the "Table of Contents" level, you would see all topics under a board in linear order, at the same
level (usually sorted by date), I would think it easier to find a subject line of interest than the usual "wavy" indented threaded listing. If it's considered important enough to keep topics and their children together as one unit (sort by the latest posting anywhere in the
group, and indent by level), that would either require some data structure changes or spending the time to chase back pointers and build the tree on-the-fly.
To make it simple: threaded view is best in ALL occasions, but ONLY if the thread is old and you're not participating in it.
Otherwise, getting the new posts to show up? Not easy.
But being able to split a post and all of its answers directly from a topic would be fantastic, eh. (Which is one of the top reasons why I was hoping that my starter code posted on page 1 would make someone want to do an actual mod out of it. As always, my own answer will be, "nah, I'm too busy with Aeva, and I'm not sure it'd be a good idea to support a mod I'm not currently using on my own site.")
All your code was correct, awesome that is a good work for you...
What?
More than likely a link spammer. I have removed their in-post link.
Quote from: Nao 尚 on August 18, 2008, 09:37:57 AM
Okay, let's go to work...!!
First of all, add a "id_parent" field to "smf_messages". It shall have the same format as "id_msg", since it will store the same kind of information...
In Post.php, BEFORE "// Start the main table.", add:
if (!empty($_REQUEST['quote']))
echo '
<input type="hidden" name="quote" value="', (int) $_REQUEST['quote'], '" />';
Now go to the Display template...
Add this around the beginning. (Before "is_poll")
if (!empty($context['threaded']))
echo '
<div class="tborder" id="quickreplybox' , $message['id'], '">
<h3 class="titlebg headerpadding">
<a href="javascript:oQuickReply.swap();">
<img src="' . $settings['images_url'] . '/expand.gif" alt="+" id="quickReplyExpand', $message['id'], '" />
</a>
<a href="javascript:oQuickReply.swap(' . $message['id'] . ');">' . $txt['quick_reply'] . '</a>
</h3>
<div class="smallpadding windowbg" id="quickReplyOptions', $message['id'], '" style="display: none">
</div>
</div>';
After "$ignoredMsgs = array();", add:
$increm_list = array();
$increm_list[0] = -20;
$increm_list[$context['first_message']] = -20;
After the "if ($message['id'] != $context['first_message'])" echo sequence, add:
if (!empty($context['threaded']))
{
$increm = $increm_list[$message['parent']] + 20;
$increm_list[$message['id']] = $increm;
}
$sty = $message['counter'] == $context['start'] ? 'margin-top: 0' : '';
$sty .= !empty($increm) ? (!empty($sty) ? '; ' : '') . 'display: none; margin-left: ' . $increm . 'px' : '';
if (!empty($increm))
echo '
<div style="margin-left: ' . $increm . 'px"><a href="javascript:void(0)"
onclick="n = document.getElementById(\'mypost' . $message['id'] . '\'); if(n.style.display == \'none\') { n.style.display = \'block\'; } else { n.style.display = \'none\'; } return false;">Réponse de '
. $message['member']['name'] . ' ' . (is_numeric($message['time'][0]) ? $txt['on'] : '') . ' ' . $message['time'] . '</a>' . ($message['new'] ? ' <img src="' . $settings['images_url'] . '/new.png" alt="New" border="0" />' : '') . '</div>';
(You'll have to replace the "new.png" link, as well as add language strings for "Réponse de" which is French for "Reply by... (author name)")
Now we're starting the main div for each message... Just increment them, something like that:
echo '
<div class="clearfix ', !$message['first_new'] ? 'topborder ' : '', $message['approved'] ? ($message['alternate'] == 0 ? 'windowbg' : 'windowbg2') : 'approvebg', ' largepadding"', !empty($sty) ? ' style="' . $sty . '" id="mypost' . $message['id'] . '"' : '', '>';
Now, right before the end of that main div, add this:
if (!empty($context['threaded']))
echo '
<div class="tborder" id="quickreplybox' , $message['id'], '">
<h3 class="titlebg headerpadding">
<a href="javascript:oQuickReply.swap();">
<img src="' . $settings['images_url'] . '/expand.gif" alt="+" id="quickReplyExpand', $message['id'], '" />
</a>
<a href="javascript:oQuickReply.swap(' . $message['id'] . ');">' . $txt['quick_reply'] . '</a>
</h3>
<div class="smallpadding windowbg" id="quickReplyOptions', $message['id'], '" style="display: none">
</div>
</div>';
Now add the final div.
I usually add a "unset($increm_list);" after the message loop.
In the Quick Reply <form> stuff, I add these among the variables:
<input type="hidden" name="quote" value="" />
Now, AFTER the quick reply code block, I add this:
$a = '';
if ($context['can_reply'] && !empty($options['display_quick_reply']) && !empty($context['threaded']))
{
$a = '
<div class="smallpadding floatleft" id="warning%msg%">
' . $txt['quick_reply_desc'] . ($context['is_locked'] ? '<p><strong>' . $txt['quick_reply_warning'] . '</strong>' : '') . ($context['oldTopicError'] ? '</p><strong>' . sprintf($txt['error_old_topic'] . $modSettings['oldTopicDays']) . '</strong>' : '') . '
</div>
<div>
' . ($context['can_reply_approved'] ? '' : '<em>' . $txt['wait_for_approval'] . '</em>') . '
<form action="' . $scripturl . '?action=post2" method="post" accept-charset="' . $context['character_set'] . '" name="postmodify" id="postmodify%msg%" onsubmit="submitonce(this);" style="margin: 0;">
<input type="hidden" name="topic" value="' . $context['current_topic'] . '" />
<input type="hidden" name="subject" value="' . $context['response_prefix'] . $context['subject'] . '" />
<input type="hidden" name="icon" value="xx" />
<input type="hidden" name="quote" value="%msg%" />
<input type="hidden" name="notify" value="' . ($context['is_marked_notify'] || !empty($options['auto_notify']) ? '1' : '0') . '" />
<input type="hidden" name="not_approved" value="' . !$context['can_reply_approved'] . '" />
<input type="hidden" name="goback" value="' . (empty($options['return_to_post']) ? '0' : '1') . '" />
<input type="hidden" name="num_replies" value="' . $context['num_replies'] . '" />
<textarea cols="75" rows="10" style="width: 95%; height: 150px;" name="message" tabindex="1"></textarea><br />
<input type="submit" name="post" value="' . $txt['post'] . '" onclick="return submitThisOnce(this);" accesskey="s" tabindex="2" />
<input type="submit" name="preview" value="' . $txt['preview'] . '" onclick="return submitThisOnce(this);" accesskey="p" tabindex="4" />';
if ($context['show_spellchecking'])
$a .= '
<input type="button" value="' . $txt['spell_check'] . '" onclick="spellCheck(\'postmodify\', \'message\');" tabindex="5" />';
$a .= '
<input type="hidden" name="sc" value="' . $context['session_id'] . '" />
<input type="hidden" name="seqnum" value="' . $context['form_sequence_number'] . '" />
</form>
</div>
</div>
</div>';
$a = str_replace('\'', '\\\'', $a);
$a = str_replace(array("\n","\r"), '', $a);
}
(a "from_qr" hidden value was added recently for Beta 4, I'm not sure it should be used here as well. Would have to check.)
Now, let's skip to the Quick Reply javascript...
Replace:
sJumpAnchor: "quickreply"
With:
sJumpAnchor: "quickreply"', (empty($context['threaded']) ? '' : ',
sThreaded: \'' . $a . '\''), '
Now, xml_topic.js
Add a new line after this first one:
this.bCollapsed = this.opt.bDefaultCollapsed;
this.bExbox = 0;
Add the first line (and linebreak) below before the two lines after:
document.forms.postmodify.quote.value = iMessageId;
// Doing it the XMLhttp way?
if (window.XMLHttpRequest)
The QuickReply swap function is half-rewritten, so it's best to simply reproduce it completely:
QuickReply.prototype.swap = function (destDiv)
{
if (typeof(destDiv) == 'undefined')
destDiv = '';
document.getElementById(this.opt.sImageId + destDiv).src = this.opt.sImagesUrl + "/" + (this.bCollapsed ? this.opt.sImageCollapsed : this.opt.sImageExpanded);
document.getElementById(this.opt.sContainerId + destDiv).style.display = this.bCollapsed ? '' : 'none';
if (this.bExbox > 0)
setInnerHTML(document.getElementById('quickReplyOptions' + this.bExbox), '');
setInnerHTML(document.getElementById('quickReplyOptions' + destDiv), this.opt.sThreaded.replace(/%msg%/g, destDiv));
this.bExbox = destDiv;
this.bCollapsed = !this.bCollapsed;
}
And finally (for now), we skip to Display.php...
Add this somewhere around the beginning:
function Tri_recursif($msg)
{
global $atrier, $ordre, $parent;
foreach ($atrier as $key => $msg2)
if ($parent[$msg2] == $msg)
{
$ordre[$key] = $msg2;
unset($atrier[$msg2]);
Tri_recursif($msg2);
}
}
(Feel free to rename this function to "recursive_sort" if you'd like.)
Add these to the globals in Display():
global $atrier, $ordre, $parent;
($atrier means "to be sorted", $ordre means "order", sorry for using French-language variable names, I didn't plan to release my code in the first place...)
After the "// Duplicate link! Tell the robots not to link this." lines, add:
if ($_REQUEST['start'] == 'threaded')
{
$context['threaded'] = true;
$_REQUEST['start'] = -1;
}
BEFORE "// If they are viewing all the posts, show all the posts, otherwise limit the number.", add:
if (!empty($context['threaded']))
{
$context['messages_per_page'] = -1;
$context['page_index'] .= empty($modSettings['compactTopicPagesEnable']) ? '<b>' . $txt['all'] . '</b> ' : '[<b>' . $txt['all'] . '</b>] ';
// Set start back to 0...
$_REQUEST['start'] = 0;
}
After these three lines, add the final line in this code block:
// Find out if there is a post before that is double ;)
$context['last_user_id'] = 0;
$context['last_msn_id'] = 0;
$context['last_parent_id'] = 0;
In the SQL request that comes next, add id_parent:
SELECT id_member, id_msg, body, poster_email, id_parent
Before "if (!empty($row['body']))", add:
$context['last_parent_id'] = $row['id_parent'] == $context['topic_first_message'] ? 0 : (int) $row['id_parent'];
Next request, same thing, add id_parent:
SELECT id_msg, id_member, approved, id_parent
Add the third line in this code block:
$messages = array();
$posters = array();
$parent = array();
Immediately after that, replace the whole while() code block with this: (there are 3 extra lines)
while ($row = $smcFunc['db_fetch_assoc']($request))
{
if (empty($first_msg))
$first_msg = $row['id_msg'];
if (!empty($row['id_member']))
$posters[] = $row['id_member'];
$messages[] = $row['id_msg'];
$parent[$row['id_msg']] = $row['id_parent'] == $first_msg ? 0 : $row['id_parent'];
}
BEFORE "// Fetch attachments.", add:
if (!empty($context['threaded']))
{
$ordre = array();
$atrier = $messages;
sort($atrier);
Tri_recursif(0);
$atrier = array_keys($ordre);
unset($ordre);
}
Skip the next request, and the request after that should add id_parent:
smileys_enabled, poster_name, poster_email, approved, id_parent,
Now, in prepareDisplayContext(), add these to the globals:
global $atrier, $ordre;
BEFORE "// Attempt to get the next message.", add:
if (sizeof($atrier) > 0)
{
if ($counter >= sizeof($atrier))
return false;
@$smcFunc['db_data_seek']($messages_request, $atrier[$counter]);
}
BEFORE "// Compose the memory eat- I mean message array.", add:
$new_parent_id = $message['id_parent'] == $context['first_message'] ? 0 : $message['id_parent']; // should id be topic_first_message?
After the 'subject' and before 'time' (but it can be anywhere else), I added this to the array:
'parent' => $new_parent_id,
In the "doublepost" subarray (this is only used in the Merge DoublePost mod, and the reason for some of my otherwise useless code additions to Display.php, so you'll have to remove these manually for an actual mod!), replace the 'postok' line with:
'postok' => !empty($context['last_user_id']) && ($new_parent_id == 0) && ($context['last_parent_id'] == 0) && $Merge_MaxLimitLength && $context['last_user_id'] == (empty($message['id_member']) ? (empty($message['poster_email']) ? $message['poster_name'] : $message['poster_email']) : $message['id_member']) && (allowedTo('modify_any') || (allowedTo('modify_own') && $message['id_member'] == $user_info['id'])),
Before "return $output;", add this:
$context['last_parent_id'] = $message['id_parent'];
Okay, I think we're done...
- As you can see, it's not that big a deal in terms of additions. It can make for a very manageable mod.
- As I mentioned earlier, some of my code was added specifically for Merge DoublePost, and it doesn't work perfectly either. The problem with Merge DoublePost is that you want to make sure one can't merge two posts made in a row, if the posts belong to a different thread in the topic. This is very important. I would recommend on disabling Merge DoublePost if you intend to use Threaded view at all on your board. My code also needs some polishing on this. If you want to remove everything related to MDP, just look for $context['last_parent_id'], I think that's the only related variable.
- I know for a fact that there are a couple lines (small blocks?) of code which I removed AFTER my first uninstall of the mod, so it means they're not mentioned in this post. I will have to find them later. If you're having any problems with the integration, please post here and I will try my best to help you.
Edit -- I found another piece of code I had forgotten. Hopefully this was the thing I had also forgotten to remove the first time around. Look at the beginning of the post.
its possible make it for 1.1.9?
i very happy if yes.
Nothing has changed. My code is freely available for anyone to make a mod, provided that they credit me for said code.
Quote from: Nao 尚 on May 24, 2009, 07:18:36 AM
Nothing has changed. My code is freely available for anyone to make a mod, provided that they credit me for said code.
o.k. anyone can make this for 1.1.9.
i cannot know php good.
I too would like to see this in 1.1.9. I am having to consider changing forum software to some other type for a new project.
Please note that the threaded view must be switchable within the threaded view to take to and from flat view> Have a look at http://community.mybboard.net/thread-48649.html for an example
Julian
Quote from: tazzydemon on May 26, 2009, 07:56:27 AM
I too would like to see this in 1.1.9. I am having to consider changing forum software to some other type for a new project.
Both the 1.1 and 2.0 series are feature-frozen. There will be no additional features added in either of those series, so you'd need to hope for the version beyond 2.0.
Okay. I do not understand this. I am very disappointed that SMF does not offer the threaded view. And the argument is that it is no good? PLEASSSSE.
This is based on what kind of judgement? See my post here is actually in reply to NAO's post "Reply #8 on: August 18, 2008, 06:46:17 AM "
How would you know that with a quick glance?
You would know with a threaded view.
I mean the developers of SMF came up with a good product and then left out "threaded view". Why?
Because Nao tried it once... for how long? and only 2 people liked it? Two people out of how many? How many did NOT like it?
I was so sold on SMF. Love all the other features, but no threaded view? Look how many people are asking for it now. Well, I will have to go with MyBB. And that although I like SMF better.
And btw, what do you think is the first option in the
http://www.forummatrix.org "choice wizard"?
Nobody says of the threaded view is not a good feature, they just think of there are other features and bugs to be fixed, Is a lot better to have a stable, fast and simple forum system, maybe someone create a mod for this or maybe this will be added for a future SMF but for SMF 2.0 we are feature frozed so please be patient, create the mod or you are free to left SMF if it's not what you are looking for
Quote from: pbpbpb on May 28, 2009, 10:05:20 PM
Okay. I do not understand this. I am very disappointed that SMF does not offer the threaded view. And the argument is that it is no good? PLEASSSSE.
Actually, it was because it's descended spiritually from YaBB SE, which was also flat-only.
Opening a solely threaded view adds some complexity when working only in that mode. As I noted before, reconnecting child posts in the tree from a deleted post and managing other things including multi-quotes gets really complex. Turning that into a hybrid view just adds more complexity.
This certainly won't be in 2.0 simply because of the complexity involved. As it is, 2.0 is a huge restructure of the foundation of SMF. We don't need to add more code to upset it.
If you look, most forums are actually flat-only. Very few are threaded, and just as few are hybrid.
Quote from: pbpbpb on May 28, 2009, 10:05:20 PM
I mean the developers of SMF came up with a good product and then left out "threaded view". Why?
Because it wasn't in the original design specs. It's like asking why a 1998 model car doesn't have an MP3 jack. Well, not quite, but it's just as silly a question.
Quote from: pbpbpb on May 28, 2009, 10:05:20 PM
I was so sold on SMF. Love all the other features, but no threaded view? Look how many people are asking for it now.
Under 10 unique individuals of how many actual regular posters here? Heck, we had more people asking for paid subscriptions (which is now in 2.0).
You are welcome to request a mod, or have someone write a modification for the mode. I know Nao's code doesn't handle some of the more complex situations, so all that logic would also have to be developed.
Long post ahead! Sorry!
Quote from: Motoko-chan on May 28, 2009, 10:56:46 PM
This certainly won't be in 2.0 simply because of the complexity involved. As it is, 2.0 is a huge restructure of the foundation of SMF. We don't need to add more code to upset it.
+1... I offered my hack for all to see but I also said that I wasn't happy with it ;) It was more a (working) proof of concept than anything else. However, it could still be used as a secondary (non-default) view type. This would pretty much eliminate the quick reply option anyway. Also, when parent messages are deleted, children messages would simply become children of the main topic, rather than children of another message. That's a fair trade for me.
I think it could be envisioned for SMF 2.1 but only as such an implementation: quick, dirty and probably not satisfying as a default view type.
QuoteIf you look, most forums are actually flat-only. Very few are threaded, and just as few are hybrid.
Actually, I looked at that comparison website, and compared all sites. I quickly counted them, and 32 boards are flat only, while 23 (+/-1?) are threaded or hybrid, with about 18 boards being hybrid. So that's not "very few". Or course, it will only be interesting to take into account the "big boys". Of them, hybrid forums are often not free (vBulletin, IPB). The only free hybrid alternatives would be MyBB and Phorum. MyBB being probably a better choice in terms of features overall. So it comes down to choosing between MyBB and SMF and that's all.
If hybrid mode is very important to you, then choose MyBB. If not, then choose SMF. (Or choose MyBB anyway, but I really don't know much about it, apart from the fact that it's rather well known these days.)
QuoteBecause it wasn't in the original design specs. It's like asking why a 1998 model car doesn't have an MP3 jack. Well, not quite, but it's just as silly a question.
Threaded view is actually the original thing... Think newsgroups ;) Messages are always sorted by thread. I remember when I first visited the first web boards (not the very early non-open source ones which really sucked, but the early versions of phpBB and IPB), "why are they showing all messages chronologically? It's hard to follow a conversation!"
Then again, SMF added the ability to choose messages to split together into a new topic, so I'm cool with that. Of course, threaded mode would allow a one-click split of a whole conversation, but that's really, really, the main reason why I wanted to implement threaded mode in the first place, more than the philosophy of having threaded/flat view in itself. As far as I can remember, when I added threaded mode to my site (on a single topic), people actually complained that it was making things more complicated. If it had been threaded by default since the beginning, they might have liked it (no one ever complained about my threaded boards at http://dossiers.cyna.fr, and no one even used the flat alternative I made for them), but then again they got used to the flat version and didn't see a good reason to switch to something else.
So, all in all, I'd say:
- threaded is better for following a whole conversation in one go,
- flat is better for following a conversation as time goes by (with new posts appearing below),
- whichever you use first will become the de facto favorite of your users, and they will tend to reject the alternative.
- it would still be interesting to have a "id_parent" entry in the messages table, if only to be able to put a link to the previous message automatically. Of course, if people use the Quote button properly, quoted messages are correctly linked back.
QuoteQuote from: pbpbpb on May 28, 2009, 10:05:20 PM
I was so sold on SMF. Love all the other features, but no threaded view? Look how many people are asking for it now.
Under 10 unique individuals of how many actual regular posters here? Heck, we had more people asking for paid subscriptions (which is now in 2.0).
I wouldn't say that -- sometimes, people "get" something only after they've been shown it in action. You can actually convert a whole slice of population to something they didn't think they'd like. But in the case of forums, threaded mode is old news, and it's just not the same, so I'm afraid I have to agree with Motoko-chan on this. And I was probably one of the most motivated users on this area -- enough to actually get a proof of concept to work. The very fact that I removed that mode from my site should lead requesters to think about whether it's not something they can't live without.
QuoteYou are welcome to request a mod, or have someone write a modification for the mode. I know Nao's code doesn't handle some of the more complex situations, so all that logic would also have to be developed.
It probably handles 95% of situations just fine, especially for such a small amount of code. But 95% is not enough for prime time of course. :)
From look at the code posted here I'm thinking these edits are for pre-2.0 SMF - anyone have any idea how difficult it would be to add this functionality to SMF 2.0?
My code? It was written on a SMF2 beta (the latest available at that time).
Nao: Someone has asked about making this a mod. Have you any objection to anyone else updating it and packaging it for current versions (credited or otherwise)?
No objection. That's why I posted the code in the first place -- so that someone repackages it.
I'd like a credit for it though, yes ;)
And I may be interested in joining that mod's team, too. As a backup programmer, like I did for SMG back in the days.
Thanks, Nao - just that if the mod does get packaged (won't be by me), there's no debate or doubt over permissions or copyright.
Yeah, no copyright, I don't care. Just a small credit somewhere is fine. And making it free, of course. (I don't believe in pay-only mods.) Maybe I should have pointed this out. Anyway. If it gets done, all for the best!
Just to fill in some background where the question came from - I have a $50 bounty right now open to convert the code into a proper free mod (see http://www.simplemachines.org/community/index.php?topic=352940.msg2397570 ) (I would do it myself but don't have the skills...)
Uh. You're paying someone to convert the code I posted for free? If that's the spirit now...........
Why didn't you contact me in the first place, anyway? You realize I had no skills in mod making back when I posted this, but I do now?
I was going to contact you directly first, but then noticed the 'No unrequested PMs, please' below your Avatar, and decided against it - that's why I posted the link here actually, in hopes you would notice it...
I'm sorry if I have offended anyone - my goal here really is just to get something packaged and released to the community in an expedited manner.... I don't want to step on any toes or anything
Unrequested PMs = PMs that ask for support instead of asking in the related topics. You wouldn't believe how many such PMs I've received. Topics are there for a reason. I also receive PMs from people asking me how to install SMF (yes, SMF), probably because they clicked on the first membergroup they found on the homepage ('Beta Testers') and I'm in that short list. Beta Testers aren't even official SMF Team Members, lol... (I have yet to be told why :P Apparently it's a transit membergroup but I've been on it for a couple of years now, lol. I've beaten longevity records as a beta tester.)
Anyway, that's unrelated to the subject. You could simply have posted in this very thread to ask me. I would have seen your post, just as I saw the activity here. (If you see a topic on which I posted, you can be sure I'll see it in my latest unread replies page, obviously.)
And no, I'm not upset or anything. I just find it silly that you didn't ask me, given that it's a very old topic, and I've been making mods for the entire last year.
Ok, here's your 11th individual who would LOVE it if SMF would add threaded view. IMHO, the main big disadvantage of the current view is that it's sometimes hard to see what particular message someone is responding to. The Forums that CompuServe was running 15 yrs ago had threadview. I remember when they changed their Forumsoftware--lots of angry members demanding that their threadview would be returned! ;)
With a lot of quoting the non threaded view is also quite good to use--I have gotten used to it, too. However, if the good 'ole threaded view could return...that would be so awesome :D
It's probably a matter of 'you do not know what you miss until you have used it before'. And because the majority of Forums these days do not have threaded views, the majority of people do not know about it and also do not ask the SMF people to make it for them. It's almost a chicken/egg problem! :P ;)
Quote from: rbeuker on December 29, 2009, 03:55:38 PM
Ok, here's your 11th individual who would LOVE it if SMF would add threaded view. IMHO, the main big disadvantage of the current view is that it's sometimes hard to see what particular message someone is responding to.
Hmm... How about clicking the Quote link above the quote? It should link you to the original post...
is theres till no mod for this important feature?
Quote from: Dannii on August 13, 2008, 09:44:18 PM
I actually find it very hard to use. I much prefer a flat forum with lots of quoting.
I'm posting in this thread not only because I've checked the Notification box and want a link to this thread, but also to comment on Danii's attitude which reflects the problem of "dealing with customers" that persists on being a difficulty here. This is the Bill Gates attitude, which states that Bill Gates knows what the customer wants better than the customer does.
The customer knows what the customer wants better than the coders do, and this will ALWAYS be the case. People who consider themselves professionals simply because they collect money for services are badly mistaken about what the word "professional" means.
Clara,
As I said in the other thread... "The Customer" can know what they want - fine. However... "The customer" in the case of this forum software is ALL of our userbase, not just YOU. You can request a feature, but unless a significant number of OUR customers indicate that they also desire that feature, then it counts as "bloat" since only a minority would ever use (or even desire) that feature.
Since our goal is to work with our customer base AS A GROUP, and we only have a limited number of developers to do the work, we have to determine what features are desired by a significant number and work on those.
Quote from: Clara Listensprechen on July 26, 2011, 11:56:02 AM
Quote from: Dannii on August 13, 2008, 09:44:18 PM
I actually find it very hard to use. I much prefer a flat forum with lots of quoting.
I'm posting in this thread not only because I've checked the Notification box and want a link to this thread, but also to comment on Danii's attitude which reflects the problem of "dealing with customers" that persists on being a difficulty here. This is the Bill Gates attitude, which states that Bill Gates knows what the customer wants better than the customer does.
The customer knows what the customer wants better than the coders do, and this will ALWAYS be the case. People who consider themselves professionals simply because they collect money for services are badly mistaken about what the word "professional" means.
Actually, I quite often find that my customers don't know what they really want. They think they know what they want but quite often it isn't what they really want. It is my job to figure out what they really want (and sometimes what they need instead of what they want).
Good point, Thantos... That too is part of my role as a business analyst (yes, yet another hat that I wear)
Quote from: Thantos on July 26, 2011, 05:27:00 PM
Actually, I quite often find that my customers don't know what they really want. They think they know what they want but quite often it isn't what they really want. It is my job to figure out what they really want (and sometimes what they need instead of what they want).
I have to agree with that. Often a customer will ask for a very specific thing, but it's not really what they want. What they want is a certain problem to be fixed, which they feel will be done by that thing. Usually, it's better to find the actual problem they want solved and determine the correct way to solve it. Sometimes it's what they asked for. Often, it's not.
Way Overblown Example to Illustrate the Point:
Customer: I want you to kill John Doe
Me: That's kinda not a good idea. What is the actual problem?
Customer: I don't want John Doe here.
Me: Well, I'll just tell him to leave and post a guard to keep him from coming back. That'll be cheaper and won't cause people to go to jail for murder.
Customer: Wow! That's exactly what I want and it saves me money!
Now, can we get back on topic, or let the topic sink back down into the depths?
The topic is what me and my demographic want. As in multiple people. Anybody who thinks that a bunch of people is just me is off topic. Forums are for communities, not echo chambers. Speaking of which....
For what crumbs of assistance I did get, thank you. The rest can sink back to the depths. Kids, you can have your thread back.
Quote from: Clara Listensprechen on July 27, 2011, 08:03:07 PM
The topic is what me and my demographic want.
Which demographic is that?
Already posted that info in the other thread. I'm done with SMF, and that's final. [/discussion]
Good luck to you then.
Good job , thanks you