Three editor related requriements: 1. other text input widgets

Three editor related requriements: 1. other text input widgets

by Tim Hunt -
Number of replies: 15
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

I am aware of three requirements around editors, that go a bit beyond a standard editor in a Moodleform. I tried to explain it in Developer's chat this morning, but did a really unclear job, so I though I would try again here.

1. Superscript / subscript editor.

This is something we made for use in scientific question types. It lets students type responses like 3x108 ms-1, or SO42-

So, we only want studnets to be able to type plain text, and superscritps and subscripts, and we don't want them to be able to nest one sup or sub inside another sup or sub. This is really just a usability thing. (You would be amaze at how much of a mess you can get yourself into with just sup and sub tags. E.g. in the Sulphate example, it is easy to end up with SO42-Oh, and look how badly Moodle CSS copes with those nested tags.)

Now, you could argue that this should be handled by a server-side filtering, but acutally that is not the point. We are not worried about malicious students hacking the server. We are worried about them getting into a mess while entering their response, and we want to make the usabulity as good as possible, but we do this by restricting the options available.

What we have currently is built on TinyMCE, but that was just for convenience. It would brobably be better (more light-weight) to base it on the Atto code. For various reasons it works best to package it as a separate editor add-on in Moodle, even though it is not the sort of pluggable that users would want to select in their user profile.

Average of ratings: -
In reply to Tim Hunt

Re: Three editor related requriements: 2. make client-side restrictions effective

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

The second example requirement comes from the work we are doing with Online exams. We are using Moodle with Safe Exam Browser. That locks down the student's computer for the duration of the exam, so, for example, they cannot get to Google. They can only click on links that are contained in the page.

We have configured the standard editor to remove most of the options. For example, we removed the insert link button so that students cannot insert a link to Google, and then click on it. Note that this is again all happening on the client-side. This is not about the data that gets stored in the Moodle database, or later re-displayed, which is where we normally do content filtering in Moodle.

However, we found a way around this. It turns out that even though we had removed some tools from the toolbar, the corresponding keyboard shortcuts still worked, so if you knew them, you could get round our restrictions.

Anyway, I am informed that in Atto, if you disable a given tool, it is completely disabled, which sounds like what we want. smile

Note also that MDL-44601 is interesting in this regard, but is something slightly different.

Average of ratings: -
In reply to Tim Hunt

Re: Three editor related requriements: 3. activity-specific editing tools

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

This is not my example, but someone else mentioned it, and it is worth capturing:

Suppose in assignments, and quizzes in essays, you want to add a word-count widget to the editor, but you don't want that to appear in other places that use the editor. (Perhaps it is an option that can be turned on for some assignents and essay questions, but not others.)

I think acutally, the answer here it that word-counting should not be built into the editor. The word-count widget belongs to the assignment UI. Clearly it needs to use an API from the editor to get the currnet text, so it can count the words, but it should be a separate JavaScript widget, not part of the editor widget.

It should, however, be a reusable widget, so it can be used in both assignment and qtype_essay.

 

Average of ratings: -
In reply to Tim Hunt

Re: Three editor related requriements: 3. activity-specific editing tools

by Daniel Thies -
Picture of Core developers Picture of Plugin developers Picture of Testers

I would agree this would be useful in several contexts.  Currently this is partially available with mathematics with the Dragmath tool which appears in the default only with the TeX filter enabled.  The TeX  filter typically is enabled for mathematics and  science courses and this behavior prevents other courses from having Dragmath clutter the toolbar.  However, even in mathematics, there are contexts in which it may be helpful to have TeX for display, but not the Dragmath icon so it does not really make sense to have it tied to the filter.  Further there are a number of other mathematics tool plugins available like Geobebra and Geonext that have similar requirements. If several mathematics tools are used controlling them is perhaps unnecessarily confusing.  

I believe that the way that this is handled with Dragmath currently is that the plugin checks for the presence of the filter in the config setting in lib.php and does not load the button if it is not enabled. It provides useful functionality , but seems like a hack.

Average of ratings: -
In reply to Daniel Thies

Re: Three editor related requriements: 3. activity-specific editing tools

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Yes, it is a bit of a hack, becuase you might be using a different maths rendering filter, and so still want dragmath even if Moodle can't work that out automatically.

Average of ratings: -
In reply to Tim Hunt

Re: Three editor related requriements: 3. activity-specific editing tools

by Daniel Thies -
Picture of Core developers Picture of Plugin developers Picture of Testers

Ok, so then we are almost to next question. Suppose I have Dragmath and a shiny new HTML5 Math editor installed on the same site and some legacy courses require Dragmath and newer courses expect the new plugin, how would you suggest we configure some courses to use Dragmath and some to use only the new plugin? Both produce TeX, and I assume that having two options to do the same would create confusion among users. 

Average of ratings: -
In reply to Tim Hunt

Re: Three editor related requriements: 3. activity-specific editing tools

by Ken Krige -

I use the javaunittest question type for short java programming questions at high school level. The question type plugin works well but the default editor is terrible for source- code editing. Is there a way I can change this which is activity-specific?

Average of ratings: -
In reply to Tim Hunt

Re: Three editor related requriements: 1. other text input widgets

by Derek Chirnside -

"I am aware of three requirements around editors, that go a bit beyond a standard editor in a Moodleform"

I'm not exactly sure of your parameters here.  Is the "Drag and drop" of an image into an editor window 'beyond a standard editor'?

Also Tim, are you suggesting in (1) that super/subscript not be built in but it is a plugin and optional?

-Derek

Average of ratings: -
In reply to Derek Chirnside

Re: Three editor related requriements: 1. other text input widgets

by Damyon Wiese -
I read the discussion from last night in chat - and have some more comments/info.

First - passing a list of plugins to an instance of the editor doesn't make a whoe lot of sense. In general - we should never have plugins relying on other specific plugins, as it breaks things when someone installs a third-party plugin or configures things in a way you don't expect.

ie tiny might have a wordcount plugin - but it is not as good as another (pretend) one in the plugins db called countwords - but people can't use that because you have hardcoded a plugin name in another unrelated bit of code.

Things like that need to be abstracted into a more generic setting that multiple plugins can read and understand.

So - we can (for example) pass an option to the text editor to say - load "minimaltoolbar", and define different toolbar configurations for atto and tinymce for such as "minimaltoolbar", "examsafetoolbar", "defaulttoolbar" etc. This way it will work independently of the chosen editor.

Average of ratings: -
In reply to Damyon Wiese

Re: Three editor related requriements: 1. other text input widgets

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Sometimes, having one add-on rely on another makes perfect sense. Some examples

  • filter_glossary depends on mod_glossary
  • report_workflow depends on block_workflow (those are OU add-ons)
  • qtype_calculated depends on qtype_numerical (and there are many other depedencies between question types to avoid duplciating code)

So, your statement is over-broad, but you have a point. The specific dependency between tinymce_dragmath and filter_text is a mistake.

I think we are both agreeing that word-count should not be built into the editor if it is specifically part of the assignment or essay qtype UI.

However, a generic word-count tool that people can add to their editors throughout the site - like the word count tool in a word processor, makes sense as an available editor add-on.

Average of ratings: -
In reply to Tim Hunt

Re: Three editor related requriements: 1. other text input widgets

by Damyon Wiese -
This sounds fine - but if we implement that alternate toolbar configuration I mentioned, you could load Atto with a custom toolbar that has only those plugins enabled - or load tinymce with a custom toolbar with only those (if that works).

You may want to test the new equation editor which will has more features at the expense of being a bit more complex.
Average of ratings: -
In reply to Damyon Wiese

Re: Three editor related requriements: 1. other text input widgets

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

No, the requirement is specifically to have an input box that lets students type text with superscripts and subscripts, and nothing else, since that is what the question type knows how to parse and grade.

The fact that behind the scenes, this input widget happens to be built using the same code that we have for implementing the main HTML editor is incidental. However, it makes perfect sense from a development point of view that this resuse is possible, and I hope similar reuse will be possible with bits of the Atto codebase.

Note that it is not just a cut-down editor. We optimise it in other ways, e.g. make up and down arrow short-cuts for sup and sub.

If you are intereseted in how it works, the TinyMCE configuration is https://github.com/moodleou/moodle-editor_supsub/blob/master/lib.php#L114 . Note in particular the valid_elements and valid_children at the end, and there is an option to only allow one or the other in some settings.

The TinyMCE add-on to do the extra keyboard shortcuts is https://github.com/moodleou/moodle-editor_supsub/blob/master/supsub_plugin.js#L37

Average of ratings: -
In reply to Tim Hunt

Re: Three editor related requriements: 1. other text input widgets

by Daniel Thies -
Picture of Core developers Picture of Plugin developers Picture of Testers

Tim,

If I understand what you initially posted, you are not specifying a requirement for an editor, but by related you are referring to the moodle form API which calls the editor. In 2.6 users can set a preferred editor in their profile, You want the moodle form API to be able to overide this choice in a plugin module (such as a qtype).  This would enable the plugin developer or content author to control which editor the student uses in particular activities. Am I understanding you correctly?

Average of ratings: -
In reply to Daniel Thies

Re: Three editor related requriements: 1. other text input widgets

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

No.

This requirement 1 has no connection with moodle forms API.

Average of ratings: -
In reply to Tim Hunt

Re: Three editor related requriements: 1. other text input widgets

by Daniel Thies -
Picture of Core developers Picture of Plugin developers Picture of Testers

Has there been any thought about using capabilities to control editor behaviour?  This would be a better solution for the mathematics editor than tying it to the filter.  The editor plugin would just check to see whether the users has the correct permission and disable itself if not.  This should provide a way for teachers to place the appropriate plugins in the editor for a particular activity, or provide it to the teacher, but not the student, etc.

This may also work for requirements 1 and 2. For example the permission system could determine whether insert link appears when safe_exam_browser is used.

Average of ratings: -
In reply to Daniel Thies

Re: Three editor related requriements: 1. other text input widgets

by Mauno Korpelainen -

Daniel,

we had such discussions in editor forums already seven years ago - check for example this link (a year ago) https://moodle.org/mod/forum/discuss.php?d=223125#p973629

When moodle was using HTMLArea some of us were testing theme, role, user, course,...whatever selector based editors (configurations and optional editors) and once tinymce had replaced HTMLArea also optional plugins like Tim's sup/sub editor or my Math plugin packages. Personally I tried for example user profile settings, yui based user preferences, theme settings etc.

If core developers want to add such features to core moodle it's certainly possible with several methods.

Average of ratings: Useful (1)