Moodle
  1. Moodle
  2. MDL-20139

Allow admins to configure which TinyMCE toolbar buttons are used on their site

    Details

    • Affected Branches:
      MOODLE_20_STABLE, MOODLE_23_STABLE
    • Rank:
      742

      Description

      Related discussions:
      http://moodle.org/mod/forum/discuss.php?d=122460#p546841
      http://moodle.org/mod/forum/discuss.php?d=130470

      Attached: TinyMCE init code that will produce the editor in the screenshot. Note that this change does not require changing the code of TinyMCE but just of the JS code that calls TinyMCE.

      Still required: Integration as Moodle default. I could not find out how to do this.

      The goal of this change is to reduce the three row toolbar in TinyMCE to two rows, making it resemble the legacy HTMLarea more. There are two reasons for this:

      • the HTMLarea toolbar design seems to have seemingly good defaults for everyday use, and
      • since users in 1.9 are used to it, there is no risk in keeping the same toolbar (= WOW. for once we actually know what many users will expect).

      On the other hand, the TinyMCE default of three rows is really a usability disaster.

      I did regroup the buttons a bit from what they are in HTMLarea, to have related items grouped together and unrelated ones separated - and to accommodate the elements that were removed or replaced.

      Removed vs. the TinyMCE in Moodle HEAD atm:

      • The style menu that was broken
      • citation,abbreviation,acronym
      • select all - there is a quite ubiquitous shortcut key ctrl+a and this can be emulated with the mouse too
      • preview (this should be provided by Moodle and not within TinyMCE - perhaps as a quick javascript like TinyMCE does now, or just a plain old slow preview POST button - if the content of the form is more complex than one editor, Moodle can preview the result of all the fields in a composite preview, whereas TinyMCE can only show the preview of that one rich field, which is kind of pointless since it is a WYSIWYG editor anyway)
      • visual control characters on/off
      • edit css style
      • insert new layer (the layer created is positioned absolutely so there is usually no way for the user to know where on the page the layer will end...)
      • insert/edit embedded media
      • create anchor
      • insert/edit embedded media (removed due to lack of space, can perhaps be put back)

      Removed vs. HTMLarea

      • Clean Word HTML (paste from word is there though)
      • Lang menu (was not in tinymce full featured),
      • fullscreen
      • Justify both left and right - rarely needed and often considered harmful for legibility for reading onscreen

      Added vs. HTMLarea

      Instead of the popup window in HTMLarea, fullscreen in TinyMCE takes up the entire viewport for the rich text editor.
      Was there an equation editor? Where has that gone?

      1. patch.txt
        3 kB
        Olli Savolainen
      2. patch2.txt
        3 kB
        Olli Savolainen
      3. tiny.html
        1 kB
        Olli Savolainen
      1. 2010-10-18 moodle 3-row tinymce suggestion.png
        15 kB
      2. buttons removed from tinymce.png
        24 kB
      3. current version a.k.a we're all gonna die horribly unless we get to a lifeboat somewhere here.png
        17 kB
      4. custom theme with 800 x 600 px screen.jpg
        59 kB
      5. Editor switcher.jpg
        27 kB
      6. Kitchen sink plugin.jpg
        53 kB
      7. Must-have-buttons.jpg
        18 kB
      8. patch2.png
        14 kB
      9. Screenshot-1.png
        40 kB
      10. The most useful plugin on earth.jpg
        149 kB
      11. Yesterday - Today.jpg
        53 kB

        Issue Links

          Activity

          Hide
          Olli Savolainen added a comment -
          • Prevent automatic linking / moodlenolink.desc: realized what this is for, so adding it back.
          Show
          Olli Savolainen added a comment - Prevent automatic linking / moodlenolink.desc: realized what this is for, so adding it back.
          Hide
          Olli Savolainen added a comment -

          Finally found how this is done in Moodle so here is a patch after all. For fun, sort of.
          I put back the prevent linking and embedded media thingies, and since the theme used by default in moodle uses less space apparently, this is still pretty much as wide as the old HTMLarea. hm, are the buttons much smaller...?

          I would consider using: use_native_selects : true

          It is being recommended at http://tinymce.moxiecode.com/examples/example_17.php as an accessible option.

          Show
          Olli Savolainen added a comment - Finally found how this is done in Moodle so here is a patch after all. For fun, sort of. I put back the prevent linking and embedded media thingies, and since the theme used by default in moodle uses less space apparently, this is still pretty much as wide as the old HTMLarea. hm, are the buttons much smaller...? I would consider using: use_native_selects : true It is being recommended at http://tinymce.moxiecode.com/examples/example_17.php as an accessible option.
          Hide
          Mauno Korpelainen added a comment -

          First ideas that came to my mind when I read your list - please read the following 14 comments before you change TinyMCE back to clone of HTMLArea.

          1) People don't expect to get new HTMLAREA in moodle 2.0 - they expect to get a new and better editor, TinyMCE, with new features and some new buttons and plugins.
          2) It might be better to create 2-5 different basic configurations instead of one default configuration. Integration of editor is fully pluggable so we can simply create different init code (editor profiles), for example

          a) SIMPLE - maybe a little advanced anyway...
          b) OLDSTYLE - for those people who want to live in nostalgia of HTMLArea and have 2 rows of buttons
          c) FULL - all allowed buttons

          and I will of course create to my own tinymce

          d) CUSTOM - with all kinds of non core plugins and
          e) KIDS - test version for kids with totally different theme and buttons

          3) We need and can use a different configuration for FULL SCREEN EDITOR with

          fullscreen_settings :

          { ... }

          ,

          and at least table controls must be added to full scren editor to the 3rd row if you want to use HTMLAREA-TinyMCE. Table controls are in full screen mode of HTMLArea as well

          Some people may also want to open full screen editor in a new window and it can be done (if needed) with

          fullscreen_new_window : true,

          4) Style menu is not actually broken - we just need to give those styles either with theme_advanced_styles : ... in init code or directly in content_css file (note: css file!) .

          In moodle 2.0 Petr has set this with

          $contentcss = $CFG->themewww.'/'.current_theme().'/styles.php'; // should be customizable

          which means that we should give the style classes in current theme styles.php but for example standard theme styels.php does not have any styles defined in the file itself.
          If you change that line for example to

          $contentcss = $CFG->themewww.'/'.current_theme().'/styles_layout.css';

          and refresh your tinymce you should see quite many styles from styles_layout.css in styles menu.

          5) Removing "Select all" button is not always clear - all people don't know keyboard shortcuts and if you have for example spans in your editor content you may not be able to select all content with mouse... in editor mode.

          6) On my test site I am using a modified Preview plugin that renders mathematical notations WYSIWYG before I save them - because TinyMCE is not any wiser than HTMLArea to render TeX or asciimathML without extra code in extra plugins. The basic version is rather useless like you said

          7) Plugin "Style" (edit css style) adds CSS style editing support to TinyMCE, this will enable you to edit almost any CSS style property in a visual way. It's the most useful plugin for such people who use css ( span style="..." ) because all XHTML classes are properly given in tabs for different elements.

          8) Media plugin (QuickTime, Flash, ShockWave, RealPlayer and Windows Media Player) would be one of the most useful and wanted plugins for teachers but Petr has some concerns http://tracker.moodle.org/browse/MDL-19611

          9) Cut,copy and paste buttons should not be added - to protect users' private information, unprivileged scripts cannot invoke the Cut, Copy, and Paste commands. Editor blocks itself unless you use keyboard shortcuts.

          10) Why should we use hr when we have the advanced plugin "advhr" that supports noshade, width and size for hr ?

          11) Either Find or Find-Replace plugin but not both...they have the same tabs in different order. I might choose Find plugin.

          12) Dragmath - http://tracker.moodle.org/browse/MDL-19544
          I will never disable this in my custom configuration...

          13) Spellchecker is useful and easy to use

          14) http://moodle.org/mod/forum/discuss.php?d=130470

          Show
          Mauno Korpelainen added a comment - First ideas that came to my mind when I read your list - please read the following 14 comments before you change TinyMCE back to clone of HTMLArea. 1) People don't expect to get new HTMLAREA in moodle 2.0 - they expect to get a new and better editor, TinyMCE, with new features and some new buttons and plugins. 2) It might be better to create 2-5 different basic configurations instead of one default configuration. Integration of editor is fully pluggable so we can simply create different init code (editor profiles), for example a) SIMPLE - maybe a little advanced anyway... b) OLDSTYLE - for those people who want to live in nostalgia of HTMLArea and have 2 rows of buttons c) FULL - all allowed buttons and I will of course create to my own tinymce d) CUSTOM - with all kinds of non core plugins and e) KIDS - test version for kids with totally different theme and buttons 3) We need and can use a different configuration for FULL SCREEN EDITOR with fullscreen_settings : { ... } , and at least table controls must be added to full scren editor to the 3rd row if you want to use HTMLAREA-TinyMCE. Table controls are in full screen mode of HTMLArea as well Some people may also want to open full screen editor in a new window and it can be done (if needed) with fullscreen_new_window : true, 4) Style menu is not actually broken - we just need to give those styles either with theme_advanced_styles : ... in init code or directly in content_css file (note: css file!) . In moodle 2.0 Petr has set this with $contentcss = $CFG->themewww.'/'.current_theme().'/styles.php'; // should be customizable which means that we should give the style classes in current theme styles.php but for example standard theme styels.php does not have any styles defined in the file itself. If you change that line for example to $contentcss = $CFG->themewww.'/'.current_theme().'/styles_layout.css'; and refresh your tinymce you should see quite many styles from styles_layout.css in styles menu. 5) Removing "Select all" button is not always clear - all people don't know keyboard shortcuts and if you have for example spans in your editor content you may not be able to select all content with mouse... in editor mode. 6) On my test site I am using a modified Preview plugin that renders mathematical notations WYSIWYG before I save them - because TinyMCE is not any wiser than HTMLArea to render TeX or asciimathML without extra code in extra plugins. The basic version is rather useless like you said 7) Plugin "Style" (edit css style) adds CSS style editing support to TinyMCE, this will enable you to edit almost any CSS style property in a visual way. It's the most useful plugin for such people who use css ( span style="..." ) because all XHTML classes are properly given in tabs for different elements. 8) Media plugin (QuickTime, Flash, ShockWave, RealPlayer and Windows Media Player) would be one of the most useful and wanted plugins for teachers but Petr has some concerns http://tracker.moodle.org/browse/MDL-19611 9) Cut,copy and paste buttons should not be added - to protect users' private information, unprivileged scripts cannot invoke the Cut, Copy, and Paste commands. Editor blocks itself unless you use keyboard shortcuts. 10) Why should we use hr when we have the advanced plugin "advhr" that supports noshade, width and size for hr ? 11) Either Find or Find-Replace plugin but not both...they have the same tabs in different order. I might choose Find plugin. 12) Dragmath - http://tracker.moodle.org/browse/MDL-19544 I will never disable this in my custom configuration... 13) Spellchecker is useful and easy to use 14) http://moodle.org/mod/forum/discuss.php?d=130470
          Hide
          Mauno Korpelainen added a comment -

          One correction to my comment 11)

          The name of that plugin is of course "searchreplace" and it has two buttons - "search" and "replace" - and I might choose the first option, "search"

          Show
          Mauno Korpelainen added a comment - One correction to my comment 11) The name of that plugin is of course "searchreplace" and it has two buttons - "search" and "replace" - and I might choose the first option, "search"
          Hide
          Mauno Korpelainen added a comment -

          One thing is also true - we can't make too sweeping generalizations about expectations that different people may have...

          Some people have used moodle but don't know about new features of moodle 2.0 or tinymce and they may expect to see similar moodle as before.
          Some people have used moodle or tinymce and know about new features of moodle 2.0 or normal features of tinymce and they may expect to see new moodle with new features or normal tinymce and may even get disappointed when everything looks the same as before or tinymce does not look the same as they expected.
          Some people have never seen moodle or tinymce and don't know what to expect.

          Show
          Mauno Korpelainen added a comment - One thing is also true - we can't make too sweeping generalizations about expectations that different people may have... Some people have used moodle but don't know about new features of moodle 2.0 or tinymce and they may expect to see similar moodle as before. Some people have used moodle or tinymce and know about new features of moodle 2.0 or normal features of tinymce and they may expect to see new moodle with new features or normal tinymce and may even get disappointed when everything looks the same as before or tinymce does not look the same as they expected. Some people have never seen moodle or tinymce and don't know what to expect.
          Hide
          Mauno Korpelainen added a comment -

          Which leads again to docs, guiding and other helper systems. For teachers a short training about new features of moodle 2.0 is a must...might be good to have similar training or guides for students as well... but moodle 2.0 is still so unstable (untested by "normal users") that even most administrators don't know about new features...and what to expect.

          Show
          Mauno Korpelainen added a comment - Which leads again to docs, guiding and other helper systems. For teachers a short training about new features of moodle 2.0 is a must...might be good to have similar training or guides for students as well... but moodle 2.0 is still so unstable (untested by "normal users") that even most administrators don't know about new features...and what to expect.
          Hide
          Olli Savolainen added a comment -

          Just a quick note – if anyone wants to bring the "show advanced toolbar" button plugin for tinymce to moodle, here is the plugin wordpress has made for it. Apparently no need to hack tinymce core:
          http://demo.opensourcecms.com/wordpress/wp-includes/js/tinymce/plugins/wordpress/

          Mauno – thanks for the discussion in the forum thread. I haven't gotten around to looking at your latest comments yet (my employed period is over for now officially) but I will respond you in time - actually in quite a few threads you have responded me, I think.

          Show
          Olli Savolainen added a comment - Just a quick note – if anyone wants to bring the "show advanced toolbar" button plugin for tinymce to moodle, here is the plugin wordpress has made for it. Apparently no need to hack tinymce core: http://demo.opensourcecms.com/wordpress/wp-includes/js/tinymce/plugins/wordpress/ Mauno – thanks for the discussion in the forum thread. I haven't gotten around to looking at your latest comments yet (my employed period is over for now officially) but I will respond you in time - actually in quite a few threads you have responded me, I think.
          Hide
          Olli Savolainen added a comment -

          http://sourceforge.net/tracker/?func=detail&aid=1482404&group_id=103281&atid=738747
          http://www.laptoptips.ca/projects/tinymce-advanced/

          These may serve as UIs for customizing the editor per-moodle installation or maybe even per-user in some cases.

          Show
          Olli Savolainen added a comment - http://sourceforge.net/tracker/?func=detail&aid=1482404&group_id=103281&atid=738747 http://www.laptoptips.ca/projects/tinymce-advanced/ These may serve as UIs for customizing the editor per-moodle installation or maybe even per-user in some cases.
          Hide
          Mauno Korpelainen added a comment -

          Thanks Olli,

          we really have several ways to make those customized settings without touching core code of moodle at all - additional (pluggable) editors that can be changed from administration menu already (by administrator site wide), theme based integrations that can override settings of default editor (works if this special theme is selected and I have used these several years), plugins that can override settings of site editor if needed (for example different plugins that are rendered according to different capabilities) but I would like to go further and allow some user selection based settings.

          If we have an option to rewrite user profiles (sometimes in the future) to make the current user profile fields better organized, better selectable and themable we could as well at the same time add a tab for "Skins and buttons" where users could change some basic settings and selections for custom editor - teachers could show or hide there such plugins they need in everyday use or kids could change the style of their profle as a part of kids learning environment and make some simple skin selections (Pink Piggies or Masters of Moodleworld...)

          If we want to separate settings for different editors we could currently use new filters with filtersettings.php to add administration of custom editors to administration menu (to Filters menu unfortinately...) and use any selectable variables in our custom editors we want together with custom filters. Or editors could have settings.php for administration like modules and also themes are going to have.

          Personally I will test first some init code and plugin based options inside and outside the actual editor - they don't require any changes to any core files of moodle or tinymce - I can use both plugins and init code for these tests and if I find some good ways to show or hide some button groups directly from editor I will report about them to Petr and ask his opinion. This way we could actually allow users to use all plugins but they could be organized under some groups (buttons or even tabs) so that users would see first only the simple default editor but could select more advanced features with one button click - that's how most programs and browsers give those advanced features...

          Creating a site wide administration for editors is a big issue and our first task is to get the default editor as functional as we can - to check all possible settings

          Show
          Mauno Korpelainen added a comment - Thanks Olli, we really have several ways to make those customized settings without touching core code of moodle at all - additional (pluggable) editors that can be changed from administration menu already (by administrator site wide), theme based integrations that can override settings of default editor (works if this special theme is selected and I have used these several years), plugins that can override settings of site editor if needed (for example different plugins that are rendered according to different capabilities) but I would like to go further and allow some user selection based settings. If we have an option to rewrite user profiles (sometimes in the future) to make the current user profile fields better organized, better selectable and themable we could as well at the same time add a tab for "Skins and buttons" where users could change some basic settings and selections for custom editor - teachers could show or hide there such plugins they need in everyday use or kids could change the style of their profle as a part of kids learning environment and make some simple skin selections (Pink Piggies or Masters of Moodleworld...) If we want to separate settings for different editors we could currently use new filters with filtersettings.php to add administration of custom editors to administration menu (to Filters menu unfortinately...) and use any selectable variables in our custom editors we want together with custom filters. Or editors could have settings.php for administration like modules and also themes are going to have. Personally I will test first some init code and plugin based options inside and outside the actual editor - they don't require any changes to any core files of moodle or tinymce - I can use both plugins and init code for these tests and if I find some good ways to show or hide some button groups directly from editor I will report about them to Petr and ask his opinion. This way we could actually allow users to use all plugins but they could be organized under some groups (buttons or even tabs) so that users would see first only the simple default editor but could select more advanced features with one button click - that's how most programs and browsers give those advanced features... Creating a site wide administration for editors is a big issue and our first task is to get the default editor as functional as we can - to check all possible settings
          Show
          Mauno Korpelainen added a comment - A new suggestion here: http://moodle.org/mod/forum/discuss.php?d=130470&parent=574337#p575384
          Hide
          Olli Savolainen added a comment -

          Petr, I thought that you might be the right person to assign to, being the original creator of lib/editor/tinymce/lib.php

          Show
          Olli Savolainen added a comment - Petr, I thought that you might be the right person to assign to, being the original creator of lib/editor/tinymce/lib.php
          Hide
          Olli Savolainen added a comment -

          Because of the sprint, I decided to get this change that I most wanted to finish from last summer, into CVS.

          Petr, This has been discussed plenty in August, and I feel safe I have now listened to everybody's views sufficiently for this to be justified. Largely a similar set of buttons as in Moodle 1.9/HTMLarea. As noted by Mauno, it would be great to have further user-level (and depending on which context the editor is) flexibility on what controls show up in the editor, but this is probably the best compromise we can get for now. I advice to commit this change now to avoid the worse disaster of having three rows of buttons. When discussion proceeds further and we may get actual research on how much the controls are used, we can make further adjustments.

          Non-visible buttons, apparently to lack of TinyMCE module loading (that I reserved space for and that were and still are in the code): {$xdragmath} and spellchecker.

          Mauno, My apologies for coming to this so late. I simply ran out of time last summer so I could not continue the discussion. I have finally gone through all your comments. Thank you, Mauno, for all your hard work on this. I must admit I could not appreciate all your discussion last summer since it seemed to mean that the basic goal of simply getting rid of the extra buttons (that ended up in Moodle as a byproduct of getting TinyMCE) would not be reached.

          No, I do not want to prevent optional buttons or restrict anybody's choice. Just the reality is that I do not know who is going to implement that flexibility at the moment. But we need to start somewhere. We can determine a reasonable default, although we do not have much data. This is much better than the three rows in any case, I have understood we agree on that much, and unless we do something now, we will have those three rows in Moodle 2.0 since it will be released soon enough.

          The main focus in my last summer's work was to generate some guidelines, using which we could improve Moodle's future usability. I do not want to stick to the past just for the sake of it. However, the reason I want to keep the old configuration in HTMLarea is twofold:
          1) Everybody seems to agree the current config of TinyMCE we have is a nightmare. There is no reason related to the users for the change from between the button set in 1.9 (which happens to be HTMLarea) to the button set in current 2.0.
          2) If we want to develop the toolbar's usability, that requires research into the different contexts people use the editor in, that is: getting data about what is actually being used, and when. We do not have time for that.
          3) The option of no risk in terms of user expectations is to change the toolbar as little as possible, since that is what users are used to. This does not mean no addition of new features, but the old one should at least be the starting point for consideration.

          Now that I could finally snatch some time for reading what you wrote, I love your reasoning about users. You are at the core of user centered thinking, and I love the way you want to make Moodle inclusive to all user groups. Trust me, ultimately we are going in the very same direction with this. (A basic rule, though, is that users typically can not tell you what they need: you have to find out what they actually do, which is usually not the same. So techniques such as examining server log statistics [this we could in theory do on Moodle.org though not on remote Moodle installations?], ethnographies and usability tests help gain actual data.)

          At the end of the day, the discussion about flexibility and providing for various uses, comes to the key vision about Moodle. This has not been defined in a sufficient granularity to allow basing decisions like this on it. Ultimately, user-centered design methods could help identify the 80% we should be designing for primarily, while accommodating the rest in a less obvious way so that exotic features don't get in the way of the application's main usage. We are not there yet. Still, I believe the default should be so simple that it does not daunt the non-techies that Moodle is supposed to be made for, to start with.

          I removed paste (which works on virtually no browsers) and paste as plain text to make room for spell checking, dragmath (the button is not there though it is in the code), moodle media, moodle nolink, and paintweb. Cut/copy work fine in Chrome and I suspect others with the Webkit rendering engine.

          It feels pretty stupid to try to limit the toolbar width as the columns are so wide now that the editor will produce horizontal scrolling on a 1024x768 display anyway . Definitely hope that is going to be fixed before release!

          The current TinyMCE in Moodle 2.0 is more narrow though than HTMLarea was in 1.9 - but not narrow enough to avoid horizontal scrolling.

          There was no spell check included, and the only module loaded was iespell, and I did not add spell check for now. Hope to have it added though but it needs to be decided which of the methods is used and the appropriate module loaded http://wiki.moxiecode.com/index.php/TinyMCE:Plugins/spellchecker . I also hope to have PaintWeb in the toolbar next to the add image button, once it gets confirmed that it will be included.

          The table controls now form the third row in full screen, as you requested Mauno, and as it apparently is in HTMLarea, too. I am not sure if this is a good idea but for now, let us keep consistent with 1.9.

          I would have perhaps removed "Find" but that was the more recognizable of that and Find/Replace, which has a completely nonstandard icon. Can't hide find/replace functionality, either, so this is how it will have to stay.

          Show
          Olli Savolainen added a comment - Because of the sprint, I decided to get this change that I most wanted to finish from last summer, into CVS. Petr, This has been discussed plenty in August, and I feel safe I have now listened to everybody's views sufficiently for this to be justified. Largely a similar set of buttons as in Moodle 1.9/HTMLarea. As noted by Mauno, it would be great to have further user-level (and depending on which context the editor is) flexibility on what controls show up in the editor, but this is probably the best compromise we can get for now. I advice to commit this change now to avoid the worse disaster of having three rows of buttons. When discussion proceeds further and we may get actual research on how much the controls are used, we can make further adjustments. Non-visible buttons, apparently to lack of TinyMCE module loading (that I reserved space for and that were and still are in the code): {$xdragmath} and spellchecker. Mauno, My apologies for coming to this so late. I simply ran out of time last summer so I could not continue the discussion. I have finally gone through all your comments. Thank you, Mauno, for all your hard work on this. I must admit I could not appreciate all your discussion last summer since it seemed to mean that the basic goal of simply getting rid of the extra buttons (that ended up in Moodle as a byproduct of getting TinyMCE) would not be reached. No, I do not want to prevent optional buttons or restrict anybody's choice. Just the reality is that I do not know who is going to implement that flexibility at the moment. But we need to start somewhere. We can determine a reasonable default, although we do not have much data. This is much better than the three rows in any case, I have understood we agree on that much, and unless we do something now, we will have those three rows in Moodle 2.0 since it will be released soon enough. The main focus in my last summer's work was to generate some guidelines, using which we could improve Moodle's future usability. I do not want to stick to the past just for the sake of it. However, the reason I want to keep the old configuration in HTMLarea is twofold: 1) Everybody seems to agree the current config of TinyMCE we have is a nightmare. There is no reason related to the users for the change from between the button set in 1.9 (which happens to be HTMLarea) to the button set in current 2.0. 2) If we want to develop the toolbar's usability, that requires research into the different contexts people use the editor in, that is: getting data about what is actually being used, and when. We do not have time for that. 3) The option of no risk in terms of user expectations is to change the toolbar as little as possible, since that is what users are used to. This does not mean no addition of new features, but the old one should at least be the starting point for consideration. Now that I could finally snatch some time for reading what you wrote, I love your reasoning about users. You are at the core of user centered thinking, and I love the way you want to make Moodle inclusive to all user groups. Trust me, ultimately we are going in the very same direction with this. (A basic rule, though, is that users typically can not tell you what they need: you have to find out what they actually do, which is usually not the same. So techniques such as examining server log statistics [this we could in theory do on Moodle.org though not on remote Moodle installations?] , ethnographies and usability tests help gain actual data.) At the end of the day, the discussion about flexibility and providing for various uses, comes to the key vision about Moodle. This has not been defined in a sufficient granularity to allow basing decisions like this on it. Ultimately, user-centered design methods could help identify the 80% we should be designing for primarily, while accommodating the rest in a less obvious way so that exotic features don't get in the way of the application's main usage. We are not there yet. Still, I believe the default should be so simple that it does not daunt the non-techies that Moodle is supposed to be made for, to start with. I removed paste (which works on virtually no browsers) and paste as plain text to make room for spell checking, dragmath (the button is not there though it is in the code), moodle media, moodle nolink, and paintweb. Cut/copy work fine in Chrome and I suspect others with the Webkit rendering engine. It feels pretty stupid to try to limit the toolbar width as the columns are so wide now that the editor will produce horizontal scrolling on a 1024x768 display anyway . Definitely hope that is going to be fixed before release! The current TinyMCE in Moodle 2.0 is more narrow though than HTMLarea was in 1.9 - but not narrow enough to avoid horizontal scrolling. There was no spell check included, and the only module loaded was iespell, and I did not add spell check for now. Hope to have it added though but it needs to be decided which of the methods is used and the appropriate module loaded http://wiki.moxiecode.com/index.php/TinyMCE:Plugins/spellchecker . I also hope to have PaintWeb in the toolbar next to the add image button, once it gets confirmed that it will be included. The table controls now form the third row in full screen, as you requested Mauno, and as it apparently is in HTMLarea, too. I am not sure if this is a good idea but for now, let us keep consistent with 1.9. I would have perhaps removed "Find" but that was the more recognizable of that and Find/Replace, which has a completely nonstandard icon. Can't hide find/replace functionality, either, so this is how it will have to stay.
          Hide
          Olli Savolainen added a comment -

          (To have it documented somewhere clearly

          Changes since HTMLarea:

          Buttons removed: justify, anchor

          Buttons moved to another row:

          • To upper row: show source, search, replace
          • To lower row: subscript, superscript (related to formatting of small amounts of text like bold,italics, etc.)

          You could switch them back to where they were in HTMLarea, but then you would need to take two buttons up and three buttons down, so the so lower row would have at least two buttons more than the upper row, with the create image (xdragmath too I guess) coming later and also belonging to the lower row.

          Buttons added: Cut, copy, paste from word, remove formatting, add video, non-breaking space (plus xdragmath, create image later)

          Changes since TinyMCE in current Moodle 2.0:
          Removed: Citation, style menu, abbreviation, acronym, select all, paste, paste as text, anchor, insert new layer, edit css style, visual control characters on/off, preview

          Replaced: hr with advhr

          Show
          Olli Savolainen added a comment - (To have it documented somewhere clearly Changes since HTMLarea: Buttons removed: justify, anchor Buttons moved to another row: To upper row: show source, search, replace To lower row: subscript, superscript (related to formatting of small amounts of text like bold,italics, etc.) You could switch them back to where they were in HTMLarea, but then you would need to take two buttons up and three buttons down, so the so lower row would have at least two buttons more than the upper row, with the create image (xdragmath too I guess) coming later and also belonging to the lower row. Buttons added: Cut, copy, paste from word, remove formatting, add video, non-breaking space (plus xdragmath, create image later) Changes since TinyMCE in current Moodle 2.0: Removed: Citation, style menu, abbreviation, acronym, select all, paste, paste as text, anchor, insert new layer, edit css style, visual control characters on/off, preview Replaced: hr with advhr
          Hide
          Olli Savolainen added a comment -

          Just a random note: While considering the usage scenario of a forum discussion, I do gather that blockquotes are one strong candidate for addition to the default toolbar - their usage adds semantics to the posts. On the other hand, it is hard to say how many users actually would come to use blockquotes and how much they would actually benefit from them, as the same purpose is - to a debatable degree - served by just using quotes. If someone really misses having blockquotes, they may be probable to know enough html to insert them by hand...

          Show
          Olli Savolainen added a comment - Just a random note: While considering the usage scenario of a forum discussion, I do gather that blockquotes are one strong candidate for addition to the default toolbar - their usage adds semantics to the posts. On the other hand, it is hard to say how many users actually would come to use blockquotes and how much they would actually benefit from them, as the same purpose is - to a debatable degree - served by just using quotes. If someone really misses having blockquotes, they may be probable to know enough html to insert them by hand...
          Hide
          Olli Savolainen added a comment -

          Another thing - I really believe we should use a theme that is less of a distraction to the eye, like the default skin or even the black variant of the current 02k7 theme seems better imho - of course I have not had any resources to actually research this since that would require an eye tracker I guess, but as there are so many non-functional lines in the current theme that are absent in the default, it is probably lighter to scan through the buttons on skins that do not have borders everywhere.

          default: http://tinymce.moxiecode.com/examples/full.php
          02k7 black variant: http://tinymce.moxiecode.com/examples/skins.php

          If required, Petr I can change the patch for you, but I guess the change is simple enough.

          Show
          Olli Savolainen added a comment - Another thing - I really believe we should use a theme that is less of a distraction to the eye, like the default skin or even the black variant of the current 02k7 theme seems better imho - of course I have not had any resources to actually research this since that would require an eye tracker I guess, but as there are so many non-functional lines in the current theme that are absent in the default, it is probably lighter to scan through the buttons on skins that do not have borders everywhere. default: http://tinymce.moxiecode.com/examples/full.php 02k7 black variant: http://tinymce.moxiecode.com/examples/skins.php If required, Petr I can change the patch for you, but I guess the change is simple enough.
          Hide
          Olli Savolainen added a comment -

          Petr,

          Do you think you can still squeeze this into Moodle 2.0? I believe it is critical for the user experience to not have the massive toolbars to slow users down everywhere. The fix here is a no-brainer for me in terms of risks, the change from Moodle 1.9 being minimal, mostly just avoiding the disaster caused by using the defaults of TinyMCE.

          Let me know if there is anything I can do to help get this in, including submitting the patch to CVS myself (which would require allowing me to access to the relevant file in CVS - currently I can only access /mod/quiz and some other parts).

          Thanks. No pressure though if you simply can't make it.

          Show
          Olli Savolainen added a comment - Petr, Do you think you can still squeeze this into Moodle 2.0? I believe it is critical for the user experience to not have the massive toolbars to slow users down everywhere. The fix here is a no-brainer for me in terms of risks, the change from Moodle 1.9 being minimal, mostly just avoiding the disaster caused by using the defaults of TinyMCE. Let me know if there is anything I can do to help get this in, including submitting the patch to CVS myself (which would require allowing me to access to the relevant file in CVS - currently I can only access /mod/quiz and some other parts). Thanks. No pressure though if you simply can't make it.
          Hide
          Petr Škoda added a comment -

          Hi, thanks for pinging me, I have removed these icons.
          I am not sure the two line layout will fit everywhere, going to test it tomorrow.

          Hmmm, maybe we could still add some configuration option so that admins may decide what to include there, I am afraid that no other solution can be perfect here...

          Show
          Petr Škoda added a comment - Hi, thanks for pinging me, I have removed these icons. I am not sure the two line layout will fit everywhere, going to test it tomorrow. Hmmm, maybe we could still add some configuration option so that admins may decide what to include there, I am afraid that no other solution can be perfect here...
          Hide
          Petr Škoda added a comment -

          hehe, I hope nobody is going to notice the missing icons, it would be a good argument for their removal....

          Show
          Petr Škoda added a comment - hehe, I hope nobody is going to notice the missing icons, it would be a good argument for their removal....
          Hide
          Mauno Korpelainen added a comment -

          Petr,

          + 100 for the administration of buttons.

          In my math editor version I have a fully functional pdw plugin - based on TinyMCE Wordpress plugin (Kitchen Sink) and originally modified by Guido Neele.

          That plugin could be used for example to show customizable plugins / rarely used buttons on the 3rd row - do you want to test that pdw plugin?

          Show
          Mauno Korpelainen added a comment - Petr, + 100 for the administration of buttons. In my math editor version I have a fully functional pdw plugin - based on TinyMCE Wordpress plugin (Kitchen Sink) and originally modified by Guido Neele. That plugin could be used for example to show customizable plugins / rarely used buttons on the 3rd row - do you want to test that pdw plugin?
          Hide
          Mauno Korpelainen added a comment -

          See that attached screenshot of Kitchen sink plugin.jpg (I have those extra math plugins there on the 2nd row and rarely used plugins on the 3rd row)

          Show
          Mauno Korpelainen added a comment - See that attached screenshot of Kitchen sink plugin.jpg (I have those extra math plugins there on the 2nd row and rarely used plugins on the 3rd row)
          Hide
          Mauno Korpelainen added a comment -

          And in addition to such button switches like pdw plugin we have also those full screen mode settings so if some buttons don't fit to 2 or 3 rows they will certainly fit to 4 full length rows in full screen mode or more than one editor configuration for various situations (small screens like 640px wide may have real problems to fit tinymce and some themes have cut part of tinymce for example - there was some post about such issues on forums). Administration of buttons is one key of solutions, flexible layout / init code according to scren resolution might be another (tinymce is using javascript anyway so javascript could be used to detect screen resolution and use 4 rows of buttons for small screens instead of 2 or 3 rows)

          No doubt - EVERYBODY will notice those missing buttons ...

          Show
          Mauno Korpelainen added a comment - And in addition to such button switches like pdw plugin we have also those full screen mode settings so if some buttons don't fit to 2 or 3 rows they will certainly fit to 4 full length rows in full screen mode or more than one editor configuration for various situations (small screens like 640px wide may have real problems to fit tinymce and some themes have cut part of tinymce for example - there was some post about such issues on forums). Administration of buttons is one key of solutions, flexible layout / init code according to scren resolution might be another (tinymce is using javascript anyway so javascript could be used to detect screen resolution and use 4 rows of buttons for small screens instead of 2 or 3 rows) No doubt - EVERYBODY will notice those missing buttons ...
          Hide
          Olli Savolainen added a comment - - edited

          Yay, happy that you decided to tackle this Petr

          Petr, indeed there was a lot of discussion also with Mauno last year's summer/autumn about the fact that it would be great to be able to customize the options available, by admin and also on a per-user basis. In addition, it varies a lot on the usage context which buttons are required: in some situations (input of short labels) plain text formatting options are sufficient (font,size,bold,italics,link,list,indent), whereas in others full "document management" options are needed. So different editors for being available for different contexts would probably help in situations where the two-row editor is too large.

          However, the kitchen sink plugin is also an useful addition - in wordpress, a similar approach is used to switch from one-row mode to two-row mode (although they also have an always-visible additional element for adding media and switching to source view above the first row). Can't remember where that discussion was left earlier Mauno but great that you brought it up again.

          Making full screen mode have full four rows of buttons seems a bit of a strange design decision to me though - I understand that it would be a chance to have all the buttons you require Mauno at least somewhere, but imho the selection of the set of buttons should be independent of full screen mode.

          Admittedly the bulk of buttons do not take room in normal view when they are only in full screen mode. However, the reason I think it is critical to reduce the number of buttons is not primarily the room they take, but the cognitive overhead they impose on less technically oriented users (even if even I find it annoying, it does not slow me down - much - since I have learnt the meaning of most those icons along the years). I saw it in several usability tests: people get really frustrated when seeing a pile of icons, among which have to one by one browse to see the tooltips, since they do not know the meanings of many of the icons. Ultimately, if I recall correctly, some were even ready to give up the task of adding a simple image from the desktop at this point, since finding the functionality in the first place was too frustrating.

          And yes, it would be great if the button rows would wrap when they don't fit on the screen.

          Show
          Olli Savolainen added a comment - - edited Yay, happy that you decided to tackle this Petr Petr, indeed there was a lot of discussion also with Mauno last year's summer/autumn about the fact that it would be great to be able to customize the options available, by admin and also on a per-user basis. In addition, it varies a lot on the usage context which buttons are required: in some situations (input of short labels) plain text formatting options are sufficient (font,size,bold,italics,link,list,indent), whereas in others full "document management" options are needed. So different editors for being available for different contexts would probably help in situations where the two-row editor is too large. However, the kitchen sink plugin is also an useful addition - in wordpress, a similar approach is used to switch from one-row mode to two-row mode (although they also have an always-visible additional element for adding media and switching to source view above the first row). Can't remember where that discussion was left earlier Mauno but great that you brought it up again. Making full screen mode have full four rows of buttons seems a bit of a strange design decision to me though - I understand that it would be a chance to have all the buttons you require Mauno at least somewhere, but imho the selection of the set of buttons should be independent of full screen mode. Admittedly the bulk of buttons do not take room in normal view when they are only in full screen mode. However, the reason I think it is critical to reduce the number of buttons is not primarily the room they take, but the cognitive overhead they impose on less technically oriented users (even if even I find it annoying, it does not slow me down - much - since I have learnt the meaning of most those icons along the years). I saw it in several usability tests: people get really frustrated when seeing a pile of icons, among which have to one by one browse to see the tooltips, since they do not know the meanings of many of the icons. Ultimately, if I recall correctly, some were even ready to give up the task of adding a simple image from the desktop at this point, since finding the functionality in the first place was too frustrating. And yes, it would be great if the button rows would wrap when they don't fit on the screen.
          Hide
          Olli Savolainen added a comment -

          In fact, with the current theme of qa.moodle.org, even the current three row editor does not fit at 1024x768, let alone the suggestion here which makes the rows a bit longer. As the buttons should still fit in the space provided, it is actually critical that TinyMce adjust to the space available. Even if three rows is rather intensive, it is still better to have those three rows with the extra buttons removed, than it is to have the three very filled rows currently visible at qa.moodle.net.

          Show
          Olli Savolainen added a comment - In fact, with the current theme of qa.moodle.org, even the current three row editor does not fit at 1024x768, let alone the suggestion here which makes the rows a bit longer. As the buttons should still fit in the space provided, it is actually critical that TinyMce adjust to the space available. Even if three rows is rather intensive, it is still better to have those three rows with the extra buttons removed, than it is to have the three very filled rows currently visible at qa.moodle.net.
          Hide
          Olli Savolainen added a comment -

          http://drupal.org/node/308912

          as per this discussion, it seems that it would be possible to make the buttons be on one big row, and then just have float:left CSS to have the row wrap to multiple rows depending on space available. (or perhaps display:inline?)

          Show
          Olli Savolainen added a comment - http://drupal.org/node/308912 as per this discussion, it seems that it would be possible to make the buttons be on one big row, and then just have float:left CSS to have the row wrap to multiple rows depending on space available. (or perhaps display:inline?)
          Hide
          Mauno Korpelainen added a comment -

          There are some other options too - for example on one of my test sites http://korpelainen.net/m20t (where that kitchen sink button screenshot is from) I use an yui editor switcher that is using yui user preferences the same way as Sam implemented Splash theme to use 4 colours. The same way as we can allow users to select whole editor on the fly (on my test site from options tinymce, tinymath with math plugins or no editor) we could use also different init codes according to each situation - for example detection of screen resolution could lead to adding body class (if javascript is disabled it does not need any workarounds because editor can't be used without javascript anyway) and according to each body class we could use different toolbars.

          Show
          Mauno Korpelainen added a comment - There are some other options too - for example on one of my test sites http://korpelainen.net/m20t (where that kitchen sink button screenshot is from) I use an yui editor switcher that is using yui user preferences the same way as Sam implemented Splash theme to use 4 colours. The same way as we can allow users to select whole editor on the fly (on my test site from options tinymce, tinymath with math plugins or no editor) we could use also different init codes according to each situation - for example detection of screen resolution could lead to adding body class (if javascript is disabled it does not need any workarounds because editor can't be used without javascript anyway) and according to each body class we could use different toolbars.
          Hide
          Mauno Korpelainen added a comment -

          This user preference switcher on my demo site is a little clumsy but you can get the idea from Editor switcher sreenshot. I have been testing different kinds of user preferences there and therefore used "Change your user preferences" link - core toolbar switchers can be simple buttons or menus etc

          Show
          Mauno Korpelainen added a comment - This user preference switcher on my demo site is a little clumsy but you can get the idea from Editor switcher sreenshot. I have been testing different kinds of user preferences there and therefore used "Change your user preferences" link - core toolbar switchers can be simple buttons or menus etc
          Hide
          Mauno Korpelainen added a comment -

          Well that Full screen mode with full 4 rows of buttons was partly a joke...

          In practise people have very few custom plugins - but on small screens full screen is not so wide after all.

          Mobile devices may have from 320 to 640px space (or maximum 960px) and even if 96% of current PC screen resolutions are wider than 1024x768 px some small screen laptops have a permanent problem to use editor with any theme of core moodle.

          Show
          Mauno Korpelainen added a comment - Well that Full screen mode with full 4 rows of buttons was partly a joke... In practise people have very few custom plugins - but on small screens full screen is not so wide after all. Mobile devices may have from 320 to 640px space (or maximum 960px) and even if 96% of current PC screen resolutions are wider than 1024x768 px some small screen laptops have a permanent problem to use editor with any theme of core moodle.
          Hide
          Mauno Korpelainen added a comment -

          And since moodle 2 does not yet fully support mobile devices (themes, editor...) this screen resolution problem is not so urgent yet - still it is good to keep it in memory for the next release of moodle (2.1?) ...

          Show
          Mauno Korpelainen added a comment - And since moodle 2 does not yet fully support mobile devices (themes, editor...) this screen resolution problem is not so urgent yet - still it is good to keep it in memory for the next release of moodle (2.1?) ...
          Hide
          Olli Savolainen added a comment -

          there are plenty netbooks etc around, and the iPad of course and following tablets. even I was using a ~5 year old thinkpad laptop just 2 months ago that had max 1024x768. so i believe official support for 1024x768 is the absolute minimum for years to come.

          found statistics for techie site users, which probably means that the percentages for higher resolutions are higher here than on more mainstream sites, as mentioned on the page itself: http://www.w3schools.com/browsers/browsers_display.asp

          Show
          Olli Savolainen added a comment - there are plenty netbooks etc around, and the iPad of course and following tablets. even I was using a ~5 year old thinkpad laptop just 2 months ago that had max 1024x768. so i believe official support for 1024x768 is the absolute minimum for years to come. found statistics for techie site users, which probably means that the percentages for higher resolutions are higher here than on more mainstream sites, as mentioned on the page itself: http://www.w3schools.com/browsers/browsers_display.asp
          Hide
          Mauno Korpelainen added a comment -

          The buttons of Petr's current version in CVS actually do fit in layout of 1024 x 768 (buttons in 3 rows) and they fit even to 960px screens with minimal cut - and not anymore to 800 x 600 px screen layouts where right blocks (or on rtl languages left blocks) start cutting part of buttons on most themes. On the other hand toolbar on wide screens has extra space on the left side of buttons.

          But that's partly a layout / theme design problem. Attached an example ("custom theme with 800 x 600 px screen") from my test site with Petr's current buttons on my custom theme that is placing all blocks to the left - in fact themes should take care that if screen resolution is small moodle should not use 3 column layouts at all.

          Show
          Mauno Korpelainen added a comment - The buttons of Petr's current version in CVS actually do fit in layout of 1024 x 768 (buttons in 3 rows) and they fit even to 960px screens with minimal cut - and not anymore to 800 x 600 px screen layouts where right blocks (or on rtl languages left blocks) start cutting part of buttons on most themes. On the other hand toolbar on wide screens has extra space on the left side of buttons. But that's partly a layout / theme design problem. Attached an example ("custom theme with 800 x 600 px screen") from my test site with Petr's current buttons on my custom theme that is placing all blocks to the left - in fact themes should take care that if screen resolution is small moodle should not use 3 column layouts at all.
          Hide
          Mauno Korpelainen added a comment -

          One correction - I should have said: "On the other hand toolbar on wide screens has extra space on the right side of buttons"

          ( but there is of course pleanty of empty space also on the left side of editor if small screen layouts would not place titles like "Subject" and "Message" to the left side but over editor... )

          Lot's of things could be done differently on small screens - eventually

          Show
          Mauno Korpelainen added a comment - One correction - I should have said: "On the other hand toolbar on wide screens has extra space on the right side of buttons" ( but there is of course pleanty of empty space also on the left side of editor if small screen layouts would not place titles like "Subject" and "Message" to the left side but over editor... ) Lot's of things could be done differently on small screens - eventually
          Hide
          Olli Savolainen added a comment - - edited

          Oh!

          Thanks Petr for the changes so far. Realizing that we still need to limit the width, keeping it three-row seems a great idea to me, too. Why didn't I think that far myself? .

          Anyhow, having realized that, I do believe that the most obvious and commonly used elements in the toolbar should still be the most prominent ones. This is a slippery slope and very subjective I know, but I believe we can make a civilized guess based on what is the best known to users by looking at what is available elsewhere most commonly.

          So I am attaching such a guess (2010-10-18 moodle 3-row tinymce suggestion.png): what now shows at qa.moodle.net, but with reordered buttons. I did this with a bitmap editor but I can create it as a patch too, if you wish.

          I believe ordering the buttons such that the most well known are first is beneficial in any case. However, I still believe that we need to add the kitchen sink plugin (that basically introduces progressive disclosure to the UI). Then we would have a maximum of two rows by default, even at the current width. Notice that there is now room for one more button in second row, while still keeping the width? That's the spot for the "show 3rd row" button.

          If I can help by making the patch for all this that you can just apply, just let me know.

          Show
          Olli Savolainen added a comment - - edited Oh! Thanks Petr for the changes so far. Realizing that we still need to limit the width, keeping it three-row seems a great idea to me, too. Why didn't I think that far myself? . Anyhow, having realized that, I do believe that the most obvious and commonly used elements in the toolbar should still be the most prominent ones. This is a slippery slope and very subjective I know, but I believe we can make a civilized guess based on what is the best known to users by looking at what is available elsewhere most commonly. So I am attaching such a guess (2010-10-18 moodle 3-row tinymce suggestion.png): what now shows at qa.moodle.net, but with reordered buttons. I did this with a bitmap editor but I can create it as a patch too, if you wish. I believe ordering the buttons such that the most well known are first is beneficial in any case. However, I still believe that we need to add the kitchen sink plugin (that basically introduces progressive disclosure to the UI). Then we would have a maximum of two rows by default, even at the current width. Notice that there is now room for one more button in second row, while still keeping the width? That's the spot for the "show 3rd row" button. If I can help by making the patch for all this that you can just apply, just let me know.
          Hide
          Olli Savolainen added a comment -

          Links to two versions of the kitchen sink plugin.
          The first one comes along with another skin that makes would seem to make the visual appearance considerably less fixation-intensive, and thus quicker for the eye to scan than the current one in use in Moodle.

          http://www.cirkuit.net/projects/tinymce/cirkuitSkin/example2.html

          http://www.neele.name/pdw_toggle_toolbars/

          I take it this latter one is the one you are using, Mauno?

          (Sorry for the comment spam, again...)

          Show
          Olli Savolainen added a comment - Links to two versions of the kitchen sink plugin. The first one comes along with another skin that makes would seem to make the visual appearance considerably less fixation-intensive, and thus quicker for the eye to scan than the current one in use in Moodle. http://www.cirkuit.net/projects/tinymce/cirkuitSkin/example2.html http://www.neele.name/pdw_toggle_toolbars/ I take it this latter one is the one you are using, Mauno? (Sorry for the comment spam, again...)
          Hide
          Mauno Korpelainen added a comment -

          I am using in my modified math plugin editor init code this attached Guido Neele's version without jQuery (pdw.zip) - I suppose it was that Example 5 in your link, Olli.

          I have added pdw to plugins row (in editor init code /lib.php) with

          'plugins' => "{$xmedia}pdw,...

          to the 1st row of buttons with

          'theme_advanced_buttons1' => "pdw_toggle,fontselect,...

          and before spellchecker code

          'pdw_toggle_on' => "1",
          'pdw_toggle_toolbars' => "3",
          'spellchecker_rpc_url' => ...

          which shows two first toolbar rows by default and toggles 3rd row with kitchen sink button.

          Show
          Mauno Korpelainen added a comment - I am using in my modified math plugin editor init code this attached Guido Neele's version without jQuery (pdw.zip) - I suppose it was that Example 5 in your link, Olli. I have added pdw to plugins row (in editor init code /lib.php) with 'plugins' => "{$xmedia}pdw,... to the 1st row of buttons with 'theme_advanced_buttons1' => "pdw_toggle,fontselect,... and before spellchecker code 'pdw_toggle_on' => "1", 'pdw_toggle_toolbars' => "3", 'spellchecker_rpc_url' => ... which shows two first toolbar rows by default and toggles 3rd row with kitchen sink button.
          Hide
          Petr Škoda added a comment -

          1/ my personal preference is to have just one line by default and expand it to 3 lines after some click
          2/ the configuration settings for each row should be pretty simple, working on that right now - hopefully this will help with adding of extra plugins too
          3/ I think it is important to put the "FUll screen" button to the left instead of right, because you need it most when the right side not there due to screen smallness, right?
          4/ I agree that the minimum supported should be 1024x600 because there are too many netbooks around (I gave one to my girl friend too...)
          5/ I agree it might be good to reorder the buttons

          I am going to ask Martin what he thinks about the 1 x 3 line switching and then we could commit the changes into CVS.

          Show
          Petr Škoda added a comment - 1/ my personal preference is to have just one line by default and expand it to 3 lines after some click 2/ the configuration settings for each row should be pretty simple, working on that right now - hopefully this will help with adding of extra plugins too 3/ I think it is important to put the "FUll screen" button to the left instead of right, because you need it most when the right side not there due to screen smallness, right? 4/ I agree that the minimum supported should be 1024x600 because there are too many netbooks around (I gave one to my girl friend too...) 5/ I agree it might be good to reorder the buttons I am going to ask Martin what he thinks about the 1 x 3 line switching and then we could commit the changes into CVS.
          Show
          Mauno Korpelainen added a comment - http://www.neele.name/pdw_toggle_toolbars/no_jquery.php
          Hide
          Mauno Korpelainen added a comment -

          Damn and blast!!!!

          You dropped out two of my favourite plugins, Olli...

          Dragmath and Style plugin.

          GRRRRRRRRRRRRRRRRRRRRRR

          Show
          Mauno Korpelainen added a comment - Damn and blast!!!! You dropped out two of my favourite plugins, Olli... Dragmath and Style plugin. GRRRRRRRRRRRRRRRRRRRRRR
          Hide
          Mauno Korpelainen added a comment -

          Olli,

          I know that you have never used style plugin so attached a screenshot about styles that you can modyfy for each and every element that supports style="..."

          And Dragmath is one of the most wished plugins - the only math plugin we have in core now. I could drop two lines of other less useful plugins

          Show
          Mauno Korpelainen added a comment - Olli, I know that you have never used style plugin so attached a screenshot about styles that you can modyfy for each and every element that supports style="..." And Dragmath is one of the most wished plugins - the only math plugin we have in core now. I could drop two lines of other less useful plugins
          Hide
          Mauno Korpelainen added a comment -

          Petr & Olli,

          attached one more screenshot "Must-have-buttons".

          In my opinion most people need font family and font size menus and bold, italics, underline, text foreground and background colors, insert image and insert link buttons. And obviously first toolbar row needs full screen mode button + probably kitchen sink button...

          Then we have buttons that very many people use: HTML (code), lists, alignment, intend, strikethrough, subscript and supscript, insert tables or media, paste from Word, undo, unlink and spellchecker.

          Finally we have lots of buttons that some people need all the time but some people never use: paragraph, non-breaking spaces, insert characters, cleanup, rtl/ltr, search/search-replace, insert text, redo, dragmath, style (styleprops), moodlenolink and a few custom plugins that are not in core moodle. All the buttons on the 3rd row could be optional in default init code (selectable from administration menu / editor settings) - still kitchen sink button is not a must-have-button. For human eye it does not matter a lot if there are 2 or 3 rows in toolbar.

          Personally I prefer such solutions where the whole editor can be changed with one switch either with (yui) user preferences, screen resolution detection or theme files and $CFG->texteditors as an essential part of theme - it is not a big problem to create separate init code for mobile phones if those ipods and ipads (Apple) start to support editors like tinymce some day or screen widths less than 1024px/960px/800px. The new pluggable editor code that Petr has implemented is the best new feature in moodle 2 and even if we now try to find only one default code for all users it might be cood to have more than one options in the future...

          Show
          Mauno Korpelainen added a comment - Petr & Olli, attached one more screenshot "Must-have-buttons". In my opinion most people need font family and font size menus and bold, italics, underline, text foreground and background colors, insert image and insert link buttons. And obviously first toolbar row needs full screen mode button + probably kitchen sink button... Then we have buttons that very many people use: HTML (code), lists, alignment, intend, strikethrough, subscript and supscript, insert tables or media, paste from Word, undo, unlink and spellchecker. Finally we have lots of buttons that some people need all the time but some people never use: paragraph, non-breaking spaces, insert characters, cleanup, rtl/ltr, search/search-replace, insert text, redo, dragmath, style (styleprops), moodlenolink and a few custom plugins that are not in core moodle. All the buttons on the 3rd row could be optional in default init code (selectable from administration menu / editor settings) - still kitchen sink button is not a must-have-button. For human eye it does not matter a lot if there are 2 or 3 rows in toolbar. Personally I prefer such solutions where the whole editor can be changed with one switch either with (yui) user preferences, screen resolution detection or theme files and $CFG->texteditors as an essential part of theme - it is not a big problem to create separate init code for mobile phones if those ipods and ipads (Apple) start to support editors like tinymce some day or screen widths less than 1024px/960px/800px. The new pluggable editor code that Petr has implemented is the best new feature in moodle 2 and even if we now try to find only one default code for all users it might be cood to have more than one options in the future...
          Hide
          Petr Škoda added a comment -

          Font family and Font size makes me sick every time I see it, I would personally vote to switch these with the "Paragraph,heading,.." selector.

          Show
          Petr Škoda added a comment - Font family and Font size makes me sick every time I see it, I would personally vote to switch these with the "Paragraph,heading,.." selector.
          Hide
          Mauno Korpelainen added a comment -

          I understand your point Petr but if you think about other most common text editing tools like MS Word - typical users seldom use css or otherwise pre-defined styles, they simply want to change font family (fonts) and size of font for their texts - and color & text effects.

          And one more important button is missing - that Emotions/Emoticons/Smileys button

          Show
          Mauno Korpelainen added a comment - I understand your point Petr but if you think about other most common text editing tools like MS Word - typical users seldom use css or otherwise pre-defined styles, they simply want to change font family (fonts) and size of font for their texts - and color & text effects. And one more important button is missing - that Emotions/Emoticons/Smileys button
          Hide
          Mauno Korpelainen added a comment -

          When we are talking about those useful buttons vs needless buttons I would still rename two buttons needless - search and replace - honestly.

          If you write a couple of rows in editor how often do you need to find some word from your editor screen - and replace it. I could somehow understand one of these plugins (they have the same tabs but those two tabs are opened in different order by default) - buth both of them - why???

          On the other hand in every suggestion Olli has made in forums and here in tracker he drops Style plugin (styleprops in buttons) which is the most advanced plugin of all tinymce plugins - a real hidden pearl...

          It's just a question of opinions - some people want to use plain textarea and code, some want to use simple theme with simple tools and some want to use all the tools they find useful.

          Show
          Mauno Korpelainen added a comment - When we are talking about those useful buttons vs needless buttons I would still rename two buttons needless - search and replace - honestly. If you write a couple of rows in editor how often do you need to find some word from your editor screen - and replace it. I could somehow understand one of these plugins (they have the same tabs but those two tabs are opened in different order by default) - buth both of them - why??? On the other hand in every suggestion Olli has made in forums and here in tracker he drops Style plugin (styleprops in buttons) which is the most advanced plugin of all tinymce plugins - a real hidden pearl... It's just a question of opinions - some people want to use plain textarea and code, some want to use simple theme with simple tools and some want to use all the tools they find useful.
          Hide
          Petr Škoda added a comment -

          David is working on the emotions button.

          Show
          Petr Škoda added a comment - David is working on the emotions button.
          Hide
          Olli Savolainen added a comment -

          Good to see this going forward.

          Unfortunately I am in a flu and occupied by my current job, so can't promise taking part in this discussion much more. But I do trust your judgement on this already based on the discussion so far.

          Just happy to see this getting done. Thanks guys.

          Show
          Olli Savolainen added a comment - Good to see this going forward. Unfortunately I am in a flu and occupied by my current job, so can't promise taking part in this discussion much more. But I do trust your judgement on this already based on the discussion so far. Just happy to see this getting done. Thanks guys.
          Hide
          Petr Škoda added a comment -

          I am waiting for Martin to return from his world tour, thanks for all the valuable ideas and feedback.

          Show
          Petr Škoda added a comment - I am waiting for Martin to return from his world tour, thanks for all the valuable ideas and feedback.
          Hide
          Martin Dougiamas added a comment -

          Adding myself as watcher. Will read all this in the next day.

          Show
          Martin Dougiamas added a comment - Adding myself as watcher. Will read all this in the next day.
          Hide
          Helen Foster added a comment -

          Thanks everyone for your comments. Hopefully Martin will be able to comment soon...

          Show
          Helen Foster added a comment - Thanks everyone for your comments. Hopefully Martin will be able to comment soon...
          Hide
          Petr Škoda added a comment -

          Reassigning back to HQ.

          Show
          Petr Škoda added a comment - Reassigning back to HQ.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Ping! Feedback about this needed, Martin. Feel free to comment / triage / whatever.

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Ping! Feedback about this needed, Martin. Feel free to comment / triage / whatever. Ciao
          Hide
          CLAIRE BROWNE added a comment -

          Is it possible to remove button all together from TINY MCE? For instant, I just want my learners to have insert image, text colour changer and spellchecker available to them.

          Show
          CLAIRE BROWNE added a comment - Is it possible to remove button all together from TINY MCE? For instant, I just want my learners to have insert image, text colour changer and spellchecker available to them.
          Hide
          Nadav Kavalerchik added a comment -

          I would like to emphasize the important of Mauno Korpelainen suggestion:
          7) Plugin "Style" (edit css style) adds CSS style editing support to TinyMCE, this will enable you to edit almost any CSS style property in a visual way. It's the most useful plugin for such people who use css ( span style="..." ) because all XHTML classes are properly given in tabs for different elements.

          The Style plugin seems to be present, but not visually available, seems like a bug
          Anyone care to comment on this?

          Show
          Nadav Kavalerchik added a comment - I would like to emphasize the important of Mauno Korpelainen suggestion: 7) Plugin "Style" (edit css style) adds CSS style editing support to TinyMCE, this will enable you to edit almost any CSS style property in a visual way. It's the most useful plugin for such people who use css ( span style="..." ) because all XHTML classes are properly given in tabs for different elements. The Style plugin seems to be present, but not visually available, seems like a bug Anyone care to comment on this?
          Hide
          Tim Hunt added a comment -

          I'm taking the liberty of renaming the bug to make it clearer what needs to be done. This functionality was available in Moodle 1.9, and we lost it with the move to TinyMCE Moodle 2.0. If no one else does this for Moodle 2.4, I guess I will, because we need this at the OU.

          Show
          Tim Hunt added a comment - I'm taking the liberty of renaming the bug to make it clearer what needs to be done. This functionality was available in Moodle 1.9, and we lost it with the move to TinyMCE Moodle 2.0. If no one else does this for Moodle 2.4, I guess I will, because we need this at the OU.
          Hide
          Jean-Michel Vedrine added a comment -

          Linking to the work done by Sam and Petr to support custom plugins

          Show
          Jean-Michel Vedrine added a comment - Linking to the work done by Sam and Petr to support custom plugins
          Hide
          Michael de Raadt added a comment -

          Giving this a bump.

          Show
          Michael de Raadt added a comment - Giving this a bump.
          Hide
          Nadav Kavalerchik added a comment -

          I have a list of HTMLAREA plugins i am waiting to integrate into TinyMCE
          http://tracker.moodle.org/browse/CONTRIB-2730

          Show
          Nadav Kavalerchik added a comment - I have a list of HTMLAREA plugins i am waiting to integrate into TinyMCE http://tracker.moodle.org/browse/CONTRIB-2730
          Hide
          Petr Škoda added a comment -

          Hello, this should be finally resolved by MDL-35172 and other subtasks of the parent issue. If you want and more improvements or tweaks please comment in MDL-34875.

          Thanks for the report and cooperation.

          Show
          Petr Škoda added a comment - Hello, this should be finally resolved by MDL-35172 and other subtasks of the parent issue. If you want and more improvements or tweaks please comment in MDL-34875 . Thanks for the report and cooperation.

            People

            • Votes:
              10 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: