Forum .LRN Q&A: Moving threads in a forum

Collapse
Posted by Martin Magerl on
Hi,

in order to increase acceptance of forum I added a "move"-option which can be used to move a posting (and its replies) in a thread or between threads, so a professor can do a little house keeping.

While moving postings seems to work fine, I have a question according notifications:
I've noticed that notifications are bound to the last message (-> tree_sortkey) in a thread although the notification-chunk (You can request notifications... / You have requested notifications...) is only shown when viewing the root message.
Therefore, if the last message is moved (directly or as child post), you will move notification settings for the current thread to, i.e. the current thread will "loose" notification requests and maybe, the thread where the messages are moved to/appended will misteriously get notification requests.
Looking at the code of ".../forums/www/message-view.tcl" I noticed that variable "$message_id" (which refers to the last message read by the db query before) is used instead of "$message(message_id)":

# If this is a top-level thread, we allow subscriptions here
if { [empty_string_p $message(parent_id)] } {
    set notification_chunk [notification::display::request_widget \
        -type forums_message_notif \
        -object_id $message_id \
        -pretty_name $message(subject) \
        -url [ad_conn url]?message_id=$message_id \
    ]
} else {
    set notification_chunk ""
}

Now my question:
Could someone please explain the special thought which was followed while programming these lines? Maybe, overwriting $message_id by "db_multirow" a few lines before was not noticed yet.

May I use the root message as "notification anchor", too? It seems to work as well (at least for a five minutes test 😊 and it would make much more sense to me (or to be honest: it would be easier to implement a user friendly behavier on moving postings 😊

I am thinking of a behavior like this: (Use-Case)

Student X posts a new message into a forum-thread. Professor Y thinks that student's thoughts does not cover the thread subject and wants to remove and insert this post as a new thread. Meanwhile all people subscribed to the thread got a notification about this new post, but notifications requests should still direct to the "old" thread not to the moved posting.

Thanks for all replies,
Martin

Collapse
Posted by Matthias Melcher on
Great functionality, Martin! Will we have this on the openACS forums, as well?

It would be very necessary here. For example, when I try to reread something about Photobook, I have to remember that the thread was originally ".LRN features in need of funding" https://openacs.org/forums/message-view?message_id=148555. Or when I am confused with subject and classes I need to click on "dotLRN newby" https://openacs.org/forums/message-view?message_id=134590

Collapse
Posted by Martin Magerl on
Hi, Matthias!

<blockquote>Will we have this on the openACS forums, as well?
</blockquote>
Since "forums" is an OpenACS-package, this feature will be there, too, if the code reaches cvs.

But before submitting a suggestion and a corresponding patch to the bug-tracker, I have to clarify the notification question.

Collapse
Posted by Bruce Spear on
Moving Threads in a Forum.

Moving threads would be a nice feature to have.  Even better, I would think, is to design the interface so that everyone uses it well in the first place.  To this end I’ve fiddled with the Forum interface.

The problem I would like to solve is that many users here are clicking first on the new thread link instead of opening up  an old one so that they are ending up with a dozen new threads on the same topic instead of responding, one after the other, in one thread.

In part, this is a conceptual problem in that some of our students are unfamiliar with the technology. It may also be the case that some have learned to upload text files and homework files and so are used to adding objects one after another. There may be other reasons, but I thought the first thing I might do is examine the Forum page design and see what I might do about it.

Sure enough, the link to start a new thread appeared at the top of the page, was centered, and for the uninitiated there was little indication that the underlined thread titles below were links to be clicked. Indeed, the threads were titled "Subject" and not even "Thread".

So far I’ve solved it by moving things around, like this:
---------------------------------------------------------------------------
Welcome to the Kolloquium Forum!

To view and add to a current discussion Thread, click on its link below.
You can also Search for a Thread: [input box]
To begin a new Thread, click here[underlined link].

You have requested notification for Kolloquium Forum. You may unsubscribe[underlined link]
---------------------------------------------------------------------------

Here’s the explanation.

1. I've used the word "Thread" three times, capitalizing it as a thing, and changing the word "Subject" in the table to "Thread" because "thread" is the among the defining features to forums, as I understand them, distinct from a homework "drop box", a survey "form", etc. , and repetition and supportive graphics sometimes work better than explanation.

2. Right away I pointed to the Threads below, identified them as links, and told people to go there, as in, “do not pass go, do not collect $200.”  In this way I would get most of the people most of the time to the place where most of them want to go: adding to an existing thread.
3. I've moved the search box formerly floating off in outer right space to a place immediately below the instructions to go for the link, to suggest they are of the same kind, and used the word "also", indicated that they are two ways to do the same thing.  If I were offering advice on logic, I’d suggest that someone write a a conditional statement to turn the search box on only when there are more items in the last than one can comfortably scan without having to scroll down.

4. To deter people from starting new subjects recklessly, I’ve moved it from being centered to being but the third item in a list of three (which I’ve aligned flush left), and so clearly subordinating it.  Now, I don’t like the solution of “click here”, but I do want to suggest that one think twice before heading off on a frolic of one’s own.  In this sense, I used "new" in the hope that users would apply the following criteria: is what I have to say different from what is being talked about?
5. I've put the notification link at the end thinking that people might read through the list at first, and later know just to do the first or third thing most of the time.  I have left the words notification and "subscribe/unsubscribe" as is, thinking one sorta explains the other.

I’m curious to know what others might think of this suggestion and this approach – particularly as I am interested in organizing a set of protocols for our new User Advisory Group.  Also, might someone tell me who might now be working on the forum and might actually be concerned with such things?  Or is the best way to find out to go to the OpenACS bug list and see who has  worked on the Forums?

Collapse
Posted by Deirdre Kane on
In your instance of dotlRN, can you disallow users to post/start their own threads?  On SloanSpace, group administrators have this control over forums, which prevents the less you explain earlier.

I also agree with and like your changes to the naming conventions for forums.

Collapse
Posted by Matthias Melcher on
Bruce,
I also favor the naming changes and filed a suggestion https://openacs.org/bugtracker/openacs/bug?bug%5fnumber=1262 .

Regarding your item #2 (identifying links), I see an even bigger problem that new users might have been confused and intimidated by previously encountering other peculiarities, https://openacs.org/bugtracker/openacs/bug?bug%5fnumber=1261 .

Your reordering changes should not be limited to your Berliners, therefore I filed another suggestion https://openacs.org/bugtracker/openacs/bug?bug%5fnumber=1263 .

Collapse
Posted by Martin Magerl on
Hi Bruce,

you are right. Many programmers (me included? 😊 spend most of their time in thinking about functionality and nice features often forgetting usability. Therefore the User Advisory Board is a very good and important idea.
Keeping this in mind, I agree that user interface should be changed in some places to solve conceptual and terminology (-> i18n 😊 problems.

Regarding move-option:
This add-on should not be a workaround for conceptual problems like fake "new" posts in order to allow a community/class admin collecting postings and building one thread, but it should allow some kind of moderating.
At the university of Heidelberg there are some professors which highly use forums in their classes/courses and even base graduating on them. Possibilty of moving postings was one item of their "wishlist" in order to split up threads covering two or more subjects after discussing a while.

Collapse
Posted by Bruce Spear on
Hi Everybody!

It is very gratifying to make a suggestion and find support.  Since I still think of myself as being new to this business, I am hesitant, feel at risk, and so greatly appreciate seeing a comment welcomed and put to use.

Risk is inherent in the situation of anyone arriving late upon the developer's good work and suggesting a mid-course adjustment -- entering terrain someone else has already mapped out considerably, messing with someone else's baby, etc. We do it with the understanding that it is ok for someone to say, "now Bruce, the issue is more complicated," or, "we have other priorities here." Assuredly, users of this forum are well aware of this, so maybe all I am doing right now is writing myself an insurance policy against the future, but I think the forum dynamic here quite remarkable and worth identifying as a protocol for our User Advistory Board.

The protocol, as I understand it, includes using the occasion of someone's thread to: a) enriching the understanding of the problem, and b) translating the discussion into a concrete suggestion or bug fix.

As with the previous posts, Dee Dee enriched my understanding by highlighting how I want users to feel free to start new threads, like in the present .LRN forum, and how I would like to amend the interface to educate people to see "threads" as conversations. Her comment reminded me how switching off the new thread feature would help instructors structure the conversation and that this might be a very good thing, too.  To answer here question: yes, our group administrators can switch the posting to open, moderated, and closed: my prejudice had swept me right by it.

The comment of Matthias I like very much because he selected relevant features, created concrete suggestions, and entered them into the bugtracker and so onto the next stage in our application development, and thus, demonstrated a powerful mechanism for translating the forum discussion into an enhancement of functionality.

Martin's generous comment at the end, as the "owner" of the thread, has sustained our adventure nicely.

Together, I think these moves suggest a powerful way of working for our little UAB -- something others have likely known for a long time but which we, in our new group, have to establish for ourselves.  I hope others agree!

Thanks!

Bruce

Collapse
Posted by Don Baccus on
So has anyone here used a forum/bulletin-board system that not only allows for the moving of [sub]threads or posts but has a REALLY GREAT UI for the admin who does the moving?

This sounds like a very useful feature but UI might be a bit tricky and it would be great to have an exiting implementation to play with.

Collapse
Posted by Martin Magerl on
Hi Don,

I've implemented an UI a week ago and uploaded it as patch #383 this morning.
I'm sure, it's not a really great UI 😊 and I welcome any suggestions. Maybe, someone wants to have a look.

Important note:
Because of Bug #1254 I could not finish programming behavior according notifications, so this patch is only for testing purpose!

General info about implemenation:
I introduced a new variable "$move_id" (and $move_p) which will turn the existing forum-/message-views into a "move"-mode, so a user can search for a message where he wants to append the choosen one.
I think using the existing UI is the best way to avoid confusing a user (e.g. by another "extra-for-moving-UI").

Example for use-case:
  • Admin clicks on "Move" shown near "Edit", "Delete", etc.
  • Admin is shown thread overview to choose thread where he wants to append selected message (and its childs).
    He may click on "Insert message as new thread", if he don't want to append it anywhere.
  • If the admin chooses a thread, he will be presented all messages in this thread to choose a message where he wants to append the selected one by clicking on "append here" (This option is shown instead of "Edit", "Delete", etc. in "move"-mode).
Cancelation of moving a message brings the user back to message originally selected for moving. (possible any time).

Comments welcome!
Collapse
Posted by Carl Robert Blesius on
I really like the elegant way Martin has implemented the function on one of our testing servers. The only suggestion I had was to make the "move mode" more obvious (e.g. make the "append here" link red or bold). Might be nice if we had a general way of making it clear that we are in a "change/edit mode" (something similar to the form builder's red exception box).

I hope we can get the notifications bug out of the way so that it can be added to the toolkit after the user board has looked at it.

Carl

P.S. Great that you are "onboard" Bruce.

Collapse
Posted by Martin Magerl on
Hi,

in order to have a quick look I created a test-user.
Feel free to login and try out the move-option.
Comments are welcome!!!

Account data:
User: mailto:test@meyerhof.zbt.uni-heidelberg.de
Password: dotlrn
URL: http://meyerhof.zbt.uni-heidelberg.de:8002

Collapse
Posted by Raad Al-Rawi on
Martin

This is a nice feature for admins/moderators!!

Just a few thoughts:

The main issue is it is not obvious you are in the process of moving a post. A secondary issue is that once you clicked 'Move', it is not obvious which post you are moving.
Most other actions on forum posts display the post message at the top of the page, then what you are doing beneath it (e.g. reply, forward); but moving doesn't do this.

The ideal (just my opinion) would be to have the context bar at the top, saying something like "Moving Forum Post from [Forum Name]", then display the post message, then the appropriate step in the process underneath that (i.e. 1st step - pick the target thread, or choose new thread, 2nd step - pick position).

I'm guessing the solution you have implemented involves fairly minimal changes, and I'm aware that my ideal requires new pages, or at least a restructuring with fragments (list of forum threads, post message, thread posts).
It may be possible to effectively turn existing pages into fragments, and have a single 'move' page collate the fragments and drive the process.

Just some ideas of the top of my head - not necessarily the best place to find them :)

<Raad>

Collapse
Posted by Martin Magerl on
Hi,

unfortunately I've forgotten to involve a special query into the patch uploaded this morning. And testing this patch erased this query from my current installation, so "append here" did not work. I corrected this error, so you can continue/finish trying out the feature.

Thanks to Deirdre Kane and Dorothea Fischer-Hornung pointing me on this.

Collapse
Posted by Don Baccus on
Since the forums package is part of standard OpenACS, I suggest you post a summary of what you've done to the regular openacs Q&A forum along with a link to your test server.

By doing this you'll get feedback from many more people, and perhaps some more ideas for improvement though it sounds like you've done a very nice first attempt ...

Collapse
Posted by Martin Magerl on
Hi Raad,

thanks for your great feedback.
Yes, being in moving "mode" should be more visible. I will add a move-mode-line in front of each page saying
"You're moving message no. MESSAGE_ID" or better "You're moving message no. X of thread XY", where X is the relativ number in the thread, because absolut no. message_id is not familiar to most users. Also a little sentence, which tells the user what to do would be nice.
In order to keep context bar working for navigation in various levels, i.e. to allow a user to switch between forum-, thread- or message-level, I would avoid presenting the mentioned move-mode-message in there.

Regarding showing the message, which should be moved:
Implementing that the original message is shown in front of the page would not be very time consuming, but I do not know, if it will be a little overhead, presenting the original message and then all other messages, where this message can be appended to, on one page. Sure, this makes sense when you forward or reply to a message, because you can (re-)read the message while writing your own comments on it.

Thanks for sharing your ideas of your head! Maybe, someone else will do the same, so we will find the best thoughts which will hopefully reach cvs head 😊

/Martin

Collapse
Posted by Dave Bauer on
Martin, perhaps in addition to the relative message number, use the title of the message, something like:

You are moving "Re: Some Message" posted by Some User on 1/1/2003 in reply to "Some Message"

Or something like that.

Collapse
Posted by Anja Wicht on
Hi Bruce,
these are exactly the kind of changes dotLRN needs. Great! Can you do this for the whole program please 😉
Anja
Collapse
Posted by Bruce Spear on
I'm curious to know how others think we might build on the excellent improvements to the forum recorded here.

For example.  Consider the difference between the problem-solving use we ourselves have used here from the use our students at the Free University have eagerly put the forum to this semester when arranging events for the student strike.  Our problem-solving use recommends a chronological order, with the most recent post put on the bottom, so we can follow the discussion as it unfolds.  But the business of arranging a demonstration, for example, might recommend that we reverse the order with the most recent suggestions first.  That is, there is a sense of urgency and consensus building such that users would be primarily interested in finding the current stage of the debate put right on top.

My more general concern here is with how we conceive of functionality, which when learning programming I considered in terms of control structures, data structures and all the rest, but when following user interactions I see functionality in very different terms, operating according to a different, even compulsive logic: "I want to find what I am looking for and not what I'm not looking for, and I want to see it on top and in a form that follows the logic of the my needs."  Thus, the building of a consensus features an ultimate crisis, so to speak, a decision, where users check the site with increasing frequency, then the time is passed, and the thread is of no more than historical interest.  This is very different from the current thread, which is more casual, many of us chirping in with advice and support, building community, good work is done, and the discussion sort of peters out.

Might others have illustrations of specific uses of the forum that confirm, contest, or offer other kinds of uses that we might eventually draw on for modelling this perhaps most fascinating of all portlets?

Bruce