Page Index Toggle Pages: [1] 2 
Topic Tools
Hot Topic (More than 10 Replies) Changes needed in "moved" topic interface (Read 8,797 times)
cepheid
Senior Member
****
Offline



Posts: 516
Changes needed in "moved" topic interface
May 22nd, 2009 at 4:16am
Post Tools
I don't know if you would count this a bug more than a need to change the philosophy of treating "moved" topics, but this is the best place I could find to post this, so...

1) When a topic is moved, it is no longer accessible from the Board listing, i.e. if I click on the Board to view the list of topics within the board, any Moved topics are not clickable... I can only click on the destination.  However, in the main forum view, the "last post" shows the Moved thread and that thread is clickable.  This is confusing and "incorrect" for two reasons:

a) It is inconsistent with the board listing - if the thread is not clickable within the board summary, it should not be clickable from the "last post" column, either; and
b) Moving a thread isn't making a post, and therefore it shouldn't appear in the "last post" column for the board.

The solution to this one is fairly easy: the code that determines "last post" should simply skip over any moved threads.  Right now, the code parses the first line in the board file regardless of whether that thread was moved or not; this should be modified to skip any moved threads until the first non-moved thread.



2) When viewing the board listings, for a moved thread, the topic title is not clickable; the destination forum is the clickable link.  This can be confusing, especially when using a template where the links are only subtly different from the regular text.

The fix for this: make the thread title (after Moved:) also a clickable link leading to the new thread.  The "Moved:" prefix and the subtext are sufficient visual indicators that the thread was moved; making the title a clickable link maintains consistency with the rest of the interface, plus makes it easier to actually follow to the new thread destination.



3) When a thread is moved, a brand new thread file is created (with a number of old_thread+1).  There is really no reason for this as far as I can tell, and in fact it creates both additional processing on the back-end (always) and additional clicks for the end-user (sometimes).

Creating a new thread file requires (a) copying the posts from the previous file to the new one; (b) deleting the posts from the previous one and inserting a "moved" message; and (c) storing and parsing a link to the new file.  However, the new file is hardly different from the old file, and based on the structure of the board flatfile, there is no need for this.  The same threadfile can be reused and simply linked from the new board, with a message appended to the thread that it was moved.  This saves all the processing of creating a new file, and still triggers a notification to all subscribed members that a change was made to the thread.  This also saves a bit of processing every time the board is loaded because it doesn't need to read the destination thread number - it's the same number.  (Since the threadfile itself doesn't even link to its container board, there would be no need to change the thread header.)  Of course, this saves a (tiny) amount of storage, as well.

Furthermore, reusing the same threadfile has the benefit that all existing links to that thread still point to the right place.  Using a new file means that all existing links now point to a thread with a single redirection post, which therefore requires an additional click to get to the new thread.  By reusing the same threadfile, all existing links remain valid.

The only problem I can see with the above is that tweaks would need to be made to the Rebuild Message Index code, because that rebuilds all the board files from the threadfiles and may therefore cause the Moved entries to get lost unless steps were taken to preserve them.  (For example, the 'board' entry in the .ctb file could include not just the current board but all previous boards, e.g. "curboard : oldboard : oldboard2," etc.  The "moved" entries could then easily be rebuilt.)

Other than that issue, I don't see any barrier to simply reusing the same threadfile, and per above, it would actually be beneficial to do so.
« Last Edit: May 22nd, 2009 at 4:24am by cepheid »  
Back to top
WWW  
IP Logged
 
deti
Legacy Dev Team
Development Team
****
Offline



Posts: 2,650
Location: Prien am Chiemsee, Germany
Re: Changes needed in "moved" topic interface
Reply #1 - May 22nd, 2009 at 6:34pm
Post Tools
Good points cepheid.

To 1)
If the others agree I think it's a good idea to skip moved threads in the "Last Post" column in the Boards Index.

To 2)
How about
- making the title a link to the thread in the other board and
- modify the link after "...has been moved to " into a link to the new board, not to the thread as it is now.

To 3)
cepheid wrote on May 22nd, 2009 at 4:16am:
Furthermore, reusing the same threadfile has the benefit that all existing links to that thread still point to the right place.  Using a new file means that all existing links now point to a thread with a single redirection post, which therefore requires an additional click to get to the new thread.

Right, but when you delete the "Moved"-info thread, the link goes directly to the moved thread. Without extra click. Wink

cepheid wrote on May 22nd, 2009 at 4:16am:
When a thread is moved, a brand new thread file is created (...).  There is really no reason for this as far as I can tell, ...
There are reasons why a new thread is created! Wink
In earlier YaBB versions the thread id wasn't changed when it was moved. But now move, split and splice are all together in one routine to keep the code better to maintain (we don't have 3 routines to modify if something changed or a bug was found). Move is now the same as spitting all posts into another thread.
I consider the actual work for the processor not really different from the way you wrote. You always has to:
- load the existing thread
- write a new thread with the old thread plus the moved post in it [actual version], or with the moved-info [your version]
- write into the old thread the moved-info [actual version], or the old thread plus the moved post [your version]
- write into the ctb files of both threads
- write into the boards file
  

Was immer Du tun kannst
oder erträumst tun zu können,
beginne es.
Kühnheit besitzt Genie,
Macht und magische Kraft.
Beginne es jetzt.
Whatever you can do
or dream you can,
begin it.
Boldness has genius,
power and magic in it.
Begin it now.
J. W. Goethe
Back to top
WWW  
IP Logged
 
cepheid
Senior Member
****
Offline



Posts: 516
Re: Changes needed in "moved" topic interface
Reply #2 - May 22nd, 2009 at 7:37pm
Post Tools
deti wrote on May 22nd, 2009 at 6:34pm:
How about
- making the title a link to the thread in the other board and
- modify the link after "...has been moved to " into a link to the new board, not to the thread as it is now.

That sounds perfect to me, and much more intuitive than the current way.

deti wrote on May 22nd, 2009 at 6:34pm:
Right, but when you delete the "Moved"-info thread, the link goes directly to the moved thread. Without extra click. Wink
Sure, but that's just a workaround in my opinion, since IMHO the "moved" info thread doesn't need to be there, anyway!  It just adds extra processing, and to save that extra click, the info thread has to be deleted, leading to more work for the admin.

deti wrote on May 22nd, 2009 at 6:34pm:
But now move, split and splice are all together in one routine to keep the code better to maintain

I see the benefits from the code perspective, but for the processing, I disagree.  To add a post, one must merely append to the existing threadfile (and update the .ctb file)... you don't have to rewrite the entire file.  If YaBB does rewrite the entire file, that's inefficient and should probably be changed.  But with my proposed method, one would only need to append a post to the existing thread and update the .ctb; in the current method, a new (possibly very large) thread needs to be created from scratch, plus the old thread overwritten, and now two .ctb files need updating (new thread and old thread).

It may not be a whole lot of processing, and perhaps this sheds light on other inefficiencies in how YaBB processes threads (not sure), but if things were working efficiently, my proposed method would save processing.

That said, I'm not entirely sure how to get around the code aspect, since having a single unified function is certainly better for the devs... but having an intuitive interface and behavior is better for the end-users, and ultimately it's the usability that makes the software better, even if code management makes development easier.

In reality, I think you can keep the same code and still do what I'm saying.  The code already differentiates between moves and splits, because for a move it has to create a new board entry, which it does not do for splits.  Therefore, the code specific to moves could easily be written to not update the threadid, or to change it back after it was already updated.

My point is that there are ways to have both: a unified codebase and the more intuitive method of moving threads.
  
Back to top
WWW  
IP Logged
 
deti
Legacy Dev Team
Development Team
****
Offline



Posts: 2,650
Location: Prien am Chiemsee, Germany
Re: Changes needed in "moved" topic interface
Reply #3 - May 22nd, 2009 at 10:17pm
Post Tools
@ cepheid

I estimate the "speed improvement" of your suggestion (if any) is between 0.001 and 0.05 seconds for this single function. Since this function is not often used on a daily average, it's not worth to touch the code. At least for me (I know how much it is to code this Cheesy). Feel free to try it yourself. But then test it widely and take benchmark of both versions on the same forum and environment.

The usability side of your request I see. But this can be done easily in Display.pl:
If the code sees that the thread was moved we can let it search for the new id and go ahead with it. Nobody will notice. Test it Wink insert the highlighted in Display.pl:
Code
Select All
	# Check to make sure this thread isn't locked.
	($mnum, $msubthread, $mname, $memail, $mdate, $mreplies, $musername, $micon, $mstate) = split(/\|/, $yyThreadLine);

	if ($mstate =~ /m/) {
		eval { require "$datadir/movedthreads.cgi" };
		$msubthread =~ / dest=(\d+)\]/;
		my $newnum = $1;
		while ($moved_file{$newnum}) {
			$newnum = $moved_file{$newnum};
			if (-e "$datadir/$newnum.txt")) {
				$yySetLocation = "$scripturl?num=$newnum";
				&redirectexit;
			}
		}
	}

	($msubthread, undef) = &Split_Splice_Move($msubthread,0);
	&ToChars($msubthread);
	$msubthread = &Censor($msubthread); 

« Last Edit: May 22nd, 2009 at 10:19pm by deti »  

Was immer Du tun kannst
oder erträumst tun zu können,
beginne es.
Kühnheit besitzt Genie,
Macht und magische Kraft.
Beginne es jetzt.
Whatever you can do
or dream you can,
begin it.
Boldness has genius,
power and magic in it.
Begin it now.
J. W. Goethe
Back to top
WWW  
IP Logged
 
cepheid
Senior Member
****
Offline



Posts: 516
Re: Changes needed in "moved" topic interface
Reply #4 - May 22nd, 2009 at 10:33pm
Post Tools
deti wrote on May 22nd, 2009 at 10:17pm:
If the code sees that the thread was moved we can let it search for the new id and go ahead with it. Nobody will notice.

That is an acceptable solution from the usability side, for sure.  I'm fine with that.  We can deal with improvements in efficiency later. Wink

(BTW, yes, I know most of these performance issues are tiny... but a lot of tiny issues can add up.  In this case, it may not be worthwhile since the function is used relatively rarely, I agree.)
  
Back to top
WWW  
IP Logged
 
OH Eng
Past Team Members
Documentation Team
Offline



Posts: 4,026
Location: Pensacola, Florida USA
Re: Changes needed in "moved" topic interface
Reply #5 - May 23rd, 2009 at 1:33am
Post Tools
@deti - my 2 cents  Smiley

Quote:
1) ...  This is confusing and "incorrect" for two reasons:

b) Moving a thread isn't making a post, and therefore it shouldn't appear in the "last post" column for the board.

The solution to this one is fairly easy: the code that determines "last post" should simply skip over any moved threads.


The user who made it DID make a post... it used to be the last post in the former board... you don't want that to count, and now you don't want it to count in the new board either?  That's not logical either.  If it's moved to a new board, it is now the "last post" there and it should count as such IF it's not going to count in the other board.   I agree with you it shouldn't be clickable from the last post column, but nothing wrong with it being the last post in the new board (until someone makes another).

Quote:
2) When viewing the board listings, for a moved thread, the topic title is not clickable; the destination forum is the clickable link.  This can be confusing, especially when using a template where the links are only subtly different from the regular text.


It's not confusing to the user who posted in Board A, then comes back to read replies and is relying on that link to tell him where his post went (moved into Board B).  Since this feature was added I've never seen a single user ask, "Where did my post go?"  If you read the entire text of what is left behind, it says plainly that it was moved to X.  What else are you going to put a link to?  You can link to a topic that doesn't exist in Board A or the topic now existing in Board B.... which makes the most sense to link to?

Quote:
Right now, the code parses the first line in the board file regardless of whether that thread was moved or not; this should be modified to skip any moved threads until the first non-moved thread.


What's the logic behind this?  A moved post is still a post.  If you move it into a board, why shouldn't it be counted as the "last post."  If you had notifications on, would you NOT want any notification this post was there, because it's not a "last post?"

Think of it this way; Suppose instead of moving posts we asked each user to delete their post and repost it in another board.  Would you count that as a new post in the new board?  How is moving the original post to there any different?

I agree with you about not counting the post in the old board, but I think it should be every bit a "new post" in the board it is moved to as any other post.  Moving is just a convenience so you don't have to delete and repost.

As far as the code goes, as I recall there were a few issues that were solved in the process of combining the split/splice/move code into one sub.  I'd be careful undoing this so it doesn't bring back former problems before the code was combined/improved.
  

 
Back to top
 
IP Logged
 
cepheid
Senior Member
****
Offline



Posts: 516
Re: Changes needed in "moved" topic interface
Reply #6 - May 23rd, 2009 at 1:51am
Post Tools
OH Eng wrote on May 23rd, 2009 at 1:33am:
you don't want that to count, and now you don't want it to count in the new board either?

No, that's not what I said.  I don't want it to count for the old board only... it should obviously count in the new board.  Right now the old board shows the "this thread has been moved" post in the Latest Post column, and this is what is both confusing and incorrect.

You are absolutely right that the last post in the moved thread should be the Latest Post in the new board, but that's not what I was debating.

OH Eng wrote on May 23rd, 2009 at 1:33am:
It's not confusing to the user who posted in Board A, then comes back to read replies and is relying on that link to tell him where his post went (moved into Board B).

Again, you're focusing on something that I didn't say.  I'm not debating that the link should go away; I'm debating that the link should be improved by making the thread title rather than the forum name linked to the new thread.  And, to be extra clear, I'm talking about the board listing (the list of topics), not the info post in the thread itself.

I'm not suggesting linking to anything new or linking elsewhere; I'm suggesting improved placement of the link itself, to make it (a) consistent, and (b) intuitive.

OH Eng wrote on May 23rd, 2009 at 1:33am:
If you move it into a board, why shouldn't it be counted as the "last post."

See above; I was referring to the old board, not the destination board.

OH Eng wrote on May 23rd, 2009 at 1:33am:
I agree with you about not counting the post in the old board, but I think it should be every bit a "new post" in the board it is moved to as any other post.

Great!  Then we're exactly on the same page, because I was never suggesting changes to the new board.

It looks like you either misunderstood what I was saying or read too much into it... I hope this clears up what I meant, though.
« Last Edit: May 23rd, 2009 at 1:54am by cepheid »  
Back to top
WWW  
IP Logged
 
OH Eng
Past Team Members
Documentation Team
Offline



Posts: 4,026
Location: Pensacola, Florida USA
Re: Changes needed in "moved" topic interface
Reply #7 - May 23rd, 2009 at 4:54am
Post Tools
When I did read this:

The solution to this one is fairly easy: the code that determines "last post" should simply skip over any moved threads.

I didn't see you were making any distinction between "old" and "new" boards.  I took "any" to mean "any."

But yes, if you think the post should count as new in the moved-to board, we are on the same page.  Smiley
  

 
Back to top
 
IP Logged
 
cepheid
Senior Member
****
Offline



Posts: 516
Re: Changes needed in "moved" topic interface
Reply #8 - May 23rd, 2009 at 6:25am
Post Tools
OH, one of the reasons I stated it that way is because in the board file, the listing of the thread in the old board has a specific status code to specify it was moved... in the new board, there is no status code - there is no indication that the thread was ever moved, so the moved thread appears just like any other thread.

So, when I said to "skip over any moved threads," what I meant was to skip over any thread whose status was "moved," which would only apply in the old board.  I think deti understood what I meant, but I can see how I wasn't clear enough in general. Smiley
  
Back to top
WWW  
IP Logged
 
deti
Legacy Dev Team
Development Team
****
Offline



Posts: 2,650
Location: Prien am Chiemsee, Germany
Re: Changes needed in "moved" topic interface
Reply #9 - May 23rd, 2009 at 7:31pm
Post Tools
New
Setup.pl

Languages\English\Main.lng

Sources\Display.pl
Sources\MessageIndex.pl
Sources\ModifyMessage.pl
Sources\MoveSplitSplice.pl
Sources\RemoveTopic.pl
Sources\SetStatus.pl
Sources\Subs.pl
Sources\System.pl

In CVS.

- Skip Moved-Info in the "Last Post" column in the Boards Index (if Moved-Info isn't the only post in that board).
- The  title of the Moved-Info is now a link to the thread in the other board
- The link after "...has been moved to " is now a link to the new board, not to the thread as it was before
- Links to Moved-Infos are redirected to the moved thread.
- Code improvements to save file loading
« Last Edit: May 23rd, 2009 at 9:19pm by deti »  

Was immer Du tun kannst
oder erträumst tun zu können,
beginne es.
Kühnheit besitzt Genie,
Macht und magische Kraft.
Beginne es jetzt.
Whatever you can do
or dream you can,
begin it.
Boldness has genius,
power and magic in it.
Begin it now.
J. W. Goethe
Back to top
WWW  
IP Logged
 
cepheid
Senior Member
****
Offline



Posts: 516
Re: Changes needed in "moved" topic interface
Reply #10 - May 24th, 2009 at 12:23am
Post Tools
deti,

I think you should skip the Moved-Info in the "Last Post" column even if the Moved-Info is the only post in the board.  If the board is empty except for the Moved-Info, there are no "real" posts in the board and the board should show "N/A" for Last Post.  In my opinion...

I presume your code skips all moved threads, if there is more than one at the top?
  
Back to top
WWW  
IP Logged
 
deti
Legacy Dev Team
Development Team
****
Offline



Posts: 2,650
Location: Prien am Chiemsee, Germany
Re: Changes needed in "moved" topic interface
Reply #11 - May 24th, 2009 at 1:48am
Post Tools
cepheid wrote on May 24th, 2009 at 12:23am:
I presume your code skips all moved threads, if there is more than one at the top?

Yes, but it looks strange if it says that in the board is 1 "Topics" and 1 "Posts" (what is true) but then shows N/A for "Last Post"!?! I can hear the users posting here in "Bugs open": "This is a bug!" Wink Cheesy Smiley Do you have a better suggestion?
Don't tell me to put "Topics" and "Posts" to 0 if there are only one or more Moved-Infos in the board, because then the next will come and say this is a bug! Cheesy
  

Was immer Du tun kannst
oder erträumst tun zu können,
beginne es.
Kühnheit besitzt Genie,
Macht und magische Kraft.
Beginne es jetzt.
Whatever you can do
or dream you can,
begin it.
Boldness has genius,
power and magic in it.
Begin it now.
J. W. Goethe
Back to top
WWW  
IP Logged
 
cepheid
Senior Member
****
Offline



Posts: 516
Re: Changes needed in "moved" topic interface
Reply #12 - May 24th, 2009 at 1:59am
Post Tools
deti wrote on May 24th, 2009 at 1:48am:
Yes, but it looks strange if it says that in the board is 1 "Topics" and 1 "Posts" (what is true) but then shows N/A for "Last Post"!?!

Quite true... but I think the preferred solution for that is to not count Moved-Info threads in the thread count or the post count... because they're not real threads or posts, just redirection/placeholder stubs.

So, I guess I would recommend fix #4: change the thread/post counting code to ignore Moved-Info threads (and the one post contained within).

That solves both problems...

deti wrote on May 24th, 2009 at 1:48am:
Don't tell me to put "Topics" and "Posts" to 0 if there are only one or more Moved-Infos in the board, because then the next will come and say this is a bug! Cheesy

Well, that's actually the solution I think is best... and if anyone reports it as a bug, they would be wrong!  The Moved-Info "thread" isn't a thread at all... it's just a placeholder with a redirect.  In fact, you usually can't even see the thread itself, because the board listing only contains a link to the new thread - there is no way to get to the original stub except via a direct link, and even then you've changed that now to automatically open the new thread.

So... since there's now NO way to see the Moved-Info thread itself, and all you can see in the board listing is a link to the new thread... then the Moved-Info "thread" isn't at all a thread but just a placeholder.  As such, it should not, IMHO, be counted as a thread.

I strongly recommend not counting the Moved-Info threads in the thread/post count for a board, per the above... I think you'll agree that this is the only logical solution.  If anyone reports it as a bug, they'd be wrong: it's not a bug, it's the intended behavior!  I doubt they would report it as a bug, though, because it's quite clear with the changes we've made here that the Moved-Info thread isn't a real thread anymore.
  
Back to top
WWW  
IP Logged
 
OH Eng
Past Team Members
Documentation Team
Offline



Posts: 4,026
Location: Pensacola, Florida USA
Re: Changes needed in "moved" topic interface
Reply #13 - May 24th, 2009 at 2:13am
Post Tools
You're splitting hairs.  If "something" is in there, even a redirect, what's the big deal if it shows 1 topic or 1 post?  Deti's right... next week another user will report it as a bug because the counts show 0 and "something" is in there.

Why not just consider what's left behind as an informational post and leave it as it sits with the update?

  

 
Back to top
 
IP Logged
 
cepheid
Senior Member
****
Offline



Posts: 516
Re: Changes needed in "moved" topic interface
Reply #14 - May 24th, 2009 at 5:08am
Post Tools
I'm not splitting hairs, I'm pointing out things that I consider inconsistent and unintuitive in the interface.  It's not that there's a "big deal" - clearly, I live with it as-is right now - but I think that my suggestions would be an improvement in terms of making the interface more consistent, more intuitive, and IMHO less confusing.

For what it's worth, other forum software (e.g. vBulletin) does not tread Moved-Info placeholders as threads - they are placeholders only and do not count towards thread or post numbers.  I find that to be the more intuitive method.

I find it strange that someone would agree with the other changes proposed above but disagree with this one, because they all follow logically from one another.  If you're going to make the Moved-Info placeholder count as a thread/post, that philosophy fits better with the way things used to be before the changes above were made.

While I'm very glad the above changes were put into place, omitting this last piece feels inconsistent and like we only went partway.  I would much rather we go all the way.  Don't get me wrong - I'm grateful that any changes were enacted.  I'd just prefer to see everything be consistent and I would not be doing my duty to the YaBB community if I did not submit my constructive criticism.  I'm trying to help.

I should also point out that omitting a feature change just because "someone" might (wrongfully!) point it out as a bug is not, in my opinion, a good philosophy.  If someone points it out as a bug, that someone can be educated as to why it's more logical the way that it's done.  However, I really don't think anyone will point it out as a bug, because it's quite clear the Moved-Info thread isn't "something," it's merely a placeholder.

But, I'm not a dev, so the final call is obviously with you guys.  I'm just suggesting what I think is the right way.  Until and unless I'm invited to the dev team, I can only make suggestions.
« Last Edit: May 24th, 2009 at 5:09am by cepheid »  
Back to top
WWW  
IP Logged
 
Page Index Toggle Pages: [1] 2 
Topic Tools
 
  « Board Index ‹ Board  ^Top