The filters we have implemented are three:
a) User name
You can select a user name and view ONLY conversations with that user (either initiated by the user or addressed to that user)
b) State of response
Out teachers were quiet used to old <1.6 Dialogue, with a tab for dialogues that "need my response" and a tab for "waiting for the other person".
It was important for our teachers to know not only what conversations were seen, but which ones were already answered and which not. In fact, in some of our courses we enforce a rule asking teachers to answer students questions within a close time limit.
So, we have a filter that cheks userids of first entry and last one and let select only those open Dialogue sthat "need my response" or are "waiting for the other person" like the old way.
In addition, admins and staffers in some courses can view and/or participate in ANY dialogue. In that case, iIt can be a nighmare to localize conversations that are really addresed to you. You see all conversations between other people with the "unread" mark. So, for "allviewers" this filter has two extra options: MY-unanswered and MY-answered, so "allviewers" can have both sides all/my.
In addition to selecting which conversatiosn to show, another filter allow to select how they are sorted in the page: By date of creation, by date of last seen, by user firstame/lastname, by subject. Both direct or, optionally, reverse sort.
(We know this could be done better using a tablelib table for presentation)
Those filters apply in open and closed conversation tabs.
In fact, other minor rmodifications are aimed at making Dialogue GUI more coherent with standards in other modules. For instance, in any other places in Moodle the name or a user is a link to personal profile information, but Dialogue used teh name as a link to conversation. We introduced that link into subject, just like Forum, and leave user fullnames as links to profile. Similar changes in breadcrumb.
A convenience mod we have introduced is a checkbox in the reply form to reply and inmediately close the Dialogue. In our experience a lot of students end a conversation with a "thanks" message after the isuue/questions has been answered by the teacher. Been polite and answering "not at all", and the closing implies two actions, and one is searching for the convesation again y a may be quite large list.
Of those features listed by Teresa, we see as most important from usabilty point of view:
- Sort entries by columns (first name, last name, etc).
saves time when looking for a particular conversation among dozens or hundreds
- View current conversation after an update (rather than go back to list of conversations).
makes easier to see any error or forgotten issue in the response. And answer and close afterwards.
I am not particularly in favor of 5. Editalways and delete capability (similar to forums)
. We at ULPGC enforce Dialogue in parallel with Forum precisely because Dialogue is "written in stone": unerasable. You can trust that if a conversation was initiated, it reamains there till course completion. Distantce-learning students recognize and put value in the importance of traceability. A site-wide config setting for that would be welcome.
I have already sent our modifications in ULPGC to Teresa and Dean. I hope they could take advantage or our changes.