Note: You are currently viewing documentation for Moodle 2.0. Up-to-date documentation for the latest stable version is available here: Dialogue module.
Dialogues allow students or teachers to start two-way dialogues with another person. They are course activities that can be useful when the teacher wants a place to give private feedback to a student on their online activity. For example, if a student is participating in a language forum and made a grammatical error that the teacher wants to point out without embarassing the student, a dialogue is the perfect place. A dialogue activity would also be an excellent way for counsellors within an institution to interact with students - all activities are logged and email is not necessarily required.
Dialogue is a contributed activity module originally released for Moodle 1.6.x. and subsequently updated for Moodle 1.8.x to support roles and capabilities and most recently updated to support Moodle 1.9.x, 2.0x and Groupings (groups of groups)
- Teachers can initiate private Dialogues between themselves and individual students
- Teachers can initiate individual Dialogues with all members of a group at one time
- Users can attach documents to their dialogue posts
- Students can view a time-stamped history of interaction between themselves and their teachers / tutors within the context of papers.
- Teachers and Students can view time-stamped histories of the interaction between them. Teachers can additionally view interaction histories with all students within a particular paper.
- Users can receive notification of new Dialogue posts via e-mail subscription
- Students can edit Dialogue posts within a specified period of time (30min default).
- Type of dialogue can be set to Teacher-Student, Student-Student, Anyone-Anyone
- Ability for Students (or any role) to initiate a Dialogue can be managed in the activity role overrides
- Can configure whether a Dialogue activity should allow more than one Dialogue between any two participants
- Can enable/disable email notification
- Can set the number of days after which a closed Dialogue will be removed
- Admin setting at site-level to control display of unread dialog count on course pages
The following capabilities are able to be assigned/set against site wide roles and overridden in your local Dialogue instances:
- mod/dialogue:viewall - allow users to have read access to dialogues which they are not a participant
- mod/dialogue:participateany - allows users to participate in dialogues that are not initiated with themselves
Tips and tricks
- When students initially enroll on a site, it might be a good idea to send them a welcome dialogue to let them know the teacher is there. This way if the student has something to say to the teacher, they will feel more comfortable responding, since the teacher made the first step.
- 2003/Oct - Ray Kingdon released the original module
- 2004/Jun - Dialogues with groups of students were supported
- 2006/Apr - Howard Miller (aka thepurpleblob) University of Glasgow, contributed fixes to bring Dialogue in line w v1.6
- 2006/Aug - Howard Miller volunteered to maintain the module. At the time he mentioned Messaging was the mechanism MartinD saw as the tool the core project would be supporting for this sort of activity, and that Dialogue was never actually intended to be anything other than an optional module.
- 2007/May - Clinton Graham provided a diff to get Dialogue running with roles in v1.8
- 2007 - Catalyst integrated group support allowing allocation of groups (or groupings) to specific activities.
- 2007/Aug - University of Waikato contract Catalyst to update Dialogue module to support v1.9 and make a number of feature changes
- 2008/Aug - Reinstated dialogue type selector, various bug fixes (Enrique,Clinton,Lorenzo & Dean)
- 2009/Feb - Improvements to student-to-student mode and all-participants selection for teachers (Dean)
- 2009/Mar - Reintroduced unread entries tracking, and validation fix on edittime field (Dean)
- 2009/Aug - Multiple fixes and improvements (Dean. With lots of contributed code/inspiration here from Enrique Castro)
- fixed bug re lost HTML formatting (see: CONTRIB-1448)
- sorting columns by name, date, post count etc (see: CONTRIB-1449)
- improved group-mode support (see: CONTRIB-1490)
- added participation report support (see: CONTRIB-1454)
- change to view current conversation after update rather than go back to list (see: CONTRIB-1455)
- lots of codeing/style improvments, thanx Petr :) (see: CONTRIB-1216)
- 2011/Oct - Troy Williams updated to support v2.0x
Possible Future Developments
Following is a list of future developments (in priority order). Please feel free to discuss these developments and vote for these if you feel the priority order is not quite right. We also ask that you add to this list:
CONTRIB-1450 Email Notifications includes:
- Option to send immediately (rather than wait 30 mins)
- Option to include the dialogue message content in the email notification
CONTRIB-1451 Change to entry header to include user's name & increase font
- Instead of "On Friday, 1 June 2009, 05:43 pm you wrote: ", would it be better that the name is displayed instead, if the dialogue was exported and archived and the people who are reading it would not know the "you" is referring to who.
CONTRIB-1452 Close conversations for unenrolled students & display date
- Close Dialogue conversations when students are unenrolled
- Display the date that the individual dialogue was closed. the last entry date is good, but sometimes the close date is not always the last entry date.
- Display the date that the closed dialogue would be removed.
CONTRIB-1453 Provide edit & delete for Manage capability (similar to forums)
Other requests with no tracker items created - see page Page Comments for more details
- Let the user specified the end date for the closed dialogue to be removed. Which I think it would be more flexible rather than the 7, 30,...,365 days options.
- Export entries (what format - Text, Html, xml??)
- Display the date that the dialogue was added
- Don't display the "You have 30 mins to edit..." after submit, instead the user should be bought to the current dialogue and allowed to edit it even if it has passed 30mins limit.