Moodlerooms Proposed Comments User Interface Updates

Moodlerooms Proposed Comments User Interface Updates

by Jason Hardin -
Number of replies: 13

Moodlerooms is proposing an update to the Comments API focused around the user interface.  Our functional specification can be found at http://docs.moodle.org/dev/Comments_UI_Update.

 

Moodlerooms would appreciate any feedback on the proposed changes.  The technical specification will follow after we have received comments on the functional design for the changes. 

We would like all comments in by February 15th 2013. 

We need time to develop the technical specification by February 19th 2013 for discussion at the Developer meeting on Feburary 26th.

 

Average of ratings: -
In reply to Jason Hardin

Re: Moodlerooms Proposed Comments User Interface Updates

by Dan Poltawski -

The one thing that immediately strikes me as a 'no no' is the setting you propose to introduce for tinymce - 'commenttoolbar'. Introducing a setting for the comment editor is not the right solution. We need something more generic, else we'll end up with a toolbar setting for every single editor in the whole Moodle interface.

Actually there seem to be a few different solutions to simplifying the tinymce editor going round. MDL-32750 recently introduced the ability to collapse the editor tools by default. There was a post and bug (MDL-37565) created about improving the default theme too.

A setting specifically for the comments is the start of a slippery slope and not the right solution here IMO.

In reply to Dan Poltawski

Re: Moodlerooms Proposed Comments User Interface Updates

by Jason Hardin -

While I like the look of each of those solutions and think they would be great overall additions. These solutions would solve the first requirements which is to shrink the HTML editor to fit nicely in all areas where comments appear. The second requirement was to allow an administrator to restrict functionality the user has access to within comments. 

Not all site administrators will want comments have file attachments from the moodle media button, or images, or raw html for that matter. Or video or audio comments (these of course are based on third party plugins not core functionality).

Maybe I missed it ( i only skimmed the first really long ticket). How does either solution serve to meet the requirement of site administrators limiting commenting functionality?

I am not stuck on the comment toolbar setting for TinyMCE, but I didn't find another solution that allowed button restriction only for Comments. I am open to other ideas.

 

In reply to Jason Hardin

Re: Moodlerooms Proposed Comments User Interface Updates

by Dan Poltawski -

Maybe I missed it ( i only skimmed the first really long ticket). How does either solution serve to meet the requirement of site administrators limiting commenting functionality?

Sorry, I was not suggesting either were solutions to this, just pointing out other work in a similar area.

Not all site administrators will want comments have file attachments from the moodle media button, or images, or raw html for that matter.

Well, restricting the editor toolbar is only one part of the solution to that. Note how the 'essay' question type has a number of options for formatting with the editor, the editor with file picker, plain text. These are setup differently on the server side andsprocessed differently on the server for each variation in addition to the editor being setup with the different options.

I realise that its out of the scope of your work, but customising the editor toolbar per form is a feature which would be beneficial across all Moodle forms. Adding a site level configuration only for commenting would be a step in the wrong direction IMO.

In reply to Dan Poltawski

Re: Moodlerooms Proposed Comments User Interface Updates

by Jason Hardin -

What would be a good step forward there?

Internally we discussed an API which allowed the developer to determine which buttons should be useable in the HTML editor on the page. This didn't provide administrative controlm and there was a concern about the way buttons are named and created for different HTML editors, which was why I didn't go down that route. 

I am willing to consider other options because I was not 100% satisfied with this design.

In reply to Jason Hardin

Re: Moodlerooms Proposed Comments User Interface Updates

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

I think it might be better to simply use an "attachment" filearea (similar to forums here, but more compact) rather than embedded links in the HTML and buttons in editors.  This is actually what Facebook, G+ etc do.

In reply to Martin Dougiamas

Re: Moodlerooms Proposed Comments User Interface Updates

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

As an example see the mp3 file attached to this forum post, rendered by forum as a player.

In reply to Martin Dougiamas

Re: Moodlerooms Proposed Comments User Interface Updates

by Jason Hardin -

Agreed. I will update the specification, hopefully by the end of the day with a redesign based on the use of the file attachment for media and the removal of the HTML Editor.

 

I will also remove the comments tool bar setting in tinymce and the activation of the HTML editor in the commenting settings. I will leave file attachments as a setting for comments and the upload limit as well.

In reply to Jason Hardin

Re: Moodlerooms Proposed Comments User Interface Updates

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

I agree the current UI for comments sucks and would love to see a lot of UI fixes to make it more useful.  Most of the workflows in the specs are attractive.

I'm a little worried about adding HTML and files to every comment though.

The original comment system was designed to be lightweight and to work anywhere across Moodle.  Things it is missing intentionally:

  1. HTML:  Formatted text in Moodle means allowing all editors, not just HTML.  And opening up to HTML means a lot of security around that, as well as a drop in performance and a more cluttered UI.  Note that Facebook, Twitter and Google Plus do not allow HTML in their posts, and no-one seems to mind.  I don't think the case for HTML here is good, and you'd need to make a good case for it if you want to keep including it.
  2. Files: There is a slightly better case for files, perhaps, but again this will open up a  bit of can of worms with performance and security.  Comments can appear in MULTIPLE contexts (eg a comment block) and the capability checks start getting onerous for all the file access and handling. Not to mention a blowout in course sizes as all these "temporary" files flinging back and forth have to be backed up etc.

I do like that these features are optional and have switches, but this itself creates some complexity, and remember that changes here will affect a lot of modules in Moodle and perhaps cause a lot of new bugs later on.

As a result I'm wondering if the commenting you are focussing on, which is almost exclusively discussion between student and teachers over graded items, might not be a separate beast to the commenting API, perhaps a gradecomments or feedbackcomments.

In reply to Martin Dougiamas

Re: Moodlerooms Proposed Comments User Interface Updates

by Jason Hardin -

I would argue that in 1 each of the simplified comments you mentioned, twitter, facebook and google plus all allow multimedia to be embedded in a comment. I would argue that their use would be significantly reduced with out mutlimedia. My goal is multimedia not HTML. If we can design a way to easily allow the embedding of multi media (links, video, audio and images) without the need for a full HTML editor I would do that. I went with the Moodle way of allowing media though, which is the HTML editor.

For 2. I would argue that based on our usage most files of of a small size 2 MB at most. I would see media file of greater concern. And the course back up you mention with user data is generally for archival purposes. If I am cloning a course from semester to semester I am not taking student data with it. This means that most institutions will off site the larger backups and rarely use them unless a student has challenged a grade or is requesting to retake a course.

IMO comments needs to be drastically expanded to be of significant use to teachers and students. The more activities that allow for grading and commenting the more robust the commenting system needs to be. In conversations with clients and industry experts I have heard requests for graded wikis, graded forums, graded glossaries and databases. There are a plethora of ways teachers want to use activities and in each one I see comments and notes as being a significant way to improve the course dialogue. But not with just text. Media is a requirement. We are finding that instructors prefer audio comments over text because they are easier and quicker to make.

All the uses above those as you said are grading. We could definitely work with just a grade commenting system, although the current database structure for comment support everything we have proposed except file attachments. 

I would suggest reviewing what commenting system you use that actually doesn't allow HTML content. Meaning only text, no links, video or images.

In reply to Jason Hardin

Re: Moodlerooms Proposed Comments User Interface Updates

by Lesli Smith -

Alright, I've tried drafting a response three different times, and I've liked none of my drafts so far. However, I think I can't wait anymore to get the wording right.  The teacher perspective needs to be interjected now:

My initial reaction to this idea (last week) was that maybe we are starting to get confused about the types of communications that belong in the new comments exchange option in assignments (which I guess I had defined in my head as an area to exchange short "tweets" of sorts and nothing more) and the more involved feedback made possible by the file and overall assignment feedback options.

I also find that I've been asking myself the following question a lot these days: At what point do we end up giving our students feedback overload?  And how do they know where to look at any given time? It gets a little overwhelming to track all of the different ways we've created to leave messages for one another in our courses.  It isn't just in Moodle, either--it's in other systems, too.  Take the Turnitin.com integration, for instance. I can post general essay feedback.  I can post specific flags with comments directly on the essay.  I can post recorded verbal feedback.  I grade with the rubric, which also provides a kind of feedback.  All of these options are pretty amazing and give us opportunities for a depth of exchange we haven't had before.  So I'm thinking to myself, I'm providing a pretty high level of feedback, right? Until I get an email from a student saying she thinks I probably left some comments somewhere, but she can't figure out how to access them because no one yet pointed out to her what the icons mean or she didn't yet access the "How to access your instructor's feedback" tutorial prior to looking at her draft.  Upshot: What good is having all of these options for communicating if the message doesn't get to the recipient? And should my student have to access a tutorial first before she can access her feedback?

Specifically, with regard to the comments option, I'm finding that while I REALLY like the two-way communication option, it is so easy to miss that someone said something if one doesn't have the arrow activated or isn't paying attention to the fact that the 0 has turned into a 1 or 2.  I am on board with the idea of creating a more robust two-way conversation area than we currently have, but I'm not sure whether opening up the comments in this way would just exacerbate the multiple feedback loop issue if the definitions of communication purposes aren't more clearly drawn up first--or if something doesn't get streamlined somewhere.  The flexibility of the proposed options in the settings area sounds really great until I start seeing how many switches I will have to remember to throw or not throw.  Please, please don't direct me to the messaging options window for any other settings options.  My own eyes glaze over trying to navigate all of those decisions, let alone a group of teachers or students who are brand new to Moodle.

I'd therefore like to ask us to take a step back for a moment and ask ourselves if we are asking the right questions.  I think you ARE asking the right question where you begin your conversation here: how can we create a space where teachers and students can have more robust communication?  It is in attempting the execution of a solution that tries to use a system with pretty inherent limitations that I think you start to ask the wrong questions.  I've been watching the developments in outcomes and elsewhere starting to take shape, and I'm thinking we are coming closer than ever before to being able to offer a more cohesive, meaningful, dynamic learning environment that is a curriculum map, portfolio, and highly personal learning space all at the same time--but we keep chopping this experience up into little pieces as we come to understand the smaller parts involved in this endeavor.

This has been the vision I've been chasing ever since 2008 when I first looked at outcomes and assessment feedback options in Moodle:

In a perfect world, as a teacher, I want a system that dynamically maps my curriculum as it grows and adapts to the learners in my courses as they come in and out of different collaborative groups and individual projects; as a learner, I want to see a portfolio that shows my growth over time--and shows it by capturing the snapshots that have been most meaningful to me.  We are closer than ever to being able to offer this system, and that is really exciting to see.

Now, when you meet on the 26th, I respectfully ask you all, as my favorite educational software wizards, to try to move forward with the idea that this system needs to function as a cohesive whole, no matter how many chaotic and disparate things are going on behind the scenes.  One way I see this happening is if, somehow, we start to think of tracking these systems differently--maybe having systems that work in parallel and often together at given points without being inextricably bound to one another: a learning object that can have comments/feedback conversations attached or not, grades and/or outcomes attached or not, in a portfolio--now THAT would be a powerful tool for a student to control and wield.  I'm not sure if that is what you meant, Martin, but if it is, it really caught my attention.

And Jason, if you are starting to envision a commenting ability that might replace the other options causing the feedback loops I described, so that all of the feedback related to a learning object starts getting logged in the same place--then I am liking that conversation direction, too.

Back to the how:  You know I have no business talking about the how, really, so I'll just leave that part of the discussion to you with one plea: Whatever you all decide to do, make it so that it is something simple that can be done in very few steps with no extra settings and no complications involving decisions that a site admin has to make when it really is a question of individual preference on the part of the teacher.

Finally: THANK YOU!  I like that you are still starting the conversation with what best promotes a richer learning experience.  smile

Average of ratings: Useful (3)
In reply to Lesli Smith

Re: Moodlerooms Proposed Comments User Interface Updates

by Jason Hardin -

To add some context to why we want to update the current commenting system. Moodlerooms is looking to do a lot of open source work this year. We have a specification for changes to outcomes, commenting and we are discussing the release of what we called Joule grader (to be renamed to something more appropriate) to Moodle HQ. If you take a look at Joule grader on youtube this is our concept of a cohesive location for activity grading and comments. This along with the proposed addition of a message output event for comments IMO provides a student and teacher with a reduction in the feedback overload that your looking for.

In reply to Jason Hardin

Re: Moodlerooms Proposed Comments User Interface Updates

by Jason Hardin -

I have updated the specification again with the following changes:

  • Added Alerts and streams back to the specification as these will be released to the Moodle Community.
  •  Added anonymous comment support to allow for Blind marking in assignment submission comments. See tracker ticket [1]

I am not happy with the anonymous display of comments implmentation when it comes to activity comments. Comments and the activity won't have the same Participant identifier, and they need to be the same. Any suggestions on improving this would be very welcome.